Programming Windows: MFC (Premium)

While Microsoft had supported Windows application development in Microsoft C and other compatible C compilers since version 3 in 1985, the firm was late to the game on two related fronts: Support for C++, the object-oriented extension to C that the rest of the industry had embraced by 1990, and a native Windows version of the product; Microsoft C was MS-DOS-based.

Microsoft temporarily addressed the first issue by releasing a one-off product called QuickC for Windows in 1991. As you may recall, the Quick series of Microsoft programming products, which also included QuickBasic and QuickPascal entries, had been released previously on MS-DOS as a counter to Borland’s enormously successful Turbo Pascal.

But the firm never adapted Microsoft C for Windows over seven major releases, though it was known to be doing so.

“Microsoft continues to work on its own C++ compiler for Windows,” Byte Magazine reported in February 1992. “Stewart Chapin, group product manager for languages at Microsoft, confirmed that the company is working on such a project.”

That product wouldn’t arrive until the following year. But before that, Microsoft C was renamed to Microsoft C/C++ and version 7.0 was released in 1992. Microsoft C/C++ 7.0 was still MS-DOS-based, but the release was notable for its support for C++ and for a new C++ class library that had been renamed to the Microsoft Foundation Class (MFC) library at the last minute. The original name had been Application Frameworx, or Application Framework Extensions, depending on whom you spoke with. AFX, either way.

(Fun aside: Many MFC functions use an “Afx” prefix due to the late library name change.)

“As part of its object-oriented software strategy, Microsoft intends to create and use a group of class libraries that it calls the AFX (Application Frameworx) Class Libraries,” Byte also reported in that same issue. “The libraries will be part of a total software environment resting on top of the operating system and GUI that will work both as part of Microsoft Windows and as an extension to Windows, the company has disclosed … The company calls its current Windows programming tools, which lie directly above DOS and Windows, the ‘Microsoft Windows Framework and Foundation.’ The AFX Class Libraries will be the next layer up: Programmers will be able to call them to simplify the work of creating Windows applications.”

I’ve never heard of the Windows API referred to as the Microsoft Windows Framework and Foundation. But whatever, the description is fair: MFC was indeed “the next layer up.” It was a class library that abstracted the terribleness of the Windows API into lightweight OOP wrappers that would hopefully prove to be more readable, maintainable, and scalable than its predecessor.

MFC didn’t really take off until the release of Visual C++ in 1993. That product shipped with MFC 2.0, a major update that doubled the size of the class library and added support for the Multiple Document Interface, or MDI, which was then briefly popular before most productivity applications returned to the more common Single Document Interface (SDI).

As its name suggests, an SDI application can contain and display a single document or view. The Paintbrush application from Windows 3.1 is a typical example of an SDI application.

But an MDI application is more complex: It can contain multiple documents or views, which are displayed in their own sub-windows inside of the main application window. The Windows 3.1 File Manager application was an MDI application.

Microsoft adopted MDI for its Office applications for several years, but later relented and moved back to an SDI model where the user can now open any number of Office documents simultaneously, each in its own full application window. The reason is that MDI sub-windows exist outside of the system-level multitasking capabilities built-in to Windows and are thus more confusing to users. (The only major exceptions today are web browsers.) MDI applications were also very hard to create and maintain, even with the built-in facilities in MFC.

Visual C++ was notable for other reasons: It included a new Visual Workbench integrated development environment (IDE) that expanded on the capabilities of its predecessor in useful ways and pointed to a future in which all Microsoft developer tools would eventually use a shared IDE called Visual Studio. It also included a number of resource editors—for things like application icons, cursors, dialog boxes, menus, bitmap images, and string tables—and supported VBXs, the add-in controls first developed for Visual Basic.

Contrary to its name, however, Visual C++ was not really a visual environment like Visual Basic, though it did include visual designers for resources like dialogs. Instead, it was more focused on pure code, similar to how previous Microsoft C/C++ products worked. But in addition to those resource editors, Visual C++ included an Application Wizard that was a distant predecessor to the Visual Studio project types we use today. (I used its modern equivalent to create the Hello, MFC application.)

This was a big deal.

This wizard-based approach, combined with the MFC library, made creating Windows applications easier than ever for the C/C++ developer. You could use the wizard to specify which features your application needed—a menu bar, perhaps, an About dialog, and so on—and Visual C++ would generate skeleton code in numerous source code files. The scaffolding that had previously made Windows API development so tedious was erected for you.

The downside to this approach, however, was that the MFC Application Wizard generated a ton of source code, spread across literally dozens of files. It became unmanageable very quickly.

Consider the Hello, MFC application, which you’ll recall was derived from Jeff Prosise’s 1996 book Programming Windows 95 with MFC. That simple program consisted of exactly two files and under 40 lines of handwritten code. Prosise didn’t use a Visual C++ wizard to generate it. He mastered the libraries and wrote his own code, much as Charles Petzold had done for his Programming Windows series of books.

This wasn’t how MFC developers did things, however. Instead, they used the Application Wizard and went from there.

To see how much more bloated even the most basic wizard-generated MFC application can be, I used Visual Studio 2019 and its MFC App project type, which steps you through the modern version of that Application Wizard. There are five steps, all with multiple options representing application capabilities like MDI support (with or without tabbed documents and the Document/View architecture), various window styles, whether it comes with a system menu, status bar, and other UI elements, and much more. Printing and print preview, ActiveX controls, application recovery support, the works.

I made this as simple as possible: A dialog-based application (so no MDI or SDI) with every possible feature unchecked in the wizard. After churning and bubbling for a bit, Visual Studio presented me with my new empty MFC application. Which consisted of 9 source code files (6 of which were header file) and three resource files representing the app’s icons and other resources. Total lines of code? Over 310.

A more complex application—a real application, one might say—would obviously be significantly bigger. It would do more, too, of course: In fact, a sample MFC MDI application presents the skeleton of an application that looks an awful lot like Visual Studio itself. It has a fully-populated menu bar, a file browser, multiple UI panes, tabbed document windows, and an About box.

The problem with MFC was that it was designed, literally, as a lightweight wrapper over the obtuse Windows API. MFC even reused many Windows API function names as the representative class methods to ease developers’ transitions to the new environment. This was the same mistake the firm made with Win32, the 32-bit version of the Windows API that Microsoft created for Windows NT. Instead of making a clean break and creating a more sophisticated, well-designed, and modern framework, Microsoft worried too much about backward compatibility and bringing its developer base forward with minimal effort.

What Microsoft should have done is created a framework that truly abstracted the Windows API into a cleaner, easier-to-use set of objects, and a developer environment that provided visual user interface layout and creation capabilities. In other words, a more sophisticated version of Visual Basic.

The software giant would eventually get there. But it was side-tracked for several years by a growing swell of outside forces that included open-source software and Linux, the Internet and web browsers, and a new generation of cross-platform developer languages and runtimes like Java that were uniquely positioned for this new world. As the software giant raced to complete Windows 95 in 1995 and peak in a brilliant—if temporary—flash of popularity, its power was slowly crumbling beneath it. But it would respond, slowly at first, and perform its last great act of destruction before finally stumbling before the power of antitrust regulators and courts from around the globe.

More soon.