Panther introduced rudimentary 64-bit support to Mac OS X. It expanded the virtual address space (in the kernel, anyway) to 64 bits and allowed the use of 64-bit registers and the instructions that manipulate them (i.e., 64-bit math). But processes other than the kernel still saw a 32-bit address space. A single process could work with more than 4GB of memory (remember, the Power Mac G5 can hold up to 8GB RAM), but doing so required the programmer to manually juggle several 32-bit-addressable chunks of memory at once.
Tiger takes Mac OS X another small step in the 64-bit direction by allowing any process to see a 64-bit address space. Such a process must use 64-bit pointers in its code, of course, and that means that any libraries it uses must also be compiled to use 64-bit pointers.
In Tiger, the only 64-bit library is "libSystem," which is basically the BSD layer. A 32-bit version of libSystem is also included, of course (otherwise 32-bit applications would not run on Tiger).
A process can do a lot using only libSystem: file and network i/o, math, inter-process communication, er...more math. But the notable thing it can't do is any sort of GUI operation. (Curses doesn't count, sorry.)
For GUI applications that need to address more than 64-bits of memory as part of their work, the recommended strategy in Tiger is to spin off a 64-bit "worker thread" that only uses libSystem and communicates its results back to the host application using one of the various inter-process communication mechanisms.
This confinement of 64-bit processes to a non-GUI jail might seem severe, but in practice, a large proportion of processes that need to be 64-bit are already "faceless" worker processes doing computations on behalf of some larger system: offline rendering, server processes, scientific computing, etc. It's also a step up from Panther's 64-bit support, which is something at least.
It's clear that the road to "full 64-bit support" will be a long one. There are few benefits to being a 64-bit process for the vast majority of GUI applications. Nevertheless, it's safe to assume that, eventually, all Macs will include 64-bit CPUs. The introduction of 64-bit versions of all Mac OS X subsystems (Carbon, Cocoa, Core Foundation, QuickTime, Quartz, etc.) seems inevitable.
I just wonder how much benefit there will be from introducing any of that support piecemeal. For example, it'd seem unfair for Carbon to be 64-bit while Cocoa was not. All the higher-level GUI libraries rely on lower-level services like Quartz and Core Foundation anyway. So it seems to me that the best move in the future will be to roll out a complete 64-bit system all in one shot. That's a tall order, which is why I think it'll be a while.
