As a long time WIN32 programmer, I find it strange that Intel’s SOC (a.k.a. ATOM System On a Chip) chips are not succeeding as well as I had hoped. The ATOM series has continued to improve by leaps and bounds, but there is a bottleneck somewhere which has prevented them from being used more extensively in IOT and Mobile devices.
Is it the chips or the operating system?
Amazingly, in my opinion, it is neither. I feel that it is how we write applications for the operating system which is the problem. First, let me start with an experts opinion. Watch Herb Sutters talk “Why C++?”
The key point is the need to get back to native code for performance. System on a Chip (SOC) based devices need to have the highest performing software possible to get the fullest benefits and Windows is quite up to the task and so are Intel’s SOCs.
I will suggest going a few steps further though than Mr. Sutter. Step 1, if you want the fastest running software possible for Windows, drop object oriented programming and go back to a more C (rather than C++) style of coding for Windows. C is more procedural in nature and procedural style coding produces smaller and faster applications. I don’t code in C myself, but when I try to describe my coding style to others (I code using PowerBasic, the great grandchild of the famous Borland Turbo Basic) I usually say that it is more akin to C than anything else. I learned WIN32 programming from C based WIN32 programming books of the 1990s, which were easy to translate to PowerBasic. I had to go back a bit to find the right books, because too many Windows programming books were about using MFC (Microsoft Foundation Classes). I found the earlier non-MFC books were the best to learn from. While most will likely remember the Charles Petzold books of the time, the book I found most helpful and easiest to understand was:
Windows 98 Programming from the Ground Up! By Herbert Schildt (1998)
For OpenGL, I learned from the:
OpenGL SuperBible (2nd edition) By Richard S Wright (and other co authors)
Pure WIN32 programming is procedural in nature and based mostly on flat APIs in Windows. Early OpenGL (1.0 and 2.0) is also mostly procedural in nature, which is why I chose it over DirectX (plus OpenGL was better suited for multiple child windows doing 3D).
Procedural style coding produces tiny and fast applications
Native coded, procedural style WIN32 applications, produce the smallest and the fastest applications for Windows. IOT and Mobile (x86 based) obviously would benefit greatly from such small and fast applications. Using this style of coding, Windows applications removes the bottleneck from small x86 based Windows devices.
Not only does this require using languages like C (or PowerBasic, PureBasic, etc.) which are native code compilers which support a procedural style of coding, but also requires avoiding the use of class based frameworks which only add extra overhead to ones application. Three things I look for to see if an application will perform well are, first, the application size (the smaller the less resources it likely will require) , second how fast it runs and third the number of operating system dependencies it has. One excellent way to check the last step is to use the Dependency Walker utility. It allows you to check any EXE or DLL and see what dependencies it has in the operating system or third party libraries.
You can download Dependency Walker here: Dependency Walker Utility
This utility is recommended on Microsoft's website.
The “proof is in the pudding” as they say, so let's look at an example. First is a simple 2D Sprite demonstration application I wrote using only the WIN32 API (and my own code of course to do sprite animation). The app EXE is only 84 kilobytes in size. It only calls the WIN32 API and does not use MFC or any other framework. The only dependencies it has in the operating system are:
- COMCTL32.DLL
- GDI32.DLL
- KERNEL32.DLL
- OLE32.DLL
- OLEAUT32.DLL
- USER32.DLL
No .NET ! No MFC ! Just pure WIN32.
Why no MFC? A programmer using the WIN32 can write his own GUI framework in the same size it takes for the MFC runtimes. The following WIN32 app has an EXE which is half the size of the Windows Wordpad app that comes with Windows (on my PC) and does not use MFC. This WIN32 app uses a GUI library I wrote using pure WIN32 code, which is half the size of the two MFC runtimes WordPad depends upon (on Windows Vista) and it contains a number of proprietary engines in for things like Visual Designer drag and drop, 2D Sprite animation and OpenGL 3D. My WIN32 demo app also has less operating system dependencies that even WordPad does.
Don’t we need the latest and greatest frameworks ?
Actually, not really. There is a big difference between user interfaces on a desktop and on a small mobile or IOT device. The core WIN32 API is extremely rich when it comes ways to customize a user interface. From low level DIB (Device Independent Bitmap) graphics to many ways to customize existing user controls (ownerdraw
, customdraw
, superclass
, subclassing
, etc.), Windows provides a rich API which in the right hands can accomplish some amazing things.
Two key APIs available on most versions of (x86) Windows (since Windows 98) which provide a rich and powerful basis for developing high performance graphic oriented applications are Device Independent Bitmaps (DIBSections) and OpenGL. They can even be merged together in a hybrid formation. DIBs are one of my favorite tools for low level graphics and OpenGL (1.0 and 2.0) APIs are relatively easy to learn and use. Remember, one isn’t going to be building extremely high performance video games, which require DirectX, for IOT and small Mobile devices like you would for a desktop gaming PC. DIBSections and basic OpenGL, which have been around for years can handle probably any graphic needs one would have for devices in the IOT and Mobile category.
Here are two demo apps which demonstrate this:
WIN32 programming can be the key to unlock the raw power of not only Windows but the Intel SOC chips. IOT and Mobile using Windows and x86 Intel SOCs can still be a very viable platform.