RFH: Applications that call stuff from DllMain

[Andrew Eikum]

On Wed, Jan 11, 2012 at 01:03:56AM +0800, Dmitry Timoshkov wrote:
> Andrew Eikum <aeikum at codeweavers.com> wrote:
> 
> > So, I'm asking for insights. Should I try hard to avoid launching
> > threads unless absolutely necessary? Is this a known deficiency in the
> > loader, and I should do nothing? Is there some other way to work
> > around this?
> 
> As usually first thing to do is to write some tests and investigate what
> Windows does/how it copes with such cases.

Some more testing just confirms that we should be able to launch
threads from within a client DllMain(). I wrote a test DLL, compiled
in MSVC++ 2010, which basically does (pseudocode, obviously):

DllMain(){
  winmm = LoadLibrary("WinMM.dll");
  wOGND = GetProcAddress(winmm, "waveOutGetNumDevs");
  printf("%u\n", wOGND());
}

I then load that DLL from a (severely hacked) dsound_crosstest.exe,
which does not link against dsound or winmm.

Printing the result from waveOutGetNumDevs() shows that it works (it
returns 2, which is correct). Monitoring the thread count via Task
Manager before and after the call shows that waveOutGetNumDevs()
launches a thread, like I mentioned in the first email.

Running that dsound test in Wine to load dmtest.dll deadlocks waiting
for the loader CS, just like the bugs linked in the first email.

So it appears we should be able to launch threads in DllMain() without
deadlocking.

Thoughts, anyone?

Andrew