3 ms·

For those who are wondering (it's the first thing I checked): It's still not 64 bits.

pyre 17y ago
As someone mentioned elsewhere (Gruber I think), it uses the older Carbon API which is being left in the 32-bit world. They'll have to upgrade it to Cocoa to make it a 64-bit app, but Cocoa isn't ported to Windows... So they have limited options: * Port Cocoa to Windows and port iTunes to Cococa * (Gruber's prediction) Port iTunes to be entirely based on Webkit (though I don't know how well that would work as I've never looked into Webkit performance/issues on Windows) * Port Mac iTunes to Cocoa maintain Windows iTunes in Carbon * Drop Windows iTunes (not going to happen) * Port iTunes to iPhone/iPod Touch and drop it on OS X (yea right) * Port Carbon to 64-bit -- even though it has been stated that they won't in a push to force developers onto Cocoa. None of those are particularly attractive decisions. Going back on their word and porting Carbon to 64-bit or porting iTunes to be entirely a Webkit view seem to be the only options with the least friction, IMO. I think that porting Cocoa to Windows would probably be a larger undertaking than it would be worth it, though they may have some portions of Cocoa ported already (IIRC, Safari is Cocoa, but they maybe have only ported what they needed to make Safari work).
- ComputerGuru 17y ago
  I think the third option (cocoa on OS X, carbon on Windows) is the most likely.
  - pyre 17y ago
    Would they really want to split development like that? Cocoa and Carbon are completely different (C vs ObjC) APIs to Aqua/Quartz/etc.
- wvenable 17y ago
  "Port Cocoa to Windows and port iTunes to Cococa" OpenStep was already ported Windows NT at one time ( http://en.wikipedia.org/wiki/File:OPENSTEP_on_Windows_NT.jpg http://en.wikipedia.org/wiki/File:OPENSTEP_on_Windows_NT.jpg ). They already port other libraries to Windows to support iTunes and Safari. I think this option makes the most sense moving forward if they want to continue building cross-platform applications.
  - pyre 17y ago
    Arguably iTunes is on Windows to support Windows users of iPhones/iPods (to expand their 'device market' beyond just the Mac ecosystem). Safari.... not really sure why Safari is there other than to try and support Windows developers of iPhone-targeted web-apps (before there was an official iPhone API). But that conclusion is questionable seeing how there are no Windows development tools for iPhone apps now that there is an official API. > They already port other libraries to Windows to support iTunes and Safari. iTunes doesn't use Cocoa/ObjC. It uses the Carbon/C (C++ too?) that was a way to transition between OS/9 and OSX back in the day (You could download the Carbon libraries for OS/9 and a Carbon app would run in OS/9 with them). Safari is Cocoa/ObjC so far as I know, but it's just a wrapper around Webkit for the most part. They could have ported the Windows version of Safari to Carbon, or just ported the parts of the Cocoa libraries that Safari needs (rather than the whole thing). So.... it looks something like this: Port X% of Cocoa to Win32 + Port iTunes to Cocoa Depending on that percentage and the amount of time it would take to port iTunes itself to Cocoa would determine how costly it is (time & money). I realize that you're also saying that porting however much of Cocoa over to Win32(+ Win64?) would help them develop more cross-platform apps, but I don't see this being part of their strategy. Unless you prescribe to the John C. Dvorák line of thinking that Apple is going to go cross-platform, make a way to seamlessly develope Windows/MacOS applications, and then eventually dump MacOS for Windows on Apple machines, I don't think that Apple will leave the galleon that they have for themselves (their product/developer ecosystem). They just use cross-platform apps as a means to an ends... extending gang planks to passing ships and beckoning their passengers to cross over to the Apple side (or at least buy their consumer-devices and get hooked onto those).
    - wvenable 17y ago
      From what I've looked into, Safari on Windows isn't using Cocoa. The latest Safari even looks much more like a Windows application than previous versions. So maybe I'm wrong about this point. However, I still think they're going to have to port iTunes to Cocoa simply because they've essentially deprecated Carbon. For the Windows version of iTunes, maybe they'll just have an completely separate version that isn't a port.
- makecheck 17y ago
  But supporting 64-bit Carbon for their own use isn't the same as supporting it for everyone else. For one thing, only a subset of the Carbon API is important to iTunes. And if it became necessary to fix things (or even break compatibility), they could, because the 64-bit frameworks would be private. And it's certainly possible to port to Cocoa incrementally. It is also possible to isolate Objective-C implementations behind pure C APIs, so that an abstraction doesn't have to know it's using Cocoa on Mac and something else on Windows.
  - pyre 17y ago
    Many of the Cocoa APIs are abstractions of C libraries like libxml, etc. But you still need to port everything that supports the Cocoa API wrapper around that C library, even if you don't have to port the C library itself.
- Perceval 17y ago
  Does anyone know what they've done with Safari? Safari 4 on Snow Leopard is 64-bit. Are they supporting 32-bit Safari on Windows and 64-bit Safari on OS X? This could give an indication of where they're likely to go with iTunes.
- blasdel 17y ago
  You left off an odd but plausible option: * Port iTunes to Webkit WebKit's native plugin system is fantastic for doing this kind of stuff -- it's expressly for embedding native code as elements that are fully interactive with the rest of the document (though it's awful for implementing the average FF extension). They could use WebKit as the majority of the GUI without having to ship very much inspectable JS.
  - pyre 17y ago
    > You left off an odd but plausible option: You missed my second bullet. > though it's awful for implementing the average FF extension I find that most Firefox extensions are more about modifying the user interface, and less about modifying the content of the page. (i.e. Pearl Crescent Saver, Tab Mix Plus, Download Them All!, Tiny Menu, etc) The big names cover most things you could want to do to the page outside of a Greasemonkey script (Ad Block Plus, NoScript, etc)
- jsz0 17y ago
  Another option: Just leave things the way they are. There's no huge need to make iTunes 64Bit or Cocoa. Most of the features Apple has added to iTunes in the last 3-4 years are just UI tweaks and some algorithms to make special types of playlists automatically. I don't think they're being constrained by Carbon or will be anytime soon. Being a native Cocoa app would probably improve some of iTunes performance issues but realistically those problems aren't that bad. I just don't see enough room for growth in iTunes to justify all the effort of porting Cocoa to Windows or iTunes to WebKit.
- pohl 17y ago
  It's plausible that they have been maintaining the Windows port of the Cocoa libraries all along. This port existed at the time of the Apple/NeXT acquisition. It was called "OpenStep/Enterprise"...but it was, basically, a Windows port of the same APIs that became Cocoa. http://en.wikipedia.org/wiki/File:OPENSTEP_on_Windows_NT.jpg http://en.wikipedia.org/wiki/File:OPENSTEP_on_Windows_NT.jpg Recall that when Apple still only sold PowerPC machines that MacOS X was "leading a secret double life" in the labs in the form of the same x86 port of NeXTstep that was brought forward in tandem with MacOS X as it progressed. They could be doing the same thing with Cocoa/Win.

pyre 17y ago

As someone mentioned elsewhere (Gruber I think), it uses the older Carbon API which is being left in the 32-bit world. They'll have to upgrade it to Cocoa to make it a 64-bit app, but Cocoa isn't ported to Windows... So they have limited options: * Port Cocoa to Windows and port iTunes to Cococa * (Gruber's prediction) Port iTunes to be entirely based on Webkit (though I don't know how well that would work as I've never looked into Webkit performance/issues on Windows) * Port Mac iTunes to Cocoa maintain Windows iTunes in Carbon * Drop Windows iTunes (not going to happen) * Port iTunes to iPhone/iPod Touch and drop it on OS X (yea right) * Port Carbon to 64-bit -- even though it has been stated that they won't in a push to force developers onto Cocoa. None of those are particularly attractive decisions. Going back on their word and porting Carbon to 64-bit or porting iTunes to be entirely a Webkit view seem to be the only options with the least friction, IMO. I think that porting Cocoa to Windows would probably be a larger undertaking than it would be worth it, though they may have some portions of Cocoa ported already (IIRC, Safari is Cocoa, but they maybe have only ported what they needed to make Safari work).

ComputerGuru 17y ago
I think the third option (cocoa on OS X, carbon on Windows) is the most likely.
- pyre 17y ago
  Would they really want to split development like that? Cocoa and Carbon are completely different (C vs ObjC) APIs to Aqua/Quartz/etc.
wvenable 17y ago
"Port Cocoa to Windows and port iTunes to Cococa" OpenStep was already ported Windows NT at one time ( http://en.wikipedia.org/wiki/File:OPENSTEP_on_Windows_NT.jpg http://en.wikipedia.org/wiki/File:OPENSTEP_on_Windows_NT.jpg ). They already port other libraries to Windows to support iTunes and Safari. I think this option makes the most sense moving forward if they want to continue building cross-platform applications.
- pyre 17y ago
  Arguably iTunes is on Windows to support Windows users of iPhones/iPods (to expand their 'device market' beyond just the Mac ecosystem). Safari.... not really sure why Safari is there other than to try and support Windows developers of iPhone-targeted web-apps (before there was an official iPhone API). But that conclusion is questionable seeing how there are no Windows development tools for iPhone apps now that there is an official API. > They already port other libraries to Windows to support iTunes and Safari. iTunes doesn't use Cocoa/ObjC. It uses the Carbon/C (C++ too?) that was a way to transition between OS/9 and OSX back in the day (You could download the Carbon libraries for OS/9 and a Carbon app would run in OS/9 with them). Safari is Cocoa/ObjC so far as I know, but it's just a wrapper around Webkit for the most part. They could have ported the Windows version of Safari to Carbon, or just ported the parts of the Cocoa libraries that Safari needs (rather than the whole thing). So.... it looks something like this: Port X% of Cocoa to Win32 + Port iTunes to Cocoa Depending on that percentage and the amount of time it would take to port iTunes itself to Cocoa would determine how costly it is (time & money). I realize that you're also saying that porting however much of Cocoa over to Win32(+ Win64?) would help them develop more cross-platform apps, but I don't see this being part of their strategy. Unless you prescribe to the John C. Dvorák line of thinking that Apple is going to go cross-platform, make a way to seamlessly develope Windows/MacOS applications, and then eventually dump MacOS for Windows on Apple machines, I don't think that Apple will leave the galleon that they have for themselves (their product/developer ecosystem). They just use cross-platform apps as a means to an ends... extending gang planks to passing ships and beckoning their passengers to cross over to the Apple side (or at least buy their consumer-devices and get hooked onto those).
  - wvenable 17y ago
    From what I've looked into, Safari on Windows isn't using Cocoa. The latest Safari even looks much more like a Windows application than previous versions. So maybe I'm wrong about this point. However, I still think they're going to have to port iTunes to Cocoa simply because they've essentially deprecated Carbon. For the Windows version of iTunes, maybe they'll just have an completely separate version that isn't a port.
makecheck 17y ago
But supporting 64-bit Carbon for their own use isn't the same as supporting it for everyone else. For one thing, only a subset of the Carbon API is important to iTunes. And if it became necessary to fix things (or even break compatibility), they could, because the 64-bit frameworks would be private. And it's certainly possible to port to Cocoa incrementally. It is also possible to isolate Objective-C implementations behind pure C APIs, so that an abstraction doesn't have to know it's using Cocoa on Mac and something else on Windows.
- pyre 17y ago
  Many of the Cocoa APIs are abstractions of C libraries like libxml, etc. But you still need to port everything that supports the Cocoa API wrapper around that C library, even if you don't have to port the C library itself.
Perceval 17y ago
Does anyone know what they've done with Safari? Safari 4 on Snow Leopard is 64-bit. Are they supporting 32-bit Safari on Windows and 64-bit Safari on OS X? This could give an indication of where they're likely to go with iTunes.
blasdel 17y ago
You left off an odd but plausible option: * Port iTunes to Webkit WebKit's native plugin system is fantastic for doing this kind of stuff -- it's expressly for embedding native code as elements that are fully interactive with the rest of the document (though it's awful for implementing the average FF extension). They could use WebKit as the majority of the GUI without having to ship very much inspectable JS.
- pyre 17y ago
  > You left off an odd but plausible option: You missed my second bullet. > though it's awful for implementing the average FF extension I find that most Firefox extensions are more about modifying the user interface, and less about modifying the content of the page. (i.e. Pearl Crescent Saver, Tab Mix Plus, Download Them All!, Tiny Menu, etc) The big names cover most things you could want to do to the page outside of a Greasemonkey script (Ad Block Plus, NoScript, etc)
jsz0 17y ago
Another option: Just leave things the way they are. There's no huge need to make iTunes 64Bit or Cocoa. Most of the features Apple has added to iTunes in the last 3-4 years are just UI tweaks and some algorithms to make special types of playlists automatically. I don't think they're being constrained by Carbon or will be anytime soon. Being a native Cocoa app would probably improve some of iTunes performance issues but realistically those problems aren't that bad. I just don't see enough room for growth in iTunes to justify all the effort of porting Cocoa to Windows or iTunes to WebKit.
pohl 17y ago
It's plausible that they have been maintaining the Windows port of the Cocoa libraries all along. This port existed at the time of the Apple/NeXT acquisition. It was called "OpenStep/Enterprise"...but it was, basically, a Windows port of the same APIs that became Cocoa. http://en.wikipedia.org/wiki/File:OPENSTEP_on_Windows_NT.jpg http://en.wikipedia.org/wiki/File:OPENSTEP_on_Windows_NT.jpg Recall that when Apple still only sold PowerPC machines that MacOS X was "leading a secret double life" in the labs in the form of the same x86 port of NeXTstep that was brought forward in tandem with MacOS X as it progressed. They could be doing the same thing with Cocoa/Win.