Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 64-bit Carbon



On 14-Jun-07, at 2:51 AM, Laurence Harris wrote:


On Jun 14, 2007, at 1:42 AM, Russell Finn wrote:

I've been following this thread with interest. May I throw out a few observations?

1) "No 64-bit Carbon in Leopard" is not the same as "no 64-bit Carbon ever".

I was wondering if someone else was going to mention that. ;-)

(Of course, Eric hinted we may learn more about this after the HIToolbox session on Thursday.) As we all know, sometimes you have to cut features to ship,

Carbon 64-bit support in Tabby (10.6) just isn't going to cut it for a lot of people. Obviously it would signal the continued support of Carbon, which many of us would see as a positive, but people who have been planning 64-bit Carbon products, just waiting for said support to appear, are unlikely to be willing to sit around twiddling their thumbs hoping it actually appears in 10.6. In addition to the obvious timeframe aspect, there's the "fool me once, shame on you; fool me twice, shame on me" effect in which people may not trust Apple if they renege this time on their last promise for 64-bit support.

Well actually, I could wait for 10.6. My main motivation for going 64-bit has been to maximize the performance of scientific apps running under Intel. I'm not out of memory yet (in fact, if anything, my memory footprint has gone down over time, thanks to some helpful tips from Ian Ollmann and the like), so I am thankfully not feeling the crunch in that regard.


Now, last year at WWDC, I was faced with the decision of choosing between two possible 64-bit migration paths. The first would have been to break my application apart into two halves (a 32-bit GUI and a 64-bit everything else) and find a way to share memory between them. The second would have been to concentrate on removing deprecated APIs and have a Carbon executable ready to go 64-bit by the time Leopard rolled around.

I decided to go with the second option, but it has been a long road full of obstacles. Getting rid of every last vestige of Quickdraw, for example, has been arduous, and I am still not there yet. I probably won't make if for Leopard either, since I have had to turn my attention away from Mac development these past few months, and I can certainly appreciate how much effort must have gone into bringing 64-bit to the GUI levels of OS X. If it's simply a matter of 64-bit Carbon not making the fall deadline, I can accept that. If they have abandoned it entirely, on the other hand, I will feel rather betrayed, since going with Plan B will have set me back about a year.

Now, I realize there will be people who say removing deprecated APIs is worthwhile regardless of the 64-bit issue. Please keep in mind, however, that I am essentially a one-man show as far as Mac development is concerned, and I can't even devote all my time to that, so it's a question of prioritization. Had I stuck with the initial plan, I may have had 64-bit capability by now. Removing deprecated APIs may mean my application will look nicer with its resolution-independent graphics and what not, but really, for a scientific package, the former would have been much more valuable.

-Ted

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden

This email sent to email@hidden
References: 
 >Re: 64-bit Carbon (From: Laurence Harris <email@hidden>)
 >Re: 64-bit Carbon (From: Tony Scaminaci <email@hidden>)
 >Re: 64-bit Carbon (From: "Russell Finn" <email@hidden>)
 >Re: 64-bit Carbon (From: Laurence Harris <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.