I just upgraded to Boost 1.35, and I now have a major problem with windows.h, thanks to the Boost.Threads library now invoking Boost.DateTime which on Windows #includes <windows.h>. Besides the min and max macros, there are other problems, like the fact that one of the platform headers does this: #define small char A third party library that I am using has a class called small. Oops. There are very, very many of these things. I'm afraid I am going to have to go back to 1.34 indefinitely. Google pulls up a lot of messages from other users having these troubles. I don't know very much about the Boost.DateTime architecture - I have used the threading library for years in its older version, but never the date/time library - but to the DateTime developers I ask: Is there any possible way that this could be reworked in the future to avoid bringing windows.h into the user's world? The macros and namespace pollution are a very serious problem. Defining NOMINMAX helps a little, but on things like the "small" macro I'm afraid I'm stuck. I see from mailing list posts that DateTime is not the only Boost library to do this, although certainly most of the libraries do not. It surprises me that Boost has such a nice policy on its own headers, yet allows implementations to do things like this. I know sometimes it is hard to avoid, but for windows.h - which is notorious for these problems - it would seem like it would be worth some contortions in the implementation to avoid this. I would be more than happy to compile and link some extra CPP files to keep the HPP files clean. To the Boost community at large I ask: What is the thinking on this? Thanks for your consideration. Brian