These days, if frameworks are discussed in the trade press, it is in the context of how well they support emerging interoperable object models such as Microsoft's COM, IBM's SOM, or the CORBA industry standard (for background, see Dr. Dobb's Report on Interoperable Objects, Winter 1994/95).
Emerging technologies aside, a common question that routinely crops up on Internet newsgroups and on-line services is: "I'm starting a major programming project this week. Which app framework should I use?" Usually, the poster is weighing Zinc versus zApp, MFC versus OWL, or XVT versus Galaxy. In this situation, the developer needs a practical answer today, not more discussion about promising, but unreleased, technologies.
Unfortunately, the subject is complex enough and individuals' needs are sufficiently varied that it's impossible to give a short answer. But we can provide context and perspective to inform your decision.
For the purposes of this discussion, I'll refer to an application framework as a class library that provides commonly used application-level functionality in an integrated fashion. Ideally, an app framework instantiates a generic application that is designed so that you can easily derive, in an object-oriented way, more specialized instances. Often, these instances can run on multiple platforms, such as Windows, Macintosh, OS/2, and/or UNIX. The functionality supported includes user-interface components (toolbars, status lines, progress meters, splittable windows, and the like), as well as non-GUI services such as support for command undo or error recovery. The architecture that ties these components together is just as important as the components, because the goal is reuse of design, not just code.
App frameworks are not new, of course. The first such framework, Smalltalk-80's class library, is now 15 years old. The mid-1980s saw some interesting projects in academia, such as ET++ and Interviews, as well as the first commercial app framework, Apple's MacApp.
On the PC platform in the early 1990s, the field of commercial app frameworks was wide open with many contenders, mostly from small, technology-intensive startups. These products were of disparate ancestry, evolving from rudimentary user- interface libraries without any awareness of architectural concepts such as the Model/View/Controller (MVC) paradigm. At times it seemed that each one reinvented different parts of the same Smalltalk/MacApp wheel. Although the tools were incomplete, they were complex enough that it was difficult for a user to evaluate more than one or two. By the time you became familiar enough with the intricacies of one product to assess whether it was appropriate for your needs, the rest of the field had changed or evolved.
The computer press grappled with evaluating this technology. Initially, many evaluations were of the "Saturday night review" ilk in which the reviewer used the framework to print "Hello world"--the equivalent of evaluating a Lamborghini by driving it inside the dealer showroom.
Since that time, the field has thinned considerably. Tools such as Glockenspiel CommonView, Vleermuis GUI_Master, Blaise Win++, Island Systems Object-Menu, Genesis Tier, WNDX, Base Technology Liana, TEGL, and Star Division StarView are either no longer with us or seem to have dropped off the radar screen. Still visible are products such as Borland Object Windows Library (OWL), Microsoft Foundation Classes (MFC), Liant C++/Views, Visix Galaxy, XVT Portability Toolkit, Zinc Application Framework, and Inmark zApp. On the Macintosh platform, Apple's MacApp and Symantec's Think Class Library (TCL) have been eclipsed by Metrowerks' PowerPlant, designed by one of the original architects of TCL.
The packages that remain have evolved along lines that mostly converge on a common feature set. Borland filled in the glaring lack of GDI coverage in OWL, then added elegant support for OLE. Microsoft moved MFC several notches up the ladder of abstraction, by adopting a Smalltalk-influenced MVC architecture, and continues to provide a head-start on evolving Microsoft APIs (Win32, OLE, ODBC, OCX). XVT grafted a C++ layer on top of its XVT Portability Toolkit, then replaced it with a from-scratch implementation; also added are an interactive design tool and specialized classes for scientific and engineering graphics. Inmark added an interactive design tool and code generator and advanced custom controls to zApp. Zinc made its system more robust and extended its internationalization support.
All these products are now full-featured, well-supported, robust, powerful packages that some of us would have killed for three or four years ago. The core functionality that all either implement or aspire to includes: an interactive design tool, a class browser, a full set of classes at several levels of abstraction, a wide repertoire of UI components including grid controls and split windows, automatic sizing and dynamic layout of UI objects, command undo, on-line help, and an architecture that allows multiple views on a single document.
Significant differences remain in feature set, pricing, and positioning. Some major areas of divergence are: support for OLE (currently only MFC and OWL), database support (MFC), and distributed processing (Galaxy). The spec sheet for any one of these products would fill this entire space, so our coverage must stay at a bird's-eye vantage point and not list every difference.
The answer to "which one should I choose?" depends on what you want to do with it. One thing that every developer claims to want is portability to other platforms. If you need your application to run on OS/2, then MFC is out, although everyone else remains. If you want to be on the Macintosh, then OWL and zApp bow out from the list (although Inmark has been promising Mac support for a while).
Of course, portability is a word whose definition gets stretched in various ways.
Zinc Application Framework is one package that has a very good reputation for portability. The company shows an impressive list of programs built with Zinc software: United Airlines PC- based front-end to its reservation system, the setup program for Compaq computers, the utilities that ship with HP Laserjet printers, Intel's plug-and-play utilities, the fax program that accompanies US Robotics modems, and so on. Most of the examples it lists, however, are programs for DOS and/or Windows. Looking at the Zinc documentation, it turns out that not everything is transparent between platforms:
When portability to many platforms is of utmost importance, one long-standing safe choice for many has been the original XVT tool (Extensible Virtual Toolkit), which began life not as a framework but as a portable C-based API, a thin layer of abstraction across several native APIs. The result is small overhead with good performance. However, this greatest-common- denominator approach implies a subset of features--those that map easily to all platforms. This subset is fine for many in-house applications but may not, again, be acceptable for shrink-wrapped commercial packages that need eye-catching look-and-feel. XVT has addressed this issue by adding features and design tools to its package, following the common evolutionary path shared with other vendors. The current framework, called Power++, is object oriented down to the level of graphical objects such as rectangles.
Microsoft's MFC started out as the notorious "thin wrapper" over the Windows API, criticized at the time by competitors who followed a higher-level, more abstract approach. (Note that, despite the "thin wrapper" criticism, this early version of MFC beat out competitors in terms of code size and memory footprint when implementing the equivalent specification for a program.) The original version of MFC was about 25,000 lines of code; Version 3.0 has grown to three times the size and complexity.
One newcomer to app frameworks recently wrote in a online discussion group: "[MFC] adds several hundred K to your disk- and memory-footprint, even if you use very little of the functionality. It makes your code nearly impenetrable except to other MFC experts, and nearly unmaintainable for that reason." Other participants responded that this is not unique to MFC, but characteristic of all frameworks.
Regarding portability, MFC programs can now be ported to the Macintosh via Microsoft's cross-compiler add-on to its Visual C++ and its Windows Portability Library. However, many developers find the sluggish performance unacceptable, especially for commercial applications.
The mapping between the abstract operating environment provided by a framework and the underlying API gets complicated when there is a second or third API to port to, especially if the framework was designed without those APIs in mind. MFC started out as an inbred kin to the Windows API; Zinc framework has strong roots in a DOS-based user-interface library; Inmark designed zApp at a high-level of abstraction and elegance, yet focused primarily on the Windows platform and has only recently tried to port it to the Mac.
Although placing an API at a high level of abstraction is methodologically more correct (after all, who will take a stand against elegance?), not all developers subscribe to this notion.
In an on-line group, one participant groused about MacApp, TCL, and PowerPlant frameworks, whose classes have names such as Director, Bureaucrat, and Collaborator:
Obviously, a big reason for MFC's success is that it's free, bundled with Visual C++. But Borland's OWL is also free, and at the time these products first appeared, the poor quality of Microsoft's C7 compiler was almost an embarrassment to the company, while Borland's language tools enjoyed a sterling reputation among developers. Clearly, the feature set of MFC must have fit in with the needs of the market. Also, MFC, while not bug-free, is more robust than most. And performance on Intel hardware has never been an issue. Further, the documentation and support, while not perfect, is head-and-shoulders above its competitors.
But you cannot discount Microsoft's tremendous marketing resources and adept execution of strategy as a major contributor to its success. For example, the company's most recent advertisements state: "Write to MFC and you can leverage your code base across a range of platforms." In the ad's accompanying chart entitled "Multiplatform Architecture," three out of five "platforms" are variants of the Windows API (Windows 3.1, Windows 95, and Windows NT). This is a masterful redefinition of the word portability: "MFC...is designed to shield developers from the differences that arise as Windows evolves. So when you write to MFC, your code is safe, as it can easily be ported to newer versions of Windows." It is this kind of marketing brilliance that leads Gene Wang, former arch-enemy of the Microsoft language group, to be quoted in the ad: "MFC is the standard today and will be the standard framework for future Windows platforms."
The point made by the ad brings up the determining factor behind why many developers I know chose MFC: until recently, it was the only one to support OLE (prior to the release of Borland C++ Version 4.5). At the moment, MFC is the only framework to support OLE custom controls (also known as OCXs). Although other vendors can innovate in various ways, such as automatic layout and sizing, or transparent distribution of objects, they can only play catch-up when it comes to changes in the Windows API. Perhaps they can find refuge in certain niches--for example, Zinc has strong support for internationalization, while zApp excels in support for visually intensive applications.
But as Microsoft leads the Windows API down a long and winding road to Cairo and beyond, there seems to be no doubt who will be at the head of the pack.
If you don't like this state of affairs, there's always the curmudgeon's approach. In response to the question, "Does anyone have a recommendation for a cross-platform application framework?", Bob Hablutzel, posting in the Internet newsgroup comp.sys.mac.oop.macapp3, writes: