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.

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.

Now I am not talking about Windows store apps here, but real Windows desktop applications. Going native or writing directly to the Windows API (WIN32) using a compiler designed for building small and fast applications can produce software which will run not only on the latest Windows 8 tablets, but also on Windows 7 tablets and Windows XP, Vista , 7 and 8 desktop PC’s.

This is why I personally prefer to use the PowerBasic compiler.  PowerBasic has a number of advantages in my opinion. First, it is Basic. Basic is a programming language which has a more natural syntax to it. Simply put, it is more readable than other languages. Second, applications written using PowerBasic require minimal resources.

A compilers effectiveness means more than simply generating fast machine code for loops and calculations. It has more to do with the overall richness of the language and its ability to solve problems. For example one of PowerBasic’s strengths is its rich string command set and how it uses the Windows OLE engine (API’s) for implimenting variable lengths strings. Manipulating strings is a vital task when writing software. But PowerBasic goes further. It is also very low level. For example, one could build fixed data types within a variable length string using pointers to structures or even define arrays within a string using the DIM AT (dimension at) command to define an array within any existing block of memory, even a string.

PowerBasic handles all the memory management for you (and fast), so you don’t have to worry about allocating and deallocating memory for variables.  One thing I like about PowerBasic is that even though it supports Object Oriented Programming using its own classes command set or even COM objects, you don’t have to use any OOP if you don’t want do. You can write apps using 100% procedurally based code.

I have found that procedurally based code can produce amazingly small and compact executables, which is what is needed for writing software which can push the limits of a Windows tablet computer.

Now, learning the Windows API can be a challenge, so PowerBasic provides a simple GUI command set called DDT (Dynamic Dialog Tools) which makes coding user interfaces much easier. For those who want more, this is why I developed my product EZGUI 5.0 Professional. The idea is to make GUI development faster, easier and more powerful. Yet,  I designed EZGUI so it can easily be extended using the Windows API, so one can go beyond its feature set to tap directly into the Windows operating system.

EZGUI itself though, was written using PowerBasic using purely native code. The native API’s are so rich with features not often tapped into by programmers that a creative developer can do all sorts of things and not feel limited.  True, it took me years to learn many of the secrets of the WIN32 API’s, but it was worth it. One of my favorite sets of API’s are the DIB (device indepent bitmaps) API’s. They have been in Windows, since Windows 95, yet they offer a programmer an amazing ability to work low level with pixels. I wrote EZGUI’s 2D sprite engine using DIB’s. EZGUI 5.0 Pro has 22 image filters, based on the DIB engine. Another great feature in the native API’s is owner draw. Owner Draw allows you to custom draw how a control looks. It opens up all sorts of possiblities. I implimented EZGUI’s 3D colored buttons using owner draw. I created two custom controls (Files Listbox and Property Listbox) using owner draw (and superclassing).

Actually, some of EZGUI’s most powerful capabilities comes from providing direct access to a number of low level features of the native API’s, such as subclassing, superclassing, DIB’s, ownerdraw, customdraw, threading and more.

I am convinced that tapping into the native API’s allows programmers to build small, faster, more powerful applications.