Leopard Drops 64-bit Carbon Support

[shamino]

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

Why would they move it? It works just fine as a 32-bit app.

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.

So? A 64-bit app isn't required to access large files.

Or are you saying you think iTunes will want to load the entire multi-GB file into memory at once? That's hardly necessary, and would be quite counter-productive, since the OS would end up swapping all that data back out to the hard drive anyway.

 

[twoodcc]

well i'm a little disappointed....but not surprised.

 

[Eraserhead]

well i'm a little disappointed....but not surprised.

What about Photoshop/CS3, that could certainly do with being 64-bit. Adobe must be furious, especially as they have just dragged their app across to Xcode.

TBH this seems incredibly lame, and a poor way to treat their developers who must use Apple's flavour of the month to develop on OS X, not cool.

 

[hdasmith]

I didn't think the Intel chips supported Carbon, and had to run any Carbon apps under Rosetta?! This was why MS were taking so long on the next Office update, they had to port to Cocoa.

Also, didn't Adobe create a 64 bit plug-in for Photoshop 7 and onward? I would be amazed if Apple didn't talk to Adobe about this during the development of CS3.

 

[840quadra]

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...

Agreed,

The time when you would need that kind of memory / processor bandwidth for movies would be for compressing, changing codec, archiving said 1080p movie.

 

[bommai]

I didn't think the Intel chips supported Carbon, and had to run any Carbon apps under Rosetta?! This was why MS were taking so long on the next Office update, they had to port to Cocoa.

Also, didn't Adobe create a 64 bit plug-in for Photoshop 7 and onward? I would be amazed if Apple didn't talk to Adobe about this during the development of CS3.

You are confusing Carbon/Cocoa with PPC/x86 binaries. Rosetta is needed for PPC native binaries (carbon/cocoa). There is carbon/cocoa x86 native binaries as well.

I think 64-bit x86 is not only better for the bigger address space, but also for the internal registers. In 32-bit mode, there are only 8 integer addresses (as that is how many there were originally). As part of going 64-bit, there are more registers available. So, there could be some performance benefit to going 64-bit that does not actually come from going to 64-bit. G4->G5 does not give this same benefit though.

 

[ClimbingTheLog]

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

- that's the closest we have to a 'groan' icon

Why would they move it? It works just fine as a 32-bit app.

It's worth their moving it anyway - to show developers that they're serious about developers porting to Cocoa.

What about Photoshop/CS3, that could certainly do with being 64-bit. Adobe must be furious, especially as they have just dragged their app across to Xcode.

Yeah, and it also happens to give Apple's apps a competitive edge over Adobe. Not that they haven't had 8 years to get porting. Perhaps it's a kind kick-in-the-ass to Adobe.

This does appear to be the first nail in the coffin of Carbon, though. I bet at WWDC 2009 they'll declare "It was a good 25 years" of the Mac Toolbox and finally deprecate Carbon for OS X.7.

I didn't think the Intel chips supported Carbon, and had to run any Carbon apps under Rosetta?! This was why MS were taking so long on the next Office update, they had to port to Cocoa.

You're confusing some technologies. IIRC (I use NeoOffice, so I don't pay close attention) MS was using CodeWarrior still, which can only emit PowerPC (and 68k) opcodes. There are also some plug-in issues which can rear their heads under Carbon/Rosetta. iTunes runs native, don't worry.

Is Microsoft really porting to Cocoa? That would be cool, though I would have guessed they'd go the Carbon route.

Also, didn't Adobe create a 64 bit plug-in for Photoshop 7 and onward? I would be amazed if Apple didn't talk to Adobe about this during the development of CS3.

Yeah, there's no reason they can't structure a 'helper app' to do the 64-bit transforms, using some shared memory or something. It's just not elegant, and Cocoa would make Photoshop a better app.

I would have thought by now (8 years on) a competitor would have emerged with a killer Cocoa graphics app, the way InDesign did Quark.

 

[swingerofbirch]

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

It seems to affect using large files. If iTunes starts selling HD movies, I would imagine the file sizes would large enough for it to matter?


Also didn't SJ say it was 64 bit top to bottom?

Would including Carbon in that mean it was 64 bit top to bottom AND side to side? Oy vay, he pulled a fast one!

 

[Bregalad]

Why would they move it? It works just fine as a 32-bit app.
So? A 64-bit app isn't required to access large files.

Or are you saying you think iTunes will want to load the entire multi-GB file into memory at once? That's hardly necessary, and would be quite counter-productive, since the OS would end up swapping all that data back out to the hard drive anyway.

The OS isn't going to swap it all back out. By the time iTunes needs to go 64-bit, every computer will have at least 16GB of RAM.

 

[macsforme]

So basically this means that there will be no 64-bit C++ applications? I know of a lot of multi-architecture apps that are coded in C++ (although they probably don't need 64-bit addressing). In any case, I hope Carbon isn't actually taken out of OS X for a long time... C++ is still a very popular language, and it would be a pain to have to maintain a separate branch of code in Obj-C for all of these programs' Mac versions.

 

[Krevnik]

So basically this means that there will be no 64-bit C++ applications? I know of a lot of multi-architecture apps that are coded in C++ (although they probably don't need 64-bit addressing). In any case, I hope Carbon isn't actually taken out of OS X for a long time... C++ is still a very popular language, and it would be a pain to have to maintain a separate branch of code in Obj-C for all of these programs' Mac versions.

C++ with UI? Probably not. You can write 64-bit POSIX apps using C++ right now, but you can't get UI without Objective-C sitting on top it seems.

This isn't quite as bad as it sounds, since if you have a properly segmented project, you can have a Objective-C++ GUI layer on top of your C++ object model.

So? A 64-bit app isn't required to access large files.

Or are you saying you think iTunes will want to load the entire multi-GB file into memory at once? That's hardly necessary, and would be quite counter-productive, since the OS would end up swapping all that data back out to the hard drive anyway.

That isn't the problem, the problem is the current streaming protocol requests byte-ranges. These are pointers that can't exceed 4GB right now. So either you make iTunes 64-bit, or use 64-bit pointers when streaming the files, and do some trickery when seeking using 32-bit relative addressing from your 64-bit pointer in your 32-bit app.

 

[Fairly]

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

Carbon sucks.

 

[Fairly]

How many big apps does this actually effect?

P-Worm

Nothing from Adobe can to go 64-bit unless they break up their source tree and make a new one only for OS X.

 

[Fairly]

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.

Sorry: I just quoted you. No, Cocoa is no requirement for anything like that. That's an executable file thing. If it says CAFEBABE you got multiple binaries inside. Period. Adobe is NOWHERE NEAR to being Carbon much less Cocoa: they run PEF binaries inside Carbon wrappers.

 

[Fairly]

DaringFireball notes that Cocoa apps often INCLUDE some Carbon elements

So what? What exactly do you think he knows? I guarantee you: It's. Not. Much. At. All.

The linked article's basically OK. No one outside Cupertino knows much more right now and things can change.

FWIW: Cocoa code can not only call Carbon funcs, it can call ANYTHING. But by the same token Carbon can't get at Cocoa - it doesn't work the other way around. Objective-C is a superset of C. It can and does call C funcs all the time (and Carbon is today C). It doesn't matter if the C func is a Unix runtime, Carbon, or whatever you want to call it. If it has a dylib you can link to it.

But C cannot call Cocoa. Look no further than the Objective-C runtime and you'll grasp what's going on - and you'll have looked further than your Pied Piper.

 

[Fairly]

It seems to affect using large files. If iTunes starts selling HD movies, I would imagine the file sizes would large enough for it to matter?

Why? Minimal 32-bit systems can access terabytes of data today. It's not how much you have in the pipeline - it's how much you have to address at any one given time. It's not a question of how much RAM you have - it's a question of how much you can address. You could theoretically make a box with a zillion meg RAM but a 32-bit app couldn't see it anyway. A 32-bit app can see 2^32 different addresses and a 64-bit app can see 2^64 different addresses. It's not about how much data you have in the pipleline - it's about how much you have to deal with at the same time. If HD means better than 32-bit, then ask yourself if there are any HD players out today and whether they're 64-bit.

 

[Segmac]

Adobe will go 64 next release

Nothing from Adobe can to go 64-bit unless they break up their source tree and make a new one only for OS X.

Nack say its just when not if they go to 64.
http://blogs.adobe.com/jnack/2006/12/is_photoshop_cs.html

 

[Fairly]

I didn't think the Intel chips supported Carbon, and had to run any Carbon apps under Rosetta?! This was why MS were taking so long on the next Office update, they had to port to Cocoa.

Where do you get this from? I get the feeling you're fumbling in the dark here. If you can compile code for Intel you can run it natively on Intel. Full stop. Crack some books and get some basics.

Also, didn't Adobe create a 64 bit plug-in for Photoshop 7 and onward? I would be amazed if Apple didn't talk to Adobe about this during the development of CS3.

A 64-bit plugin? Oh they've got a heap of legacy PEF code and so someone writes a 64-bit plugin and suddenly everything is all right? Sounds like the best hack ever.

I think Adobe are in deep you-know-what. Then again we might all be (pleasantly) surprised.

 

[andrewm]

iTunes will probably go 64-bit, even if that's unnecessary today, as a side effect of eventually being ported to Cocoa. Now, that means that it won't run on Windows... unless... I think that Apple will probably do the same thing with iTunes as with Safari. I don't know if that's Yellow Box or something else, but I'm guessing that it will happen.

 

[shamino]

That isn't the problem, the problem is the current streaming protocol requests byte-ranges. These are pointers that can't exceed 4GB right now. So either you make iTunes 64-bit, or use 64-bit pointers when streaming the files, and do some trickery when seeking using 32-bit relative addressing from your 64-bit pointer in your 32-bit app.

You obviously don't do any software development, do you?

You don't need a 64-bit OS to send/receive 64-bit numbers in a network protocol. You also don't need one to perform 64-bit math. And you would never memory-map a video stream, so there's no need for 64-bit memory pointers either.

 

[ChrisA]

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

Not really. Once you move to a pure 64-bit environment and don't need to support a legacy 32-bit environment then you can what "Multics" did.

"Multics came first, then "Unix" came along The name "unix" was a play on the "multics" name. The idea was that unix would be so much more simple. In retrospect many people today think that Multics "got it right".

What did it do? Very much in contrast to UNIX it uses a "single level storage model" Which meant that to the programmer there was ONLY "memory". No disk, no files, so no reading and no writing. Everything was only in RAM and there simply was no other place it could be. One never read a file but simply accessed the memory location where that data was kept. This is natural when you have a truly HUGE address space, like 64 or 128 bits. (64-bits is truly huge. It is 4 Billion times larger then 32-bits.) The OS manages the movement of data and uses virtual memory so simulate thousands of terabytes of RAM. Multics was built in the 1960's on 64-bit hardware. and was very expensive and then came UNIX which was "file-centric" and ran on low-end hardware and became popular. In UNIX terms what Multics did was something like implementing "mount" with mmap().

Once the world runs on 64-bit hardware we can revert to the Multics way and all programs iTunes, text editors and database engines will be much simpler as all that reading and writing code will be gone. Multics was 35 years ahead of it's time.

 

[kuwan]

The biggest problem with this is that a lot of Cocoa apps use Carbon. Why you might ask? The reason is that some things in Carbon are easier to use than they are in Cocoa (rarely) or they do not even exist in Cocoa (most often reason) because there's no need to duplicate the functionality already in Carbon. In fact some parts of Cocoa are actually implemented using Carbon (the Cocoa menu system for example, see here: http://lists.apple.com/archives/mpw-dev/2004/Jan/msg00023.html ).

So what will Cocoa applications do that rely on Carbon? I'm guessing that some of Carbon will be available as 64-bit but not all. It's too bad though that it sounds like most of Carbon won't be available. On the Carbon Dev mailing list one of the Apple guys asked to postpone discussion until after a Carbon session at WWDC tomorrow (Thurs.). So hopefully we'll know more after that. Too bad I'm not at WWDC this year.

 

[shamino]

Once the world runs on 64-bit hardware we can revert to the Multics way and all programs iTunes, text editors and database engines will be much simpler as all that reading and writing code will be gone. Multics was 35 years ahead of it's time.

Simpler? Have you ever thought about what you'd have to do to implement applications with this model?

Go try it. Write a simple text editor that uses mmap() and shuns all of the file I/O. I think you'll find your code more difficult to write, more complicated, and impossible for anybody else to figure out.

When you don't have any concept of a file system, and applications are directly accessing disk-blocks for storage (as they often did 35 years ago), this might make perfect sense. On a modern system, where you've got millions of files, possibly scattered all over a network, and dozens (or even hundreds) of apps running at once, that design would quickly lead to insanity.

File I/O is not a significant contributor to application complexity. There are plenty of other things that make apps hard to develop and maintain, but this isn't one of them.

 

[dcr]

Adobe is NOWHERE NEAR to being Carbon much less Cocoa: they run PEF binaries inside Carbon wrappers.

You have no idea what you're talking about. Seriously. PEF binaries do not run natively on Mac Intel machines, and I'm pretty sure all of CS3 runs on Mac Intel machines.

PEF is an executable format. (Preferred Executable Format, dates from 68K-PPC transition.) Mach-O is also an executable format, which is, ironically, the preferred/native executable format for OSX. Adobe's applications have been Mach-O for some time now.

Carbon and Cocoa are application programming interfaces, and an application can choose to use one or the other or even both. This choice is unrelated to executable format. So "PEF binaries inside Carbon wrapper" is a nonsense statement.

 

[Sayer]

Ah, young padawan, so confused.

Carbon persists, as a middle-ware. Cocoa is not written in "Cocoa" or as much Objective-C as you may think. The true "core" of OS X such as the Window manager is written using Carbon's lower-level APIs. Objective-C "Cocoa" frameworks simply wrap around this low level functionality,written using OOP C++ pretty much and Carbon.

Even WebKit is largely OOP C++ with a Objective-C wrapper. Hence it's porting to Windows.