December 2025 - Wine-GitLab

[PATCH 0/1] MR4709: winedbg: Show all loaded modules in automatic backtrace.
by Bernhard Übelacker Jan. 10, 2026

Jan. 10, 2026

This patch should change the module list in the automatic backtraces from "info share" to "info wow share". That way all loaded modules should get listed instead of just the process native ones. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4709

3 5

[PATCH v7 0/1] MR3410: advpack: Add nullcheck for parameter that can be null (Coverity)
by Fabian Maurer (＠DarkShadow44) Jan. 8, 2026

Jan. 8, 2026

-- v7: advpack: Add nullchecks for parameters that can be null (Coverity) https://gitlab.winehq.org/wine/wine/-/merge_requests/3410

4 8

[PATCH v7 0/3] MR9789: winebus: Use smallest report size for joystick axis
by SeongChan Lee (＠foriequal0) Jan. 6, 2026

Jan. 6, 2026

Some games don't handle 32-bit sized joystick axes well. Assetto Corsa Rally, which was released a month ago as an early access and is still v0.1, is a recent example. The proof of concept 16-bit patch resolves the problem for many users and hardware on Linux, (https://github.com/ValveSoftware/Proton/issues/9220#issuecomment-3647591465) and users with open-source hardware confirmed the behavior of the game on Windows. Since it's the case that the game is non-compliant while the wine is perfectly compliant, we might be able to push and wait for the developer to release the fix, but I believe that the fix will also help to improve compatibility for some old, non-maintained, non-compliant games. -- v7: winebus: Use smallest report size for unsigned axis too winebus: Use 16-bit relative axis range for bus_sdl winebus: Use smallest report size for joystick axis https://gitlab.winehq.org/wine/wine/-/merge_requests/9789

3 5

[PATCH 0/1] MR9841: winex11.drv: Don't send -1 fullscreen monitor indices to window managers.
by Zhiyi Zhang (＠zhiyi) Jan. 5, 2026

Jan. 5, 2026

Fix a regression from 3bea06b8. This partly reverts 6a2e414d, which introduced this bug initially. With 3bea06b8, it becomes much more likely that indices (-1, -1, -1, -1) got sent to window managers. This can happen, for example, a game with a 1920x1080 window changes the display resolution to 3840x2160, then changes the window size to 3840x2160. After the resolution change and before the window size change, xinerama_get_fullscreen_monitors() will return monitor indices (-1, -1, -1, -1) because 1920x1080 is not fullscreen. While sending a _NET_WM_FULLSCREEN_MONITORS client message with fullscreen monitor indices (-1, -1, -1, -1) clears the _NET_WM_FULLSCREEN_MONITORS property for a window on KWin, it can also make the window to disappear and lose focus. See KWin X11Window::fullscreenMonitorsArea()[1] and X11Window::updateFullscreenMonitors()[2]. Note that QRect is constructed with an empty rect at the beginning of X11Window::fullscreenMonitorsArea(). So fullscreen monitor indices (-1, -1, -1, -1) will produce an empty rect for moveResize() in X11Window::updateFullscreenMonitors() and cause the window to disappear. While indices (-1, 0, 0, 0) might work, I think it's better not to change _NET_WM_FULLSCREEN_MONITORS when the window is not fullscreen because removing the property is not part of any standard. [1]: https://invent.kde.org/plasma/kwin-x11/-/blob/v6.5.4/src/x11window.cpp?ref_… [2]: https://invent.kde.org/plasma/kwin-x11/-/blob/v6.5.4/src/x11window.cpp?ref_… Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59180 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9841

3 2

[PATCH 0/2] MR9710: winegstreamer: Read input in chunks of 256KiB instead of 512KiB.
by Charlotte Pabst (＠CharlottePabst) Jan. 5, 2026

Jan. 5, 2026

Supersedes !8183. JR East Train Simulator's IMFByteStream implementation relies on the following two properties: - Reads are always aligned on a 256KiB boundary. - Reads are never larger than 256KiB. When chunking was initially benchmarked[1], a chunk size of 512KiB only performed marginally better than 256KiB, so this change has a negligible performance impact while being more correct. I'm testing using a WAV handler here because it's easy to create the data for it in memory (avoids including a large video file in git), but the same behavior can be observed with other handlers, such as MP4. [1] https://gitlab.winehq.org/wine/wine/-/merge_requests/2390#note_27314 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9710

4 4

[PATCH 0/1] MR9838: opengl32: Avoid leaking memory on error paths (Coverity).
by Sven Baars (＠sbaars) Jan. 5, 2026

Jan. 5, 2026

Fixes 11728e0a9c58f1b7a8d320b05f1ce40e4fa3c790. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9838

3 2

[PATCH v4 0/2] MR9822: Fix possible EA launcher hangs.
by Zhiyi Zhang (＠zhiyi) Jan. 2, 2026

Jan. 2, 2026

Registering window classes in DllMain() is prone to deadlocks. Tests show that comctl32 window classes should probably be registered in RegisterClassNameW(). Fix possible EA launcher hangs due to deadlocks. A deadlock can happen, like the following, based on Tim Clem's findings. Say there are two threads, T1 and T2. T1: does some COM stuff that results in registering the window class OleMainThreadWndClass.\ T1: NtUserRegisterClassExWOW() does get_desktop_window(). Because this is not a built-in class.\ T1: doesn't yet have a desktop window, so it makes one and calls register_builtin_classes().\ T1: starts the pthread_once in register_builtin_classes() to actually register the classes.\ T1: starts calling NtUserRegisterClassExWOW() with its classes.\ T2: loads comctl32.dll, calls its PROCESS_ATTACH. It grabs the loader lock.\ T2: comctl32's DllMain starts registering its classes.\ T2: comctl32's attempts to register classes also call get_desktop_window().\ T2: get_desktop_window hits the pthread_once in register_builtin_classes() and starts waiting for T1 to finish it.\ T1: some built-in class registration results in a LoadImageW call for a class's cursor.\ T1: LoadImage has to grab a resource, so it tries to grab the loader lock.\ T1: the loader lock is held by T2. Deadlock; T2 is waiting on T1, which is waiting on T2. -- v4: comctl32: Register window classes in RegisterClassNameW() instead of DllMain(). comctl32/tests: Add more RegisterClassNameW() tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/9822

3 5

[PATCH v4 0/5] MR9843: wtsapi32: Fix session id and desktop handling when using CreateProcessAsUserW with tokens from WTSQueryUserToken
by Katharina Bogad (＠hackathi) Dec. 31, 2025

Dec. 31, 2025

This Merge request resolves [Wine-Bug #58588](https://bugs.winehq.org/show_bug.cgi?id=58588). The underlying problem was that services started on their own, non-interactive winstation, but within the current user's session. This is trivially not the case for system services on Windows: they run, by design, in other user contexts (e.g. NTAUTHORITY\SYSTEM). Whenever a service wants to start a process within another user's graphical session, it needs to set the session id to the correct value. This may be done using the WTS API. This MR implements this functionality in a (hopefully) wine-compatible way: 1. Patch wineserver so tokens can be transferred to other sessions 2. Implement NtSetInformationToken for TokenSessionId 3. Change the session of non-interactive services to session 0 (from the default session 1) in addition to setting their desktop to `__wineservice_winstation\Default` 4. Let CreateProcessAsUserW reset the desktop to the default value `__winsta0\Default` if the session of the to-be-created process is not a service session. This avoids implementing all user and session handling in-depth while still allowing the underlying functionality to work. A real-world user of this mechanism is the Dassault 3DEXPERIENCE launcher, which runs as a system service and wants to open interactive child processes within a user's scope. -- v4: kernelbase: Let CreateProcessInternalW overwrite the desktop if needed services: start services with session id 0 wtsapi32: Make WTSQueryUserToken return a token with correct session id ntdll: Implement NtSetInformationToken for TokenSessionId server: Allow changing of session id for process tokens https://gitlab.winehq.org/wine/wine/-/merge_requests/9843

2 6

Re: [PATCH 0/0] MR9844: user32: Remove unused todo_wine handling from listbox test. - closed
by James Hawkins (＠truiken) Dec. 31, 2025

Dec. 31, 2025

This merge request was closed by James Hawkins. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9844

1 0

[PATCH v3 0/5] MR9843: wtsapi32: Fix session id and desktop handling when using CreateProcessAsUserW with tokens from WTSQueryUserToken
by Katharina Bogad (＠hackathi) Dec. 31, 2025

Dec. 31, 2025

This Merge request resolves [Wine-Bug #58588](https://bugs.winehq.org/show_bug.cgi?id=58588). The underlying problem was that services started on their own, non-interactive winstation, but within the current user's session. This is trivially not the case for system services on Windows: they run, by design, in other user contexts (e.g. NTAUTHORITY\SYSTEM). Whenever a service wants to start a process within another user's graphical session, it needs to set the session id to the correct value. This may be done using the WTS API. This MR implements this functionality in a (hopefully) wine-compatible way: 1. Patch wineserver so tokens can be transferred to other sessions 2. Implement NtSetInformationToken for TokenSessionId 3. Change the session of non-interactive services to session 0 (from the default session 1) in addition to setting their desktop to `__wineservice_winstation\Default` 4. Let CreateProcessAsUserW reset the desktop to the default value `__winsta0\Default` if the session of the to-be-created process is not a service session. This avoids implementing all user and session handling in-depth while still allowing the underlying functionality to work. A real-world user of this mechanism is the Dassault 3DEXPERIENCE launcher, which runs as a system service and wants to open interactive child processes within a user's scope. -- v3: kernelbase: Let CreateProcessInternalW overwrite the desktop if needed services: start services with session id 0 https://gitlab.winehq.org/wine/wine/-/merge_requests/9843

2 5