OS X was the first operating system to ship as a single
install that could boot into either a 32-bit or 64-bit
kernel, either of which could run 32-bit and 64-bit
applications at full native performance. OS X now
exclusively uses a 64-bit kernel, but it continues to run
both 32-bit and 64-bit applications.
I believe Solaris was actually the first to do this:
The key phrase is "either of which could run 32-bit and 64-bit applications." OS X supported 64-bit apps on a 32-bit kernel. This enabled users to run 64 bit apps, and use >4 GB address space, without any device driver incompatibilities.
I think Solaris (and Windows and Linux) require a 64 bit kernel to run 64 bit apps. Correct me if I'm wrong.
With that said, OS X's hack support for 64-bit applications on a 32-bit kernel certainly wasn't at the same performance level as a 64-bit kernel as they claim. It's a dubious achievement at best given the performance tradeoffs.
It seems like you are casting aspersions. In what way was it a "hack" and what performance tradeoffs were there? Apple's claim is that 64 bit apps ran at native speeds, which is true, since they just used the native ISA.
Apple lists a few benefits of K64 at https://developer.apple.com/library/mac/#documentation/MacOS... , specifically more efficient support for systems with lots of RAM, a larger buffer cache, and better support for multiple video cards with over 2 GB of RAM. These are pretty specialized, and I certainly don't remember my Mac getting a lot faster when it switched to K64. (I sure wish it had!)
But, there was a cost to that dependent on architecture. If you read the document I linked above, you'll see that there is a cost to this 64-bit translation -- the performance is not completely equivalent to a 64-bit application running on a 64-bit kernel where there is no need for translation.
And yes, there were performance tradeoffs. A 64-bit application running on a 32-bit OS still had all of the 32-bit limitations enforced (limit on maximum process size, number of file descriptors, etc.).
And once Apple made the transition to x86 from PowerPC they lost the built-in hardware advantage. x86 can also run 64-bit applications on a 32-bit kernel, but the cost of doing that hardware switch is not as cheap as it was on PowerPC. I also think it's very telling that Solaris, Linux, and Windows opted to never do this as well.
And now that OS X no longer offers a 32-bit kernel, this all seems moot anyway.
To be clear, Apple are claiming the ability to install both 32-bit and 64-bit kernels on a single disk, and select the correct one at boot time so that boot disks are transportable between 64-bit and 32-bit machines.
I'll clarify then: I believe Solaris has had the first part (ability to boot into a 32-bit or 64-bit kernel) since 1998. That's well before Apple even provided a 64-bit kernel or ever shipped an OS X release.
Solaris has long had a single, unified architecture for 32-bit and 64-bit and until recently delivered both a 32-bit and 64-bit kernel on a single disk. That's why on Solaris you'll generally find the 32-bit libraries installed in 'usr/lib' and the 64-bit under 'usr/lib/64'.
The only exception is for processor architectures (SPARC/x86) where it made less sense.
But even then, Solaris 11 has multi-variant packages, so a single package provides support for both x86 and SPARC.
It's true that (as far as I'm aware) Solaris never supported the 64-bit application on 32-bit kernel hack that OS X did (which comes with significant performance tradeoffs).
So at most, Apple can claim that achievement, but they can't claim to be the first to provide a single install image supporting 32-bit and 64-bit.
"It's true that (as far as I'm aware) Solaris never supported the 64-bit application on 32-bit kernel hack that OS X did"
It also is true that (as far as I am aware) Solaris never had lots of 32-bit customers running applications and drivers that neither Sun nor those customers could recompile for 64-bits.
That and the fact that some of those customers desperately wanted/needed to access more than 4 GB of memory forced Apple's hands. They had to keep the kernel 32 bits to support older drivers, and had to provide a user space that supported more than 32 bits.
The world is so much simpler if you can force al your customers to recompile their applications. If you doubt that, ask Microsoft or Intel why Itanium didn't even get a chance.
It also is true that (as far as I am aware) Solaris never had lots of 32-bit customers running applications and drivers that neither Sun nor those customers could recompile for 64-bits.
That is definitely not true. In fact, many of the binaries distributed with Solaris itself (even now that it has a 64-bit kernel) are still delivered as 32-bit because there's no need for them to be 64-bit (yet).
The world is so much simpler if you can force al your customers to recompile their applications. If you doubt that, ask Microsoft or Intel why Itanium didn't even get a chance.
Except Sun/Oracle (Solaris) never required that. In fact, Solaris is famous for its backwards binary-compatibility. In fact, on Solaris 10 you can run binaries that were compiled decades ago without issue.
Apple would have lost many of its top of the range customers if it had jumped directly to full 64 bit, because, due to lack of drivers (note the italics in my original post), those users would have lost the use of their expensive hardware.
Sun, AFAIK, was much more in control of its drivers, so it could move its systems to 64 bit easier.
http://en.wikipedia.org/wiki/Solaris_%28operating_system%29#...