iTunes 10.5 Beta is 64-bit, and... Cocoa?

[commander.data]

My guess: it’s still Carbon-based, even if third-party Carbon apps can’t be 64-bit. Maybe even some weird hybrid. But a new UI will come eventually.

I don't see why a hybrid 64-bit Carbon-Cocoa program is weird. In fact, it seems to be Apple's recommended transition method for Carbon developers.

http://developer.apple.com/library/...n.html#//apple_ref/doc/uid/TP40004381-CH1-SW1

Most APIs in Mac OS X v10.5 are available to both 32-bit and 64-bit applications, but some APIs commonly used by Carbon applications are not. In particular, the APIs used to implement a Carbon user interface are generally available only to 32-bit applications. If you want to create a 64-bit application for Mac OS X, you need to use Cocoa to implement its user interface.

It's always portrayed that Carbon never got 64-bit support, but based on Apple's documentation, it's not an all or none decision. It seems like most Carbon APIs were transitioned to 64-bit, just that Carbon UI APIs remained 32-bit, so it isn't possible to make a completely Carbon 64-bit application.

http://developer.apple.com/library/...t.html#//apple_ref/doc/uid/TP40004381-CH3-SW1

Because most Carbon UI functions are not available to 64-bit applications, you have two possible development paths. You can continue modernizing and improving your Carbon UI with the expectation that your application will remain a 32-bit application for the foreseeable future. Apple plans to support and maintain the 32-bit Carbon Human Interface Toolbox, although Apple will not be adding any significant new features to these APIs. The other development path is more challenging and also potentially more rewarding in the long term. You can develop a 64-bit version of your application, using Cocoa to implement your UI. As you do so, consider going one step further and implementing other parts of your application using Cocoa.

It seems like the only requirement for Carbon applications to be 64-bit, is that they implement their UI in Cocoa. The back-end code can largely remain unchanged. Redoing non-UI Carbon code in Cocoa is a "one step further" option, but not necessary for 64-bit support.

64-bit iTunes could presumably be done just like this. A new 64-bit Coca UI, admittedly one that looks the same, and the existing Carbon back-end spruced up with 64-bit compatibility. This method actually makes the most sense to save work since Carbon code seems to be considered easier to port to Windows than Cocoa, so the 64-bit Carbon backend can be shared between OS X and Windows and only the UI needs to be different/rewritten for each platform.

 

[drtimhill]

Reason for 64-bit..

The article says the main reason for 64-bit is access to a larger (virtual) address space. In fact, that's mostly true for things like database servers. For apps like iTunes there is little advantage to the larger address space.

The big gain for regular apps like iTunes when going to 64-bit is access to additional processor resources (registers) that lets the app run most efficiently, typically about 10% faster than the same 32-bit app, though there is some loss because it can take longer to handle 64-bit values when a 32-bit one would have been just as good.

Just an fyi.

--Tim

 

[MrNomNoms]

The article says the main reason for 64-bit is access to a larger (virtual) address space. In fact, that's mostly true for things like database servers. For apps like iTunes there is little advantage to the larger address space.

The big gain for regular apps like iTunes when going to 64-bit is access to additional processor resources (registers) that lets the app run most efficiently, typically about 10% faster than the same 32-bit app, though there is some loss because it can take longer to handle 64-bit values when a 32-bit one would have been just as good.

Just an fyi.

--Tim

IIRC, another benefit was ASLR but that has since been expanded to include 32bit and 64bit applications which will hopefully roll onto greater security in Lion. The thing that confused me about Snow Leopard is why they didn't make some major breakage with when they had the chance; if you're going to go 64bit then why not go for gold and push better security even if it breaks some applications in the process? or was it simply a matter of chewing off things in small chunks as to avoid choking (aka Windows Vista)?

 

[peopleinatree]

iTunes 10.5 is not Cocoa... or at least not fully Cocoa. Cocoa apps are dock aware; meaning when you pull their window title bar below the dock and let go it will move the window title above the dock. iTunes 10.5 does not exhibit this behavior.

 

[commander.data]

The article says the main reason for 64-bit is access to a larger (virtual) address space. In fact, that's mostly true for things like database servers. For apps like iTunes there is little advantage to the larger address space.

The big gain for regular apps like iTunes when going to 64-bit is access to additional processor resources (registers) that lets the app run most efficiently, typically about 10% faster than the same 32-bit app, though there is some loss because it can take longer to handle 64-bit values when a 32-bit one would have been just as good.

Just an fyi.

--Tim

One micro-architecture detail that most people don't know is that Macro-Ops Fusion does not work on Core 2 Duo (Merom and Penryn generation) processors when in 64-bit mode. Macro-ops fusion allows Intel CPUs to decode more instructions at a time for processing and is the "+1" in Intel's 4+1 instruction decoder width. When Intel first introduced Macro-Op Fusion they claimed it can work on 1 in 10 instructions in an instruction stream and could potentially lead to up to 11% increase in performance over not having Macro-Op Fusion. 64-bit OS weren't popular back then, and Core 2 Duo didn't support Macro-Op Fusion when in 64-bit mode. This was fixed starting with Nehalem.

 

[Discoverer]

I am not a developer, however, I decided to try it out. I have to say that I like it a lot. It is much faster for me than the latest release version. And, I think it looks nicer too.

 

[PurrBall]

iTunes 10.5 is not Cocoa... or at least not fully Cocoa. Cocoa apps are dock aware; meaning when you pull their window title bar below the dock and let go it will move the window title above the dock. iTunes 10.5 does not exhibit this behavior.

Heck, 10.5 isn't even menu-bar aware- mine always starts above the menu bar.

 

[jeanlain]

iTunes 10.5 is not Cocoa... or at least not fully Cocoa. Cocoa apps are dock aware; meaning when you pull their window title bar below the dock and let go it will move the window title above the dock. iTunes 10.5 does not exhibit this behavior.

The search field has the contextual menu of Cocoa text fields (spelling, grammar, etc.). So the iTunes 10.5 main window is Cocoa.

 

[stormj]

hmmm

iTunes 10.5 is not Cocoa... or at least not fully Cocoa. Cocoa apps are dock aware; meaning when you pull their window title bar below the dock and let go it will move the window title above the dock. iTunes 10.5 does not exhibit this behavior.

It's at least part Cocoa.

Scan through it in a hex editor. It's at least *partially* Cocoa. It's full of references to NS* classes.

A lot of the things that "Cocoa" apps do automatically are just nice things that some of the classes set up for you. It's entirely possible to create an app that uses features of the Cocoa API without that for whatever reason, or that they're using a custom version.

 

[stormj]

IIRC, another benefit was ASLR but that has since been expanded to include 32bit and 64bit applications which will hopefully roll onto greater security in Lion. The thing that confused me about Snow Leopard is why they didn't make some major breakage with when they had the chance; if you're going to go 64bit then why not go for gold and push better security even if it breaks some applications in the process? or was it simply a matter of chewing off things in small chunks as to avoid choking (aka Windows Vista)?

There are actual differences at the machine language level with 64-bit code other than just access to 64-bit addressing. This is not because it's 64-bit, but because that's when they put it there. Intel 64-bit code on the mac is more secure it (mostly) prevents things like self-modifying code and has a faster sys call function, etc.

 

[Bokito]

It seems like they use a Cocoa wrapper for the whole application and completely transitioned the UI part to Cocoa. The whole application will make the switch to Cocoa eventually. I guess Apple's attempt to rewrite iTunes completely was unsuccessful and so they got onto this path.

I hope iTunes will be a little more 2011 with the changes coming. The PC version is way snappier than the Mac version. The Mac version only runs good on a Mac Pro, probably for their multithreading which seems to resolve some programming limitations in the current iTunes.

 

[JackieTreehorn]

A slightly unrelated post: how does one uninstall iTunes 10.5 beta? I want to go back to 10.3.1 so I can enjoy my iWow plugin.

 

[ipedro]

10.5 is of course just an intermediate update meant for Lion (hence the point increment). The overhaul will come when iCloud is released in the fall.

With iCloud taking the syncing duties away from iTunes, Apple will be presented with an opportunity to simplify the app to its core function of a media player.

As for the full screen mode, I'd like to see an iOS 5 iPad music app like UI. Really simplified and optimized for interchangeable operability via mouse/remote.

 

[mdriftmeyer]

The big news is that either they fork the source and support a continued Windows with Carbon or they will re-release the Mach-o/Yellow Box Runtime for Windows so they can provide the same source code in 64 bit.

This would then require only security updates for earlier releases that includes 32 bit legacy on Windows.

 

[gnasher729]

I know this is only a beta, but I'm going to say this flat out: iTunes 10.5 is crap. Full screen mode is glitchy. Traffic lights don't perform properly when iTunes is behind another application (no scroll over effect). Not all of the scroll bars have that "rubber band/springy" effect. And, a host of other minor issues. Basically, it feels subpar for a native application.

And you are either in breach of an NDA or using a pirated application.

 

[Lesser Evets]

A couple of notable changes, however, include the fact that iTunes for Lion now supports Full Screen Mode and also returns the close/minimize/maximize buttons to their usual horizontal location.

iTunes has supported full-screen mode for years, maybe forever. What it needs to do is not black out a second monitor, thus rendering the computer useless while playing a movie.

Apple has a series of small, annoying problems with iTunes which it hasn't corrected forever. Example: can't play podcasts through as a list; it only plays one and resets everything. Why?

I wonder if anyone from Apple actually uses the basic program and thinks about the consumer. There is so much other tomfoolery and doodaddery within the program that makes it look quite slick and fun, but which does very little to improve the basic function: playing music/video and customizing the play to accommodate the user.

 

[roadbloc]

At last. This is LONG overdue.

Now all they need to do is redesign iTunes from the mess it's become.

 

[Atlantico]

What happened to iTunes 10.4?

But really, since the Music Store was introduced and the iPhone/iPad, iTunes has stagnated into becoming a connective vessel between the device and the computer - it's been a while since actually playing music or sound was improved or streamlined.

It is fast enough I suppose and Apple seems incapable of just writing a decent clean rewrite of iTunes (despite some 12 thousand employees on campus, some probably even capable of writing software) - possibly because it is largely irrelevant.

iTunes works "well enough", iPads/iPhones will not need the Mac to connect with with iOS 5 and the software engineers aren't working much on Mac apps anyway. So for reasons of convenience (i.e. to enable some of the "important" new features of Lion) iTunes 10.5 is partially written in Cocoa.

 

[bigwig]

Now all they need to do is redesign iTunes from the mess it's become.

That'll probably happen when iTunes gets native FLAC support.

 

[goodcow]

What problems ? It's fast and everything works well.

When plugging an iDevice into the computer makes iTunes freeze a $4,000 MacPro for about ten seconds, it's neither fast nor working well.

 

[goodcow]

And you are either in breach of an NDA or using a pirated application.

Who the hell cares. You're on a website whose purpose is to post news about people leaking information.

 

[zedsdead]

When plugging an iDevice into the computer makes iTunes freeze a $4,000 MacPro for about ten seconds, it's neither fast nor working well.

+1

Let's hope that the rewrite itself will be a surprise at the fall keynote. iTunes needs some serious attention.

Visually, I cannot stand the yellow playback section at the top. Why is it still look like something from the early 1990's like the screen of an old Gameboy?

 

[Sbrocket]

Shouldn't this be trivially easy to figure out? Please explain to me if I'm wrong, but an application using Cocoa should be easy to detect by spending a few minutes in a debugger or even a hex editor, right?

OK... iTunes 10.5 is referencing some AppKit classes if you search through it in a Hex Editor. Doesn't that mean it's at least partially Cocoa? (Other than nib files, I've never seen a reference to any NS* class in a Carbon app, and even then only NSObject -- not NSNumber, NSAutoreleasePool, NSBezierPath, etc. as you can find mucking around in iTunes 10.5)

Anyway, other than whiners at Adobe, no one cares that Apple doesn't follow the same "rules" as outside developer, and, as such no one cares if they are making 64-bit Carbon apps.

Update: Transitioning to Cocoa doesn't mean they would necessarily have to change a thing. I guess you can decide whether the version increment skipping 10.4 means that much.

There are a number of ways to look into this that don't involve a hex editor, I don't know why people jump on that approach. /usr/bin/otool, /usr/bin/strings, and /usr/bin/file among others can give you lots of information. Of course, iTunes links against both Carbon.framework and Cocoa/AppKit.

And NS* classes are not necessarily Cocoa. NSAutoreleasePool and NSNumber are Foundation. You don't need a Cocoa UI to use the Foundation collection classes or to subclass NSObject, hah.

My unscientific guess is that iTunes isn't so easily categorizable because its probably a single codebase for both OS X and Windows, which results in some oddities at the user interface level. Not to mention that they do a lot of things custom with iTunes and don't really stick with standard NSWindow and brethren behaviors.

I really doubt they ported over the HIToolbox to 64-bit *just* for iTunes without giving it to third-party developers, though, which would mean iTunes would have to have a Cocoa UI.

 

[KnightWRX]

Shouldn't this be trivially easy to figure out? Please explain to me if I'm wrong, but an application using Cocoa should be easy to detect by spending a few minutes in a debugger or even a hex editor, right?

Or simply using otool -L

iTunes 10.3 :

$ pwd; otool -L iTunes | grep -i carbon
/Applications/iTunes.app/Contents/MacOS
	/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 152.0.0)
	/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 152.0.0)

 

[Schtumple]

At last. This is LONG overdue.

Now all they need to do is redesign iTunes from the mess it's become.

I know right? It genuinely looks a bit off now, nothing quite syncs in place... Would love to see them put in the minimalist design ascetic they had up until a few releases ago.