WIN32, 32 bit Atom SOC’s and Windows ! A powerful combination.
I just have to say that I am getting very excited about some of the things both Intel and Microsoft are working on. Why ?
Old time programmer feeling lost
I have been programming since the 1980’s professionally (anyone remember the Commodore 64, TI-99, CPM ?) and like most programmers change is not easy. How far things have come and development tools have changed drastically. I am a coder. For you new generation programmers, that means rather than spending a lot of time in a drag and drop, intellisense based, IDE I prefer to to code in a simple code editor without a lot of fancy stuff getting in the way. Now I appreciate the importance of RAD (rapid application development), even building my own RAD tools, but it is when I get down to just plain old writing code where I feel most comfortable.
I have been a long time Microsoft BASIC programmer, first with QBasic, then Quick Basic 4.0, Microsoft PDS 7.1 and then later classic Visual Basic 1.0, 2.0 and finally 5.0 Professional. But I am also a low level coder, having worked with 6502 machine language (Commodore 64 days) and some x86 assembler. I wrote my own simple compiler back in the Commodore 64 days just so I could write a family friendly video game which was published in the Compute Gazette magazine.
One of the things that I have maintained over the years as a long time programmer, was an appreciation of building high performance applications which work with minimal hardware. I remember once building a complete point of sale system for a Kaypro II (CPM) computer using interpreted BASIC on machine with only 2 floppy disk drives and 64 KB ram (that is Kilobytes, not megabytes) and a 2.5 mhz CPU. Now imagine that (and programmers today complain about the Intel Atom SOC’s with over 400 times more power). So working with minimal hardware is nothing new to me.
It is easy for a programmer like me to feel lost today with all the different development tools being used today. C++, JAVA, C# and more. But amazingly some of my old time tricks may now come back into fashion because of computer devices getting smaller and smaller and the interest in the so called “Internet of Things”.
What is an old time programmer to do when classic Visual Basic meets the end of its life cycle ?
I had two choices when classic Visual Basic came to an end. Either jump on the dot.net (managed languages) bandwagon or learn something many prefer not to do anymore, the low level WIN32 API. I chose the latter, the WIN32 API. Fortunately for this old time BASIC programmer, I found a programming language well suited to the task called Powerbasic. In short, PowerBasic is what I felt C should have been. The ease of BASIC, but with the power of C and of course the WIN32 API. The history of Powerbasic is important here because of where it came from. Powerbasic dates back to the old DOS days, but under a different name. Back then it was called TurboBasic, sold by Borland International, well known for their powerful programming languages. Borland eventually sold back the rights to TurboBasic to its original developer Bob Zale, who renamed it Powerbasic. Powerbasic now works with Windows and to get the most out of it requires a good knowledge of the Windows API (WIN32). The point of all of this is the history of the programming language and how it dates back to when compilers produced very small and fast executables capable of running on computer hardware which most programmers today could not even imagine developing software for. It is this kind of mindset which allows todays WIN32 programmers (which are likely a small number) to be able to write software which runs on very minimal computer hardware with ease.
15 years learning the WIN32 API
For the last 15 years I have been learning the deeper things of the WIN32 API. I still use BASIC, but for those of you not familiar with PowerBasic, just think of it like an old time C (not C++) compiler, but BASIC instead. Yes, I work with things like code and data pointers, threads and of course the low level WIN32 API. Since there were no books written about learning the WIN32 API for PowerBasic programmers, I had to read books written for C (not C++). Because so much has changed over the years with software development, the only usable books for me dated back before even MFC (Microsoft Foundation Classes). Fortunately with places like Amazon.com one can find such rare books. So research I did and amazingly even books written for good old C (not C++) were easy to port to PowerBasic code. So what were the best books I found for learning the WIN32 API ?
WIN32 Books ?
While most will likely suggest the Charles Petzold books, I found others which I felt were more clear and easy to understand. For those of you interested in learning the WIN32 API the following are good reads:
Windows 95 – A Developers Guide
by Jeffrey Ricter and Jonathan Locke
copyright 1995
published by M&T Books
Windows 98 Programming from the ground up
by Herbert Schildt
copyright 1998
published by Osborne McGraw Hill
Threading is an important subject and I strongly recommend an entire book dedicated to the subject:
Multithreading Applications in WIN32
(the complete guide to threads)
by Jim Beveridge and Robert Wiener
copyright 1998
published by Addison-Wesley Developers Press
It was very difficult to find a good book which explained writing custom controls (true WIN32 controls) and I finally found this one:
Windows Custom Controls
By William Smith and Robert Ward
Published by R&D Technical Books
Copyright 1993
That one may be difficult to find but is worth getting if you can. Amazingly, even though it was written for 16 bit Windows the core concepts have not changed in 32 bit Windows.
I also learned basic OpenGL technigues and found this book invaluable:
by Richard Wright
Copyright 1999
While I used the 2nd edition, there are a number of later editions worth reading. Early editions though may be a good start since they have less material to deal with.
Old skills have new uses
So what does this all have to do with today ? There is a big interest in the “Internet of Things” (translated means very small devices which connect to the internet in all sorts of everyday uses). There is also interest in tiny computers which could be the basis for developing such devices. While I, like other tech users, have an interest in Arduino, Intel Galileo and the Raspberry PI the latest addition is what really interested me. It is called the Sharks Cove and it sounds very exciting indeed. It also appears my aging programming skills now may have a new life in such a device.
The Sharks Cove
Microsoft, Intel and CircuitCo are working closely together to bring to life this amazing new device. While the price is a bit steep (intially $299), it does open up possibilities for developers who are interested in the coming generation of devices. What I find most interesting is that this device, unlike Galileo, appears to be a full blow mini PC capable of running real 32 bit Windows with GUI capabilities (it has HDMI output). You can read about the Sharks Cove here and here. So what is the Sharks Cove ?
It appears to be a real computer, capable of running 32 bit Windows 8.1. It uses the Intel Atom system on a chip (SOC), has a 16 gig EMMC drive (just enough to hold windows) and 1 gig memory. Now most programmers today don’t feel comfortable with anything less than an ICore CPU and 4 or 8 gig memory on a PC, so those of you interested in writing software for a device like this might want to consider learning either plain C or PowerBasic along with the WIN32 API. The WIN32 API is very low level and is more procedural in nature (using a flat API) so I would recommend skipping the object oriented style of coding to get the maximum power (performance and minimal resourses) out of your software if you want to write software for the Sharks Cove. Why is such low level programming important ? Watch Herb Sutters talk “Why C++ ?” to better appreciate why native coding is so important today. Whether you use C, C++ or PowerBasic (or any other language well suited to WIN32 programming), native coding can produce amazingly small and fast executables, well suited to devices like the Sharks Cove.
The power of the Windows WIN32 API
Normally in my blog when I write an article which will also be posted here on Code Project, I try to avoid mentioning the software I develop or at least keep it to a minimum. But for this article I will, because it demonstrates the raw power of the WIN32 API and what is possible if programmers started working with the WIN32 API again. I will try to keep what I say to useful generalities, but forgive me if I find it difficult.
There are two key issues when developing software for a device like the Sharks Cove. The first is the size of the executables themselves, since disk space will be at a premium. The second is the ability to run with minimal CPU power and minimal memory. Remember that Windows itself will already be using a significant portion of the available resources, so what is left for your applications won’t be anything like you may be use to. Managed programming languages do have a reputation of requiring a good bit of resources, so coding using the WIN32 API does have its benefits.
For the last 15 years my company has been developing its own GUI framework based on the WIN32 API. Currently it only supports the PowerBasic compiler, so most of you likely couldn’t use it anyway (if you program in C++). But it does demonstrate how WIN32 programming can be used to build much smaller, faster, lean GUI frameworks for devices like the Sharks Cove.
Classic Visual Basic programmers will appreciate the value of a GUI framework or runtime, since Visual Basic applications required a core runtime (DLL). That DLL though only was 1.4 megabytes in size so it was not much overhead. Visual basic applications themselves are actually quite small because they use a runtime, so they are well suited to running on computers with minimal memory and disk space. One downside to classic Visual Basic was that much of the more advanced functionality was left to secondary runtimes (or OCX controls), so when using the common controls, common dialogs, etc an application quickly grew in size up to 3 or 4 megabytes and if you used third party OCX controls some times the app could grow significantly larger. When Visual Basic was originally created it was kind of a fluke, really. Microsoft didn’t create it, but it was created by Alan Cooper (original developer of Visual Basic) and was not initially intended to be a full blown programming language. This explains why it started out as a Pcode language and only after years of development did it finally get a real compiler backend (which I have read was actually a C compiler). It was not designed from the ground up to be a GUI framework, like the dot.net framework was. It also concentrated more on component resuse and the drag and drop experience, rather than on being a lean, fast GUI framework. The concept was good, but flawed in that it did not concentrate on performance and tapping into the raw power of Windows and the WIN32 API. Ease of use was the priority and even in later years, experienced Visual Basic programmers had to resort to calling the WIN32 API directly to tap into that raw power of the Windows API. So books about the WIN32 API and how to use it with Visual Basic became a staple for many an experienced Visual Basic programmer. But what if developers back then had built GUI frameworks which tappped into the raw power of the WIN32 without all the weaknesses of early versions of Visual Basic ? There were attempts like MFC and OWL but they were simply object oriented wrappers on top of the WIN32 API, which did solve some problems, but were not the lean framework which programmers would have desired.
Building my own GUI framework using the raw WIN32 API
My company for the last 15 years has been developing a GUI framework which does demonstrate how possible it is to build small, fast, lean GUI frameworks based on the WIN32 API. Now while I developed my framework for the Powerbasic compiler, it is very reasonable to conclude that other programmers could do something similar for C and C++. Especially would this be useful for developing software for future devices based on the Shark Cove device running real 32 bit Windows (x86). But how small, how lean, could such GUI frameworks be ?
Now some of the features I mention here, may not sound very exciting to many programmers who are using the latest dot.net languages, so please don’t start with the “I can do that easily with Visual Studio”. The point is that imagine writing software for a device where even the dot.net runtimes might be considered bloated for the device and you definitelly won’t be installing Visual Studio on any such devices. Imagine for a moment, you don’t have dot.net. Imagine only being able to code using C++ and the WIN32 API because of restraints in software size and system requirements. Now consider the features I mention below and see how developers can create new GUI frameworks specifically for these new devices.
Let’s use the classic Visual Basic runtimes as a basis of comparison.
Consider Visual Basic 5.0 Professional’s runtimes:
msvbvm50.dll – 1324 KB
comdlg32.ocx – 150 KB
comctl32.ocx – 595 KB
comct232.ocx – 161 KB
mscomct2.ocx – 633 KB
richtx32.ocx – 208 KB
Totol – 3071 KB
Because many of the more needed features of Visual Basic, such as the common controls, richedit control and common dialogs required additional OCX libraries, the above runtime list well enumerates what the typical Visual Basic application required. So for all practical purpose the Visual Basic runtimes (or GUI framework) were about 3 megabytes in size. That is still not bad though. But remember, that Visual Basic was not designed for leaness, but for ease of use and component use. But the above runtimes didn’t include any animation engines, customizing features like owndraw, OpenGL graphics, threading, subclassing or superclassing. Actually they were pretty lean in features really.
But what if Visual Basic had been designed from the beginning for leaner size, better performance and tapping into some of the raw power of the WIN32 API ?
Now consider, simply for comparison sakes a more recent GUI framework which my company developed which was designed to tap into the raw power of the Windows API while maintaining ease of use. Let’s simply list a feature set of the framework and you tell me how large a runtime would be required.
- Forms (including MDI)
- All standard controls
- Most common controls (Animation, Calendar,DateTime,Listview,Pager,Progressbar,Rebar,StatusBar,ToolTips,Tab control, Toolbar,Trackbar,UpDown)
- RichEdit (supports versions 1.0 to 4.0)
- Print engine (print to printers)
- Common Dialogs (open/save, colors, fonts,print, page setup, find/replace)
- Tray Icons
- Form Menus and Popup menus
- Clipboard (text,RTF text,bitmaps)
- Registry
- Control Search Functions
- Timers
- Display HLP and HTML Help files
- MessageBoxes
So far a decent number of features, so if we can stay below Visual Basics 3 meg runtime size we are doing good, right ?
Well let’s add some more advanced features such as:
- Shape/Hotspot/SplitterBar custom control
- Turtle Graphics (vector based images) custom control
- Files Listbox custom control
- Properties Listbox custom control (yes a real property list control)
- MCI custom control with simple scripting language
Not bad, but let’s add some more features to our GUI framework (definitely going to be a bigger runtime than Visual basic, right ?)
- Thread engine for non-GUI worker threads
- Subclassing engine for low level access to controls window procedures
- Superclassing engine to make building new controls from existing classes easier
- Support for multi-monitors
We need Graphics, so what about that ?
- Canvas custom control with low level drawing engine and low level DIB (device indepent bitmap) engine for accessing pixels directly
- 2D Sprite engine for Canvas with frame animation, alphablending, antialiasing
- 22 Image filters for drawing bitmaps
- OpenGL based glCanvas custom control with 3D scripting language
- STL 3D model support for drawing high polygon count models
If we have graphics, how about customizing controls ?
- OwnerDraw engine with graphic commands for customizing Menus, Tab control, Listbox, Combobox,Button, Label and Listview controls
- Customdraw for customing fonts and colors per item/cell for Listview and treeview controls
- support for drawing some Theme aspects for ownerdraw
- direct access to window DC’s for drawing or reading
Some more features thrown in like:
- copy contents of forms and controls to a bitmap
- complex window region generation for forms and some controls (non-rectangular windows)
And lastly, since RAD is so important wouldn’t a GUI framework need some way to make building a visual designer (like Visual Basic) easy ?
- Visual Designer drag and drop engine with drag handle custom control
- Snap To Grid
- Rubberbanding engine (for drawing controls)
- subclassing engine to make controls capable of drag and drop visual design
Ok, how big a runtime do you think we will need ? If classic Visual Basic was about 3 megabytes, then likely all of the above would require at least twice as much, right ?
Wrong. The entire runtime for the GUI framework is only about 1 megabyte in size and I haven’t even mentioned all the features in it (it has a command set which is close to 1000 commands).
So how does one do it, if they want to build their own GUI framework ?
First, this demonstrates the power of writing directly to the WIN32 API. You will need a programming language well suited to working with the Windows API as a flat API, such as C, C++, Powerbasic, PureBasic or others. Next, it is best to write the code in a more procedural style avoiding all the extra overhead of object oriented coding styles. Even something like GDIplus (which I don’t currently use yet) can be accessed using the flat API versions rather than the C++ classes most programmers use. Here is an example of a programmer who uses the GDIplus API’s via the flat API’s rather than C++ classes, along with OpenGL and other advanced graphic API’s using only flat API’s to develop powerful skinning and graphic engines. His GDImage library, originally written in PowerBasic but now ported to C, is an example of a very lean graphic engine built using only the flat API’s in Windows without all the extra OOP overhead. It demonstrates how powerful low level WIN32 (and OpenGL) programming can be, while maintaining a very, very lean framework.
Some of you are likely old time C programmers (rather than C++), so using the WIN32 API directly along with C makes you a very valuable asset to companies interested in building software for devices based on the Shark Cove initiative. By honing down your WIN32 skills you have a resource not easily found today in the programming world. WIN32 programming used to be considered old fashioned, but maybe not anymore.
While what my company has done is only for use with Powerbasic development tools, I would venture to say maybe this article will spur on some of you C programmers to start building new GUI frameworks specifically for C which are just as lean. Old time procedural style coding has some advantages, such as producing very small executables with minimal resources required. WIN32 programming can produce the next generation of small, fast software which could turn the “Internet of Things” into a practical reality.
Wondering if old fashioned WIN32 programming is viable for the Windows 8.1 desktop ?
The WIN32 amazingly has stayed very intact and well written WIN32 code works very well on Windows 8.1 Why not download my sample, “backward compatiblity”, application which I wrote just for testing many of the features in my GUI framework on Windows 8 to make sure they work as expected.
Download: WIN32 backward compatibility test app
So, I hope this little article will spur on more development of GUI frameworks, especially for the coming “Internet of Things” devices. So start programming now and see what you can create. Keep it small. Keep it lean. Keep is fast. Use only minimal hardware. Why not check out the Sharks Cove device and see what you can do with it, using the WIN32 API. Please post your experiences with this device here, since we all would like to see what others can do with it.