Smaller, Faster, with Windows programming
With mobile computing taking hold, programmers are looking for ways to produce smaller and faster applications. Soon with the so called “Internet of Things” concept bringing possibly even smaller mobile devices into all areas of life, the need for smaller and faster software capable of running on tiny mobile devices may bring even greater challenges. Developers of Windows software may wonder, is it possible to write such software for the Windows platform ? Are there any secrets to how this can be done ?
You are likely not going to like it !
Programmers often like to tell other programmers that they should be willing to learn new technologies if they want to be able to build better software. If that would work, fine, but sadly it hasn’t produced the kind of software we are really looking for. Why not ? Because much of our coding styles have revolved around building desktop software using faster and faster hardware. Each year, better CPU’s, more memory and faster GPU’s have allowed programmers to tolerate development methods which, while producing some very good software, also has pushed up hardware requirements for such software. What we really need today are some well trained programmers who know how to squeeze every cycle out of a CPU, know how develop software which can run on minimal hardware (less powerful CPU and less memory) and know how to write software so that it uses less disk space (SSD’s are small on moble devices). But where can you find such programmers ?
Well, let me first say, you won’t like it when I tell you. The truth though is that such programmers do exist, but they are not what you would have expected. They also are becoming more and more rare. So where are they ?
I told you, you would not like it !
Actually, such programmers have been around for a long time, but the mainstream development community tends to shun them for a variety of reasons, but mostly because they are considered old fashioned and out of touch. But are they really out of touch or do they know something that others may find hard to accept ? So before I discuss these unique programmers, consider this illustration. Which would you prefer to work on your motorcycle, an experienced car mechanic or an experienced motorcyle mechanic ? The answer is obvious. Why ? Because while a car and a motorcycle have many things in common, motorcycles are designed differently and you would want someone who understands the complexities of working on a much smaller driving machine. Now in the world of mobile devices, rather than “cars” (the desktop PC), many prefer the smaller “motorcycle” (the tablet and smaller devices) and this introduces new challenges.
When programming was really difficult
Youthful programmers may not appreciate this, but for any who have been around awhile you may appreciate what it was like back on the 1970’s and 1980’s in the programming world. The challenges seemed insurmountable. I can remember learning how to program a Commodore 64 home computer, with only 64 kilobytes of memory. To be able to do anything significant with the computer, one had to learn to how to make every CPU cycle count, learn how to manipulate the hardware to do things beyond what the hardware was designed for and learn how to work with minimal resources such as memory and disk space. In my own case, I also learned this when I decided write a family friendly video game for the Commodore 64. Interpreted Basic was definitely not going to work. I had already started using a real compiler on the Commodore, a Basic language compiler by Abacus, but even that was not fast enough, so I found myself using the Abacus compiler to write my own compiler, which I ultimately used to write the game. In essence I was doing what ever I could to squeeze out every bit of power out of every CPU cycle. I sold that game and it was published in the October 1987 issue of the Compute Gazette magazine. It earned me nearly $1500 for just a couple weeks work.
The Commodore computer had ony a 1 megahertz CPU and 64 kilobytes of memory. How many programmers today could work with such limitations ? But the things done in those early years on such minimal hardware were amazing. For example a group of programmers created an operating system for the Commodore 64 called Geos, which was quite amazing for the limitations of the hardware. With the new, so called, “Internet of Things” on the horizon, surely we could benefit from programmers like this who know how to create amazing software which will run on minimal hardware. Actually, this is the point of this article.
Learning how to code software in the old days produced a mindset which some of these programmers, still around today, find hard to give up and maybe they shouldn’t. Is it really so bad a thing that a programmer wants to build fast running software which requires minimal hardware ? Actually, it is a very important consideration today ! Watch Herb Sutters talk, entitled “Why C++ ?” and I think you will appreciate what I mean. He discusses how important it is to develop faster , high performance, software and how getting away from managed languages and using C++ for development can accomplish this. But I would like to go much farther than Herb Sutter, in this article.
I warned you, you really are not going to like this !
If I had little experience in programming then maybe what I am about to say would have little value. But that is not the case. I started doing custom programming for local businesses back in the early 1990’s. My first work was on CPM computers and then when the IBM compatible (and DOS) became popular, I started writing software for that. I wrote software which did real work in real businesses, from local Mom and Pop operations to large manufacturers. I wrote software for accounting, point of sale, engineering, quality control, job tracking and estimating. Some of the DOS software I wrote is still in use today. For the last decade and a half I have been developing tools and libraries for programmers which have become the backend of some important commercial software. The likes of Chevron, Disney and even some popular TV shows have been using software which was written using my tools and my libraries. One example should suffice here to demonstrate this. Fathom Systems, in the UK, develop control devices used in the commercial diving, ROV and underwater engineering industries. They designer software for their equipment too and that software was written using Powerbasic and my own GUI tools. They sent me the link to the following video of a large project by Chevron, which uses their equipment and to run their equipment, software written using my own GUI engine. Watch the video and at about 4 minutes and 33 seconds into the video, pause it and notice the laptop which is controlling some of the equipment. The software doing this, was developed using my companies GUI tools. So, I do have some experience in writing real software and tools which have been used to write software which is being used by some very large companies.
Chevron Deepwater Pipeline project (video)
Now with that behind me, I continue. So what I am about to discuss next is not only possible, but actually practical for developing software for todays smaller mobile devices, particularly the Windows Desktop on x86 base systems. What can one learn from old time programming experience ?
Native coding
The first thing is that nothing compares to native coding for an operating system, especially Windows. Of one wants optimal performance, native coding definitely can produce very small applications which require minimal hardware. For Windows, this does not mean developing using DOT NET or even the WINRT, but means developing for the low level WIN32 API. My first Windows 95 computer (I upgraded from 16 bit Windows on that computer) only had 8 megabytes of memory, if I remember correctly. How could Windows back then run on so little memory ? Because of the design of the operating system itself. Windows was based on a flat API (not object oriented) and amazingly that core API still exists in Windows and is a core part of what makes it run today. While a bit terse at first to learn how to code for it, once a programmer masters it, it provides a huge feature set for producing some very powerful software. This style of coding has grown out fashion, possibly because it was difficult to master. Microsoft later came out with tools to make it easier, like MFC (Microsoft Foundation Classes), ATL, etc. Later managed languages literally took over Windows development.
So what does an old timer programmer like myself think of the two styles of programming, managed languages compared to native coding using the WIN32 API ? I was actually put into a situation where I gained a unique perspective on this, few programmers may have. When I moved to Windows programming I was using Visual Basic (classic). I had versions 1.0, 2.0 and later 5.0 professional. Visual Basic was a masterpiece when it comes to fast software development. Visual Basic, despite its amazing speed for designing the front end of software, also lacked in areas where I needed a bit more, so I left Visual Basic behind and then tried my hand at coding using Powerbasic (the closest thing as far as language syntax). Back then when I first started programming using PowerBasic, many programmers using it, used it as an addon to Visual basic for writing high performance DLLs. The language was capable of being used to write EXE’s too, but Powerbasic has no GUI command set at the time and so it was best suited for writing backend code (non-GUI) which is why it was marketed as an addon for Visual Basic. Develop your front end in Visual Basic, but use PowerBasic to write your number crunching code for the backend. But I wanted to be able to write a full blow application using PowerBasic alone. But Why ?
PowerBasic had two things Visual Basic lacked. One was that it was designed for better performance. It had many low level features which Visual Basic lacked such as pointers, very fast string engine with extensive command set, inline assembler and it was better suited for accessing the Windows API. Yes, Visual Basic programmers for years were extending Visual Basic by accessing the Windows API, but PowerBasic was designed specificly for this, so it was better suited. One nice example is how easy it was in Powerbasic to work with pointers, even code pointers. One could use the LoadLibrary API to load a DLL and then pool it for the address of an API function and then make a call to the function using the CALL DWORD command which is for calling a function using a pointer. PowerBasic also had a richer data type set, better suited for working with the Windows API.
So for a few years I was on a new adventure. I started to learn how to code using the native Windows API (WIN32). While some may laugh at the idea of using BASIC for any professional programming, what I was learning to do was more akin to learning how to code using pure C with the Windows API. Now mind you, I said C, not C++. Why ? Because working with the Windows API was more procedural in nature than object oriented, whether one did it in C or Powerbasic. To be able to learn how to work with the Windows API, I needed some kind of training and since there were literally no books available about using the Windows API with PowerBasic I had to use books written for C (not C++). Since coding with C using the Windows API went out of fashion in a short time after Windows became a 32 bit operating system, with Microsoft first pushing MFC and then later managed languages took over, when I would search out good books to read, I could only find used books from many years ago which I would look for on Amazon. I searched for the best books I could find on coding with C using the Windows API. I did find a few (the same was with OpenGL too). When I wanted to learn how to write custom controls, I could not find anything useful for 32 bit Windows and the only book I could find was for 16 bit Windows, but amazingly the techniques taught are still viable today even with Windows 8. So with an extensive library in hand, I proceeded to teach myself WIN32 programming. Fortunately, PowerBasic syntax is much easier to deal with than C, so coding the WIN32 with PowerBasic was much easier than coding using C, so maybe this is why it was possible to deal with it better. But learn I did.
What native coding has taught me!
What makes this story so interesting (at least for me) is what I learned from this effort to learn low level WIN32 coding. I have spent a decade and a half as a native coder and it is what one can accomplish with native coding that really amazes me. The Windows API (WIN32) is an amazing thing. It is actually very efficient and designed for performance. The many features designed in Windows for low level customization is just astounding to me. The DLL (dynamic link library) is ingenious. I work with things like writing custom control classes, threads, ownerdraw, customdraw, subclassing, superclassing, window hooks, custom dialog classes, DIBs (device independent bitmaps). But if the powerful features of the Windows API don’t excite a programmer, that maybe this will. Native coding allows a programmer to write software which will put most modern software to shame when it comes to performance and minimal hardware requirements. Native coding produces software which is so small, that it is simply amazing, really.
But there is more to this. Native coding is not object oriented ! Yes, native coding is more procedural in nature. True, later versions of Windows added a layer of new features using COM classes, but the majority of the WIN32 API is a flat API. Even when GDIplus was added, while Microsoft promoted using the C classes provided to work with it, they did create a flat API, which a few PowerBasic programmers were able to leverage so they could use much of the GDIplus using a more procedural style of coding and this benefited performance. Do you find this hard to believe ? Here is an example of how a native coder can leverage multiple graphic engines in Windows to work together and all in a tiny package using native coding. ZapSolution, a french company, developed a number of excellent graphic libraries using native coding. One is a skin engine, for skinning Windows ( WinLift ) applications and the other is a graphic engine which allows you to combine the GDI, GDIplus and OpenGL together seamlessly ( GDImage ). But what you will find amazing about both of the libraries is not only the performance, but the amazingly the tine size of the libraries. They were originally written in PowerBasic, but the developer switched over to C and is porting them to C. The two languages are very similar when doing native coding. It is not whether the libraries were created in PowerBasic or C, which really matters, but the point that they were developing using native coding using a purely flat API using a procedural style of coding.
Native coding produces some of the smallest executables you likely will ever see and the performance is as good as it gets. About the only way I could see one get better performance would be to use native coding but use assembler instead. I doubt most programmers could handle that, working with both native coding and assembler, but amazingly there are some who have. One of my favorite examples and a very nice toolbar painting utility called ToolBar Paint . It was written using native coding and assembler its tiny size shows it. The app even supports plugins.
Procedural coding style improves upon Native coding
While everything today seems to be all about OOP (object oriented programming), few appreciate the power of good old procedural style coding. What makes native coding so powerful is that it also uses a more procedural style of coding which is easier to debug and which produces much smaller applications with less overhead. Actually, I have found the good old dynamic link library (DLL) to be far more efficient and less resource hungry than modern day components (COM based OCX, dot.net components). DLL’s can be very efficient and can do some amazing things. The so called problems some faced with DLLs can be easily overcome by some simple practices. For example, if I plan on a DLL being upgraded but the filename needs to be the same, I design it from the beginning to pass the application a version number so the application can know what version of the DLL it actually loaded. This way the app can compensate or even provide information to the user that a different version of the library was found than expected, in the rare case it does. Second, in the old days hard drive space was limited so often libraries like DLL’s were installed in the System folder (or System32) to decrease disk space usage. But today, disk drives are so huge that this is no longer an issue, so DLL’s can simply be installed in the same folder as the application, which prevents problems with version conflicts. Native coded DLLs are so small in size, that the extra space used even on tablets is insignificant. Lastly, the practice of writing an API using a prefix for all function calls, decreases the problems with name conflicts (which name spaces was designed to solve in the managed world). For example I developed a GUI engine (DLL’s) which has a command set of nearly 900 commands (subroutine and function calls) and in the entire API I use a prefix for every API and even the constants used in the include file (similar to a C header). I uses the first letters of the products name as the prefix, so every API call starts with EZ_ . Other library developers have found this useful, to use a common prefix for an API they create. While this won’t solve every possible conflict between libraries, it does decrease them significantly, so one need not use namespaces anymore, but simply one can use a flat API library. I should also point out that the use of DLL’s and native coding, can allow one to create transportable software, which only needs to be copied and run. Much of the software today can only be run if it is properly installed by an installer program which handles any registrations with the operating system. Most applications could not simply just be copied from drive to another and then expected to run. Transportable software is purely standalone software which does not require any access to the registry, has no components to register and can simply be copied and run. It can easily be installed onto a flash drive, micro SD card or even be copied and run from the cloud drive, like SkyDrive.
Smaller, Faster
Programmers are always looking for ways to developer smaller and faster software. Some compiler makers have even considered that smaller and faster should be a major goal of their programming languages. Old time programmers know what it means to be able to build smaller and faster software. They had little choice when computers had so little power and memory. But today, programmers can benefit from that experience. Find that old time C programmer working in a corner somewhere in your shop and ask him (or her) how you can learn to build small, faster software. Maybe you might even have native windows coder in your shop or company somewhere. Surely they can teach todays programmers a thing or two about building smaller, faster software. So with the coming “Internet of Things” are you looking for ways to produce the next great software package which can run on even the smallest Windows device possible ? Why not learn more about native coding. Why not learn how the “old fashioned” procedural style of coding, often used with such native coding, can provide some benefits that even OOP can not. Now remember, I warned you a couple times in this article that you probably don’t want to hear this, so if you have read this article all the way to its end then maybe you have that itching inside to be the next native coder. Just be careful to not tell your friends you are one (no one wants to be laughed at). Instead just let your tiny, high performance apps that you create using native coding speak for themselves. Then you truly do get the last laugh. Maybe even a raise when you show the boss what you can do. So happy coding ! Maybe you too can be a native coder !