"Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote in message news:d2kofr$nbs$1@sea.gmane.org...

...

Many Boost tests are failing in the Test library on CW 9.4 due to the lack of IsDebuggerPresent(). Gennadiy?

I will deal with it this weekend.

Gennadiy

Hi, Unfortunately I was busy this weekend with some family matters. So the issue still exists. "Stefan Slapeta" <stefan@slapeta.com> wrote in message news:d2bgva$sf0$1@sea.gmane.org...

Stefan Slapeta wrote:

...

The only solution I can imagine to solve this is to set _WIN32_WINNT globally in CW's bjam settings.

FYI, the behavior is the same with other compilers: boost.test fails to compile if you include windows.h prior to the boost.test headers! (and if you didn't define _WIN32_WINNT, of course)

IsDebuggerPresent() is not implemented in windows 95, I really don't know which strategy is to embark here.

Does anybody know a reliable way to workaround this? Why _WIN32_WINNT isn't defined by default? Could we define it in Jamfiles or Boost.Build sources? Gennadiy

Another (real) issue: defining it in the jamfiles makes the boost libs compile. However, you cannot avoid that a user writes something like this in his own code:

#include <windows.h> #include <boost/test/...>

This fails for the same reasons!

I guess I could use hack like this: #define BOOST_MS_STRUCTURED_EXCEPTION_HANDLING #if !defined(_WIN32_WINNT) #if defined _WINBASE_ #error "either define _WIN32_WINNT or include boost headers in front please" #endif #define _WIN32_WINNT 0x0400 #endif #include <wtypes.h> #include <winbase.h> Gennadiy

I guess you mean

#if !defined(_WIN32_WINNT) || _WIN32_WINNT < 0x0400 etc.

Actually if _WIN32_WINNT < 0x0400 it's different situation. I should probably just disable unsuported logic.

And don't forget the jamfiles ;-)

Sorry.Maybe it's long day at work, but I did not get the joke. Could you clarify.

Cheers,

Stefan

Gennadiy

On Monday 04 April 2005 17:51, Stefan Slapeta wrote:

Gennadiy Rozental wrote:

...

Does anybody know a reliable way to workaround this? Why _WIN32_WINNT isn't defined by default? Could we define it in Jamfiles or Boost.Build sources?

The problem is that if you define it, the code will not execute on Win95 (at least for _WIN32_WINNT=4; higher values have more restrictions, of course). I don't know if there's really a huge problem with this.

Using that inside a library would make the lib unusable on win95 though. Much better is the approach taken for (IIRC) TryLockMutex in the threads library: try to retrieve a function pointer at runtime via GetProcAddress(). Also an idea: namespace boost{ // wrapper around platform specific means to detect and activate a debugger namespace debugger { // detect presence bool present(); // create a break to enter the debugger void enter(); } } /** special versions as macros that enter the debugger at the point of use and not inside debugger::enter(), if available. Purely for debugging convenience. */ #if __x86 // enter debugger via int13 # define BOOST_DEBUG_BREAK int13() #else // default # define BOOST_DEBUG_BREAK ::boost::debugger::enter() #endif Uli