The Software Developer

Intel’s Atom CPU’s are by no means a powerhouse compared to many of the multicore desktop and laptop CPU’s in use today. It is a matter of compromise. The SOC (system on a chip) design of the Atom CPU’s , plainly put, is for mobile. Small size and minimal amount of power usage are the criteria. So does this make the Atom CPU’s bad ?

No !

The problem with the Atom CPU is Windows and how most software is built today.  I was writing software back in the days when the CPU’s were 1/10th the power of an Atom CPU and they could do quite a lot back then. The key is how software is created. Do you realize that Windows 95 could run on a computer with as little as 8 meg ram ? My first Windows 95 computer had a 586 CPU (a souped up 486) and 8 meg ram. Today CPU’s are measured in gigahertz, while back then CPU’s were measured in megahertz. The thing though was that back then Windows software was often written in C (not C++) and was native code (WIN32). It wasn’t easy to write software using C and the WIN32′s, but it produced fast software which had a small footprint.

Today, in my opinion, two things have contributed to bloated (and slow) software. The first is managed programming languages (aka. dot.net).  The second is the overuse of OOP (Object Oriented Programming).  If you read some of my other posts in this blog, you will see some of my thoughts (and that of others) about OOP. OOP adds a level of complexity to software, which I strongly feel makes programming harder and adds a lot of bloat to software.

What we need today, to make Atom based tablet computers look good, is better software, which runs faster and has a smaller footprint. Having used PowerBasic for about a decade now, I have been spoiled when it comes to small and fast executables.  Why do I say that ?

If you have browsed my web site, you likely know that I developed my GUI engine (EZGUI 5.0 Pro) using PowerBasic and for use with the PowerBasic compiler. Two things I have learned from building this GUI engine. (1) One can build reusable code which is small and fast using absolutely no OOP at all. The size of the EZGUI runtimes are amazingly small and I give the credit to both the PowerBasic compiler, as well as to using a procedural style of coding (no OOP). (2) Second, is that if a library can be written to be tiny, imagine how small executables can be if they reuse that library,

For example, let’s consider my freeware 3D model viewer app which I created using EZGUI 5.0 (see:  http://cwsof.com/forums/index.php?topic=266.msg2146#msg2146 ). Because the EXE uses the EZGUI runtimes, which do most of the work, how big do you think the actual app EXE is ? It is only 58 KB in size ! The app has a nice GUI with multiple controls in it, multiple OpenGL controls, can load STL 3D models and display them and can modify the 3D model in real time. Now imagine what happens if I were to write a suite of apps that all uses the same runtime. The runtime exists one time, but the apps EXE’s are all small in size (tiny actually) and share the same runtime. Is that not what code resuability is all about ?

So with the right compiler and well written libraries, developers can write powerful apps which require minimal hardware to run. Now this means a lot for something like a tablet computer, which has minimal memory, memory SSD space and a minimal CPU (to save power). So rather than blame the Atom CPU for all the problems with poorly running software, maybe the blame really should be placed on the software itself.

I think the Atom CPU is well suited to both Windows 7 and Windows 8 (desktop), as long as one writes software using a fast compiler and avoids OOP as much as possible.

Everybody wants cross platform choices, but few appreciate the problems with this and the disadavantages.

As a software developer, I have struggled with the decision of whether to stick with a single platform or to look for better ways to write software which can be run on multiple platforms. For this discussion let’s consider Windows 95 to Windows 7 as one platform, the Windows platform. Then you have the Mac platform and then Linux. Windows 8 will introduce a new platform with Windows for ARM, which I consider a different platform than normal Windows.

So what is the big deal you may say ?

There are two key issues for multiplatform development:

(1) The operating system

(2) The CPU family the operating supports.

Lets first look at the operating system. Different operating systems have different API’s programmers (or compilers) which often are significantly different than each other. It is not easy (or even practical some times) to try to make an application run identical on two different platforms. It can be done, but often it is done at the expense of key features unique to each operating system. Such applications are hybrids which only use what is common between the operating systems and often they have to use work arounds in areas not common to both operating systems. This puts more pressure on the developers because they can’t take advantage of some fetaures because one operating doesn’t support it. Have companies successfully developed and marketed cross platform applications. Yes and No. I will use one example to explain what I mean. Corel for years made CorelDraw (its flagship product) available for both Mac and Windows. When you ran Coreldraw on Windows it was obvious it was a hybrid. You can tell the developers had to make sacrifices to make it run on both Mac and Windows. The interesting thing about Corel is that while it successfully developed and marketed both a Mac and Windows version for years, they finally reached a point when they decided on developing for Windows only. Why ? Well I can’t speak for Corel and I doubt it was because Mac was not a valuable platform to develop for, but consider this. They chose the platform with the larger user base (obviously Windows) and the Windows only version didn’t have that hybrid look and feel any more. It was a true 100% Windows application which used all the features available to the Windows operating system.

Why would a software developer feel they needed to target a single operating system ?

Its because operating systems are so uniquely different from each other, especially under the hood, that trying to develop hybrid applications forces a developer to make too many sacrifices. You just can not get the best of both worlds as they say. I happen to agree that this is a problem and also this is why too many operating system choices can actually decrease software quality rather than increase it because of the desire of many for cross platform development. I personally like the idea of learning to become an expert on just one operating system, rather than trying to be a “jack of all trades, but master of none” with multiple operating systems.

Now I should point out that some consider Windows to be multiplatform because of all the different versions (95 to Windows 7), but as an experienced Windows API programmer I can tell you that Windows provides a number of mechanisms to allow one to develop applications which can run on all versions of Windows (albeit early versions may not support a feature, but the app can be designed to test for this and use an alternate solution). My own EZGUI 5.0 was designed to it can run on Windows 95, which the runtime supports with nearly 90% or more of its feature set, but still can be run on Windows Vista, 7 (and 8) and use the new features they support by dynamically loading them at runtime.

Yet I do not consider Windows 8 for ARM (CPU’s) the same as Windows in general. Why ?

Because of the second problem and that is the CPU family an operating system was designed for. Interestingly, the x86 (Intel , AMD) family of CPU’s has an amazing advantage over others in that it has a long history of growth and improvement, but yet maintaining an amazing amount of backward compatiblity. For example the latest x86 CPUs’ could be used to run the ancient DOS operating system, even today and a programmer can write inline assembler to access some of the new features of the CPU. 64 bit x86 CPU’s can run 32 bit operating systems if you want to. Now add to this the Windows operating system, which too provides significant backward compatibility. To appreciate this, consider my own EZGUI GUI engine. I designed it specifically to use long time API’s which have been in Windows since Windows 95 but are still perfectly supported in Windows 8. True Microsoft has added a lot of stuff on top of the core API, but it is amazing how little the core of Windows has changed. With the renewed interest in native coding at Microsoft, one can use code which has been around for a very long time. But there is a hitch ?

What will happen when Windows is put on ARM devices ?

I don’t see a problem with Metro applications, since they are not native code but use cross platform methods of programming, which interestly is the product of the most cross platform operating system there is, which is not really an operating actually, which is the Internet (the Web). HTML, HTML5, Javascript, etc are the new cross platform languages and personally I think it works and works well. All the years of coding for the internet has matured these languages. But what I am talking about hear are true, 100%, native applications for an operating system.

To have apps run on Windows, both x86 and ARM, depends upon having compilers which can target multiple CPU families. Microsoft compilers can do this and possibly some others, but there is a catch. What is that ?

Similar problems can result when trying to create a compiler for multiple CPU families, such as x86 and ARM. You see, while CPU’s within a family are similar, CPUs in different platforms can be a different as night and day. Now I have not worked with ARM at all and I am not an expert on this family of CPU’s, but this much I can say. CPU families have a unique core designer which may significantly differ. For example ARM is designed for a smaller instruction set (RISC) while x86 is designed for a more extensive isntruction set (CISC). There is a big difference between these CPU families. It is not the high level languages used for programming that matters, but the underlying generation of machine code by these compilers. What may work well on one CPU family may not work as well on another.

Why is this important ?

I can only speak from my own experience on this, but this is what matters to me. I learned a little about 6502 machine language in my early years programming, enough to write a simple compiler. I liked the RISC (reduces instruction set) of the 6502 CPU family and it was easy to learn. But today computers (and CPU’s) are far more complex with greater requirements. You want a CPU which can handle that complexity, but you also want a compiler which is optimized for that CPU. Most software today is bloated, likely because compiler/language developers don’t seem to care as much about the low level CPU as they did in the past. In the old days, compiler makers became experts on a specific CPU and counted CPU cycles and benchmarked their compilers. It doesn’t seem to be that way as much any more. Now I have been using the PowerBasic compiler (see:  http://www.powerbasic.com  ) for nearly 10 years now and what excites me about their compilers is they still are experts on their target CPU (x86 Intel/AMD) and they still count CPU cycles and they still benchmark the execution speed of their compiler and its generated executables. This provides two advantages. Software created using a compiler which is optimized for a specific CPU, created by experts on that CPU is more likely to run faster and be more efficient. Also the software is more likely to be more reliable (less buggy) at least from the perspective of bugs generated by the machine code generated by the compiler. Don’t think it is easy to write machine code generation for a task for two uniquely different CPU families. It is literally twice the work, which means one should expect the compiler maker to be expert on both CPU’s to the same degree. I personally find it better to be a master of one trade rather than try to be a “jack of all trades, but master of none”. Thats why I stick with one programming language (Basic) and one compiler (PowerBasic) and one CPU family (x86) and one operating system (Windows or x86). I think my choice does provide some advantages which is best indicated by the quality and reliability of the software tools I create.

While I hope Windows 8 on ARM does well , I plan on sticking with the x86 CPU family (for now anyway).

Windows on x86 has a long, long history and it has the largest user base of any CPU/Operating system pair. Look at how hard Linux has tried to overtake Windows and it still has a small user base in comparison. For me, for now, I plan on being a one CPU (family) and one operating system programmer. If I do delve into cross platform it will likely be HTML5, since it too has a long history (HTML) and track record. But as far as native coding , PowerBasic is my compiler choice, x86 is my CPU choice and Windows is my operating system choice.

Note: If you are curious what version of Windows I use, my primary development PC is running Windows XP, but I also use Windows 95 (can you believe that), Windows Vista Home Basic and Windows 7 (32 bit and 64 bit) and I am experimenting with the Windows 8 Preview. How many programmers do you know who even still have a Windows 95 PC ? I do because I strongly believe in the value of backward compatibility and only by testing on all the full range of Windows can one appreciate how amazing this is. Just another note, because of this method of development, my software even runs well on Linux using Wine (nows thats backward compatibility).

I have been following the discussions on the web (online magazines) and it is amazing how negative the views are of Microsoft ever getting any decent Tablet PC’s, running Windows 7, to the market in time to gain any decent market share.

Ok, Windows is a resource hog, I’ll admit to that. Yet Windows has a long and rich history with a huge user base and a huge developer base. Windows should be the major player in the Tablet market. So why isn’t it ?

From my perspective, there are two key issues. First, Windows requires some powerful hardware to run on and currently its hard to get decent CPU’s which can run Windows, and yet have a decent amount of battery life. Ok, maybe a Windows Tablet won’t have as long a battery life as say an android Tablet will, but is that the only criteria for a decent tablet ? Absolutely not! A Tablet PC is not a cell phone, or at least it shouldn’t be viewed as one. If you want a Tablet simply to use as a cell phone, then buy a better phone or buy an Android tablet, but don’t consider it a PC. Its an over grown phone. Even if you want a tablet for web browsing, then again, don’t think of it as a PC, but think of it as a web device.

If you want a real PC (Personal Computer) which is a Tablet, then Windows is a much better operating system. Windows has been and always will be a computer operating system, rather than a personal device operating system. The Tablet PC though, limits what kind of hardware you can put into it, so the next generation of Intel chips (ie. Sandy bridge) is what we are waiting for. This will improve the battery life and speed, so the Tablet can keep up with Windows. So the hardware is coming and when it gets here, Windows should be able to shine on Tablet PC’s.

The real problem is the software. Software needs to be designed specifically for Tablet PC’s, so they can run well within the limits of a Tablets hardware. So whats the problem ?

The problem is the mindset of Windows software developers and sadly even Microsoft. You see, Windows programmers have been spoiled by the fast pace at which hardware developers have improved PC’s. Harddrives got faster and bigger, so programmers didn’t care about saving disk space anymore. RAM got cheap and PC’s got more and more memory, so programmers didn’t care any more about using memory efficiently. Graphic cards got more powerful, so programmers didn’t care about efficient use of graphics thinking, I’ll let the GPU do all the work (aka. DirectX). The point is that programmers have been spoiled and hardware advances have been lost to bloated software.

The problem comes when Tablets come on the scene, because you have space and power limitations with tablets, which smack right in the face those spoiled programmers. Add to this bloated development systems like dot.net and you have a real problem. So whats the answer ?

Programmers need to start learning how to accomplish a lot, with a little, like in the old days. I remember writing full blown accounting software in the days when a PC only had 640 KB of memory. Anybody remember, writing software when PC’s only had floppy drives ? (I do !)

For years, PowerBasic programmers would tout how they could write software which could fit on a floppy disk and could run in very low memory situations. Dot.net programmers would laugh and say, “who cares. There plenty of disk space and memory.” But now, with tablet PC’s, such limitations have returned and it will take years before Tablets will be able to run the big bloated software with little problem. So maybe the old time programmers, who are used to counting CPU cycles and to saving bytes have a valid point after all.

When I look at my latest software, EZGUI 5.0, I still am disatisfied with the “huge” runtime DLL EZGUI has, which is 700 KB. Wait a minute. 700 KB is tiny by todays standards ! Yes, it is, but I am old school and its big to me. I have a runtime DLL, which can runs rings around other development tools and is less than 1 meg in size and the EXEs which use it are amazingly tiny and the reason why is because I “care” about the size of my software and how much memory it needs and how fast it runs. I benchmark my software to get maximum speed out of it as well. Its the caring about such things, which is needed to make Windows 7 a viable operating system for Tablet PC’s.

Steve Balmer of Microsoft one said “Developers, developers, developers” is what they need.

If you want to see Windows 7 on more tablet PC’s, we need “Developers, developers, developers” who care about the size of their applications and how they use resources. We need more PowerBasic programmers.

This much I can say, is that EZGUI users who are writing powerful applications (using EZGUI and PowerBasic) can be (and hopefully will be) at the forefront of the “Developers, developers, developers” who will be writing software for Tablet PC’s.