Share via

Reflections on 64-bit

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:

  1. On X64, don't think ill of apps that are 32-bit.
  2. If you don't care much about performance on IA-64 or using more than 4 GBs of memory, don't bother compiling your app for 64-bit.
  3. If you need to look at files in the system directory, use Wow64DisableWow64FsRedirection

Comments