cocoa vs. carbonizing

[agillitt]

I have been trying to find out the answer to what should be a very simple question, but I can't seem to get a straight answer. <p>
Here it is: do OS X applications that are written in Cocoa have any advantage over applications that have been Carbonized? I understand there are many differences under the hood, but when it comes to the end-user, is there anything a Cocoa app can do that a Carbonized application cannot? (i.e. system calls, services, bells and whistles, etc...)<p>
From what i understand, Carbon was originally supposed to be a stepping stone to get from 8 to Rhapsody, but now has become robust enough to author first-class apps. If this is the case, then why bother with Cocoa at all, since the apps will only run under OS X?<p>
Does anyone have a clue about this? No one i have consulted yet has been able to give me a firm yes or no, and Apple's woefully thin documentation is anything but definitive.<p>
Oh yeah, i work for ZDNet News, so if I get enough meat on this, it will end up as an article. Email me directly at <a href="mailto:adam_gillitt@zdnet.com">adam_gillitt@zdnet.com</a> if you would like.<p>
Thanks in advance,<br>
-afg

 

[ITz The MaN]

When i run carbon apps, they tend to crash much more than cocoa apps. Actually I dont think i have ever had a cocoa app crash on me! I think that carbon is like what FAT used to be in the Classic OS. I dont think that carbon apps run as smoothly as cocoa apps. They dont run as fast, and i dont think they take full advantage of all the Mac OS X fetures. I am not 100% sure of most of this stuff, so before you write an article about this, you should look into it more.

 

[macdaddyfunk]

is there anything a Cocoa app can do that a Carbonized application cannot? (i.e. system calls, services, bells and whistles, etc...)

Short answer: Not at this time. and probably through 2001, is there any significant advantage to writing Carbon applications over Cocoa applications. I personally believe it was by design to gain over users and developers to adopt the technology.

Details, (as I understand them):
A good reference:
http://developer.apple.com/techpubs/macosx/SystemOverview/SystemOverview.pdf (also available from fatbrain.com)
Chapter 3 should answer some of the questions you have.

Some definitions from the above book:
Classic: Older Macintosh APIs we've all known and loved for the past 16 years. Interesting note about Classic:

The Classic “compatibility” environment is where users can run their non-Carbon Mac OS 8 or Mac OS 9 applications. Instead of sitting on top of the
Application Services, the Classic environment in this diagram has lines connecting it to each layer. These connections indicate that the Classic environment is “hard-wired” into Mac OS X; it is not an environment that developers can specifically compile code for on Mac OS X. In other words, there are no public non-Carbon Mac OS 8 or Mac OS 9 APIs on a Mac OS X system that can be compiled.

Carbon:

Carbon is an adaptation of the Mac OS 9 APIs and libraries for Mac OS X. It carries over most of the prior APIs (70 percent of the functions) and includes some APIs and services specifically developed for Mac OS X. See “Carbon” (page 45) for a discussion of Carbon.

Carbon is a set of programming interfaces derived from earlier Mac OS APIs that have been modified to work with Mac OS X, especially its kernel environment. Carbon carries forward most of the existing Mac OS managers and APIs;

Cocoa:

Cocoa is a collection of advanced object oriented APIs for developing applications written in Java and Objective-C.

The Cocoa application environment is based on two object-oriented frameworks: Foundation (framework)and the Application Kit framework).

Here's a quick summary (at least how I see it) of these layers:

1) Classic layer - legacy codebase support, everything MacOS9.x and downward. Can run as many classic apps as you wish, only pitfall, that if one classic application crashes, they all crash. Basically, classic apps can run, but don't gain any of the OS X features, like protected memory. This was included as not to have current Mac users burn Apple HQ to the ground. 16 years is a lot to invest in a system only to be told that you have to start *completely* over to get a next generation Operating System.

2) Carbon layer. This is simply Classic code rewritten to take advantage of the Mac OS X services(application services, core services, kernel environment) in it's own process. There have been demonstrations to show how relatively simple it is for dev houses to Carbonize their code. Apps in the Carbon layer have access to all the features of MacOS X, so if a Carbon app crashes (which IE5.5b2 does a lot of), other Carbon apps will be (and are) unaffected. The purpose of the Carbon layer was to not have 3rd party Mac developers burn Apple HQ to the ground. They can take their existing code and modify it so it can run at the same time on MacOS 8.1 or higher (with the CarbonLib 1.0.2 extension) or fully OS X compliant, there's no need for them to have two separate codebases.

3) Cocoa layer. I like to think of these as the "future ready" APIs, or what the Mac OS will use to evolve past OS X 1.0. These APIs offer advanced (cleaner) internal features as opposed to Carbon that we'll see more of in the years to come as OS X support gains ground and market.

Hope this helps!

 

[WebObjectsNo1]

Though the end-user benefits of Cocoa versus Carbon are not very clear right now, there are a few things to consider....

1. Cocoa is based upon the NeXTSTEP object libraries that have been around for almost 10 years. These libraries are considered to have a near-perfect object-oriented architecture - which is why NeXT was able to quickly snap WebObjects on top of their foundation libraries and be the first web-app server on the market. Cocoa developers will see huge benefits when it comes to development speed and responding to the market.

2. The Cocoa foundation has factored out all repetitive programming tasks. This means that core interactions with storage, control, and display have been (almost) perfectly implemented by Apple so that the developer only has to 'use' it instead of re-developing it. This will mean more stability and portability because the programmer no longer has to worry about testing at the hardware interface layer.

3. Did I just mention portability? THIS IS PURELY SPECULATIVE but consider this... Older versions of the groovy OS-X apps like Email, TextEdit, ProjectBuilder, EOModeler are included with WebObjects and currently run on WindowsNT. How hard could it possibly be to add Aqua APIs to the services on NT which already ship with WebObjects (and OPENSTEP for Windows)? Hmmm....makes you wonder.

I hope this helped. Good Luck.

 

[eVo]

One thing that I can confirm is that Carbon apps are not as responsive as Cocoa apps. For example, holding down a menu in IE 5.5 (Carbon) causes the whole app to freeze until you let go like it would under OS 9, but this is not the case for Cocoa apps. As well, when dragging a browser window while loading a site, you will notice that the window doesn't update live. Another Carbon disadvantage.

 

[agillitt]

thanks for your help in figuring this subject out.

i have completed an article on the topic, and it is available <a href="http://www.zdnet.com/zdnn/stories/news/0,4586,2640872,00.html">here</a>.

-afg

 

[mbharrin]

in osx-pb, cocoa apps support a mouse wheel and two button mouse. carbon apps don't. it's simple to have inline spell checking incorporated into a Cocoa app. i'd guess that it's harder in Carbon.

just two examples which illustrate how easily cocoa apps can take advantage of additions to the underlying framework.


if you know C and OO concepts you can be up and programming in obj-c in an afternoon. using Interface Builder you can have sophisticated GUIs churned out lickety-split. Cocoa is way cool.

-M.

 

[Kosh]

With regards to the commentson Carbon apps being less responsive than Cocoa apps...

The reason IE doesn't update browser windows while being dragged or while a menu is open is because IE isn't very well multithreaded. OmniWeb, on the other hand is multithreaded, and so can do these these things.

Services, such as spell checking, are not currently supported in Carbon apps, but Apple intends to have them available by OSX 1.0

Carbon vs. Cococa.

Well, Cocoa is superb if you are building an application from scratch, because you can do it so quickly. Carbon is great for porting from Classid applications. This has al been said ad nauseum.

However, there is anothe important consideration - potential user base.

Writing an application in Cocoa will result in a program with a very small potential user base in comparison to Carbon apps. As a result very few major developers (eg Quark, Adobeo, Macromedia, Microsoft) are creating applications in Cocoa, and have no current plans to do so. Even Apple's Cocoa applcations are all ports from Yellow Box/OpenStep - they have no plans to port AppleWorks to Cocoa.

One of the few major developers who has committed to making a Cocoa application is Alias|Wavefront. In the case of Maya, porting to Carbon makes no sense, because OS9 is incapable of supporting the program anyway, so a Cocoa port doesn't hamstring their development efforts. Also, with a program as big as Maya (~20m lines of code), you want the quickest development environment possible. At a guess, I would suspect that the porting of Maya is being done in a similar way to Fizilla - porting Unix code with calls to Mach-o frameworks.

Jonathan