Sometime ago when I got new machine with Intel EM64T extensions I decided to make the switch to an an x64 version of Windows. With the release of Whidbey coming up (this was last summer) I knew I would be having to support customers using both the x86 and x64 versions of ASP.NET 2.0 so I thought I had better start getting acquainted with it.
The following is a fairly random list of things I've learned and tips that might help you if you do the same. Put together in one place it might look like a list of woe but bear in mind this has accumulated over months and on the whole I love working x64. Just think of it as a list of quirks you have to get used to when working in a dual-bitness environment
I currently run Windows Server 2003 x64 Edition on a dual-proc hyperthreaded 3GHz Xeon with 4Gb RAM. I use Virtual Server 2005 R2 x64 so that I can host virtual guest operating systems for when I need to test particular software configurations. I use a quad flat panel monitor configuration. This allows me to remote desktop to physical or virtual machines that I am working on, run my email, communicator, Live Meeting, case logging tool, debugger and everything else I need with screen real estate to spare all from one keyboard and wireless mouse. I find this a very productive configuration.
1) Most 32-bit applications run just fine on x64 Windows. I've run into very few compatibility issues. Usually they are around setup programs that make incorrect assumptions about folder or registry locations and do not use the appropriate APIs to manipulate them.
2) In task manager, 32-bit applications are called out in the process list by having a *32 appended to the end of the name.
3) If you want to use FrontPage Server Extensions on your x64 machine you need to install it. It is not included "in the box":
4) If you want to use the .NET runtime then you have to install it. Unlike its 32-bit counterpart, Windows Server 2003 x64 does not include the 1.1 .NET runtime.
5) When you install the .NET 2.0 runtime for x64 you actually get 2 runtimes in one - the 32-bit and the 64-bit.
The 32-bit on goes here - "E:WINDOWSMicrosoft.NETFrameworkv2.0.50727"
The 64-bit one goes here - "E:WINDOWSMicrosoft.NETFramework64v2.0.50727"
6) In Windows x64, most things exist in both 32-bit and 64-bit versions. So, for example, you can choose to run 64-bit Notepad or 32-bit Notepad. My favourite is 64-bit Notepad.
7) 64-bit system DLLs and EXEs reside in the windowssystem32 directory. 32-bit system DLLs and EXEs live in the windowssyswow64 directory.
8) If you want to "see" the registry as a 32-bit application would see it you should run the 32-bit version of regedit. Start->Run, e:windowssyswow64regedit.exe, "Ok".
9) If you want to monitor performance counters for a 32-bit application you need to run the 32-bit version of perfmon. Start->Run, e:windowssyswow64perfmon, "Ok".
10) When you run a 32-bit process on x64 it is actually launched as a 64-bit process. Very early on in the life of the process the OS recognises it is compiled as 32-bit and sets up the necessary WOW64 bits and pieces so that all API calls from the 32 bit code get thunked to the appropriate system call. Try it, attach the 64 bit WinDBG to a 32-bit process and poke around. I'll probably blog about that later.
11) If you are using Visual Studio 2005 on x64 the IDE still runs as a 32-bit process. It is only the .NET runtime itself that comes in both 32-bit and 64-bit flavours. By default, when you compile up a .NET (managed code) application it is compiled to target a platform of "Any". That means that if you run it there and then on your x64 system it will run as a 64-bit process. However you can take the same EXE and run it on a 32-bit version of Windows and it will run happily as a 32-bit process. That is because the CLR's JIT compiler turns the IL into native instructions for the platform you are running on, at run time.
12) If you rely on shell extensions provided by 32-bit applications (like WinZIP for example) then you will not see their options on the context menu when you right click on a file or folder. That is because Explorer.exe is running as a 64-bit process while the shell extension is a 32-bit binary and is registered in the place where shell extensions get registered in the 32-bit "view" of the registry. The solution (at least the one I am happy with) is to use Internet Explorer to browse to the file or folder and right click in that. By default, when you launch IE on x64, the 32-bit version of IExplore.exe is launched. (Presumably this is for convenience reasons because so many web sites rely on 32-bit plugins and ActiveX components.).
13) If you work with IIS you need to decide whether you are going to use 32-bit worker processes or 64-bit worker processes. You can't have both on the same machine. Your choice is made by making the appropriate metabase setting which you can read about here.
14) You cannot load 32-bit DLLs in a 64-bit process or vica-versa. So if you have some crucial legacy component that you cannot migrate to 64-bit then you either need to stick with 32-bit OR look at some way of hosting it in a 32-bit process (like a COM+ package or other host process). You could then communciate between your 64-bit process and the 32-bit process using some inter-process communication mechansim like COM or something.
15) Even if you stick with 32-bit worker process model you can still benefit greatly from moving to an x64 server platform. That is what Microsoft.com found anyway.
16) Processes linked with /LARGEADDRESSAWARE actually get access to the full 4Gb of address space when running on x64. I mentioned this in an earlier blog post.
P.S. There is a 64-bit portal on MSDN.