What to watch out for when writing 32-bit software on 64-bit machine?

Question

I am purchasing a comfortable laptop for development but the only operating system available to me is 64-bit (Win7) , now I am basically aware that 64-bit has 8-byte integers and can utilize more RAM, that is about it.

My programming will vary (C++, sometimes PHP) but would like to know:

• Can I build my C++ application to be 32-bit portable (run in a 32-bit computer without needing to build under a 32-bit virtual machine?)
• What are the simple gotchas to watch out for when writing an application (casting, etc)

Answer 1

Specifically for windows, take a look at the msdn documentation of WOW64. Windows 64 bit runs 32 bit applications in an emulator, so you can build an run 32 bit apps for your system. This has some (rather positive) effects on your app, e.g. virtual address space for your process increases, as the OS may use higher 64 bit addresses your 32 bit process isn't even aware of.

The MSVC++ data type sizes are also documented on MSDN. But if you are worried about casting, you should use bigger types that'll certainly fit your needs. The C++ standard doesn't define the exact size of types (afaik), only their relative sizes (short is shorter than int and so on). So, you cannot rely on the exact size of these types unless you use some int32 or __int32 which obviously won't change for 64 bit apps.

Answer 2

The simplest thing would be to simply build a 32-bit executable. With Visual Studio, just choose Win32 as the build type. With gcc, use the -m32 switch.

Answer 3

Cross compiling (for different platforms, pointer sizes, endianess, etc.) has been around for ages and as long as you use the right tools and flags to build your 32-bit executable, the build platform really shouldn't matter.

In case of the Microsoft compiler, it should as simple as firing up Visual Studio and compiling your program using the default "Win32 configuration. In case you prefer the command line, be sure to select the 32-bit tools by invoking the Visual Studio Command Prompt (as opposed the x64 version).

BTW, if you are running 64-bit Enterprise Server, you can turn on the Hypervisor Role, install 32-bit Win7 inside a virtual machine and actually test your built program. Finally, it's always a good idea to test the program on the actual target platform on which it wil execute :)...

Answer 4

Processors have been 64 bit for some time. I'm perplexed about why people are afraid to make the move to a 64 bit operating system. A 32 bit OS can't address much more than 3Gb of RAM, so that's good enough reason to make the upgrade in my book!

When you're coding, the biggest difference I've encountered to look out for is the size of a pointer!

On a 32-bit compiled program, a pointer is normally 4 bytes. On a 64 bit compiled program, a pointer is normally 8 bytes.

Why does this matter?

Lets say your program uses sockets to communicate a data structure from one process to another. Maybe the server process is 32-bit and the client process is 64 bit.

While the struct might be defined identically in both 32 and 64 bit programs, the 64 bit exe will reserve 8 bytes per pointer (and structures normally contain pointers to other structs as in linked lists etc.).

This can lead to data misalignment when a 32 bit exe communicates a struct to a 64 bit exe.

In (almost?) all cases, communicating pointer values between processes is meaningless anyway, e.g. their data doesn't matter and can be omitted.

So you might think that communicating pointer values would be an uncommon practise - but the easy way to communicate a struct is to memcpy its contents over a socket, pointers and all!

This is the most significant snag I've found so far, when coding 64 bit clients, when our server software is 32-bit.