Mac OS X Snow Leopard Discussion

[.Neo]

However in 2004 / 2005 Apple made the effort to shift QuickTime Player over to Cocoa, so why not iTunes as well?

[the evn show]

However in 2004 / 2005 Apple made the effort to shift QuickTime Player over to Cocoa, so why not iTunes as well?

I'm not sure what your point is here (and I'll extend my charity wager offer to you as well). Are you arguing that 5-years after we start seeing the first steps towards a full 64-bit Cocoa iTunes we'll finally see it?

[.Neo]

(and I'll extend my charity wager offer to you as well)

Come again? As far as I'm concerned I'm not participating in a right/wrong competition here, just trying to make a normal conversation.

I'm not sure what your point is here. Are you arguing that 5-years after we start seeing the first steps towards a full 64-bit Cocoa iTunes we'll finally see it?

My point is that if QuickTime Player made it to Cocoa, it's not crazy to think iTunes might make it there as well. Especially since they more or less closed the door on a Carbon future with Snow Leopard (64-bit wise that is).

[Phantom Helix]

What does one really gain by having a 64-bit version of Address Book?

Not a damn thing really, especially when you keep in mind that they ship a 32-bit version in 10.6.

They also didn't lose anything because Address book has none of the computability requirements that iTunes does, nor did it has a sizeable Carbon dependency.

They do ??? looks like only only 4 are not 64bit in 10a402a (excluding SnapNdrag), yes there are others like some USB components but in the screen ive got everything i can click to run/open

Address book is in the second screen and it is 64bit

and yes i left iTunes out because we already know its only 32

Edited July 12, 2009 by Phantom Helix

[the evn show]

They do ??? looks like only only 4 are not 64bit in 10a402a (excluding SnapNdrag), yes there are others like some USB components but in the screen ive got everything i can click to run/open

Address book is in the second screen and it is 64bit

Every application in Mac OS X 10.6 ships with 32 bit binaries. Most ship with 64-bit versions as well.

For example: Address Book.

(me@debugtwo: ~)$ lipo -detailed_info /Applications/Address\ Book.app/Contents/MacOS/Address\ Book 
Fat header in: /Applications/Address Book.app/Contents/MacOS/Address Book
fat_magic 0xcafebabe
nfat_arch 2
architecture x86_64
	cputype CPU_TYPE_X86_64
	cpusubtype CPU_SUBTYPE_X86_64_ALL
	offset 4096
	size 175168
	align 2^12 (4096)
architecture i386
	cputype CPU_TYPE_I386
	cpusubtype CPU_SUBTYPE_I386_ALL
	offset 180224
	size 138608
	align 2^12 (4096)

You misread what Activity Monitor was telling—what kind of programs are running on your system, not what kind of programs are installed on it—and came to the wrong conclusion.

EDIT:

For the purpose of completeness - Mac OS X 10.6 still contains some PowerPC 32-bit executables too, including the Ruby, PERL, PHP, and Python environments.

Edited July 12, 2009 by evn.

[.Neo]

Mac OS X Snow Leopard includes 32-bit binaries as well. Early Intel Macs came with a Core Duo / Core Solo CPU which lacks 64-bit support.

Edit +evn. beat me to it.

[Phantom Helix]

I never intended to say that SL does NOT include 32bit.

[the evn show]

I never intended to say that SL does NOT include 32bit.

What does one really gain by having a 64-bit version of Address Book?

Not a damn thing really, especially when you keep in mind that they ship a 32-bit version in 10.6.

They do ??? looks like only only 4 are not 64bit…Address book is in the second screen and it is 64bit

Emphasis yours.

What did you intend to say?

[Phantom Helix]

I guess I misread the point of a couple of your posts after I re-read them. your "Not a damn thing really, especially when you keep in mind that they ship a 32-bit version in 10.6." comment made it sound as if address book was 32 only.

anyway I still don't understand why iTunes among everything that is included in OS X would be singled out to stay 32 only,

currently there is a version of safari for tiger and another for leopard, by the time SL is released and support for tiger is dropped why could there not be a version of iTunes for Leopard and another for SL?

what Makes iTunes so different than any other app that it alone would need such special consideration to be excluded from 64 when nearly everything else already has it added ?

You have said a couple times compatibility what is gain if 64 was included, well i ask that for all the other apps, why so many in SL have it included if the gains are marginal ?

[the evn show]

what Makes iTunes so different than any other app that it alone would need such special consideration to be excluded from 64 when nearly everything else already has it added ?

iTunes is both 32-bit and Carbon (well, mostly carbon: it uses AudioToolbox and Carbon.framework). The effort to move from 32 to 64-bit is closer to trivial when you're already Cocoa. You wouldn't want to ship a production version in a day, but you could probably get things to compile and run in short order. For trivial applications like Address Book they probably didn't need to do anything to make it run and could focus on adding features like Exchange integration.

Moving from Carbon to Cocoa is a significant effort and involves rewriting core portions of the application.

Apple will likely take the same approach with iTunes that they have with Safari and Adobe is planning for Photoshop CS5: A C++ "guts" (which can use anything it wants: Cocoa, Carbon: who cares) with a thin layer of Cocoa at the edges which gets mated to the UI.

So long as Apple wants to share code between the Mac and Windows version there are some compromises they're going to have to make. I think Apple's plans for QuickTime on Windows will tell us more.

You have said a couple times compatibility what is gain if 64 was included, well i ask that for all the other apps, why so many in SL have it included if the gains are marginal ?

Gain isn't just "is it better", but "is it better and at what cost and how much risk is there?"

Relative to porting iTunes from Carbon to Cocoa and also ensuring it was clean, updating address book was both low risk and low effort. iTunes also operates on a separate release cycle from the OS so there's no pressing deadline. Lastly, there's the possibility that iTunes is hindered by the same thing that holds back DVD Player, and I'm guessing here, licensed 3rd party code that is essential to the application hasn't been updated.

So unlike many bundled applications: iTunes is highly visible, essential to other businesses (including iPhone developers and record labels), has a lot of cruft to shake off, has unique cross platform and backward compatibility requirements, and stands to gain very little from an update to 64-bit Cocoa. With so much going on it makes sense to let iTunes coast along for a while and update it once 10.6 has settled.

[The_Decryptor Veteran]

The only performance increase you'd get from going 64bit is the encoding and decoding, and they should already be located in outside frameworks (which can be made 64bit without bothering the main app)

Going 64bit won't do a damn thing to scrolling speed or UI redrawing speed.

[Vice]

I'm curious about the 64-bit implementation in Snow Leopard. Will applications that include both 32-bit/64-bit automatically open as 64-bit if it detects a 64-bit compatible processor or is Apple limiting it to Mac Pros for example ?

The reason I ask is we all know how Apple likes to impose artificial limits for the sake of getting some extra $$$ out of consumers. So will my MacBook Pro auto open 64-bit versions?

[the evn show]

I'm curious about the 64-bit implementation in Snow Leopard. Will applications that include both 32-bit/64-bit automatically open as 64-bit if it detects a 64-bit compatible processor or is Apple limiting it to Mac Pros for example ?

It scans the binary and chooses the best one for your platform.

64-bit Intel Mac? You get the x64 binary.

32-bit Intel Mac? You get the 32-bit binary.

Have a PowerPC application that was never updated for Intel? It fires up Rosetta and runs it that way.

Mac OS has worked this way for nearly 2 decades now. In the "olden' days" you'd get versions optmized for PowerPC G3s, G4s (altivec) and G5s (64-bit).

Before that it would load M68k or PowerPC binaries depending on what you had in your system.

In theory you could cram optimized binaries for a dozen architectures into an application but it'd be unusual to do so, 4 seems like a realistic upper bound: PowerPC, PowerPC w/altivec, i386, x64. I can't think of any application that has that many, but I wouldn't be surprised to learn they exist. On 10.6 the highest number I found was 3: powerpc, i386, and x64.

[PyX]

What does one really gain by having a 64-bit version of Address Book?

One gains by having no emulation.

Suppose that your system is entirely 64-bit. You'd have to emulate Address Book just because it is in 32-bit format? No, it's better if it runs natively, aka in 64-bit.

Also maybe a couple of things speed up a little, I'm not really aware of what 64-bit does and doesn't do, and I won't invent stuff like most people do, but that's it. No emulation required.

[the evn show]

One gains by having no emulation.

Suppose that your system is entirely 64-bit. You'd have to emulate Address Book just because it is in 32-bit format? No, it's better if it runs natively, aka in 64-bit.

There isn't any emulation going on when you run 32-bit Intel code on a 64-bit Intel processor, nor is there an equivalent to the "WoW" layer on Windows.

[giga Veteran]

One gains by having no emulation.

Suppose that your system is entirely 64-bit. You'd have to emulate Address Book just because it is in 32-bit format? No, it's better if it runs natively, aka in 64-bit.

Also maybe a couple of things speed up a little, I'm not really aware of what 64-bit does and doesn't do, and I won't invent stuff like most people do, but that's it. No emulation required.

No emulation is required on x86_64 systems. 32-bit applications can run with native speed.

On the topic of 64=bit: http://developer.apple.com/documentation/D...inkElementID_21

Edited July 13, 2009 by giga

[PyX]

No emulation is required on x86_64 systems. 32-bit applications can run with native speed.

On the topic of 64=bit: http://developer.apple.com/documentation/D...inkElementID_21

Wow... it's even better than I thought then o_O

I didn't know 32-bit was a subset of 64-bit to quote them! I don't understand why I had so much trouble running Windows XP 64-bit a year after it was released. Drivers would cause a mess, a couple of apps weren't working at all, etc. It seemed like they were 2 opposite worlds... This is what my experience told me, and it was a misconception.

But I don't know then... why would you have Address Book in 64-bit rather than in 32-bit? Is there any other reason than "just because they want everything 64-bit"? I'd agree with that reason by intuition, but it's a poor one... !!!

[mattrobs]

Has the horribly long-standing bug, where Front Row doesn't display album art for shared libraries, been fixed in 10.6?

[the evn show]

But I don't know then... why would you have Address Book in 64-bit rather than in 32-bit? Is there any other reason than "just because they want everything 64-bit"? I'd agree with that reason by intuition, but it's a poor one... !!!

Not really. It's one of those "no harm, no gain, why not" things. If it doesn't take any extra resources to move the trivial Cocoa apps to 64-bit versions then why not? At the very least it's another bullet point for the feature list.

I suppose 5 years down the road (or whenever) they'll drop support for 32-bit systems and so if they convert everything they can now then they'll have had that much more time for testing and debugging on the 64-bit version.

I didn't know 32-bit was a subset of 64-bit to quote them!

That part only applies to PowerPC systems. On a PowerPC system (G5, Power4, etc) there's no gain or loss simply from compiling 64-bit vs 32-bit for code that would otherwise be 32-bit. You don't gain access to registers, there's no "faster" version of operations for moving data or multiplying small numbers that get used: it's all the same.

On Intel systems x64 fixes some of the register starvation problems and there are some extra functions that can be used so your compiler might be able to optimize things to run quicker.

The down side for both platforms is that you chew up more of the cache with things like storing the address of instructions or variables (what used to take 4bytes is now 8bytes). Pulling data from outside of cache is substantially slower than a cache hit so the extra strain on your cache may cause things to run more slowly.

On a PowerPC system (where all other things are equal) there's a chance that 64-bit code runs more slowly and in the best case it will run at the same speed.

On an x64 system the performance gains from having access to extra resources should cancel out penalties incurred from using more cache. Sometimes your code ends up slightly faster, sometimes it ends up slightly slower. For the sort of applications we're talking about there is no difference because they spend 99.9% of their time idle anyway.

Edited July 14, 2009 by evn.

[giga Veteran]

10A411 on SU.

First impressions from users on MR..

Larger, less bold fonts in the new Dock menus:

Quicktime 10 hover controls have changed:

[AltecXP]

Will 10.6 be available for pre-order soon?

[Phantom Helix]

10A411 on SU.

Larger, less bold fonts in the new Dock menus:

Quicktime 10 hover controls have changed:

That Quicktime Controls is damn sexy.

There sure seem to be a lot of UI changes for a OS upgrade that was supposed to be "under the hood" loll

seems like the automatically corrected spelling is working better in Safari 4.0.3 as-well.

And I don't think Apple does pre-orders for OS X do they?

Well there is only 2-1/2 months left anyway, if you sign up for the "notify me" on the SL page im sure you will know right when it is available

Edited July 15, 2009 by Phantom Helix

[AltecXP]

They did for 10.5 i remember people at work got it in the mail on release day.

[Xero]

Quicktime 10 hover controls have changed:

Good lord those controls are sexy. Here's hoping they fix the titlebar so its not 23 pixels :x

[Phantom Helix]

Dragging from stacks to Dock works correctly now

Also the "Blur" is now in the dock lists and the shade matches that of the grid-view

Edited July 15, 2009 by Phantom Helix