The Death of Carbon

Despite what some die-hards say, Carbon is not native OS X code.

Carbon is an alternative API for OS X. It is not part of either NeXTSTEP or the OpenStep specification. And it was not originally designed into what came to be OS X.

The original idea for OS X was to let archaic MacOS applications run in a virtual address space of their own and otherwise concentrate on the new OS. There are many reasons for this, not the least of which is that this old MacOS code was 16-bit and not secure in any way shape or form. MacOS was a standalone system incapable of any of the security features of a true operating system.

MacOS code would run through a thunking layer: 16-bit calls would be fixed into 32-bit calls and then pushed into the 32-bit world; responses from these calls would then be squished back to 16-bit before returning control.

Because the old 16-bit MacOS code was not reentrant, precautions would have to be taken to ensure that only a single thread at a time had access to the old system. This of course would slow things down considerably.

The big hitch with this of course is that it's not really secure and it's not really that fast either. But by running all MacOS applications in the same virtual address space the OS X system itself could be protected.

But as this old code was on its way out (precisely as 16-bit Windows code disappeared) this was a temporary annoyance and no more.

The trouble started when Apple announced their plans to their third party vendors. Totally fixed on the idea that something like 'Copland' would supersede, these people refused to accept a situation where they'd have to rewrite their products if they wanted to really get on the bandwagon. While MacOS apps would run in their protected environment, they would look exactly as they'd always looked - and gain none of the benefits of the new OpenStep port. Aware they were asking to have their cake and eat it too didn't make a difference: they insisted on a solution.

And they got one. Apple began work porting the old 'toolbox' code to a new API so MacOS applications could get in on some of the goodies. Not all of these goodies would be accessible of course: as Lotus have claimed time and again, some things are simply not possible without the NeXTSTEP API. But a compromise was possible, although it would take the better part of five years to implement.

Five years that saw Apple miss all their last call golden opportunities. In these five years Microsoft consolidated their position as market leaders with Windows 98, Windows 98SE, Windows Me, Windows NT, Windows 2000, and Windows XP. Microsoft were able to release all these products while Apple essentially released nothing. The battle was over before it began.

Attempting to hot-wire a procedural API into a sophisticated object oriented framework is of course folly, and undoubtedly the NeXT engineers at Apple took on their tasks begrudgingly. But there are also several significant steps that were necessary before they could even begin to consider such a task.

Somehow they needed to 'extrapolate' the functionality of the base classes to an underlying procedural API. That is to say they needed to yank the code out of their classes, move it to standalone functions, and replace the code with calls to these new functions. When one considers the NeXTSTEP API is approximately four times the size of the colossus Windows one gets an idea of how much work this entailed.

Once Apple had their procedural APIs in place to support the NeXTSTEP classes, they could begin to wire in MacOS 'toolbox' code. Names for these functions were chosen to afford as smooth a transition for third party developers as possible.

It's important to understand that not everything could be migrated to this new layer. In particular the graphics seen today in Carbon are obviously not the same as otherwise used in OS X. Also, the interactivity of ordinary OS X applications cannot be achieved by Carbon apps because they don't access the same frameworks.

Another element of Carbon often referred to is the layer that has to do with MacOS specifics - things that don't fit into the OpenStep specification, things that are not eminently portable. As long as the architecture of OS X includes these elements Carbon will be the way to access them.

But here's an important point: for while ordinary OS X applications can access anything in Carbon, it doesn't work the other way around. The examples of this are too numerous to mention. At the end of the day Carbon was an imprudent compromise to Apple's third party vendors who refused to go back to school.

A lot of major players balked at doing anything at all. Adobe saw the market statistics and seriously wondered if they should support the platform anymore: the money simply wasn't in it. Likewise Microsoft were hardly going to devote any time to a platform that promised at best a 2-3% market share.

There's no doubt this code could easily be integrated into ordinary OS X products, but even this minimal effort was not financially justifiable. Adobe customers got last year's 'PEF' executables wrapped by Carbon instead of space-age apps like some of the other players were churning out.

The hurdle to 'native' OS X programming is not very steep. Learning the Objective-C programming language takes a couple of hours. It's so well designed that things go that fast. And once that part is accomplished, the developer tools take over and finish the job.

Any number of these classic (legendary) NeXTSTEP tools were made over to afford a modicum of functionality for Carbon applications. The file extension 'XIB' is for example an indication that a 'Carbon' NIB file is in use.

There's no point claiming that old code - which has to be upgraded to 32-bit anyway - is going to be that difficult to wrap in 'native' OS X code. It's just not that difficult. And considering the platform's been out for so many years already, there is simply no excuse - except that of 'money', and even that is pretty thin.

There's a lot of talk about whether Carbon survives the transition to Intel. Yes it survives. There are elements of the API which will not work directly with the file system and other parts of the hardware, but up to now Apple have been able to make these elements work through emulation. The 'MacOS' layer won't survive, but Carbon shouldn't have an issue.

There's of course a bottleneck here, and that bottleneck is Apple's insistence on hardware lock-in. No one may run anything but OS X on their Apple computers (except Windows today) and no one may run OS X on any other hardware. There is just no way Apple will ever get any significant market share with that attitude.

Once was the time Apple were going to go after both the hardware and software markets individually and try to dominate them both. And with the attention to detail and the reputation for quality the company had, they had all chances to succeed. And this was when the first NeXT engineers had already come over from Redwood City to Cupertino. When Steve Jobs was just a 'consultant' at Apple.

When Steve Jobs replaced Gil Amelio as CEO of Apple in July 1997 everything changed abruptly and completely. There was to be a hardware lock-in again. And this lock-in has persisted ever since. And with that lock-in Apple will never gain adequate hold of either the hardware or software markets.

It is because of this lock-in - and consequent single digit market share - that the major players in the market won't make the transition to 'real' OS X development and other major players not yet in the market won't even consider it.

There's no doubt that the OS X development model is head and shoulders above any other model found anywhere - especially at Apple - and would save millions in development cycles, produce far more feature-rich, stable, and secure products, and decimate traditional time to market calculations, but what the major players are comparing that with is the alternative of 'doing nothing'. That takes even less resources and has an even faster time to market. Were OS X truly a platform to invest in - a 'gorilla' as Microsoft are often referred to - then there's of course no question what would happen. But as long as Apple stick to hardware lock-in, things will be stuck in this transient and unsatisfactory state.

[This of course is the same dilemma facing Apple's hardware vendors such as IBM: there's simply no money in making processors for a company with a 2-3% market share. What do Apple get stuck with? The bottom of the heap: Intel. Ed.]

No Carbon developer who's seen what's possible on the other side of the fence would stay a single nanosecond if given the go-ahead. You get decidedly better apps, much more security, much more stability, it's less work plain and simple, you get a pile of super-cool and helpful features that are otherwise impossible - there's only one thing holding them back.

Apple.

So instead of using the API Apple paid $429 million for and instead of using the space-age 64-bit PowerPC processors everyone assumed they'd be still using, Apple are today a company with a legacy compatibility platform and second rate 32-bit processors all over again.

And it's all because of the hardware lock-in.