John Maddock:
Lets see where these changes get us, and then we need to decide what to do on Win32 in strict mode when <windows.h> is unavailable :-)
I believe that the fact that <windows.h> is unavailable (this can happen in non-strict mode as well under VC++ Express, if the Platform SDK hasn't been installed) should be indicated by a new macro that is documented as such.
Well we have BOOST_DISABLE_WIN32 which is set when <windows.h> is unavailable - or alternatively optionally by the user.
I don't like the fact that the macro names do not reflect their actual meaning. This inevitably leads to their being set in situations where they shouldn't be, and vice versa. A macro that indicates the absence of windows.h should be called BOOST_NO_WINDOWS_H, and the reverse should be BOOST_HAS_WINDOWS_H. A user macro that overrides the detection should be called BOOST_DISABLE_WINDOWS_H. In general, we should follow a consistent naming scheme. It's obvious when this macro should and should not be set, and it's obvious when it needs to be tested - when the code decides whether to #include <windows.h> or not. The problem with making the macro clear and unambiguous in this manner is that it exposes that libraries - in reality - have no use for it. :-)
Still, the easiest way out is just to use an internal macro for communication and leave BOOST_DISABLE_* as pure user macros.
If we stop setting BOOST_DISABLE_THREADS when BOOST_DISABLE_WIN32 is set this issue become moot doesn't it?
There are other places where BOOST_DISABLE_THREADS is being set by Boost.Config. The problem is that I can't really know whether they are correct or not - from user point of view. The good thing about testing a user macro is that one is 100% certain that the user means what he says; the library better do what it's being told.