November 2025 - Wine-gitlab

[PATCH 0/1] MR9533: win32u: Avoid leaking semaphore and fence exported fds.
by Rémi Bernon 19 Nov '25

19 Nov '25

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/9533

1 1

[PATCH v6 0/8] MR8812: winegstreamer: Support 2D sample buffer.
by Conor McCarthy (＠cmccarthy) 19 Nov '25

19 Nov '25

Performance issues can occur when a video output sample has a 2D buffer, because winegstreamer currently outputs only to a linear buffer, which must then be copied into the 2D buffer. Worse, a linear lock of the 2D buffer requires the current contents to be copied to a linear buffer, even when we intend to overwrite it, because MF linear buffers do not support write-only locking. -- v6: winegstreamer: Support 2D sample buffer. https://gitlab.winehq.org/wine/wine/-/merge_requests/8812

3 14

[PATCH v2 0/1] MR9512: widl: Fix MethodList value for apicontract typedefs.
by Vibhav Pant (＠vibhavp) 19 Nov '25

19 Nov '25

apicontract typedefs don't have any associated methods, so the MethodList value should be 0. -- v2: widl: Fix MethodList value for apicontract and enum typedefs. https://gitlab.winehq.org/wine/wine/-/merge_requests/9512

3 3

[PATCH v4 0/5] MR9511: Draft: server: Forbid background process window reactivation.
by Rémi Bernon 19 Nov '25

19 Nov '25

Pegasus Mail posts a WM_USER + 8991 message to its own window when it loses focus, then calls SetFocus on its window when processing this message. Several other applications have been seen calling SetWindowPos during WM_ACTIVATE message, which might also attempt to reactivate the window. That processing happens shortly after we have changed the foreground window to the desktop window, when focus is lost, then SetFocus tries to change the foreground window again. This SetFocus behavior is tested, and should work like this, but would only activate the window if the process is allowed to do so. Windows has various rules around this, and it seems to boil down to something like: * Allow taking focus if the process never was foreground, ie: when process is starting and gets initial focus on its windows. * Allow taking focus if the process was foreground but lost it recently because of a window being destroyed. * Forbid taking focus back if the process had foreground and called SetForegroundWindow explicitly to give it to another process. This doesn't implement all this rules, but rather keep rely on the host window management with some additional heuristics to avoid activating windows which lost foreground recently. This is mostly about keeping track of user input time, updating it on user input and on focus change. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58167 --- I think this should be enough to prevent spurious window reactivation, either from calls to SetWindowPos during WM_ACTIVATE messages like in https://gitlab.winehq.org/wine/wine/-/merge_requests/9398 or from calls to SetFocus from posted messages right after window deactivation as described above. Fwiw we could have tests for that, and show that this MR is fixing them but fvwm doesn't implement window minimization properly, and doesn't change focus when window is minimized, so the tests would be meaningless. -- v4: server: Forbid background process window reactivation. server: Set NULL foreground input when switching to desktop window. win32u: Introduce a NtUserSetForegroundWindowInternal call. user32/tests: Use a dedicated window instead of the desktop window. ddraw/tests: Use a dedicated window instead of the desktop window. https://gitlab.winehq.org/wine/wine/-/merge_requests/9511

1 5

[PATCH 0/7] MR9531: msado15: Reimplement Field::get_Value and Field::put_Value.
by Piotr Caban (＠piotr) 19 Nov '25

19 Nov '25

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/9531

2 7

[PATCH v3 0/5] MR9511: Draft: server: Forbid background process window reactivation.
by Rémi Bernon 19 Nov '25

19 Nov '25

Pegasus Mail posts a WM_USER + 8991 message to its own window when it loses focus, then calls SetFocus on its window when processing this message. Several other applications have been seen calling SetWindowPos during WM_ACTIVATE message, which might also attempt to reactivate the window. That processing happens shortly after we have changed the foreground window to the desktop window, when focus is lost, then SetFocus tries to change the foreground window again. This SetFocus behavior is tested, and should work like this, but would only activate the window if the process is allowed to do so. Windows has various rules around this, and it seems to boil down to something like: * Allow taking focus if the process never was foreground, ie: when process is starting and gets initial focus on its windows. * Allow taking focus if the process was foreground but lost it recently because of a window being destroyed. * Forbid taking focus back if the process had foreground and called SetForegroundWindow explicitly to give it to another process. This doesn't implement all this rules, but rather keep rely on the host window management with some additional heuristics to avoid activating windows which lost foreground recently. This is mostly about keeping track of user input time, updating it on user input and on focus change. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58167 --- I think this should be enough to prevent spurious window reactivation, either from calls to SetWindowPos during WM_ACTIVATE messages like in https://gitlab.winehq.org/wine/wine/-/merge_requests/9398 or from calls to SetFocus from posted messages right after window deactivation as described above. Fwiw we could have tests for that, and show that this MR is fixing them but fvwm doesn't implement window minimization properly, and doesn't change focus when window is minimized, so the tests would be meaningless. -- v3: server: Forbid background process window reactivation. server: Set NULL foreground input when switching to desktop window. win32u: Introduce a NtUserSetForegroundWindowInternal call. user32/tests: Use a dedicated window instead of the desktop window. ddraw/tests: Use a dedicated window instead of the desktop window. https://gitlab.winehq.org/wine/wine/-/merge_requests/9511

1 5

Re: [PATCH v4 0/1] MR9442: comctl32/treeview: check for child item before SendExpanding
by Thomas Csovcsity (＠thc13) 19 Nov '25

19 Nov '25

On Wed Nov 19 15:27:47 2025 +0000, Zhiyi Zhang wrote: > Could you add a test? Not ATM. I do not know, what prerequisites trigger this bug. Could only test it with UltraEdit, which is closed source. Explorer in wine does not trigger this bug. Hints and help with the test is appreciated. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9442#note_122942

1 0

[PATCH 0/7] MR9489: mf: Fix seeking within sample grabber.
by Brendan McGrath (＠redmcg) 19 Nov '25

19 Nov '25

This fixes seeking within sample grabber by matching Windows functionality. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9489

3 8

[PATCH 0/1] MR9529: user32: Avoid out-of-bounds read in DdeCreateDataHandle with offset (ASan).
by Bernhard Übelacker 19 Nov '25

19 Nov '25

Current implementation applies offset to the source buffer. But it looks like it has to be applied to the destination buffer. The bytes in the destination below the offset seem to get initialized with zero. [Testbot run with this patch](https://testbot.winehq.org/JobDetails.pl?Key=160951) <details> <summary>ASan report details</summary> ``` ================================================================= ==684==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000140292045 at pc 0x6ffffe8ccfac bp 0x7ffffe1feed0 sp 0x7ffffe1fef18 READ of size 5 at 0x000140292045 thread T0 #0 0x6ffffe8ccfab in memmove /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt\lib/asan/../sanitizer_common/sanitizer_common_interceptors_memintrinsics.inc:100:3 #1 0x6ffffa6dd6e4 in DdeCreateDataHandle .../wine/dlls/user32/dde_misc.c:1328 #2 0x000140061ffe in test_DdeCreateDataHandle .../wine/dlls/user32/tests/dde.c:1943 #3 0x00014005b743 in func_dde .../wine/dlls/user32/tests/dde.c:2764 #4 0x000140268dc2 in run_test .../wine/include/wine/test.h:780 #5 0x0001402687cb in main .../wine/include/wine/test.h:900 #6 0x00014026aa5a in mainCRTStartup .../wine/dlls/msvcrt/crt_main.c:62 #7 0x6ffffaf57a54 in BaseThreadInitThunk (C:\windows\system32\kernel32.dll+0x178027a54) #8 0x6ffffdcb06d6 in RtlUserThreadStart (C:\windows\system32\ntdll.dll+0x1700506d6) 0x000140292045 is located 27 bytes before global variable '"Expected non-NULL ptr\n"' defined in '.../wine/dlls/user32/tests/dde.c:1915' (0x000140292060) of size 23 '"Expected non-NULL ptr\n"' is ascii string 'Expected non-NULL ptr ' 0x000140292045 is located 0 bytes after global variable '"data"' defined in '.../wine/dlls/user32/tests/dde.c:1886' (0x000140292040) of size 5 '"data"' is ascii string 'data' SUMMARY: AddressSanitizer: global-buffer-overflow .../wine/dlls/user32/dde_misc.c:1328 in DdeCreateDataHandle ``` </details> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9529

1 1

[PATCH 0/1] MR9528: winevulkan: Avoid returning innacurate extension counts.
by Rémi Bernon 19 Nov '25

19 Nov '25

We need to adjust the extension count to take the extra client-side extension into account but we did it in an opportunistic way, adjusting it the maximum possible count when no buffer is provided, then returning a lower number once we were able to filter the extension list. It's been reported to be confusing, so this makes sure the returned extension count is always correct, by requesting the host extensions to an internal buffer. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9528

1 1