December 2025 - Wine-gitlab

[PATCH 0/2] MR9748: Draft: msi: Implement MsiProvideAssemblyW().
by Dmitry Timoshkov (＠dmitry) 10 Feb '26

10 Feb '26

While bug 58578 depends on MsiProvideAssemblyW() my testing target is SQL Server Express 2012 (bug 42792 has a download URL). I marked this MR as a draft because the implementation doesn't seem to work: MsiProvideComponent() detects feature INSTALLSTATE_ABSENT, MSDN mentions that both MsiProvideAssembly() and MsiProvideComponent() should return ERROR_FILE_NOT_FOUND in that case, however the installer generates an exception and crashes once this error is returned. The installer calls MsiProvideAssembly() with the application context, however I investigated with Orca the problematic MSI and for the assembly specified in the MsiProvideAssembly() call there's no associated application, so it's not clear how it's supposed to behave in that case. Hans, would you mind looking at this and probably suggest the ways to proceed? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9748

4 4

[PATCH 0/1] MR9765: ws2_32 / Add stub for WSCInstallProvider64_32
by Janne Kekkonen (＠Janne) 09 Feb '26

09 Feb '26

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58853 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9765

3 4

[PATCH 0/1] MR9391: uxtheme/tests: Verify GetCurrentThemeName() returns Aero\Aero.msstyles on Windows
by nikita pushkarev (＠strudelll) 08 Feb '26

08 Feb '26

Problem Native Windows returns a theme path ending with \\Aero\\Aero.msstyles from GetCurrentThemeName(), even when “Light” is selected. Wine currently returns ...\\light\\light.msstyles which confuses some WPF installers. Windows evidence Windows 11 24H2: system.c:830: theme=L"C:\\WINDOWS\\resources\\themes\\Aero\\Aero.msstyles" Result: test passed (0 failures) (full log attached in the bug / can reattach in MR if needed) Wine behavior (before fix) theme=L"C:\\windows\\resources\\themes\\light\\light.msstyles" (test is marked todo_wine to keep CI green until the fix) This MR 1/2 uxtheme/tests: Add a conformance test that documents Windows behavior (Aero\\Aero.msstyles); mark check as todo_wine on Wine. 2/2 uxtheme: Return Aero.msstyles from GetCurrentThemeName() when Light is active, matching Windows. Notes - Minimal diff; no formatting changes. - Test passes on Windows; after the fix it also passes on Wine (todo_wine can be dropped). Add a conformance test that calls GetCurrentThemeName() and checks that the returned path ends with \\Aero\\Aero.msstyles (regardless of Light/Dark). Skip if theming is inactive. On Wine this currently returns ...\\light\\light.msstyles, so the check is wrapped in todo_wine. Tested on: - Windows 10 22H2: theme=Aero\\Aero.msstyles (passes) - Windows 11 24H2: theme=Aero\\Aero.msstyles (passes) Signed-off-by: Nikita strudelll(a)etersoft.ru -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9391

4 6

[PATCH 0/2] MR9597: Iphlpapi: Implement GetOwnerModuleFromTcpEntry, GetOwnerModuleFromTcp6Entry.
by Paul Gofman (＠gofman) 07 Feb '26

07 Feb '26

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

3 3

[PATCH 0/1] MR9713: xaudio2_7/tests: Dynamically load function XAudio2CreateWithVersionInfo.
by Bernhard Übelacker 07 Feb '26

07 Feb '26

Make the test run again with win10-1709 and before. Followup to e04f84dc4c. [Test pattern page](https://test.winehq.org/data/patterns.html#xaudio2_8:xaudio2) [Testbot run with this patch](https://testbot.winehq.org/JobDetails.pl?Key=161206) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9713

3 3

[PATCH 0/2] MR8368: libs/xml2: Import upstream release 2.13.8.
by Daniel Lehman (＠dlehman25) 04 Feb '26

04 Feb '26

import with 2 small changes: - config.h -> win32config.h - comment out deprecation to avoid warnings while preserving `xmlThrDefTreeIndentString` (for 8c792c25) https://testbot.winehq.org/JobDetails.pl?Key=158748 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8368

5 6

[PATCH v2 0/1] MR9751: Draft: gitlab: Make core files accessible as artifacts.
by Bernhard Übelacker (＠bernhardu) 04 Feb '26

04 Feb '26

All some days there is an issue with the `debian-32` gitlab job showing a segfault. But it also shows `core dumped`. This merge request is the attempt to make this core file available as artifact. Last segfault example from yesterday: https://gitlab.winehq.org/wine/wine/-/jobs/216539#L135 ``` /usr/bin/bash: line 213: 185 Segmentation fault (core dumped) wine usr/local/lib/wine/i386-windows/winetest.exe -q ``` -- v2: gitlab: Make core files accessible as artifacts. https://gitlab.winehq.org/wine/wine/-/merge_requests/9751

4 17

[PATCH v3 0/1] MR2498: msado15: Implement _Recordset Find
by Alistair Leslie-Hughes (＠alesliehughes) 03 Feb '26

03 Feb '26

Find only supports one Column to filter on. The parser for this will be the same for both Find/Filter with the only different is the Filter supports multiple columns. In trying to keep this patch small, only WSTR/BSTR/Integer have been supported. (The Common cases). -- v3: msado15: Implement _Recordset Find https://gitlab.winehq.org/wine/wine/-/merge_requests/2498

3 3

[PATCH v7 0/4] MR359: mmdevapi: copy ContainerID property from audio driver if available
by Claire (＠ClearlyClaire) 03 Feb '26

03 Feb '26

Some games with support for the haptic feedback and speaker features of the Sony DualSense controller select the controller's audio output by filtering on the ContainerId IMMDevice property to find one that matches the controller's HID's. This MR allows this information to be accessible from the IMMDevice's property store when the audio driver provides it (none for now, but I intend to add that feature to `winepulse.drv` and maybe `winealsa.drv`) This is made specific to containerId rather than supporting VT_CLSID on every property because Wine currently stores VT_BLOBs directly in the registry value, which does not allow us to safely disambiguate between VT_CLSID and VT_BLOB values when reading from registry. -- v7: mmdevapi: Invalidate ContainerID of unavailable audio devices. https://gitlab.winehq.org/wine/wine/-/merge_requests/359

7 12

[PATCH 0/1] MR8406: wined3d: Make sure swapchain can't be used after being released.
by Yuxuan Shui (＠yshui) 02 Feb '26

02 Feb '26

In wined3d_swapchain_cleanup, before decrementing the reference counts of each of the back/front buffers, we first set their swapchain to NULL, presumably to stop the current under-destruction swapchain from being used through them. But there is an oversight. When we call wined3d_texture_decref on the front_buffer, the back_buffers still have their swapchains pointing to the swapchain being destroyed. In texture_resource_unload, we call context_acquire(device, NULL, 0), note the NULL texture parameter here. When the texture parameter is NULL, wined3d_context_gl_acquire (in turn called by context_acquire) will default to using the first back buffer from the implicit swapchain of "device", which, as previously stated, has not had their swapchain set to NULL yet. From here, we reach wined3d_context_gl_activate with a texture whose swapchain is currently being destroyed. This swapchain is then assigned to "context_gl" here before being freed, leaving a dangling pointer. When this context_gl is acquired again later, we will try to access context_gl->c.swapchain->win_handle, thus complete the use-after-free cycle. This commit makes sure the swapchain pointer of ALL front and back buffers are set to NULL before decrementing their reference counts. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58325 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8406

4 7