For your information Leopard just run fine with my Quad Core G5 without a single halt until now. Since it is only 2 years old I do expect it support the newest OS.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Seeds Snow Leopard 10A190 (Mac OX 10.6) to Developers
- Thread starter MacRumors
- Start date
- Sort by reaction score
For your information Leopard just run fine with my Quad Core G5 without a single halt until now. Since it is only 2 years old I do expect it support the newest OS.
It may be that 32 bit support is a variant of 10.5.9, but it will be there. 10.6 is next gen stuff.
I hope Apple has a handle on this, because they have been known to deliver buggy and crippled products quite often, bleeding edge, and insanely great aside.
There is a reason why it is "insanely" great, and "bleeding" edge.
Rocketman
While that's true, I guarantee you that WOW incurs a similarly high overhead.
Thing is, 32->64-bit is an inherently difficult transition.
There are basically three schools of thought as to how to handle this:
1) 32-bit kernel, mixed 32/64-bit userland (Leopard)
Pros: Apps gain the benefits of 64-bit addressing. Excellent backwards compatibility (flawless, if done correctly). Excellent driver support. Allows 32/64 bit apps to run side-by-side.
Cons: Performance penalty (minimal, if done correctly -- but could be quite bad.) Doesn't solve the problem of 64-bit drivers -- just delays the need for it. (Then again, how many drivers actually need 64-bit addressing?) Harder to implement.
2) 64-bit kernel, both 32 and 64-bit userlands (32-bit chroot environment on 64-bit Linux boxes, for example)
Pros: Allows for "pure" 64-bit userland. Isolates "old code" from "new code." 64-bit kernel.
Cons: Isolates "old code" from "new code". 64-bit kernel (thus the chicken/egg driver problem.) More complex setup than other solutions. Less-than-perfect backwards compatibility (although still excellent.) Requires more disk space.
3) 64-bit kernel, 64-bit userland with 32-bit userland emulated (WOW64)
Pros: Near-perfect backwards compatibility (if done correctly.) 64-bit kernel. Often more transparent than #2.
Cons: Hack. Translation incurs a potentially significant performance overhead. More complex codebase. Processor-specific. Did I mention it's a hack?
There's no one "correct" way to do this. Each of the three solutions has its advantages, and each has its disadvantages.
Mac OS X is a fairly fast-moving OS to deal with. Yes, code is stable, but Apple doesn't have the religious dedication to backwards compatibility "at all costs" that MS does -- when something sucks, or is broken, Apple rips it out and replaces it. This means that old code doesn't tend to stick around for long unless it's well-written. This also means that it's easier make transitions (as it doesn't take as long for poorly-written code to be phased out.) For Apple, the 32-bit kernel and mixed userland is a good choice. Performance is acceptable (esp. since Leopard improved the kernel's high-load and SMP performance), and new apps can be written to take advantage of 64-bit addressing. The transition is a fairly gentle one, and all that's really needed is to wait for driver makers to start writing 64-bit drivers.
Windows is a slow-moving OS. Microsoft has a damn-near religious obsession with backwards compatibility. If something is broken, they'll go to extreme lengths to allow for the continued functioning apps that depend on the broken behavior (for examples, see the 16->32 bit transition, and the bizarre "virtual registry" scheme of Vista). This wins them some customers, but it also means that major transitions are a royal bitch. They had to make a sudden change, but still support old apps -- thus the only solution was the emulation/translation hack that is WOW64. This allowed them to move the OS to 64-bit in one go while still allowing old unmaintained apps to run unmodified -- but it did so at a cost (performance and a serious increase in complexity). They also can't abandon the broken parts of the API; in fact, they need to do even more work to support them (as they must now maintain said broken functionality in both Win32 _and_ WOW64.) This is going to make their life a bit more 'interesting' down the road, but is probably their best bet, given the circumstances.
Most of the software for Linux is open source, and a lot of it is actively maintained. Transitions of this nature are easy -- app developers just "tweak and recompile" (to use a familiar WWDC-esque) expression. The stuff that's not already 64-bit clean (or can't easily be made 64-bit clean) can be run in a 32-bit chrooted environment. There's not too much of this stuff barring a couple pieces of closed source software (ahem... Flash), so this is a workable solution. It's easy, doesn't require a lot of dirty hacks, and is a good interim solution until old code and closed source apps are either updated or replaced.
Each OS does things its own way for different reasons. The 32 -> 64 bit transition is a royal pain in the ass, and there's no perfect way to do it. Claiming that one OS does it in a better way than another, although possibly true from a technical perspective, requires that you overlook some 20-odd years of technical and business decisions.
Whats wrong with them offering both 32 and 64-bit kernels? There is no "gross hack". The SL build says that only specific models will boot into 64-bit by default and the others won't because of driver issues. So that says very clearly that SL will boot into a 64-bit native kernel on all machines that are 64-bit. And my *guess* is that on all 32-bit machines it will boot into a 32-bit kernel. I don't see any hacks here.
Has PPC support in 10.6 been confirmed? Granted I don't think the drop of PPC support has been made official either, but it seems very likely. With a mid-2009 release timeframe, that would be precisely 3 years since the Mac Pro was released and the last PPC model was replaced. 3 years seems to be the expected useful life of a computer and is also when AppleCare for those PPC users that bought it should end.
I am going to take a middle of the road approach and say the mostly outcome is that the PPC kernel will be dropped, an x64 Intel kernel will be added and the x86 Intel kernel will remain. The 32-bit kernel is needed to keep support for 32-bit Core Duo iMac, MacBook, MacBook Pro, and Mac Mini users which aren't a small number. Plus, the 32-bit kernel will be needed because not everyone will want to switch to a 64-bit kernel since they may have peripherals that don't have 64-bit drivers and will break. 32-bit programs that interface with the kernel might also have trouble now if the kernel were 64-bit.
And the I think term 64-bit clean is kind of misleading for Snow Leopard. While Snow Leopard will have a 64-bit kernel, the included applications and libraries will all remain 32-bit and 64-bit Intel Universal Binaries for compatibility and speed reasons. The common problem being if only 64-bit versions of programs were offered it would break a whole bunch of plug-ins. Safari for instance wouldn't have many plug-ins in 64-bit mode, like Flash. Even if Apple denies Flash's existence on the iPhone, I can't see them getting away with it on a computer. There are also some Java programs that have issues with Apple's 64-bit Java 1.5 and Java 6 VMs. And even XCode 3 in Leopard defaults to 32-bit mode even though it's a 64-bit UB because in 64-bit mode it has to load the large 64-bit libraries in addition to the 32-bit libraries to compile Universal Binaries which slow things down. Carbon will likewise still exist even though it's 32-bit, since even if Apple manages to port all their own Applications over to 64-bit Cocoa, I can't see them expecting to sell an operating system that doesn't support Adobe CS4 that was just released this month or Office 2008. Simiarly Rosetta will still remain, if only to support Office 2004 for VBA users. Afterall, if Apple wants to get Snow Leopard into corporations with Exchange Support, they're going to need to keep VBA support and Office support as well.
I actually wouldn't mind running Windows 2008 x64, but I've heard about driver hiccups, lack of driver support, mandatory driver signing...and literally all of my applications are 32bit, so I doubt that there would be any advantage whatsoever.
And on the Mac side, I'm also not in a huge hurry to have everything pure 64bit. I have 4GB of RAM and unlike Windows NT6, Leopard seems to be able to use all 4GB of it, despite being a 32bit OS (that is, having a 32bit kernel). The only "downside" to 32bit Windows is that only 3GB of physical RAM is used--the top 1GB is reserved for shadowing VRAM and other things.
So right now, it seems like 64bit-ness is a moot point for me (and the majority of computer users out there, unless you need big iron).
And on the Mac side, I'm also not in a huge hurry to have everything pure 64bit. I have 4GB of RAM and unlike Windows NT6, Leopard seems to be able to use all 4GB of it, despite being a 32bit OS (that is, having a 32bit kernel). The only "downside" to 32bit Windows is that only 3GB of physical RAM is used--the top 1GB is reserved for shadowing VRAM and other things.
So right now, it seems like 64bit-ness is a moot point for me (and the majority of computer users out there, unless you need big iron).
While that's true, I guarantee you that WOW incurs a similarly high overhead.
Thing is, 32->64-bit is an inherently difficult transition.
There are basically three schools of thought as to how to handle this:
1) 32-bit kernel, mixed 32/64-bit userland (Leopard)
Pros: Apps gain the benefits of 64-bit addressing. Excellent backwards compatibility (flawless, if done correctly). Excellent driver support. Allows 32/64 bit apps to run side-by-side.
Cons: Performance penalty (minimal, if done correctly -- but could be quite bad.) Doesn't solve the problem of 64-bit drivers -- just delays the need for it. (Then again, how many drivers actually need 64-bit addressing?) Harder to implement.
2) 64-bit kernel, both 32 and 64-bit userlands (32-bit chroot environment on 64-bit Linux boxes, for example)
Pros: Allows for "pure" 64-bit userland. Isolates "old code" from "new code." 64-bit kernel.
Cons: Isolates "old code" from "new code". 64-bit kernel (thus the chicken/egg driver problem.) More complex setup than other solutions. Less-than-perfect backwards compatibility (although still excellent.) Requires more disk space.
3) 64-bit kernel, 64-bit userland with 32-bit userland emulated (WOW64)
Pros: Near-perfect backwards compatibility (if done correctly.) 64-bit kernel. Often more transparent than #2.
Cons: Hack. Translation incurs a potentially significant performance overhead. More complex codebase. Processor-specific. Did I mention it's a hack?
There's no one "correct" way to do this. Each of the three solutions has its advantages, and each has its disadvantages.
Mac OS X is a fairly fast-moving OS to deal with. Yes, code is stable, but Apple doesn't have the religious dedication to backwards compatibility "at all costs" that MS does -- when something sucks, or is broken, Apple rips it out and replaces it. This means that old code doesn't tend to stick around for long unless it's well-written. This also means that it's easier make transitions (as it doesn't take as long for poorly-written code to be phased out.) For Apple, the 32-bit kernel and mixed userland is a good choice. Performance is acceptable (esp. since Leopard improved the kernel's high-load and SMP performance), and new apps can be written to take advantage of 64-bit addressing. The transition is a fairly gentle one, and all that's really needed is to wait for driver makers to start writing 64-bit drivers.
Windows is a slow-moving OS. Microsoft has a damn-near religious obsession with backwards compatibility. If something is broken, they'll go to extreme lengths to allow for the continued functioning apps that depend on the broken behavior (for examples, see the 16->32 bit transition, and the bizarre "virtual registry" scheme of Vista). This wins them some customers, but it also means that major transitions are a royal bitch. They had to make a sudden change, but still support old apps -- thus the only solution was the emulation/translation hack that is WOW64. This allowed them to move the OS to 64-bit in one go while still allowing old unmaintained apps to run unmodified -- but it did so at a cost (performance and a serious increase in complexity). They also can't abandon the broken parts of the API; in fact, they need to do even more work to support them (as they must now maintain said broken functionality in both Win32 _and_ WOW64.) This is going to make their life a bit more 'interesting' down the road, but is probably their best bet, given the circumstances.
Most of the software for Linux is open source, and a lot of it is actively maintained. Transitions of this nature are easy -- app developers just "tweak and recompile" (to use a familiar WWDC-esque) expression. The stuff that's not already 64-bit clean (or can't easily be made 64-bit clean) can be run in a 32-bit chrooted environment. There's not too much of this stuff barring a couple pieces of closed source software (ahem... Flash), so this is a workable solution. It's easy, doesn't require a lot of dirty hacks, and is a good interim solution until old code and closed source apps are either updated or replaced.
Each OS does things its own way for different reasons. The 32 -> 64 bit transition is a royal pain in the ass, and there's no perfect way to do it. Claiming that one OS does it in a better way than another, although possibly true from a technical perspective, requires that you overlook some 20-odd years of technical and business decisions.
Very well said. I'm no computer expert, but these paragraphs definitely cleared up the 32-64 bit transfer mess for the three major OS's. Thanks for the great clarification.
Though I didn't bother reading 11 pages of posts, and I bet many people have said this so that it's pretty cliched at this point, but:
Snow Leopard is looking better every time I hear about it.
And Apple in theory has an easy enough solution for Flash (note that safari is currently 32-bit only to deal with plugins) : "Adobe, fix it for snow leopard or you aren't on the DVD"
Losing 1/2 of my RAM (6GB) is a big deal. Thus my unwillingness to run 32-bit Windows.
On a MBP, I have had literally no problems with 64-bit Windows Vista (except for the occasional broken app, for which there has always been an easy 64-bit-friendly replacement).
But, on the other side of the same coin, I can't really see what I'm losing from the current 32-bit kernel/64-bit userland state of Leopard. It recognizes and uses all my RAM, and I don't run the kind of applications (which tend to be server applications) that really suffer in performance from Leopard's architecture.
Any driver that does DMA either needs to support 64-bit addressing in some fashion, or the data needs to be copied from 32-bit driverland to the correct place in 64-bit userland.
3) 64-bit kernel, 64-bit userland with 32-bit userland emulated (WOW64)
Pros: Near-perfect backwards compatibility (if done correctly.) 64-bit kernel. Often more transparent than #2.
Cons: Hack. Translation incurs a potentially significant performance overhead. More complex codebase. Processor-specific. Did I mention it's a hack?
It's also not quite true.
WOW64 uses a native 32-bit userland, like your #2.
Almost all 32-bit DLLs are unmodified copies of 32-bit Windows binaries.
http://msdn.microsoft.com/en-us/library/aa384274.aspx
http://msdn.microsoft.com/en-us/library/aa384274.aspx
No emulation is required for WOW64 on x64.
http://en.wikipedia.org/wiki/WOW64
http://en.wikipedia.org/wiki/WOW64
WOW64 maps between the 32-bit userland and the 64-bit system calls.
The x64 implementation simply thunks 32-bit to 64-bit - it translates a 32-bit system call into the equivalent 64-bit call, and executes both in native mode, switching between 32-bit and 64-bit mode as needed. Little or no instruction set emulation is done. See that Microsoft link for more information.
You're completely right -- I said "emulation", even though that's not quite true, as I figured more people would be able to grok what I was saying. WOW64 is more akin to WINE than it is to MAME -- but if I said "WOW64 is an application compatibility layer that provides translation between 32-bit and 64-bit system calls", I figured fewer people would understand me
Right, those drivers need to be 64-bit clean if they're being used in a 64-bit kernel, but in a hybrid system like Leopard they don't need to be. I guess I didn't express myself well enough: few drivers actually require the larger address space -- usually they just need to be 64-bit because the rest of the OS is.
Obsolescence
I have a Quad G5 at home and it cost me £3,000 (about $4,500-$5,000). It was bought in March 2006. It was the best Mac I could buy at the time, and knowing I was intending it to run for up to 5 years before being replaced, and spent an incredible amount of cash on it.
It runs Tiger very nicely. I have noticed the odd application is Leopard-only, and I've had the machine for 2.5 years. That's the only problem I've seen. I intend to do a big upgrade cycle on it, as I think it's useful life will be AT LEAST another 2 years. I can add Leopard, a nice 30" Cinema Display, shove 1Tb hard disks inside, get the swanky new Apple keyboard and a Wacom Intuos3 tablet. I only have 6Gb RAM, and that can be upgraded to 16Gb for £200.
In every studio I've worked in, we skip every other version of Creative Suite. This works nicely because not everybody buys every version. The point where an upgrade is a necessity is when I receive a file from a client in a version of CS that I can't read, and they're unable to save it down to my version. So I can go get the PPC CS4 right now, and when CS5 comes out, that's not a problem. The impetus to upgrade will be CS6. If Adobe continue releasing at 18-month intervals, that gives me nearly three years till that unreadable file arrives from a client.
So that means that my G5 will no longer be useable as a workhorse machine between 5 and 6 years after it was purchased. I have no real problem with that. Money well spent.
People have a bee in their bonnet because Apple likes to hype things up: every machine they 'launch' but you can't buy for 6 weeks; announcing the new, best ever version of OS X 12 months before it's out. If they were going to flip a kill switch on all the PPC Macs in June '09, maybe I'd be pissed off. But they're not.
We still get updates to Tiger, and it's been around for about four years. We'll keep getting them for Leopard for a while, too. Your PPC is NOT going to grind to a halt. Lob some RAM in there, get a nice new monitor, whatever, and it'll still be a fast, professional workstation.
I have a Quad G5 at home and it cost me £3,000 (about $4,500-$5,000). It was bought in March 2006. It was the best Mac I could buy at the time, and knowing I was intending it to run for up to 5 years before being replaced, and spent an incredible amount of cash on it.
It runs Tiger very nicely. I have noticed the odd application is Leopard-only, and I've had the machine for 2.5 years. That's the only problem I've seen. I intend to do a big upgrade cycle on it, as I think it's useful life will be AT LEAST another 2 years. I can add Leopard, a nice 30" Cinema Display, shove 1Tb hard disks inside, get the swanky new Apple keyboard and a Wacom Intuos3 tablet. I only have 6Gb RAM, and that can be upgraded to 16Gb for £200.
In every studio I've worked in, we skip every other version of Creative Suite. This works nicely because not everybody buys every version. The point where an upgrade is a necessity is when I receive a file from a client in a version of CS that I can't read, and they're unable to save it down to my version. So I can go get the PPC CS4 right now, and when CS5 comes out, that's not a problem. The impetus to upgrade will be CS6. If Adobe continue releasing at 18-month intervals, that gives me nearly three years till that unreadable file arrives from a client.
So that means that my G5 will no longer be useable as a workhorse machine between 5 and 6 years after it was purchased. I have no real problem with that. Money well spent.
People have a bee in their bonnet because Apple likes to hype things up: every machine they 'launch' but you can't buy for 6 weeks; announcing the new, best ever version of OS X 12 months before it's out. If they were going to flip a kill switch on all the PPC Macs in June '09, maybe I'd be pissed off. But they're not.
We still get updates to Tiger, and it's been around for about four years. We'll keep getting them for Leopard for a while, too. Your PPC is NOT going to grind to a halt. Lob some RAM in there, get a nice new monitor, whatever, and it'll still be a fast, professional workstation.
You're completely right -- I said "emulation", even though that's not quite true, as I figured more people would be able to grok what I was saying. WOW64 is more akin to WINE than it is to MAME -- but if I said "WOW64 is an application compatibility layer that provides translation between 32-bit and 64-bit system calls", I figured fewer people would understand me
But the point isn't that you used a particular word - it's that WOW64 is very much your case #2, not case #3.
Note that OSX has "stubs" to map 64-bit application calls to the 32-bit kernel - similiar to WOW64 but in reverse.
I would espouse the opinion that DMA drivers "require" 64-bit, since the performance hit from doing a copy can be huge.
Not so. I've purchased three new Macs in the past three years (a Mac Pro and two MacBook Pros) but I still have two PPC machines in use. I'm sure there are plenty of other families and businesses in the same position -- nobody replaces every machine at once.
Fair enough, but the point I was making was that those old machines aren't Apple's problem any more. You bought them years ago and presumably got your money's worth.
I have a QuadG5 that probably won't run SL. This doesn't bother me because I didn't buy the QuadG5 to run SL. I bought it to run Tiger. That it also runs Leopard is already a bonus over what I paid for.
4+2. I know it works fine in Penryn/SR MBPs and I think it should work OK in Merom/SR MBPs as the chipset is the same. Some users say the 4GB module needs to be in the outside slot. I just installed mine there without trying it the other way and it works great.
8GB doesn't work in the SR MBPs; if you exceed 4GB of memory usage with 8GB installed the machine slows nearly to a halt.
There was another thread where iFixit confirmed that 8GB doesn't work but 5GB does work in the unibody MBPs. I'm still waiting for someone to confirm that 6GB works in those machines.