[Lazarus] disable the debugger capturing the OutputDebugString() messages

[Sven Barth]

Hi again!

On 18.07.2010 13:16, Bernd wrote:
> 2010/7/18 Sven Barth<pascaldragon at googlemail.com>:
>> GDB registers itself as a debugger with Windows for that application and
>> thus Windows itself is routing all messages that are sent with
>> OutputDebugString to that registered debugger.
>
>> From what I have read about this mechanism it is not possible to
> register for these messages as long as there is another program
> already registered and running. I can start DebugView and it will work
> and continue to capture messages from other applications *before* and
> *during* the run of GDB, so GDB cannot use the normal mechanism. It
> must somehow intercept these calls before they reach the windows API.
> At least this is the only explanation I have to explain the observed
> behavior.

Now you got me to digging deeper into it and I took a look at the source 
of OutputDebugString in ReactOS (see here: 
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/debug/output.c?revision=40558&view=markup 
).

It basically does the following:
1) Raise an exception containing the message. If a user mode debugger is 
attached (e. g. GDB), that one will catch the exception, will see that 
it's a OutputDebugString one and will do something with the contained 
message (e.g. Print in case of GDB).
2) If the exception is not catched by the debugger the except handler 
will be executed which will try to print the message for the global 
debug message monitor (in your case DebugView) which is basically a 
memory mapped file.
3) If that fails, too, the message is sent to the kernel debugger which 
will normally print it.

So in your situation GDB is catching the OutputDebugString exception of 
your application and thus prints the message that is contained in it. 
All other applications don't have a debugger attached and thus the 
messages are written into the shared file and read by DebugView.

You might copy the "print to shared file" approach from kernel32.dll in 
a Pascal variant (e. g. called "PrintToDebugMonitor") too circumvent GDB 
catching the exception. Take a look at the C code to do this.

Regards,
Sven