http://bugs.winehq.org/show_bug.cgi?id=13915
Nicolas Joyard joyard.nicolas@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |joyard.nicolas@gmail.com
--- Comment #4 from Nicolas Joyard joyard.nicolas@gmail.com 2008-11-01 22:29:07 --- According to the UESP wiki, the author of OBSE (Ian Patterson) has been contacted about this issue. Here's his answer, it might be useful to solve this bug...
--
This appears to be a discrepancy between the Windows implementation of the DLL dependency handler/loader and the Wine implementation. Unfortunately I don't have a linux install to test this on, but my first guess would be that calling CreateProcess with the CREATE_SUSPENDED flag set leaves the new process' loader critical section locked until the main thread is resumed.
The loader works in a pretty straightforward way:
- create the new process with CREATE_SUSPENDED - VirtualAllocEx some executable memory in the new process to store enough code for "jmp LoadLibraryA" and a null-terminated string pointing to our DLL (in a perfect world we would just point the thread entry point straight at LoadLibraryA, but this makes some virus scanners explode, literally) - use CreateRemoteThread to create a thread in the new process pointing to the injected code, setting the parameter to the thread function to the DLL path in the new process (conveniently the calling convention and signature of thread entry points and LoadLibrary are exactly the same) - wait for the thread to terminate, signifying that the DLL has been loaded - clean up
This sequence requires that processes not be holding the loader lock immediately after creation.