There Must Be a Cocoa iTunes Coming + Vista 64-bit iTunes?

[Update: Apple released iTunes 8, and whatever it is, it is not pure Cocoa]

[Update: Apple did release a version of iTunes for 64 Bit Vista. I don't know how it matches up with the below speculation. ]

This is entirely speculation on my part. If I had insider information, I would not betray it. This is just my uninformed opinion.


Fact 1: iTunes as we know it is a Carbon application on the Mac. It after all is the direct descendent of SoundJam, a short-lived MP3 player for Classic Mac OS. Open up its package in the Finder and see things like a .rsrc file.

Fact 2: iTunes makes heavy use of QuickTime and the Mac Toolbox emulation layer which QuickTime for Windows contains. This is what allowed the same codebase to be deployed on both OS X and Windows relatively quickly. (OK, this may not be a fact, not having access to the iTunes code, but it seems darn likely.)

Fact 3: There is no 64-bit C API to QuickTime on the Mac. There is only a 64-bit Cocoa interface.

Fact 4: Pretty much all of that Mac Toolbox being emulated on Windows is no longer available under 64-bit compiles on the Mac.

Fact 5: All new Macs are 64-bit. Apple is in a good position to start promoting themselves as The 64-bit Company, as their path to 64 purity seems easier than Microsoft's, but it will take getting all their apps there first, and convincing their major developers to follow. I assume it was easy getting their Cocoa applications there, but any residual Carbon applications would be a nightmare.

Extrapolation 1: Even Apple will not be able to make iTunes a 64-bit application without a major rewrite. After you remove QuickTime, all the old Classic Mac APIs which are not in the 64-bit frameworks, etc., there is little left. Maybe much of the task specific onscreen drawing on the Mac is now done with Quartz calls, and the networking calls are probably being done with CFNetwork calls on the Mac, and maybe they are using WebKit to do the store, and that can all be salvaged, and hopefully the code is factored such that system calls are not sprinkled all over the place, but they are going to have to bite the bullet and just write a from scratch Cocoa application and call it iTunes 8.

Extrapolation 2: If Apple is not going to extend the life of Classic Mac APIs and QuickTime C APIs for 64-bit Mac applications, what are the odds of them doing so for the emulation layer on 64-bit Vista. Pretty low. There is no obvious quick way to get iTunes as we know it on Windows to run as a 64-bit process. I guess they could if they really wanted to, but it seems a pretty hacky solution and would basically obligate them to maintain an entire OS's SDK just to run iTunes and QuickTime.

Extrapolation 3: I assume Apple cares about the future of QuickTime and iTunes on 64-bit Windows. This is not a big market now, but will only get bigger, and Windows user are not going to accept running multimedia software in 32-bit emulation mode in perpetuity. They can do two things. They can create a new framework which can play and edit QuickTime content, perhaps a set of .NET classes, and write a separate version of iTunes which makes use of these classes. Or, they can bring Cocoa to 64-bit Windows, and run the same source based iTunes as the Mac. I suspect Apple doesn't want to do either, but iPod sales are important to them. They wouldn't want those early adopter 64-bit users running to Zune.


A little Googling on "64-bit iTunes" came up with this revealing alert text in the current Windows iTunes "This iPod cannot be used because the required software is not installed. Run the itens installer and remove itunes, then install the 64-bit version of iTunes." That makes me wonder if all this is going to fall out sooner rather than later. Or maybe it's an aberration.

Anyway, that's my uninformed opinion, and we'll see if it has any relationship to reality.

[Update: See this article about how Adobe is not releasing a 64-bit version of Photoshop until they can do the major re-writing required to remove their Carbon code.]

The Future or Lack of It for Carbon

If you are tasked with maintaining a large, old—is there any other kind—Carbon application, here's an illuminating experiment. In XCode 3.0, under Build architecture, turn on 64 bit compilation for Intel. Now try to compile.


In my case, I see errors and lots of them:

error: '::FlushVol' has not been declared
error: 'HideCursor' was not declared in this scope
error: 'ShowCursor' was not declared in this scope
error: 'LMGetFractEnable' was not declared in this scope
error: 'GetOutlinePreferred' was not declared in this scope
error: 'GetPreserveGlyph' was not declared in this scope
error: 'GetWindowEventTarget' was not declared in this scope
error: 'SetFractEnable' was not declared in this scope
error: 'SetOutlinePreferred' was not declared in this scope
error: 'MoveWindow' was not declared in this scope
error: 'SetOutlinePreferred' was not declared in this scope
error: 'OpenCPicture' was not declared in this scope
error: 'SetControlPopupMenuHandle' was not declared in this scope
error: '::SetControlMaximum' has not been declared
error: '::DrawThemeMenuItem' has not been declared
error: 'GetIntlResource' was not declared in this scope
error: 'CompareString' was not declared in this scope
error: '::SetMenuWidth' has not been declared
error: 'IsWindowVisible' was not declared in this scope
error: '::GetPicture' has not been declared
error: '::DrawPicture' has not been declared
error: '::EraseRect' has not been declared
error: '::FindDialogItem' has not been declared
.... lots more errors ...

So, we have a litany straight out of Inside Macintosh Vol. 1-3: all of QuickDraw, much of the File Manager, the Control Manager, the Dialog Manager, the Window Manager, the Menu Manager, the Font Manager all gone, but surprisingly not the Resource Manager. Anything that uses Pascal strings or FSSpecs. Few of the API's which came from the Classic Mac OS survive a 64 bit compile.


I don't know in the short term, what the carrot is for getting independent developers to make 64-bit compiles. Unless you are doing something that really needs 6 GB of real RAM—very few applications—there seems to be little performance advantage for 64-bit. And, it's hard taking a Carbon application, ripping out the APIs behind its entire GUI, and putting it back together again. Lots of redesign and drudgery for little immediate payoff. In the long term, Apple will presumably stop supporting 32-bit applications, but that is in the very long term.


Plus, there are little bits of functionality in the Carbon APIs which are hard to replicate in the more modern APIs. One example is embedding one's private metadata in the PICT clipboard flavor. I'd very much like to know how to do that with the PDF API. Another example is the XOR drawing mode for doing tracking, stupid and old fashioned, yes, hard to replace, yes.


There's an Ars Technica article which goes into this in more detail.

HDHomerun Gets More And More Useful

[Update: check out Signal GH, an iPhone utility for monitoring the signal quality of an HDHomerun].

One of the best bits of tech I've bought over the last year is the HDHomerun networked digital HDTV tuner. I was reminded of this a couple of weeks ago, when I was going through the process of setting up a Mac Mini as a dual boot Leopard/Vista desktop.


The OEM copy of Vista Home Premium I picked up cheap at MicroCenter comes with Windows Media Center, which Silicon Dust supports for use with the HDHomeRun, so for no added cost, I get live TV watching with a guide, and recording. This is functionality I would not easily get otherwise, as there is no MythTV client for Vista, and I am not going to get an additional tuner for the Mini. It just happened I get all this for free because I happen to own an HDHomerun.


Not that I'm very impressed with Windows Media Center, at least not on the Mini. HD playback is a bit stuttery, unlike VLC on the same OS and hardware; and navigation is confusing. Also, there doesn't appear to be an integrated solution for using my Wiimote; Remote Buddy on the Mac spoils you for effortless couch potato style navigation. MCE does allow the same application to control both live TV viewing and DVD playback, whereas I have to switch off between EyeTV and Front Row on the Mac, but that is comparatively easy with Remote Buddy.


Another HDHomerun nicety is that EyeTV can Picture In Picture both HDHomerun tuners (again on the same hardware Vista MCE can barely decode 1 stream), allowing me to watch 2 HD football games simultaneously, which will be my preferred mode going forward. I like to watch football live, so EyeTV wins over MythTV, whose live TV support is always a bit cumbersome, and the PinP feature seals the deal.


Anyway, my main point is to emphasize the value one gets from a networked device. Because the HDHomerun is accessible from any computer in my house, any computer capable of decrypting an HD stream can use it. In my case, I have 3 computers (my MacBook, a Mac Mini, and my Linux server) and 3 operating systems (Leopard, Vista, Linux), each with their own strengths, sharing this resource.

The Cover Flow Compulsion

Compulsion can be a silly thing. Ever since Cover Flow became ubiquitous on the Mac, I've been on a mission to stamp out generic covers. I spent 5 minutes last night looking for a MP3 track called Voyager "Motion" by someone named Sandra Collins which I'm not sure where it came from (did it come bundled with my Fischer Price iBook 6 years ago?), and which I have told iTunes never to play. That's just silly. But look at the pretty pictures swirl by....

Yes, Walt Mossberg, Cover Flow is addictive.

For tracks iTunes can't automagically find artwork for, Amazon is a gold mine of customer submitted artwork, at least for popular stuff; you can pick and choose your Beatle covers.

Then there's the DVD situation. MythTV wants your artwork in one folder where its database can keep track of it. Front Row 2.0 wants a preview.jpg file in the same folder with the VIDEO_TS. Vista Media Center Edition wants a folder.jpg in the same place.

My process was as follows. I copied the artwork from DVDpedia (which had downloaded them from Amazon), used Apple's Preview application to create a new file from the clipboard, and saved it as preview.jpg in every DVD folder on my server. Creating the folder.jpg file was a bit easier, as I wrote a script to make static links from the preview.jpg, the equivalent of typing
$ln -s preview.jpg folder.jpg
170 times. Try to let the computer do what computers do best. A lot of busy work, but look at the pretty pictures swirl by...

SVG on Webkit - Improving

I'm gratified to see WebKit's continuous improvements in its support for SVG. Recent builds fixed a bug, I and many others, reported involving non-support for superscripted and subscripted text. This might seem a minor thing, but SVG support means, for instance, that someday soon Chemistry students will be able to go to a structure on Wikipedia via their iPhone, Android phone, or iPod Touch and actually zoom in on any portion of it perfectly, without worry about pixelating some lame .png file, and without worrying about errors in rendering making the structure ambiguous.

XML based SVG might not be the hottest technology, but the need for an open standard, full featured, vectored image format is so great, it just keeps chugging along. And it's inclusion in the base technology of both the iPhone and the Google Android SDK means it will finally allow for the inclusion of resolution independent and small vectored files, where today monstrous bitmap files are used. I'm sure Google is eager for its use in web apps for such activities as creating charts and graphs.

Now if Apple would just turn it on for the iPhone.