Application frameworks vs. a full application system Object-oriented technology has been evolving for a long time and has many precursors in the current generation of system software. The left side of Figure 5 shows the basic model used in today's procedural systems: an underlying operating system, libraries and APIs built on top of that system, and applications written using those libraries and APIs. The middle part of Figure 5 shows how object technology has been introduced for writing applications that work with the current generation of operating systems. An application framework provides a preassembled generic application that a developer can modify to create a real application. For example, the application framework includes basic menus and windows and code for basic operations, and the programmer adds the new code required for a specific application. Because the developer starts with robust code that's been tested and debugged, the new code is more likely to work reliably both with the system and with other applications built from the same base. This is a big improvement over the model shown on the left of Figure 5. Examples of application frameworks include Apple's MacApp, Microsoft Foundation Classes (MFC), and NextStep. These frameworks in turn provide class libraries, or collections of ready-made objects, that make the frameworks easier to work with. (Objects and class libraries are discussed in more detail in Chapter 2.) The class libraries are built on top of the same procedural operating systems as before. At first glance application frameworks seem to have the best of both worlds: they make use of OOP, so they're easier to use and maintain, but they can coexist with the older procedural operating systems and applications that are based on them. However, application frameworks running on a procedural operating system have some drawbacks: The application framework controls the underlying operating system not by manipulating objects in the system, but by mapping object behavior to the underlying procedural libraries. This creates a certain amount of overhead and loss of fidelity. Because the framework generally doesn't provide everything required to write a real application, programmers must still make calls to the underlying procedural libraries (the box below "Class libraries" in the middle part of Figure 5). For example, MacApp developers must still make QuickDraw and other Mac OS calls, NextStep developers must still make Display PostScript and UNIX calls, and so on. In effect, the programmer must master two programming environments, one object-oriented and one procedural, including two sets of manuals, two kinds of debuggers, two sets of courses to take, and so on. Because the creators of the framework must figure out how to map the behavior of the framework to the underlying procedural system and then test the resulting mechanism, there is often a time lag between upgrades to the operating system and corresponding upgrades to the application framework. MacApp developers, for example, had to wait six months after the first release of System 7 before they received a version of MacApp that gave them the system's new capabilities "for free." The right side of Figure 5 illustrates Taligent's approach. Taligent has built its entire programming model around objects. A foundation layer of basic system objects supports a rich set of class libraries, which in turn support frameworks designed to build not only traditional applications but also extensions and additions to any part of the application system. Taligent not only asks its developers to use OOP, but also uses exactly the same techniques throughout its own application system. As mentioned earlier, Taligent has designed the CommonPoint application system to run on existing operating systems such as OS/2 and HP-UX. This means that applications written for the CommonPoint system can run on the same computer with applications written for that computer's native operating system, as shown in Figure 3 on page 33. However, unlike applications written with most traditional frameworks, CommonPoint applications don't need to use the host operating system APIs. The CommonPoint application system provides a complete programming model, and applications developed with it are fully portable across multiple host operating systems. Because the CommonPoint application system maps to host systems at a very low level, rather than repackaging host capabilities, it avoids mapping overhead and time-lag problems associated with traditional application frameworks.