Hide full article
When Apple acquired NeXT in late 1996 the goal was ostensibly to acquire a next-generation operating system that could replace the Mac OS, since Apple had bought into the notion that the Mac OS was creaky and could barely cross the street under its own steam. As the past two and half years have demonstrated, the most valuable part of the NeXT acquisition was in fact the return of Steve Jobs to Apple's helm. Since Jobs has become interim CEO, Apple has successfully executed a number of daring moves, most notably the release of the iMac.
It's easy to forget that the other effects of NeXT acquisition have barely begun to be recognized. Sure, Apple has talked about a road map to future versions of the Mac OS and has even released Mac OS X Server, but for the most part, we've simply seen improvements to the Mac OS we know well. But if you look back the schedule Jobs laid out at the Worldwide Developer's Conference (WWDC) a year ago, you'll see that Apple has done well at meeting those self-imposed deadlines. Mac OS 8.5 shipped on schedule in Q3 of 1998, Mac OS X Server was only a little late in Q1 of 1999, and Mac OS 8.6 appeared soon after its scheduled Q1 1999 launch. The next major release comes in Q3 of 1999, when Apple plans to ship the next version of Mac OS 8, codenamed Sonata, with the first full release of Mac OS X scheduled for early 2000.
<http://db.tidbits.com/article/04899>
One friend who attended this year's WWDC called it "nicely boring," because along with the schedule, Apple was sticking to the same stories told at the previous year's WWDC. Despite the lack of excitement, that's great news to hear, since developers in the past have griped about paying a lot of money to go and listen to Apple evangelize technologies that would meet the guillotine shortly thereafter. Consistency is good, and for Apple, consistency seems to mean adding underlying improvements to Mac OS 8.x and concentrating on the release of Mac OS X.
Mac OS X Details -- Perhaps the most interesting aspect of Mac OS X for current Macintosh users is that it is slated to support most existing Mac OS 8.x applications, some that won't be able to take advantage of Mac OS X's advanced features, and others that can become full-fledged citizens by sticking to a set of current Mac OS application programming interfaces (APIs) called Carbon, which Mac OS X will support directly. If Apple and Macintosh developers are able to pull off the Carbon strategy, it will truly be a best case situation where existing applications can take advantage of Mac OS X's features without needing complete rewrites. Here are the basic levels in Mac OS X:
Classic: This "Mac OS virtual machine," which replaces the Blue Box (a part of Rhapsody, the precursor to Mac OS X), will let us run current applications that are not Carbon-compatible and thus won't benefit from the advanced features of Mac OS X. At WWDC, Apple showed Classic applications running in their own windows, not all together in a single Blue Box window as previously shown.
Carbon: Applications compiled for use with Carbon will run directly under Mac OS X, taking advantage of protected memory, preemptive multitasking, and other features of Mac OS X. Carbon is important to Mac OS X's success, since Apple claims it's easy to make existing Mac OS applications Carbon-compatible. Some developers dispute the ease of making an existing application Carbon-compatible, but none argue that it will be easier than porting to Cocoa or rewriting from scratch.
Cocoa: Applications written for NeXT's OpenStep (perhaps with some tweaking) and future applications written specifically to Mac OS X take advantage of all of Mac OS X's features. This native layer of Mac OS X, previously called the Yellow Box, is now called Cocoa. Cocoa will also offer advanced support for Java.
Command-line: Yes, Virginia, there will be a command-line option in Mac OS X for working with command-line Unix applications. For the sake of most Mac users, we hope it's a totally ancillary interface.
This combination of the best of the Macintosh with the best of NeXT's operating system technology sounds great in theory, but as Mac OS X's release date looms closer, concerns arise. Most of the public moves from Apple have focused on improving the Mac OS and releasing new Macintosh hardware. But all those employees who came over from NeXT haven't been sitting still. They may wear Apple badges now, but it's possible that on some levels these people are more interested in turning the Macintosh into a NeXT-like system than in making a Macintosh system built in part from NeXT technologies. I commented on this back in 1997, when the lines between Apple and NeXT technologies were more distinct. Things have blurred since then, but a sense of NeXT/Unix mentalities being forced onto Mac OS X still remains.
<http://db.tidbits.com/article/00694>
Examples of this unsettled feeling broke the surface at this month's WWDC. In each case, Apple has made promises about maintaining the best of the Macintosh, but after discussions with Macintosh developers, we're left with concerns about how the situations will play out in reality. Consider the following:
Carbon Finder -- At WWDC, Jobs and Apple vice president Phil Schiller showed the "Carbon Finder," a version of the Finder rewritten from scratch. Unfortunately, on the surface it bore little resemblance to the Finder that tens of millions of Macintosh users use every day, and the audience greeted it with a combination of hisses and silence (comments after the keynote were even less polite). Instead, the "Carbon Finder" looked like an updated version of the NeXT Workspace Manager file browser (see the Macworld Online picture linked below) that was used by at best tens of thousands of people in NeXT's heyday.
<http://macworld.zdnet.com/1999/05/02/wwdc/ photogallery/wwdc5.html>
It seems that with proper settings, the Carbon Finder could be made to look like the current Finder, and it should provide a better interface for network browsing than the Chooser or even the Network Browser, which isn't part of the Finder. Apple has long needed to resurrect something along the lines of the PowerTalk Catalog, a desktop icon that provided access to networked servers (see "PowerTalk Arrives" from TidBITS-195 for description).
There's nothing wrong with multiple pane file browsers, but they often aren't as flexible as today's Finder. No one minds Apple providing a file browser as an option, even as a View option, but if Apple attempts to replace the Finder with a less-capable file browser, current Mac users will revolt. For a preview of a file browser, try Greg Landweber's shareware utility Greg's Browser.
<http://db.tidbits.com/article/02403>
<http://kaleidoscope.net/greg/browser.html>
The Yellow Brick Pathname -- Mac OS X is based on Unix, and one of the basic aspects of Unix is a reliance on special directories with cryptic names like /bin, /etc, /usr, and so on. That's not all that different than the Mac OS's reliance on special folders like the Extensions, Control Panels, and Preferences folders. The main difference is that Unix file systems rely on pathnames not just for the special directories, but for all directories. In contrast, the Mac's HFS and HFS Plus file systems assign every file and folder a unique ID number. The beauty of file IDs is that their independence from names and paths allows a level of abstraction that's not possible under Unix. For instance, if you rename the folder that contains your applications, everything works as it did before, because file IDs don't change. In Unix, such an action would cause all pathnames to change, in turn causing applications to lose track of support files.
In addition, it's possible on the Mac to have multiple volumes with the same name, something that doesn't come up with Unix (where the root level is always /) or Windows (where every volume has a unique letter). The impact of losing the capability to have multiple volumes with the same name could range from annoying to disastrous.
Mac OS X is slated to support HFS Plus by default, so file IDs should continue to work on disks that use HFS Plus. However, the fact that standard NeXT programming practices encourage pathname use may result in file IDs not being used. It's also unclear what will happen when sophisticated users move back and forth between the different file systems also supported by Mac OS X. Even mentioning multiple file systems to most Mac users is a bad thing, so let's hope Apple manages to hide the entire situation from normal users.
What's Your Type? Mac OS X, being Unix, may also rely in part on filename extensions to assign types to files, just like Windows. A GIF file must have a .gif extension, a text file must have a .txt extension, and so on. The Mac OS instead uses file type and creator data structures to type files, so although you're welcome to add .gif to a GIF file's name, the operating system identifies the file as a GIF based on its file type code, not its file name.
Another feature Macintosh users expect is that files of the same type can open in different applications when double-clicked. One text file might open in SimpleText, whereas another might open in BBEdit or Nisus Writer. In Unix, as in Windows, files of the same type can be linked only with a single application. Aside from the obvious loss of functionality here, there's a loss of control for the user. Suddenly, you must name your files correctly or they won't work as you expect. I can't imagine trying to explain to my grandmother that every file she creates must have a specific set of characters at the end of the filename. Applications could add them automatically, as many Windows programs do, but that's also confusing.
Again, since Mac OS X will support HFS Plus, type and creator codes will probably be retained at least when using an HFS Plus file system. Expert users are curious how Mac OS X's Unix utilities will interoperate with HFS Plus volumes, since it's unlikely that the Unix file copy command cp, for instance, would retain type and creator codes when copying files on an HFS Plus file system.
To Text or not to Text -- As a final concern, consider the humble preferences file. Normal Macintosh users seldom interact with their preferences files directly, because it's an accepted tenet of the Macintosh world that applications must provide an interface to their preferences. In the Unix world, though, text-based preferences files rule.
As a friend has noted, attempt a real Apache configuration in today's Mac OS X Server and you're in vi (an arcane Unix text editor). Want to change a setting? Just edit the appropriate line in this text file! That may work fine for Unix power users, but it's a recipe for disaster in the Macintosh world. Text-based preferences files are brittle; make a single character mistake and the application won't behave as you expect.
Of course, an application could provide a graphical interface to its preferences and save the results in textual form, but as we've seen in programs ported from the Unix world, once there's a text-based preferences file in use, creating a graphical interface becomes a low priority and may never happen.
Reading the Cocoa Leaves -- These concerns are for the moment just that, concerns. Mac OS X isn't scheduled to ship for at least seven months, and since Mac OS X Server slipped from Q3 1998 to Q1 1999, it's entirely likely that the full Mac OS X will slip as well.
That gives Apple time to make sure that Mac OS X truly incorporates the combination of the best features of the Mac OS (the user experience) and the best features of the NeXT (modern operating system features). Steve Jobs has called the Mac OS Apple's "crown jewels," saying that Apple had to concentrate on the Mac OS because that was where the company's customers were. No one bought Macs during Apple's death spiral days because they cared that Apple would one day release a totally different operating system. They bought Macs then, as they do now, because the Mac OS remains the best computing experience available today.
I sincerely hope that Jobs wasn't buttering up existing Macintosh users merely to bolster Apple's then-waning fortunes, because his comments then were on target. As good as aspects of the NeXT may have been, it was not a commercial success, whereas the Macintosh changed the face of computing. Keep the Macintosh face, Apple, and utilize the NeXT technology behind the scenes where it can work its magic without disturbing millions of Macintosh users.
