- Table of Contents
- Copyright
- About the Author
- Acknowledgments
- Tell Us What You Think!
- Introduction
- Part I: Introduction to Mac OS X
- Chapter 1. Mac OS X Component Architecture
- Chapter 2. Installing Mac OS X
- Chapter 3. Mac OS X Basics
- Chapter 4. The Finder: Working with Files and Applications
- Chapter 5. Running Classic Mac OS Applications
- Part II: Inside Mac OS X
- Chapter 6. Native Utilities and Applications
- Chapter 7. Internet Communications
- Chapter 8. Installing Third-Party Applications
- Part III: User-Level OS X Configuration
- Chapter 9. Network Setup
- Chapter 10. Printer and Font Management
- Chapter 11. Additional System Components
- Part IV: Introduction to BSD Applications
- Chapter 12. Introducing the BSD Subsystem
- Chapter 13. Common Unix Shell Commands: File Operations
- Part V: Advanced Command-Line Concepts
- Chapter 14. Advanced Shell Concepts and Commands
- Chapter 15. Command-Line Applications and Application Suites
- Chapter 16. Command-Line Software Installation
- Chapter 17. Troubleshooting Software Installs, and Compiling and Debugging Manually
- Chapter 18. Advanced Unix Shell Use: Configuration and Programming (Shell Scripting)
- Part VI: Server/Network Administration
- Chapter 19. X Window System Applications
- Chapter 20. Command-Line Configuration and Administration
- Chapter 21. AppleScript
- Chapter 22. Perl Scripting and SQL Connectivity
- Chapter 23. File and Resource Sharing with NetInfo
- Chapter 24. User Management and Machine Clustering
- Chapter 25. FTP Serving
- Chapter 26. Remote Access and Administration
- Chapter 27. Web Serving
- Part VII: Server Health
- Chapter 28. Web Programming
- Chapter 29. Creating a Mail Server
- Chapter 30. Accessing and Serving a Windows Network
- Chapter 31. Server Security and Advanced Network Configuration
- Chapter 32. System Maintenance
- Appendix A. Command-Line Reference
- Appendix B. Administration Reference
Classic
The next step in the OS X layered model is the APIs that can be used to create applications. Classic, although lumped into this group, is truly an amazing piece of engineering. When Apple released Mac OS X, the company knew that it would be several months before native applications started to appear. Many developers, burned in the past, wanted to see a real shipping product before they committed to porting their applications to Mac OS X. So, how could Apple ship an OS that didn't have any native applications? By creating an environment that would allow any existing Mac OS application to run transparently under Mac OS X.
What makes this truly astounding is that in no way is Mac OS X's foundation even remotely similar to the traditional Mac operating system. Luckily, Apple has a bit of experience with similar situations. In 1994, when Apple made the transition to the PowerPC processor, it knew that none of the existing software could run on the system—including portions of the operating system itself! To get around this, Apple built a dynamic recompiling emulator that, on the fly, would turn existing Motorola 68000-series code into native PowerPC code. It worked flawlessly. When faced with a similar problem in Mac OS X, Apple worked another miracle and created a transparent environment capable of running early Mac OS software.
When Mac OS X Server first shipped in 1998, it included the Mac OS Blue Box. This compatibility environment took over the Macintosh's screen and literally booted a copy of Mac OS 8 within a process of Mac OS X Server. The Blue Box required the user to be in either the server or classic OS environments at any given time—they did not share the same screen space. Although it was fine for occasionally using a piece of software, this arrangement would never fly with Mac enthusiasts. Maintaining two desktops and constantly jumping between environments was far from seamless, and often very confusing.
During the two and half years between the release of Mac OS X Server and Mac OS X, Apple refined the Blue Box, turning it into a Transparent Blue Box, and finally renamed it Classic. Like Blue Box, Classic requires that the system boot a full working version of Mac OS 9.2. After the system boots, what happens next is almost magic.
Upon starting, the Classic application vanishes and the system returns to an idle state. From that point on (until the user logs out), existing applications may be started and run as they would on a pre-X system. Windows from Classic applications intermingle with OS X–native windows, and the OS X Dock updates appropriately with the loaded Classic application.
Aside from a few cosmetic differences, the user cannot tell that Mac OS X is running a complete copy of another operating system just to run his legacy application. In addition to the close integration, applications in Classic also gain access to the OS X I/O system and virtual memory. In many cases, this results in increased application speed and stability. Apple has done such an amazing job of integrating the environments that software that uses video acceleration (such as games) continues to run as normal.
Unfortunately, not all of OS X's advantages are passed on to the Classic environment. Even though many USB/FireWire devices are supported under Classic, there is a large amount of hardware that simply will not work without booting directly into Mac OS 9.2. Additionally, the added stability and performance of features such as protected memory and symmetric multiprocessing are not available in Classic. If a Classic application crashes, it might take down the entire Classic subsystem. Luckily, the rest of Mac OS X will be unaffected, and Classic can easily be restarted.
Although it's only my opinion, there is little doubt in my mind that Apple sees Classic as a necessary evil, but an evil that will eventually go away. After all major applications are ported to native OS X code, Classic will have little to no purpose on the Mac platform. At the present time, it is very much the limiting factor in moving Mac OS X to alternative hardware platforms.
Carbon | Next Section

Account Sign In
View your cart