The one FACT I do know, is the MSVC IDE, ever since the beginning of 32-bit, automatically adds
-
/D "WIN32"
to EVERY build file set it automatically create for every new project...
EVERY 'makefile' given in the copious sample code has /DWIN32. It is true some ALSO have /D "_WIN32", ALL have WIN32, even when /D "WIN64" is defined when "$(CPU)" == "IA64"...
That alone should be sufficient evidence that in our header we should be using -
#ifdef WIN32
And that is true even for the latest MSVC10 (2010), so no idea where the idea that the use WIN32 is in any way be considered 'obsolete'. That sound like FUD ;=))
This following site seems to say most of what I have always understood to be the 'facts'... but it can certainly be read two ways, depending on your bias I guess. If you already feel _WIN32 is the right thing, then I think you can read that. Likewise, if you already think WIN32 is correct, then you can read that ;=((
http://stackoverflow.com/questions/662084
Since I 'started' with using MSVC, and knew little of unix and other compilers outside MS at the time - I have since tried to correct that imbalance - then I have a strong propensity towards what the MS coders of the MSVC IDE chose as a DEFAULT define, name /D "WIN32", so tend to like #ifdef WIN32 in header macros, but both, either will work...
And I sort of 'like' this 'explanation', although have no idea if it is true or not :-
"Essentially the versions with the underscore are controlled by or used by the compiler
team, the versions without the underscore are controlled/used by teams outside of the
compiler"
We are OUTSIDE the compiler team, so should use just WIN32...
And it points out there are OTHERS exactly like this -
_UNICODE/UNICODE, _DEBUG/DEBUG, or maybe _DLL/DLL
As stated, the MS compiler always defines _WIN32 for us, whether we add it or not, but still in
the Windows headers, there is a simple macro :-
#ifndef _WIN32
#define _WIN32
#endif
I understand this is because other 3rdparty compilers, apparently like that in the MAC, and MingW compile, maybe the gcc ported to cygwin, and perhaps others, do NOT automatically define _WIN32, so this windows header ensure it IS defined... And that is maybe the reason why this 3rdparty site only mentions _WIN32 when giving a long list of 'Operating System' macros...
And that page, and others, go on to explain that since the MS compiler defines _WIN32 is ALL CASES, and there is a header which does it, even if the compiler does not, thus for WIN64 switching, you MUST check if it is defined FIRST, because even for a 64-bit build, because _WIN32 will be defined ;=((
This
stackflow page perhaps gives some history of why WIN32, that is why WIN + 32, came about in
the first place
"_WIN32 doesn't mean what you think it does. It means "I am using the Windows API". The 32
postfix was added back in the days of Windows NT 3.1 to make it distinct from the 16-bit API
that was used in Windows version 3. This term has fallen out of favor because of the bitness
problem. You can see this at stackoverflow.com, the [win32] tag takes you to [winapi]."
It is worth repeating, like I suggest for other pages on this subject WIN32 versus _WIN32, I think after reading this page, if you already feel _WIN32 is the right thing, then I think you can read that. Likewise, if you already think WIN32 is correct, then you can read that. I personally fall in the latter category ;=))
Just some thoughts on the subject...
Geoff.
2012-02-18