* 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/