Leopard Drops 64-bit Carbon Support

[MacRumors]

Developers at WWDC are realizing that Steve Jobs made a purposeful omission when he didn't include Carbon in Leopard's list of 64-bit compatible libraries at this year's WWDC keynote.

At last year's keynote, Apple had claimed that both Carbon and Cocoa would be 64-bit, adding to the 64-bit fundamentals that Tiger had laid. A photo from last year's presentation, courtesy of Engadget:



However, according to the latest on Apple's website, Leopard's 64-bit frameworks will include the POSIX and math libraries found in Tiger, Cocoa, Quartz, OpenGL, and X11 GUI framework. In addition, Apple confirms that Carbon will not be 64-bit on the Carbon Developer mailing list.

In all reality, this omission may not prove to be a huge stumbling block for many users, as Cocoa has been Apple's preferred framework since the inception of Mac OS X and Carbon was employed primarily as a method for porting legacy apps to OS X.

[Harpo]

I don't like Carbon apps anyway -- it's high time we moved away from all that.

[P-Worm]

How many big apps does this actually effect?

P-Worm

[AppleMan101]

Originally Posted by P-Worm

How many big apps does this actually effect?

P-Worm

iTunes for one, will Apple move it to cocoa or stick with a 32-bit version?

[longofest]

Originally Posted by P-Worm

How many big apps does this actually effect?

P-Worm

Pretty sure MS Office is still Carbon, but they don't need 64 bit anyways

I don't know what Adobe Suite is, but they had a lot of code that came from OS9 days, so at some point I suspect they were Carbon, but they may have gone Cocoa... in fact, I think they have, because I think Cocoa is a requirement for Universal apps, although don't quote me on that.

[mkrishnan]

It affects MS Office, but it's hard to imagine Office making benefit of 64-bit files. I think Adobe CS is the major, major app, and it is actually capable of benefiting from 64-bit aspects of the OS. It looks like Adobe is at work on making use of this, but I think CS3 is a Carbon app.

Originally Posted by AppleMan101

iTunes for one, will Apple move it to cocoa or stick with a 32-bit version?

What does iTunes really need with 64-bit processing? Even 1080p movies and Apple Lossless files are rarely, if ever, large enough.

[longofest]

Originally Posted by AppleMan101

iTunes for one, will Apple move it to cocoa or stick with a 32-bit version?

iTunes really has no need to go 64-bit. Really, only pro-level apps have needs to go 64-bit.

[NNO-Stephen]

good. we need to get away from carbon apps because they don't work as well for Universal Access stuff like VoiceOver.

any more motivation we can give developers to modernize their apps without taking away their ability to function currently is good IMO.

[Am3822]

What does it mean in layman's terms? Will I be able to run a Carbon application under Leopard, or is it time to start looking for an alternative?

[hollerz]

Originally Posted by Am3822

What does it mean in layman's terms? Will I be able to run a Carbon application under Leopard, or is it time to start looking for an alternative?

No, you will still be able to use it.

[nagromme]

So, this means AppleWorks will STILL be dog slow when placing 8GB image files

[mkrishnan]

Originally Posted by Am3822

What does it mean in layman's terms? Will I be able to run a Carbon application under Leopard, or is it time to start looking for an alternative?

Carbon and Cocoa are two different sets of programming tools for programmers in OS X. There're a number of threads that debate this, and it's a can of worms, but to oversimplify, Carbon is basically more like what programming looked like on Macs before OS X, and so was supposed to facilitate developers moving over from OS X. In contrast, Cocoa was sort of the gold standard of what the development environment was supposed to look like in OS X.

Both Cocoa and Carbon work on both PPC and Intel. They're both going to work in Leopard. There are two important issues, though:

1) There are a few big apps or suites (e.g. MS Office, Adobe CS) that are written using Carbon. What this means is that these apps take a long time and a lot of money to port and convert, and so to the extent that they can benefit from 64-bit, it's important that they may not be able to get it unless they switch to Cocoa (Office probably wouldn't benefit, but CS might).

2) There are some small system level tools that only work in the Cocoa environment. For instance, Cocoa provides a built-in inline spell checker for the text areas in apps, but this isn't something that Carbon apps can use. So this is why it took such a long time for built-in spell checking to happen in Firefox (which is not Cocoa right now, I think, but will use Cocoa later, I believe in version 3). I think another example is the Ctr-Opt-D command that triggers the OED pop-up. Things like international language support also don't work completely in Carbon, which I think is why some languages don't function correctly or behave bizarrely in Office.

Anyway, the second issue has nothing to do with 64-bit. It has to do with user interface niceties. The first issue does have to do with 64-bit, and really only applies to apps that can benefit from 64-bit. The rule of thumb is that an app needs to push around 4GB or more of information to really benefit. So, think some photo / art / video / rendering apps, some kinds of scientific computation, etc. This is why iTunes becoming 64-bit is nonsense.

[nagromme]

Carbon apps will still run -- they just have to stay 32-bit (and 64-bit doesn't benefit a lot of apps anyway).

This link from DaringFireball notes that Cocoa apps often INCLUDE some Carbon elements, in which case this could become an issue. (Assuming the app would benefit from going 64-bit.)

http://mjtsai.com/blog/2007/06/13/64-bit-carbon/

In any case, nothing will fail to run for users.

[Clive At Five]

Originally Posted by mkrishnan

1) There are a few big apps or suites (e.g. MS Office, Adobe CS) that are written using Carbon. What this means is that these apps take a long time and a lot of money to port and convert, and so to the extent that they can benefit from 64-bit, it's important that they may not be able to get it unless they switch to Cocoa (Office probably wouldn't benefit, but CS might).

I can easily see CS3 benefitting from 64-bit in the near future... Especially as cameras gain larger and larger megapixel capabilities, and HD content is getting trickled down onto a user-level.

And regarding iTunes, I know it might sound ridiculous now, but eventually iTunes will offer HD movies (be it in 2 years, 5 years, 10 years, or what have you) and an 8GB file will seem to us like an 8MB file seems today. 10 years ago, I would've lamented having to download an 8MB file but now it's a sinch. Similarily, it will be a sinch to download and play an 8GB file 10 years in the future. So it may not be soon, but 64-bit is coming to iTunes.

-Clive

[mkrishnan]

Originally Posted by Clive At Five

And regarding iTunes, I know it might sound ridiculous now, but eventually iTunes will offer HD movies (be it in 5 years, 10 years, or what have you) and an 8GB file will seem to us like an 8MB file seems today. 10 years ago, I would've lamented having to download an 8MB file but now it's a sinch. Similarily, it will be a sinch to download 8GB 10 years in the future. So it may not be soon, but 64-bit is coming to iTunes.

I guess that's a fair point... I guess 1080p H.264 is about 1mb/sec, putting a ful movie around 6-8gb. But then, from how I understand things, the issue for playing a movie file is not so much the size of the movie file but how much of it has to be considered at one time -- unlike a 4GB picture file, you are only interested in a tiny fraction of the 4GB movie file at one time. But yes, presumably much higher resolutions along with multiple tracks of multichannel digital audio will eventually become commonplace, and we'll need 64-bit even for videos someday.

[Krevnik]

Originally Posted by mkrishnan

What does iTunes really need with 64-bit processing? Even 1080p movies and Apple Lossless files are rarely, if ever, large enough.

720p movies at 2 hours wind up being overcompressed to fit into 4GB so I can stream/sync to my Apple TV...

To say that 1080p movies are rarely large enough... wait for feature-length films to appear in HD. They will float at the 3-5GB range for 720p, and more than double that for 1080p.

[Clive At Five]

Originally Posted by mkrishnan

I guess that's a fair point... I guess 1080p H.264 is about 1mb/sec, putting a ful movie around 6-8gb. But then, from how I understand things, the issue for playing a movie file is not so much the size of the movie file but how much of it has to be considered at one time -- unlike a 4GB picture file, you are only interested in a tiny fraction of the 4GB movie file at one time. But yes, presumably much higher resolutions along with multiple tracks of multichannel digital audio will eventually become commonplace, and we'll need 64-bit even for videos someday.

Well put.

You're right in your previous post, though. 64-bit iTunes today would be worthless. The advantage that Apple has with iTunes is that 1) it isn't tied to an OS release 2) it's free... so when Apple does decide that 64-bit is necessary, it'll be released, and it'll be available to everyone... at no charge, to boot!

-Clive

[longofest]

Originally Posted by Krevnik

720p movies at 2 hours wind up being overcompressed to fit into 4GB so I can stream/sync to my Apple TV...

To say that 1080p movies are rarely large enough... wait for feature-length films to appear in HD. They will float at the 3-5GB range for 720p, and more than double that for 1080p.

But why would you need that all loaded into memory at once? Pulling from disk to watch a movie is just fine... its when you're manipulating a 3 GB image that you would need the entire thing in memory...

[jellomizer]

Well the entire world wants to reduce Carbon, Apple is doing its thing to help. Getting rid of Carbon in the next version of the OS will get Green Peace off their back. Heck they made the background with some plants in the back. That'll get them some extra Carbon Credits as well

[travishill]

Carbon apps can open huge files (> 4 GB) right now, today. The File APIs are not impacted at all by this.

[ehurtley]

All this means is that a Carbon app will not be able to take advantage of more than 4 GB of RAM. That's all it really amounts to.

But it is slightly disappointing, as I was hoping to make a Universal Fat Ultra Binary, consisting of a Carbon app that would run in OS 9 and X, on both PPC and Intel, in 32-bit and 64-bit. :-p (Hrm, does the old Carbon framework that runs on OS 8.1 work on 68040 machines? Could I still make a super-binary that contained 68040 and PPC Classic code plus PPC and Intel OS X code?)

[Peel]

It's high time that developers reduce their Carbon footprint anyway

[ehurtley]

Originally Posted by jellomizer

Well the entire world wants to reduce Carbon, Apple is doing its thing to help. Getting rid of Carbon in the next version of the OS will get Green Peace off their back. Heck they made the background with some plants in the back. That'll get them some extra Carbon Credits as well

I wish this was Slashdot where I could give this post a +1, Funny rating...

[MonaLisa]

Carbon is the GUI API for C++ (and C), while Cocoa is a higher level API for Objective C. So, if you have a huge C++ app written with Carbon, it would be quite a huge pain to convert to using Cocoa, so it would seem these apps will be stuck in 32-bit land. One way around this is is to use the Objective C++ mode, where Obj. C can access C++ code, but this still requires chucking all of the Carbon GUI code and replacing it with Cocoa code in Obj C. If you're target is only Mac OS X, then this is probably a good idea. I think Cocoa and Obj C rocks and it's the way to go, and I'm a long time C++ developer.

[stoid]

Originally Posted by Peel

It's high time that developers reduce their Carbon footprint anyway

Yes, I think we can officially say that Carbon's Dated.