What is Mac OS X DP4?

Mac OS X DP4 is the fourth "Developer Preview" release of Mac OS X (pronounced "ten", not "ex"), Apple's upcoming next generation operating system. See the previous three articles in this series for more information:

• Mac OS X DP2: A Preview 12/14/1999
• Mac OS X Update: Quartz & Aqua 1/17/2000
• Mac OS X DP3: Trial by Water 2/28/2000

Mac OS X DP4 was released on May 15th at Apple's Worldwide Developer Conference. It is the second developer release to include the Aqua user interface. As usual, I'll begin this article with an exploration of some of the core technologies in DP4 before moving on to the (increasingly depressing) gooey bits. (Note that some of the technical features covered in this article have been in Mac OS X since earlier releases but were not included in previous articles due to a lack of documentation and/or space and time constraints.) The later discussion of the GUI and user experience, will focus on new features of DP4 and the differences between DP4 and earlier releases.

NOTE WELL: This article deals with Mac OS X Developer Preview 4, NOT Mac OS X. Mac OS X DP4 is a work in progress, not a finished product. You will never find Mac OS X DP4 on a store shelf. It will never come pre-installed on your computer. Unless you are a developer, you will never use it at all. Any and all features present in DP4 are subject to change before release.

The diagrams in this article are all taken from Apple's excellent developer documentation and are copyright © 2000 Apple Computer, Inc.

Bundles Revisited

Mac OS X Bundles were first covered in my DP2 review and were revisited in the DP3 article. Briefly, a bundle is a directory in the file system that stores executable code and resources related to that code. Bundles are designed to encapsulate related software resources in a way that facilitates installation, localization, and cross-platform distribution. (Note that Bundles may also contain other Bundles.) See the Apple's documentation on the benefits of Bundles (as quoted in my previous article) for more information.

Earlier confusion regarding naming conventions has been resolved with the release of DP4. "Bundle" is the generic name. The three main "subspecies" of Bundles are Application Packages, Frameworks, and Loadable Bundles.

Application Packages

Application Packages were covered in earlier articles. They are named with a .app extension and appear as a single item in the high-level UI (rather than appearing as a structured directory of files, which is what they really are.) The details of the internal structure of Application Packages have changed since I last covered them (directories have been moved and renamed, mostly) but the concepts remain the same.

Frameworks

Frameworks are Bundles that encapsulate dynamic shared libraries and all their associated resources. They are named with a .framework extension. Dynamic shared libraries are similar to what you may know as .DLL, .so, or .a files, depending on your OS. They are files containing executable code that may be used by one or more application simultaneously. Here's a simplified example. Let's say a shared library contains code for parsing XML, and that code is exposed through a function called parse_xml(). Any application that wants to parse XML can link to this shared library and call this function. This saves the application programmer time and effort, of course, but the tricky bit is that only one copy of this code needs to be in memory no matter how many applications are using it.

Shared libraries are not new. They exist on every major OS (yes, even classic Mac OS). But Mac OS X adds a few (mostly NeXT-derived) twists, as usual. The first wrinkle is that the use of shared libraries in Mac OS X involves what is called "lazy linking." What this means is that the code required to execute our hypothetical parse_xml() function is not retrieved until that function is actually called at some point during program execution.

When an application is built, the name of the Framework containing the shared library that defines parse_xml() is stored inside the application executable. When the code is needed, that library (or a suitable equivalent--more on that later) is found and the code is loaded into memory (unless another application is already using it, in which case it's already there), linked, and executed. If the required library (or equivalent) is not found, a runtime error occurs and the application explains that a required library could not be found and (most likely) quits.

This "lazy linking" behavior is different from both static linking and many other implementations of dynamic linking. Static linking compiles the linked code directly into the application executable itself. This means that it will never be without its required code, but it also means that the code cannot be shared by other applications. Other forms of dynamic linking try to resolve all linked library functions at application launch time rather than waiting for each function to be called. Such applications know whether or not they have all the required functions from the start, but have the disadvantage of linking and loading all such functions even if they are never used during execution. And linking functions at application launch time does not guarantee a lack of runtime errors since the shared library that was linked may not be the correct version and might still cause a runtime error. (Frameworks address this problem as well. More later.)

The dynamic linker in Mac OS X takes another step towards "laziness" by allowing each shared library file to contain sub-modules, each of which may be loaded separately. In other words, once the exact file containing the exact function an application needs is located, the entire file does not needs to be loaded into memory. Instead, only the sub-module containing the required function is loaded. This is another memory saving device. It is especially effective when dealing with very large shared library files. The diagram below illustrates this concept:

Lazy linking of dynamic shared library modules (click for larger version)

Here we see a single shared library file within the Boffo Framework that contains three separate modules of executable code, a.o, b.o, and c.o, each of which contains a single function. The MyApp application contains calls to all three of those functions, but they are only linked when they code that calls them is actually executed. For example, the function c() may not be called at all during the application's lifetime if the if(!n) conditional never evaluates to true. And even though all three functions are defined within the same shared library file, the entire file is not linked into MyApp when the function a() is called. Instead, only the specific library module that contains a() is linked.

As mentioned earlier, all of this clever resource management doesn't help if the particular shared library you use ends up containing an incompatible version of the functions you need. We've all seen this happen, for example, when an impolite installer overwrites an existing shared library with an older (or newer!) version of that library that breaks applications that used the previously installed version. Or worse, the newly installed library may present the same functional interface (allowing it to be successfully linked) but behave in a subtly different manner. Bugs like this are among the most difficult to track down.

Frameworks solve this problem by encapsulating one or more versions of a shared library in structured directories. Framework versioning is split by the concept of Major and Minor versions. A new Major version is required when making a change to a library that renders it incompatible with applications that work with older versions. Examples of incompatible changes that require a new Major version are: removing or renaming a function, adding or reordering instance variables, or adding functions in languages like C++. (Functions can be added in more dynamic languages like Objective C without causing any incompatibility.)

Each Minor version of a library remains compatible with all other Minor versions within the same Major version. Minor version changes include bug fixes, performance enhancements that do not affect functional structure, and the addition of methods (except in C++), classes, and structures.

Traditionally, Major versions have been named with a single capital letters of the alphabet, but they may be any string that is also a valid directory name: "2.0", "Two", and so on. Major versions of a shared library file are stored in their own directories within the Framework. When an application is compiled, the path to the Major version of each Framework is stored within the executable. When an app needs a function defined in a Framework during execution, it searches for the required version of that Framework, checking the path stored during compile time first, and then traversing a standard search path if that fails. The standard locations for Frameworks include:

• /System/Library/Frameworks - Frameworks included with the operating system.
• ~/Library/Frameworks - Frameworks that are only used by a single user.
• /Local/Library/Frameworks - Frameworks used by all users of a particular machine.
• /Network/Library/Frameworks - Frameworks used across a network.

(This type of search path should look familiar to those of you who read the DP3 article.)

Since each Framework can contain more than one Major version of a shared library, upgrading a Framework to a new Major version does not break old applications; the older versions of the library are still contained within their respective Major version subdirectories inside the Framework Bundle.

Individual apps may also contain Frameworks within their Application Package. These may be private Frameworks used only by the application itself, or shared Frameworks that can be used by any application on the system. Shared Frameworks may be contained within Application Packages instead of in one of the system-wide locations in order to preserve the "single item" simplicity of Application Packages. These shared Frameworks are tracked by the OS and are just as readily available to other applications as the Frameworks installed in the system-wide locations.

When an application attempts to load a Framework, the OS ensures that the most recent Minor version of that Framework is loaded, regardless of where it is located: in the app's own Application Package, in a system-wide directory, or in another app's Application Package. In this way, an application may be self-sufficient while still taking advantages of system-wide upgrades (or even upgrades to other applications).

Frameworks don't just contain shared libraries, they also encapsulate everything associated with that library: documentation, header files, resource files, and so on. Again, this a maintenance win for Bundles in general. Frameworks enjoy the same "single item" install/remove process as Application Packages. Contrast this with, say, the traditional Unix shared library installation which puts the library file(s) in one place (/lib, /usr/lib, /usr/local/lib, etc.), the header files in another (/include, /usr/include, /usr/local/include, etc.), and the documentation in yet another location (/usr/man/man3, /usr/man/man3c++, etc.)—hardly a system that facilitates ease of maintenance!

And since the Framework Bundles themselves are stored in a series of standard locations, they are still easy to locate. Mac OS X tracks the location and version of all Frameworks installed on the system (or available via the network) in a centralized registry. Like classic Mac OS's Desktop database, this registry is built from (and can be easily rebuilt from) information available inside the Framework Bundles themselves.

Let's take a look at an actual Framework from Mac OS X DP4, the oft-maligned Human Interface Toolbox stored in /System/Library/Frameworks

HIToolbox.framework/
    HIToolbox  -> Versions/Current/HIToolbox
    Headers/   -> Versions/Current/Headers
    Resources/ -> Versions/Current/Resources
    Versions/
        Current/ -> A
        A/
            Headers/
                Controls.h
                Dialogs.h
                ...
          HIToolbox
          Resources/
              hltb.rsrc
              Extras.rsrc
              Info.plist

The files and directories with arrows after their names are symbolic links to the path that follows the arrow. These symbolic links enable an application to easily locate the most recent version of a Framework, and expose the subdirectories of that Framework on the top level of the Framework Bundle.

HIToolbox is the actual (4.5MB) shared library file (which is no doubt subdivided into many library modules, each of which defines many functions, structures, classes, and methods.) The Resources directory contains an XML property list file (Info.plist) and two resource files, including the now-infamous Extras.rsrc which contains most of the graphics and interface layout parameters that define the look of the Aqua UI.

(And yes, you can still move or rename Extras.rsrc in DP4 and end up with a somewhat spotty approximation of the old platinum interface. No, I'm not going to screenshot it again. Yes, this means that themes will be possible. No, this does not mean that Apple will release the specs for such theme files.)

Loadable Bundles

Loadable Bundles are Bundles that can be loaded at any time by an application. They may have any extension. Unlike Frameworks, Loadable Bundles do not have to be linked (or even exist) at compile time. You can think of Loadable Bundles as Mac OS X's answer to "plug-ins." Loadable Bundles are organized and stored very much like Frameworks, but must be explicitly loaded by an application. Furthermore, it is the application's responsibility to provide a UI through which the user can load such bundles.

Let's take a hypothetical Mac OS X version of Photoshop as an example. On launch, it might load all the plug-ins (each a Loadable Bundle) from within its Application Package (remember that Bundles can contain other Bundles). While running, it may also provide a dialog box or palette through which users can explicitly load plug-ins located anywhere on the system (or network.) Using that UI to load plug-ins may actually move those Loadable Bundles into the Application Package itself. Since Application Packages appear as a single file to the high level UI, applications are required to provide a user interface for Loadable Bundle management.

Loadable Bundles also fill some of the role of classic Mac OS Extensions. Kernel Extensions in Mac OS X ("KEXTs") are a type of Loadable Bundle that is recognized and loaded by the OS. Unlike classic Mac OS Extensions, Kernel Extensions can be loaded and unloaded without requiring a restart.

Umbrella Frameworks

Let's look at one last (I promise!) Bundle-related topic: Umbrella Frameworks. As the name implies, Umbrella Frameworks are Frameworks that encapsulate (via tree of symbolic links within their Framework Bundles) several subframeworks. Umbrella Frameworks in Mac OS X are used to define each major application environment. They provide a layer of abstraction between what outside developers link their programs with and what Mac OS X uses for its internal implementation. Developers are actually forcibly restricted from linking directly to a subframework. And you may be surprised to find what is defined as a subframework in Mac OS X. Quartz, Open Transport, and Core Foundation are a few examples.

Each subframework may be included in more than one Umbrella Framework, and Umbrella Frameworks may themselves contain other Umbrella Frameworks. For example, the Carbon Umbrella Framework contains the Core Services Umbrella Framework which contains the Core Foundation Framework. A developer creating a Carbon application only needs to #include <Carbon.h>. Trying to #include <CoreFoundation/CFString.h> would result in an error message explaining that Core Foundation is a subframework and should be linked to via an Umbrella Framework instead.

This system provides Apple with a lot of implementation flexibility. The multiple-version nature of Frameworks provides backwards compatibility, and everything but the Umbrella Frameworks themselves can be moved, renamed, and re-implemented without affecting existing applications.

Bundle Wrap-up

Most of what people think of as "Mac OS X" is some kind of Bundle, usually a Framework. Most of those blocks in the block diagrams in previous articles correspond to a Framework of some kind. Even the APIs through which developers access and manipulate Frameworks (and other types of Bundles) are themselves contained in a Framework. All those Frameworks are what make Mac OS X so different from other Unix-like operating systems, including Apple's own Darwin project. Indeed, Mac OS X is essentially "Darwin plus a huge pile of Frameworks" (and applications built on those Frameworks).

As promised, I'll now move on to another topics. Of course, Bundles are hard to avoid in Mac OS X. The next section deals with the details of a Bundle (a Framework, specifically) that we've visited before: Quartz.

Inside Quartz

Quartz was first covered in an earlier article. To review, in summary, straight from Apple's developer documentation:

Quartz is a powerful new graphics system that delivers a rich imaging model, on-the-fly rendering, anti-aliasing, and compositing of PostScript graphics. Quartz also implements the windowing system for Mac OS X and provides low-level services such as event handling and cursor management. It also offers facilities for rendering and printing that uses PDF as an internal model for graphics representation.

Quartz has two components, Core Graphics Services and Core Graphics Rendering.

Core Graphics Services: Events and Compositing

Core Graphics Services is the lower-level component of Quartz and is largely implemented inside the Core Graphics Framework. It has two main responsibilities:

• Event routing
• Composing and displaying on-screen elements

The diagram below shows the anatomy of the Core Graphics Framework:

The Core Graphics Framework

Core Graphics Services provides a lightweight window server that supports basic windowing functions and event-routing for all GUI applications. Event routing means tracking user input (mouse clicks, cursor movement, typing, etc.) and sending those events to the correct applications (i.e. the one beneath the cursor during a mouse click, or the front-most app when a keyboard shortcut is typed.)

The window server is "lightweight" in that it does no screen drawing itself. It is, to use Apple's term, "drawing model agnostic."

The window server plugs into Core Graphics Services' (currently private) system programming interfaces (SPIs) and leverages lower level services provided by the I/O Kit Framework to access frame buffers and i/o devices (the source of user events).

Core Graphics Services provides device-independent color and pixel depth, layered compositing, buffering, and includes hooks for remote display. It is responsible for coordinating the composition of overlapping windows and other elements on the screen. It does so by modeling the screen as a layered compositing engine much like the layers in Photoshop 3.0 and later. While traditional windowing systems (such as X) define every pixel on the screen as belonging to a single application at any given time, Core Graphics Services models each pixel on the screen as a composite of all applications that have drawn something to that pixel. Transparency effects are therefore possible by simply varying the relative "weight" of each pixel being composited into the final result.

(Note: it is important to understand that Core Graphics Services deals with more or less "ready-to-display" data sent to it from higher layers in the graphics system. It is a pixel pusher, not a graphics creator.)

The diagram below is a higher level look at the Mac OS X graphics and windowing system, with Core Graphics Services as the bottom layer. The "Applications and Application environments" in the previous diagram include the three white boxes in the diagram below: QuickDraw, QuickTime, and OpenGL. All three of those technologies are built on top of (are "clients of") Core Graphics Services.

Mac OS X graphics and windowing environment

Core Graphics Rendering: Drawing with Vectors

Core Graphics Rendering is also a client of Core Graphics Services. It contains common functionality that QuickDraw, QuickTime, and OpenGL all leverage. Core Graphics Rendering is, to quote Apple, "a graphics library with a vector flavor." It provides APIs for the creation of graphics via a sequence of commands and mathematical statements that place lines, shapes, color, shading, translucency, and other graphical attributes in two-dimensional space without requiring applications to specify the attributes of individual pixels. This is where much of the third generation display layer magic happens.

Core Graphics Rendering translates this vector information into pixel values before passing it to Core Graphics Services for compositing onto the screen. This vector-to-pixel translation uses a flexible coordinate system made up of arbitrary units (inches, centimeters, etc.) and is based on the floating-point coordinate values defined by the vectors.

Core Graphics Rendering uses PDF for its internal vector graphics representation. Apple describes its rationale for using PDF as follows:

As a superset of Adobe PostScript, PDF brings several improvements, including better color management, internal compression, font independence, and interactivity. However, PDF is not a full-fledged language as is PostScript; it is declaratively, not programmatically, specified. Consequently a sophisticated and expensive language runtime is not necessary, as it is for PostScript.

(Note that licensing fees are not mentioned, most likely because such business concerns are not very relevant to developers since Apple would be paying the fees, not them.)

Apple describes Core Graphics Rendering as a "black box" that converts input to PDF and then converts the PDF to various output formats. The diagram below illustrates:

Core Graphics Rendering: The PDF Black Box

The inputs for Core Graphics Rendering include PDF files, Core Graphics Rendering's own native C API, and QuickDraw. QuickTime and OpenGL also leverage Core Graphics Rendering, but to a lesser extent since those two technologies implement their own versions of certain two-dimensional graphics capabilities. The final input arrow is simply labelled "inputs." Apple explains it by stating that future APIs in the front end may be supported.

I don't know about you, but one word immediately springs to mind: DirectX. Well, obviously only the portions of DirextX that deal with screen drawing, but it's clear that Apple has designed Mac OS X's graphics subsystem to be as flexible as possible. And with QuickDraw, QuickTime, and OpenGL already implemented, I'm hard-pressed to name another API (other than X, which is already in the busy hands of Darwin hackers) that would be implemented in the future. This is pure speculation at this point, of course, but if it does come to pass, remember that you heard it here first.

The output arrows include screen rendering (i.e passing pixel values to Core Graphics Services for compositing onto the screen), PDF, PostScript, and raster data. Which subsystems are interested in those outputs? Screen rendering is a no-bainer, and PDF could be used to create a PDF file, but the last two (PostScript and raster data) lead us into the next topic...

The Mac OS X Printing System

The Mac OS X printing system's relationship with its graphics system is perhaps its most important feature. As described in the previous section, the only difference between screen drawing and printing is the choice of the output from Core Graphics Rendering. What this means is that anything drawn to the screen can be printed using exactly the same commands. This is a huge win for WYSIWYG printing. And since any input to Core Graphics Rendering can be converted (via the intermediary format of PDF) to any output, any type of graphic can be printed to any kind of printer—raster graphics to a PostScript printer, PDF graphics to a raster printer, etc.—all without any special code in the application.

The Mac OS X Printing System is quite a beast, as the large block diagram below illustrates. It is extensively modularized and presents users, developers, and printer manufacturers with a much cleaner interface than is available in classic Mac OS. Let's go through this diagram step by step:

The Mac OS X Printing System (click to enlarge)

The user is at the top with arrows pointing to the two aspects of printing that he can control. The first is the Print Center. The Print Center is the GUI through which the user configures printers and manages print jobs. The first step in printing is to set up one or more printers. Print Center compiles a list of all available printers, both local and on the network. It supports plug-in Printer Browser Modules (you guessed it, Loadable Bundles) that may modify the Print Center UI to support new printer connection types (i.e. SCSI or FireWire).

Once one or more printers are set up, the user can print a document via an application. The application uses the Print Job Creator to present the print dialog box. The Print Job Creator supports its own set of plug-in modules that may modify the UI of the print (or page setup) dialog box. The solid black line in the diagram represents the Print Job Ticket. This ticket tracks the status of the print job and is updated by each component it encounters during the printing process.

The next step is the Queue Manager. Once the job reaches the Queue Manager, all status updates and errors associated with the job are reported asynchronously back to the Print Center. The Queue Manager then passes the job to the Job Manager.

The Job Manager consults the job ticket to determine the destination printer and queries the destination printer's associated Printer Module to find out what data format it requires. If necessary, the Job Manager uses a converter to transform the incoming data into a format that the destination printer module can accept. As we've already seen, Core Graphics Rendering provides just such facilities.

The print job is then passed to the Printer Module which converts the incoming data into the raw commands for the printer. Printer Modules are provided by printer vendors and are analogous to a simplified version today's classic Mac OS printer drivers. They handle all printer-specific exceptions (out of paper, paper jam, etc.) but are "simplified" in that they do not have to concern themselves with the low-level operations performed by other modules in Mac OS X (i.e. the I/O module or the Converter) or high-level operations like presenting or modifying the print and page setup dialog boxes (handled by the Print Job Creator and its associated Printer Dialog Extension modules).

Finally, The Printer Module passes the job back to the Job Manager which then passes the printer-specific data from the Printer Module to the actual printer using the appropriate I/O module. There is an I/O module for each type of connection: USB, TCP/IP, AppleTalk, etc.

It's not really all that complex if you take the time to trace an imaginary print job through the diagram a few times. And it's certainly a welcome change from the classic Mac OS printing architecture in which both application developers and vendor printer drivers are responsible for a much greater portion of the printing process, and where the user is forced to wade through several different UIs: the Chooser, Desktop Printers, Print Monitor, and so on.

Aqua Revisited

Congratulations, you've made it through the technical portion of the article and into the swimsuit competition. But before I start with the screenshots and the blow-by-blow feature analysis, I'd like to take a step back and examine the reasoning behind Aqua. I feel this is important because I don't want people to get the impression that by highlighting Aqua's faults I'm denying its merits—or, at the very least, the merits of the motivation behind its features.

(Note: Obviously I don't speak for Apple, and I have no inside information on the genesis of Aqua. The following is simply my analysis based on my experience with Aqua, classic Mac OS, and the public statements that Apple has made regarding both.)

Problems with the classic Mac OS UI

Despite the fact that many critics have accused Apple of skimping on user testing in recent years, I think the first thing the Aqua design team did was sit a bunch of novice computer users down in front of classic Mac OS and note where they ran into problems. Anyone who has had to support Mac users can probably guess what surfaced as sore spots.

First, there's the Apple menu. Novice users often don't even realize it's a menu at all. And once they do discover it, they rarely use it unless prompted to do so (say, by a support person asking them to access a Control Panel or select "About this Mac") Customizing the Apple menu rarely occurs to novices since it is not immediately obvious that this is even possible.

The application menu is also a mystery to novices. Again, many don't even realize it's a menu. And even those who do often forget to use and/or consult it. Instead, they switch applications by clicking on visible regions of windows. Novice users often forget how many applications they're running and just continue launching things until classic Mac OS's creaky memory management system puts up an "out of memory" message.

The Finder is another stumbling block for novices. The problem is that it is too flexible. It allows them to put almost anything anywhere they want. The result is that most novice user's hard drives look like a bomb went off inside them. Files, folders, and applications are all over the place, sometime with many duplicates scattered across the disk. I've seen Macs with no less than three copies of MS Office "installed" in various locations. Novices also don't understand and/or can't be bothered to deal with logical folder hierarchies. Perhaps they'll encapsulate a project within a folder, but forget about further organizing projects by topic, or applications by purpose, and so on.

Finally, there's the desktop itself. This is one of the few places that novices feel as if they can always find. Consequently, most novice users have desktops absolutely filled with junk. Their favorite apps are there (usually actual copies instead of aliases) as are their twenty different "documents" folders and possibly last few documents they've saved.

Aqua's Solutions

What are Aqua's solutions to these problems? Well, the Apple menu is gone. A nonfunctional Apple logo is in the center of the menu bar instead (which, ironically, is what most novices initially think the Apple menu is anyway.) The application menu is also gone. In their place is the dock which is always visible by default and provides a single, simple interface element to fill the roles of the missing Apple and application menus.

The dock fares surprisingly well when confined to the needs of novice users. They have very simple requirements: allow me launch web, email, and office-style apps; show me what's currently running; allow me to switch between applications. The dock does all that, and looks good to boot. Even the dock's seemingly gratuitous genie effect serves an important purpose: it conveys, in very plain visual terms, exactly where a window goes when it is minimized and maximized. Even with visual aids like classic Mac OS's "zoomrects", novice users can often lose track of windows that appear and disappear quickly.

As for the Finder and desktop, the addition of a toolbar with large, friendly buttons to Finder windows provides novices with easy access to a handful of standard locations for their stuff. Novice users need these boundaries to avoid the "messy desktop hell" often seen in classic Mac OS. Even dragging files to the desktop was changed in DP3 to make aliasing the default behavior. This is what novices really want to do most of the time when they drag something to the desktop, and it helps to keep their actual files and applications in their standard locations.

For these reasons, I'd imagine that testing Aqua with novice users went very well. So why all the fuss about Aqua?

The Bad News

Although Aqua fills the needs of novice users admirably by clarifying the most problematic features of classic Mac OS, it fails almost everyone else, particularly experienced and/or advanced users with sophisticated needs. Although it may seem counter-intuitive, most experienced Mac users revel in their ability to micro-manage their environment. They expect nothing less than direct manipulation from their interface, and anything that gets in the way of their ability to customize their environment (within reasonable bounds) is seen as damage.

Experienced Mac users also pick and choose their favorite UI elements. Some use the application menu to switch apps. Some drag it out into a palette, with or without labels, large icons or small, with or without a window frame, anchored to any corner of the screen, or none at all. Some use command-tab. Some use the Apple menu to organize frequently used applications. Some prefer to keep them in a well-positioned window or launcher. Some use the desktop. Some use pop-up tab folders. Some use all of the above. And in each of those areas, experienced users build their own hierarchy of items that is custom-tailored to their particular needs.

Aqua removes this pick-and-choose flexibility, and, most damaging, much of the core functionality that makes it possible. While providing a simplified interface for novices is admirable, it should (and, more importantly, can) be done in a manner that does not take functionality away from experienced users. (Perhaps Apple should revist the concept of "scalable" interface complexity bandied about during the Copland project.) Aqua's missing functionality was detailed extensively in my DP3 article. Unfortunately, as we'll see in the following sections (and despite much hype to the contrary), not much has changed in DP4.

Enter DP4

DP4 installs very much like DP3. My test system for this review was the same 400MHz blue and white G3 with 256MB RAM that was used in the DP3 review. HFS+ remains the default volume format, and will be in the final release unless something drastic changes. Boot and login times are comparable to DP3: still much faster than classic Mac OS on the same hardware. Interestingly, the control-alt-delete easter egg from DP3 has been removed, as has the Think Different "About..." screen egg.

uname -a now reports the following:

Darwin localhost 1.1 Darwin Kernel Version 1.1: Sat May 6 20:49:29 PDT 2000;
root:xnu/xnu-74.7.obj~1/RELEASE_PPC Power Macintosh powerpc

Of interest is the fact that DP4 is now using the Darwin kernel ("xnu" in Apple's public CVS repository.)

The first obvious UI change is that the Mac OS X application menu (the new left-most menu in the menu bar that contains application-specific "About..." screens, preferences, the "Quit" command, and so on) now uses a bold-faced application name in place of a small application icon:

Application menu in DP3

Application menu in DP4

This is much clearer for novice users but, again, it hurts experienced users by making the standard suite of menus (File, Edit, etc.) into moving targets as each application name offsets them by a different amount. There are guidelines for the name that appears in as the menu title. It is not the same as the application's file name but is defined inside the application package. Apple recommends that it be no longer than 16 characters and should not exceed 128 pixels in width when drawn in the standard menu font. Fortunately, according to Eric Schlegel of Apple, the eventual goal is to allow the application menu to take the form of an icon, an icon plus a name, or just name, according to the user's preference. Choice is a Good Thing.

The next obvious change is that the Finder has been renamed "Desktop." This corrects another long-standing difficulty novice users have with classic Mac OS. Ask a novice to "go to the Finder" and they'll likely give you a blank stare (or worse, hit cmd-f). Calling it the Desktop makes more sense and, thankfully, does not hurt experienced users. Slightly confusing is the fact that the windows that appear in the Desktop application are still officially called "Finder windows." I know I'll probably continue calling the whole shebang "the Finder" out of sheer habit, so don't be confused if I interchange these terms throughout this review.

The Apple logo at the center of the menu bar remains (and remain non-functional), but blessedly disappears in DP4 when an application's menus extend past it.

The Desktop's application menu contains a new item in DP4: System Preferences

System Preferences item added to the Desktop application menu

Selecting System Preferences launches Preferences.app, the Mac OS X equivalent of classic Mac OS's Control Panels folder. The addition of this item to the Desktop is yet another indictment of the decision to remove the Apple menu. In classic Mac OS, the Apple menu (in addition to the Control Strip) provides access to commonly used items, including system preferences like Control Panels. I bemoaned the lack of such access in my DP3 review. Apple's solution? Hard-code the most commonly used system configuration item into the Desktop's application menu. While I'm glad it's there, it is a stunningly inadequate quick-fix for a very particular symptom of a much larger UI design problem: the total lack of a user-configurable, space efficient, always-accessible, hierarchical item organization system.

In better news, DP4 includes a full complement of Preference panels, most of which are fully functional aside from a few minor bugs. This is quite an improvement over DP3, where almost nothing worked. A complete list is presented below. When more than one tab is present in the Preference panel, I've taken a screenshot of the most interesting tab (trust me, you're not missing much.)

The preference item in the Desktop's application menu has been renamed "Desktop & Dock Preferences" and the dialog has been revised. It now includes three tabs: Desktop, Dock, and Disks. The Desktop prefs now allow custom desktop backgrounds (glitches with the display of the little "picture well" aside), and the dock preferences remain unchanged. The disk preferences appear below:

Desktop Preferences: Disks

The option to show removables on the desktop is a welcome addition, but I wish there was an option for fixed disks as well.

The Desktop's "Go" menu has also changed since DP3:

Desktop Go menu

The "Go to Folder" item pops up a dialog box into which you can type a path—very odd and Windows-ish, but it'd be useful with the addition of an auto-complete feature. The other items are shortcuts to common locations.

Finder windows are subtly different in DP4. The toolbar full of large buttons that runs across the top of each window can now be toggled via a menu item. Here's a shot of a Finder window without the toolbar.

A Finder window without the large toolbar. (Here it is with the toolbar.)

When the toolbar is switched off, the pop-up menu containing the current folder's context remains. It behaves somewhat like a more obvious (but less space-efficient) version of the command-click title bar menu in the classic Mac OS Finder. The browser-like "back" button remains as well. Note that the view mode (icon, list, column) is now toggled via a three-part custom control that is separate from the larger top toolbar (and therefore remains when it is turned off.)

Classic Mac OS dragging behavior has been restored to the Finder in DP4: drag now does a move or copy (even to the desktop), option-drag copies, and command-option drag creates an alias. Thank goodness for small favors.

The DP4 Dock

The biggest and perhaps most important change to the Dock in DP4 is that it is now a separate application: Dock.app. And yes, you know what that means...

Killing the Dock

Send a "Quit" Apple Event to the Dock and it exits gracefully and does not come back until you either log out and back in or manually launch the Dock app yourself. When the Dock is not running, the yellow minimize widgets is disabled on all windows. This separation of the Dock from the Finder (now Desktop) application opens the door for third party Dock replacements.

The DP4 Dock has undergone an organizational change. It is now divided into two sections: the left side contains applications (running or otherwise) and the right side contains anything that's not an application (files, folders, minimized windows, etc.) The red arrow added to the screenshot below points to the dividing line

The Divided Dock: Apps on the left, everything else on the right

This organization is enforced; you cannot drag an application to the right side or a non-application to the left. While some organization is better than none, this change does not help with the Dock's fundamental failings (e.g. its one-dimensional nature or the overwhelming burden of the functionality it is expected to replace.)

There are also cosmetic changes. The Dock no longer uses obvious tiles. Instead, icons are displayed on an attractive, subtly-striped translucent background. This background does not scale along with the icons when when Dock magnification is used.

The Dock's new look has created a new problem: only the icon itself is clickable. Clicking on the Dock background does nothing. This is not that much of a problem when the icons are meaty and provide large targets (although it would be nice if the active area extended to the bottom of the screen to provide a target with infinite height) but some "skinny" icons, like Apple's own Project Builder hammer icon, are nearly impossible to hit quickly, even at very large sizes.

Go ahead, try and click me.

Running applications are now differentiated from inactive applications by an ellipsis below their icons, as seen in the screenshot above. (This is a feature brought over from the NeXT Dock.) The underlines used in the DP3 Dock are gone; DP4 has regained that row of four previously blacked-out pixels at the bottom of the screen.

Icon scaling appears to be implemented the same way as in DP3: nearest neighbor scaling. I'd like to suggest to any Apple folks reading this an implementation that may be familiar to Myth: TFL players: use the faster algorithm when icons are being scaled, and perform a "final render" using a better algorithm (e.g. bicubic interpolation) when they have stopped moving. This technique is nearly imperceptible to the user (just ask Myth players if they ever noticed that the software renderer falls back to a very low quality rendering algorithm when the camera is moving) and would result in more attractive scaled icons in the much more common static state of the Dock.

The DP4 Dock implementation differs from DP3 in more ways than just its separation into its own application. In DP3, each item in the Dock appeared as an alias in a "Dock Items" folder inside a user's home directory. The DP4 Dock uses an XML property list (in a user's "Preferences" folder) to track docked items by URL. This implementation highlights the nature of the Dock: items are not actually moved or copied to it. Rather, the Dock contains (logically, if not literally) symbolic links to the items contained in it. Consequently, removing an icon from the Dock does not affect the actual item that the icon refers to. Dragging an icon off the Dock in DP4 and dropping it on the desktop results in a cute "puff of smoke" animation reminiscent of the scrub-out effect from the Newton OS. This is supposed to indicate that, while the item is gone from the Dock, it still exists on the disk. I don't think it works very well, and rumor has it that this puff animation has already been removed by Apple in later builds.

Here's a look at the Dock's per-user XML property list (.plist) in the GUI property list editor:

The Dock property list

(Note that applications now use Java-style unique identifiers (e.g. com.apple.dock.plist) in their resource file names to avoid name conflicts.)

You can see the Dock items in the property list, each stored as a URL and divided into "favorite-apps" and "favorite-docs" arrays. There are also properties that correspond to the Dock preferences available in the Desktop & Dock Preferences dialog. Setting these manually to values beyond the range possible via the GUI is amusing. (Note the circled item; that value is in pixels.)

Drag and drop is still not completely implemented in the Dock (for example, you still can't drag items into docked folders), but I suspect it will be implemented eventually.

The icons for the Trash and the Finder remain fixed in the right- and left-most positions, respectively, although developer documentation does state, in slightly broken English, that "there is no user preference yet to display or not the Trash on the desktop." The important word there is "yet." I think such a feature would be welcomed.

The Dock is still fixed bottom-center on the screen and it still does not expand in more than one dimension. Dragging more than a handful of items to the Dock simultaneously now results in the icons being repelled by the Dock and "springing back" to their original location. (Although "lurching" might be a better word; there are major redraw performance issues during this operation for some reason.)

Aside from the reclaimed pixels and small concession towards Dock organization, my previous complaints about the Dock still stand. It's still one-dimensional, it still presents moving targets of finite height, it still lacks text labels without a mouse-over, it still takes up too much screen real estate, it still tries to fill too many roles, and it's still a very poor substitute for the functionality missing in DP4.

The New Project Builder

Apple is in the process of creating a new Project Builder IDE. The old Project Builder app, renamed ProjectBuilderWO, remains in DP4 as it is still necessary for WebObjects development at this point. Here's a screenshot of the new Project Builder:

The new Project Builder (click to massively enlarge—sorry, it's a big app)

It's no MS Visual Studio, but it's still very impressive, especially considering the short time it has been in development (less than a year and a half, starting with only two developers on the project.) The application is dominated by various "slide out" drawers and tabs whose functions should be obvious to anyone who has used a modern IDE. What may not be so obvious is that Project Builder is built on top of popular open source development tools: everything from gcc, gdb, and cvs to smaller tools like diff. When viewed in this light, Project Builder is by far the most impressive front-end to open source development tools I've ever seen. It is slick and polished even in its current unfinished state, so much so that I would never have guessed that those old Unix stand-bys were lurking behind the scenes if they didn't declare themselves in their program output (e.g. the gdb output in the debugger console window in the screenshot above.)

Project Builder provides all the usual IDE functions: a capable syntax-coloring editor (and plans to allow any external editor to be substituted), breakpoints, stack trace, watch variables, file organization, build process configuration, multiple projects and subprojects, multiple build targets, and so on.

OpenGL

I explored Project Builder by playing around with some of the example projects included in DP4. The most interesting examples turned out to the OpenGL demos. DP4 is the first release of Mac OS X to include OpenGL, and the implementation is impressive. Subjectively, it feels faster than OpenGL in Mac OS 9. The demos include the usual range of OpenGL test apps, many of which were ported from old SGI demos. Examples:

Ring w/ environment map

SGI logo demo

Surface w/ environment map

All of these (admittedly, not very challenging) demo animations ran as smooth as glass on a G3/400 with slowest Rage128 card ever shipped by Apple. This bodes well for OpenGL game performance in Mac OS X.

QuickTime

Unfortunately, QuickTime in DP4 is not as solid as OpenGL. Movie playback lagged in DP3 as well, but I didn't bother mentioning it since the implementation was so obviously unfinished (you couldn't even drag the player windows consistently.) QT in DP4 has more polish, but performance is still way below par on my G3/400 test system. Reportedly, QT runs is just fine on G4 Macs. Perhaps Apple is doing G4 optimization first and worrying about the G3 afterwards. (This appears to be the case with the genie effect; see the performance section of this article for more details.)

Playing even a single movie in DP4 on the G3/400 results in dropped frames, stutters, and sometimes culminates in a crash. It's difficult to tell where the fault is. It may be in the QT Player app rather than in QT itself. Partially supporting this theory is the fact that movies play back much better inside the preview pane of Finder windows than they do in the QT Player. Then again, maybe that's just because they're smaller. Whatever the cause, QT in DP4 is not yet ready for prime time. Mac OS 9 trounces it in all aspects of movie playback on the G3. But I'm sure a flagship technology like QT will get the attention it needs before release.

Playback issues aside, the QT Player app itself is interesting. Most of what is broken in the current QT4 Player app is fixed in the DP4 player. The useless drawer is gone, the volume control is a slider instead of a clumsy thumbwheel, the window has a full complement of widgets, and all the major controls are visible. Check it out:

The DP4 QuickTime Player

The most interesting thing about the new QT Player is the arc that separates the player controls from the bottom of the player window. When I first saw the screenshots of the DP4 player at apple.com I immediately wondered what happened to that arc when the window was resized. The answer is surprising:

The DP4 QuickTime Player Stretched

As you can see, the arc just gets shallower as the width increases. How does the player do this? There are no obvious bitmapped resources relating to that arc in the QT Player app, so it may be that we are seeing the first use of vector graphics in a static UI element in Mac OS X. That arc could be defined by a vector (via Core Graphics Rendering), filled with a pattern on both sides (the brushed metal pattern is a bitmap in the app), and the area where they meet could be blended (via Core Graphics Services)

This speculation about vectors in DP4's QT Player brings up an important point. I've frequently read overly enthusiastic claims to the effect that "everything in Mac OS X is a vector" or "everything is a PDF", from the window frames and widgets to the icons. Perhaps I wasn't clear enough in my original look at Quartz, but I hope by now it's obvious that the vast majority of the UI in Mac OS X is made up of raster graphics. The icons, the window widgets, and the menu backgrounds are all bitmaps. The window and menu regions may be defined by vectors, but the contents are mostly raster images (with the obvious exception of type, which is rasterized from its vector-based font file, be it PostScript, TrueType, or OpenType.) And there are certainly vector transformations of raster images (the genie effect and dialog sheets being two examples) but that's not quite the same thing as "everything being a vector."

Apple could have decided to make the entire UI with vectors (i.e. the infrastructure is all there), but that would have made eye candy like the jewel-like window widgets and buttons much more difficult. Re-reading the section of this article that deals with Quartz should be instructive, paying particular attention to the roles of Core Graphics Services (event handling and on-screen compositing) and Core Graphics Rendering (a "black box" that takes input or drawing instructions from a range of sources, converts them into an internal PDF representation, and can send the output to an equally wide range of destinations, one of which happens to be the screen, where Core Graphics Services is waiting to composite it.)

Aqua Guidelines

The guidelines for building applications using the Aqua UI have expanded and changed with the DP4 release. The most important change is that the control sizes have been modified to match those in classic Mac OS. This was necessary to ensure that developers creating Carbon applications targeted at both classic Mac OS and Mac OS X wouldn't have to create two separate versions of the app, one for each control set. Because the DP3 Aqua widgets were much larger than classic Mac OS widgets, a dialog box or other UI element designed for classic Mac OS widgets would show up as a mess of overlapping buttons and controls in Mac OS X DP3. With monitor resolution having increased considerably since the 512x342 screen that the classic Mac OS widgets were designed for, I can understand Apple's desire to make things slightly larger. But backwards compatibility is clearly more important in this transitional stage of Mac OS development.

Apple has also released guidelines for Mac OS X icon creation. As is obvious to anyone who's seen Mac OS X icons, they are no longer meant to be abstract, geometric glyphs. Instead, they are meant to be "emotive", which is Apple-speak for "photographic." Gone are the guidelines (which, incidentally, very few developers have followed in recent years) dictatating that application icons should all be abstract diamond shapes with a tool over them, and that document icons should be limited to vertical sheets of paper with the corner folded.

Instead, Apple says that Mac OS X application icons should look like common objects laying on a desk (possibly in a pile), viewed from the perspective of a person sitting at the desk. They should also be rotated and may include a supportive tool (rotated in the opposite direction) to further suggest the application's purpose. The idea is to represent "familiar objects in a familiar way." Some examples:

Mac OS X Application Icons

Note the familiar objects, some in piles, rotated in one direction with the associated tools rotated the opposite way. Also note the subtle "sitting at a desk" perspective: the top of each icon is farther away and is therefore narrower.

The guidelines for "utility" applications are different. They should avoid the use of color in an attempt to convey their "serious" nature. They should be drawn to look like objects sitting on a shelf at eye-level. The supporting tool, if any, should be integrated into the icon rather than just layered on top as in regular application icons. Examples:

Mac OS X Utility Icons

The general lack of color is obvious, but I'm not sure how well the perspective guidelines have been followed. And the "tool" in the Installer app is just some sort of arrow. Still, the purpose is generally clear and I like the grayscale look.

Unfortunately, while these guidelines make sense and the icons sure do look nice, I think there is still a need for abstract, geometric icons. These "emotive" icons look fine at sizes above 32x32 pixels, but degrade terribly at smaller sizes. While novices may keep their icons large, experienced users will undoubtedly want to conserve screen real estate by making their icons small, perhaps as small as 16x16. At these sizes, photographic-style icons become indecipherable blobs no matter how good the scaling is. A solution would be to include abstract icons for the very small sizes, changing to the photographic style at 32x32 and above.

Classic

The classic Mac OS compatibility environment is much improved in DP4. The most egregious cosmetic problems present in DP3 are gone. The integration with the rest of Mac OS X has improved. Classic apps show up in the dock and use the Mac OS X Finder instead of the classic Mac OS Finder. Many Control Panels inside Classic now show a reduced feature set, reflecting their lack of relevance when running in Mac OS X (e.g. the Memory control panel only shows the disk cache setting since Mac OS X is handling all the memory issues behind the scenes.)

Performance and resource usage has improved considerably. Classic is not nearly the memory and CPU hog it was in DP3. To get DP4 Classic close to DP3 levels of CPU usage I had to open a 16MB TIFF in Photoshop and run computationally expensive filters on it. The screenshot below shows Classic's resource usage under normal conditions:

Classic CPU usage is much more reasonable in DP4

At times, Classic in Mac OS X DP4 feels faster than native Mac OS 9, particularly during actions that leverage the virtual memory system such as application launching. Screen display is similarly impressive. Opaque-scrolling web pages in the classic version of IE5 feels just as fast as it is in native Mac OS 9. In fact, IE5 running in Classic beats the Carbonized beta of IE5 included with DP4 in almost every performance measure. The Carbon IE5 beta is a very early build (it crashes every few minutes), so obviously it's not quite a fair comparison. But it's still an impressive showing for DP4's Classic environment.

Performance and Stability

On the whole, DP4 seems marginally faster than DP3 on a G3/400. Some things have made obvious improvements. Classic is much faster. The genie effect is much smoother on a G3 than it was in DP3. DP4 even continues to play QuickTime movies as they are "genie-ed" on the G3—a feature that only worked on G4s in DP3. Opaque window dragging is more or less unchanged. Opaque resizing is slightly better but still sluggish, and has been disabled in some of the apps that were very slow in DP3. Boot time is a wash.

Performance sore spots remain in DP4, some of them new. Preference panels inexplicably take forever to load in DP4. As explained earlier, QuickTime playback on the G3 is not even up to classic Mac OS standards yet. All UI elements and controls continue to be slower than those in classic Mac OS, particularly anything that involves transparency. This is to be expected (especially on the G3 where there's not an extra functional unit that is mostly idle in classic Mac OS just waiting to be leveraged by Mac OS X to do the GUI heavy lifting), but the gap could be narrowed.

OS stability continues to be a non-issue. Again, the OS did not crash at all during my testing. DP4 is vulnerable to "denial of service"-type attacks, however. No, I do not mean the network packet attacks, I mean things like fork bombs and other applications that absorb more and more resources until the system becomes completely swamped. I created and ran a few such processes (as root), but stopped them before the system became completely unresponsive. Clearly, Mac OS X needs to enforce some sort of resource usage limits, even for the root user. Unlike traditional Unix, I suspect many users will do all their daily work in Mac OS X as root simply because they are accustomed to being able to change any aspect of their Mac in classic Mac OS (where you're always essentially "root")

WWDC

Apple's Worldwide Developer Conference has come and gone without any major new product announcements. This should be expected; it's a developer conference, after all. But Apple is partially to blame for unrealistic expectations, having announce new products at WWDC in the past. A huge amount of technical documentation for Mac OS X was released at or after WWDC 2000 (and is the basis for much of this review) but that's not quite as exciting to the general public as a new iMac or a PDA.

The biggest announcement at WWDC was that Mac OS X will not be completed by Summer 2000, as was promised. And yes, it was promised. Here's a quote from Steve Jobs from MacWorld Expo 2000: "Mac OS X will be on sale as a software product starting this Summer." Instead, Mac OS X DP4 was released at WWDC, and it was announced that a public beta will be released this Summer rather than a finished product. Apple could decide to shrinkwrap and sell the beta, but it's clear that Apple has violated the spirit of their original schedule, even if arguments can be made regarding the letter of the original announcement.

The deadline for pre-installation of Mac OS X on new Macs remains unchained, however: January 2001. The idea behind the original Mac OS X roll-out plan was to make Mac OS X available to early adopters in Summer 2000 and start pre-installing in 2001. That really hasn't changed. What has changed is the nature of the version of Mac OS X that will be available to the early adopters: it will be a beta rather than a finished product.

Regular readers may recall my prediction from the Mac OS X DP2 review in December 1999:

"The current party line has Mac OS X on store shelves some time in 2000. I fearlessly predict that it will not appear until 2001 at the earliest (unless they decide to ship a half-finished product a la Mac OS X Server 1.0)"

This prediction was easy to make. First, it's always a safe bet to pick a major software product and predict a delay. Try it! Second, Mac OS X is a huge project and it was clear (to me, at least) that, given its state as of DP2, it would not be completed in any reasonable state by Summer 2000. I do not think the delay has much to do with UI changes, as some other have speculated. Fundamental OS features were released very late in the game. The i/o architecture, for example, was not available to developers until DP3. Even DP4 has seen major changes such as the reorganization of Bundles and the addition and removal of attribute keys from standardized XML property lists. And the Mac OS X audio architecture is still not complete.

The other WWDC event that's gotten significant press is Apple's demonstration of Mac OS X running on a multiprocessor G4. This was just a technology demonstration, not a product announcement. In my opinion, this was a non-event. Multiprocessor support is a no-brainer move for Apple. We've known from the start that both Mac OS X and the G4 CPU are completely multiprocessor capable.

The only significance that can be attached to it is that multiple processor may be Apple's only road to CPU parity given the current clock speed stagnation of the PowerPC line. I suspect that, at today's prices, Apple's cost for two 500MHz G4 CPUs is comparable to that of a single 1GHz Athlon. Apple would have to take reduced margins, but it could conceivably introduce multi-G4 systems at the same price as its single-processor G4 products. (Fat chance, I know.) Even with the next generation G4 CPU on the horizon, I believe multiple CPUs are Apple's best path to performance increases given the PowerPC line's (apparent) focus on embedded applications in recent years. If they're going to make PowerPCs small and cheap, just buy two! Failing that, another CPU transition (to IA64, Alpha, x86, or whatever) is certainly possible down the road when the eminently portable Mac OS X has supplanted the PowerPC-bound classic Mac OS.

Wrap-up

The question is now whether or not Mac OS X will be done by 2001. I think that's a pretty safe bet, give or take a few months for Apple's traditional "it's shipping, we're just not quite ready to send you yours yet" delay. I suspect that Mac OS X will undergo significant UI changes only after its official release (possibly due to public outcry from experienced Mac users regarding the 1.0 version.) In other words, I do not doubt Apple's resolve to ship Mac OS X with an interface feature set that is not a radical departure from that seen in DP4.

There are ample precedents for this phenomenon in the Mac community, the most glaring of which may be the long battle to make the Apple menu hierarchical in classic Mac OS. It took years of shareware Apple menu enhancement utilities to convince Apple to integrate that functionality into Mac OS. Let's hope similar changes to Mac OS X don't take as long.

Mac OS X is still a work in progress. Technically, it is as sound and innovative as ever. But despite hype to the contrary, I do not believe that the UI changes in DP4 (welcome though they may be) have made any significant dent in the problems detailed in my DP3 review, elsewhere on the web, and reiterated in this article. There's still plenty of time for changes before 2001, however. My fingers are firmly crossed.

The vast majority of the technical information in this article came from Apple's developer documentation available on the web.

I encourage Mac users with concerns about the Mac OS X user interface to send constructive feedback via email to Apple's human interface feedback address: machi@apple.com.

Addendum: Symbolic Links

A lot of people not steeped in Unix culture do not know what symbolic links are, particularly Mac users who don't understand the differences between Mac OS aliases and Unix symbolic links, or "symlinks." But it's such a simple concept, it's worth taking a few seconds to explain it.

Symlinks are files that contain a string that is interpreted as a file path. Let's look at that sentence a piece at a time.

• "Symlinks are files..." That means they can be moved, renamed, and deleted just like any other file.
• "...that contain a string" Yes, they really do contain a plain old text string. Depending on the OS, the contents of symlink files may not be accessible. But rest assured, at the lowest level it's just a file containing text.
• "...that is interpreted as a path" This is the only vaguely tricky part for people who have never used a system that required them to understand paths. It is explained further below.

A path is a series words separated by an aptly-named "path separator" character. In Unix-style systems (like Mac OS X), the forward-slash (or just "slash") character "/" is the path separator. Each component of the path corresponds to a file or directory. Every path component but the last one must be a directory name. The last path component can be either a directory or file name. Thus, a path leads to a particular file or directory in the file system. Some examples of paths appear below:

/MyDisk/Documents

/MyDisk/Documents/xmas.txt

Documents/xmas.txt

Paths maybe either "absolute" or "relative." Absolute paths begin from the very top of the directory tree and therefore always correspond to the same file or directory no matter where the symlink file containing that path is moved.

Relative paths correspond to the file or directory located at a particular path starting from the current directory. The "current" directory for symlinks is the directory that contains the symlink file. This all sounds complex, but it's really not. Examples:

Let's say we have two symlink files:

• symlink1 contains a text string that spells out the following absolute path: /Food/Apple
• symlink2 contains a text string that spells out the following relative path (note the missing slash at the start): Food/Apple

Now let's look at the simple directory structure below:

/MyDisk/
    Food/
        Apple
    Special/
        Food/
            Apple

No matter where we put symlink1 on MyDisk, it will always point to the Apple file in the Food directory at the top level of MyDisk.

symlink2, on the other hand, could point to either the Apple file in the top level Food directory, or the Apple file in the Food directory inside the Special directory, or, perhaps, to nothing at all! Examples:

Example 1: symlink2 pointing to the "non-special" Apple file:

/MyDisk/
    symlink2 -> Food/Apple
    Food/
        Apple (symlink2 points to this)
    Special/
        Food/
            Apple

Example 2: symlink2 pointing to the Apple file in the Food directory inside the Special directory. Note that the Special directory could be moved anywhere on the filesystem and symlink2 would still point to the same file. This is the benefit of using relative links.