Jamie,

> You have to be very careful with DllMain. A lot of things don't work
> properly from DLL_PROCESS_ATTACH, usually deadlocking but other subtle
> bugs are possible too. (Detaching is even worse).

Yes, I've read these warnings too. Unfortunately there isn't a lot of
choice since DLL_PROCESS_ATTACH is the only hook available, so I'm
hoping to tiptoe through the minefield unscathed.

> In particular, initialising Winsock from DllMain doesn't always work
> (because it might load some Winsock DLLs), depending on the version of
> Windows (and Winsock, and third party network products), so even if
> you use an IP address, or _synchronous_ DNS resolution, it's not
> guaranteed to work on all Windows versions.

Since we're already using a DLL-injection technique, I've been playing
with the idea of injecting ws2_32.dll first, followed by our DLL. The
hope is that when our DLL, which in turn uses libcurl, comes along,
Winsock will be already loaded and initialized. There may still be some
LoadLibrary calls initiated during our DLL_PROCESS_ATTACH but AIUI if
the DLL has already been attached to the current process space any
subsequent LoadLibrary calls are no-ops.

In fact when I first encountered the hang I assumed it was the result of
loading Winsock from DllMain and wrote up a test case to dig into it. I
was quite surprised to find out that (a) the hang was in the DNS
resolver and (b) once that problem was solved (with Daniel's help) the
test case actually succeeds in establishing an HTTP connection and doing
a GET from DllMain. Unfortunately even with these fixes the main
application still hangs, so I'm back to trying to figure out the
difference between the test and the main app, but at least the test case
provides a proof of concept. Whether this can be made to work reliably
is another question.

Thanks,
MB
Received on 2008-01-02