December 2025 - Wine-gitlab

[PATCH v2 0/1] MR9768: include: Disable compiler exceptions for ARM64EC MSVC targets before Clang 21
by André Zwing (＠AndreRH) 19 Dec '25

19 Dec '25

Alternative to #9762 as suggested by Jacek -- v2: include: Disable compiler exceptions for ARM64EC MSVC targets before Clang 21 https://gitlab.winehq.org/wine/wine/-/merge_requests/9768

2 2

Re: [PATCH 0/1] MR9769: nsiproxy.sys: Assign the highest metric value to loopback adapters. - approved
by Huw Davies (＠huw) 19 Dec '25

19 Dec '25

This merge request was approved by Huw Davies. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9769

1 0

Re: [PATCH v3 0/2] MR9722: windowscodecs: Support trivial cases for copying 1bpp indexed data.
by Dmitry Timoshkov (＠dmitry) 19 Dec '25

19 Dec '25

What this MR is waiting for? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9722#note_125890

1 0

Re: [PATCH v24 0/1] MR9414: shlwapi: Handling of "C:\...xx" in PathCanonicalize[AW].
by Alexandre Julliard (＠julliard) 19 Dec '25

19 Dec '25

Please don't rebase your MR every day, it's a waste of CI resources, and makes it look like it's not ready. We are currently in code freeze so it will have to wait anyway. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9414#note_125887

1 0

Re: [PATCH v2 0/1] MR9798: wined3d: Update the context DC from its swapchain if it changed.
by Rémi Bernon (＠rbernon) 19 Dec '25

19 Dec '25

Eh... thanks, I actually saw these but somehow was hoping they were just fluke. I should know better :sweat:. https://gitlab.winehq.org/wine/wine/-/merge_requests/9801 should fix it, I even had that change pending but was looking for an actual reason to send it, I guess this is it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9798#note_125885

1 0

[PATCH 0/1] MR9801: winex11: Avoid creating window data entirely for offscreen windows.
by Rémi Bernon (＠rbernon) 19 Dec '25

19 Dec '25

This fixes a series of unfortunate changes made in 844e90b0b51c799bed68320940b51bda74ac275c b621117c652280799e209d5bec20106b1f28cb4e, which started causing various behavior changes as the (foreign / message) client window creation now triggers window data to be created, and even worse, with a whole_window set. This first makes these client windows to always be created attached to their whole window instead of the dummy parent, and, the be managed more like normal client windows and eventually detached / attached by reparenting them to / from the dummy parent. The actual issue, which started somehow after 92f5d5bc7c8412924e7cb4f6f715ecc9c4e4dd13, is that the client windows are created from an arbitrary thread, when D3D sets its internal pixel format, and this thread display is initialized and used and stored in the newly created window data. The client window lifetime is not bound to this particular thread, and it may outlive the thread itself. We then keep using a destroyed display for the reparenting calls, which is causing crashes. Using a dummy window data is enough for the client window creation to succeed and the client window will always stay attached to the dummy parent. As we don't create window data anymore, get_win_data will never succeed and we will never assume these client windows are from the current process. X11DRV_get_whole_window will works still, as we need it in some cases, but retrieving the toplevel X11 window from the window property instead. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9801

2 1

Re: [PATCH v2 0/1] MR9798: wined3d: Update the context DC from its swapchain if it changed.
by Alexandre Julliard (＠julliard) 19 Dec '25

19 Dec '25

This is causing hangs in tests like evr:evr and mf:mf, could you please have a look? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9798#note_125880

1 0

[PATCH v2 0/1] MR9793: winex11: Avoid hiding windows between WM_SETREDRAW messages.
by Rémi Bernon (＠rbernon) 19 Dec '25

19 Dec '25

See also f323d75e658fcb4f48c0b762001cee1da09d9398. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59098 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59069 This is different from the Splinter Cell case, as the window processes its messages and the window get shown again, but it is still related to WM_SETREDRAW and this fix here would fix the Splinter Cell case too. I originally decided to try a simpler fix, but as this issue is also present with other applications I think it's better now to try fixing it for all of them. -- v2: winex11: Avoid hiding windows between WM_SETREDRAW messages. https://gitlab.winehq.org/wine/wine/-/merge_requests/9793

4 10

[PATCH 0/2] MR9797: winex11: Track SWP_(SHOW|HIDE)WINDOW for window visibility.
by Rémi Bernon (＠rbernon) 19 Dec '25

19 Dec '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59098 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59069 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9797

2 5

[PATCH 0/1] MR9800: winex11: Unmap windows only when SWP_HIDEWINDOW is set.
by Rémi Bernon (＠rbernon) 19 Dec '25

19 Dec '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59098 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59069 Instead of !9793 and !9797 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9800

2 1