December 2025 - Wine-gitlab

[PATCH v2 0/2] MR9648: dlls/wmp: Implement the OLEIVERB_SHOW needed by the software Alldup
by pan hui (＠panhui) 05 Dec '25

05 Dec '25

The software "Alldup" uses OLEIVERB_SHOW, but OLEIVERB_SHOW is not implemented in oleobj.c, resulting in errors when running the Alldup via Wine. -- v2: add test for OLEIVERB_SHOW https://gitlab.winehq.org/wine/wine/-/merge_requests/9648

2 2

[PATCH 0/3] MR9689: qcap: Implement GetFrameRateList().
by Elizabeth Figura (＠zfigura) 05 Dec '25

05 Dec '25

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

2 3

[PATCH 0/1] MR9688: faudio: Make sure at least one wavebank notification gets allocated (ASan).
by Bernhard Übelacker 05 Dec '25

05 Dec '25

With the update of faudio in d4479c27 I received below ASan report. It looks like the `wavebank_notifications_capacity` stays at zero, therefore a zero byte allocation is requested. CC: @zfigura - [ASan gitlab CI 32-bit report](https://gitlab.winehq.org/bernhardu/wine/-/jobs/215013#L5541) - [ASan gitlab CI 64-bit report](https://gitlab.winehq.org/bernhardu/wine/-/jobs/215014#L5831) - [Test patttern page, showing daily gitlab runs of xactengine3_7:xact3 failing](https://test.winehq.org/data/patterns.html#xactengine3_7:xact3) <details> <summary>ASan report with full symbols</summary> ``` ================================================================= ==312==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7ea2933e0690 at pc 0x6ffffdd0ec1f bp 0x7ffffe1ff280 sp 0x7ffffe1ff2c8 WRITE of size 1 at 0x7ea2933e0690 thread T0 #0 0x6ffffdd0ec1e in FACTAudioEngine_CreateStreamingWaveBank .../wine/libs/faudio/src/FACT.c:578 #1 0x6ffffdd03464 in IXACT3EngineImpl_CreateStreamingWaveBank .../wine/dlls/xactengine3_7/xact_dll.c:1280 #2 0x000140002c95 in test_notifications .../wine/dlls/xactengine3_7/tests/xact3.c:392 #3 0x0001400011bb in func_xact3 .../wine/dlls/xactengine3_7/tests/xact3.c:1576 #4 0x00014001af82 in run_test .../wine/include/wine/test.h:780 #5 0x00014001a9fc in main .../wine/include/wine/test.h #6 0x00014001cb1a in mainCRTStartup .../wine/dlls/msvcrt/crt_main.c:62 #7 0x6fffffc67a64 in BaseThreadInitThunk (C:\windows\system32\kernel32.dll+0x178027a64) #8 0x6fffffde0876 in RtlUserThreadStart (C:\windows\system32\ntdll.dll+0x170050876) 0x7ea2933e0690 is located 0 bytes inside of 1-byte region [0x7ea2933e0690,0x7ea2933e0691) allocated by thread T0 here: #0 0x6ffffe8bde13 in HeapAlloc /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt\lib/asan/asan_malloc_win.cpp:230:3 #1 0x6ffffd02dca9 in allocator_Realloc .../wine/dlls/combase/malloc.c:211 #2 0x6ffffd02d3ba in IMalloc_Realloc .../obj\include\objidlbase.h:1336 #3 0x6ffffd02d370 in CoTaskMemRealloc .../wine/dlls/combase/malloc.c:399 #4 0x6ffffdd010e1 in XACT_Internal_Realloc .../wine/dlls/xactengine3_7/xact_dll.c:1661 #5 0x6ffffdd0ea8f in FACTAudioEngine_CreateStreamingWaveBank .../wine/libs/faudio/src/FACT.c:574 #6 0x6ffffdd03464 in IXACT3EngineImpl_CreateStreamingWaveBank .../wine/dlls/xactengine3_7/xact_dll.c:1280 #7 0x000140002c95 in test_notifications .../wine/dlls/xactengine3_7/tests/xact3.c:392 #8 0x0001400011bb in func_xact3 .../wine/dlls/xactengine3_7/tests/xact3.c:1576 #9 0x00014001af82 in run_test .../wine/include/wine/test.h:780 #10 0x00014001a9fc in main .../wine/include/wine/test.h #11 0x00014001cb1a in mainCRTStartup .../wine/dlls/msvcrt/crt_main.c:62 #12 0x6fffffc67a64 in BaseThreadInitThunk (C:\windows\system32\kernel32.dll+0x178027a64) #13 0x6fffffde0876 in RtlUserThreadStart (C:\windows\system32\ntdll.dll+0x170050876) SUMMARY: AddressSanitizer: heap-buffer-overflow .../wine/libs/faudio/src/FACT.c:578 in FACTAudioEngine_CreateStreamingWaveBank ``` </details> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9688

1 1

[PATCH v24 0/10] MR7797: ntdll: Wait for all pending operations to be cancelled in NtCancelIoFile[Ex]().
by Matteo Bruni (＠Mystral) 05 Dec '25

05 Dec '25

This fixes Trials Fusion often crashing when disconnecting a controller while there are more still connected. -- v24: ntoskrnl/tests: Use the 'Nt' version of the CancelIo APIs. ntoskrnl/tests: Test the thread ID the cancellation routine runs from. ntoskrnl/tests: Add more cancellation tests. ntoskrnl/tests: Fix tests on current Windows 10 / 11. ntdll/tests: Test IOSB values of the cancel operation. ntdll/tests: Add more NtCancelIoFile[Ex]() tests. ntdll: Wait for all asyncs to handle cancel in NtCancelIoFile(). server: Factor out a cancel_async() function. server: Introduce a find_async_from_user helper. ntdll: Factor out a cancel_io() function. https://gitlab.winehq.org/wine/wine/-/merge_requests/7797

4 14

[PATCH v2 0/2] MR9054: winebth.sys: Remove redundant locks + Fix potential deadlocks while performing operations that block on the DBus event loop.
by Vibhav Pant (＠vibhavp) 05 Dec '25

05 Dec '25

Disconnecting and removing remote devices hold device_list_cs before blocking on the DBus event loop, which may cause a deadlock if we receive a message from BlueZ whose handler also attempts to enter device_list_cs (Like BLUETOOTH_WATCHER_EVENT_TYPE_DEVICE_PROPERTIES_CHANGED). To fix this, the device/radio handle is duplicated once found, device_list_cs is released, and the DBus method call is made using the duplicate handle(s), which are then freed normally. Also, replace the two locks in `bluetooth_radio` with `device_list_cs` instead. -- v2: winebth.sys: Fix potential deadlocks while performing operations that block on the DBus event loop. winebth.sys: Unify critical sections used for bluetooth_radio. https://gitlab.winehq.org/wine/wine/-/merge_requests/9054

3 4

[PATCH 0/1] MR9637: wined3d: Create / release the window DCs with the swapchains.
by Rémi Bernon 05 Dec '25

05 Dec '25

Wine-Bug: http://bugs.winehq.org/show_bug.cgi?id=58491 This fixes a regression introduced with a085746bbe3594e4ea01ea578823383e6447b6b6, as contrary to what I thought wined3d aren't specific to a given window but may be used alternatively on different windows, with `wined3d_context_gl_update_window` called when they switch. This causes DCs to be released / acquired every time window is switched and it triggers destruction and recreation of the underlying D3D OpenGL drawables. Keeping the DCs with the swapchains is probably a better fit anyway, and they already need some for fallback GDI blits. The GL contexts does not own its DC anymore, but simply uses either its active swapchain DC or the device backup DC. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9637

2 2

[PATCH 0/1] MR9685: wineusb.sys: Use the full port path to avoid collisions with identical devices connected to other hubs on the same bus.
by Ivo Ivanov (＠logos128) 04 Dec '25

04 Dec '25

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

2 1

[PATCH v4 0/3] MR9585: win32u: Introduce a D3DKMT escape code to set fullscreen present rect. (1/2)
by Rémi Bernon 04 Dec '25

04 Dec '25

These calls are Wine-specific and expected to fail on Windows, as the escape codes and parameter combinations are likely invalid there. There doesn't seem to be any mechanism to do this otherwise. When a window presentation rect has been set, the window is meant to be presented to that rect on screen exactly, mapped to physical coords. Then this also has the following side effects: * In exclusive fullscreen mode, GDI drawn child windows are clipped out of the rendered screen, regardless of the normal clipping rules. * The window position and size changes should be ignored wrt its visible area, and in particular the window should not be unmapped even if its Win32 rect is moved to an invisible location. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58844 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58443 --- This only introduces the mechanism and calls it from Wine D3D side. The side effects will be implemented later in win32u and the user drivers. This is necessary both for Command & Conquer 2, which has dialog child windows covering the entire game window while using WS_CLIPCHILDREN, and for Fallout 3 which does a bogus call sequence after window restoration which moves the window outside of screen area and causes its window and client rects to be empty: ``` SetRect(&rect, 0, 0, width, height); AdjustWindowRectEx(&rect, style, FALSE, 0); SetWindowPos(hwnd, 0, rect.left, rect.bottom, rect.right - rect.left, rect.top - rect.bottom, 0); ``` We need either this kind of mechanism (which could be later changed to some D3DKMTPresent call, but it would require a lot more work and I'd like to fix those regressions before the release), or to hook the window proc like modern Windows seems to be doing as tested in !9549 (and more tests suggest that invalid window moves are also now inhibited and corrected on modern Windows). -- v4: wined3d: Use the present rather than client rect when fullscreen. wined3d: Set the window present rect when entering fullscreen mode. win32u: Introduce a D3DKMT escape code to set fullscreen present rect. https://gitlab.winehq.org/wine/wine/-/merge_requests/9585

2 6

[PATCH 0/1] MR9626: wined3d: Create cube views for cube textures in wined3d_texture_acquire_identity_srv().
by Henri Verbeet (＠hverbeet) 04 Dec '25

04 Dec '25

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

3 2

[PATCH 0/1] MR9653: wined3d: Remove now unnecessary pixel format restoration.
by Rémi Bernon 04 Dec '25

04 Dec '25

wglSetPixelFormatWINE now sets the internal pixel format privately on each DC, and it is unnecessary to restore the window pixel format. That call is even undesirable as it allocates and destroys a private OpenGL drawable when the DC is acquired, its internal pixel format is set, and the DC is then immediately released. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9653

2 4