Hide full article
As we discuss Apple's new operating system, there's a strong awareness that, no matter how good Mac OS X itself might be, it can't succeed without applications created outside Apple. As a result, Apple has put a great deal of effort into both encouraging and pressuring developers to produce software that takes full advantage of the new operating system and requires Mac OS X to run - which will in turn convince users to switch. Unfortunately, since Mac OS X and Carbon (the technology that enables programs to run under either Mac OS 8.6/9.x or Mac OS X) are still relatively new, developers have found themselves stuck between the rock of Apple's Carbon rhetoric and the hard place of its incompleteness. Mac OS X 10.1.2 is a major improvement in terms of maturity, but can't yet compare to the Classic Mac OS's two decades of refinement - begun even before the Macintosh, with the initial development of Apple's Lisa computer.
<http://www.apple.com/macosx/>
<http://guide.apple.com/macosx/>
Mac OS X combines several earlier products into a new and modern operating system, and each brings its own identity and user community along. To make things more interesting, some of the threads Apple has woven into Mac OS X have historically gone in different directions; contrast the Classic Mac OS, designed for non-technical people, with Unix, which was intended for programmers. The end product is a surprisingly successful blend, but Mac OS X's mixed ancestry shows up in some interesting ways. Because each of the different elements includes its own interfaces, biases, and applications, it's impossible to get a good grasp of Mac OS X without keeping in mind the varied heritage of its programs. In part one of this article, I'll go over the three application breeds familiar to most Mac OS users - Classic, Carbon, and Cocoa - and explain their strengths and weaknesses regarding the Mac OS as a whole. In part two, I'll talk about the advantages of Mac OS X's Java support and look at applications written purely for Unix, the heart of Apple's new operating system.
<http://developer.apple.com/macosx/architecture/>
API in the Sky -- The defining characteristic of a Mac OS X application today is the set of APIs (Application Programming Interfaces) it uses, the group of requests an application can make of the operating system - from "what time is it?" and "draw this paragraph in Palatino 12 in that window" to "open this URL in Help Viewer." To avoid redundant effort, programs use APIs as much as possible. This means, for instance, that most applications don't need to deal with fonts directly, because they can have the OS generate font menus and display text. Because of Mac OS X's long and complex history, programmers can choose among several different API sets, each of which manifests some of its own characteristics in programs using the API.
Mac OS X can run applications based on Apple's Classic APIs, which are also available on Mac OS 9 (and earlier), and were previously called the Mac Toolbox. Mac OS X also offers the Carbon APIs, a subset of the Mac Toolbox, designed to offer compatibility with Mac OS 9 while also making specific incompatible changes that make possible major benefits under Mac OS X. Carbon's changes enable preemptive multitasking, superior virtual memory, and crash protection for applications in Mac OS X - none of these additional features are available to Carbon applications running in Mac OS 9. In addition, Mac OS X includes the NeXT-developed Cocoa APIs - in fact, many of today's Cocoa applications were previously available under NeXTstep, the operating system developed by Steve Jobs's former company, NeXT.
All three of the above API sets are proprietary to Apple, but Mac OS X also supports a couple important public API sets (covered in part two of this article). First, Mac OS X supports the Java APIs, designed by Sun to enable the creation of programs that use the Java programming language and run on multiple operating systems. Then there's support for Unix APIs through Darwin, Apple's open source Unix operating system foundation. Based on BSD Unix, the Unix API layer is what enables Mac OS X to run the powerful Apache Web server. This richness of APIs gives Mac OS X many more applications than one would expect in a new operating system - but keeping track of the various types of programs can be confusing.
<http://java.sun.com/>
<http://www.apple.com/macosx/technologies/ darwin.html>
<http://httpd.apache.org/>
Classic -- The most familiar programs under Mac OS X - for now, at least - are Classic programs. These are mostly written for Mac OS versions 7 through 9 and tend to run the same as they would in Mac OS 9. To accomplish this, a copy of Mac OS 9 runs as an invisible Mac OS X program (called, appropriately, Classic). The Classic layer of Mac OS X is good enough that most programs run exactly the same under Mac OS X as they would under Mac OS 9. The exceptions are mostly programs that control hardware directly, such as CD recorders, since Mac OS X has new and incompatible drivers to manage such devices.
The broad compatibility offered by Classic is critical for the success of Mac OS X, since the many existing Classic programs enable people to use Mac OS X on a daily basis, getting work done with familiar tools instead of waiting years for programs to be rewritten. Microsoft Office 2001 and Eudora 5.1 are two excellent examples of important Classic programs - the Office applications enabled people to use Word, share Office documents, and crunch numbers normally when running Mac OS X until Microsoft released the carbonized version of Office X in mid-November of 2001. In a similar vein, the Classic version of Eudora is still being widely used in Mac OS X while Qualcomm works on the Carbon beta of Eudora (recent releases of which have improved significantly).
<http://www.microsoft.com/mac/office/>
<http://www.microsoft.com/mac/officex/>
<http://www.eudora.com/betas/>
Because the Classic APIs are based on Mac OS 9, Classic programs can't take full advantage of Mac OS X's new capabilities. In addition, since Classic works by running an entire copy of Mac OS 9 inside Mac OS X, there is a great deal of duplication - some of which is managed well, and some of which isn't. For example, you can connect to file servers through the Classic Chooser, or through the Carbon Finder. Either way, file servers are available to both Classic and Carbon programs, but they show up in different places depending on how you are navigating. The Carbon Finder shows them on the desktop, or under the Computer top-level folder; old Open/Save dialogs and Navigation Services show them at the top level, but lack a Computer container; in Terminal and Unix-based programs, they're under the top-level Volumes folder.
To run Classic programs, it's first necessary to "boot" Mac OS 9, which adds significant startup time for the first Classic program launch; Classic can then stay running until logout or restart, but a Classic crash can still bring down all Classic programs (only Carbon and Cocoa programs gain the benefits of the new protected memory model). Additionally, since there are separate clipboards for Classic/Carbon applications and Cocoa applications, there is a brief delay before synchronizing them, so it's possible to copy from a Classic program and then paste the wrong thing in Cocoa program, or vice-versa.
Carbon -- Carbonized programs running under Mac OS X are more interesting, because they automatically take advantage of improvements introduced with Mac OS X with less effort than a complete rewrite in Cocoa. Some of the major changes are implicit and automatic for all Carbon programs - such as improved memory management and live window dragging. (Taking advantage of other changes in Mac OS X requires explicit support that must be added to any application that's ported to Carbon.) In addition, Apple is now putting essentially all of their operating system development effort into Mac OS X, so the benefits of Apple's ongoing development work have shifted from Mac OS 9 (which is now being revised primarily to support Mac OS X better) over to the new platform. Mac OS X is rapidly getting better, and these improvements are focused on Carbon and Cocoa applications.
<http://developer.apple.com/carbon/>
Once developers have carbonized their Classic programs and become familiar with the new environment, we'll see a resumption of the normal process of development and improvement, instead of the current stage where existing applications are moving to Carbon, but not acquiring many new features. Developers are starting to cease work on their Classic programs and shift attention to Carbon and Mac OS X. The rate at which this transition occurs is important to Apple - if it's too slow, people will continue to use Mac OS 9 for "real work" and consider Mac OS X a toy. As key developers gradually cease Mac OS 9 development, as Microsoft has done, pressure to upgrade will grow stronger.
Distinguishing Carbon programs from their Classic counterparts is made easy by the different window interfaces. Classic programs use the old 2D Platinum appearance (rectangular windows, grey borders, zoom boxes in the upper right), while Carbon (and Cocoa) programs use the Aqua interface, with rounded edges, drop shadows, 3D style buttons, and the colored close, minimize, and zoom buttons in the upper left.
The improvements in Mac OS X open up new possibilities for Mac applications. Most Carbon programs are currently just prettier versions of Classic programs, but Apple doesn't draw attention to that. After attaining feature completeness in Carbon, developers start introducing new features unique to Mac OS X. This was the case, for example, with Interarchy 4.1 and BBEdit 6.1 - both programs merely attained Carbon parity with an existing Classic version. Then came Interarchy 5, which offered OpenSSH encryption for FTP transfers thanks to Mac OS X, and BBEdit 6.5, which included better integration with external programming tools, a Unix shell worksheet window, and a tool for controlling BBEdit from the command line. Because Mac OS X is so rich in new APIs, it offers tremendous opportunities for growth.
<http://www.interarchy.com/>
<http://www.barebones.com/products/bbedit.html>
<http://www.openssh.org/>
Looking beyond the immediate need to migrate programs, Apple is attempting to make Carbon a superior platform for developing new applications, as illustrated by changes in the underlying way the system handles events such as mouse clicks, keystrokes, window drags, and so on. The way Classic programs work is that they run in a tight loop, waiting for the user to do something. During that time, they also voluntarily cede processor cycles to other applications. Even though a Classic application may not be doing anything, it's still wasting processor cycles waiting for events.
In contrast, Carbon applications in Mac OS X can take advantage of a different approach to handling events, called Carbon Events (the same approach Cocoa applications use). With Carbon Events, programs register with the operating system the types of events they will react to and how they will respond to these events. When such an event occurs, the system triggers the right application response, but if nothing relevant happens, the program doesn't consume any processing time. The idea is that this will make programming simpler, since the programmer only has to deal with the specific stimuli they're interested in, and also make the system faster since it will only give programs processor cycles when they have something to do.
<http://developer.apple.com/techpubs/macosx/ Essentials/Performance/Carbon/Carbon_and __OS_X_Events.html>
Cocoa -- After Steve Jobs left Apple, he founded NeXT, which built computers that resembled Apple prototypes - cutting-edge hardware, with many of the same technologies as Macs (Motorola processors, PostScript, etc.). To match this advanced hardware, NeXT developed the NeXTstep software, which was essentially three things, a Unix-based operating system, a windowing system based on Adobe's Display PostScript, and a programming API that enabled the fast development of graphical applications. That API has evolved over the years, becoming OpenStep when NeXT gave up on the hardware business, and then Cocoa when Apple acquired NeXT.
So Cocoa was mature well before it was integrated into Mac OS X, while Carbon was designed and written at Apple starting in the early phases of Mac OS X development. For this reason, Cocoa applications from NeXT developers like The Omni Group and Stone Design had a considerable head start over their Carbon counterparts. As Apple has fleshed out the Carbon environment in Mac OS X 10.0 and 10.1, Carbon and its applications have reached a kind of parity with Cocoa, but each has strengths and weaknesses. Cocoa applications require significantly less work on the programmer's part because of everything Cocoa provides, but writing a Carbon application is a more familiar process for a Macintosh developer. Plus, there are some things Macintosh programmers expect to be able to do that are possible only in Carbon. As Apple continues to work on both, the differences between programs written in either environment will decrease.
<http://www.omnigroup.com/>
<http://www.stone.com/>
It's increasingly difficult to tell the difference between Carbon and Cocoa applications, both of which use the same Aqua appearance, but here are some clues. If it's relatively small, uses drawers (like Mail), has a Font panel for selecting fonts, it's almost certainly a Cocoa application. Another minor distinction that exists currently is the difference between the way Carbon and Cocoa applications let the user navigate Open and Save dialogs (for more on the discrepancies see "Apple's Dirty Little Secret" in TidBITS-601). Apple is wisely trying to iron out the remaining discrepancies in application behavior. In the long run, it shouldn't matter to an end user if an application has an object-oriented NeXT heritage or the Classic Mac OS in its ancestry, although Cocoa applications will always be significantly smaller than Carbon applications, given that so much of the necessary code for a Cocoa application is built into Mac OS X.
<http://db.tidbits.com/article/06594>
Not Your Father's Mac -- As of this writing, Classic is still essential to Mac OS X, since there are many Classic applications without carbonized versions or Cocoa equivalents available. As developers release Carbon and Cocoa programs, Classic will become a vestige of Mac OS history. Already, major software releases for the Mac OS - with the Classic-only QuarkXPress 5.0 being a notable exception - are generally Carbon apps, due to large existing code bases and lack of familiarity with Cocoa. But NeXTstep/Cocoa developers have another opportunity to demonstrate the advantages of their favorite programming environment, and they're hoping to woo existing Mac developers over to Cocoa, which provides all the advantages of Mac OS X for far less effort than writing a new Carbon application.
Mac OS X goes beyond Classic, Carbon, Cocoa, with support for native Unix and Java programs as well. Macintosh development in those environments is just getting started, but as developers previously unfamiliar with the Mac discover what's possible in Mac OS X, Apple's best-of-both-worlds operating system is garnering increasing attention. Part two of this article will take a look at these developments.
[Chris Pepper is a Unix System Administrator in New York City. He's amused and somewhat surprised that Mac OS X has turned out to be such a great management workstation for the Unix systems he works with. Chris is involved in various documentation efforts, including those for Interarchy and the Apache Group.]
<http://www.reppep.com/~pepper/>
