Click here to Skip to main content
15,867,453 members
Articles / Desktop Programming / MFC

Lessons Learned from Legacy Windows Programming

Rate me:
Please Sign up or sign in to vote.
4.82/5 (14 votes)
2 Jun 2015CPOL15 min read 15.6K   7   11
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 ?

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.

This article was originally posted at http://cwsof.com/blog?p=849

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Software Developer Computer Workshop
United States United States
Chris Boss is the owner (and programmer) of a small software development business in rural Virginia, called the Computer Workshop. For the last ten years or so he has been developing tools for use by Powerbasic programmers (see: http://powerbasic.com ). His main product called EZGUI (Easy GUI) is a high level GUI engine with Visual Designer and code generator. It is in its fifth generation now. He is an experienced Windows API programmer (more low level) and has experience in writing GUI engines (forms/controls), drag and drop Visual Designers, Graphics engines (printing and to the screen) and one of his favorites is a Sprite engine (2D animated movable images). His current project is version 5.0 of his main product EZGUI, adding such features as multi-monitor support, component engine, custom control engine, superclass engine and the latest project a 3D OpenGL based custom control. One of the goals he has is to push the limits of Windows software development, while making it easy, fast execution speed, small footprint (size of executables) and code reusability while providing a more graphic experience in user interfaces, while still being able to write software which can fit on a floppy disk (small footprint), use minimal amount of memory and able to run on multiple versions of Windows from 95 to Win8.

Comments and Discussions

 
QuestionMakes me homesick Pin
Willem Gons24-Nov-15 20:25
Willem Gons24-Nov-15 20:25 
QuestionGreat Article! Pin
eslipak8-Jun-15 13:49
professionaleslipak8-Jun-15 13:49 
QuestionNice Pin
waleri5-Jun-15 3:06
waleri5-Jun-15 3:06 
AnswerRe: Nice Pin
Chris Boss5-Jun-15 7:15
professionalChris Boss5-Jun-15 7:15 
GeneralRe: Nice Pin
waleri10-Jun-15 21:12
waleri10-Jun-15 21:12 
QuestionCool article Chris! Pin
enterprisetoday3-Jun-15 20:39
professionalenterprisetoday3-Jun-15 20:39 
AnswerRe: Cool article Chris! Pin
Chris Boss4-Jun-15 4:59
professionalChris Boss4-Jun-15 4:59 
AnswerRe: Cool article Chris! Pin
Chris Boss4-Jun-15 5:18
professionalChris Boss4-Jun-15 5:18 
I should mention that from my days with the Commodore 64 learning 6502 machine language, it has made me tend to prefer being closer to the machine than most programmers are today. Low level API's are more friendly to me than all the object oriented stuff of today. That is probably why I took so well to the WIN32 API. Initially it was confusing to me, but I blame that in having used Visual Basic for awhile. That took me away from the lower level stuff. Surprisingly the WIN32 is far more friendly and sensable to me than any dot.net languages of today. Have played with visual studio in recent years, but it is far too confusing to me. I guess my mind is geared to more simpler and low level concepts than all the OOP stuff.

But rather than be limited, by not using dot.net, it has freed me to learn how to push the WIN32 to its limits. So many things were left out of it, so I had to build many things myself from scratch. For example, one of the hardest things to do with the WIN32 API is to build a drag and drop engine, such as needed for a programmers visual designer. I built mine from scratch and it can handle things like "rubberbanding" (drawing the controls), subclassing real controls and using them as objects (rather than use placeholders for controls), build my own drag handle control, handle dragging of hundreds of controls (via a rubberbanding engine) at one time, handling autoresizing of controls, etc. Most visual designers require a property listbox control (which does not exist in the WIN32), so had to build my own.

The WIN32 never had Sprites (DirectX does) which is surprising to me, coming from the old Commodore 64 and Atari. I would have thought sprites would be a given. Had to build my own 2D Sprite engine from scratch. The Windows DIB engine solved a lot of problems for me.

As far as 3D, which I tackled later, DirectX was too object oriented for me and it didn't work well for handling 3D controls (multiple child 3D windows in a Form, rather than a single 3D window). OpenGL though was better suited, being a flat API (at least 1.0 and 2.0) and it worked perfectly for building a real 3D control, which WIN32 should have had early on. The problem with 3D is that most view is for gaming only. I built a 3D control better suited for business apps and general apps, rather than for gaming.

The WIN32 also has so many different ways to customize things, from ownerdraw, customdraw to callback procedures for the common dialogs. Building custom controls using superclassing also allows one to build upon what is already there.

I don't need a 50 megabyte dot.net framework either. Built my whole framework and it only takes about 1 megabyte. Can fit on an old fashioned floppy disk. Does more than the VB runtime at about one third the size (VB runtime needed a bunch of OCX controls just to handle things like the common controls, common dialogs, etc) and I am doing things like OpenGL 3D, 2D Sprites, ownerdraw, threads, etc. Made me realize that Visual Basic (like because it was too dependent upon COM) was not very efficient. My framework even has the drag and drop engine in it for building visual designers (VB does not). All on one megabyte! Likely the whole framework could fit and run any IOT device that can run Windows too, as long as Windows can run.
QuestionNice story! Pin
SMD1113-Jun-15 8:48
SMD1113-Jun-15 8:48 
AnswerRe: Nice story! Pin
David A. Gray3-Jun-15 21:03
David A. Gray3-Jun-15 21:03 
GeneralI think you misnamed your article.... Pin
clawton3-Jun-15 7:09
clawton3-Jun-15 7:09 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.