Road to Mac OS X 10.6 Snow Leopard: 64-Bits - Page 2

Amen to that. There still hasn't been any real confirmation that 10.6 will be intel only, just speculation.


Logic Audio. Big sample libraries are multi gig these days. I'd kill for a 64 bit version of the app, there have been 64 bit audio apps on the windows side for a couple years now, and us mac users are left out in the cold (Logic maxes out about 2.8 gigs of memory) while they can load up as much ram as they can afford to buy.

And isn't photoshop one where it could make a difference?

Sadly, right now Apple IS lagging behind windows in terms of 64 bit apps that are available. Of course it would be great to see APPLE release one of their own apps as 64 bit, but they seem to find doing it as difficult as everyone else.

Vista may actually push 64-bit though, as it has a true 64-bit kernel, 64-bit drivers, and a few 64-bit apps, as more and more new PCs are coming with 4 GB of RAM and hence Vista x64.

I like how Apple is going to handle 64-bit better than Windows in most respects, but Apple is still playing with a 32-bit kernel and PAE at the moment.

Hmm, I don't think that is going to be the case for end users; as RIA start to rise, so will the grunt to run complex javascript/actionscript/etc will rise with it. Believe me, provide a programmer with more power, and they'll find a way to not only utilise it but complain there isn't enough.

As for Photoshop and the lack of 64bit, it actually tells me that they're very poor programmers at Adobe. If they wrote their application properly, then their back end and front end shouldn't be so reliant on each other that a re-write is required - it would be just a matter of reconstructing a new front end in Cocoa. Yes, it would take a while, but it would still allow them to maintain and port the back end to 64bit carbon, and use Cocoa 64bit for the front end (as mentioned in the article that Carbon/Cocoa code can be mixed and matched).

I hope, however, they do something about h264 encoding, its terrible that something like x264 can encode faster and produce better results than a commercial product.

I think the convention assumption is that applications must be 64bit to take advantage. If one has a look at the architecture documentation in reference to the original hammer/amd64 design - the whole idea was that you could recompile 32bit applications running on a 64bit operating system and access the new registers. 32bit OS on amd64 was in compatibility mode, 32bit recompiled with the amd64 switch on a 64bit operating system meant that it was running in long-mode, which enabled it to access a wide variety of features by the processor running in native (long-mode).

I'm sure there is the original PDF still out there, it goes into great detail about how 32bit and 64bit applications both benefit merely from a recompile with the amd64 switch, even if they aren't written from the ground up to be 64bit.

On a more serious note though; I remember seeing this 'internet addiction' BS that was going around - the only reason why there isn't 'television addiction' is because apparently it is socially acceptable to vegetate in front of a one-way device for hours on end versus using a computer that requires mental agility. The double standards in society is amazing imho.

Wikipedia is your friend.

Start here, here and here.

Summary: despite its name the Core Duo processor was not based on the "Core" microarchitecture - it was actually just a fairly minor evolution of the Pentium-M, itself based on a 32 bit microarchitecture called "P6". Core 2 processors are based on the "Core" microarchitecture, which brought many changes, including "64 bit-ness".

Let it snow - let it snow - let it snow

Didn't you know speculation and opinions are the same as facts in this society? If somebody somewhere said so it's must be true.

Apple's given a lot of mixed messages on the relative weighting of Cocoa and Carbon. While I agree with you that Apple's made it clearer in the last few years, there was little reason to suspect in mid-2007 that Apple would drop 64-bit Carbon, especially after demoing and releasing it.

I didn't catch it in the article, but will 10.6 run on a Core Duo system? Or is Snow Leopard going to drop support for 32bit systems entirely? Forgive my ignorance... I'm not really up on this stuff so I need the experts to dumb it down a shade.

So that's two applications (I already mentioned PS), used my a small minority of professional users, and only some of those have come up against the limits.

As I said, this doesn't really mean much for most people, even if it is important to get it done. It's a meaningless technicality and nothing to get excited about unless you're a nerd who wants to allocate more than 4G of memory for some reason.

Are you seriously saying that people need more than 4G to run Javascript programs? I hope I never see the day. And you seem to be making a case for software bloat. I predict Microsoft Word will be the first program that requires 64 bit to launch.

Adobe programmers are not bad programers and it's just not that simple. It's not just about the front end, there are more APIs than that involved. Apple is the guilty party for misleading developers.

That's not going to make a whole lot of difference to the speed of the code and is not the point of 64 bit at all. Intel CPUs use register renaming and implements more than 8 registers in the CPU. Any advantage would spring from the compiler doing a much better job compiling given the extra registers, which is questionable.

Well I grew up thinking we had mountains in Scotland so The White Mountains in NH being twice the size of those seem pretty big to me I am guessing you are in Tibet?

Just by looking at the direction Apple apps were taking for their UI I'd suggest it's been obvious for a long time. Carbon UIs stand out like a sore thumb.

I think the problem is Adobe's cross platform UI library and also the old Macromedia crap they've inherited - carbon and Javascript based! Merging all that together and stepping up to Cocoa style UI guidelines and cross platform is going to be some job.

I don't think it was so, really. Non-Cocoa code is alive, growing, and supplying functionality to Cocoa. Also, Apple directed everyone to adopt new Carbon UI parts to be 64bit-able and gain certain new UI features.

A year later, with these Carbon UI parts nearing completion, and some software companies carrying app prototypes to test, Apple cancelled them and left Adobe, Trolltech, AutoDesk and others facing having to redo their apps' UIs on a non-multiplatform-friendly biggie conversion project-unproven API (where is, say, Cocoa FCP?) and with an unsatisfying IDE to work with.

We could say Apple did it's real Cocoa statement then. But I don't think that was good news at all for multiplatform programmers and OS X as a big players multimedia platform.

When Apple unveiled Carbon and Cocoa at WWDC, the message was loud and clear: Cocoa for new apps, Carbon for legacy code *only*, move to Cocoa as soon as you can. I was there. This was the constant, consistent message.

And what happened? All the devs who screamed bloody murder about Rhapsody, and threw a fit until they got Carbon *STILL* weren't happy, and continued to scream bloody murder. So Apple backed off the intensity of the message.

They went so far as to continue developing Carbon, spending time and resources that could have been used to move the platform ahead, just to appease the legacy devs. At that time, the legacy devs were a significant portion of the dev community.

Now, the message has been received by pretty much everyone except Adobe, Microsoft, and Eclipse. (Although oddly, some of Adobe's engineers are coming to the rescue of Eclipse by porting SWT to Cocoa for them...) Further, they aren't quite as critical to the success of the Mac as they used to be. Apple can push back a bit.

The yanking of 64-bit Carbon at the last minute was kind of assholish, IMO, but the move to 64-bit was, from a technical POV, the right time to drop as much legacy cruft as possible. Who was going to benefit from 64-bit Carbon, really? Adobe and Microsoft. That's pretty much it. This was one rare case where technical reasoning overrode inter-company politics.

To us who have been around a long time, the message has *always* been: Cocoa is the future, Carbon is a stopgap. The only variance was how loudly that drum was banged.

snafu: care to explain how Cocoa is any worse for cross-platform production than Carbon? They're both proprietary Mac-only APIs, they both can call C and C++...

You really think that even if they only had to rewrite the front end of Photoshop, that still wouldn't be an absolutely enormous job.

And since Apple has showed no signs of shipping 64 bit versions of any of their apps, wouldn't you say that that would make them "very poor programmers" as well?


No, it's just something that isn't useful to a majority of users yet. Just because the advantages are only helpful to a minority right now doesn't make the (real!) advantage a "meaningless technicality" nor does it make those who have a use for it "nerds".

We get it, you don't care. Why not move on instead of trying to defend the notion that it's somehow useless?

Devs make decisions based on Apple announcements, not speculation based on "the direction Apple apps were taking for their UI". And up until mid 2007, Apple was telling devs that Carbon would work for 64 bit.

So specifically which Apple apps are on Cocoa now? I'm particularly interested in pro apps. Is there a list somewhere? Is there an easy way to tell from looking at the app?


That would imply that Apple itself gets that Cocoa is the way to go, and that the smart move would be starting to switch to Cocoa years ago. So again, how many apple apps are Cocoa?

Can you really blame any company for not supporting something that apple hardly uses themselves?

I can't find a repository so unless someone comes along with an answer I'll devise a method to find out which are which and then post them to a Wikipedia page for easy viewing and editing. It would also be nice to see how much attention Apple has given Cocoa over Carbon with each new OS revision.

That would be awesome. I'm kind of surprised there isn't already a list like that on wikipedia or somewhere similar.

If you'd actually bothered to read any of the discussion you'd realise I'd already said exactly that. I was addressing another question: The question is if it's an interesting topic or a issue for your average reader. The answer is no.

Nice ad hominem, that's not a tired internet cliché at all.

So if the topic isn't interesting to you, why are you still following the thread about it? And why do you think that anyone here cares if one random anonymous schmuck on the internet thinks it's interesting?

Isn't it well known that FCP and Logic are undergoing huge rewrites to make them 64-bit ready?

Since Aperture is fairly new, I imagine it will be relatively trivial to make it 64-bit in the next revision.

And Phenomenon (Shake's successor) will be 64-bit out of the gate.

What other Pro Apps does Apple have that would require 64-bitness?

Yes, that is so, but it is easier to map multiplatform UI features to Carbon or create new ones based on it, and that avenue is closed for 64bit. When most comments talk about separating the program's logic from the program's UI, they seem to assume that the UI is the easy part, and that's not necessarily so, when one considers, say, Maya's UI or After Effects'. Cocoa won't cover for their needs in a straightforward way.

Anyway, it feels a bit forced to do a "what was Adobe thinking all these years", as if it was so easy peasy a porty: how many gigantic apps is CS3 composed of? A dozen or so, plus a inmense community of plug-in developers which will have to rewrite (again!) their products (we'll see how many we lose this time). It's not trivial, it was even less so in the past, and they gain nothing but 64bitness and a big headache testing and reoptimizing things.

Anyway, of course they are going to do it: http://blogs.adobe.com/jnack/2008/04...hop_lr_64.html

How many pro apps has Apple ported from Carbon to Cocoa? Do they intend to port any, actually? One suspects we'll see the Pro Apps UI toolbox inherit what's left of Carbon64's development and so sidestep the issue.

Where did you hear that, or is that just speculation?

People who have been to music trade shows and actually talked to guys on the Logic dev team have said that the word from them is that they have NO plans to update Logic to 64 bit, and that if they did, the app would take a major performance hit (which I have a hard time believing).

Hopefully both apps are getting ported to 64 bit, but is there any evidence that that's actually happnening?

Or that we'll see the result before the 64 bit version of the Adobe apps ship?

Hmm. I'm not sure I agree with that. In fact, I'm pretty sure I don't, as a blanket statement. Carbon may feel more familiar to someone coming from Win32 or an X environment, but that's because it's similarly a legacy design. Callbacks, resource maps, and all those things we all thought were so slick 20 years ago are kind of outdated these days.

Furthermore, if someone ports their UI from another platform to the Mac, and expects to be able to just slip in some Carbon-style callbacks, calls, and so on into their other-platform UI, and have it work, well... it'll *work*, but it's going to look like *ass*. Mac users will notice, even if no one else does. If you want to play in the Mac sandbox professionally you need to step up and create a *Mac UI*. That's all there is to it.

Given that constraint, the UI code is likely to be very Mac-specific, even if it Carbon. The cross-platform argument goes out the window at the UI level, for any serious developer's app, if you ask me. Back-end? Sure! Knock yourself out. Build up those C and C++ libraries for all platforms - I do it that way too. But there's no reason why a Cocoa UI can't call into them just like a Carbon UI.


This is quite true. UI design is a pain in the butt, which is why so few developers manage to get it right, or even in the ballpark.


No one said it was easy, but that it was necessary... and no one expected it to be fast, which is why there was a what, *9 year gap* between "Carbon is for legacy code" and "By the way... we're not bringing Carbon forward to 64-bit." The writing has been on the wall every since Carbon and Cocoa were unveiled. I think a decade is enough time for everyone to get the hint and prepare their plans, don't you?


Of course. They don't have much choice.


That's an interesting idea, and a possibility. Kind of underhanded if so, but I'm betting that they'll be Cocoa up top.

Remember, as the years have progressed, most of the Carbon functionality has been pulled out of Carbon and put in Core*, which Carbon then calls. And so does Cocoa. *Most* of what devs expected in Carbon should still be available, just through a different API. Not all of it, obviously, but they get a lot of other things for free instead.

I'll be interested to see that list of apps that are Carbon, Cocoa, and when they changed over.

But don't forget that up until mid 2007, Apple was telling devs that they WERE bringing carbon to 64 bit. There's no question that devs would have started things sooner and made different plans if Apple had said that carbon wouldn't make the jump in the first place.

And if nine years is such a long time to get the message and switch things over, then why hasn't apple done it with most of their OWN apps?

That would be the assholish bit I mentioned earlier. Pulling it out from under devs was not nice, but OTOH, they *had* had a number of years to make plans, right?

"Carbon is going away, move to Cocoa."

"Oh, ok. Um... how's that 64-bit Carbon coming?"

"Great! Hey... waitaminnit..."

Without knowing anything about the specifics, my wild assed guess is that 64bit Carbon ran into some difficulties, and they realized that if they just stopped it, they'd finally force that move to Cocoa they'd been trying to get people to do since before MacOS X arrived. As long as it was going well, they were willing to do it, but once snags were hit, the headache to fix it was larger than continued legacy support would be in the future.


It's called 'eating your own dog food'. If you are producing the APIs for your development community, it's in your best interest to write some of your own critical apps in it.

Drag a highlighted text snippet from a text field to the desktop. If it works it is a Cocoa app.




Apple uses it quite a bit. But Apple has also said for years Carbon is not a second class citizen and HAD to code Pro apps in Carbon to prove the move to OS X was even viable for large third party devs. Now Apple is saying Carbon is just fine for existing 32-bit apps, but they aren't going to extend it for 64-bitness. Why, this reduces their out year API development and QA effort by nearly half. They will be able to do more things rather than the same things twice. And yes, Apple is moving apps over to Cocoa as it make sense to do so.

LOGIC->Replacement to LOGIC in 64 bit and evolutionary but written in 64 bit Cocoa.

Now that Carbon is freaking dead let's clear the airwaves.

CARBON WAS ALWAYS A SECOND CLASS PLATFORM.

Politically, they had to make it First Class to save face and keep Adobe, Macromedia and Microsoft on-board.

Having worked at NeXT I saw how quickly large 3rd party houses can kill a platform--no apps from them and the platform suddenly isn't viable.

NOTHING ADOBE AND MICROSOFT CAN DO WEAKENS APPLE NOW.

They either write their applications in Cocoa or lose out on markets and profits that Apple will gladly soak up or work with other 3rd party devs that have promising applications to fill the void.

I suggest those that can't figure this out, sign up for an NDA Developer Account--the freebie is great but you aren't really in the loop, download Xcode 3.1 and write Cocoa code.

LLVM and the future of Apple's Dev Tools: http://llvm.org/devmtg/2008-08/

If you want to keep current I suggest you keep in the loop.

Either way, speculating about Apple not moving it's tools to Cocoa really shows you know nothing of the history of NeXT nor today's Apple Engineering.

Very good.

It was a close call for a while.

That wasn't an ad-hominem, it was an admonishment. As I said, try reading more carefully.

Anyway, these forums are for discussion. If you don't like what I'm discussing don't read it (which you're mostly not doing anyway).

mdriftmeyer's got it right.

Carbon was only a huge issue with the big, bloated laggards: Adobe, Microsoft and Intuit.

Adobe has been inflicting a Windows-like UI on its Mac base for years, Microsoft has been looking for ways to keep the Mac in its place, and Intuit has been just plain lazy.

Of the three, only Photoshop is viewed as a must have anymore. Quark is 1000x better than before, OpenOffice will be out before year end, and there are 5 or 6 good alternatives to Quicken.

If they want to keep their historical status, I say let them fight for it.
The whole platform shouldn't be held back by three laggards.

STANDING OVATION

Thank you.


Hear, hear. I love me some llvm. Oh, the possibilities.

mdriftmeyer is absolutely right. It has been clear for a full decade that Carbon is transitional and temporary. I'll go further and say that it was a stupid mistake for Apple to ever do any development on 64 bit Carbon.


Snow Leopard would certainly be the sensible time to drop support for both PPC and 32 bit Intel. Legacy code should not be maintained forever. If you want the benefits of Snow Leopard, buy a Mac produced after 2005.

That's what I said, minus the second sentence editorial.


WhereTF did that all come from? Did you even read what you quoted? You certainly weren't replying to anything in my post after the CARBON EDITORIAL. I have no problems with that line, dev's perception doesn't need to mesh with Apple's message, and I was relating the message. I agree fully that moving away from Carbon is a Good Thing™, I even gave a reason why!

I don't tend to be as vitriolic as you were on whether the Apple message and reality are in sync, Apple said from WWDC in 1999 that Cocoa was the way to go for all new apps, but that Carbon would maintain feature equivalence for existing apps. That message NEVER changed, that's all I said. If you want to call that second class, I won't argue, but I think it's a tad over the top.

After that, I said absolutely nothing about Apple not moving to Cocoa. Actually I said the opposite. So either READ THE POST; or break out the multi-quote goodness to point the ire at the real recipient; or chop your responses into separate posts.

Which Apple Apps are NOT Cocoa now though?

iTunes - inherited but there's quite possibly cross platform reasoning there.

Safari? - not inherited but again cross platform reasoning

Final Cut - partly inherited

Logic - inherited

Filemaker - old and cross platform


Everything else, especially the in-house born stuff is Cocoa including iLife, iWork, Aperture... and it shows or maybe they just hide it well.

I just can't bear to even look at some of the old Carbon UI products from MS and Adobe and for that matter Firefox. They're just horrible. Unfortunately I have to use them occasionally but more and more I'm picking Mac only apps for web development and use.