[__^^__]

I notice a number of people asking Carbon programming related questions. My question is how long will Carbon be supported by Apple? Wasn't Carbon meant to be a quick fix for programmers to migrate their Classic apps to OSX? I wonder how much Carbon will be supported on the Intel Macs..

[Chuckit]

You are mistaken about what Carbon is. Much of OS X's main functionality is provided by Carbon.

[Angus_D]

Whilst it is true that Carbon was initially proposed as a "transitionary" API or something along those lines, it has been clear for some years that Carbon is a first class citizen on Mac OS X. In fact, Carbon has evolved and changed and been modernised a considerable amount over the last few releases (particularly in Jaguar and Panther).

Carbon will be supported on the Intel Macs.

[graffix]

I hate to disagree, but Carbon is a depracated API.
It was only intended as a transitional API, much as the 68k emulation layer was during the transition to PPC. As an example, QuickDraw has already received it's death notice, and it's the primary drawing method for Carbon applications
Also, Carbon has a lot of PPC-specific routines that won't translate well to x86, though they will probably still function via Rosetta, but will not be able to be natively compiled for x86.

[Dair Grant]

graffix, there isn't a single correct statement in your post (apart from QuickDraw being deprecated, and even that's half-wrong given that any modern Carbon app draws with Quartz).

Would you care to name a "PPC-specific routine that won't translate well to x86"?

[tooki]

Besides, as I recall, the very long-term plan is to ultimately merge the two APIs, not to decide on one or the other.

Carbon is in no danger whatsoever.

tooki

[graffix]

You guys are right... any app coded with XCode is in no danger.
It's the Carbon Apps coded with Metrowerks Codewarrior that are going to have problems.
Looks like I've gotten a bit confused with all the hubbub surrounding the transition.
Sorry.

[tooki]

They're in no danger, either -- they just need to be moved over from CodeWarrior, which does not entail rewriting the app from scratch.

And it's not just Xcode -- other development environments, such as RealBasic, will also transition seamlessly.

In fact, it's only CodeWarrior apps that are really going to involve much work, and that's simply because CodeWarrior no longer has an Intel compiler.

tooki

[Person Man]

Originally Posted by tooki

In fact, it's only CodeWarrior apps that are really going to involve much work, and that's simply because CodeWarrior no longer has an Intel compiler.

tooki

Not surprising, when you consider who bought Metrowerks in the first place.

[Millennium]

Originally Posted by __^^__

Wasn't Carbon meant to be a quick fix for programmers to migrate their Classic apps to OSX?

That was originally the plan back in the days of Rhapsody DR2, but things changed very quickly when the major developers threatened to leave. They didn't want to have to rewrite their existing codebases for Cocoa. By the time of OSX 10.0 this idea of "Carbon-as-quick-fix" had been abandoned, but two of Apple's most important apps -the Finder and AppleWorks- were so badly ported that they have damaged Carbon's reputation undeservedly ever since.

Carbon has since been developed into the "low-level" API for OSX, while Cocoa is the "high-level" API. The plan is to eventually merge the two, with Cocoa written as a layer on top of Carbon such that the two APIs run down a single code path; this stands to improve both APIs by allowing each to play off the strengths of the other. Work on this has been going since the 10.2 days, but it's far from complete.

As for whether Carbon will be supported in OSX/Intel, this depends. Carbon/Mach apps -those which were compiled for OSX only- will certainly be supported. Carbon/PEF apps -those which were compiled to be run on both OSX and OS9- are less certain; they might be supported through Rosetta, but you can't compile x86 apps in this format (and they wouldn't run on OS9 anyway)

[Dair Grant]

As for whether Carbon will be supported in OSX/Intel, this depends.

Well, not really - the question is if Rosetta will support the PEF (i.e., CFM) executable format. The x86 version of Tiger will support Carbon in the same way the PowerPC version does, i.e., it will.

That might seem like splitting hairs a bit, but there is a distinction between Carbon (the Mach-O programming framework) and CarbonLib. CarbonLib is a CFM implementation of the Carbon API that provided an implementation on Mac OS 9 and simply forwarded API calls on to the native Carbon.framework on Mac OS X.

Initially, "Carbon apps" ported from 9 to X would be better described as "CarbonLib apps" - they use the Carbon API, but talk to it through an intermediate library.


The question is if CarbonLib (or really CFM) will be supported on Intel. As it happens, Rosetta will support CFM applications according to the current "Universal Binary Programming Guidelines" document (that may change before release, but it seems unlikely).

This is really for backwards compatibility - enough time has passed that dropping Classic is no longer a problem, but the fact that significant apps (Photoshop CS 1) still use the CFM executable format mean that it's going to be around for a while.