Carbon vs. Cocoa

Yesterday I posted a link to Todd Bishop’s More on Mac BU. Among the comments to Todd’s article is a question I’ve seen and heard before: When is Microsoft going to port Office to Cocoa? The question, the frequency with which it gets asked in various venues and the common tone that suggests Carbon is a second-class citizen to Cocoa’s aristocratic blood-lines, all suggest that there’s still a great deal of misunderstanding out there regarding these two technologies.

Application Environments

That Carbon plays second fiddle to Cocoa’s first chair in the orchestra is a serious misconception. To understand why, we first need to discuss what constitutes an application environment. Apple’s System Overview offers a summary view of the application environments available on Mac OS X. They further provide a definition of application environment as “the frameworks, libraries, and services (along with associated API) necessary for the runtime execution of programs developed with that API. The application environments have dependencies on all underlying layers of system software.” The full discussion can be found here.

While the two environments involve different system frameworks, the primary difference between the two is the extent to which the application programmer is responsible for mundane, house-keeping tasks. Under Carbon, for example, the application programmer is responsible for implementing various carbon event handlers that respond to user actions like mouse clicks, key presses and menu selections. Under Cocoa, much of these low-level house-keeping tasks are handled by the Objective-C framework, freeing the application programmer to concentrate on overall application logic.

The downside of Cocoa is that it’s extensively tied to the Objective-C language. Carbon, on the other hand, is largely language independent. If a programmer is implementing a new application from scratch, Cocoa makes sense. If, on the other hand, the programmer is porting thousands, or, in the case of Office, millions of lines of C and C++ code, then Carbon is the obvious choice. There’s little benefit to be gained from rewriting those millions of lines of code to work within Objective-C, particularly the C++ code.

In this regard, it’s worth noting that Apple chose to implement the OS X Finder as a Carbon application. Project Builder, and XCode for Panther, on the other hand, are Cocoa applications. It made sense to write them in Cocoa because there wasn’t an existing code base already tied to older APIs.

Despite the nature of the APIs and/or object-oriented support in the two environments, the choice between Carbon and Cocoa is really a matter of the programmer’s preference. Those preferences are not necessarily limited by an existing code base. Familiarity with a given set of APIs and/or relevant programming languages (e.g. RealBASIC) also play a role in any given developer’s choice to write for Carbon or Cocoa. What doesn’t play a factor in the decision, however, is the quality of the user experience.

Executable Formats

Carbon isn’t the only technology Apple has implemented in OS X in order to facilitate the porting of legacy applications from Mac Classic. The other technology is the Code Fragment Manager (CFM). CFM is the Mac Classic method of using shared libraries, and is based on the Preferred Executable Format (PEF). However, the native technology for linking separate executables at runtime is the dynamic link editor (dyld), and that’s based on the Mach.o (pronounced “Mach-Oh”) executable format.

Apple has a fairly complete description of both technologies which can be found here. I’ll only point out two things:

1) The Carbon application environment is not tied to CFM. In fact, Carbon is implemented as a set of Mach.o binaries that use dyld to resolve symbol addresses. CFM applications resolve references to the Carbon APIs through a set of thunking libraries that implement CFM on top of dyld.

2) Despite its name the Preferred Executable Format is not the “preferred” executable format on OS X. Among other things PEF employs something called a TVector to implement function pointers and what are known as cross-TOC calls while Mach.o doesn’t. You don’t need to know the details of either of those. All you really need to know is that the same code in the PEF format will be slower than if it had been complied to the Mach.o format. For this reason, Apple strongly recommends that applications be compiled to use dyld and Mach.o.

Mac Office and PEF vs. Mach.o

For a number of reasons, Mac Office is still a PEF executable. The primary reason is that we didn’t have time to both port Office from Classic to Carbon and deal with all the issues, many of them unknown until such time as you actually undertake the change, involved in also converting from PEF to Mach.o.

The second reason is that, until recently, converting from PEF to Mach.o would have also necessitated a change in our build environment. Metrowerks’ support for Mach.o is relatively recent, and, for Office 2004, we decided that converting to Mach.o was simply too great of a risk. As I mentioned, you really don’t know what problems you’re going to run into while making such a conversion until you try it. The work is certainly more involved than just flipping a compiler switch and rebuilding the code.

In any event, the legitimate question is, when will Mac Office be converted to the Mach.o executable format? Unfortunately, I really don’t know. It’s on the horizon, and we’ve conducted some preliminary investigation (enough to get a reasonable handle on how much work is involved). However, at the moment, we’re really focused on shipping Office 2004. For now, the effort is on the back burner, and the decision to move it to the front burner rests in the hands of people who have job titles that end with either “Development Lead” or “Development Manager”. My job title ends with neither.


Further reading:


Comments (16)

  1. Rick Schaut of Microsoft’s Mac Business Unit explains what went wrong with version 6 of Word for Mac:In order to understand why Mac Word 6.0 was a crappy product, we need to understand both the historical background that led to…

  2. 2lmc spool says:

    <a href=’’ >Carbon vs Cocoa, wrt Office</a>

  3. I’m Microsoft local and well know to Mr. Gates and company. One of the things Microsoft is focused on is Application Servers–.NET. They are pushing C# as a way to write their software as server based and then use thin clients to access it from either a service provider or broadband. This method of distributed application is now very viable due to the high speeds of our networks.

    Quite honestly, when they started pushing the licensing thing I knew it was due to a miss understanding of the .NET idea between Gates and the other parts of the company. It was a mistake. But with what they are focused on how–especially in Southeast Asia and Africa–they have the potential of making a lot of inroads for thin client technology.

    As a women, I’m very happy to see this evolution. I’ve been in the industry since the very early 80s and was a SE in the IBM mainframe environment. The major drawback then was network speed but their terminal technology for engineering was truly awesome with color and 3D graphics. We called this smart terminal technology then. The women especially like this system because they just use the software and didn’t have to be an engineer to do so. I believe that this will be true again. And since women buy more than 80% of everything in the US and almost everything in the third world, this is a major market niche.

    For broadband to really work, it has to be seen as a utility. Look to the past and consider how our water ways, road ways, power and phone utilities were built. To form a utility you have to work together and realized the power in the technology over petty bickering. It has to be brought together like farmers use to get together to harvest crops or raise a barn.

    Think about it. People are so diverse that you wouldn’t ever expect anyone to be happy about showing up somewhere important looking and wearing exactly the same thing. And even men get miffed when they find the exact same car sitting in a parking lot by theirs. It’s the individuality in the USA that made us a great nation. Hopefully this can happen again. I’m on a Mac OS X Duel G5 and loving it. That is because I like beauty and grace, not mac trucks. But I know this isn’t what most people need. This is like a high end sports car. What the world really needs is an economy model…

    Joan L. Brewer BS Computer Systems Engineering/Artist/Humanist

    Issaquah, WA 98027


  4. Scott Byer at Adobe put up a very nice post about the switch to intel and some of the growing pains many…

Skip to main content