Generic Windows Constant

[shadypalm88]

Hi, I've never programmed in C/C++ for Windows before.  I'd like to start doing that, and I was wondering if there's a single constant defined on all Windows systems so I can just use #ifdef and the like to include Windows-specific code when I compile on Windows vs. *nix-specific code.

Thanks in advance.

[iago]

WIN32

#ifdef WIN32
printf("You're on windows");
#endif

[Skywing]

WIN32

#ifdef WIN32
printf("You're on windows");
#endif

Actually, it's _WIN32, not WIN32.  Also, note that Win64 defines this too because of so much broken code that refuses to work if _WIN32 isn't set.

[Adron]

Actually, it's _WIN32, not WIN32.  Also, note that Win64 defines this too because of so much broken code that refuses to work if _WIN32 isn't set.

Doesn't that make sense? If you're expecting to be running on a 32-bit platform and your code is written with that assumption, you'll want to only run when _WIN32 is set, and not when _WIN16 or _WIN64 are set?

[Kp]

Doesn't that make sense? If you're expecting to be running on a 32-bit platform and your code is written with that assumption, you'll want to only run when _WIN32 is set, and not when _WIN16 or _WIN64 are set?

If Win64 implements the same API (aside from the obvious conversions from 32bits to 64bits in the right places), code designed properly should work fine on 64bit architectures with nothing more than a recompile (and maybe some updating to typedefs if they did custom typedefing for integer sizes).  However, from Skywing's description, some code which is written well enough that it could port over this way refuses to port easily because the programmer(s) who wrote it conditioned it to require exactly 32bit architecture, when they really only needed to check if the base data type was at least 32bits.

[Adron]

If Win64 implements the same API (aside from the obvious conversions from 32bits to 64bits in the right places), code designed properly should work fine on 64bit architectures with nothing more than a recompile (and maybe some updating to typedefs if they did custom typedefing for integer sizes).  However, from Skywing's description, some code which is written well enough that it could port over this way refuses to port easily because the programmer(s) who wrote it conditioned it to require exactly 32bit architecture, when they really only needed to check if the base data type was at least 32bits.

That depends on how they wrote the code. If the code was written to work with 32- or 64-bit architectures, then yes. But if they didn't take special care to make the code operational on architectures with longer variables, making the code only compile in a 32-bit architecture makes sense. All I have to do to make that very obvious is look at the number of 64-bit portability warnings I get when I enable those. Until they have tested the code on Win64, it would make sense not to allow it to compile there, since there may be bugs that surface only on a 64-bit architecture.