- Wine-GitLab - list.winehq.org

[PATCH v2 0/1] MR9909: Draft: winemac: Avoid updating client surface views unnecessarily.
by Rémi Bernon Feb. 4, 2026

Feb. 4, 2026

-- v2: winemac: Avoid updating client surface views unnecessarily. https://gitlab.winehq.org/wine/wine/-/merge_requests/9909

1 2

[PATCH v3 0/6] MR10025: mshtml/msxml3: Add XMLSerializer, embedded XML declaration handling, and fix DISPATCH_METHOD|PROPERTYGET for ES5+
by Phiality (＠PhialsBasement) Feb. 4, 2026

Feb. 4, 2026

This patchset adds XMLSerializer support and fixes several compatibility issues for Adobe Creative Cloud installer and similar applications. XMLSerializer implementation (mshtml) - Implements the `IXMLSerializer` interface with `serializeToString()` method - Allows JavaScript to serialize DOM elements to XML strings Embedded XML declaration handling (msxml3) - Adds CDATA wrapping for embedded `<?xml?>` declarations inside elements - Windows MSXML tolerates these nested declarations but libxml2 rejects them - The preprocessing step wraps problematic content in CDATA sections before parsing DISPATCH_METHOD|DISPATCH_PROPERTYGET fixes (jscript/mshtml) - Fixes ES5+ handling that was breaking method calls with arguments - When `cArgs > 0`, treats the call as `DISPATCH_METHOD` (actual method invocation) - When `cArgs == 0`, uses ES5+ behavior preferring `DISPATCH_PROPERTYGET` (property access) - In quirks mode (pre-IE9), returns `E_ACCESSDENIED` for `METHOD|PROPERTYGET` on function objects to match Windows Also added tests for XMLSerializer (empty elements, text nodes, special characters, nested elements, multiple children), embedded XML declaration handling (multiple declarations, deeply nested, encoding attributes, self-closing elements) and DISPATCH_METHOD|DISPATCH_PROPERTYGET behavior in both quirks and standards modes - Filip Bakreski -- v3: mshtml/tests: Fix method_reference_call test to use .call() for proper this binding. https://gitlab.winehq.org/wine/wine/-/merge_requests/10025

4 8

[PATCH 0/1] MR10029: odbcad32: Add stub program.
by Hans Leidekker (＠hans) Feb. 4, 2026

Feb. 4, 2026

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

2 1

[PATCH v2 0/2] MR10004: jscript: Fix DISPATCH_METHOD | DISPATCH_PROPERTYGET in ES5+ modes.
by Gabriel Ivăncescu Feb. 4, 2026

Feb. 4, 2026

-- v2: mshtml/tests: Test calling function object method with return value and jscript: Always treat DISPATCH_METHOD | DISPATCH_PROPERTYGET as method call https://gitlab.winehq.org/wine/wine/-/merge_requests/10004

2 3

[PATCH 0/2] MR10028: server: Only try to grab atom for string window properties.
by Rémi Bernon Feb. 4, 2026

Feb. 4, 2026

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

1 2

[PATCH v6 0/1] MR9999: winex11.drv: Fix window stacking order with insert_after parameter.
by Zhao Yi (＠Zhaoyi) Feb. 4, 2026

Feb. 4, 2026

When calling the SetWindowPos function to change the window Z-order with an insert_after parameter as a real window handle, the expected result is that the insert_after window appears above the specified window hwnd. For example, calling SetWindowPos(g_hwndB, g_hwndA, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_SHOWWINDOW | SWP_NOACTIVATE) should result in window A appearing above window B. Below is a demo showing test results on Windows versus Wine: The initial z-order of WindowA and WindowB is: WindowB is above WindowA: ![zo-1.png](/uploads/a190a622181ab71682ecd2908d5d649b/zo-1.png){width=781 height=399} Next, click the "Place WindowA above WindowB" button on Windows and Wine respectively. The test results are as follows: On Windows, After clicking the button, WindowA is placed above WindowB: ![zo-2.png](/uploads/220a8889e7f08943f20824121ebedd66/zo-2.png){width=801 height=439} \ On wine, After clicking the button, the Z-order of WindowA and WindowB remains unchanged: ![image.png](/uploads/158905a1fa6702fcd9fb0e5e810e2ad5/image.png){width=900 height=444} demo： [demo.cpp](/uploads/6e3a44e8b223e54d28c2d65e66856d40/demo.cpp) Signed-off-by: Zhao Yi zhaoyi(a)uniontech.com -- v6: winex11.drv: Fix window stacking order with insert_after parameter. https://gitlab.winehq.org/wine/wine/-/merge_requests/9999

2 1

[PATCH v5 0/1] MR9999: winex11.drv: Fix window stacking order with insert_after parameter.
by Zhao Yi (＠Zhaoyi) Feb. 4, 2026

Feb. 4, 2026

When calling the SetWindowPos function to change the window Z-order with an insert_after parameter as a real window handle, the expected result is that the insert_after window appears above the specified window hwnd. For example, calling SetWindowPos(g_hwndB, g_hwndA, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_SHOWWINDOW | SWP_NOACTIVATE) should result in window A appearing above window B. Below is a demo showing test results on Windows versus Wine: The initial z-order of WindowA and WindowB is: WindowB is above WindowA: ![zo-1.png](/uploads/a190a622181ab71682ecd2908d5d649b/zo-1.png){width=781 height=399} Next, click the "Place WindowA above WindowB" button on Windows and Wine respectively. The test results are as follows: On Windows, After clicking the button, WindowA is placed above WindowB: ![zo-2.png](/uploads/220a8889e7f08943f20824121ebedd66/zo-2.png){width=801 height=439} \ On wine, After clicking the button, the Z-order of WindowA and WindowB remains unchanged: ![image.png](/uploads/158905a1fa6702fcd9fb0e5e810e2ad5/image.png){width=900 height=444} demo： [demo.cpp](/uploads/6e3a44e8b223e54d28c2d65e66856d40/demo.cpp) Signed-off-by: Zhao Yi zhaoyi(a)uniontech.com -- v5: winex11.drv: Fix window stacking order with insert_after parameter. https://gitlab.winehq.org/wine/wine/-/merge_requests/9999

2 1

[PATCH v4 0/1] MR9999: winex11.drv: Fix window stacking order with insert_after parameter.
by Zhao Yi (＠Zhaoyi) Feb. 4, 2026

Feb. 4, 2026

When calling the SetWindowPos function to change the window Z-order with an insert_after parameter as a real window handle, the expected result is that the insert_after window appears above the specified window hwnd. For example, calling SetWindowPos(g_hwndB, g_hwndA, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_SHOWWINDOW | SWP_NOACTIVATE) should result in window A appearing above window B. Below is a demo showing test results on Windows versus Wine: The initial z-order of WindowA and WindowB is: WindowB is above WindowA: ![zo-1.png](/uploads/a190a622181ab71682ecd2908d5d649b/zo-1.png){width=781 height=399} Next, click the "Place WindowA above WindowB" button on Windows and Wine respectively. The test results are as follows: On Windows, After clicking the button, WindowA is placed above WindowB: ![zo-2.png](/uploads/220a8889e7f08943f20824121ebedd66/zo-2.png){width=801 height=439} \ On wine, After clicking the button, the Z-order of WindowA and WindowB remains unchanged: ![image.png](/uploads/158905a1fa6702fcd9fb0e5e810e2ad5/image.png){width=900 height=444} demo： [demo.cpp](/uploads/6e3a44e8b223e54d28c2d65e66856d40/demo.cpp) Signed-off-by: Zhao Yi zhaoyi(a)uniontech.com -- v4: winex11.drv: Fix window stacking order with insert_after parameter. https://gitlab.winehq.org/wine/wine/-/merge_requests/9999

2 1

[PATCH v3 0/1] MR9999: winex11.drv: Fix window stacking order with insert_after parameter.
by Zhao Yi (＠Zhaoyi) Feb. 4, 2026

Feb. 4, 2026

When calling the SetWindowPos function to change the window Z-order with an insert_after parameter as a real window handle, the expected result is that the insert_after window appears above the specified window hwnd. For example, calling SetWindowPos(g_hwndB, g_hwndA, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_SHOWWINDOW | SWP_NOACTIVATE) should result in window A appearing above window B. Below is a demo showing test results on Windows versus Wine: The initial z-order of WindowA and WindowB is: WindowB is above WindowA: ![zo-1.png](/uploads/a190a622181ab71682ecd2908d5d649b/zo-1.png){width=781 height=399} Next, click the "Place WindowA above WindowB" button on Windows and Wine respectively. The test results are as follows: On Windows, After clicking the button, WindowA is placed above WindowB: ![zo-2.png](/uploads/220a8889e7f08943f20824121ebedd66/zo-2.png){width=801 height=439} \ On wine, After clicking the button, the Z-order of WindowA and WindowB remains unchanged: ![image.png](/uploads/158905a1fa6702fcd9fb0e5e810e2ad5/image.png){width=900 height=444} demo： [demo.cpp](/uploads/6e3a44e8b223e54d28c2d65e66856d40/demo.cpp) Signed-off-by: Zhao Yi zhaoyi(a)uniontech.com -- v3: winex11.drv: Fix window stacking order with insert_after parameter. https://gitlab.winehq.org/wine/wine/-/merge_requests/9999

2 3

[PATCH 0/2] MR10024: wined3d: Reset internal_format_set when using the backup DC.
by Elizabeth Figura (＠zfigura) Feb. 4, 2026

Feb. 4, 2026

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

4 4

[PATCH 0/1] MR9999: winex11.drv: Fix window stacking order with insert_after parameter.
by Zhao Yi (＠Zhaoyi) Feb. 4, 2026

Feb. 4, 2026

When calling the SetWindowPos function to change the window Z-order with an insert_after parameter as a real window handle, the expected result is that the insert_after window appears above the specified window hwnd. For example, calling SetWindowPos(g_hwndB, g_hwndA, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_SHOWWINDOW | SWP_NOACTIVATE) should result in window A appearing above window B. Below is a demo showing test results on Windows versus Wine: The initial z-order of WindowA and WindowB is: WindowB is above WindowA: ![zo-1.png](/uploads/a190a622181ab71682ecd2908d5d649b/zo-1.png){width=781 height=399} Next, click the "Place WindowA above WindowB" button on Windows and Wine respectively. The test results are as follows: On Windows, After clicking the button, WindowA is placed above WindowB: ![zo-2.png](/uploads/220a8889e7f08943f20824121ebedd66/zo-2.png){width=801 height=439} \ On wine, After clicking the button, the Z-order of WindowA and WindowB remains unchanged: ![image.png](/uploads/158905a1fa6702fcd9fb0e5e810e2ad5/image.png){width=900 height=444} demo： [demo.cpp](/uploads/6e3a44e8b223e54d28c2d65e66856d40/demo.cpp) Signed-off-by: Zhao Yi zhaoyi(a)uniontech.com -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9999

5 9

[PATCH v2 0/5] MR10025: mshtml/msxml3: Add XMLSerializer, embedded XML declaration handling, and fix DISPATCH_METHOD|PROPERTYGET for ES5+
by Phiality (＠PhialsBasement) Feb. 4, 2026

Feb. 4, 2026

This patchset adds XMLSerializer support and fixes several compatibility issues for Adobe Creative Cloud installer and similar applications. XMLSerializer implementation (mshtml) - Implements the `IXMLSerializer` interface with `serializeToString()` method - Allows JavaScript to serialize DOM elements to XML strings Embedded XML declaration handling (msxml3) - Adds CDATA wrapping for embedded `<?xml?>` declarations inside elements - Windows MSXML tolerates these nested declarations but libxml2 rejects them - The preprocessing step wraps problematic content in CDATA sections before parsing DISPATCH_METHOD|DISPATCH_PROPERTYGET fixes (jscript/mshtml) - Fixes ES5+ handling that was breaking method calls with arguments - When `cArgs > 0`, treats the call as `DISPATCH_METHOD` (actual method invocation) - When `cArgs == 0`, uses ES5+ behavior preferring `DISPATCH_PROPERTYGET` (property access) - In quirks mode (pre-IE9), returns `E_ACCESSDENIED` for `METHOD|PROPERTYGET` on function objects to match Windows Also added tests for XMLSerializer (empty elements, text nodes, special characters, nested elements, multiple children), embedded XML declaration handling (multiple declarations, deeply nested, encoding attributes, self-closing elements) and DISPATCH_METHOD|DISPATCH_PROPERTYGET behavior in both quirks and standards modes - Filip Bakreski -- v2: mshtml/msxml3: Add tests for XMLSerializer and embedded XML declaration handling. https://gitlab.winehq.org/wine/wine/-/merge_requests/10025

2 5

[PATCH 0/5] MR10025: mshtml/msxml3: Add XMLSerializer, embedded XML declaration handling, and fix DISPATCH_METHOD|PROPERTYGET for ES5+
by Phiality (＠PhialsBasement) Feb. 4, 2026

Feb. 4, 2026

This patchset adds XMLSerializer support and fixes several compatibility issues for Adobe Creative Cloud installer and similar applications. XMLSerializer implementation (mshtml) - Implements the `IXMLSerializer` interface with `serializeToString()` method - Allows JavaScript to serialize DOM elements to XML strings Embedded XML declaration handling (msxml3) - Adds CDATA wrapping for embedded `<?xml?>` declarations inside elements - Windows MSXML tolerates these nested declarations but libxml2 rejects them - The preprocessing step wraps problematic content in CDATA sections before parsing DISPATCH_METHOD|DISPATCH_PROPERTYGET fixes (jscript/mshtml) - Fixes ES5+ handling that was breaking method calls with arguments - When `cArgs > 0`, treats the call as `DISPATCH_METHOD` (actual method invocation) - When `cArgs == 0`, uses ES5+ behavior preferring `DISPATCH_PROPERTYGET` (property access) - In quirks mode (pre-IE9), returns `E_ACCESSDENIED` for `METHOD|PROPERTYGET` on function objects to match Windows Also added tests for XMLSerializer (empty elements, text nodes, special characters, nested elements, multiple children), embedded XML declaration handling (multiple declarations, deeply nested, encoding attributes, self-closing elements) and DISPATCH_METHOD|DISPATCH_PROPERTYGET behavior in both quirks and standards modes - Filip Bakreski -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10025

2 5

[PATCH 0/3] MR10023: wined3d/spirv: Pass vkd3d_shader_d3dbc_source_info.
by Elizabeth Figura (＠zfigura) Feb. 3, 2026

Feb. 3, 2026

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

2 3

[PATCH v3 0/1] MR2498: msado15: Implement _Recordset Find
by Alistair Leslie-Hughes (＠alesliehughes) Feb. 3, 2026

Feb. 3, 2026

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

Re: [PATCH v3 0/1] MR10011: programs/explorer: Follow up c31e65fd3bde7, keep systray visible with taskbar enabled - approved
by Alexandre Julliard (＠julliard) Feb. 3, 2026

Feb. 3, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10011

1 0

Re: [PATCH v2 0/4] MR10020: Winedump improvements for PDB files. - approved
by Alexandre Julliard (＠julliard) Feb. 3, 2026

Feb. 3, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10020

1 0

Re: [PATCH v2 0/5] MR10018: PDB speedup 4 - approved
by Alexandre Julliard (＠julliard) Feb. 3, 2026

Feb. 3, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10018

1 0

Re: [PATCH v2 0/1] MR10016: dbghelp: Rewrite EnumerateLoadedModulesW64 in terms of CreateToolhelp32Snapshot. - approved
by Alexandre Julliard (＠julliard) Feb. 3, 2026

Feb. 3, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10016

1 0

Re: [PATCH v11 0/2] MR2044: ntoskrnl.exe: Implement acquiring and releasing guarded mutexes - approved
by Alexandre Julliard (＠julliard) Feb. 3, 2026

Feb. 3, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2044

1 0

Re: [PATCH v2 0/1] MR10015: win32u: Actually return HKL for SPI_GETDEFAULTINPUTLANG. - approved
by Alexandre Julliard (＠julliard) Feb. 3, 2026

Feb. 3, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10015

1 0

[PATCH v2 0/1] MR10005: Draft: [RFC] server: Add option to return ticks since wineserver start.
by Bernhard Übelacker Feb. 3, 2026

Feb. 3, 2026

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59287 - Unsure if there is a better way to make this configurable? - Is adding the message to GetTickCount ok for performance reasons? How can a user be better warned if they have an uptime above 25 days and their application uses this Api? -- v2: Draft: server: Add option to return ticks since wineserver start. https://gitlab.winehq.org/wine/wine/-/merge_requests/10005

1 2

Re: [PATCH v4 0/9] MR9987: opengl32: Generate extension lists with basic GLES support.
by Elizabeth Figura (＠zfigura) Feb. 3, 2026

Feb. 3, 2026

> I don't really know well but it seems to me that GL_APPLE_fence is a fallback for GL_ARB_sync, and GL_APPLE_flush_buffer_range a fallback for GL_ARB_map_buffer_range. I'm not sure about GL_APPLE_rgb_422 and GL_APPLE_ycbcr_422 but I suppose that they aren't available outside of macOS, and the latter described as only available on legacy contexts, so I assume they are only optional for wined3d operation? Sort of. While we use ARB_sync and APPLE_fence in more or less the same way, I don't think the semantics of ARB_sync are a subset of those of APPLE_fence in general. In fact they are probably a superset if anything. It wouldn't be appropriate to implement ARB_sync on top of APPLE_fence. The reason we fall back is because an implementation might expose APPLE_fence but not ARB_sync. I don't know for sure but it wouldn't surprise me if Apple machines do this very thing. That's the case for many extensions, including APPLE_flush_buffer_range vs ARB_map_buffer_range. In the case of YUV, we have fallback implementations, since, as you mention, those extensions aren't actually exposed outside of Mac as far as I know. They do require more work on our part, but I wouldn't be surprised if they're not actually less efficient for that. Now that we require GLSL anyway, there may not really any point continuing to use the Apple extensions. I'm not really about to delete something from wined3d if it's not getting in the way, though, and I think that's the main point here. GL_APPLE extensions are just like any other vendored extensions. You see vendors implementing each others' extensions all the time. There's no reason to treat them separately, and I don't see why they'd be a problem for opengl32 translation. (GLX_APPLE_* would be another story, if any such extensions existed, but then the operative part there is really "GLX", and I assume we already filter out GLX_*.) If a Windows application did in fact choke on seeing any APPLE extensions, we could remove them, and decide what we want to do about that in d3d, but I don't think there's any reason to do that preemptively. In fact, I would be surprised if this happens, because looking now, it seems at least one Apple extension, namely APPLE_packed_pixels, is frequently implemented on both Linux and Windows, including the radeonsi machine I'm typing from. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9987#note_128701

1 0

[PATCH v9 0/4] MR10007: Support enabling/disabling IME on winewayland
by Ziia Shi (＠mkrsym1) Feb. 3, 2026

Feb. 3, 2026

Currently, IME is always enabled for all applications. This can cause some very annoying issues on winewayland. For example, fcitx takes over the character repeat functionality when enabled, and does it via repeatedly sending sequences of keyup/keydown, which leads to applications not being able to track hold duration of a button (can be reproduced on any game which requires holding a letter key). The spec states that the enable request should only be sent when a text edit is focused, and a disable request should be sent when it is unfocused. Windows provides a "similar-ish" mechanism: applications can use ImmAssociateContext/ImmAssociateContextEx to associate an IMC when IME should be enabled, and set associated IMC to null when it should be disabled. From my rather limited testing, it is implemented this way in Chromium/CEF, QT and Unity. Setting it to null internally results in deactivation of the currently associated context. This MR makes the ImeSetActiveContext function of the builtin IME utilize a new driver function to communicate activation status. It does not take into account which specific context was activated, thus semi-stub. This fixes behavior of applications using the above-mentioned components. I only implemented it for winewayland, it probably should also be implemented for winex11 too, but I'm not sure how. ~~Unfortunately this breaks IME input in Wine comctl32/user32 components. I am not sure how it is supposed to behave on Windows or how to test it at the current point, will look into it later. Having IME on by default appears to "fix" it, but that is very likely not the Windows behavior; moreover, at least Unity does not disable IME on start, which causes the above-mentioned issue to occur until a textbox is manually focused and unfocused.~~ Fixed -- v9: imm32/tests: Test which IME receives ImeSetActiveContext deactivation call after layout change https://gitlab.winehq.org/wine/wine/-/merge_requests/10007

3 7

Re: [PATCH v31 0/2] MR9414: shlwapi: Handling of "C:\...xx" in PathCanonicalize[AW].
by Thomas Csovcsity (＠thc13) Feb. 3, 2026

Feb. 3, 2026

Rebased after code freeze. Will leave it untouched for review until i receive other advise. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9414#note_128691

1 0