macOS Carbon vs. Cocoa: A structured debate

[GothicChess.Com]

Apparently my post regarding the status of the "keyDown" event spawed a new thread wherein the longevity of Carbon was called into question.

So let's throw this out there:

1. Is Carbon here to stay?
2. If Cocoa is the way of the future, what benefits does it have over Carbon?

Let me first preface the discussion with a few thoughts:

Carbon, to me, appears to be a natural way to code. I was around since the "Inside Macintosh: Volume I" days, originally coding in Pascal on a 128 K Mac. Ok, that makes me a dinosaur, so be it

But the Carbon API had its seeds in that command structure, and so much of Apple's documentation, even today, fits the "Carbon profile."

Now when I look at Cocoa, I admit, I am lost! The flowery, overly verbose modifiers and prefixes and suffixes just don't make sense to me. They look like a Windows C++ tome painted over with wide brush strokes.

For me, and I would assume for most Carbon diehards, making such a transition is non-trivial. We would, in fact, be functionally at "Programming the Macintosh: Day 1", and this is not a happy thought.

So, given that other developers would probably be in the same boat, I ask the group, what is there to gain by undergoing "programming brain surgery" to learn Cocoa? What can a Cocoa application do/offer/perform that a Carbon app cannot?

Feel free to discuss at length, but please, where you are injecting opinion, please so state.

 

[HiRez]

Carbon is here to stay mostly because much of Cocoa is built directly on Carbon data structures. But, Cocoa and Objective-C is a higher-level, more object-oriented programming environment that is more flexible at runtime than Carbon/C is. Personally I far prefer Cocoa and Objective C but then I have more experience with those than Carbon. You say Carbon seems more natural to you but I suspect that's just because it's what you're used to. Give Cocoa/Obj-C a chance and I think you'll like it.

 

[GothicChess.Com]

Carbon is here to stay mostly because much of Cocoa is built directly on Carbon data structures. But, Cocoa and Objective-C is a higher-level, more object-oriented programming environment that is more flexible at runtime than Carbon/C is. Personally I far prefer Cocoa and Objective C but then I have more experience with those than Carbon. You say Carbon seems more natural to you but I suspect that's just because it's what you're used to. Give Cocoa/Obj-C a chance and I think you'll like it.

Now that was the level-headed, well thought-out response I was hoping would start things off! Thanks! I am not saying I am turning my back on Objective-C and Cocoa, I am saying I am afraid to face it

I think you might be volunteering to take a few arrows in the back though, some of the posts to follow might be a little heated.

Thanks for your input though, much appreciated.

 

[GFLPraxis]

You should also consider that Cocoa apps mean your apps can be 64-bit once Leopard hits.
Carbon apps will not get that advantage when running on 64-bit machines.

 

[Krevnik]

I would say that killing Carbon at this point would be a bit of suicide. Cocoa isn't good enough for everything, and while I would hope codebases are written cleanly enough to port UI over... the reality is that they aren't.

MS will probably never be able to get rid of Win32 with .NET, and I don't see Apple getting rid of Carbon with Cocoa. The only alternative to Carbon for C-based libaries is POSIX which doesn't have any UI piece to it that works on OS X (very well, anyways). Choice is not something that should be taken away at this point in the OS' life time.

That said, I love Cocoa right now as a rapid application development environment. I have been able to prototype an app in a matter of days, and swap out the Cocoa-provided bits with my own bits to polish and improve functionality. Can't do that with Carbon... but any port to Windows would be hell.

 

[jeremy.king]

Taken straight from ADC:

Mac OS X supports both modern and legacy APIs. Most of the legacy APIs derive from the assorted managers that were part of the original Macintosh Toolbox and are now a part of Carbon. While many of these APIs still work in Mac OS X, they are not as efficient as APIs created specifically for Mac OS X. In fact, many APIs that provided the best performance in Mac OS 9 now provide the worst performance in Mac OS X because of fundamental differences in the two architectures.

As Mac OS X evolves, the list of APIs and technologies it encompasses may change to meet the needs of developers. As part of this evolution, less efficient interfaces may be deprecated in favor of newer ones. Apple makes these changes only when deemed absolutely necessary and uses the availability macros (defined in /usr/include/AvailabilityMacros.h) to help you find deprecated interfaces. When you compile your code, deprecated interfaces trigger the generation of compiler warnings. Use these warnings to find deprecated interfaces, and then check the corresponding reference documentation or header files to see if there are recommended replacements.

A developer who fails to adopt Cocoa can't blame Apple, they have been warned.

For me, and I would assume for most Carbon diehards, making such a transition is non-trivial. We would, in fact, be functionally at "Programming the Macintosh: Day 1", and this is not a happy thought.

<opinion>
This is a very thick headed statement. Developers need to evolve as the platform evolves, its as simple as that. You are still a programmer and those same skills apply, just different language and different APIs.
</opinion>

 

[Krevnik]

A developer who fails to adopt Cocoa can't blame Apple, they have been warned.

That clip doesn't talk about the deprecation of Carbon, it talks about the deprecation of the really poor toolbox APIs like the Event Manager and QuickDraw that have been long replaced with a proper event management system, Quartz and HIToolbox.

<opinion>
This is a very thick headed statement. Developers need to evolve as the platform evolves, its as simple as that. You are still a programmer and those same skills apply, just different language and different APIs.
</opinion>

That is true, but evolution of code costs money that could be spent evolving your product and making money. Business is almost always trying to find the balance, the larger the business, the slower the evolution because of the increased costs of porting/adapting codebases.

 

[jeremy.king]

That is true, but evolution of code costs money that could be spent evolving your product and making money.

True.

My opinion is a little distorted because I am usually making money porting applications to something a little more current. At least the speed of evolution is much slower in the desktop space than the web based space - which is reinventing itself every 2 years!

 

[Krevnik]

True.

My opinion is a little distorted because I am usually making money porting applications to something a little more current. At least the speed of evolution is much slower in the desktop space than the web based space - which is reinventing itself every 2 years!

The difference is that web apps have faster turn-around times since the underlying technology isn't changing. Sure your front-end to the user might change rapidly, but HTML, PHP, SQL aren't changing rapidly. That is one extreme: rapid product evolution with little to no platform evolution.

The other extreme is that you get a lot of platform evolution, but little to no product evolution (OS 9 -> OS X is a good example).

The second is really only profitable when platforms change or are added. Having to migrate to OS X from OS 9 or Windows, etc stuff like your work... since you grow the market the product can address, generating sales. Endless churn of updating your app to use the latest APIs for no benefit while addressing the same market size... not so much.

 

[GothicChess.Com]

A developer who fails to adopt Cocoa can't blame Apple, they have been warned.

I don't see any mention of Cocoa being the API to support and Carbon being the API on the way out anywhere in the statement you quote from ADC.

They were referring to very antiquated API concepts, like MoreMasters(), SetApplicZone(), MaxApplZone(), GetNextEvent(), etc.

Carbon is NOT a software-based blueprint of the original Mac 128K ROM.

<opinion>
I don't think you have furnished any definite proof Carbon is on the way out and Cocoa is preferred by Apple.
</opinion>

I do welcome seeing such evidence as it will direct my future time allocations towards learning Cocoa, if such a learning curve is warranted.

 

[whooleytoo]

As long as even one 'big name' application is Carbon based (Photoshop, Quark Xpress, MS Office etc..) then Carbon will be around. Apple is in no position to tell any such developer 'port to Cocoa or get off the Mac'.

The major developers will port to Cocoa - or perhaps more likely they'll start their next generation application in Cocoa - when the costs & risks involved mean it makes more sense to do so, not when Apple decides they will.

From a technical perspective, I was in the identical position to you 4 or 5 years ago, but had to take the time to learn Cocoa; as obscure and verbose as the syntax looks, and as daunting as the framework seems. It's time well spent.

The Carbon vs Cocoa debate is virtually the stereotypical API vs framework discussion: an (in this context, non-OO) API exposes functionality in its barest form, and requires you to build it into your program piece by piece.

But a framework goes a step further and groups functionality together - you don't just want to create a bare-bones application but an application that has a menubar, responds to Notifications and AppleEvents. You don't just want to create a window, but a window which can be maximised, minimised, dragged around, resized and has a view for drawing into. In Carbon you do all this yourself, in Cocoa it's done for you.

Of course, there are C++ Carbon frameworks too, but <personal prejudice here> I don't trust them. You're then dependent on a (non Apple) third party to stay in business, not be bought out, not change business direction and abandon the product. It introduces a middle-man into the development equation. Plus it introduces a degree of latency - if Apple introduces a major OS release, the 3rd party framework may well require substantial changes too, which you need to wait for before you can fix your own application</prejudice>.

If you want to develop a new application for OSX, learn Cocoa. It's easier if you have a project to keep you focused, rather than training for training's sake.

Just work with a goal in mind. Try the following, and look at the Xcode documentation and online tutorials (cocoadev.com, cocoadevcentral.com, macdevcenter.com are among the best):

- Learn the string classes, how to divide a string up, concatenate strings etc.
- Learn how to add and manipulate items in arrays.
- Now use strings to build an array of paths of all the files in a given folder on your hard drive (hint: there's a subset of NSString methods that'll help you here)
- Next, try finding out how to draw a table or outline view and populate it with the array you just built. (Personally, I'd recommend steering away from the bindings tutorials for now - they're a little obtuse - and look for tutorials that draw table views with datasources & delegates).
- Next, add a few buttons, and using the NSFileManager object, make these buttons open, delete or duplicate the selected file.
- Finally, look at the documentation for QTMovie, and QTMovieView, and see if you can put a movie view in your window. If the user clicks on a file that's a movie (hint: check the file extension), display the selected movie in the movie view.

Viola.. you have a basic media library application!

Certainly, Apple's documentation is nowhere near the quality of the Inside Macintosh volumes (very little documentation is!), but no doubt it's more difficult to maintain quality documentation due to the pace of change these days.

 

[GothicChess.Com]

You should also consider that Cocoa apps mean your apps can be 64-bit once Leopard hits.
Carbon apps will not get that advantage when running on 64-bit machines.

The question is, to what extent is 64-bit applicability denied to the Carbon API?

For example, my primary concerns are memory, and, to a lesser extent, being able to read and write files > 4 GB.

If I buy a 16 GB MacPro and attempt to do a malloc() of, say, 8 GB, will the malloc() call fail under Carbon?

I don't think so. While such a call is only requiring "33 bits" since 2 ^33 is about 8 GB, as long as I can cross the 32-bit limit of 4 GB, I know my app will be able to use the <overkill> I intend for it.

File size read/writes, in my case, can be broken down into 2 GB or even 1 GB chunks.

But the RAM, I need the RAM!

So, my main question is, can you malloc() more than 4 GB on a machine with that much RAM using Carbon?

 

[GothicChess.Com]

As long as even one 'big name' application is Carbon based (Photoshop, Quark Xpress, MS Office etc..) then Carbon will be around. Apple is in no position to tell any such developer 'port to Cocoa or get off the Mac'.

Well, if you were correct about that, I would agree with you You see, the original owner of Quark sold his business for like $1 billion and bailed out prior to the OS X conversion. And, the new owner came close to going bust because of the extremely long time it took Quark to get up to speed. Even dedicated publishing houses like BookMasters.com that relied heavily on Quark dropped them like a rock when they continually delayed their OS X rollout. I know this for a fact because I was publishing a book in Quark at the time and they let me know they would only be supporting Quark OS 9 for a few months longer, and they encouraged me to change over to something else.

The Carbon vs Cocoa debate is virtually the stereotypical API vs framework discussion: an (in this context, non-OO) API exposes functionality in its barest form, and requires you to build it into your program piece by piece.

But a framework goes a step further and groups functionality together - you don't just want to create a bare-bones application but an application that has a menubar, responds to Notifications and AppleEvents. You don't just want to create a window, but a window which can be maximised, minimised, dragged around, resized and has a view for drawing into. In Carbon you do all this yourself, in Cocoa it's done for you.

That is true too, but there is a down side to all of this. For example, I recently wanted to create a group of 3 radio buttons, simple enough, correct? There is a way to create a cluster of "N" radio buttons easily, and the API will switch the radio button "bullet" to the one you select, and de-select the other one for you, automatically.

However... using this predefined format means you cannot execute a command on a radio button hit, you can only "read" its state, and take some other action when some other event occurs, such as pressing a button named "Apply", or something like that.

I have a floating palette up with a few radio buttons on it. When I hit a radio button, I want to switch modes right away, and steer the program to take subsequent action based on this mode change. If I used the radio button cluster as it is bundled, I would have to create another button, then execute 2 clicks every time I wanted this change -- one click on my radio button in the group, then another click on the button I did not want there

This is contrary to Apple's own User Interface Guidelines -- why do in 1 click what you can do in 2?

This was a minor example, but a poignant one I believe.

In fact, I never got around to programming my radio buttons to change state after I press them, I was just in a hurry to get it done "the old fashioned way".

Of course, there are C++ Carbon frameworks too, but <personal prejudice here> I don't trust them. You're then dependent on a (non Apple) third party to stay in business, not be bought out, not change business direction and abandon the product. It introduces a middle-man into the development equation. Plus it introduces a degree of latency - if Apple introduces a major OS release, the 3rd party framework may well require substantial changes too, which you need to wait for before you can fix your own application</prejudice>.

I agree with that 100% and have seen what has happened to those who had large Borland libraries in the PC World. Of course, Micro$oft engineered their failure by releasing new operating systems that only IT knew how to code, then they released all new versions of their software that worked on the new OS, as the rest of the world struggled to buy the new Micro$oft compiler, the new Micro$oft developer training classes, the new Micro$oft certification courses....

If you want to develop a new application for OSX, learn Cocoa. It's easier if you have a project to keep you focused, rather than training for training's sake.

You know, I would, if Apple would only release a few demo applications with all of the source files, well commented. I can soak up a language/API like a sponge if I could "crib" off some existing source, I have a knack for it But I have yet to see a complete program, and all of the snippets I have do the same thing in widely different ways, and that contributes a great deal to my own confusion.

So, if you know of any such sites with code examples that compile under XCode, lead me there, and I will follow!

 

[Krevnik]

The question is, to what extent is 64-bit applicability denied to the Carbon API?

For example, my primary concerns are memory, and, to a lesser extent, being able to read and write files > 4 GB.

If I buy a 16 GB MacPro and attempt to do a malloc() of, say, 8 GB, will the malloc() call fail under Carbon?

I don't think so. While such a call is only requiring "33 bits" since 2 ^33 is about 8 GB, as long as I can cross the 32-bit limit of 4 GB, I know my app will be able to use the <overkill> I intend for it.

File size read/writes, in my case, can be broken down into 2 GB or even 1 GB chunks.

But the RAM, I need the RAM!

So, my main question is, can you malloc() more than 4 GB on using Carbon?

It depends, that isn't clear yet, since nobody really knows the full extent of support for 64-bit Carbon will or will not have, even the Apple devs on the mailing lists are unclear. malloc actually is provided by the POSIX layer, and you can write apps meant to run in 4+GB virtual address spaces for 10.4 now, but you don't get UI support.

The catch is that Carbon is where all the C-based UI code lives.

 

[Krevnik]

That is true too, but there is a down side to all of this. For example, I recently wanted to create a group of 3 radio buttons, simple enough, correct? There is a way to create a cluster of "N" radio buttons easily, and the API will switch the radio button "bullet" to the one you select, and de-select the other one for you, automatically.

However... using this predefined format means you cannot execute a command on a radio button hit, you can only "read" its state, and take some other action when some other event occurs, such as pressing a button named "Apply", or something like that.

Is this in Interface Builder? Carbon or Cocoa?

In Interface Builder, if you can get just the one radio button selected, then you can assign it an action when it gets selected to your controller (in Cocoa). Pretty straight-forward. To be honest, I have never tried this in XCode with Carbon. I did try it with carbonized PowerPlant once. It was still kinda messy.

You know, I would, if Apple would only release a few demo applications with all of the source files, well commented. I can soak up a language/API like a sponge if I could "crib" off some existing source, I have a knack for it But I have yet to see a complete program, and all of the snippets I have do the same thing in widely different ways, and that contributes a great deal to my own confusion.

So, if you know of any such sites with code examples that compile under XCode, lead me there, and I will follow!

The problem with a framework is that you enter the land of 'anything you can do to glue A and B together, works'. Samples can show you 3-4 different ways to do the same thing, and all are right.

To get a kickstart into Cocoa, I actually recommend the O'reilly books on the subject. They got me in far enough for Apple's reference docs to take over.

 

[Nutter]

Carbon is here to stay mostly because much of Cocoa is built directly on Carbon data structures.

This is often repeated, but I don't think it's true. You are probably referring to Core Foundation, a framework that underlies both Carbon and Cocoa. Core Foundation is in C, but that doesn't make it Carbon.

Some parts of Cocoa do use Carbon internally, such as NSMenu and NSAppleEventDescriptor ... that's about it I think. I suspect that NSMenu may have to change in Leopard as Apple seem to be abandoning 64-bit support in much of Carbon, including the Menu Manager.

The question is, to what extent is 64-bit applicability denied to the Carbon API?

This is a very controversial issue at the moment. It appears that Apple have 64-bit Carbon more or less up and running, but may axe parts of it for reasons unknown. The bits that will be dropped are the UI-related bits - in other words, most things that a Cocoa developer might want will be there in 64-bit Carbon, but not much else.

Of course 32-bit Carbon is still perfectly viable, but a lot of developers are taking this as a sign that Carbon is a dead end.

And no, I don't think you can allocate more than 4 GB of memory in a 32-bit world. That is the whole point of 64-bit!

 

[SC68Cal]

There is no debate. Carbon is old, deprecated, and is going to get shut out in the cold like OS 9 emulation. This is what has happened with 64-bit support.

All you Carbon types spread FUD about how "Cocoa is built on top of Carbon" you're absolutely wrong. Apple has bent over backwards creating toll-free functions for you to take advantage of Cocoa technology.

Toll-free functions != "Cocoa is built on top of Carbon"

Technote TN2034 was a warning. All you greybeard OS9 fools vomited with rage when that was released. Daring Phucball jumped up and down and had enough people on his side to influence the game, at least, that is he wanted to believe. We don't have that luxury today. Vista is a mess, and people are looking for alternatives. Nobody wants to play with OS 9 again. It was dead the day it was delivered, and I REFUSE TO PURCHASE OR RECCOMEND OS X in a NETWORKED ENVIRONMENT if it will not behave itself and work like a UNIX system.

I threw out our old OS 9 boxes. I don't want any more.

Now that OS X doesn't have the ability to rot away in obscurity, Technote TN2034 will have to be taken seriously.

 

[elppa]

Apple has made it clear from day one (see here — 4:45 in) that cocoa is the way to go and the way they want developers to write proper Mac OS X applications. Carbon was an intermediate step. I am not a programmer and I know this and have known it for sometime.

Surely it would have been better having a look 7 years ago at the cocoa frameworks and gradually building up your knowledge?

I don't mean to sound harsh but this post sounds awfully naïve. I mean who really expects to program in one language/framework/style all their life? Technologies move on, so should you.

 

[Krevnik]

There is no debate. Carbon is old, deprecated, and is going to get shut out in the cold like OS 9 emulation. This is what has happened with 64-bit support.

All you Carbon types spread FUD about how "Cocoa is built on top of Carbon" you're absolutely wrong. Apple has bent over backwards creating toll-free functions for you to take advantage of Cocoa technology.

Toll-free functions != "Cocoa is built on top of Carbon"

Technote TN2034 was a warning. All you greybeard OS9 fools vomited with rage when that was released. Daring Phucball jumped up and down and had enough people on his side to influence the game, at least, that is he wanted to believe. We don't have that luxury today. Vista is a mess, and people are looking for alternatives. Nobody wants to play with OS 9 again. It was dead the day it was delivered, and I REFUSE TO PURCHASE OR RECCOMEND OS X in a NETWORKED ENVIRONMENT if it will not behave itself and work like a UNIX system.

I threw out our old OS 9 boxes. I don't want any more.

Now that OS X doesn't have the ability to rot away in obscurity, Technote TN2034 will have to be taken seriously.

With all due disrespect... TN2034 also told you to use Carbon Events to help reduce your CPU usage down to zero while idle.

The thing is... Carbon is not the old monster of horror known as the Toolbox and InterfaceLib. As long as Windows is the dominate force with tons of Win32 apps, a clean, maintained C API is a great way to get developers onto the platform. You don't burn the bridge until the victim is on /your/ side of the bridge.

And since Carbon is not InterfaceLib, and sits on the same BSD environment that Cocoa does, saying that it must be UNIX doesn't discount Carbon in any way, especially since you have pthreads, sockets, etc, all sitting right there. And you know, it would be great to be able to actually optimize a game once and awhile without running into the wonderful overhead that a dynamic runtime thrusts on you. Sure, OpenGL is C, but not all the supporting APIs I need are in OpenGL/POSIX.

And this is coming from someone who writes code predominately in C# and Obj-C.

 

[GothicChess.Com]

And no, I don't think you can allocate more than 4 GB of memory in a 32-bit world. That is the whole point of 64-bit!

Well, you have to be very, very clear on what you mean by "world".

For example, hard drives have been > 4 GB for eons now, even attached to a 32-bit OS you can still address what is at hard drive byte location 2^32 + 1, and beyond. This is because the OS farms out to the hard drive controller.

Conversely, the Mac was "originally" a 32-bit microprocessor, yet you could never allocate more than 1 GB of RAM because Apple used the upper 2-bits of their 32 to store the handle states for calls such as LockHandle()!

When did Apple become "truly" 32-bit clean? Was it when that "Mode32" startup extension fixed Apple's mess, or was it when Apple officially redid the Operating System?

The same can be tossed around regarding 64-bit-ness. With ANSCI C-90 (or was it 99? I forget now) we have the first instance of 64-bit vars that your compiler can use, so you can enumerate more than 4 billion with a counter. But this is clearly 64-bit emulation and not a measure of true 64-bit capabilities.

Look at Microsoft's "64-bit" operating System. They only have 36-bits addressable for RAM management, meaning a 64 GB limit for memory.

All of these "mixed" implementation of bit-ness means you really have to investigate what is meant by the associated terms.

 

[GothicChess.Com]

Apple has made it clear from day one (see here — 4:45 in) that cocoa is the way to go and the way they want developers to write proper Mac OS X applications. Carbon was an intermediate step. I am not a programmer and I know this and have known it for sometime.

Surely it would have been better having a look 7 years ago at the cocoa frameworks and gradually building up your knowledge?

I don't mean to sound harsh but this post sounds awfully naïve. I mean who really expects to program in one language/framework/style all their life? Technologies move on, so should you.

Well pardon me for becoming the Chief Executive Officer of a company and graduating from being a daily coder!

I have been developing on the PC for the past 7 years, co-authoring the 2004 World Computer Chess Champion (see http://www.chessville.com/GothicChess/ComputerWorldChampionships.htm for example).

I program on the Mac as a hobby, and I am "diving back in" again.

By the way, I also wrote Blackjack Deluxe, a program that was voted one of Mac User's "50 All-Time Best Shareware Programs" in 1996.

So there!

 

[Nutter]

Sure, you can access files larger than 4 GB with a 32-bit process, but you can't keep it all in memory at once.

That 16 GB of RAM isn't going to be any use to you unless you're able to address more than 4 GB at once, and for that you need 64-bit pointers.

(Not quite true, as the OS is perfectly capable of sharing out that memory among various processes, but you see my point I hope. Anyway, off-topic! I reckon that if you spent a little time with Objective-C and Cocoa you would most likely enjoy yourself. I would recommend doing so, even if just to satisfy your curiosity. Objective-C is a very elegant language and not at all difficult to learn.)

 

[Krevnik]

Sure, you can access files larger than 4 GB with a 32-bit process, but you can't keep it all in memory at once.

That 16 GB of RAM isn't going to be any use to you unless you're able to address more than 4 GB at once, and for that you need 64-bit pointers.

(Not quite true, as the OS is perfectly capable of sharing out that memory among various processes, but you see my point I hope. Anyway, off-topic! I reckon that if you spent a little time with Objective-C and Cocoa you would most likely enjoy yourself. I would recommend doing so, even if just to satisfy your curiosity. Objective-C is a very elegant language and not at all difficult to learn.)

In some cases, 4GB files really shouldn't all be in memory at once.

An analogy of 32 to 64-bit is a bit like moving from a 4000 sq ft home to a mansion when you lived alone most of the time. While the old 16 to 32-bit move was a bit more like moving from a Japanese apartment in downtown Tokyo to the 4000 sq ft home. You get a lot more benefit moving out of the apartment than you do the house.

Some things do need the extra address space, most of them are in academia like VT's cluster running expensive computations. My mother certainly doesn't need it.

 

[Thinine]

The thing is... Carbon is not the old monster of horror known as the Toolbox and InterfaceLib. As long as Windows is the dominate force with tons of Win32 apps, a clean, maintained C API is a great way to get developers onto the platform. You don't burn the bridge until the victim is on /your/ side of the bridge.

And since Carbon is not InterfaceLib, and sits on the same BSD environment that Cocoa does, saying that it must be UNIX doesn't discount Carbon in any way, especially since you have pthreads, sockets, etc, all sitting right there. And you know, it would be great to be able to actually optimize a game once and awhile without running into the wonderful overhead that a dynamic runtime thrusts on you. Sure, OpenGL is C, but not all the supporting APIs I need are in OpenGL/POSIX.

Carbon may not entirely consist of the horrors known as Toolbox and InterfaceLib anymore, but those clean C APIs you point to aren't Carbon either. CoreFoundation, CoreServices, CoreText, etc. may be partly derived from old Carbon stuff (CoreServices especially) but part of the transition is changing the API to adopt more modern conventions, rather than the 20 year old conventions of traditional Carbon. These are also the frameworks that can be made cross platform, as we saw with CoreFoundation and Safari 3 for Windows.

Cocoa, as it was on OpenStep, before Apple bought it, was a complete framework that encompassed all of the functionality of the OpenStep OS. But when Apple decided to add Carbon to Mac OS X, the also decided that Cocoa had to access some of that functionality. As it turns out, they used a lot more old Carbon functionality for important stuff than they put into Cocoa, perhaps making Cocoa seem more limited than it could have been.

To Everyone: According to Apple engineers, the only part of Cocoa to ever be based on Carbon (directly) are parts of the UI functionality. And even that is going to be removed for Leopard (there is a new CoreUI private framework).

 

[Krevnik]

Carbon may not entirely consist of the horrors known as Toolbox and InterfaceLib anymore, but those clean C APIs you point to aren't Carbon either. CoreFoundation, CoreServices, CoreText, etc. may be partly derived from old Carbon stuff (CoreServices especially) but part of the transition is changing the API to adopt more modern conventions, rather than the 20 year old conventions of traditional Carbon. These are also the frameworks that can be made cross platform, as we saw with CoreFoundation and Safari 3 for Windows.

HIToolbox is part of Carbon, was written explicitly as a MacOS X API... and won't be 64-bit for Leopard.

For many programmers, Carbon is a term that encompasses much of the C API set on OS X that Cocoa doesn't use, and isn't part of the BSD/POSIX API set. So part of the annoying debate misses out on C APIs that have been introduced that will likely be 64-bit (DiscBurning, CoreImage/CoreVideo/CoreAudio, etc).