[Title link goes to my Oxford homepage, where you can grab a PDF of my slides and notes]
So yesterday was the UKUUG/Apple tech briefing on the Intel transition. Talking to Eric (Albert, Apple Core OS group) and listening to his talk was very interesting, and gave me new and unexpected insights into the whole business of the transition.
Essentially, the fact that [[NeXT|OPEN]Step|Rhapsody] was already ported to Intel platform hardly helped at all. Or maybe that should be "what Apple did to support the Intel port hardly helped at all", though whether they were right or wrong to use it as they did is not the subject of this post. The reasons are manifold, but largely come down to the fact that technology’s moved on.
Porting a UNIX – especially Mach, which has been seen on so many architectures already – to a new platform these days is a trivial exercise, with a small team of engineers who know the platform well you could probably get up to single-user mode in a couple of days, and have a multi-user networked platform up and running in a matter of weeks. Apple pretty much went back to the starting blocks on the OS X Intel port, because so much of the existing Intel port was obsolete. Even Darwin/x86 (as was) didn’t help here, because although Darwin/x86 and "the Darwin in Intel OS X" target the same architecture, they’re different operating systems on different platforms. None of the existing IOKit drivers are for hardware that’s contained in an Intel Mac (in fact, OpenStep/Rhapsody didn’t use IOKit at all, let alone the fact that no-one wrote an AirPort Extreme driver for them). The processors which OpenStep and Tiger target are completely different – for instance, Tiger doesn’t hit the floating point unit at all but instead uses the vector engine’s floating point support; this effectively means compiling for a different CPU. Even the bootloader has to be different, to speak with EFI instead of the legacy BIOS.
But that’s only part of the problem, it would seem that the higher-level APIs have nothing to gain from older Intel ports either. OK, so OpenStep was designed portable (and largely OS-independent too, but that’s another matter) from the ground up, but Cocoa just ain’t OpenStep. Or rather, Cocoa ain’t just OpenStep. As well as supporting new classes, and the bindings/CoreData stuff, implementations of the OpenStep APIs have been rewritten over the years such that the fact that Yellow Box runs on Intel doesn’t mean that Cocoa will. A specific example, and one I particularly liked, which Eric used was that of NSString/CFString, which now (sometimes) uses UTF-16 as its internal data representation. As does whatever type passes for a text representation in the Carbon world. This is nice, except that when Apple first implemented the UTF-16 support, it seems that some of the people forgot to check for endianness, and some other of the people deliberately ignored endianness (i.e. most UTF-16 is bigendian anyway, and we’re running bigendian cough, let’s assume it’s all bigendian). Bring that representation over to the Cocoa/Intel API, and interesting and humourous results can occur. So you end up having to reimplement NSString anyway. It actually turns out that Carbon (at least, the Carbon API itself; apps are a different matter) can be easier to deal with than Cocoa, because there you just assume that any data you have control over has historically always been bigendian, and you treat it appropriately.
Anyway, it turned out that the amount of time spent on porting Cocoa and porting Carbon, including all the respective applications, was more-or-less the same. Which I find surprising.
