RFH: Applications that call stuff from DllMain

[Andrew Eikum]

This mail is about bugs 28042[1] and 28677[2]. In short, what I'm
trying to deal with is buggy applications that make calls to DSound
and WinMM from within DllMain(), causing deadlocks.

On almost any entry into DSound or WinMM's wave functions, the modules
launch a thread to communicate with MMDevAPI. We create a new thread
for two reasons. First, to CoInitialize() the thread, which we
shouldn't do on a user thread. Second, the MMDevAPI docs say that the
device objects should be created and destroyed from the same
thread[3], which we can't guarantee if we create them on a user thread
(I think dsound currently violates this, actually).

Wine holds the loader critical section during calls to DllMain().
However, launching a new thread requires using the loader, and so we
hit a deadlock. This is the problem reported by these bugs.

While we might be able to perform some of these functions without
launching a new thread, I'm not sure that that's a general solution,
since we will have to launch a thread at some point. Analysis on
Windows 7 shows that DirectSoundEnumerate() does not launch any
additional threads, but mixerGetNumDevs() actually does launch a
thread, yet the application still launches successfully.

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?

Thanks,
Andrew

[1] http://bugs.winehq.org/show_bug.cgi?id=28042
[2] http://bugs.winehq.org/show_bug.cgi?id=28677
[3] http://msdn.microsoft.com/en-us/library/windows/desktop/dd370873%28v=VS.85%29.aspx