Yesterday I spent some time at one of the prototype Macs with a Pentium inside. There was one of them with the cover removed. The most remarkable thing was – and, now that photos have leaked, I don’t think I violate any NDA by saying this – that there was nothing remarkable about the box (a standard cheese-grater PowerMac) or about the motherboard (a standard Intel motherboard). There was nothing remarkable about it usage-wise either; unless you looked at the “About This Mac” window, or at the System Profiler Report, or at the Processor preference panel, there was no way of telling what CPU was inside. It ran some unreleased build of Tiger, and there was this huge conspicuous security cable on it for some reason .

But it walked like a Mac, it quacked like a Mac, it was a Mac to all intents and purposes. I downloaded a dozen of random software packages off the Internet, they all just worked – under the Rosetta translator, which I had to see working to really believe in. The perceptual speed was, perhaps, a little faster than my 1GHz PowerBook; quite usable. I suppose this will get faster after a year of tweaking; another word in everybody’s mouth these past days.

Ah, and a bit of news which also leaked out today: Steve Job’s machine was not a souped-up quad processor monster, just the same box I had been using, but with some extra RAM. So, Rosetta is one cool app. I talked to one of the guys on the Rosetta team and he confirmed what I saw happening at the keynote: when you launch an app the second time, it uses the cached translated binary, so it launches much faster.

I looked at the installed libraries, drivers and applications: of course they were all “fat” binaries. The entire system is fat. Oops, sorry, “universal binary” is the politically correct version now. It’s not quite double the size of the standard Tiger installation, but who cares in these days of 100+GB disk drives?

I checked out some of my own projects on the new Xcode 2.1. Nearly all standard Cocoa stuff just compiled and ran with no modifications, no matter what combination of architectures I compiled it for. You can even step-debug PowerPC binaries on this thing, they somehow made gdb Rosetta-aware, so that the translated executable is back-linked to your PowerPC source code; very cool. This is probably a bonus of the Mach-O executable format, like the universal binary format itself. The old Carbon CFM format will run under Rosetta, but not natively; CFM is the new Classic, it seems. The old Classic appears to be dead at last; I suppose getting the Classic compatibility layer running under Rosetta would be a huge pain.

I don’t have any straight Carbon projects to test. I do have one new project that twiddles bytes that flow to and from the disk at a lot of places, because it uses a legacy format (one dating from 1984, by the way). I got most of it converted in less than an hour by scanning for certain source code patterns and putting byte swap function calls around the pertinent expressions. Now, the publicly available Guidelines list dozens of exceptions, where porting takes some extra work: if you use custom resource formats or Apple Events, if you use bitfields, if you want to divide by zero, and so forth. I think the biggest headache will be for whoever has invested time in writing great gobs of code in PowerPC assembly or Altivec; fortunately I never did this myself.

One place where I later lost another hour of work was in a somewhat obscure open source module which made unwarranted assumptions about the order local variables were allocated on the stack. Now, this is something which certainly works for one-off applications, but to actually publish such a thing without calling attention to it, is somewhat foolhardy. This is where many of the conversion failures will come from, I believe; sloppy coding and unwarranted assumptions.