Re: non-persistent DllMain

["Sam Liddicott" <sam at liddicott dot com>]

* Dave Korn wrote, On 03/10/08 15:58:
> Sam Liddicott wrote on 03 October 2008 14:04:
>
>   
>> * Dave Korn wrote, On 03/10/08 13:34:
>>     
>>>   DllMain is special.  There's a lot you cannot do in there, in
>>> particular file i/o, printf etc, because you're running inside a lock
>>> and it's a sort of critical section-y sort of situation, and indeed the
>>> MSVC CRT probably isn't inited yet, so you definitely won't have stdio.
>>>
>>>   If I were you, I'd put loads of OutputDebugMessage calls in your
>>> DllMain, and watch what's happening and look at the value of hModule,
>>> and the addressof g_hDLL (etc) using Sysinternals DebugView.
>>>
>>>       
>> OutputDebugString doesn't work in DllMain either, but it works in the
>> other functions.
>>     
>
>  [also in light of your subsequent post:]
>
>   Are you /completely/ sure DllMain is being called, and that you're actually
> invoking the particular build of the DLL that you think you are, rather than
> maybe one in your PATH or elsewhere that's somehow getting first in the DLL
> search order?
>   
Yes. If I edit DllMain and put in "return False;" then then perl fails
when it tries to load the dll.

I recompile with: make && copy GuiTest.dll /path/to/GuiTest.dll, if perl
is still running, then the copy fails because the file is in use.


Have you any tips on cross-process debugging?
I can attach to explorer.exe but I don't know how/where to set the
breakpoint to catch when the send-message hits that process, or maybe it
isn't even getting that far...

Sam


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/