The 64-bit Issue
A 32-bit operating system can give a single program, at most, 4GB of memory. A 64-bit operating system can give a single program, at most, 16 EB of memory. The Mac OS X build that is currently running on the PowerMac G5 (10.2.7) allows each program to access 4GB of RAM. This is because all of the pointers used in such programs are 32 bits. It also allows programs on this machines to use the full width of the G5's registers, and thus manipulate 64-bit integers without penalty.
Q: Why can't we just change the pointer size (to 64-bits) and get 16 EB memory spaces?
A: Because there is more to the change than just your code. Mac OS X (as all operating systems) provides you with a HUGE volume of precompiled code for your program to use. These libraries are necessary for your programs to even start running. And all of these libraries are built (currently) expecting 32-bit pointers. There is no way for these libraries to start dealing in 64-bit pointers without being recompiled.
Q: Ok, so we need to update our libraries. So lets just have them all just work with 64-bit pointers. Problem solved right?
A: No. Unfortunately, if you just change all your libraries to expect 64-bit pointers then your 32-bit programs will break when those libraries return a pointer that is out of range for them. So what you have to do instead is have two different libraries, one that handles 32-bit programs, and one that handles 64-bit programs, this way each kind of program gets the kind of pointers that it expects.
Q: Ok, so we need 2 versions of each library. So lets start cranking. Two weeks tops right?
A: Unfortunately no. When you create such an incredible additional mass of code, you need to test it. And testing it all takes a huge amount of time. It's hardly practical to expect it to happen quickly. Yes, much of Mac OS X was designed to be easily moved from 32 to 64 bits without much difficulty, but there are many edge cases where things don't quite work out of the box, either due to common usage of an API, or exceptional circumstance around that API.
For example, many APIs take a reference constant that is passed to a callback so the callback knows what context it is being called with. Unfortunately for some older APIs these reference constants are defined as 32 bit integers, but common practice has been to use them as
pointers. So in moving to a 64 bit memory model, these APIs would need to be redefined to use 64 bit integers AND the programmers using them would need to check their code to make sure that they do the right thing when passing in the pointer (C/C++ doesn't allow you to pass a pointer as an integer without explicitly changing the data type. Code written for passing a 32 bit integer would thus clip your 64 bit pointers).
This is just one of many issues that would cause the testing time of new 64-bit libraries to take a LONG time. And before someone says it, no that doesn't make Carbon implicitly harder to move to 64-bit than Cocoa =). All of the newer, recommended Carbon APIs already use a pointer type for the reference constant instead of an integer
.
Hopefully all this will clear up why it is a difficult task to add support for 64-bit memory spaces to an OS. Hopefully it has also put across that it should not be as difficult a task as it has been for that other operating system.
