We are getting really darn close to shipping Visual Studio 2005. Visual Studio 2005 is the first released VS-based debugger to support 64-bit. This is a feature that has taken an amazingly long time to ship. The first 64-bit work was done ~8 years ago. 64-bit debugging work was going on well before we actually had any IA-64 hardware.
One interesting thing about the way we implemented 64-bit debugging – the UI is in a 32-bit process. This works by running a separate 64-bit process to hold the debugger backend. Internally, we refer to this as 'pseudo-remote debugging' because we are using the remote debugger (msvsmon.exe) even though we are debugging a local process. We didn't always implement 64-bit debugging this way. For the first many years of the 64-bit effort, everything was a 64-bit process.
Using a 64-bit process on a 64-bit machine seems like the natural thing to do. Historically, emulators have tended to give a second-class experience. When I ran OS/2, I tried to find OS/2 applications. When I switched to Windows 95, I tried to find 32-bit applications. So running Visual Studio in a 32-bit process seemed like the wrong long-term approach.
Now, a couple of years latter, I am glad we went with the 32-bit process. Building fewer components as 64-bit meant that we have fewer components that could possibly break the 64-bit build, and fewer components that could have pointer-truncation bugs. We had difficulty with the 64-bit registry, and producing a setup. But these are challenges that we would have had even with a 64-bit process.
So after all this, here are my conclusions: