As a programmer, what do I need to worry about when moving to 64-bit windows?

Question

Most of my recent programming has been on 32-bit Windows using C/C++/C#/VB6 . Lately, my customers are asking if my code will run on 64-bit Windows.

I\'m wondering w

Answer 1

If you do DLL injection for any reason you will have trouble.

Answer 2

Is the 32-bit emulation really bullet proof? I have seen that the registry is layed out a little differently. I'm just wondering what typical things don't work...

Also, the C:\windows\SYSTEM32 directory can only contain 64-bit DLLs. If you have a 32-bit DLL, you need to put it in C:\windows\syswow64\

Answer 3

32bit programs will run fine on 64 bit windows. As long you are not doing any device driver kind of development of course.

If you compile your software as a 64 bit software the first time, you need to take care of following:

• a pointer is 64 bit wide, while an int is 32 bit. Don't store pointers in ints, your code will break.
• 64 bit process need 64 bit DLLs. If you depend on third part DLLs, make sure they are also provided in 64 bit. If you need to communicate between a 32 bit process and a 64 bit process, you will need some of the many different ways of IPC on Windows. Calling functions directly is out of question.
• The system directories on 64 bit Windows are different than on 32 bit Windows. If you have some hard coded paths, you might need to check them again.

Answer 4

From a C/C++ perspective....

One obvious thing is that the size of an int will become 8 bytes instead of 4 bytes. If any of your code is dependent on that you may get unexpected results. Structure and variable alignments may shift. You may be able to overcome it with a #pragma pack, but I am not very fluent in alignments and packing.

If you use any unions with ints in them, the behavior may change.

If you are using any bitfield structures, based on ints the extra 32 bits may cause confusion. The sign bit won't be where you thought it was.

If you code any hex constants and expect signs to go negative, you may have issues. Example 0x8000000 is a negative number as a log, or 32 bit integer. 0x80000000 as an integer on a 64 bit platform is a positive number. to directly set the sign bit you would have to use 0x80000000 00000000 (embedded space for readability only)

Also I expect size__t to grow appropriately. If you are making any allocations based on MAX_INT, they will be much larger.

To avoid these type of size anomalies, I generally stick with longs instead of ints.

Answer 5

It might be easier to migrate .NET code if you have 100% "type safe managed code". You can just copy it to the 64-bit platform and run it successfully under the 64-bit CLR. Check this MSDN link on migrating 32-bit Managed code to 64-bit.

Btw, hanselman blogged about the topic recently.

Answer 6

If you are talking about 32-bit programs then you have practically nothing to worry about since Windows 64 will run them under emulation as 32-bit. Any problems with future Windows versions (e.g Windows 7) are likely to be incompatibilities rather than issues with a 64-bit OS.

However if your managed code is compiled for the "Any CPU" target platform and you make calls into unmanaged code (e.g PInvoke), or are dependent on other assemblies then there are some things to be aware of. Scott Hanselman's post about the x86/x64 CLR covers this and is a good explanation of the CLR on Win32/64.

When developing 64-bit native programs then the Programming Guide for 64-bit Windows is a good guide. It largely comes down to pointers and the size of data types :)