Prince McLean
Instead, it means that the early developer build of Snow Leopard does not yet supply 64-bit kernel extensions for some of the critical components of the MacBook and other consumer machines. When released to developers around spring and to end users a few months later, Snow Leopard will support using a 64-bit kernel on all Intel Macs with 64-bit CPU, such as the Core 2 Duo.
A 64-bit kernel requires all of its extensions to also be 64-bit. Kernel extensions or KEXTs include drivers for audio hardware, graphics adapters, networking, certain printing components, and other devices on the logic board or attached as peripherals. Until Apple delivers 64-bit versions of the nearly 300 extensions it ships with Mac OS X (not all of which will need to be supported on 64-bit Macs; many are legacy), it is limiting official 64-bit kernel support to a subset of Macs in prerelease builds of the new operating system.
The 32-bit kernel of Mac OS X
Snow Leopard will deliver the first 64-bit kernel for Mac OS X. Earlier versions of the operating system, including today's Leopard, can run 64-bit software but do so using a 32-bit kernel. More accurately, whether running on 32 and 64-bit CPUs, Mac OS X loads the same kernel image and run it as a 32-bit process, although when run on 64-bit hardware, the 32-bit kernel switches into "long mode compatibility mode."
Apple's current implementation allows the existing 32-bit kernel to run both 32-bit and 64-bit applications at once, as well as being able to handle 64-bit virtual memory allocations, giving 64-bit applications and background tasks the capacity to allocate memory spaces larger than 4GB when working with large data sets. In Tiger, 32-bit graphical apps could create a 64-bit process; under Leopard, Mac OS X can run full 64-bit graphical apps.
Leopard's 32-bit kernel has been fitted with enhancements that handle copying between 32 and 64-bit user address spaces, and its syscall and trap handlers are also 64-bit code. This hybrid design enabled Apple to deliver a kernel that could run 64-bit apps without needing to immediately deliver 64-bit kernel drivers for it, nor to require third parties to all ship 64-bit versions of their drivers.
As described in earlier coverage of Snow Leopard's 64-bit features, Mac OS X can also currently use various techniques to use more than 4GB of installed RAM, the limit imposed by 32-bit memory addressing, despite using a 32-bit kernel. Intel's hardware uses a method called PAE to enable certain Mac models to address as much as 32GB of installed RAM, despite Mac OS X's use of a 32-bit kernel.
The 64-bit kernel of Mac OS X Snow Leopard
Having a 64-bit kernel will enable Apple to move well beyond PAE to address very large amounts of installed RAM in Macs of the future as memory becomes more affordable. This is particularly useful for servers, but even consumer machines will someday need vast amounts of RAM.
Additionally, the new 64-bit kernel will gain the advantages that 64-bit Mac OS X apps already have: the ability to set up an address space for itself greater than 32-bits (4GB), as well as the ability to access the full x64 register set of 64-bit CPUs. This wasn't as compelling of a need on the 64-bit PowerPC G5, but 64-bit Intel CPUs like the Core 2 Duo provide more general purpose registers that are conspicuously absent on 32-bit Intel CPUs, leading to a significant performance advantage when moving to 64-bit software.
Along with these advantages comes the necessity of upgrading all of the kernel's drivers to 64-bit, including any provided by third parties. Again, that's because 64-bit programs can't load and run 32-bit plugins, and vice versa. That means Mac users will need to do the same driver upgrade that Windows Vista users did.
Fortunately, Apple took steps to plan for the transition. By exposing 64-bit development tools and concepts years in advance, Mac programmers have had time to build a more mature understanding of how things work. If Apple had attempted to simply deliver a 100% 64-bit OS in one fell swoop, it may never have come together. Apple would have run into many of the same catch-22 problems that have held 64-bit Windows from gaining mass adoption.
Additionally, Apple only needs to deliver a relatively small number of drivers: just those devices used in Macs supported by the Snow Leopard release. Since Apple designed and built all those machines, it won't have nearly as tough of a time as Microsoft had in prodding third parties to deliver good 64-bit versions of their drivers for all the hardware anyone has every put into any brand of PC sold within the last several years.
Mac OS X and Windows x64 software
Apple also developed a clean 'fat binary' method for delivering cross-platform binary code, including both 32-and 64-bit versions in a single app bundle, or binary package. On Windows, 32-bit and 64-bit code has to be installed separately. Supporting library files on 64-bit Windows have to be put into System32 (if they are 64-bit) or SysWOW64 (if they are 32-bit).
This apparent contradiction relates to the fact that Microsoft couldn't change the name of the Windows System32 directory (originally named to distinguish it from the 16-bit System directory) for compatibility reasons, and that SysWOW64 is the 64-bit process that runs 32-bit Windows apps in a compatibility mode on Windows x64, called WOW64 for 'Windows on 64-bit Windows.'
On Mac OS X Leopard and in Snow Leopard, Apple designed the kernel to run both 32 and 64-bit software natively with no compatibility layer running, and all supporting files and libraries can be organized in the same application bundle. That means developers can distribute a single installer that works on any Mac, and that users won't need to make sure they've obtained the correct binary for their machine. This promises to go a long way in making the transition to 64-bit Mac software very smooth and virtually invisible to most users.
AppleInsider's Road to Leopard Series
Malcolm Owen
Wesley Hilliard
AppleInsider Staff
Christine McKee
Andrew O'Hara
William Gallagher
47 Comments
I cant wait!
Nice diagram - shows the gradual approach Apple has taken. First the Unix layer, then the programming frameworks, and finally the kernel and drivers. It's good software development practice to do smaller releases and test them in the wild rather than do everything at once.
On Mac OS X Leopard and in Snow Leopard, Apple designed the kernel to run both 32 and 64-bit software natively with no compatibility layer running, and all supporting files and libraries can be organized in the same application bundle. That means developers can distribute a single installer that works on any Mac, and that users won't need to make sure they've obtained the correct binary for their machine. This promises to go a long way in making the transition to 64-bit Mac software very smooth and virtually invisible to most users.
Having only one installer that works for any Mac will make the transition so much easier. If you take an average consumer, they wouldn't know if they're running a 32-bit version, 64-bit version or whatever. So when they go to install an application, they have no clue what version to use.
None of this stuff will compel "consumers" to upgrade to Snow Leopard. If Apple is going to offer this as a paid upgrade, and not free, there'll have to be several major obvious "new things". Cocoa touch?
Having only one installer that works for any Mac will make the transition so much easier. If you take an average consumer, they wouldn't know if they're running a 32-bit version, 64-bit version or whatever. So when they go to install an application, they have no clue what version to use.
This is also part of the reason why Microsoft's 64 bit strategy, (which is actually ahead of Apple's in terms of most implementation details), is such a colossal failure.
The average user sees no reason to "switch" to 64 bit anything and will not jump through any hoops to do so. Having to install a completely separate version (64 bit) of Windows at a higher price, and then shop around for replacements for all the apps, while having the OS at the same time, look and act exactly the same is a big problem. It doesn't give the end user any reason to move to 64 bits, and at the same time erects some hefty barriers to them doing so.
The Apple approach on the other hand just changes everything around in the background without the user even being aware of the change and provides actual benefits in terms of faster programs that work more reliably.
Yet another case of the difference between having the end user as your customer (Apple) versus having the corporation as your customer (Microsoft).