Article:		Cocoa Vs. Carbon?
Subject:		It strange nobody mentioned it but carbon is the way to go for cross platform
Date:		2001-05-25 02:34:14
From:		eredler
Companies that wish to maintain a common code base for their Win/Mac application would find it quite hard with Cocoa. Since Carbon and Win32 are very close, conceptually, it is much easier to write such applications with Carbon.

Showing messages 1 through 3 of 3.

• It strange nobody mentioned it but carbon is the way to go for cross platform
  2001-05-28 01:19:47  laird [View]
  
  
  This comment is amusing, since Cocoa runs/ran across an amazing number of platforms. NeXT shipped the API's on 680x0, x86, SPARC, HP PA-RISC, etc. You may want to check out www.gnustep.org as well. Even better, the development tools allow you to build an application once and deploy it natively on every platform. Wonderful stuff. Apple ships Coca on numerous platforms as WebObjects, though (oddly) they don't allow application vendors to license them, so even though Carbon app's run across a half-dozen or so platforms, you can't really sell them that way. Still, it runs great on MacOS X, or anywhere WebObjects is installed. I sure wish that Apple would allow software vendows to license the runtime.
  
  
  
  
  
  
  
  
  
  
  
  Of course, the MacOS API's, including Carbon, are implemented in a completely Mac-hardware specific manner, so they'll never run on anything else (unless Apple throws $millions at porting it). So while it might be the case that procedural API's might be mappable ( though if you get into the details, the MacOS API's and Windows API's are quite different in almost every detail aside from a few cross-ported technologies (e.g. TrueType, QuickTime).
  
  So what it comes down to is that developers will have to pick between Carbon and Cocoa. And, having used both, Cocoa is clearly the right way to go unless you have an overwhelming pile of legacy code, and even then you're simply trading off a quick port now against a long, losing battle against competition using Cocoa and getting 10x your productivity. So any smart company, even if they're porting a legacy Mac app to Carbon had better be exploring a Cocoa port.

• It strange nobody mentioned it but carbon is the way to go for cross platform
  2001-05-25 13:10:42  dmag [View]
  
  
  I agree. Cross platform folks build their own Application frameworks, usually.
  
  Also, game programmers, often don't want all the application layer stuff. Folks developing new languages (or new implementations, or porting implementations) don't necessarily want to buy into ObjC. All this is good stuff, and Apple should welcome these folks to X.
  
  Since ObjC, which views objects as pretty coarse-grained, takes zero performance penalty for being built on top of a procedural layer, it seems like a good idea for Apple to keep a procedural layer around.
  
  (The fact that C++ supports fine grained objects well, but is weak on the course grained stuff (not dynamic enough) is what made ObjC++ such a good thing.)
  
  I think Carbon Events, which Cocoa seems to be built on top of, will survive, and some other key features, but a large portion of Carbon will slowly fade out as OS 9 disappears. It will be replaced with the Unix filesystem APIs, Mach memory management and thread packages, and the new procedural APIs, such as CoreGraphics and CoreAudio.
  
  Dan
  
  
• It strange nobody mentioned it but carbon is the way to go for cross platform
  2003-12-22 15:40:25  anonymous2 [View]
  
  
  Cocoa isn't built on Carbon Events. That was the entire point of some of the previous posts. Cocoa uses its own event handling code (look at the Apple docs that explain how the system fits together... you'll find that the event dispatch mechanism differs for Cocoa and Carbon).
  
  Apple *have* used Carbon to implement some of the Mac OS X Cocoa methods, but it isn't used from the ground up as your comment implies. They have also (helpfully) made it so that you can mix Cocoa and Carbon code in the same application. But that doesn't mean Cocoa is built on Carbon... it isn't; sure, some things use Carbon (NSMenu is a good example), but not everything does (which is why Cocoa apps behave subtly differently in many cases).