Conference Report: 2000 USENIX: Invited Talks: Challenges in Integrating the MacOS and BSD Environments

by Wilfredo Sanchez

Fred Sanchez discussed some of the challenges in integrating the MacOS and BSD environments to produce MacOS X. Historically, the Mac was designed to provide an excellent user interface ("the best possible user experience") with tight hardware integration and a single user. In contrast Unix was designed to solve engineering problems, using open source (for differing values of "open"), running on shared multi-user computers and with administrative overhead. There are positives and negatives with both approaches. MacOS X is based on the Mach 3.0 kernel and attempts to take the best from both worlds. A picture may help explain how all this hangs together:

Platinum	Aqua		Curses
Classic	Carbon	Cocoa (OpenStep)	BSD
Application services: Quantum, OpenGL, and QuickTime
Core Services
Darwin (BSD layer)

Fred next talked about four problem areas in the integration: file systems, files, multiple users, and backwards compatibility. Case sensitivity was not much of an issue; conflicts are rare and most substitutions are trivial. MacOS used colon as the path separator; Unix uses the slash. Path names change depending on whether you talk through the Carbon and Classic interfaces (colon, :) or the Cocoa and BSD interfaces (slash, /). File name translation is also required, since it is possible for a slash to be present in a MacOS file name. File IDs are a persistent file handle that follows a file in MacOS, providing for robust alias management. However, this is not implemented in file systems other than HFS+ so the Carbon interface provides for nonpersistent file IDs. Hard links are not supported in HFS+, but it fakes it, providing the equivlent behavior to the UFS hard link. Complex files 00 specifically, the MacOS data and resource forks — are in the Mac file systems (HFS+, UFS, and NFS v4) but not the Unix file systems (UFS and NFS v3). The possible solutions to this problem include using AppleDouble MIME encoding, which would be good for commands like cpand tar but bad for commands using mmap(), or using two distinct files, which makes renaming and creating files tough, overloads the name space, and confuses cpand tar, The solution they chose was to hide both the data and resource forks underneath the file name (for example, filename/data and filename/resource, looking like a directory entry but not a directory) and have the open() system call return the data fork only. This lets editors and most commands (except archiving commands, like cpand tar, and mv across file system boundaries) have the expected behavior. Another file system problem is permissions (which exist in HFS+ and MacOS X but not in MacOS 9's HFS). The solution here is to base default permissions on the directory modes.

The second problem area is files. Special characters were allowed in MacOS file names (including space, backslash, and the forward slash). File name translation works around most of these problems, though users have to understand that "I/O stuff" in MacOS is the same as "I:O_stuff" in Unix on the same machine. Also, to help reduce problems in directory permissions and handling they chose to follow NeXT's approach and treat a directory as a bundle, reducing the need for complex files and simplifying software installations, allowing drag-and-drop to install new software.

The third problem area involves multiple users. MacOS historically thought of itself as having only a single user and focused on ease of use. This lets the Mac user perform operations like setting the clock, reading any file, installing software, moving stuff around, and so on. Currently MacOS X provides hooks for UID management (such as integrating with a NetInfo or NIS or LDAP environment) and tracks known (Unix-like) and unknown disks, disabling commands like chown and chgrp on unknown disks.

The fourth and final problem area Fred discussed was compatibility with legacy software and hardware. Legacy software has to "just work," and the API and toolkit cannot change, so previous binaries must continue to work unchanged. The Classic interface provides this compatibility mode. Classic is effectively a MacOS X application that runs MacOS 9 in a sandbox. This causes some disk access problems, depending on the level (application, file system, disk driver, or SCSI driver). The closed architecture of the hardware is very abstracted, which helps move up the stack from low-level to the high-level application without breaking anything.

Questions focused on security, the desire to have a root account and the terminal window or shell. The X11 windowing system can be run on MacOS X, though Apple will not be providing it. Software ports are available from http://www.stepwise.com/. Additional details can be found at http://www.mit.edu/people/wsanchez/papers/USENIX_2000/, http://www.apple.com/macosx/, and http://www.apple.com/darwin/.

Back to my conference reports page

Back to my professional organizations page

Back to my work page

Back to my home page