multifariam.net

On the CarbonDev wiki, this page contains numerous interesting tidbits about Leopard’s 64 bit support for Carbon. Notably:

In practice, it looks like Carbon means “the UI(User Interface) 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 API‘s.

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

There is no explanation as to why Apple is deprecating Carbon; we all have a pretty good guess. However, the developers are discouraging this point of view:

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.

Onto the idea of a Cocoa Finder. Finder’s Carbon-ness has rubbed quite a few people the wrong way. With the demo of Leopard, some key Cocoa features were demonstrated. But for those of us hoping for a Cocoa-native Finder:

(T)he 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.

(T)he 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.

Well, some Cocoa is better than none, I suppose. Hey, there’s always 10.6, right?