WIN32 , the Assembler language of Windows, key to building GUI frameworks!
I saw an interesting reference on the web calling the WIN32 API, the Assembler language of Windows. While not quite true technically (since a true assembler is even lower level than something like the Windows API), it is a valid description of the WIN32 compared to other GUI frameworks, such as dot.net.
The benefit of assembler
Back in the day when home computing first got started (the 1980’s), budding programmers quickly learned that higher level languages were just too slow and the only way to get any decent performance was to learn assembler language. I remember learning 6502 machine language for the Commodore 64 and even wrote my own compiler just to get the performance I desired. But computers have come a long way since then, with CPU’s many thousands times faster than what we had back then. Yet, computers have to do so much more today. The difference of drawing a HD display (1920 x 1080) with full color, versus drawing an extremely low resolution screen (320 x 200) in 4 bit color, for example, means todays computers have a lot more work to do than such computers of old. While most programmers likely aren’t going to write software in assembler today, the WIN32 API in Windows is a very powerful and reasonable solution for getting higher performance. Especially in the areas of embedded Windows and IOT (Internet of Things) running on x86 devices. the WIN32 API is a very viable solution.
Time for better GUI frameworks
But coding in the WIN32 is very time consuming and challenging, to say the least. So rather than code using the WIN32, it makes sense to build new and better GUI frameworks based on the WIN32, while allowing easy integration of WIN32 calls within the framework, when absolute performace is required. But wasn’t MFC (Microsoft Foundation Classes) for that ?
I am going out on a limb here with the following observation, but I feel it needs to be said. Most will take issue with it, but try to have an open mind here. The problem with early GUI frameworks built on top of the WIN32, was the decision to go all out with OOP (Object Oriented Programming). Why would I say that ? The WIN32 is not OOP based. It is mostly a flat API (not counting later COM usage, but much can be done without a single COM call, using the WIN32 API). COM can still be used when required, while still mostly coding in a procedural style when using the WIN32 API. Yes, the WIN32 API is a flat API model, not OOP. Flat API’s tend to produce smaller and faster executables. A well designed flat API can still be easy to use (OOP is not required for ease of use) and you benefit from its better performance.
Now some may stop right there and say “but that is easy to say in theory, but it is a different story in reality”. I agree, so if I were only speaking in theory, then you would have a point, but I am not speaking in theory.
Lessons from 15 years of GUI development using the WIN32 API
I was forced by my situation to not only be required to learn how to code using the WIN32 API, but also to build my own GUI framework from the ground up based on the WIN32. I have been a long time BASIC programmer, from the old days using GWBasic, QBasic, Microsoft QuickBasic, Microsoft Professional Basic, Visual Basic (classic) and others. In my transition to 32 bit Windows, I found Visual Basic to be lacking in a number of areas and even though later versions of Visual Basic eventually provided a real compiler backend, there were just too many things I needed to do which Visual Basic could not do well. For example, Visual Basic 5.0/6.0 were hobbled by the need to use additional OCX controls for many things which were built into the operating system (ie. common dialogs, common controls). I once designed an app, which was to be included with another programmers software multimedia studio (he was a native C programmer) and that programmer wanted a lean software package and he complained about my needing a bunch of extra OCX controls with my utility app, just to do simple things which could be done using the WIN32 API. Such experiences as this moved me away from Visual Basic and I finally came across PowerBasic. PowerBasic is the great grand child of the famous TurboBasic from Borland International (Borland sold back the rights to Turbo Basic to its original developer Bob Zale). Now the problem with PowerBasic, was that while it was years ahead of Visual Basic in the raw power area (it was a BASIC compiler with the raw power of C), it was also years behind in the GUI area. Back then PowerBasic had no GUI framework and the only way to write an application with it was to use the WIN32 API directly. It was, though, well suited to working with the WIN32 API.
I had two challenges in the process. First I needed to build my own GUI framework to make programming faster. While I could handle the WIN32 API, I surely wasn’t going to code full blown apps with it. I was also a firm believer in RAD (Rapid Application Development) tools. I needed to build my own GUI framework based on the WIN32 API. By building a flat GUI API, it would still be lean and fast, unlike many OOP based frameworks today.
Second, I needed a number of higher level features not found directly in the WIN32 API and a number of them not found in Visual Basic. One of the most critical was a drag and drop engine for building a visual designer. It turned out, visual design drag and drop is not available in the WIN32 API and is a very difficult thing to do. A number of programmers in the PowerBasic community of programmers attempted to figure this out and only a select few were even able figure it out. I had to not only build my own GUI framework, I needed to build my own Form designer. Yet over time, again and again, I found the Windows API lacking in what I needed for higher level features. But remember the reference I started with, that the WIN32 API is the Assembler language of Windows. The raw power was there to accomplish most anything I wanted, I just had to figure out how to do it and I did.
Leaner than even Visual Basic
Building your own GUI framework using the WIN32 API can produce not only something leaner than MFC, but even leaner than classic Visual Basic’s runtimes. Now remember that classic Visual Basic, had not only its famous 1.4 megabyte runtime DLL, but to do anything really worthwhile you had to include a number of OCX controls (which had to be registered with windows) which often brought the runtime to twice the size, on average about 3.5 megabytes. Sure that seems small in comparison to dot.net today, but it is actually still quite large for something written using a flat API model using the WIN32 API.
While what I do is commercial proprietary software, I can at least provide a nice simple demo of what I mean in a demo app I wrote using my framework, which I used to test compability of the WIN32 calls I used on Windows 8 (and now Windows 10). You can download the demo app here:
The purpose of this demonstration is to show how tiny and lean a WIN32 Flat API model GUI framework can be and hopefully it will encourage others to start build frameworks like this.
The app may not seem like much, but it does many things not immediately available in Visual Basic and with a much smaller footprint. The entire framework footprint is only about 1 megabyte in size, which is about 1/3rd the size of a typical Visual Basic runtime footprint and it does things you can’t easily do with a typical Visual Basic runtime, such as: OwnerDraw, CustomDraw, OpenGL 3D (aside from WIN32 features), 2D Sprite engine and a visual designer drag and drop engine. This is only a small portion of what is in the framework. Actually the entire framework is amost a programming language in itself, with a command set of about 1000 GUI commands, including also a 3D OpenGL scripting language, autosize engine (automatically resize controls when form is resized), multi-monitor support, a number of built in custom controls, theme drawing support and more.
The lesson: Try using the WIN32 to build a new generation of Flat API GUI frameworks, rather than OOP based.