Editing 64-bit Carbon - Carbon Dev for MacOS X Wiki

When saving, enter the following:

  _    _    ___   ___    _______  ___   
 | |  | |  / _ \ (  _`\ (       )(  _`\ 
 | |  | | | | | || ( (_)| () () || (_(_)
 | |  | | | |_| || |___ | || || ||  _)_ 
 | |__| |  \__\_\| (_, )| |(_)| || (_( )
  \____/         (____/'| |   | |(____/'
                        | )   ( |       
                        |/     \|

Visit Preferences to set your user name

== Apple's official statement on 64-Bit Carbon ==

Most APIs in Mac OS X v10.5 are available to both 32-bit and 64-bit applications, but some APIs commonly used by Carbon applications are not. In particular, the APIs used to implement a Carbon user interface are generally available only to 32-bit applications. If you want to create a 64-bit application for Mac OS X, you need to use Cocoa to implement its user interface.

== Choosing a Development Path for Your Carbon User Interface ==

During the evolution of Mac OS X, a number of improvements and new features have been added to Carbon to help you modernize your Carbon user interface (UI) and begin to incorporate Cocoa features. You have been encouraged to adopt newer UI technologies such as composited windows, HIView-based controls, and Quartz 2D for drawing. In Mac OS X v10.5, the addition of HICocoaView has opened up a number of possibilities for adding Cocoa features to applications that use Carbon windows.
Because most Carbon UI functions are not available to 64-bit applications, you have two possible development paths. You can continue modernizing and improving your Carbon UI with the expectation that your application will remain a 32-bit application for the foreseeable future. Apple plans to support and maintain the 32-bit Carbon Human Interface Toolbox, although Apple will not be adding any significant new features to these APIs. The other development path is more challenging and also potentially more rewarding in the long term. You can develop a 64-bit version of your application, using Cocoa to implement your UI. As you do so, consider going one step further and implementing other parts of your application using Cocoa. For an introduction to Cocoa programming, see Cocoa Fundamentals Guide. 
At this time, a reasonable approach would be to compare the amount of work required for each development path, assess the potential benefits, and decide which option is more attractive.

[http://developer.apple.com/documentation/Carbon/Conceptual/Carbon64BitGuide/index.html Introduction to 64-Bit Guide for Carbon Developers]

[http://arstechnica.com/journals/apple.ars/2007/06/13/64-bit-support-in-leopard-no-carbon-love 64-bit support in Leopard: no Carbon love]
== Talk on carbon-dev ==

The following excerpts are all taken from the carbon-dev mailing list.  I have edited this down to main things stated by Apple engineers on the mailing list.   If you have facts about this topic, please add them. But, the idea here is to state the facts about this issue and omit, as much as possible, the speculations and emotions that are flooding the mailing list.  If you attended WWDC and have specific information or clarifications they are welcome.

----
  //"Q: Steve said '64-bit Cocoa', but there was no mention of '64-bit Carbon'.  Can we assume this was not an accidental omission?" //

Yes, that is a correct assumption.

-eric schlegel

----
  //"Q: Carbon isn't just the UI stuff if I understand things correctly. Maybe I'm confused. Exactly what does Carbon encompass?"//

That's a darn good question (and practically the first question we asked when we were informed of this change in plans).

In practice, it looks like Carbon means "the UI portions of HIToolbox". So for 64-bit there will not be a Control Manager, Menu Manager, Window Manager, etc. We are still planning to support the Carbon Event Manager and Text Input Sources, to name two mostly non-UI APIs.

You might wonder, what about the Memory Manager, or the Alias Manager, or the Process Manager, or other lower-level managers? At this time, it looks like most, if not all, of the APIs provided by the ApplicationServices and CoreServices umbrella frameworks will still be available in 64-bit (subject to further changes in plans).

-eric schlegel

----
   //"Q: Well, the easiest answer might have been that Apple engineers weren't focusing initial effort on a move to 64-bit Carbon, focusing on other features, Cocoa, etc. Then when they seriously delved into it, they realized that there were some major issues that couldn't be solved. Or perhaps management decided that 32/64-bit would be a good cut-off point and that those engineering resources could be better used elsewhere."//

The latter 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. I spoke with several developers at the conference today who were making good progress in porting their Carbon apps to 64-bit, including one who was almost ready to go to beta-testing.

**Fundamentally, Apple engineering is focused on Cocoa much more than Carbon, and Apple's engineering management made the decision to un-support 64-bit Carbon to emphasize that fact.**

-eric schlegel

----
  //"Q: After all, aren't most of the Cocoa APIs implemented on the HIToolbox stuff now?"//

No; primarily just the menu classes (NSMenu and NSMenuItem), which use the Carbon Menu Manager. The Cocoa event system also calls into the Carbon Event Manager to fetch events from the event queue. No other parts of AppKit are implemented on top of HIToolbox, or ever have been.

No, the Finder in Leopard is a 32-bit app. The only Leopard app I'm aware of that ships as a 64-bit app is Xcode.

No, the Finder is still largely a Carbon app in Leopard, although it does use our new HICocoaView capability to allow embedding NSViews inside a Carbon window to implement the coverflow view.

Currently plans call for the Carbon Event Manager to continue to be available in 64-bit HIToolbox, but not the Menu Manager.

HITheme is currently undecided. We did hear from multiple developers at the conference today who use HITheme and would like to see it in 64-bit.

-eric schlegel

----
  //"Q: So now I'm wondering, can 64-bit unix kernel calls be mixed freely within a 32-bit Carbon GUI environment? //

No, 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).

-eric

----
  //"Q: since every Cocoa app I've ever written links against the Carbon framework and makes calls to it, does that mean that all my Cocoa apps will be automatically demoted to 32 bits? //

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

----
  //"Q:  I have a large Cocoa application that makes extensive use of the FS... file system APIs, low level notifications, and other C-interface toolboxes. Are these frameworks "Carbon?" //

From my perspective, yes, they are part of Carbon, but in fact those parts of Carbon will still be available in 64-bit.

-eric

Most people will say yes.  But if you dig up File System slides from the last few years you'll notice we now refer to it as the "CoreServices File Manager".

-Deric Horn

----
  //"Q:  Will I be able to easily tell from the SDK headers which methods/functions are available in 64-bit and which aren't?? //

No, because we haven't yet actually made any implementation changes in response to this change in plans. That will happen soon, though - like in the next seed after WWDC.

-eric

----

For those that care about text, ATSUI and MLTE will not be supported in 64-bit.
ATS and CoreText will be 64-bit.

Julio Gonzalez

----
  //"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
----

You know, you don't all have to exchange supposition and speculation like this.

64-bit support was introduced into the OS with Tiger and the G5s.  We have supported 64-bit processes running alongside 32-bit ones at low (non-UI) levels of the OS for years.  The documentation is public and plentiful.

http://developer.apple.com/macosx/64bit.html
http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/index.html

Leopard introduces 64-bit support all the way up to the application level, which is the only difference (announced for Carbon and Cocoa last year, scaled back to Cocoa and non-UI Carbon this year).  The details of that have been in the Leopard seeds for seed key holders for a year.

While there may be room for speculation on a public bulletin board for the motives and effect of Apple's change in plans on 64-bit Carbon UI layers, there's just no reason to trade on rumors and supposition on the facts of what's been in peoples' hands for several years.  Read the above documentation before "[not] being surprised if Leopard has this same issue" — Tiger doesn't.

Chris
----

Actually, the Menu Manager does exist in 64-bit for use by NSMenu. It's simply not available for third-party developer use.

-eric

----

In Leopard, the only system pieces that are planned to ship as a 64-bit processes are Xcode and Chess, so this won't be an issue. I don't think any plans have been made yet regarding future OS releases.

-eric

----

//"Q:  Those of us who have 10.5 seeds could of course just try it out - take a Carbon project, add ppc64 or x86_64 and  press build&run. Of course, the results of those test they'd have to keep to themselves. //

But if you do that, and you find problems, please file bugs. Much of Carbon _is_ still available in 64-bit and we'd definitely like to know what issues you run into.

-eric

----

If you were planning to use 64-bit Carbon for your Mac OS X application, **please send your feedback about its removal from Leopard to the Frameworks evangelist, Deric Horn, deric (at) apple (dot) com** 
He reads this list, so he's probably seeing your messages already, but you can go into more detail in private with him about your specific business situation, the practical realities of whether you can or can't move to Cocoa, your customer base, competitive situation,  etc.
----

Summary of change:
Add document to category: