I stopped believing in the “it will just recompile option” many hours of unpaid overtime ago. There’s almost always going to be some amount of work necessary for supporting a new architecture. Maybe the code will recompile fine, but you’ll need to optimize certain operations for the new processor because the old instructions now run X times slower. There’s always going to be something.

As for the Copland/Star Trek fellow, I wouldn’t put a whole lot of stock into what he says. I’m still not entirely sure what point he’s trying to make and I’ve had 2+ months to look at the damn thing.

Carbon would port to Intel just fine. It’s C and C++ code. It’ll recompile just as nicely as Cocoa will. And it had better, because Cocoa depends on Carbon.

That doesn’t mean there will ever be Mac OS for Intel. Apple sells computers with design features which command high margin. Show me a way for Apple to make high margin on Intel-based computers and then we can talk about the hurdle of recompiling all the apps so that Apple can make computers which… work exactly the same as far as users are concerned. Why were we pining for this again?

No, it’s not difficult for a ported Carbon app to move from CFM to Mach-O. I’d be surprised, though, if Apple didn’t take the opportunity to move to a new executable file format for this mythical Intel machine. Everyone but the one Mach-O engineer (is he still hanging on?) agrees Mach-O is crap.

And no, Carbon’s lineage is not Copland or Star Trek. It’s QuickTime, if anything, but in truth that was just for the initial demo, and then pretty much everything got rewritten.

Where people get these ideas is beyond me. Oh yeah, I forgot: They make them up to feel well-informed.

However, I don’t like deleting comments, so it stayed posted.

BBEdit has had syntax coloring since at least version 4. If you don’t mind a little programming, you can add your own syntax modules. There are already various third-party modules available, such as SQL.

My point still stands — you can switch Carbon apps to Mach-O so CFM isn’t a hard and fast barrier tying all Carbon apps to PowerPC.

Like I and others have said, though, it looks like this is a moot point. Apple’s not switching to Intel. Carbon’s not going away.

Mac on Intel’s not going to happen. It looks like IBM’s developed a higher performance PowerPC chip (the 970) that will simultaneously boost the speed of Apple’s systems and not require radical changes to existing programs.

“How likely is it that, if Apple release a version of OS X for Intel chips, Carbon will be available?”

It’s not even possible. Most Carbon apps use the Code Fragment Manager, which makes heavy use of direct PPC calls. Because Mac OS X doesn’t allow such direct calls any longer (in contrast to Mac OS 9), Carbon/CFM apps are slower than Carbon/Mach-O apps (those that call the Mac OS X Mach-based kernel instead). Mozilla builds with Carbon/Mach-O were about 30% faster than Mozilla builds with Carbon/CFM.

Not only that, but CFM on x86 would mean absolute emulation of lots of system calls. Do you want an emulated Photoshop? I think it’s slow enough when it’s “half-native”, as it is now.

Besides, Mac OS X on x86 is not going to happen, if only because x86 is a dying architecture (ever heard of AMD64 and IA-64?).

“There?s no portability problem with Carbon that does not also exist for Cocoa.”

Yes there is, CFM. Cocoa builds are always Mach-O; Carbon builds (when ported from Mac OS 9) cannot be, because Mac OS 9 doesn’t support Mach-O for obvious reasons.

And, Nat et al: There’s no portability problem with Carbon that does not also exist for Cocoa. Carbon is not a 68k emulator and does not contain one. Carbon apps are usually written entirely in a high-level language. The Carbon framework itself is written entirely in C and C++ and was derived from Mac OS 9 via Copland via Star Trek. It has been ported to x86 before and would be ported again if Apple wanted to do OS X for x86. Too much of the core technology of OS X is built on Carbon, whether Stoner likes it or not.