Submitted by The lack of announcements about 64-bit Carbon in Mac OS X Leopard created uncertainty about Carbon’s 64bit capabilities in the developer community. But it seems like only the UI parts of the Carbon API are not ported to 64 bit – at least according to Apple engineers on the Apple mailing list.
“the Mac OS programming model does not support mixing 32-bit and 64-bit calls in the same process (regardless of whether you’re using Carbon, Cocoa, or just BSD Unix calls).”
Does that mean that Adobe has to rewrite the GUI of Photoshop and their other Carbon apps to be able to take advantage of 64 Bits?
“Does that mean that Adobe has to rewrite the GUI of Photoshop and their other Carbon apps to be able to take advantage of 64 Bits?”
The cleanest way to write an app for a specific bitness is to go all or nothing, i.e. make the entire app 64 bit or not.
Admittedly I am not an Apple developer so I would love to hear any experts on how this can be handled, i.e. parts of Carbon will be 64 bit and other parts will be 32 bit.
I do know that on Windows, it’s the same type of behavior…only one set of bitness is allowed inside a process, however 64 bit was implemented throughout the entire API so it’s simple to implement an app which will be purely one bitness. I for one find it a bit odd that Apple would intersperse bitness ports for an API (legacy or not) as it just gives developers one more hurdle to jump through while they’re still using Carbon API’s. Apple seems to be making it pretty clear that they don’t want developers using Carbon anymore.
A.f.a.i.k. this is why Apple supports fat (and/or Universal)-binaries.
In extremo an app could contain a binary with seperate code for 32-bit PPC, 64-bit PPC, 32-bit X86 and 64-bit X86.
4 executables in one application.
Edited 2007-06-22 00:02
“In extremo an app could contain a binary with seperate code for 32-bit PPC, 64-bit PPC, 32-bit X86 and 64-bit X86.”
This is true for BSD/Unix apps and with Leopard also for Cocoa apps. But it looks like there’s no easy way to support 64bit Carbon apps.
Remember how 64 bit worked on older MacOS X releases? Your GUI had to be 32 bit, and you’d spawn a seperate 64 bit process to do the heavy work. It’s going to be the same deal here if you’re using Carbon, except the 64 bit process will have more of the system available to it this time.
Why not make all of Carbon 64 bit? They focused on what they considered most important first and ran out of time.
Interesting, and I appreciate the informative response.
I was thinking in the back of my mind that something like that would work, however the performance hit must be pretty severe. I know that on Windows, inter-process calls are thousands of times more expensive than an in-process call, and in this case since it’s a GUI making the call (which must remain responsive) I’m even more worried about the overall cost.
Another question: Do either the 32bit caller or the 64bit callee need to be aware of the bitness of the other, i.e. does the 32bit code need special ‘hooks’ for calling into 64bit code (and vice-versa) or will the plumbing be taken care of by Carbon? Again I don’t do Mac development, but this is all very interesting to me nonetheless.
If developers want their programs to be fully 64 bit (32 on machines that aren’t 64 bit machines) then they need to move to Cocoa.
Carbon = Windows ’95 16 bit apps.
Cocoa = Windows XP 64 bit (but on steroids).
I disagree. You can make your application 64bit clean and use the switch m32 or m64.
Cocoa (and Cocoa with LLVM) is more .NET to Windows, its a completely new paradigm that will require a big move. The problem as far as I see it, these are great technology moves by Apple and Microsoft, but it is ultimately the software vendors who hold back development.
Just talk to Microsoft about how much they would *really* like to do if backwards compatibility was a non-issue; I can assure you that the half-assed chunder that was pushed out known as Windows Vista would never have existed for starters.
(This isn’t directed at you) I think those who whine need to realise that software companies make millions, and need to actually start re-investing their profit rather than giving their management lofty pay cheques and frivolously throwing around money when they make a little.
Sorry. Cocoa is 20 years of MVC OOA/OOD Paradigm that isn’t new. It’s seasoned, was introduced in 1997 to the Apple developers at WWDC ’97 and they have had 10 years to transition to this.
If it takes a company ten years to convert they deserve to be left behind.
Actually you’re wrong there. Carbon is equivalent to Win32: very few new project use it directly, but it does get used here and there in projects, and new Carbon APIs are frequently available. For example, if you read Will Shipley’s blog, you’ll see him complain about how, often times, Apple realised Carbon APIs for functonality first (e.g. Quicktime) and were very slow to provide Cocoa wrappers.
Cocoa therefore is more like .Net, it’s nicer, they’d like everyone to use it, but even people who used it have to drop down to Win32/Carbon occasionally to so some stuff like configure quicktime or do some low-level work with iSight.
Incidentally, this is why Apple has transitioned most of Carbon to 64 bits: there’s almost no single Cocoa app out there that doesn’t use Carbon to some extent. And given that Apple was still releasing new Carbon only APIs with Tiger, it was hardly a surprise that developers expected it to continue.
I think that most of people have missed the main point revealed in the mailing list.
The decision to not provide a 64 bits Carbon UI is more a business decision than a technical one, from the mailing list we can read:
“Perhaps management decided that 32/64-bit would be a good cut-off point and that those engineering resources could be better used elsewhere.”
This is more accurate. 64-bit Carbon works pretty well in Leopard; you can see it in action when opening a menu in 64-bit Xcode, for example, since menus are still displayed in 64-bit compositing WindowRefs and HIViews”
“”Q: I’m not privy to the internal discussions within Apple, but I’m willing to bet a quarter they don’t even know themselves for sure at this point. Apparently they have working 64-bit Carbon that they’re just arbitrarily opting to not ship because they want to send a message to developers.
Larry is correct up to the word “because,” at which point he makes an assumption.
– Chris Espinosa”
They clearly say that a complete 64 bits Carbon actually works but they decided to remove the HiToolBox. Why? Well, it looks to me that Apple has decided to migrate gradually their developers using Carbon to Cocoa. First step? No 64 bits for Carbon UI…..
If you been using the Leopard builds before the WWDC, you could actually code and call the HiToolBox APIs in a 64 bits application.
From the mailing list:
“Much of the Carbon API will still be available in 64-bit. The primary parts planned for removal are the UI portions of HIToolbox, which you likely don’t use if you’re using Cocoa for your UI.”
The last part of this sentence is important. Apple wants Carbon developers to start to use Cocoa at least for their interface. If they do then they can use Carbon in a 64 bits application as the non-UI part of Carbon is 64 bits. And so yes, a developer like Adobe has to use cocoa for their UI if they want to go for 64 bits (if they will ever go as Adobe is very slow when it comes to use new technologies).
This approach has the benefit that it allows Carbon developers to switch gradually to Cocoa, they don’t have to rewrite all their apps in Cocoa, they start with the UI.
Again, it is not that Apple does not want the Carbon developers to use Carbon anymore, they want them to start to use Cocoa, and the jump to 64 bits is a good time. Also remember that not all Carbon developers will be affected, because not all Carbon applications need to be 64 bits anyway. A lot of them will continue to live in the 32 bits worlds so i think that the Apple’s decision in full of sense in this one.
The kernel and drivers are still 32 bit. All 64 to 32 transitions happen at the interrupts and syscall boundaries. This is a good solution for desktop machines and even single-user compute-intensive workstations (not really IO intensive ones), but we’re not going to be seeing very powerful OSX servers.