Linked by Thom Holwerda on Thu 14th Jun 2007 15:58 UTC, submitted by Jeremy Fox
Mac OS X Carbon will not be 64bit in Leopard. "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. 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 addition, the readme file included with Leopard's developer preview says G3 support will be dropped from Leopard.
Thread beginning with comment 247886
To view parent comment, click here.
To read all comments associated with this story, please click here.
meianoite
Member since:
2006-04-05

It would be like Microsoft shipping Vista x64 with only a 32 bit Win32 API and requiring anyone who wants to write native 64 bit apps to use .Net x64. If that were the case, it'd be a huge deal, but of course since this is Apple no one gets up in arms.


No, it would be like deprecating Win32s, a temporary API that has *always* been announced as so, whose only purpose was to ease the transition of legacy applications to current modern APIs while not losing the currently installed user base which *at the time* comprised most of the users. Oh wait, that happened for how long now, half a decade?

Carbon is but a compatibility layer between the Mac Toolbox from 15 years ago, forced to play along with the reality of needing preemptive multitasking (i.e., they rewrote parts to enable reentrancy).

Apple has been preaching the death of "plain" Carbon for 3 years now. Objective-C++ hasn't been invented for nothing. Cocoa bindings for *several* languages haven't been invented for nothing. And people still writing CodeWarrior apps in Pascal should really find better ways to spend their time.

And now, how unsurmountable an effort would it be to compile only the GUI using [Carbon] and write the backend in, say, Objective-C++?

I guess I should refrain from commenting further until today's WWDC sessions are over. Plenty of questions will be answered then.

Apple's user base lets them get away with bloody murder without holding anyone accountable for actions like this.


How again are YOU being affected by it as a Mac developer? Or a user? Oh, way to "authoritatively" talk about something that you really can't state anything about...


Edit: [Carbon], 4 paragraphs back.

Edited 2007-06-14 17:15

Reply Parent Bookmark Score: 5

edwdig Member since:
2005-08-22

No, it would be like deprecating Win32s, a temporary API that has *always* been announced as so, whose only purpose was to ease the transition of legacy applications to current modern APIs while not losing the currently installed user base which *at the time* comprised most of the users. Oh wait, that happened for how long now, half a decade?

Not sure what you're trying to say there, but you don't seem to grasp what Win32s was. It wasn't some sort of transition API meant to be discarded. It was an implementation of the Win32 API (which is the core of the WinNT and Win9x lines) on top of Win16 (the older Windows API). It basically implemented all the parts of Win32 that could easily be bolted on top of Win16. You didn't get threading and some other fancy stuff.

In short: A valid Win32s program is a valid Win32 program. Win32s wasn't some transition API intended never to be spoken of again. It was a backport of Win32 to the extent that was reasonably possible.

If you want a Mac analogy, it would be like Apple porting large chunks of Cocoa to MacOS 9 after the release of OS X to help developers transition.

Reply Parent Bookmark Score: 1