The Software Developer

Do you remember Windows 95 ? Yes, Windows was no longer a 16 bit operating system. Now with a 32 bit operating system, more would be possible with software. How much memory did Windows 95 require ? My first Windows 95 computer was one which I upgraded from DOS/Windows 3.1 which only had 8 megabytes of RAM. So how did an operating system like Windows run so well on so little memory ? The average CPU back then was likely a 386 or 486 class CPU which was in the 25 to 32 mhz range. From todays perspective, such a thing would almost seem impossible. The official system requirements were a 386 CPU, 4 megabytes of RAM and 55 megabytes of diskspace. Most computers today have CPU’s in the 1 to 2 ghz range with 2 to 4 gigabytes of ram. So much power is now in our hands. But is it really ?

So how was Windows 95 possible with so little hardware ?

The operating system was designed around a set of flat API’s (basically function calls). Often refered to as the WIN32 API, the operating system provided a set of low level features which could be used to build applications. The efficiency of that operating system to run on such minimal hardware says a lot. But what many may not appreciate today is that how software which ran on Windows 95 was written is far different than how software is written today. While MFC (Microsoft Foundation Classes) was already being used by some developers at that time, many applications were still written using the pure Windows API’s alone. Doing this created applications with less dependencies. If you examine the Windows programming books available at that time, while some discussed using MFC, there were a number which taught programming using the pure WIN32 API’s alone. Having been exposed to WIN32 programming much later, nearly 15 years after Windows 95, I can appreciate why some programmers chose MFC over the the pure WIN32 API’s, since working with the WIN32 was not an easy task. But the WIN32 API’s though do have one real advantage. Working closer to the core operating system allows one to build applications which are smaller, faster and which requires a minimal footprint (less memory and disk space).

So what happened to Windows development ?

I am sure many programmers have a different perspective on this, but my own experience is quite unique and offers a different perspective on this. My programming started back on the days of CPM, before even DOS. When the IBM compatible PC came along, I started programming in Microsoft QuickBasic, then PDS 7.1 (professional version of QuickBasic). I even wrote some libraries for the compiler using assembler. There were three criteria for my development needs, (1) Fast development (2) Easy to read syntax and (3) Performance. Using a quality BASIC compiler along with a little bit of assembler provided me with all three.

When it came time to move to Windows, like many Basic programmers I quickly latched onto Visual Basic 1.0 (for 16 bit, and later 5.0 for 32 bit). I dabbled with a number of Basic programming languages such as GFA Basic and CA Realizer, but Visual Basic provided the easiest transition for me. But something happened to my programming experience which would change things drastically. I switched to a different Basic language compiler which was more akin to programming in C in Windows, which forced me to start learning how to work with the WIN32 API’s. There were no RAD tools for me to use at the time. Everything had to be coded manually in a code editor without a RAD front end. It was very difficult at first, not so much because the WIN32 API’s were too complex to work with, but because all the documentation about the Windows API were written for C (or C++) programmers. I had to port a lot of C code to Basic, which wasn’t easy because I was not a C programmer. To make things even more difficult, in the C world programmers had quickly adopted MFC, so many of the programming books dealt with MFC, rather than the WIN32 API’s directly. Over the years I would scan online looking for old copies of programming books which dated back to the early to mid 1990′s. For example I just could not find a book which explained how to write custom window classes using the WIN32. The only (and best) one I could find dated back to Windows 3.1, but it was amazing how little had changed since then.

It was interesting to see the direction that Visual Basic followed during these and later years. In the 16 bit days of Windows 3.1, Visual Basic added the VBX custom control format which was a real benefit to Visual Basic programmers back then. It was later replaced by the OCX (COM based) custom control format. While there were many advantages to these component models, the OCX would, in my opinion, introduce a downhill slide in the Windows programming model. I first experienced this when I wrote an application which could be used as a utility for a multimedia development tool. I was a beta tester for a product called MediaForge, a powerful multimedia development tool. The developer of that software was an amazing C programmer with an extensive knowledge of the Windows API. When I sent him my Visual Basic application (an HTML generator utility), the first thing he commented on was whether I could get rid of the OCX’s that had to be distributed with my app. I was forced to use OCX’s for simple things like the common dialogs. It would not be until some years later when I started digging into the WIN32 API’s myself, that I would come to appreciate how bloated some software became because of overuse of the OCX component model. The code needed to impliment a common dialog via the API was minimal compared to the size of the Visual Basic OCX. So what was the problem here ?

Object Oriented Programming changes things.

The real cause for the software bloat was, in my opinion, the overuse of the COM component model and the overuse of object oriented programming model. While they both have their value, their overuse has added a significant amount of extra overhead to Windows programming, far more than most programmers would like to admit. How do I know this ?

(For some more info about the weaknesses of OOP consider these articles:)

• http://www.csjournals.com/IJCSC/PDF1-2/9..pdf
• http://software.intel.com/en-us/blogs/2008/08/22/flaws-of-object-oriented-modeling/
• http://www.4js.com/files/documents/products/genero/WhitePaperHasOOPFailed.pdf

When I started learning how to program using the pure WIN32 API’s, I had a few advantages that the early Windows programmers may not have had. First, I had a chance to see how the WIN32 API remained basically intact over multiple generations of Windows. The few changes made, were easy to work with since Windows from the days of Windows 95 has had a few very important features which have remained steadfast in every generation. One is the trusty DLL (dynamic link library). The DLL design, in my opinion, was simply ingenious. DLL’s are truly dynamic, produce reusable code and they tend to have a much smaller footprint than their OCX counterparts , plus they normally don’t need to be registered with the operating system, meaning the registry need not be involved. You can simply copy and run. The second important feature, associated with DLL’s again, is the ability to dynamically load DLL’s (via the LoadLibrary API), rather than staticly link them at compile time (the DLL is still separate, but the EXE header tells Windows to load the DLL automatically). Dynamic loading allows you to poll the DLL to see if an API exists or not, so you can take adantage of features in later versions of Windows if you like.

The second advantage I had was that I used a BASIC language compiler rather than C. The amazing thing about this was that working with the pure WIN32 API’s was so much easier using Basic, than it would have been using C. The language syntax made code more readable, the powerful memory management built in made coding easier, the compilers built in support for variable lengths strings (using the Windows OLE engine) made things much easier as well. For once, WIN32 code made sense and was readable. I didn’t need to use MFC. I could write applications using the WIN32 API alone.

Interesting results !

Of course to be able to write software faster it only made sense to design RAD tools, but once again the power of the WIN32 API’s proved an advantage. As I went from just a beginner API programmer to an experienced one, I began to solve more and more problems using the pure WIN32 API’s. Of course, every programmer needs some kind of higher level libraries, so I began to build my own. Because I used a Basic language compiler, I had no MFC to fall back on. I had to build my own libraries.

So while building a reusable GUI library was important, I had some basic rules. The library must be in DLL format. API’s which didn’t exist on some earlier versions of Windows, had to be polled for and then loaded dynamically, so the library would be compatible with all versions of Windows from 95 to Windows 8. If possible when an API was not available on an earlier version of Windows alternate code was added to support similar features if possible. At the minimum, the library must support all of its features on at least Windows XP forward.

Since I didn’t even have the benefit of a drag and drop visual designer to help me, I decided that I needed to learn how to build that from scratch using the WIN32 API’s. Any complex task using the WIN32 API’s which took some time to develop, I decided should be put into library code so it can be reused. Code reusability is not dependent upon the object oriented programming model as some may think. Procedural, flat API, programming models can also benefit from high level reusable code libraries. The key to working with the WIN32 API’s is to build such reusable libraries.

So the final results have been interesting. First, I found there are some very powerful low level features in Windows which have been there since Windows 95 and are still fully supported in Windows 8. For example the DIB (device independent bitmap) API’s are very useful and very powerful. The WIN32 API’s offer so many different ways of customizing user interface elements (controls). Such things as subclassing and superclassing are powerful tools. Fortunately I found one of the few books written about how to write custom window classes (controls) using the WIN32 API’s (and the term class does not mean it is object oriented in this case). I have written a number of custom window classes using the WIN32′s, such as my own Canvas control with a low level DIB engine and 2D sprite engine, an OpenGL based 3D Canvas control with a 3D scripting language, a Turtle Graphics control and a Property Listbox control. For me, as a WIN32 programmer, the possibilities seem endless.

But the most amazing thing about all of this was the size and footprint of the GUI libraries I was able to build using the WIN32 API’s. The entire GUI library can fit on an old fashioned floppy disk with room to spare. When I realized that I could write complex GUI libraries and applications which can run on most versions of Windows in use today with a minimal amount of memory (easily 64 meg or less), which are truly transportable (just copy and run, even from a flash drive) and can easily be run on the most minimal of computer hardware (ie. 233 mhz or less CPU), it is very exciting. While most programmers may be stifled by the minimal hardware on some Windows tablets today, for a WIN32 programmer the average Atom based Tablet is far more than adequate, but is a powerhouse.

So if you are looking for an alternative way of writing software which has a minimal footprint, then seriously consider what has been around since the days of Windows 95, the WIN32 API’s.

It is quite obvious that the future of Windows has to do with tablets and touch. But how do we write software which takes full advantage of the variety of devices that Windows runs on? The key to this, is to work with the strengths built into Windows.

One of the strengths of Windows often overlooked is backward compatibility. It is so easy to always be considering the latest computer hardware  , while forgetting about existing computer hardware and the need to find ways to write software which can run on both. Windows has a long history based on backward compatibility which can allow software developers to write software which can run on current as well as legacy hardware . The key to this is the WIN32 API’s which Windows was built upon.

So much has been written about how using touch on tablets is so much different then using the keyboard and mouse on a desktop computer.  Rather than force users to have to choose one or the other , why can’t software be written so it is dynamic and will change depending upon the hardware it is used upon.  While most programmers today depend upon complex software frameworks , few may appreciate the power of the low level Windows API.  This API was designed to be dynamic. As a WIN32 programmer, who builds tools for programmers, one of the problems I was faced with was how to build software which can take advantage of features found in a newer version of Windows, while still supporting previous versions of Windows. The solution was easy and has existed in Windows since Windows 95.  There are API’s which allow software to test to see if an API exists or not and then if it does, call it via a pointer and if it does not, you use an alternate solution. Also, Windows provides a great deal of information about the current specifications of the computer running it, so software can be written to impliment new features when available and to morph itself to that hardware.

Another problem with different versions of Windows is that the user interfaces continue to change. The look and feel may be different, between different versions of Windows. Once again, the Windows API comes to the rescue. Rather than be dependent upon the default look and feel for user interface elements, the Windows API, since Windows 95, has provided a variety of means to customize the look and feel of an application. Such things as ownerdraw, customdraw, subclassing (to change default behavior), superclassing (build new control classes upon existing ones) and even writing custom window classes from scratch, all provide ways to write applications which can look and act very similarly on multiple versions of Windows. The surprising thing is, that these features have been in Windows from the beginning, since Windows 95.

Even when it comes to graphics, one is not totally dependent upon the latest DirectX hardware and the latest version of Windows. Since Windows 95, the low level API’s supported DIBs (device independent bitmaps) which have been a cornerstone upon which later technologies (ie. video) have been built upon. When I needed a solution for graphic animation, I built my own custom Canvas control using the DIB API’s and created my own 2D sprite engine on top of it. The beauty of this, was that my graphic control was not dependent upon a specific version of Windows nor required DirectX (no special hardware or drivers needed).  While a few of the more advanced graphic features I wrote require at least Windows 98 or later, my 2D sprite engine runs on Windows 95 to Windows 8. It is also amazing how little has changed in the low level WIN32 API’s and how backward compatible even Windows 8 is (desktop of course).

The point is, the software can leverage features which have been in Windows for over 15 years. Now when you add dynamic features to such software so it can change depending upon which version of Windows it is run on and the hardware it has, then you truly have a powerful tool for software development. No need to worry about which version of dot.net is on the computer. No need to worry about which version of DirectX is on a computer. No need to worry about the size of the display or whether it is touch based or not (dynamically change the user interface based on what kind of device it is run on).

Imagine software, when run on a desktop computer it knows this and takes full advantage of all the available screen space for UI elements ? But when run on a smaller device, like a Netbook it dynamically changes itself to better use the limited screen space. And even more, when run on a touch device (ie. tablet) it changes the entire user layout to compensate for the need for larger UI elements for touch. Building dynamic software is what is needed now. Rather than complain how software runs well on a tablet, but wastes space and runs poorly on a desktop, why can’t we have both ? Why can’t software be dynamic ?

Another issue with trying to write dynamic software is that different computers may have differences in performance. A lowly Atom CPU on a Windows tablet is not going to be the same as running the software on a desktop computer with the latest CPU. The key here is to write software for the lowest denominator, the ATOM CPU. This requires smaller, faster software. The best way to do this is to write software using a native code compiler which produces small executables and fast software. This is how I approach software development. My goal is to write software which can run on a 10 year old legacy computer with minimal hardware. Software can be written so it fits on an old fashioned floppy disk and also is truly transportable (meaning you can copy and run). Software should be transportable today. It should be able to be simply copied to a jump drive and moved from computer to computer or even run directly from a jump drive on any computer. This requires software with a minimal footprint and no heavy system dependencies.

By using a native code compiler and the WIN32 API’s to build dynamic software, programmers can build better software which can leverage any Windows computer it is run on.

The real question though is, can this really be done ? The answer is definitely yes. But will we as software developers do it ?

Having been writing software since the days of CPM (and before) I can appreciate how far computers have come. If anyone thinks an Atom CPU is slow, try writing software for the Commodore 64 with a CPU which was only 1 mhz in speed. Yet despite all the changes in computers over the years, to me it is still just a matter of working with bits and bytes. Ascii text are just bytes. Numbers are just bytes. Graphics is simply moving a lot of bytes around really fast. I know, that sounds a bit over simplistic, but it leads to a point.

In the old days, operating systems were simply a set of API’s which encapsulated basic functionality one could build upon. They provided access to the hardware (ie. keyboard, mouse, screen). They provided basic user interface elements (anyone remember Geos for the Commodore 64). They were the building blocks of which software was based. Even Windows from the days of 16 bit Windows was simply a set of API’s which you could build upon.

Something changed though over the years. Object oriented programming took over and it wasn’t enough to just use it to build higher level abtractions on top of the operating system, but it began to take the place of simple API’s in the core of operating systems.  I believe that object oriented programming may be at the core of what makes operating systems and software too complex so that each new generation requires more and more powerful hardware just to keep up.

While I appreciate the goals of OOP, such as code reuse, I am not so sure that it really accomplishes what it was intended to solve. What can make software and even an operating system powerful is simplicity, not complexity. Just for a moment consider the inherent complexity of OOP. Just ask someone to explain the meaning of common terms of OOP and you quickly find that was is suppose to be simple is actually an overly complex concept. For example was is abstration ?

Just do a Google search to find the answer and rather than a clear cut answer one finds that there really isn’t a clear definition. Here is one discussion where someone asks this question and just take a look at the variety of answers he gets:

http://programmers.stackexchange.com/questions/16070/what-is-abstraction

Now, define something like subroutine or function. Not too difficult is it. Subroutines and functions are the simplist constructs of reusable code. Early API’s where simply a set of prewritten subroutines or functions of which software could build upon.  Need a font ? Call a simple operating system API like CreateFont and you get an index (or handle) to an available font. What could be simpler ?

Now some may feel the objects are the necessary higher level contructs of which modern software must be built upon, but is this true ? I don’t think so. Why do I say that ? Because as a developer of tools for programmers, my job is to design higher level constructs to make programming easier for other programmers and after spending ten years building a GUI engine (in its fifth generation now) I have come to the conclusion that one can build high level GUI libraries without object oriented programming and guess what happens when you do ? You get smaller, less resource hungry software.

Yes, with so much emphasis today on mobile platforms, we need smaller, less resource hungry software. So how can one provide the higher level functionality that programmers require, without using object oriented programming ?

The three tiered building block approach.

Have you ever played with Lego blocks ? The amazing thing about Legos is that with a good assortment of different blocks one can build an almost unlimited variety of models. The blocks come in different degrees of complexity from just rectangular blocks to wheels, windows, etc. Most blocks are totally reusable too.

Building software, even an operating system, can be done in a similar fashion. The difference with software though is that the less complex building blocks can be used to build the more complex blocks for the ultimate in code reusability. I will refer to this as a “three tiered” design. What is that ?

Basically the three teirs are:

• low level functions (or subroutines)
• medium level functions (or subroutines)
• high level functions (or subroutines)

All operating systems must have some low level functionality to build upon and one can build an API to provide the lowest level of functionality available to all software that runs on it. Some may feel that one must build this functionality upon objects, but it need not be so. True, data types which the core operating system (even higher level apps too) will use to track tasks may need some structure, but simple types or structures which most programming languages provide is sufficient for this. The core set of API’s can be very low level. Low level functions should be of a single task nature, for example, create me a font or a drawing brush.

The next step is to build the medium level API’s, which are built upon the low level API’s. Medium level API’s will combine multiple tasks together to provide more complex user interface features. For example in Windows, if I wanted to prepare a drawing surface (a memory DC with a bitmap selected into it) it requires multiple steps (create a DC, create a bitmap, select a bitmap into the DC). Yet, the Windows API doesn’t provide this functionality in a simple API. It should have though (and that is the kind of thing I write into my GUI libraries).  It is this medium design which may be lacking in operating systems. By building even more complex user interface features into this medium level, it provides programmers with even more choices and makes software development faster.

Lastly, with an extensive medium level set of API’s (which build upon the low level), now we can start building the higher level API’s. High level API’s should provide functionality which would have taken hundreds of lines of low level or dozens of lines of medium level code. The more extensive the low level and medium level API’s are, the more high level API’s can be created.

By using a procedural based approach using such a three tiered system, I strongly believe that operating systems could be designed to be simpler, faster and smaller, which is exactly what we need today for our mobile platforms.

Does this approach work ?

Yes it does. While I don’t develop operating systems, I do develop GUI engines that sit on top of the operating system. To me, the WIN32 API’s are the low level functions I build upon and my job is to build the medium level and high level constructs on top. By using this three tiered approach with purely procedural style coding (API’s upon API’s) and avoiding the use of objects I find I can software with an amazingly small footprint which requires minimal hardware resources. I design software with the mindset of “write it so it can fit on a floppy disk”. Ok, we don’t use floppies anymore, but you can get the picture. Small is beautiful and efficient !

There are a number of open source operating systems in development and likely more coming. But has anyone ever considered this more simplistic approach ? If they did, I would not be surprised to someday see small tablets which are super thin and with multiple days of battery life, but are full blown computers rather than simply an ebook. The three tiered approach lends itself to the “smaller, faster” goal which Bob Zale (creator of TurboBasic and PowerBasic) always encouraged.  Maybe those old timers knew something which todays programmers haven’t learned yet. While I am not saying that OOP should never be used, the above three tier approach could lead to faster, smaller operating systems and software.