Peter did not suggest not using windows.h itself AFAICS. He just suggested that stacktrace functionality which does not need it be segregated into specific headers which do not include it. Furthermore if stacktrace still has the general header, and promotes the use of it, rather than specific headers, that's fine as long as the end-user has a choice. OTOH if stacktrace functionality which appears not to need the constructs in windows.h still does need it under the covers in the header only version of the library, then I understand Antony's objection.
If you choose the null backend, then yes windows.h should not be included. If you choose the non-null backend, which needs to open up a COM session with the Debug Engine to debug the calling executable, I think windows.h (and the COM headers which are also massive) pretty hard to avoid. And for the record, I too feel little love for windows.h, though they do provide NOMINMAX and WIN32_LEAN_AND_MEAN to make the problem less awful. One HUGE win with C++ Modules will be that we can finally work around windows.h once and for all. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/