Lessons Learned from Legacy Windows Programming

For many programmers who have been writing software only for less than a decade or two, how they write software today may seem unquestionable and the only way to program. But for old time programmers who have been around for awhile, things are not so clear and concrete. Their lives have likely been one of change, after change, after change. It is easy to dismiss the comments of such old time programmers as “out of date” or to assume they simply can’t handle change. But actually their long time in the industry often provides a perspective that younger programmers may not have gained yet.

How Computers Have Changed!

My first experience with writing software was back in 1975. In an advanced math class, the teacher gave students access to a teletype like terminal connected via a modem to a nearby college mainframe computer. Programs were written in BASIC. Later when in college, learning how to write programs in Fortran on punch cards was tedious and slow. I would not be exposed again to computer programming until the mid 1980’s, when computers were coming into a new phase. The “home” computer became the darling of the industry, but being expensive at first, only self taught adventurers were programming on these. The education system had not caught on yet to computing for the “masses”. My first computer was a TI-99/4A computer (by Texas Instruments). Learning BASIC was easy, but the computer was very limited. I was able to pick up a number of home computers, clearanced at a local store (mostly Atari’s) and started to teach local people how to program (in BASIC) on a home computer. This opened up an opportunity for me to connect with a local factory who needed some help in writing some quality control software for data gathered from a testing machine in the plant, which was downloaded to a Kaypro computer. I had to start learning some assembler programming to solve some problems with performance. Writing software for local businesses over the years on CPM and later early IBM compatible PCs was challenging. I started with interpreted BASIC, but in time recognized the need for using a compiler. Even with software I was writing on a Commodore 64 home computer, I quickly realized the need for using a compiler and then even learning how to code in assembler. Since performance required getting every tiny bit of speed out of a computer as possible, I even learned how to write my own compiler (using another compiler), just to meet a specific need for better performance.

The DOS world of computers changed rapidly, from CPUs running at only a few megahertz, to CPUs running 25, 35 or more megahertz. Breaking the 100 mhz CPU speed was a big deal when it happened. Data storage was a challenge too. From single sided floppy disks to double side floppy disks, then to hard drives with “huge” storage capacities like 10 or 20 megabytes (at the time of course, not today). From monochrome displays to CGA, EGA and the VGA color monitors, the visual aspects of software changed rapidly. From text only screens to graphic oriented displayed, software again had to make big changes.

Then Came Windows (16 bit)

And then came Windows (16 bit). The Graphic User Interface (GUI) flipped the software world upside down. Many a DOS programmer found the switch from DOS to Windows to be an extremely difficult challenge. I was one of them too. Many commercial software companies hung on to DOS versions of their applications for far too long, simply because learning Windows programming was challenging to say the least. The benefits of a Graphic User Interface were obvious, but the coding was the problem. I experimented with a number of BASIC programing languages for 16 bit Windows, such as CA Realizer, GFA Basic, etc. Most I found too complex and with either too much emphasis on object oriented programming styles (which was not used in the early days) or too low level (too close to the Windows API), so I struggled like many other DOS programmers. And then along came Visual Basic (classic). Visual Basic had the nice mix of some OOP (for Forms and Controls) but also allowed a more natural procedural style of coding which most DOS programmers were used to. Sadly though, while Visual Basic introduced RAD (Rapid Application Development) software design, along with a familiar BASIC coding language, it went backwards as far as performance because it was a PCode compiler and not a native code compiler. Most were happy that it made an easy transition to Windows programming, but old time programmers used to squeezing every little bit of raw power out of a computer quickly begged for more. In was not until a number of generations later of Visual Basic that a real compiler backend was provided. With 32 bit Windows, Visual Basic made the transition seamless for existing Visual Basic programmers, since it went from 16 bit to 32 bit with few demands on the programmer to change.

In the C (and later C++) world, performance was a must, so some of the best software was likely written in C (and later C++). During much of this time, the transition from procedural style coding to object oriented style coding changed the industry in ways that it is still reeling from to this day.

The WIN32 Appeared to be a Challenge for Many

Much of this I am viewing from hindsite, so the observations may not have been so apparent to programmers at the time, but the problems were still there. It appears that the Windows API was the powerhouse of programming styles, first with 16 bit Windows (WIN16) and then later with 32 bit Windows. If you wanted raw power in an application, then learning how to code directly to the WIN32 API was how you did it. The problem though, was that the WIN32 was not that intuitive (nor easy) for most and it was very time consuming. Microsoft's efforts to improve the situation with MFC (Microsoft Foundation Classes) and others solutions from other companies like Borlands OWL framework, helped a little, but did not satisfy fully the need for ease of use and RAD development. So what was a programmer to do?

Visual Basic had lost some of its glamor among commercial developers, because it was not a true compiler. Only late in the game did it finally get a real compiler backend and even there from what I have read, a C compiler backend had to be used to fill the need, rather than write a real BASIC compiler from scratch. Performance has always been an issue in software development. There has always been this difficult balancing act between performance and ease of use (later RAD) in programming language development. Programmers want the best performance, but with the least amount of effort.

RAD and OOP Change Software Development

Along the way, two key software development styles began to emerge, which would change the software industry significantly. RAD has always been around in one form or another. In the early years, RAD was accomplished through screen design (text only) utilities and code generator utilities. I found myself writing such utilities back in the DOS days. Much of such tools were likely inhouse tools developed by programmers (or companies) themselves. Some companies wrote tools which they sold to programmers (anyone remember a DOS code generation system called Soft Code by Software Bottling Inc.). Programmers (and companies) also put a lot of work into building their own user interface and database frameworks.

But with Graphic User Interfaces coming into style, the need for Drag and Drop design became the rule rather than the exception. Building a real Drag and Drop designer (WYSIWYG) is not an easy thing to do, at least not in the early years of Windows. If you have an old copy of Visual Basic 1.0 or 2.0 still sitting around, why not pull it out and install it on a computer (which can run 16 bit Windows apps) and see what things used to be like back then. Visual Basic 1.0 and 2.0 were rudimentary at best. True, they were exceptional when they first were released, but by today’s standards they were quite rudimentary. Drag and Drop design has become the responsibility of programming language makers today, rather than programmers themselves. Few programmers today likely would know how to write a drag and drop visual designer using the WIN32 API alone. Programming has become something more akin to graphic design, rather than old time coding. Programmers expected to be able to “draw” their applications, rather than have to code them.

Object Oriented Programming also drastically changed software development. Now for an old time programmer, like myself, OOP was not the big hit it appears to be today. Why ? OOP came out of the educational system more so than from programmers themselves. As a commercial programmer, I had no desire to start writing classes and objects to solve problems. Most in the DOS days likely didn’t either. It was the Graphic User Interface which changed things and particularly classic Visual Basic. Visual Basic introduced many to something more akin to OOP than they had worked with in the past. Now Forms and Controls were objects with properties and methods to implement them. Interestingly though, the core WIN32 API under the hood which Visual Basic tapped into to accomplish Graphic User Interfaces, was not object or class based, but was a flat API or more procedural in nature. Learning how to code directly to the WIN32 API was thought to be difficult and possibly some may have blamed this on its more procedural nature Having come to WIN32 programmer many years after it went out of style and looking back, I personally feel that the complexity of the WIN32 didn’t come from its procedural nature, but it came from a lack of higher level procedural based GUI frameworks which would provide ease of use for programmers. The WIN32 is an amazingly powerful framework, but simply is too low level and it lacked the kind of documentation needed to make it understandable (meaning you won’t learn how to code the WIN32 from the MSDN documentation). So the Charles Petzolds of the world filled a nitch by figuring out how Windows really worked (WIN32) via experimentation and then wrote excellent books bringing their experience to the masses so others could tap into the raw power of Windows. But there was one problem. Most such books on Windows programming were like reading the New York city telephone book (not in content but simply in size). It took dedication and commitment for a programmer to read (and understand) such books from cover to cover. Also programming languages have gone through shifts in favor. BASIC in the DOS days was very popular. Between Microsoft's Quick Basic and Borlands TurboBasic (which is now called PowerBasic), programmers had programming languages with powerful compilers, so they had ease of use (via the language and any libraries it provided) and performance. With Windows, classic Visual Basic took too long to finally have a real compiler backend, so likely other languages like C (and later C++) which did have the performance, took the “front seat” (favor) among commercial programmers , despite lacking the ease of use of languages like BASIC.

.NET Changes Things

So what next? .NET came along with its GUI framework, which is much more high level and its heavy reliance on object oriented programming. The goals were good, but the implementation has much to be desired. How have some old time programmers viewed the shift to .NET ? Were they simply just too old and tired out to learn something new? It should be pointed out that the longer someone has been programming, the likelihood they have a lot more experience to help them gauge new technologies. Old time programmers have been dealing with changes in software development a lot longer and have likely seen a lot. Today’s programmers would likely benefit from the perspectives of such programmers. So what has this old time programmer experienced and what observations might he offer?

Because my programming experience didn’t follow the typical path of most, using mostly Microsoft development tools (after classic Visual Basic ended) in recent years, I actually found myself not using any Microsoft programming language for over a decade. Classic Visual Basic was fading away, so I switched to a native code compiler (PowerBasic). The compiler had absolutely no GUI engine at all at the time (15 years ago) , so the only way to write a Windows application was to learn the Windows API (WIN32). I was starting the process of learning WIN32 programming, many years after it had gone out of style. I found that I had to search for used books dating back into the 1990’s, to find ones that dealt with WIN32 programming without MFC or ATL. Fortunately for me, there was Amazon.com and buying used books was easy. The same went for learning OpenGL 1.0/2.0, which I did also. A few of those books were pretty big (not quite the NY phonebook), but I trudged through them thoroughly. It took years, but I slowly began to make sense out of it all. With MSDN and the SDK docs (downloadable) available, I had the core API documentation as well. But even then some things alluded me. For example, I could not find a book on how to write a custom control using the pure WIN32 API. Finally I found one, which dated back to 16 bit Windows (fortunately it had not changed for 32 bit Windows). There appears to be very few good books on the subject. Learning how to build custom dialog classes, subclassing, superclassing and writing new control classes from scratch were all there in that book. After over a decade of not using a Microsoft programming language, I tried my hand at Visual Studio when WIndows 8 came out. It turns out that WIN32 programming actually appealed to me more than today's object oriented programming. Legacy Windows programming was no so obsolete after all. True I now have the benefit of years of experience with the WIN32 API, but its advantages far outweigh its challenges. Why is that? Computing devices are getting smaller and smaller, so programmers need to be able to squeeze every tiny bit of raw power out of a Windows device. TV PC Sticks (USB sticks which plug into the TV) are now coming to market and the Internet of Things likely will bring new devices, many running a real version of Windows (x86). With minimal hardware, a programmer needs to be able to tap into the raw power of Windows with the least overhead.

Legacy Windows (WIN32) Lessons

Rather than switch to class based frameworks or something like the .NET runtime, the WIN32 can be the basis for building flat API frameworks which are so lean (small) and fast, that programmers will be able to write the fastest, tiniest applications with few hardware resources required. Much of the WIN32 has often not been tapped into. The resources for customization are almost endless in the WIN32. Windows was designed with all sorts of customization features built in. From subclassing, ownerdraw, customdraw, etc you can modify how things work to your exact specifications. The Windows DIB (Device Independent Bitmap) engine is very powerful and I found it one of the most useful tools in the API and it has been there since Windows 95. The simple design of DLLs (Dynamic Link Libraries) is so well done. It even allows one to be able to load libraries dynamically at runtime (ie. operating system DLLs) and then you can poll them to see if an API exists. This has made it easy to build GUI frameworks (of your own) which can respond to the different versions of Windows, so you are not locked into always targeting the latest version of Windows. In the enterprise and business, the need to be able to build applications which can run on today's computers as well as ones running legacy versions of Windows is important. The biggest advantage is the size of the applications and the amount of resources (memory and CPU power) required. If Microsoft could create a version of Windows which could run on less than 1 gigabyte of memory and run well on a CPU running at less than 1 ghz, a WIN32 programmer would have little problem in writing an application which could run on it. The Internet of Things might make such devices necessary, so native coding using the WIN32 could be the new standard for building tiny applications. Do you find that hard to believe ?

Why not download the following two applications and see how well they run on the most minimal hardware (with x86 Windows) you can. Do you have an old Windows XP or Vista computer sitting around with little disk space and memory ? How about Windows ME ?

• WIN32 Windows 8 compatibility Test App
• OpenGL Based 3D (STL) Model Viewer App

Now remember, the above apps do not need any .NET runtimes. You can run them on a Windows PC (or device) without any .NET runtimes installed, since they are not dependent upon any .NET GUI frameworks. No MFC required. No ATL required. No C runtimes required. No Visual Basic (classic) runtimes required. Only what the core operating system itself requires.