February 2026 - Wine-GitLab

[PATCH v4 0/3] MR9704: winmm, msvfw32: DGV window shenanigans with audio only files
by Bernhard Kölbl Feb. 25, 2026

Feb. 25, 2026

Basically, check if we can set a HWND in the driver, before doing so. Right now, msvfw32 + mciqtz32 error out on audio only playbacks, breaking the game Transcendence. -- v4: msvfw32: Only attempt to set a digital-video window, when the driver has a window itself. msvfw32/tests: Add a basic audio playback test. winmm/tests: Test digital-video window behavior for audio files. https://gitlab.winehq.org/wine/wine/-/merge_requests/9704

1 0

[PATCH v2 0/10] MR10180: Desktop Window Manager (DWM) Overlay and Composition Support
by Namo Nath (＠namoninja) Feb. 25, 2026

Feb. 25, 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. -- v2: 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. winex11.drv: Resolve overlay Z-Order priority via _NET_WM_STATE_ABOVE. winex11.drv: Implement click-through input routing for transparent windows. winex11.drv: Support ARGB visuals for DWM glass effect. winex11.drv: Implement SetWindowDwmConfig for opaque regions. win32u: Add NtUserSetWindowDwmConfig syscall. https://gitlab.winehq.org/wine/wine/-/merge_requests/10180

2 3

Re: [PATCH v7 0/1] MR10174: bcryptprimitives: Abort if `ProcessPrng` fails
by Paul Gofman (＠gofman) Feb. 25, 2026

Feb. 25, 2026

On Wed Feb 25 14:23:54 2026 +0000, Paul Gofman wrote: > > The question is whether it's better to abort the app or to continue > without random data. > IMO such sort of abort, if considered useful, can only go to the Unix > ("kernel") side to the underlying Nt call. Doing that on PE side, if it > is not known to match Windows, is not ideal. As a generic rule, anything > on PE side is subject to hotpatching and thus the logic to be overridden > by app and abort will break compatibility. And if the app doesn't > hotpatch anything there it already should not ever fail here on PE side. > And if it does hotpatch our code it can also avoid this abort. Note that we can't protect things this way securely anyway. E. g., if app does random memory access and hits our random data buffer used in SystemFunction36, this won't be detected by return value check. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130497

1 0

Re: [PATCH v7 0/1] MR10174: bcryptprimitives: Abort if `ProcessPrng` fails
by Paul Gofman (＠gofman) Feb. 25, 2026

Feb. 25, 2026

> The question is whether it's better to abort the app or to continue without random data. IMO such sort of abort, if considered useful, can only go to the Unix ("kernel") side to the underlying Nt call. Doing that on PE side, if it is not known to match Windows, is not ideal. As a generic rule, anything on PE side is subject to hotpatching and thus the logic to be overridden by app and abort will break compatibility. And if the app doesn't hotpatch anything there it already should not ever fail here on PE side. And if it does hotpatch our code it can also avoid this abort. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130496

1 0

[PATCH v2 0/6] MR10183: msxml/tests: Extend PI test with newlines.
by Nikolay Sivov (＠nsivov) Feb. 25, 2026

Feb. 25, 2026

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: msxml3: Add SAX error messages. https://gitlab.winehq.org/wine/wine/-/merge_requests/10183

2 6

[PATCH 0/3] MR10184: compiler-rt: Import aarch64 chkstk.S.
by Jacek Caban (＠jacek) Feb. 25, 2026

Feb. 25, 2026

This fixes a problem with Wine build revealed by https://github.com/llvm/llvm-project/pull/179812. With that LLVM change, the compiler emits references to `__chkstk_arm64ec` from exit thunks. While these references are typically resolved by ntdll in user-mode, ntoskrnl does not provide this symbol, leading to undefined reference errors when building kernel-mode test modules. Although ARM64EC kernel modules obviously don't make much sense by themselves, there is no reason to prohibit compiler builtins in these modules regardless of the EC aspect. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10184

1 0

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

Feb. 25, 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 still 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 ("Safety Latch") 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, cross-process tracking, WH_MOUSELL hooks, and aggressive `SetWindowPos` calls. * **Blish HUD (.NET/C#):** Validated DXVK/Vulkan path, late ARGB binding, dynamic style hotswapping, 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. ## Outro 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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10180

3 12

Re: [PATCH v3 0/2] MR9704: winmm, msvfw32: DGV window shenanigans with audio only files
by Bernhard Kölbl Feb. 25, 2026

Feb. 25, 2026

> I'm still confused about the lack of test changes after the implementation change. We're changing the audio behaviour; why can't we test that change? I could maybe add some similar tests to msvfw32, like I did for winmm. Those should show the difference between failure to play audio-only (current upstream) and the working state, being able to play audio only files (Windows). Does that sound good? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9704#note_130489

1 0

Re: [PATCH v3 0/2] MR9704: winmm, msvfw32: DGV window shenanigans with audio only files
by Huw Davies (＠huw) Feb. 25, 2026

Feb. 25, 2026

'dgv' should be capitalised in the commit messages, or better yet expanded to Digital-Video (if that's what it stands for). I'm still confused about the lack of test changes after the implementation change. We're changing the audio behaviour; why can't we test that change? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9704#note_130485

1 0

Re: [PATCH v3 0/2] MR9704: winmm, msvfw32: DGV window shenanigans with audio only files
by Huw Davies (＠huw) Feb. 25, 2026

Feb. 25, 2026

Huw Davies (@huw) commented about dlls/winmm/tests/mci.c: > ok(err==ok_saved,"mci open tempfile.wav type MPEGVideo returned %s\n", dbg_mcierr(err)); > > err = mciSendStringA("play mysound", NULL, 0, NULL); > - ok(!err,"mci play retuend %s\n", dbg_mcierr(err)); > + ok(!err,"mci play returned %s\n", dbg_mcierr(err)); > > err = mciSendStringA("play mysound", NULL, 0, NULL); > - ok(!err,"mci play retuend %s\n", dbg_mcierr(err)); > + ok(!err,"mci play returned %s\n", dbg_mcierr(err)); > > err = mciSendStringA("close mysound", NULL, 0, NULL); > ok(!err,"mci close returned %s\n", dbg_mcierr(err)); > + > + /* test playing a mp3 file */ > + snprintf(buf, 1024, "open %ls type MPEGVideo alias mytest", filename); ```suggestion:-0+0 snprintf(buf, ARRAY_SIZE(buf), "open %ls type MPEGVideo alias mytest", filename); ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9704#note_130484

1 0