When writing processor-specific code, the _M_IX86, _M_AMD64 and _M_IA64 can be used for conditional compilation — so far, so good. But sometimes code is not exactly processor-specific but rather specific to the natural machine word length (i.e. 32 bit or 64 bit). Fur such situations, there are defines, too — however there is a little catch: For ancient 16 bit code, there is _WIN16. For 64 bit, the WDK build environment defines _WIN64 by default. Given these two macros, it is tempting to conclude that _WIN32 should only be defined for 32 bit builds — however this is not the case. As it turns out, _WIN32 is always defined, both for 32 and 64 bit builds.
And yes, this behaviour is documented on MSDN, but it is stupid anyway.
However, where _WIN32 can be of use is when writing code targeting multiple platforms — as _WIN32 is always defined, it can be used as an indicator that you compile for Windows, regardless of the compiler used (another option is to use _MSC_VER, but that is compiler-specific).
LinkedIn Profile
Xing Profile
Follow me on Twitter (new)
Yeah it may look sick but perhaps it has quite some reasons behind the decision. _WIN32 is introduced quite some time ago and compared to 16-bit Windows it was a completely different world. Not so much difference now between 32-bit and 64-bit code and I am pretty sure they decided to keep _WIN32 defined for 64-bit code for compatibility and code migration reasons.
It is not a big problem in practice since you often end up writing something like:
#ifdef _WIN64
SomeAPI()
#else
DisableRedirection()
CallLegacySomeAPI()
RestoreRedirection()
#endif
For cross platform builds, the fact that _WIN32 is defined for 32 and 64 also comes in handy:
#ifdef _WIN32
WSA*()
#endif
socket()
Hi,
Is there a way we can avoid these #ifdef to make code compatible with both 32 bit and 64 bit?
Thanks,
Keerti