Since we stop the thread in DllMain, we always haev the loaderlock.
Thread shutdown also requires the loader lock, so we will always time out
So just wait until all cleanup is done, the thread itself can exit later
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52314
Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de>
--
v2: dinput: Wait on event instead of thread on stop
https://gitlab.winehq.org/wine/wine/-/merge_requests/1455
This avoids the following warning by GCC 13:
dlls/msado15/recordset.c:790:32: warning: 'i' may be used uninitialized
--
v3: msado15: Avoid uninitialized variable warning in fields_get_Item
https://gitlab.winehq.org/wine/wine/-/merge_requests/1449
In preparation for https://gitlab.winehq.org/wine/wine/-/merge_requests/1324.
This also begins preparation for a slightly different route than what the MR currently takes, with syscall flags eventually stored in the CounterTable rather than overusing syscall number unused bits.
To do that we're checking the syscall number and loading the syscall table (keeping it in %rbx/%ebx) earlier. This assumes that %rbx isn't modified in between, for instance by the eventual `SYS_arch_prctl` syscall, but I believe it is the case?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1437
We need to make sure all (important) cleanup is finished when we exit DllMain,
otherwise we might already unload krnl386 and deadlock
Since we can't have a synchronous DestroyWindow, use an extra message
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52511
Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de>
Code flow is like follows:
- DOSVM_Exit -> RtlExitUserThread -> LdrShutdownThread
- acquire loader lock
- send DLL_THREAD_DETACH to imm32
- - calls DestroyWindow on its window
- - WM_DESTROY is handled asynchonously!
- send DLL_THREAD_DETACH to krnl386.exe
- - TASK_ExitTask
- - try get win16 lock, is blocked by ime32
meanwhile, at ime32
- handles WM_DESTROY
- already have win16 lock from user32
- __wine_ime_wnd_proc (WM_DESTROY) -> imm_couninit_thread -> CoRevokeInitializeSpy
- LdrGetProcedureAddress (want CoRevokeInitializeSpy)
- try get loader_lock, is blocked
Solution is to wait in ime32 DllMain until the cleanup as happened, aka CoRevokeInitializeSpy has finished.
--
v4: imm32: Prevent deadlock on unload
https://gitlab.winehq.org/wine/wine/-/merge_requests/1456