Compatibility. There is currently a disparity in the number of APIs in the Carbon specification that have actually been implemented between Mac OS 9 and OS X. The CarbonLib SDK, a free download from Apple, includes both the CarbonLib stub library and a library called LiteCarbonLib, which contains only those calls that currently work on both Mac OS X and OS 9. These libraries are 204 and 124 k respectively, which is a very crude measure of the difference between the two.
Having a carbonized app work in Mac OS 9 is no guarantee that it will work in DP4, even if you do use “safe” Carbon calls. For example, while writing my app to benchmark CopyBits, I discovered that it worked fine in OS 9 or even the Classic environment but did not work in OS X as native app. Here you can see it in OS 9 and in OS X.
The CarbonLib SDK comes with several sample apps. Not even all of these work correctly in both OS 9 and OS X. Moofwars, a program that ran but didn’t display sensible graphics in OS 9, would quit without explanation in OS X. I noticed it was missing a carb resource, which is needed for all Carbon apps, and after adding that with ResEdit, it would run but display nothing more than a blank window.
Appearance Sample is an impressive but utterly useless app meant to demonstrate some human interface guidelines. Here it is in OS 9 and in OS X. As you can see, there are some problems with the names not fitting in the buttons under OS X. (This is probably because Apple shrunk the size of the buttons and some other interface elements between DP3 and DP4 so that they would be the same size in OS 9 and OS X to appease developers.) Also, “Dessert Topping” is cut off.
OS X DP 4 comes with Internet Explorer 5.1b1, a carbonized version of IE 5. This program was obviously designed with the old Aqua layout guidelines; here is a screenshot of the about box. It will open in Classic, but it will quit shortly after asking you if you want to make it your default browser. I did manage to open it in OS 9; here’s what it looks like there.
SpeedI wrote a pair of benchmarking apps. The first tests the speed of CopyBits, a vital graphics command for displaying graphics on the screen. The second tests the speed of NewHandle and DisposeHandle, which are important commands for allocating memory. Here are the results, in ticks. Lower is faster.
|OS X in Classic||546||8|
Want to know more about how the benchmarks were done?
Stability. Wrote an evil little app (source) that starts at the first address and works its way up, garbling all the memory as it goes. When run in classic, it immediately crashed and also brought down the entire classic environment and all the apps in it, not surprisingly. But when run natively in OS X, it only brought down itself. Looks like the memory protection is doing its job.
AppleScript is there and mostly working. I could not open the dictionary of any application; it would always give me a miscallaneous error. Furthermore, the Finder is not yet scriptable. However, simple scripts did work, and seemed to go faster than in OS 9.
Starting apps is still quite slow. Opening the Quicktime Player took 11 seconds, compared to 3 seconds in OS 9.
ProcessViewer, the Console, and Terminal.app are still available. There is also a Setup Assistant which is very similar to the program of the same name under OS 9. Here’s a screenshot of all four of them, starting in the upper right and proceeding counterclockwise. The Console has some ominous messages in it!
When you open an application in OS X DP 4 and then shif to something else, when the application finishes opening you are automatically sent there. This is reminiscent of Windows, and you may consider it either a feature or a bug. I find it bothersome, since if I’m typing the application will interrupt that.
OS X now integrates the OS X Finder with the Classic Finder. For example, choosing Control Panels from the Apple menu of any Classic app brings up the control panels folder in the OS X Finder.
All in All
Apple seems to know what they did well in the Mac OS and appears to be trying to reproduce those benefits in OS X. The command keys are still equivalent across apps, and now the Preferences menu item has a standard place (IE 5.1b1, in classic Microsoft style, eschews the proper place, leaves the Preferences item dimmed under the Application menu, and implements its own under the Edit menu. To be fair, it is unlikely that they will keep this in the final release.) The Finder preserves and strenghtens the incredible and unmatched file manipulation tools of the Mac OS. AppleScript, while somewhat broken in DP4, is obviously slated to be a feature. The open and save dialogs now implement a “mini-Finder,” which is excellent from a consistency point of view (a unified method of choosing files means a smaller learning curve).
Unfortunately, Apple is picking up some new interface stupidities and inconsistencies. The inability to click on the bottom of icons in the dock is a small but important example that combines the worst of multiple menu bars with the worst of a single menubar. The fact that the root folder is not a folder is also reminiscent of the ugly parts of Windows. The “single window mode” button never seems to be useful and takes up window real estate. While the three window widgets are far enough apart to minimize mistaken clicks, choosing the wrong button could be prevented almost entirely by moving the close box to the other corner of the window, like the classic Mac OS. Windows cannot be resized or moved by their borders, which is a feature sorely missed when the resize handle is obscured by the dock.
Apple, to its credit, has learned from both its own successes and its mistakes, and is also willing to experiment to push the frontiers of user interface design ahead. But it does not appear to have learned from the mistakes of other companies, like Microsoft, and will doom its users to suffer if it does not fix them before the first full version ships.