MACWORLD EXPO, SAN FRANCISCO—January 9, 2001—Apple® today announced that Mac® OS X, the next generation Macintosh® operating system, will ship on March 24, 2001 for a suggested retail price of US$129. Announced in July 2001, the iMac (Summer 2001) represented a minor change to the existing iMac line, and represented a shift back to a more conservative color-scheme. The iMac (Summer 2001) was initialy available in three configurations. The 500 MHz model, with 128 MB or RAM and a 20 GB hard drive was $999, and was available in Indigo and Snow.
Learning to live with Mac OS X Mac OS X's Finder: love it or loathe it, the two points that unite almost everyone who has used Apple's next-generation operating system are that it's not up to scratch and that Apple's reason to write it using OS X's Carbon API is the chief reason why.
No, say so many observers, Apple should have written Finder using OS X's other API, Cocoa. But is that really the case? Certainly Carbon seems to be getting all the bad press, while Cocoa is being held up as some sort of shining beacon lighting the way to 'true' Mac OS X native apps.
Bollocks, says one ex-Apple software engineer of our acquaintance who has no small knowledge of the beast. 'Carbon is at the same level as Cocoa, and they are both built on the same underlying foundation. They are absolutely true peers of each other,' he says. 'One can do things that the other can do and vice versa, but there's no reason why a well written Carbon app can't be just as good as a well written Cocoa app.
'Rewriting the Finder in Cocoa is not the answer.'
Apple of my API
Carbon and Cocoa are OS X's two Application Programming Interfaces (APIs). Both are frameworks around which coders can weave applications and utilities that are able to take full advantage of the new operating system. Cocoa's origins lie in NeXT's NeXTSTEP operating system, later reborn as a cross-platform programming framework called OpenStep. It's an object-oriented framework programmed in Objective C or, since Apple bought NeXT, Java.
With almost all of Apple's senior software staffers ex-NeXT, it's nor surprising that Cocoa has gained a reputation as the way of producing native OS X applications.
Carbon, on the other hand, has often been portrayed as Cocoa's lesser sibling. Carbon was only developed because some of the biggest Mac software developers balked at being forced to rewrite their code from scratch. That's what they would have had to do under Apple's original next-gen operating system plan: rewrite their apps to work with Cocoa, then called Yellow Box, or leave them as classic Mac OS apps but have the run without any of the benefits the new, Unix-based OS brings.
No wonder, then, that Carbon has always seemed little more than a kludge to shoehorn OS 9.x code into OS X, done to allow software vendors to port their apps over quickly with just a few modifications.
Carbon ain't no kludge
'Rewriting the Finder in Cocoa is not the answer.'
Apple of my API
Carbon and Cocoa are OS X's two Application Programming Interfaces (APIs). Both are frameworks around which coders can weave applications and utilities that are able to take full advantage of the new operating system. Cocoa's origins lie in NeXT's NeXTSTEP operating system, later reborn as a cross-platform programming framework called OpenStep. It's an object-oriented framework programmed in Objective C or, since Apple bought NeXT, Java.
With almost all of Apple's senior software staffers ex-NeXT, it's nor surprising that Cocoa has gained a reputation as the way of producing native OS X applications.
Carbon, on the other hand, has often been portrayed as Cocoa's lesser sibling. Carbon was only developed because some of the biggest Mac software developers balked at being forced to rewrite their code from scratch. That's what they would have had to do under Apple's original next-gen operating system plan: rewrite their apps to work with Cocoa, then called Yellow Box, or leave them as classic Mac OS apps but have the run without any of the benefits the new, Unix-based OS brings.
No wonder, then, that Carbon has always seemed little more than a kludge to shoehorn OS 9.x code into OS X, done to allow software vendors to port their apps over quickly with just a few modifications.
Carbon ain't no kludge
That's the wrong way to look at it, says our correspondent: 'The Carbon engineers have done an amazing job. The fact that you can run the same application on both OS 9 and OS X is a really amazing thing that should be celebrated, not called a kludge.'
Digging into the details of both Carbon and Cocoa and you can soon see what he means. If you're interested, check out O'Reilly's Learning Carbon and Learning Cocoa. Written by Apple, they're not the most friendly of programming manuals (what I want is a Carbon-specific answer to Jim Heid's great but now very dated Programming Starter Kit for Macintosh) but right now they're the best there is and the certainly provide a good introduction to the two APIs.
Cocoa provides a solid development framework, particularly when supported by the developer tools Apple ships with Mac OS X. Getting your head around object-orientation isn't easy. But if you've spent some time with RealSoftware's RealBasic, which works broadly like Apple's Project Builder but operates in a much more intuitive way, you'll have a good idea how it works.
OOPs upside your head
Object orientation programming (OOP) is an approach to coding that essentially breaks applications down into self-contained modules that contain not only data but the code to manipulate that information. A Mac OS window is ultimately just data (size, position, style, content, etc.), but in a OOP world, it's an self-contained object that knows not only what it looks like (the data) but how to behave - how to close, how to hide, that kind of thing. Brain storm (kaletvx) mac os.
Actually, a lot of Mac OS apps are already built around an OOP framework, Metrowerks' PowerPlant and written using C++, like Java and Objective C another object-oriented programming language.
PowerPlant was, of course, designed for the Toolbox, the classic Mac OS' own API, adding an object-oriented layer to Toolbox's traditional, linear framework. Since PowerPlant now supports Carbon coding it's perfectly possible to do build object-oriented Carbon apps. And Carbon is essentially just a modified version of the Toolbox API, it's immediately familiar to anyone who has written Toolbox apps in C.
Park (2001) Mac Os Update
And, as our correspondent points out, 'Carbon is evolving'. Toolbox was developed for systems running one application at once. Multifinder and later kludges to allow multiple apps to run alongside each other aside, that's essential what Toolbox is: a one-app-at-time system.
Park (2001) Mac Os X
Event horizons
OS X isn't. Based on Unix, it expects to have to support umpteen processes running in parallel, often for multiple users working on the system at the same time. That requires a very different approach to interacting with the user, one where apps don't look out for your clicks and key presses but wait for the OS to tell them what the user has done.
Carbon can work with both of these 'event models', but to get the most from it code needs to be written with the OS X event model in mind. 'The new Carbon Events API is very powerful and as applications adopt it, rather than just doing straight ports of their old apps, we'll see very nimble applications appearing,' says our correspondent.
'What you should be pushing developers to do is not to throw away their existing apps and rewrite them in Cocoa, but to get them to embrace the modern Carbon APIs. It doesn't make any financial or engineering sense to start again from the beginning when they are 90 per cent of the way there already.
'The key thing is, Carbon is designed to be a compromise on OS 9, not a compromise on OS X. It's designed for OS X first, and then things are brought back to OS 9 and made to work the best they can.'
Carbon and Cocoa: peer to peer
So much for Carbon being unequal to Cocoa. Actually, the reverse may be true, whatever the ex-NeXTers may think. 'I've used both, and I've found I'm much more productive writing code using Carbon and CodeWarrior rather than Cocoa and Project Builder.'
In short, if there's a problem with Finder, it's not that it's written using Carbon. No, it's that it needs tuning and optimising. And, credit to Apple, that was the company's key message at last May's Worldwide Developers Conference. Recompiling an application to support Carbon is only the first step - next comes the real work: reworking it to support OS X's design philosophy and thus making at true Carbon - and a true Mac OS X - application. ®
To be continued..
Related Links
O'Reilly's Mac books site
RealSoftware's RealBasic homepage
Earlier Episodes
3. Windows XP hits where Apple's Aqua misses?
2. Mac OS X crashes: Radeon not guilty
1. Mac OS X: Reg box stable - at last..
