The serie intent is to fix unexpected paths in module's list:
This happens:
- when running under old / (new) wow64
- when main module is located under the syswow64 directory
- the 32 bit modules are stored in LdrData (and then exposed through
a couple of ways) under syswow64 (they are normally stored under
system32, letting the redirection come into play when needed)
This triggers a couple of errors in winetest (as we're using
c:\windows\syswow64\msinfo32.exe in many tests to trigger a wow64
process from a winetest program).
This is the fix awaited in MR!2497.
@julliard: I'm not 100% happy with the fix itself by reintroducting
ref to the redirected DLLs in ntdll/PE but couldn't find a better idea.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2578
This MR contains two somewhat related commits/fixes for regressions that were made apparent in https://bugs.winehq.org/show_bug.cgi?id=54781.
1. The adapter ids used by the host and settings handlers are not guaranteed to be compatible, so ensure we are using the proper id with each
handler.
Note that although the possibly incompatible id was already used in `settings_handler.get_modes()` before, the settings handler was ignoring it anyway for `get_modes()` in the case it was really incompatible (e.g., using host handler xrandr 1.4, settings handler xrandr 1.0), . The problem manifests now since we are additionally calling `settings_handler.get_current_mode()` which does check the id value (e.g., in xrandr 1.0 to differentiate primary vs non-primary).
2. The virtual desktop get_current_mode() implementation recurses into win32u (through NtUserGetPrimaryScreenRect) causing a deadlock if we call it from within UpdateDisplayDevices. There is a way to avoid the deadlock if we get the current_modes before calling add_gpu(), but we don't need to get and update the win32u current/registry in the virtual desktop case anyway, so skip the call completely instead.
--
v4: winex11.drv: Use a distinct type for the settings id.
winex11.drv: Do not call desktop get_current_mode() from UpdateDisplayDevices.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2593
I'm not 100% sure all of them are the same thing, and I can only reproduce one failure locally, but I suspect they might. In any case if the foreground window is wrong it's simply not going to work.
--
v2: dinput/tests: Mark some tests as flaky to workaround fvwm bug.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2599