Windows development: x86 to x64 transition

Question

Hi everybody.

Are there any guidelines how to transit to x64 with as little pain as possible?

Suppose, I have a windows native x86 executable written in C++. The EXE works fine by itself, but there is also DLL that is hosted by both, the former EXE and an outside x64 process. With setup like this, what parts would I need to rewrite?

I would appreciate a more general answer or maybe a link to a reference where some theoretical background is given. Thanks

Answer 1

This SDK article lists considerations for 64-bit Windows. MSVC++ specific considerations are listed here. In general, just compiling your code will flush out most issues. I cannot comment on your specific scenario, it isn't detailed enough.

Answer 2

In general the approach I recommend is to Unit Test the hell out of it. Build up your tests so that they're all passing on the 32-bit implementation and then start building and testing on 64-bit. It's worth devoting particular attention to any parts of your code where you do any of the following:

• Stream data across the network (especially for types such as size_t which will now be a different size. Go through this code and change things like size_t and long to explicit 32 or 64-bit typedefs)
• Load/save binary data to file (ditto re: size_t/long)
• Do bit-twiddling with hardcoded values such as 0xFFFFFFFF

There really are no shortcuts except to test as many code paths as you can. How easy the job will be will depend on how portably the code was written. You might be lucky...

Answer 3

I've found the best way to flush out bugs is to audit your code for any code that does any of the following and to fix it in the 32 bit world, then start the port.

• Uses untyped containers and casts rather than the correct container.
• Uses casts to store pointers in DWORDs for whatever reason, typically as an eventual prelude to storing in a container
• casting when archiving

For cases when you really do have to do the DWORD/ptr thing change the type to DWORD_PTR.

I've seen plenty of code using a CStringToPtr rather than a CMap<> with the appropriate types.

All of these things will probably compile on 64 bit (with no warnings because of the cast) and then fall flat on their face. If they used the correct types and no casts the code would work first time.

Also check for any subclassing code that sets the WndProc - you need a different flag to set this on 64 bit Windows.

If using MFC you will also (unhelpfully) find that the container sizes now return 64 bit size counts rather than 32 bit size counts, which means your 32bit/64bit archiving will be broken. You'll have to tackle this as you go. We created our own custom MFC implementation with some clever tricks to allow us to de-serialize 32 bit archives on 64 bit boxes and vice versa.