Liviu Nicoara wrote:
> This looks better. I was reluctant to use build numbers as a substitute
> for micro as build numbers are AFAIK sequential throughout the whole
> windows series.

The build number probably isn't terribly useful, except to detect
bugs. Unfortunately, on Windows even the major and micro numbers
aren't very useful without some non-trivial interpretation. I
expect the _RWSTD_OS_WINDOWS_XXX macro is the one that will be
the most useful in detecting which API can and cannot be used
(which is the main purpose of this test).

> 
> I got the point that undef'ing is a no-no in the comp tests.
> 
> When it comes to OS version, I believe the build number is the one that
> comes closest to be the equivalent of UNIX "uname -v". It would be very
> helpful to hear more opinions on this one though.

Unfortunately, the output of uname -v is completely unspecified
(just like the output of pretty much any other uname option):
http://www.opengroup.org/onlinepubs/009695399/utilities/uname.html

For example, on AIX it outputs the major version of the OS, but on
HP-UX it prints the letter U and on my Solaris box it spits out the
word Generic. On IRIX it gives the timestamp when the OS was built,
and on Linux it includes a whole bunch of stuff.

So I think we can put whatever we want in there, as long as we
think it will be useful. None of the macros that expand to strings
is currently used in the library (some of them are used in the test
suite). Eventually, I would like to use them in the library to
detect at runtime on what machine it was configured. This would
be useful in cases where the library was configured for one OS
and is being used on another that's not 100% compatible with it
(e.g., Windows NT vs 2000).

Unless there's more feedback I'll go ahead and check in the latest
patch.

Martin