What is Mac OS X DP3?

Mac OS X DP3 is the third "Developer Preview" release of Mac OS X (pronounced "ten", not "ex"). What is Mac OS X? See the two previous articles in this series for more information:

• Mac OS X DP2: A Preview
• Mac OS X Update: Quartz & Aqua

Mac OS X DP3 is the first developer release to include the Aqua user interface introduced at the recent MacWorld Expo in San Francisco. Chances are good that Aqua is the reason you're reading this article. Love it or hate it, Aqua is an attention getter. But this is Ars Technica, not GUI Eye-Candy Weekly, and cruel fiend that I am, I'm going to start this look at DP3 with some good old-fashioned technical exploration. (Jelly bean GUI lovers fear not, I promise I'll cover Aqua in the next section.)

NOTE WELL: This article deals with Mac OS X Developer Preview 3, NOT Mac OS X. It is a work in progress, not a finished product. You will never find Mac OS X DP3 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 DP3 are subject to change before release.

Bundle Services

Mac OS X's meta-information encapsulation was first covered in the DP2 article. (You may want to review the linked page before reading further). Although the encapsulation Mac OS X uses to contain meta-information is identified as a "package" in Mac OS 9, the developer documentation uses the term "bundle." The official specifications for the "bundle" architecture and the "Core Foundation" APIs built on top of it are now on Apple's developer web site.

I'm not going to rehash all the details (interested readers can follow the link above to learn more), but I will quote from the section of the documentation that explains why bundles are a useful feature of Mac OS X:

Benefits of Using Bundles

• A single application can run on both Mac OS 9 and Mac OS X.

• A single application can support multiple chip architectures (PowerPC, x86), library architectures (CFM/MachO), and other special executables (for example, optimized libraries for AltiVec).

• A single application can include support for multiple languages (localizations). Applications can also add new language support or remove unwanted language support simply by adding or removing resources.

• Applications can reside on many different volume formats, including multiple fork formats like HFS, HFS+, and AFP, and single-fork formats like UFS, SMB, and NFS.

• An application can run directly from a server. No special shared libraries, extensions, and resources need to be installed on the local system.

• Because an application package both includes and hides all the executables, resources, libraries, help files, required plug-ins, and other elements necessary for execution, users cannot accidentally break an application by renaming it, moving it, or otherwise manipulating it in the Finder.

• Shared libraries and plug-ins enjoy the same advantages as applications. All necessary resources and localizations are included.

• Application installation, relocation, and removal is accomplished simply through drag and drop.

It may seem like I'm inordinately focused on file system meta-information, but it really is a key part of the Mac OS experience. Less technical Mac users may wax rhapsodic about the "elegant GUI" or "intuitive ease of the Finder", but the technical features of classic Mac OS that make all of that possible are rooted in Mac OS's ability to categorize and track files based on an extended set of attributes (i.e. meta-information).

If Mac OS X is ever to be "Mac-like", it must retain the ability to handle file system meta-information. But Mac OS X must also be a thoroughly modern operating system, and that means not being afraid to leave the classic Mac OS world of resource forks and proprietary file systems behind. Those are two conflicting goals, and Mac OS X bundle services are Apple's solution. The design retains the old Mac OS "elegance" while breaking free of some nasty legacy issues.

Bundles also serve as a means of encapsulating the various files associated with applications, harking back to classic Mac OS's roots as a system where applications were single files that you could shuffle around and copy with impunity. This is another Mac OS simplicity hallmark, but it's one that has been lost in recent years. Today, classic Mac OS applications are rarely single executable files. More often, they are composed of an executable (can be stored anywhere), a few shared libraries (usually stored in the Extensions folder), data files (usually stored in the same directory as the executable), and system extensions (again, the Extensions folder--plus a reboot).

The ease of use and configuration enjoyed by classic Mac OS has returned with bundles. No, applications have not turned back into single files, but that's how they appear in the high-level UI. Bundles not only encompass all the files related to a single application, they may also include all the files necessary for that same application to run on several architectures and in many different languages. It is a "fat" binary in a new sense of the word.

And while the bundle concept is certainly not new (it's yet another gem from Apple's acquisition of NeXT), the details have been thoroughly modernized by Apple. Propriety class listings and binary object-resource files from NeXT have given way to XML files in Mac OS X. Earlier we looked at XML Property List (".plist") files in DP2. DP3 takes the next step by using XML for interface builder resource (".nib") files inside Carbon applications. The DP3 release notes state that Cocoa ".nib" files will use XML in a future release as well. (Apple watchers with a good memory will recall the first announcement of this XML migration strategy from a Rhapsody Q&A session at the Apple World Wide Developer Conference in 1998. And who says Apple never follows through... ;-) The (long-term) upshot of all this? Say goodbye to ResEdit and resource forks, and say hello to XML files and a text editor.

Core Foundation

Bundle services (and many other features of Mac OS X) are accessible via Apple's "Core Foundation" (CF) architecture. The CF architecture is an interesting implementation of code sharing across Mac OS X's various APIs. Below is the obligatory block diagram.

This diagram contains more detail than the ones featured in previous articles. The bottom two blocks are usually combined into a single "Core/Mach/BSD" block. The reality of the situation is that Mach only provides the most basic services: memory allocation, threading, inter-process communication, and so on. Core Foundation provides more the complex common services: date handling, string representation, bundle services, XML parsing, property lists, unicode string handling, arbitrary data collections, and other services that almost any API implemented in Mac OS X will find useful.

The block diagram shows that both Carbon and Cocoa are built on CF services, as is Quartz. And while developers could write directly to CF's API, the common case is that developers will write to a more familiar API like Carbon or Cocoa, and those calls will be mapped to the appropriate functions within CF. This is a big win in terms of maintainability for Apple. It also conserves memory and allows refinements and optimizations to CF to trickle down (or is it up?) to the other APIs.

Core Foundation in Action

Let's take a look at one application of CF in Mac OS X. We've got XML property lists and we've got a standard interface to edit and create them via CF. What can we do with that ability that would be an improvement on existing implementations of the same feature in other operating systems? How about overhaul the standard Unix startup and configuration system?

Anyone who has spent some time hacking away at Linux or some other Unix-like operating system has no-doubt experienced the joys of editing one or more (usually "more") shell scripts and/or text configurations files somewhere under /etc/ and /etc/rc*. Sometimes it really is a joy; with nothing more than a simple text editor you can change OS behaviors and services that are buried under mounds of impenetrable binary object code in other OSes (e.g. classic Mac OS). Other times, you spend hours trying to figure out why your name resolver fails to load correctly following the joyous changes you made last week.

Like many features of Unix-ish OSes, it's a trade-off: with simplicity of implementation comes a lack of higher-level control. In other words, although it's great that you don't need a tool any more complex than a text editor to make changes, the implementation is such that creating, say, a GUI front-end to the startup and configuration system is actually a very difficult task. For starters, most of the configurations files have their own subtly different formats (cron, fstab, etc.). Worse, creating a general-purpose GUI tool for editing bourne shell scripts is nearly impossible unless you massively restrict the possible changes.

Mac OS X provides an interesting solution, and it uses CF to do it. Peek inside DP3's startup configuration directory (/System/Library/StartupItems/) and you'll find subdirectories for the various OS services which contain (surprise) a bunch of bourne shell scripts. Aside from the more intelligible directory structure, it doesn't appear to be much of an improvement. But we're not done yet. An XML property list file accompanies each service. Even more interestingly, double-clicking on that XML property list file doesn't pop up a text editor. Instead you get this:

Property List Editor

It's a GUI property list editor. The top pane of the window contains an editable GUI representation of the property list file. The bottom pane shows the actual XML source code. The property list being viewed belongs to the Network Time service. Property lists for other services look similar. They include the start and stop messages, a description of the service, load order preference, and dependency checking via the "Provides" and "Requires" parameters. We can see that this service provides "NetworkTime" and requires "Resolver." This make sense; the network time service needs to connect to a time server (say, time.apple.com), and it can't do that until the name resolver is functioning. The name resolver, in turn, requires that the networking interface be up. And so on, all the way back to the lowest level items that "Require" nothing and "Provide" essential services used higher up in the chain.

In this system, the shell script merely starts the service when run. The decisions about when (and if) a service may start are handled by the property lists rather than being a function of a complex tree of files and directories with obscure names that reflect equally obscure Unix run-levels (e.g. /etc/rc0.d/K85rpc or /etc/rc3.d/S77vital...and no, I did not make those up.)

To test this feature, I added a value to the "Requires" parameter array and named it, appropriately, "DoesNotExist", but I left the shell script untouched. On reboot, the network time service failed to load and the following error was logged:

SystemStarter: Some startup items failed to launch due to conflicts
...NetworkTime...

...followed by a text dump of the NetworkTime property list and the path to the file. Not earth-shattering, perhaps, but it is a good example of a useful feature made possible (and almost trivial) by Core Foundation. The simplicity of plain text files is maintained, and modular high-level organization is introduced via an open standard like XML rather than a proprietary text or binary file format.

(As an aside, one of the original applications of XML suggested by its creator was to unify the thousands of different kinds of text configurations files in Unix. The current situation requires each program to implement its own parsing routine designed to read its own configuration file format(s). It's not usually complex code, but it's a hassle and prone to bugs. The duplication of work is also offensive to any good programmer. XML solves this problem nicely. The XML parser can be provided by the OS (in this case, by Core Foundation) and used by any application to read its own XML configurations files. Unfortunately, it's not easy to change the status quo, especially in Unix. It's nice to see Apple taking some initiative in this area.)

Dive into Aqua

Congratulations, you made it to the part with the pretty pictures. Or did you skip directly here, thus validating Apple's appearance-focused hardware and software strategy? ;-) Let's get started with a bit of traditional Mac OS fun. Mash the modifier keys and select "About Mac OS" from what was once the Apple menu and you'll get this:

Not much of an egg, to be certain (whee, scrolling text), but the "About..." screen is the quintessential Mac OS easter egg, dating back to the very first Mac. The other less interesting egg is triggered by typing control-alt-delete at the DP3 login screen. You get a very confused dialog that reads "This is not DOS!"

Enough foolishness, let's begin. (Note: the two test machines used for this review were a G3/400 with 256MB RAM and a G4/350 with 64MB RAM. Unless specifically noted, my comments apply to both machines.) DP3 installs much like DP2 or any other recent Mac OS. HFS+ is the default volume format. The first look at Aqua comes during the installation process. A progress bar marches along as your hard drive grinds away. The only button in the installation dialog box is labeled "pause." It also happens to be the default button, meaning that if you hit return you will activate the button. Default buttons in Aqua dialog boxes "pulsate", which is a nice way of saying "blink." Not only is this feature mildly annoying (not as bad as, say, a flashing ad banner, but blinking is blinking), it's often misleading as well. In some circumstances, it makes sense to draw the user's attention to the "common case" (i.e. the default button) by some means. But "pause" is not the common--or even likely--case during the installation process, and there are better ways to draw attention without being so distracting. (For example, how about a nice "halo" around the default button?)

After installation and a reboot, the "Setup Assistant" asks the usual questions about time zone, network configuration, and so on. Network options remain limited to AppleTalk and TCP/IP over ethernet, with a few variations like DHCP and BootP. You're also asked for an "Administrator password" and presented with a form that allows you to create user accounts. Grind through that process (or skip it all together and just use the administrator account) and wait while DP3 reboots again.

The startup process is clean, if unimpressive. You get an Apple logo and the OS name in a window with a progress bar. Startup messages (as defined in the XML property lists described earlier) flash beneath the progress bar as DP3 boots. By tweaking an Open Firmware setting, DP3 can boot with the traditional Unix black screen full of scrolling console messages, a very tiny sample of which appear below:

config @ 148af000 (80880000)
USB Generic Hub @ 1
devfs enabled
IOKitBSDInit
/pci@80000000/pci-bridge@D/ADPT,2930CU@2"@13;}@11;}@8;}@0
Using DMA transfers
MATSHITA, DVD-ROM SR-8583, rev D54A [ATAPI].
USB Generic Hub @ 2
Using U-DMA/33 transfers
, IBM-DTTA-351290, rev T58AA73A [ATA].
25385472 blocks, 512 bytes each, write-enabled.
USB Generic Mouse @ 3
USB Generic Keyboard @ 4
Debugger client attached
Link is up at 10Mb - Half Duplex
IOMEGA, ZIP 100, rev E.08 [SCSI].
disk2s6, major 14, minor 24
probing for root file system
not a ufs disk, trying next file system
devfs on /dev
start_other_cpus - temp disabled

Most of this is just the usual litany of Unix console messages, and over half of it appears to be error reports and/or debugging code (not listed above because it's boring to see 50 identical error messages in a row). There are a few gems as well, like the very last line indicating that multiple CPUs are disabled in DP3 (although it's not as if there are any multi-CPU Macs outside of Apple anyway).

Startup times are very fast, faster than both Mac OS 9 and Linux PPC 1999 on the same hardware by a significant margin (but still not as fast as Be OS on similar hardware). Type a username and password in the login dialog and you're in the Finder. Being a mischievous person, my first order of business was to pop up a terminal window, create 2000 empty files named "foo1", "foo2", ... "foo2000" via a simple command-line script, pull up that folder in the Finder, select all, and drag all 2000 files to the dock...

The MWSF keynote showed how the icons in the dock shrink as more are added, but one of my unanswered questions from the previous article was, what happens when the icons can shrink no more? Does the dock expand to multiple rows like the Windows task bar? Do the dock icons shrink to single pixels? Does the dock dump core and exit? Take a look.

<squint>

That image is at 100%, folks. It's a tiny snippet of the bottom of a 1024x768 screen. Click the image to see a full-width screenshot of the dock. If you squint, you can barely make out the "generic document" icon on each of those dock tiles. And if you count them, you'll see that there are far fewer than 2000. So, to answer my question, what happens when the dock really fills up? The icons shrink to 8x8 pixels and then scroll of the right and left edges of the screen when they no longer fit! That's not what I'd call "graceful scaling" of a UI feature. By contrast, I currently have over 3000 items in a single pop-up tab folder in Mac OS 9. It's in list-view and I can get at any item I want by scrolling and/or flipping disclosure triangles on nested folders. It takes up about an inch and a half at the bottom of my screen. Classic Mac OS 1, Aqua 0. (Actually, I'm not going to keep explicit score. I'm sure you can create your own tally.)

Worse, with 2000 unrecognizable, identical, mostly inaccessible items in the dock, its responses slow to a crawl. Trying to add or remove anything from the dock at that point is nearly useless. Logging out and back in didn't change the contents of the dock, and I really wanted to get rid of that mess so I could continue testing. This quickly led me to a folder inside my home directory (aptly) named "Dock Folder." Predictably, inside were 2000 aliases. I deleted them and the dock was back to normal.

Whew, enough malicious hacking. Let's rewind and start again...

Aqua Look and Feel

As anyone who's seen the screenshots knows, Aqua looks very nice. Even in this very first private release, the attention to detail in Aqua is impressive. Everything appears sharp and polished. All the UI elements look just as good as they do in the screen shots on Apple's web site. Some even look better. For example, the title bars of inactive windows are not the faded blue that they appear to be in Apple's screenshots (and in the various Aqua skins and themes created based on them). They're actually semi-transparent. It just so happens that the default desktop background is blue, so the title bars all appear faded blue in Apple's screen shots. Below is an example of their behavior:

Note that the transparency is layered rather than a simply a function of the desktop background (i.e. the middle window is more opaque when you have to "look through" both it and the title bar of the bottom-most window.)

Here's the darker side of all this transparency:

Can you quickly read those window titles, or does it all look like a jumble to you? Depending on how you look at it, this is either a bug or a feature. The "feature" is that you can read window titles that would normally be obscured (e.g. "Administration"). The "bug" is that the legibility of the front-most inactive window is reduced due to "show through" from the windows below it. I'll punt on this one and say that, while this problem nags at the perfectionist in me, it rarely comes up in normal usage. I had to arrange this rather contrived screenshot manually.

The window widgets are straight-forward with the exception of the purple button on the far right that toggles "single window mode." When single window mode is activated, all but the front-most window minimize to the dock. When any other window is un-minimized from the dock, the previously active window automatically minimizes. Thus, only one un-minimized window appears on the screen at a time. This may actually be a useful feature for novice computer users, but a system-wide setting that's of use to only a certain subset of users should not be a widget on every single window in the OS! And even if the setting was applicable to everyone, the title bar is not the place to put system-wide configuration controls. Conceptually, it's as bad as adding a button for the audio volume control to the title bar of every single window!

Single window mode off

Single window mode on

Another curiosity is the blue Apple logo in the center of the menu bar. What is it? What does it do? The answers turn out to be "an Apple logo" and "gets in the way." First of all, it has no function that I was able to determine. It doesn't change appearance at all, and clicking on it, dragging to it, and otherwise abusing it has no effect. Second, as menus expand from the left ,they are eventually forced to straddle the logo. Worse, Classic apps are not aware of the badge at all:

Apple badge

Apple badge in Classic

Also note the inferior anti-aliasing of the menu titles in Classic. Classic lags behind in look and feel in many ways. Classic apps don't get the Aqua appearance. Instead, they use a modified version of the classic "Apple platinum" appearance that has the window widgets rearranged to match Aqua windows:

The "Classic X" Appearance

The menu bar and the menus appear to get the Aqua appearance in classic, but it's an illusion. What's actually going on is that the Mac OS 9 disk image in DP3 includes an Appearance Manager theme called "Classic X."

(Brief review: Mac OS 8 and later have used the Appearance Manager to control all aspects of the GUI's look. Originally, Apple planned to ship several themes with Mac OS 8. When Steve Jobs came on board, he axed themes, but the functionality remained. Apple shipped Mac OS 8 with a single theme, "Apple platinum", and did not publish the Appearance Manager specifications. Industrious third parties have created Appearance Manager themes through reverse-engineering, and several Apple appearance themes originally intended to ship with Mac OS 8 have leaked out onto the net.)

As it turns out, the Appearance Manager came in handy in the end. The "Classic X" appearance includes the Aqua-like title bar and menus, but otherwise looks just like Apple platinum (with the window widgets rearranged).

Classic X appearance	Apple Platinum appearance
Classic X menu	Apple Platinum menu

Note that the system font does not change between appearances (and, in fact, cannot be changed via the "fonts" tab in the classic Appearance control panel). Also note that the Aqua menu bar peeks out from under the Apple Platinum menu bar. The Apple Platinum menu bar does not include the centered Apple badge. Of course, these appearance settings only affect the menu bar and menus seen when a classic app is the front-most application. Both Classic X and Apple Platinum appearances use the Aqua-style window widget grouping seen earlier. As in DP2, the classic menu bar has little relation to the rest of the system. It shows its own Apple menu, it's own application menu, it's own extensions (i.e. the menu bar clock), and so on. I still see no good solution to this problem.

Appearance-wise, it gets even worse for classic apps in DP3. They do not play well with Aqua windows:

As you can see, the transparent shadows don't quite work on top of classic apps yet. The same thing happens when Aqua menus (the real ones, not the Classic X versions) come down over classic windows. In fact, this shadow bug can be seen when any Aqua UI elements display themselves over a classic window: dock item titles, tool-tips, etc. The bug is especially jarring beneath the active window (which has a larger shadow than inactive windows, appearing to float "higher" above the desktop.) There are many other more minor cosmetic bugs across both classic and Aqua, but these (unlike the dual-UI issues) are very solvable problems.

Performance: Aqua in Motion

Aqua performance is a mixed bag, but is generally acceptable. Things that were fast in DP2 remain fast (or faster) in DP3. Opaque window dragging is very snappy and does not appear to suffer any slow-down due to the transparent window shadows. The translucent menus come down only marginally slower than the plain ones did in DP2, and scrolling over menu items suffers no perceptible speed hit. Buttons, checkboxes, and other control widgets are not particularly CPU intensive and behave innocuously.

The first signs of CPU loading come when large motions are required. Scrolling windows (both list and icon view) in the Finder is fast in most circumstances. Horizontal scrolling in list view windows is noticeably slower, however. Opaque resize is inordinately slow for no good reason (it's so slow that I must assume it's some sort of implementation bug in DP3). "Sheets" (those attached dialogs that seem to slide out from under the window title bars in Mac OS X) miss a few frams on the G3/400. The genie effect stutters even more noticeable in some circumstances, but the total time taken to minimize or maximize seems constant. Frames of animation are dropped, but the window rarely takes any more time to appear or disappear.

The genie effect

"Sheets"-style dialogs

The G4/350 handled all the transformations effects (sheets, genie, etc.) noticeably better than the G3/400, even with only 64MB of RAM (which is the minimum RAM requirement for Mac OS X). Further, the impressive ability of QuickTime movies to continue to play while they're being "genie-ed" during a maximize or minimize operation isn't even attempted when DP3 is running on the G3. Instead, what you see is a white outline of the window with no picture of any kind where the movie would be. Try the same operation on the G4 and it not only displays the playing movie while max/minimizing, it actually appears to get more frames of animation than the ostensibly "faster" (in MHz) G3 does with it's empty window.

As responsive as DP3 is on the G4 (and even on the G3), switching back to Mac OS 9 on the same machine results in a noticeable improvement. So while DP3 may not be unacceptably slow, it is slower than Mac OS 9 on the same hardware. What constitutes an "acceptable" drop in performance is likely to be a personal issue.

The G4/350 really does feel like the faster machine in DP3 under casual usage. But the limited RAM on the G4 test system eventually gets it into trouble. The classic environment alone can easily eat up 64MB of RAM. Launch a few classic apps, open a bunch of Finder windows, launch a few Cocoa or Carbon apps, and you quickly get into The Land of Thrash. Classic's enormous appetite for system resources is a real killer. It not only wants a huge chunk of RAM, it also dominates CPU usage on an otherwise idle system.

Ouch.

Keep in mind that this is an idle system, and as scary as those stats appear, they does not mean that there's less than 10% of the CPU left for other tasks. Start actually using the Finder, for example, and Classic immediately drops to less than 30% CPU usage. Genie a window and suddenly the WindowManager process leaps to the top of the table with ~20% CPU usage. The bottom line is that the numbers in the "%CPU" column will always total to 100%. But while every other process is essentially idle (either in i/o wait for just plain not doing anything), the Classic environment is glad to slurp up every CPU cycle passed up by the other apps (which it distributes to each of the classic apps running inside it). Of course, this being a preemptive multitasking system, when the other apps actually need cycles, they can just take them.

Classic's RAM usage is more of a problem than its CPU usage, since a shift in RAM usage often means hitting the disk (which is much slower than merely redistributing CPU cycles). If you never launch Classic, a 64MB machine is about as usable as a 64MB machine under Mac OS 9. You can actually launch more apps on a 64MB DP3 machine, but you pay the price in swap activity. Still, at least you have the option. A 64MB Mac OS 9 machine will just "run out" of RAM and complain. And if you try to crank up Mac OS 9's VM system to much more than double your real RAM, you'll see thrashing that makes DP3 look polite and docile.

It's not clear how much debug/testing "fat" remains in DP3. As things stand, DP3 would probably run acceptably on a 64MB machine while simultaneously running updated versions of common household apps: word processing, email, web browsing, spread sheets, etc. The key word here is "updated," meaning Carbon or Cocoa. In the time between now and Mac OS X's commercial launch, Apple had better be lighting fires under the big-name app vendors to Carbonize.

The Dock Revisited

Let's return to the dock (I'll try to be gentler this time). The entire world of dock settings is contained in the Finder preferences dialog:

Dock preferences

The maximum tile size spans from 16x16 to 128x128 pixels. Dock tiles start out at this size and only shrink to make room for new tiles added after the dock has hit the edges of the screen. When magnification is turned on, tiles grow when the mouse is over them. The magnification size also goes from 16x16 to 128x128 pixels. If the magnification setting is lower than the current size of dock tiles, it has no effect. "Auto hide and show" causes the dock to remain hidden until the pointer hits the very last pixel at the bottom of the screen, at which time it slides up from below. When "use single click to open items" is unchecked, dock items must be double-clicked in order to activate them. Here's the dock in action:

The maximum tile size is set to exactly 32x32 pixels, and the magnification is set to maximum (128x128 pixels). The first thing you'll notice is the difference in icon quality between tiles. The three left-most tiles are folders from a Mac OS 9 volume, and their custom icons are 32x32 pixels. The fourth and fifth tiles are apps with 128x128 pixel icons. The right-most tile is an app with a 32x32 pixel icon. The differences in appearance demonstrate the dock's preference for scaling down rather than up. When scaling 128x128 pixel icons down to smaller sizes, it does a reasonable job. Just look at this series of shrunken dock tiles taken from the same screenshot:

The miniaturized "terminal window snapshot" icons in particular look very nice considering the degree of scaling. The scaled "Grab" application (the hand holding the window) looks okay, but not as nice as the scaled terminal application in the previous screenshot (the monitor with the prompt on it).

It's clear that the dock does not use bicubic interpolation as was surmised in the previous article in this series. When scaling down, it's using the much faster (and lower quality) "nearest neighbor" scaling algorithm. When scaling up, it does little more than scale the individual pixels, resulting in the "Fatbits" zoom effect you see above (5 nostalgia points for Mac users who get that reference).

In the long run, the algorithm may be changed. Right now, a dock full of 128x128 pixel icon scaled to some smaller size looks acceptable. A dock that contains smaller icons scaled up to larger sizes starts to look chunky. In all cases, magnification is lightning quick and responsive. The moral of the story: if you care how your docked icons look, don't set the maximum tile size (or magnification, if you use that) larger than the smallest icon in the dock. A good setting is a maximum tile size of exactly 32x32 pixels with no magnification. (It takes some careful tweaking to get the tile size slider to exactly 32x32 pixels, however.)

Astute readers have already noticed the strange underlines present in the dock screenshots above. The underlines indicate that the dock item is a running applications: yellow for the active (front-most) application and white for all others. Dock tiles without underlines are one of the following:

• The Finder (always present on the dock as the left-most tile)
• The trash (always present on the dock as the right-most tile)
• Minimized windows
• Aliases (to files, folders, applications, drives--anything that can be aliased)

Confused yet? You're not alone. With the exception of the trash and the Finder, dock icons can (and do) arrange themselves in any order: active applications mixed in with minimized windows and aliases. It makes it very difficult to tell what's going on at a glance, and very difficult to perform simple tasks like application switching. Clearly, changes need to be made.

The underlines themselves present another interesting problem. To allow for them, four pixels are blacked out at the bottom of the screen. They're not actually inactive, of course. It's just that the dock constantly displays a four-pixel high black area at the bottom of the screen--even when it's hidden. When the dock is visible, this area is used to draw the underlines. This is a "feature" I suspect most users can do without. Apple needs to gives back those pixels, at least when the dock is hidden.

Kill the dock and those pixels come back. But the dock is not a separate application, it's part of the Finder application. Kill the Finder and the dock disappears (along with the Finder, of course!) Despite the dialog shown below (triggered by pressing the "force quit" key sequence: cmd-option-esc) killing the Finder does not log you out. (The button reads "Force Quit" when an application other than the Finder is selected; see image.)

Unfortunately, the Finder has a nasty habit of re-launching right after it's killed. Under some circumstances, you can get it to stay dead with just a "Finder has been killed" dialog on the screen. I wasn't able to do this in a reproducible manner, however.

Actually using the dock for its intended purpose(s!) is "extremely unsatisfying," to say the least. Everything the dock does is done better by an equivalent feature of classic Mac OS.

• Application switching is easier with Mac OS 8 and 9's application switcher palette and application menu (which is totally gone in DP3; the far-right corner of the menu bar is absolutely empty). In classic Mac OS, you never have to worry about which item in the app menu or palette is an active application (and which is an alias or a minimized window) because they're all active applications. The ordering is also deterministic (alphabetical, launch order, etc.) instead of a willy nilly jumble as in the dock. And items have text labels as well as icons, so selecting the application you want to switch to is fast and easy.

  The dock could not adequately replace the application menu or palette even if the only thing it did was store active applications. It would still be slower to access (jumbled order instead of alphabetical), take up more room (a row of icons vs. a tiny menu in the always-present menu bar), be less configurable (the application palette can be anchored anywhere on the screen or be free-floating, with and without a title bar and window frame, sorted in several different orders, using different icons and label sizes) and be less intelligible (icons with no text labels) than the application switching features in classic Mac OS.

• Minimized windows handled better by classic Mac OS's window shade feature. With windowshaded windows, you know exactly where they're going to appear when you open them, and you know exactly where to find them when you want to un-shade them. With the dock, minimized windows get thrown into the soup of icons and are difficult to find later. After all, one shrunken icon of a terminal window looks very much like the next. And since there are no text labels until you mouse-over a tile, it's absolutely impossible to pick out the minimized window you want without "rubbing" the dock and reading the labels. Even then it remains a guessing game, since many applications do not give their windows intelligible titles. ("Now was it /dev/ttyp1 or /dev/ttyp5 that I was working in a second ago...")

  The dock could not adequately replace windowshading even if the only thing it did was store minimized windows. It is slower to access (jumbled order with no relation to the previous screen position of the minimized windows, and no text labels) and less clear (no indication of where the windows will appear or how big they'll be when they're un-minimized) than the windowshade feature in classic Mac OS.

• Aliases are handled better by both the Apple menu (totally absent in DP3 and not slated to be part of Mac OS X at all--except in Classic, which is its own little world in DP3) and pop-up tab folders (also absent except in Classic). Both offer a hierarchical, two-dimensional access to anything you want: drives, applications, files, folders, etc. And both take up a very small, constant area of the screen no matter how many items are added (to the Apple menu or to an individual pop-up folder). Compare this to the dock which grows more or less linearly as items are added (and as applications are launched!), degrades in usefulness as items are added and icons become even smaller and more inscrutable (again, no text labels), is one-dimensional, and is confined to a single row of images no wider than the width of the screen.

  The dock could not adequately replace even a simple Apple menu that had no sub-menus at all, even if the only thing it did was serve as an application launcher. Such an Apple menu would take up less room (a tiny icon in an always-present menu bar), offer faster access (being ordered alphabetically rather than a jumble), and offer better clarity (using text labels and small icons simultaneously) than the dock does in DP3.

  The dock could not adequately replace even a simple pop-up tab folder that had no sub-folders at all, even if the only thing the dock did was serve as a quick-access storage system for files and folders. Such a pop-up tab folder would be more configurable (offering all the view options of a Finder window), take up a less screen area (an inch or so at the bottom of the screen), be faster to access (ordered deterministically by any item attribute), and offer better clarity (using text labels as well as several sizes of icons) than the dock.

The total damage is even worse. The dock doesn't merely try to replace one of the items listed above (which it cannot do anyway), it tries to replace ALL of them! The dock, as it currently exists in Mac OS X DP3, is a total failure in that it not only fails to improve upon any aspect of Mac OS 8 and 9's equivalent GUI feature, it actually makes every single one of them substantially worse.

Hm, perhaps that wasn't any more gentle. Sometimes the truth hurts. Let's move on to some cheerier topics...

File System Organization

The file tree has more or less coalesced in DP3. A skeletal overview (with the BSD directories removed (likely to be an optional install anyway) and only a few files listed to give a flavor for directory contents) looks like this--split into two columns to save space:

/.../Users/
    John/
        Applications/
            TextEdit.app (alias)
            Mail.app (alias)
        Documents/
            My Photo.jpg
            Resume.html
            ...
        Library/
            Addresses/
            Carbon/
                Desktop Folder/
                Dock Folder/
                System Folder/
                    Preferences/
                    Extensions/
                    Appearance/
                    Application Support/
                    ...
            Preferences/
            Favorites/
            ...
    Administrator/
    Peggy Sue/
    ...

/System/
    Administration/
        Terminal.app
        Console.app
        NetInfo Manager.app
        ...
    Applications/
        Finder.app
        Classic.app
        Mail.app
        TextEdit.app
        ...
    Library/
        ColorSync/
        Fonts/
        Java/
        Perl/
        Printers/
        StartupItems/
            Disks/
            Cron/
            Network/
            Portmap/
            NFS/
            ...
    Documentation/
        Administrator/
        Developer/
        Help/
        ManPages/

User Home Directories

Let's start with the /.../Users/ tree. It contains the users' home directories and may live under either /Local (for an accounts on the local machine) or /Network (for accounts mounted from a server). Each user has his own folder for applications, documents, preferences, favorites, and so on. These items are accessible via the large buttons on top of the file browser (more on the browser later). The user's "Applications" folder initially contains aliases to the originals stored in the system-wide directories.

Each user gets his own folders for the dock, the desktop, and any Classic preferences or settings that should be stored on a per-user basis. The desktop and dock folders are just plain folders full of files and/or aliases. Anything on the desktop appears in the "Desktop Folder", and anything in the dock appears as an alias in the "Dock Folder." The "System Folder" mirrors the classic Mac OS directories that store per-user data. When a classic app saves its preferences file, for example, it thinks it's saving it in the one and only "System Folder" from classic Mac OS, but it's really being fooled by an equivalent directory structure rooted in each user's home directory. In this way, classic applications that were never designed for multiple users retain per-user settings in Mac OS X.

The /System directory tree contains items that are part of the operating system. Regular applications and administration tools are stored separately. Note that Finder.app is merely another application, although it is looked for by name. Replacing Finder.app with another application (also named Finder.app) will essentially replace the shell application (i.e. no more the dock, browser, or Finder windows) but everything will retain the Aqua look.

(As an aside, Finder.app is not actually the "login shell" for users in the traditional Unix sense of the word, nor according to Mac OS X policy. Users' shells as listed in /etc/passwd (and in the NetInfo database) default to /bin/tcsh, but these settings have no effect on local behavior. Terminal.app is configurable and will launch any shell you want when you pull it up, regardless of the /etc/passwd and NetInfo settings. As explained earlier, Finder.app can be killed without logging the user out. The closest Mac OS X equivalent of the login shell for local logins is "Workspace.app", stored in /System/Library/CoreServices/Workspace.app. Kill Workspace.app and you're instantly booted out to the login screen.)

System-Wide Directories

/System/Library is the closest equivalent to the classic Mac OS "System Folder." It contains shared libraries, fonts, system extensions, drivers, system services, and most other OS-related files, all organized in reasonably intelligible directories. (We looked at the contents of "StartupItems" folder earlier.) Although (necessarily) more complex than the classic "System Folder", the /System/Library tree is actually better organized. No longer are initialization services ("INITs" in classic Mac OS) and shared libraries throw into a giant catch-all directory (i.e. "Extensions"). Instead, they're subdivided by component: Java classes are in the "Java" directory, Perl modules are in the "Perl" directory, printer drivers and PPD's are in the "Printers" directory, and so on. Settings files are similarly organized: CMM's and ICC profiles are stored in the "ColorSync" directory, keyboard configurations are stored in the "Keyboards" directory, etc.

The whole /System/Library tree is a welcome improvement over both classic Mac OS (a pile of stuff in the "Extensions" folder, a pile of stuff in the "Preferences" folder) and traditional Unix (/etc/inet/services, /usr/lib/utmpd, etc.). System documentation is similarly subdivided based on audience: Administrator/, Developer/, Help/ (for regular users), and ManPages/ (traditional Unix manual pages).

There are reflections of the directory structure present in /System rooted under /Local (for items local to the machine that are not part of the operating system) and /Network (for items that are located on remote machines). Mac OS X supports the concept of a Search Path: an encapsulated strategy for finding resources, whether they are part of the operating system, items installed by the user, other items installed on the local machine, or resources available via the network. Mac OS X provides an API for finding resources according to the search path. This system is conceptually identical to the one implemented in OpenStep, but the layout itself has been clarified considerably. A comparison is available here.

For more detail on Mac OS X's file system layout, consult the relevant section of the current revision of Apple's Mac OS X developer documentation.

The Finder

The DP3 Finder is nearly identical to the DP2 Finder with the obvious exceptions of the dock and the Aqua look and feel. The browser-style window does have a few changes, however.

New to DP3 are the widgets along the top of each browser window. The buttons (with the exception of "View" on the far right) are simply shortcuts to the conceptual root item, ~/, ~/Applications, ~/Documents, ~/Library/Favorites, and ~/Library/People, respectively. The "View" button cycles the browser window through column view (pictured above), icon view, and list view (with disclosure triangles). The pop-up menu lists the hierarchy leading to the currently displayed directory. The button with the leftward-facing arrow on it works like a web browser's "back" button, taking you backwards through the history of directories you've navigated. The "search" field appears to be only partially functional. It will sometimes do local searches of the items listed in the current directory (with file and directory name auto-completion). It doesn't appear to be a system-wide search or a front-end to Sherlock.

The "Computer" conceptual root continues to show mounted volumes as they come online as well as the "Network" item which is a shortcut to /Network. Most Unix-ish directories (/bin, /dev, /lib, etc.) are hidden in the Finder, as are dot-files (files and folders beginning with a period). Bundles (".app" files like "TextEdit.app") show up as single items of type "application" with their own icons. Double-clicking one launches the app.

The ".app" extensions is not always necessary. Removing it from most applications does not affect functionality. "TextEdit.app", for example, is unaffected if it is renamed to "Text Edit." The Finder looks inside what is really the "Text Edit" directory and finds the various meta-information files: the "PkgInfo" file which contains the classic Mac OS type and creator codes, the "Info-macos.plist" file which contains the Mac OS property list with keys declaring "Text Edit" to be an application, and so on. Any one of those items is sufficient for Finder to determine that "Text Edit" is a bundle that should be treated like an application.

Remove the ".app" extension from an older (i.e. NeXT era) Cocoa application like "Mail.app", however, and it looks like a folder from the Finder. All such older applications should be updated to include the proper meta-information by the time Mac OS X ships.

Traditional Finder windows are still present. In fact, you never have to see a browser window if you don't want to. (Keep in mind that volumes still appear in the conceptual root "Computer" item and not on the desktop, regardless of whether or not you use the browser.) And yes, the maximize (green) window widget does "shrink-to-fit" in DP3, although not as intelligently as the same functionality in classic Mac OS. List and icons views are available, but "button view" is not. Examples appear below:

List view

Icon view

View options are also carried over, with an addition: background images. But first, the usual options. Grid snap and "keep arranged by" are available, but the grid is quite buggy (and not adjustable) in DP3. The icon size in each window is scalable via the slider control, and although the icons in the window change size continuously in real time as you drag the slider, the "sticking points" are as follows: 16x16, 32,32, 48x48, 64x64, and any size between 64x64 and 128x128. In other words, the sizes are fixed up to 64x64, and scale continuous (most likely based on a down-sampling of the 128x128 icon) thereafter.

View options for list view windows (not pictured) include the usual array of checkboxes for the columns to show (date, size, etc.), options to view relative dates and to calculate folder sizes, and two preset icon sizes: 16x16 and 32x32.

View options: icon view

View options: background image

Let's take a short diversion into icon sizes. "icns" resources were introduced with Mac OS 8.5 and can contain pre-defined icons in many sizes and bit depths. Mac OS X "icns" files (which no longer have to be stored in resource forks) extend classic "icns" resources to include a few new sizes. The breakdown is shown in the table below. A "C" means that the icon type (size and bit depth) is available in classic Mac OS (8.5 and later). An "X" means it's available in Mac OS X "icns" files.

(Note: The icons missing on one or both OSes may be technically possible within "icns" files and resources (i.e. the "icns" format may be arbitrarily extensible) but they are not commonly present and not used by the high-level UI in the corresponding OSes at this time.)

Getting back to view options, the background picture option is only available in icon view windows, and does not appear to have any size limits. The background picture featured below is 1024x768 (at 129dpi, which is down-sampled for presentation on the screen).

Icon view window with a
background image

Unfortunately, the background image tab is disabled when you pull up the view options for the desktop. But an industrious user can dig into the "Finder.app" bundle and discover that the desktop picture is stored in there as a plain PICT file named (surprise) "Desktop Picture." Replace it, log out and then back in, and you have a new desktop background. Obviously, this functionality will be added to the Finder down the road, but it's convenient that you can change it now without any special tools.

There are other neat things lurking inside the Finder bundle: files contain icons for the buttons along the top of the Finder browser windows, the background image for dock tiles (currently a mild gray top-to-bottom gradient), the trash icon, and so on. Speaking of the trash, everyone's favorite fractured metaphor--the ability to drag disks to the trash to eject them--remains in Mac OS X. This time around, the trash icon changes to the "eject" symbol when a disk is hovering over it:

Trash eject icon

That's the 128x128 source icon, obviously. It scales with the dock. The trash also changes its icon to a pair of scissors when a file is hovering over it, indicating that the file will be deleted. I'm not sure how much better a pair of scissors is than the existing trash can icon, but we'll see what actually ships.

Finally, the desktop is indeed a "normal" desktop. Real items may be stored on it, not just aliases. As seen earlier, each user's desktop is just the contents of the "Desktop Folder" buried under their home directory. Unfortunately, the default action when items are dragged to the desktop is to make an alias. Holding down the command key while dragging will moves the item, and the option key will copy it. These key bindings need to be re-mapped to the classic Mac OS policy: no modifier for move, option for copy, and command-option for alias. There's not good reason for the change.

Loose Ends

As mentioned earlier, the Apple menu and the application menu and palette are gone. In place of the Apple menu is a menu that takes the icon of the active application and contains menu items for application-wide preferences, an "About this application" item, and the "Quit" command. While I sorely miss the Apple menu, I have no objection to the addition of this menu. It does make sense to have application-wide items like preferences, about, and quit in a single "application menu" instead of strewn throughout the "File" and "Edit" menus, no matter how "traditional" that arrangement may be.

Mac OS X's new application menu

There is currently no way to change any aspect of the appearance of Aqua (short of hacking; see below). The accent color, highlight color, system font, and text sizes are currently one-size-fits-all. Selectable "flavors" are a no-brainer option for the future, as is some flexibility with system font size, if not typeface.

A Short Diversion Into Themes

Brave users can muck around in /System/Library/Frameworks/HIToolbox.framework/ and actually disable most of the Aqua UI by moving, deleting, or renaming the right resource file (Extras.rsrc). Log out and back in and your windows look like they did in DP2: Apple platinum appearance with window widgets in classic Mac OS positions. The application menu returns, but the Apple menu remains missing in action. Windows retain their transparent shadows. The dock is still there, but windows no longer minimize to it; they windowshade instead. The system font changes back to Charcoal. Generic file and folder icons retain the Aqua look. Classic applications remain under the control of the Mac OS 9 appearance manager.

Mac OS X DP3 sans (most of) Aqua

Extras.rsrc contains resources very much like those found in classic Mac OS appearance themes. The match is good enough that classic Mac OS will accept Extras.rsrc as an appearance theme. The results are not pretty, however. Aside form the pinstriped background in some windows, it doesn't look very Aqua-ish, and it's so buggy as to be immediately useless. Menus stop working, clicks are missed, you name it. It's actually pretty difficult to even deactivate the appearance since pop-up menus no longer function.

Going in the other direction--trying to use classic Mac OS appearance themes in DP3 by replacing Extras.rsrc--has slightly better results. Interestingly, Carbon apps (like the Finder) retain most of the Apple platinum appearance, while Cocoa apps pick up a few UI elements from the classic appearance theme file, most notably the look and position of the window widgets and some bits from the scroll bars. Large portions of the UI in Cocoa apps are completely blank, and bugs abound. Also, the presence of even an imposter copy of Extras.rsrc causes the minimize button to dock windows via the genie effect rather than using windowshading (which is the behavior when Extras.rsrc is totally removed).

It makes sense that Apple would implement Mac OS X appearances in some modular fashion that leverages its past work with themes in classic Mac OS. Whether or not they publish that specification down the road is another issue. But it's good to know that third parties will have plenty of places to sink their teeth in.

Most Missed

Experienced Mac OS users using DP3 will miss the following classic
Mac OS features the most:

• The Apple menu. Want to change your monitor resolution? Sorry, no Apple menu -> Control Panels -> Monitors. Want to jot down a note? Sorry, no Apple menu -> Notepad. Want to open your CD player? Add up a few numbers? Change the time and date? Set your mouse tracking? Do any one of the tasks that are immediately accessible in the classic Mac OS Apple menu? Sorry, you're out of luck. You can either pre-fill your dock with 100 or so "desk accessory"-class applications, thus rendering it useless for any other task (and practically useless as a launcher due to the size of the icons when there are 100 of them) or resign yourself to digging for those applications each time you need them.

• Pop-up tab folders. There is nothing in DP3 that offers anywhere near that depth of access in such a compact package. If you filled your entire desktop with aliases to files and folders (and we've all seen Windows machines with exactly this setup) you still wouldn't match the functionality of a single, one-inch pop-up tab folder.

• The application menu/palette and "hide others." Switching applications is annoying and unnecessarily time consuming in DP3 as you scan the dock for underlines and then decipher the scaled icons. Both the application menu and palette from classic Mac OS are far superior. The "hide others" command is also sorely missed. The only option you have in DP3 is to minimize windows manually or go into single-window mode, both of which fill the dock with inscrutable minimized window icons and crowd an already crowded and jumbled area.

• The control strip. This is almost a luxury in comparison to the features listed above. DP3 lacks even the most essential functionality, so it's probably too much to ask for yet another elegant, quick-access point for common functions that takes up little or no screen real estate and has a single function that it performs admirably. (Sigh)

• Traditional window widget placement. Mac users everywhere will be reaching for the upper-right corner of windows to minimize them. This problem is exacerbated by the fact that there is a widget there (the poorly thought-out "single window mode" toggle), it's just not the right one. I suspect that the muscle memory will re-map in a week or so of constant use. And although the grouping of the destructive "close" widget alongside the more benign minimize and zoom widgets is a step backwards for Mac OS, I didn't mis-click at all during my time with DP3, nor did I find the Aqua widgets harder to hit. Your mileage may vary.