[lpkmckenna]

I never thought this day would come: 64bit Cocoa iTunes now available.

I don't know what benefits this is gonna bring to users, but I'm kinda amazed. I guess full-screen will be fun.

[davidflas]

I can't install it on the Mac Book Pro in my sig....

[lpkmckenna]

So I installed it, opened it, and they changed the look back: no more weird window without a titlebar, no more vertical window controls. And now I can't stand how it looks! Damn you Apple!!

[Sealobo]

seriously... what has changed?

[lpkmckenna]

Those are the only differences I see. Two minor visual tweaks. I don't have Lion, so if there are Lion-specific changes, I can't see them. Activity Monitor doesn't say it's 64bit, either.

[subego]

Originally Posted by lpkmckenna 

I never thought this day would come: 64bit Cocoa iTunes now available.

I don't know what benefits this is gonna bring to users, but I'm kinda amazed. I guess full-screen will be fun.

It'll be nice if you can full screen the visualizer without locking up the entire UI.

[CharlesS]

Originally Posted by lpkmckenna 

Those are the only differences I see. Two minor visual tweaks. I don't have Lion, so if there are Lion-specific changes, I can't see them. Activity Monitor doesn't say it's 64bit, either.

Activity Monitor says it's 64-bit on mine, and the find tool also reports the presence of an x86_64 binary. It's 64-bit.

[lpkmckenna]

Very strange. Are you using Lion?

EDIT: System Profiler says 64bit, but Activity Monitor does not.

[P]

It's 64-bit, but I think it's time to stop saying Cocoa as opposed to Carbon. Actually, I think that that time was several years ago - the two have grown together.

lpmckenna: do you have any iTunes plugins installed, perhaps?

[Art Vandelay]

64bit on Lion only, otherwise 32bit still.

[lpkmckenna]

No plug-ins. Oh well, not like this is affecting anything.

[CharlesS]

Originally Posted by P 

It's 64-bit, but I think it's time to stop saying Cocoa as opposed to Carbon. Actually, I think that that time was several years ago - the two have grown together.

The two always were linked to some extent — for example, Cocoa apps have long used Carbon menus behind the scenes, and it's always been possible to incorporate many of the Cocoa views in Carbon apps.

The distinction remains, though, because what makes an app Cocoa or Carbon is the run loop. Applications that call NSApplicationMain() are Cocoa apps, and apps that use RunApplicationEventLoop(), ReceiveNextEvent(), WaitNextEvent(), etc. are Carbon apps.

Originally Posted by lpkmckenna 

EDIT: System Profiler says 64bit, but Activity Monitor does not.

Upon looking at the Info.plist file, it looks like iTunes is set up so that the 64-bit binary will only run under Lion, and Snow Leopard and before still get the 32-bit binary.

[ShortcutToMoncton]

Huh. Still in Snow Leopard but scrolling is far smoother and more immediate on my largish (~180gig) library. Immediately noticeable. Sweet.

[Spheric Harlot]

Originally Posted by CharlesS 

Upon looking at the Info.plist file, it looks like iTunes is set up so that the 64-bit binary will only run under Lion, and Snow Leopard and before still get the 32-bit binary.

What is the point of doing this?

Are there fixes to 64-bit Cocoa UI libraries (AFAIK, it's mostly the GUI that's been Cocoa-fied?) that are exclusive to Lion?

[P]

Originally Posted by CharlesS 

The two always were linked to some extent — for example, Cocoa apps have long used Carbon menus behind the scenes, and it's always been possible to incorporate many of the Cocoa views in Carbon apps.

The distinction remains, though, because what makes an app Cocoa or Carbon is the run loop. Applications that call NSApplicationMain() are Cocoa apps, and apps that use RunApplicationEventLoop(), ReceiveNextEvent(), WaitNextEvent(), etc. are Carbon apps.

I guess using the event loop is one way to make a distinction, but it's really just a long scale. Also: Carbon can use two different event loops - the old OS 9-derived WaitNextEvent setup (based on a hack by Andy Hertzfeld from 1985, oh yes) and the newer Carbon Events (Page 15 of this document explains the difference, if anyone is interested). Carbon apps based on WaitNextEvent are the source of all the "Carbon bad" stigma that you still see every now and then. A Carbon app based on Carbon Events was much better, and in effect faster than Cocoa (because QuickDraw is STILL the fastest way to draw to the screen, and not even Apple seems to understand why)

[reader50]

Originally Posted by CharlesS 

Upon looking at the Info.plist file, it looks like iTunes is set up so that the 64-bit binary will only run under Lion, and Snow Leopard and before still get the 32-bit binary.

Has anyone tried a plist edit, to see if the 64-bit binary will run under earlier OSes?

[Art Vandelay]

Just tried it and got a dialog saying 64bit needs 10.7.

[CharlesS]

Originally Posted by Spheric Harlot 

What is the point of doing this?

Are there fixes to 64-bit Cocoa UI libraries (AFAIK, it's mostly the GUI that's been Cocoa-fied?) that are exclusive to Lion?

There are always changes to the system libraries and frameworks with every major OS X release, with plenty of new APIs and features added. There are actually very good reasons that they could be doing that, and Pacifist 3.0 (once I manage to get the thing finished) is actually going to be doing something very similar. Hacking the plist file to make the 64-bit binary run on Snow Leopard would very likely be ill-advised. And come on, can you really tell the difference between a 32-bit and a 64-bit app? I know I can't.

[CharlesS]

Originally Posted by P 

I guess using the event loop is one way to make a distinction, but it's really just a long scale. Also: Carbon can use two different event loops - the old OS 9-derived WaitNextEvent setup (based on a hack by Andy Hertzfeld from 1985, oh yes) and the newer Carbon Events (Page 15 of this document explains the difference, if anyone is interested). Carbon apps based on WaitNextEvent are the source of all the "Carbon bad" stigma that you still see every now and then. A Carbon app based on Carbon Events was much better, and in effect faster than Cocoa (because QuickDraw is STILL the fastest way to draw to the screen, and not even Apple seems to understand why)

Yep, could have sworn I mentioned those different run loops in the post you were quoting there. I mentioned three, but there are actually four — if you count GetNextEvent, which I left out because it hasn't been best practice since at least System 6 or perhaps even earlier. The run loop is, and always has been, the distinction between a Cocoa and a Carbon app, though.

As for QuickDraw, not only is it not the fastest, but in fact it's not any way to draw to the screen at all these days. It was removed from the 64-bit versions of the frameworks back in 10.6 and is no longer usable.

[Spheric Harlot]

Originally Posted by CharlesS 

There are always changes to the system libraries and frameworks with every major OS X release, with plenty of new APIs and features added. There are actually very good reasons that they could be doing that, and Pacifist 3.0 (once I manage to get the thing finished) is actually going to be doing something very similar. Hacking the plist file to make the 64-bit binary run on Snow Leopard would very likely be ill-advised. And come on, can you really tell the difference between a 32-bit and a 64-bit app? I know I can't.

No, I can't (well, apart from something like Logic, where the difference in memory and plug-in handling is obvious and the switch is, naturally, a very welcome one).

That's why I asked - maintaining a separate 32-bit and a 64-bit build that apparently accesses different architecture must have benefits that offset the greater development effort involved. Otherwise, why bother at all?

[CharlesS]

It's not necessarily that great a development effort — without knowing exactly what they did, it's quite possible that they just surrounded some Lion-only features with #ifdef __LP64__ to keep them out of the 32-bit builds.

[Spheric Harlot]

But Why?

[CharlesS]

To keep things that need to be out of the Snow Leopard binary, out of the Snow Leopard binary.

[Spheric Harlot]

Such as what kind of things?

Sorry to keep harping — I'm trying to understand.

[CharlesS]

Well, there's no way for me to know that, since I don't have the iTunes source code.

In my case, I'm doing something similar with Pacifist 3.0. Pacifist 3.0 is planned to run on everything from 10.4 on up, but I'm limiting the 64-bit version to run on Snow Leopard and higher. This way, I can use language features that were introduced in 10.5 (foreach loops) and 10.6 (blocks), as long as I restrict them to the 64-bit binary. This lets me put in little performance optimizations in the 64-bit version that wouldn't be possible if the binary had to work all the way back to 10.4. So, that's what I use it for. Unfortunately, I haven't done too much investigating to see what new language features are available in Lion, but it's possible that they could be writing some new Lion-specific code using ARC or something, making it incompatible with the old OS releases.

Another possibility is that they could be taking advantage of new features offered by the 64-bit runtime itself. There are a bunch of nice features that come from the non-fragile ivar layout in 64-bit land, which can make your coding a bit simpler and quicker. If they were including classes that were only relevant on 10.7, then it could make sense to do this.

Also, this is a real stretch, but since Lion is 64-bit only, and is thus guaranteed to be running the 64-bit version of the binary, Apple might be using ifdefs instead of version checks to separate out Lion-specific code. In theory, this would be slightly better for performance by eliminating all the version checks, and would reduce the size of the binary by a few bytes, but in practice the difference would be negligible. But who knows, they could be doing that.

This is all pulled out of my ass, though. To really know what they're doing, I'd need to have the source code, which I obviously don't.

[Spheric Harlot]

Thanks for the details. That makes some sense to me.

New version of iTunes still does not fix the buffering of radio streams. I'm on a 15 Mbps connection and every 5-20 minutes iTunes will lose a song, buffer it... but the progress bar won't even show up, and it won't buffer anymore. I have to keep restarting my streams.

[lpkmckenna]

I read at Ars Technica today that iTunes no longer uses QuickTime for video playback, and now can't decode some kinds of videos. Has anyone experienced this issue?