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

[PATCH v14 0/8] MR1074: Draft: ntdll: Improve Valgrind and GDB integration.
by Rémi Bernon May 31, 2026

May 31, 2026

Valgrind support requires a fork, which I've published to https://gitlab.winehq.org/rbernon/valgrind. The fork implements loading DWARF debug info from PE files, instead of the old and broken upstream PDB support. I've tried to upstream these changes a long time ago but didn't receive any feedback. I think we could maybe consider keeping a fork, which I'm happy to maintain, as the changes aren't too large. We may want to investigate adding 32-on-64 support, which may require a bit more changes (to VEX specifically, because its amd64 guest doesn't support segment register manipulation). The changes here are not all related to Valgrind, and I'll create separate MR for those which may make sense independently from Valgrind / GDB. Also included is a suppression file to silent some annoying false positives, many of which are coming from the cross-stack accesses during syscalls, which are confusing Valgrind's stack heuristics. One can try this out with something like: `WINELOADERNOEXEC=1 valgrind --suppressions=tools/valgrind.supp wine64/loader/wine64 wine64/programs/winecfg/winecfg.exe` -- v14: ntdll: Avoid marking freed block header as undefined for valgrind. ntdll: Force HEAP_TAIL_CHECKING_ENABLED flag with valgrind. ntdll: Fix valgrind notifications from ntdll.so. ntdll: Import valgrind headers for PE side ntdll. DEBUG: ntdll: Don't use preloader when running on valgrind. tools: Add gdbunwind.py script with a syscall unwinder. ntdll: Maintain a PE module link map and expose it to GDB. loader: Expose the standard debugging symbols for GDB. https://gitlab.winehq.org/wine/wine/-/merge_requests/1074

5 15

[PATCH v5 0/6] MR9332: combase: Implement RoOriginateError.
by Vibhav Pant (＠vibhavp) May 29, 2026

May 29, 2026

-- v5: combase: Add semi-stub for RoOriginateLanguageException. combase: Implement RoOriginateError(W) and GetRestrictedErrorInfo. combase: Implement Ro{Get,Set}ErrorReportingFlags. combase/tests: Add tests for GetRestrictedErrorInfo. combase/tests: Add tests for RoOriginateError(W) and RoOriginateLanguageException. https://gitlab.winehq.org/wine/wine/-/merge_requests/9332

3 8

[PATCH 0/1] MR10613: winemac: Handle reset parameter in ClipCursor.
by Feifan He (＠Feifan) May 29, 2026

May 29, 2026

At the moment, `ClipCursor()` sent to winemac with parameter `reset`=1 is ignored. This doesn't seem to match other drivers' behavior (e.g. winex11 does unclip if `reset`=1, and winewayland simply doesn't care about the value). It causes problem in following steps: - App (typically a game) enters fullscreen, with a display mode change. - Display mode changes, triggering cursor clipping for fullscreen. - App then leaves fullscreen, supposed to have cursor clipping reset, _but nothing happened_. - UNEXPECTED BEHAVIOR 1: Cursor remains confined in windowed mode. - App enters fullscreen again, with a display mode change identical to previous one. - UNEXPECTED BEHAVIOR 2: Clip rect shrinks to previous size of windowed mode, instead of fullscreen size. The second unexpected behavior is actually a side effect of the first one. Currently `[NSWindow setMouseConfinementRect]` is used to implement cursor clipping, and it doesn't handle window resizing "properly": the clip rect always becomes the minimum of size before and after resizing. Interestingly when app enter fullscreen again, a second `ClipCursor()` will be sent to winemac and overwrite clip rect (unclip and clip again), but it can still be skipped if the clip rect is identical to the previous one. Anyway these won't happen if `reset` is properly handled in the first place. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10613

5 5

[PATCH v4 0/10] MR10180: Desktop Window Manager (DWM) Overlay and Composition Support
by Namo Nath (＠namoninja) May 28, 2026

May 28, 2026

## Overview This patchset introduces support for Desktop Window Manager (DWM) APIs—specifically `DwmExtendFrameIntoClientArea` in `dwmapi` for region-based cutouts and glass effects. It patches the `dwmapi` stub and resolves issues with transparency, input routing, and Z-order management for cross-process Windows overlays on Linux for both X11 and Wayland. This project originated as a side project and direct solution to a long-standing issue with the dwmapi stub. It was a steep learning curve and a significant step forward from basic compositor tweaks. While I have invested significant effort into adhering to Wine's architectural standards and documenting my findings, my knowledge of Wine internals and general graphics development is limited. Some patches required a middle-ground compromise due to architectural limitations in Wayland. I am submitting this as a working, well-documented proof-of-concept and as a handover for further review, refinement, and hopefully integration by more experienced developers. This proposal introduces a best-effort attempt at an upstream-compliant implementation to bridge Windows composition syscalls (`dwmapi.dll`) directly to native Linux display protocols. Historically, users have relied on external bash scripts, custom window manager rules, external `.dll` injections, or compositing workarounds (like pixel shaders to remove black backgrounds) to achieve partial functionality. The goal of this patchset is to provide native support for these DWM features, eliminating the need for external interventions. ## Key Features Implemented * **Core Infrastructure:** Plumbing for `NtUserSetWindowDwmConfig` from `dwmapi` down to the user drivers. * **X11 Driver:** Implemented dynamic 32-bit ARGB visual upgrades upon DWM Glass requests and XShape region-based cutout features. * Mapped `WS_EX_TRANSPARENT` to empty `XShape` masks for click-through input routing. * Resolve Z-Order priority via `_NET_WM_STATE_ABOVE`. * **Wayland Driver:** Implemented a dual-path DWM masking strategy (CPU Alpha Matrix for GDI layers, `glScissor` for OpenGL hardware subsurfaces) alongside ARGB late-binding. * Synchronized physical DWM cutout margins and empty input regions across `wl_surface` hierarchies. * Implemented `zxdg_foreign_v2` to share surface handles via 16-bit Win32 Global Atoms, delegating Win32 overlay Z-order management to the Wayland compositor. * Added Z-order sniffing and geometry preservation to prevent compositor crashes during rapid Win32 `SW_HIDE`/`SW_SHOW` toggles. * **Vulkan/win32u:** Added native swapchain invalidation (`VK_ERROR_OUT_OF_DATE_KHR`) via an asynchronous driver callback to support applications that late-bind DWM transparency after initial Vulkan setup. ## Testing & Reference Documentation I have comprehensively documented the entire project, detailing the architecture, implementations, and alternatives, along with build, regression, and project-specific test tools in a centralized custom repository. I highly recommend checking out my supplementary repository for the project - [dwm-overlays](https://gitlab.com/namoninja/wine-custom/-/tree/main/projects… - and reading the [`README.md`](https://gitlab.com/namoninja/wine-custom/-/blob/main/projects/dwm-overlays/README.md) for full technical details and scope. Tested successfully with: * **DWM Tester (Internal tool):** Validated against a matrix of GDI, OpenGL, region cutouts, glass effects, input routing, and focus. Tested for regressions. * **GW2TacO (C++):** Validated legacy GDI fallback path, transparency, Z-order, WH_MOUSELL hooks, and aggressive `SetWindowPos` calls. * **Blish HUD (.NET/C#):** Validated DXVK/Vulkan path, late ARGB binding, input, Z-order, and Vulkan/DXVK swapchain recreation. These overlays served as optimal test candidates because they utilize aggressive methodologies, such as high frequency `SetWindowPos` calls and omitting `WS_EX_LAYERED`, `WS_EX_TOPMOST`, or `GW_OWNER` during initialization. While Wine implementation is not supposed to accommodate workarounds for non-standard app behavior, my objective stance on this is basic compatibility: if it functions natively on Windows, it should function under Wine. Bridging this expectation to Wayland's strict surface isolation protocols along with Wine's upstream standards, presented a significant challenge. ## Patch Sequence Here is a summary of the implementations along with a (subjective) assessment of how well aligned the concepts are with upstream. Deviations were introduced only to navigate limitations and are isolated to `DwmExtendFrameIntoClientArea` upgrade requests to prevent side effects during standard operations. 1. `win32u`: Add NtUserSetWindowDwmConfig syscall. 1. **:green_square: Clean/standard -** Standard Win32 syscall routing through `gdi_driver`. Adheres to Wine's architecture. 2. `winex11.drv`: Implement SetWindowDwmConfig for opaque regions. 1. **:green_square: Clean/standard** - Utilizes standard `XShape` protocol logic to manage bounding and input regions. 3. `winex11.drv`: Support ARGB visuals for DWM glass effect. 1. **:yellow_square: Pragmatic/deviation -** Dynamic visual upgrades during runtime deviate from static X11 visual assumptions but are implemented safely without spoofing. 4. `winex11.drv`: Implement click-through input routing for transparent windows. 1. **:green_square: Clean/standard -** Proper application of `XShape` empty input masking to achieve `WS_EX_TRANSPARENT` behavior. 5. `winex11.drv`: Resolve overlay Z-Order priority via \_NET_WM_STATE_ABOVE. 1. **:yellow_square: Pragmatic/deviation -** Forces `_NET_WM_STATE_ABOVE` for DWM glass windows to bypass X11 Window Manager heuristics, which frequently silently drop late `SetWindowPos(HWND_TOPMOST)` requests from unfocused or input-transparent windows. 6. `winewayland.drv`: Implement ARGB late-binding and DWM extended frame support. 1. **:yellow_square: Pragmatic/deviation -** CPU matrixing is inefficient but necessary; Wayland's source-over model physically prevents GDI from cropping OpenGL layers, mandating the `glScissor` intervention. 7. `winewayland.drv`: Implement wl_surface input regions for transparency and DWM. 1. **:green_square: Clean/standard -** Synchronizes physical cutout margins and empty input regions across both the toplevel and OpenGL subsurface layers. 8. `winewayland.drv`: Implement cross-process window hierarchy via zxdg_foreign_v2. 1. **:green_square: Clean/standard -** Memory-safe implementation of Wayland protocols for cross-process surface linking. 9. `winewayland.drv`: Stabilize cross-process overlay lifecycles and parenting. 1. **:yellow_square: Pragmatic/deviation -** Heuristic sniffing bridges the gap for Win32 overlays lacking explicit parents. Latch logic mitigates cross-process mapping race conditions. 10. `win32u`: Implement dynamic ARGB Vulkan swapchain recreation. 1. **:yellow_square: Pragmatic/deviation -** Relies entirely on native Vulkan invalidation. Eliminates `NtUserGetProp` IPC blocking and generic format spoofing. Injects VK_ERROR_OUT_OF_DATE_KHR during image acquisition to force client frameworks (e.g., DXVK) to reconstruct swapchains, allowing the injection of PRE_MULTIPLIED alpha configurations for late-bound transparency. ## Final Comments Should this patchset not align with upstream goals, I am happy for it to be evaluated for `wine-staging`, however, I was unable to find a way to request a PR in that repository. The full patchset is available in my custom repository. I am aware there may be areas that still require refinement. While I attempted to maintain atomic commits and follow correct procedures, I am relatively new to the complexity of a project of this scale and to Git collaboration in general, so I hope my rebase is clean and merge request correct. I have tested and patched any regressions I could find, but I could have missed some. I could only test this to the limitations of my own time and hardware, and not as in-depth as the wider community can. I would have preferred to refine this further and expand on other features, but due to time constraints, this is as far as I can take the implementation. I present it as a handover, or at the minimum, as a technical blueprint for future developers. Thank you to all the Wine developers for maintaining such an incredible project and for the opportunity to learn and contribute. -- v4: win32u: Implement dynamic ARGB Vulkan swapchain recreation. winewayland.drv: Stabilize cross-process overlay lifecycles and parenting. winewayland.drv: Implement cross-process window hierarchy via zxdg_foreign_v2. winewayland.drv: Implement wl_surface input regions for transparency and DWM. winewayland.drv: Implement ARGB late-binding and DWM extended frame support. https://gitlab.winehq.org/wine/wine/-/merge_requests/10180

6 18

[PATCH 0/1] MR7591: Improve performance and precision of parse_numeric_literal() for doubles
by Carsten Waechter (＠toxieainc) May 21, 2026

May 21, 2026

..and improve performance and precision of parse_numeric_literal() for doubles, and replace artificial (INT_MAX/100) border conditions with the true +/- 308 10^308 is the largest representable power of 10 in double -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7591

7 14

[PATCH v2 0/2] MR6760: msi: Make MsiInstallProductW open msi readonly
by Fabian Maurer (＠DarkShadow44) May 20, 2026

May 20, 2026

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57343 This is what the Java JRE installer does: - It calls MsiInstallProductW - this opens the msi read/write - The msi runs installer.exe - installer.exe tries to open the msi readonly -- v2: msi: Make MsiInstallProductW open msi readonly msi/tests: Add test for MsiOpenDatabaseA during MsiInstallProductA https://gitlab.winehq.org/wine/wine/-/merge_requests/6760

6 12

[PATCH v9 0/2] MR9567: winegstreamer: Refactor WMSyncReader to use DMOs internally.
by Yuxuan Shui (＠yshui) May 20, 2026

May 20, 2026

-- v9: winegstreamer: Refactor WMSyncReader to use DMOs internally. winegstreamer: Fix leakage of media type in IWMOutputMediaProps. https://gitlab.winehq.org/wine/wine/-/merge_requests/9567

5 14

[PATCH 0/2] MR10535: mfreadwrite: Rescale video frames based on aspect ratio when processing is enabled.
by Yuxuan Shui (＠yshui) May 20, 2026

May 20, 2026

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

5 9

[PATCH 0/2] MR10712: wineandroid: fix desktop sizing and repaint on resolution changes
by Twaik Yont (＠twaik) May 19, 2026

May 19, 2026

This series fixes two related issues in wineandroid affecting desktop initialization and repaint behavior when using the virtual desktop mode. First, launching explorer.exe with an empty desktop size ("/desktop=shell,,android") does not behave as intended on wineandroid. When the size is omitted, explorer attempts to determine the desktop resolution via get_default_desktop_size(). If no matching registry entry is found, it falls back to a hardcoded default (typically 800x600). Later, even if the wineandroid backend sets the correct display size through pCreateDesktop, explorer overrides it again during initialize_display_settings(), restoring the default resolution. As a result, the desktop ends up stuck at 800x600 regardless of the actual display size reported by the backend. To address this, the desktop is now launched with a size of "-1x-1". This value is accepted by parse_size(), but does not correspond to a valid resolution. As a result, explorer does not fall back to the default resolution, and also avoids overriding the backend-provided size during initialization. This allows the desktop to retain the correct resolution as configured by wineandroid. Second, window repainting on resolution changes is fixed. Previously, WM_ANDROID_REFRESH used NtUserExposeWindowSurface(), which only exposes existing surface contents without invalidating the window. This prevents WM_PAINT and WM_ERASEBKGND from being generated. When the desktop or other windows are resized (e.g. after applying a new display mode), they may retain stale contents instead of repainting. This is resolved by replacing NtUserExposeWindowSurface() with NtUserRedrawWindow(), ensuring proper invalidation and repaint of window contents. This fixes cases where the desktop background is not redrawn after a resolution change. Together, these changes ensure that the desktop starts with the correct resolution and that windows are properly repainted when display settings change. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10712

3 29

[PATCH 0/1] MR10365: kernelbase: Add language specific resource support.
by Craig Schulstad (＠NoDakker) May 14, 2026

May 14, 2026

When an application relies upon language specific resources, search for an associated language specific subfolder and subsequent mui file. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10365

3 15