- The Layers of Mac OS X: Aqua
- The Layers of Mac OS X: Application Environments
- The Layers of Mac OS X: Graphics Services
- The Layers of Mac OS X: Darwin
- Domains: An Overview
- The Libraries of Mac OS X: /System/Library
- The Libraries of Mac OS X: /Library
- The Libraries of Mac OS X: /Users/"Home"/Library
- Fonts in Mac OS X: Font Formats
- Fonts in Mac OS X: Working with Fonts
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Layers of Mac OS X: Application Environments
The main thing you do when you are in Aqua is use applications. On the surface, almost all applications in Mac OS X appear to function in a similar way: You launch them; you use commands from their menus; you quit them. Mac OS X has some fundamentally different types of applications, however. As a troubleshooter, you need to understand these categories.
Cocoa
The Cocoa environment is unique to Mac OS X—that is, software developed via Cocoa uses Mac OS X-only programming tools, and the finished application runs only in Mac OS X. The advantage of Cocoa-based software is that it potentially can take advantage of every feature built in to Mac OS X. The TextEdit application that comes with Mac OS X is an excellent example of such an application. Its Font Panel window, its spelling checker, and its capability to access Services from the Services command in the TextEdit menu are all, at least in part, due to the fact that TextEdit is a Cocoa-based application. Other types of applications will not be have such features or will be much less likely to include them. In non-Cocoa applications, items in the Services menu are likely to be dimmed and unselectable; they will have a Fonts menu instead of a Font panel, and so on.
Apple probably hopes that down the road, almost all Mac OS X applications will be Cocoa-based. But for now, they are relatively uncommon, because writing a Cocoa-based application means pretty much starting from scratch. If you already have written a Mac OS 9 application that you now want to get to work in Mac OS X, Cocoa would not be the fastest way to go.
Carbon
Applications written for the Carbon environment also run in Mac OS X. In most cases, a user would be hard-pressed to tell whether a particular application is Cocoa-based or Carbon-based. Carbon-based (or Carbonized) applications can offer all the basic Aqua features that you expect to find in Mac OS X, such as the look and feel of its windows. You cannot look at an application in the Finder and see quickly whether it is a Cocoa or a Carbon application.
To some extent, however, when a developer Carbonizes an application, he can decide how much of the Aqua interface features to support. As a result, some Carbon applications may look and feel more like Mac OS X applications than others do.
Carbon exists for two main reasons. First, it reduces the development time needed for rewriting existing Mac OS 9 applications to work in Mac OS X. That's why major Mac OS 9 applications, such as AppleWorks and Microsoft Office, are Carbonized applications rather than Cocoa ones. Second, some developers find it preferable even when they're starting from scratch. REALbasic, for example, is a programming language that creates Carbonized applications for Mac OS X.
Making matters a bit more complicated, Carbon applications have two distinct subcategories. Their difference depends on an OS feature called a library manager. Library managers are special programs that prepare other, more "ordinary" programs to be run. Library managers exist in both Mac OS 9 and Mac OS X. Carbon applications in Mac OS X can use two different types of library managers. Bear with me as I introduce some esoteric jargon:
CFM (code fragment manager) is essentially the same as the CFM used in Mac OS 9. It works with an application's executable binary code, which is in a format called PEF (for Preferred Executable Format). Unfortunately, this format is not preferred in Mac OS X.
Dyld (dynamic link editor) is the manager that only Mac OS X uses. It works with an executable binary-code format called Mach-O. Mach-O format is what Mac OS X's kernel uses; it is derived from Unix.
Exactly what all these managers and formats do, and how they differ, need not concern you. What does matter is the following:
CFM is not optimized for Mac OS X. Mac OS X is a native dyld platform. This means that for CFM-based programs to work, they must bridge to the dyld platform via Carbon routines. This bridging step takes time, resulting in a performance penalty that dyld-based software does not have—that is, CFM-based software will not run as fast in Mac OS X as the same program would if it had been written to use dyld instead.
The most visible sign of this bridging is the LaunchCFMApp application. The file itself is located in /System/Library/Frameworks/Carbon.framework/ Versions/A/Support/LaunchCFMApp. More important, this file (which is an updated version of the Mac OS 9 Code Fragment Manager) is used every time you launch a CFM-based application. In fact, if you launch ProcessViewer and look at the list of open applications in User Processes, you won't see any of the CFM-based applications by name. Instead, you will see multiple instances of LaunchCFMApp . This intermediary causes the performance hit for CFM-based applications. LaunchCFMApp is itself a Mach-O program.
Figure
4.1 LaunchCFM App items in Process Viewer.
Also, CFM applications, although they can be packages, may still use the single file format common in Mac OS 9. Thus, if you open the contextual menu for an application and no Show Package Contents command is listed, the application is almost certainly a CFM application. Dyld software will always use the preferred package format.
SEE
"Technically Speaking: Understanding Packages," in Chapter 2.
Dyld (Mach-O) software cannot run in Mac OS 9. So why bother with CFM at all? Two reasons. First, it may be easier to convert an existing Mac OS 9 application to its CFM-based cousin than to a dyld one. Second, CFM-based programs can run equally well in Mac OS 9 and Mac OS X. Thus, you need only one application for both environments. Dyld-based software runs only in Mac OS X. By the way, Cocoa-based software also uses Mach-O.
For those who want a dyld-based Carbon program to run in Mac OS 9 and Mac OS X, a solution is to create two versions of the application, a CFM version and a dyld version. These versions can be combined into an application package that appears as a single file in the Finder. When the application is launched in Mac OS 9, however, the CFM version will be used; in Mac OS X, the dyld version will run. This situation allows the optimized version for each OS to be used with its respective OS. Actually, this type of division is more common with Classic and Carbon software versions in the same package, as described a bit later in this chapter.
)
Figure
4.1 When a program is said to be a native Mac OS X program, this generally means that it is either a Cocoa program or a dyld Carbon one (although some people consider any Carbon application to be native).
TAKE NOTE
Faceless Applications; Hidden Applications
Some applications run without an icon in the Dock or without being listed in the Force Quit window. Such applications are often called faceless applications, as they run without any user interface. The log-in window application, discussed in Chapter 5, is an example.
You can also simulate the effect of a true faceless application by setting it to launch at log in (via choosing it in the Login Items list in the Login System Preferences window, and checking the Hide checkbox). Installers for some applications automatically set up software this way. iTunes does this with the iTunes Helper application (which is actually located within the iTunes package).
Be careful when you hide an item in the list. You might lose its functionality. When I chose to hide items that created menus in the menu bar, for example, the menus no longer appeared.
This Login Items type of hiding is separate from hiding the windows of open applications, as you can do by holding down the Command and Option keys when clicking an application icon in the Dock. This technique hides the windows of all open applications except the one you clicked. Shareware utilities such as ASM, which mimics the Mac OS 9 Application menu, offer similar window-hiding options.
SEE
"Take Note: Dock and Finder Shortcuts," in Chapter 3, for more details.
)
Figure
4.2 Note the Hide checkboxes in the Login Items list.
TAKE NOTE
Identifying Application Formats
Suppose that you needed to know whether a given application is Cocoa, Carbon-cfm, Carbon-dlyd, or Classic. What's the fastest way to find out? A utility called Get Info for App works great—if it works (in the most recent versions of Mac OS X it kept crashing on me). Just drag the application in question to the Get Info for App icon, and a window will open that shows you what you want to know.
For TextEdit, for example, you will see that the Framework is Cocoa and the Binary Kind is Mach-O.
On the other hand, if you select Internet Explorer, the window will say Carbon for the Framework and CFM for the Binary Kind.
As an alternative, you can use the ever-handy XRay. It does not distinguish between CFM vs. Mach-O, but it does distinguish between Cocoa, Carbon, and Classic applications.
)
Figure
4.3 Three applications as listed in XRay. Note the Kind line distinction of
Cocoa, Carbon, and Classic 68K.
Classic
Mac OS 9 programs that have not been Carbonized can still run in Mac OS X, but this capability requires a special trick. Mac OS X needs to launch what is called the Classic environment. I discuss this topic in detail in Chapter 9. For now, here's a brief summary of what happens. When you launch Classic, a working version of Mac OS 9 (including extensions and control panels) is loaded. The Mac OS 9 application then runs in this environment. In many ways, going back and forth between the two environments is almost seamless. You can cut and paste from a Classic program to a Mac OS X one, for example. Classic can even borrow your Mac OS X Internet and printer settings, so Classic applications can maintain access to the Web and to your connected printers.
Still, running a program in Classic has a huge disadvantage: You are not really using Mac OS X and thus get almost none of the advantages of running Mac OS X. Running an application in Classic is pretty much like running it in Mac OS 9, and maybe even a bit worse; it will likely run slower and have more potential conflicts than if you booted from Mac OS 9. The sole advantage of Classic is that it allows you to run Mac OS 9 programs that otherwise would not run in Mac OS X. As time goes by, however, you will want to find Mac OS X alternatives to these applications (or hope that Mac OS X versions of them get released) so that you can reduce your use of Classic to zero.
SEE
Chapter 9 for more information on the Classic environment.
Java
Mac OS X can run programs written in Java. Most users, if they are familiar with Java at all, think of it as being something used by certain Web sites and accessed from your Web browser. But Java software can be created to run independently of a browser. and Mac OS X is set to do this. Apple has even provided a means for developers to incorporate Mac OS X's Aqua interface into Java code so that a Java application can have the look and feel of a typical Mac OS X application. The main advantage to Java, for the programmer, is that Java is platform-independent. The same Java software (with some minor modifications to accommodate the platform's user interface) can run on any computer that supports the use of Java, including a Windows PC. At present, few Java applications are available for Mac OS X. The jury is still out as to whether Java will someday play a significant role in Mac OS X.
Putting it together
All these application environments are unified within the Aqua interface. There are signs—some subtle, some obvious—that occur when you shift from Classic to Carbon to Cocoa to Java applications. Still, one of the great successes of Mac OS X is that you can accomplish these switches almost effortlessly. And at least most of the time, it all works as Apple intended.
One other type of application that can run in Mac OS X: Unix software. I discuss it in "Darwin" later in this chapter.