As a programmer, what do I need to worry about when moving to 64-bit windows?
As far as I'm concerned, the single most important thing about porting C/C++ code to 64-bit Windows is to test your application with MEM_TOP_DOWN
allocations enabled (AllocationPreference
registry value) as described in 4-Gigabyte Tuning:
To force allocations to allocate from higher addresses before lower addresses for testing purposes, specify
MEM_TOP_DOWN
when callingVirtualAlloc
or set the following registry value to 0x100000:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Memory Management\AllocationPreference
When does this matter?
- If you have existing 32-bit EXEs that were built with the
/LARGEADDRESSAWARE
MSVC linker option (or which have theIMAGE_FILE_LARGE_ADDRESS_AWARE
flag set in their PE headers through other means, such aseditbin.exe
), then they get a full 4 GB of virtual address space in 64-bit Windows, and you must test them with theAllocationPreference
registry value set. - If you have existing 32-bit DLLs that may be loaded by large address aware EXEs, you must test them with the
AllocationPreference
registry value set. - If you recompile your C/C++ code into a 64-bit EXE or DLL, you must test it with the
AllocationPreference
registry value set.
If your C/C++ application falls into one of these three categories and you don't test with MEM_TOP_DOWN
allocations, testing is very unlikely to catch any pointer truncation/signedness bugs in your code.
The second most important thing, if you use MSVC and you are recompiling C/C++ code for 64-bit, is to use the /Wp64
compiler option for your 64-bit build:
- This will cause the compiler to emit warnings for typecasts that truncate pointers or extend smaller integral types into pointers (even when
reinterpret_cast
or a C-style cast is used), as well as a few other 64-bit porting issues. - Yes, the documentation says that instead of compiling with
/Wp64
you should use a compiler that targets a 64-bit platform, but that alone will not catch pointer truncation/extension issues at compile time. Using a compiler that targets 64-bit and enabling the/Wp64
compiler option for the 64-bit build will catch many pointer truncation/extension issues at compile time, and this will save you time in the long run. - Unfortunately, with MSVC 2008, this will also produce a "command line warning" for each translation unit saying that the
/Wp64
option is deprecated. I can see why the option is deprecated for 32-bit builds (where it is an evil hack that requires annotating many of your typedefs), but it's unfortunate that it is also deprecated for 64-bit builds (where it is actually useful).
Articles:
20 issues of porting C++ code on the 64-bit platform
The forgotten problems of 64-bit programs development
64 bits, Wp64, Visual Studio 2008, Viva64 and all the rest...
Traps detection during migration of C and C++ code to 64-bit Windows
AMD64 (EM64T) architecture
And
Viva64 tool - for check 64-bit programs:
Viva64: what is it and for whom is it meant?