January 2026 - Wine-GitLab - list.winehq.org

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

Feb. 8, 2026

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 v3 0/1] MR9742: mf: Prevent invalid topologies from being started.
by Bernhard Kölbl Feb. 8, 2026

Feb. 8, 2026

Signed-off-by: Bernhard Kölbl <bkoelbl(a)codeweavers.com> -- v3: mf: Prevent invalid topologies from being started. https://gitlab.winehq.org/wine/wine/-/merge_requests/9742

2 5

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

Feb. 7, 2026

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

3 3

[PATCH v3 0/4] MR9756: mmdevapi: Allow querying I{Simple,Channel}AudioVolume from IAudioSessionControl.
by Matteo Bruni (＠Mystral) Feb. 7, 2026

Feb. 7, 2026

Ancillary MR for !9755. -- v3: mmdevapi: Add some session_wrapper traces. mmdevapi: Add some traces around session retrieval. mmdevapi: Allow querying I{Simple,Channel}AudioVolume from IAudioSessionControl. https://gitlab.winehq.org/wine/wine/-/merge_requests/9756

3 6

[PATCH v4 0/3] MR9915: mmedvapi: Device name changes.
by Bernhard Kölbl Feb. 7, 2026

Feb. 7, 2026

The test in the last commit would still need an implementation, which turned out to be more complicated than the possible benefits. -- v4: mmdevapi: Adjust device names. https://gitlab.winehq.org/wine/wine/-/merge_requests/9915

3 6

[PATCH v2 0/28] MR9928: Draft: dsound: Speed up resampling.
by Anton Baskanov (＠baskanov) Feb. 7, 2026

Feb. 7, 2026

This implements a number of optimizations, in particular: - Swapping around the resampling loops in case of downsampling, allowing the FIR step to stay fixed regardless of the resampling ratio. - Rearranging the FIR array elements to make the access sequential. - Adding SSE versions of the resampling functions. Together, these amount to more than a 5x reduction of `cp_fields_resample` execution time. The quality of the resampling should be the same, or even improve slightly, due to a more precise `rem` calculation and removal of the FIR step rounding, although I haven't yet conducted any measurements. -- v2: dsound: Add a 32-bit SSE version of downsample. dsound: Add a 32-bit SSE version of upsample. This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/9928

2 4

[PATCH 0/1] MR9713: xaudio2_7/tests: Dynamically load function XAudio2CreateWithVersionInfo.
by Bernhard Übelacker Feb. 7, 2026

Feb. 7, 2026

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/1] MR9854: cmd: Add '/' to delimiters for tab-completion support.
by Thomas Csovcsity (＠thc13) Feb. 6, 2026

Feb. 6, 2026

**Improvement:** Since 'cd ../' works in wineconsole, tab completion should too. - This not like **win10 cmd**, because 'cd ../' fails there. Interestingly tab completion for 'cd ../' shows results for actual path and not for the parent folder. It fails only after enter like cd command does for using '/' instead of '\'. - wineconsole behaves more like **PowerShell on win10**, which accepts '/' as delimiter, but it replaces '/' with '\' on completion. **Before:** ![wineconsole-slash-delimiter-not-working](/uploads/45ff9b1f69ec9c5c77ddd2601910ec25/wineconsole-slash-delimiter-not-working.gif){width=600 height=380} **After:** ![wineconsole-slash-delimiter-working](/uploads/1c0b77121ee37cb62d9c727ede85744f/wineconsole-slash-delimiter-working.gif){width=600 height=380} -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9854

3 9

[PATCH 0/1] MR9874: Draft: wineandroid.drv: experimental bring-up fixes for Android 7.1.x (discussion starter)
by Twaik Yont (＠twaik) Feb. 5, 2026

Feb. 5, 2026

#### Note on authorship and language This text was translated into English and structured with the assistance of ChatGPT. The author is not a native English speaker and may struggle with written technical English; any wording issues are unintentional. #### Description This merge request is an experimental attempt to bring wineandroid.drv back to a minimally functional state on Android 7.1.x. It is primarily intended as a discussion starter rather than a final or polished solution. The current Android support appears to have bit-rotted over time, likely due to a combination of internal contract changes in Wine, toolchain and NDK evolution, and the absence of continuous Android testing. The changes proposed here aim to re-establish a working baseline and make the regressions more concrete and easier to reason about. At the moment, all changes are provided as a single patch. This is intentional: until at least one of the proposed changes is confirmed as a valid or acceptable fix, the patchset is kept consolidated to simplify iteration. Once individual changes are reviewed or agreed upon, the history can be rewritten (via force-push) to split them into logical, self-contained commits. #### Test environment and context All testing so far was performed on Android 7.1.2 x86 images from the Android-x86 project. The primary target is i386 Wine running on x86 Android userspace. Because no up-to-date official Android build scripts were available, Wine was built using Termux as an unsupported but convenient environment for rapid testing. The Java part (WineActivity and related glue code) was built with `sharedUserId = com.termux` purely for convenience (filesystem access and faster prototyping). **Termux is explicitly not considered a supported environment and is mentioned only to provide context for the testing setup.** The build uses Android NDK r29. Since the last known functional Android Wine builds, the NDK and linker behavior have changed multiple times, including symbol visibility and relocation handling. These changes appear to have directly affected several failure modes described below. There is also a known issue with wine-preloader producing excessively large binaries under recent toolchains; a workaround exists but is not included here and is mentioned only as additional context. #### Scope of changes This merge request currently modifies only Android-specific code: - `wineandroid.drv` (native code and Java glue, including WineActivity) - android-only paths in `dlls/ntdll/unix/loader.c` No non-Android platforms are affected. #### Summary of resolved issues 1. `virtual_alloc_first_teb` failure Wine frequently failed early during startup with: ``` err:virtual:virtual_alloc_first_teb wine: failed to map the shared user data: c0000018 ``` This failure was not observed on older Wine versions. It appears to be related to JNI interaction occurring too early during initialization, interfering with allocation of the shared user data region at the required fixed address. This was resolved by moving the call to `virtual_init()` earlier in `wine_init_jni()`, before JNI-related activity begins. 2. Missing exported JNI symbols The symbols `java_vm`, `java_object`, and `java_gdt_sel` were no longer visible when accessed via `dlopen`/`dlsym`. This appears to be a consequence of newer toolchain and linker behavior. The issue was resolved by explicitly exporting these symbols using `DECLSPEC_EXPORT`. 3. Desktop thread assertion during startup Wine aborted with the following assertion: ``` dlls/wineandroid.drv/window.c:519: int wait_events(int): assertion "GetCurrentThreadId() == desktop_tid" failed ``` The failure happens because `pCreateDesktop()` is now invoked before `pCreateWindow()`, while the existing code expected `desktop_tid` to be set during `pCreateWindow()`. As a result, the event waiting path may execute before `desktop_tid` is initialized. This was addressed by moving `init_event_queue()` and `start_android_device()` from `pCreateWindow()` into `pCreateDesktop()`, ensuring the event queue and device startup occur before `wait_events()` is used. 4. Recursive desktop recreation The change described above introduced a new problem: `create_desktop_window()` could be triggered repeatedly. Each Java-side content window creation/layout initialization caused additional resolution/configuration change notifications, which in turn could cause repeated desktop window recreation. This was mitigated by changing the Java/native glue so that when a window/view is being created, the code explicitly checks whether the target is the desktop window and passes this information to Java as a flag. This avoids triggering repeated content-window initialization paths during desktop recreation. 5. WineAndroid device path change Opening the device using `\\.\WineAndroid` no longer works. Switching to `\Device\WineAndroid` resolved the issue. The fix itself is simple but required for basic functionality. 6. Rendering stalls and USER lock assertion Rendering occasionally stalled or crashed with: ``` err:system:user_check_not_lock BUG: holding USER lock ``` Adding TRACE statements often caused the issue to disappear, making it difficult to debug and reproduce reliably. After extensive experimentation, it was discovered that inserting a full memory barrier: ``` __sync_synchronize(); ``` at a specific point makes the issue reliably disappear in the tested setup. This suggests a race or memory visibility/ordering problem. At this time it is unclear whether the root cause is an internal behavioral change in Wine, NDK toolchain/codegen changes, or some other interaction specific to the Android 7.1.x environment. The current change should be treated as a workaround and a starting point for further investigation rather than a definitive fix. #### Remaining issues - Window focus handling is partially broken: windows receive focus on click, but are not always raised to the front. - Despite the available desktop area being larger (e.g. 1024x696), Wine consistently reports a display resolution of 800x600. #### Limitations Wine on Android stopped functioning entirely starting with Android 8. As a result, all testing so far has been limited to Android 7.1.x. No claims are made about behavior on newer Android versions. #### Out of scope This merge request intentionally does not attempt to: - redesign IPC mechanisms - introduce new Android integration models - address Android 8+ compatibility The sole goal is to re-establish a minimally working baseline on Android 7.1.x and enable informed discussion about what regressed and how to proceed. **This is my first contribution to Wine, and I am aware that some parts of this analysis or implementation may be flawed. I would be grateful for any review comments or suggestions.** -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9874

4 6

[PATCH 0/1] MR9998: shell32: ShellExecute uses SW_SHOWDEFAULT by default
by Fan Zhou (＠zhoufan_uniontech) Feb. 5, 2026

Feb. 5, 2026

This patch applies to applications that launch processes via ShellDispatch without specifying a show mode (such as WPS PDF Editor). When no show parameter is specified, VT_EMPTY is converted to the integer 0 (i.e., SW_HIDE), causing the main window to be hidden by default. This behavior is now adjusted to use the default show mode. The modification references Microsoft’s official description of the IShellDispatch2.ShellExecute interface: "If this parameter is not specified, the application uses its default value." -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9998

2 2