- Wine-GitLab - list.winehq.org

[PATCH v3 0/6] MR11106: server: Move window extra info / id / instance / user data to shared memory.
by Rémi Bernon (＠rbernon) June 10, 2026

June 10, 2026

-- v3: server: Move window user data to shared memory. server: Move window instance to the shared memory. server: Move window id / menu to the shared memory. win32u: Return value directly from get_window_extra. server: Move window extra data to the shared memory. win32u: Introduce a server_set_window_info helper. https://gitlab.winehq.org/wine/wine/-/merge_requests/11106

2 7

[PATCH v6 0/2] MR10869: atl: Implement registering ATL window messages.
by Steven Don (＠shdon) June 10, 2026

June 10, 2026

The [documentation](https://source.winehq.org/WineAPI/AtlAxWinInit.html) for `AtlAxWinInit` states that it initialises ATL's control hosting code by registering window classes "_and some messages_". MSDN's documentation phrases this as "_plus a couple of custom window messages_", but Wine's implementation didn't register any custom window messages. Logging calls to `RegisterWindowMessage` showed that Visual Studio 2005, when going into Options -\> Projects and Solutions -\> VC++ Directories, calls this function to get the message IDs for custom messages name `WM_ATLGETCONTROL` and `WM_ATLGETHOST`. I've then registered those same messages in `AtlAxWinInit` and logged when they were called in `AtlAxWin_wndproc`. Since they were called with 0 for both `wParam` and `lParam`, the only sensible implementation would be routing the calls through `AtlAxGetControl` and `AtlAxGetHost` and returning the `IUnknown` pointer from the window procedure. This minor change now makes the VC++ Directories control in Visual Studio 2005 work as expected (and probably other stuff too). In that, it fixes one of the problems listed on the [Visual Studio 2005 AppDb page](https://appdb.winehq.org/objectManager.php?sClass=version&iId=4494), specifically as described in the comment "Building" posted by Dave on 2021-08-01. -- v6: Added tests for proper handling of WM_ATLGETCONTROL and WM_ATLGETHOST. https://gitlab.winehq.org/wine/wine/-/merge_requests/10869

3 4

[PATCH 0/1] MR11110: dxgi/tests: Avoid crash with old Windows.
by Bernhard Übelacker (＠bernhardu) June 10, 2026

June 10, 2026

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

2 2

[PATCH v2 0/6] MR11106: Draft: server: Move window extra info / id / instance / user data to shared memory.
by Rémi Bernon (＠rbernon) June 10, 2026

June 10, 2026

-- v2: server: Move window user data to shared memory. server: Move window instance to the shared memory. server: Move window id / menu to the shared memory. win32u: Return value directly from get_window_extra. server: Move window extra data to the shared memory. win32u: Introduce a server_set_window_info helper. https://gitlab.winehq.org/wine/wine/-/merge_requests/11106

2 6

[PATCH 0/1] MR11107: user32:Unify drop_target cleanup at end of drag_drop_drop to avoid spurious...
by zhou zhang (＠zhouzhang) June 10, 2026

June 10, 2026

user32:Unify drop_target cleanup at end of drag_drop_drop to avoid spurious DragLeave in next DnD session Change-Id: I1213239a7c7981c4d3f7cb56281e3687527c7885 Bug: drag_drop_drop calls IDropTarget_Drop but fails to Release+NULL drop_target. When the next XdndEnter arrives, drag_drop_enter releases the old data_object, whose destructor sees the stale drop_target is non-NULL,incorrectly calls IDropTarget_DragLeave, and interrupts the new drag session. Fix: Remove Release+NULL from the else-if branch, add a single Release+NULL after if (drop_file) as the sole cleanup point, avoiding double-release. Cannot reproduce in Wine tests: DoDragDrop API bypasses clipboard.c entirely and has no stale pointer issue; the X11 DnD path requires cross-process COM deferred Release timing, which cannot be simulated in a simple Wine test case. MSDN:https://learn.microsoft.com/en-us/windows/win32/api/oleidl/nf-oleidl-i… [drop_receiver.exe](/uploads/85f0571bc354238576bf9e50a62f12e2/drop_receiver.exe) [drop_receiver.c](/uploads/b409b8a12a352dae9dbd4dab5fa322d2/drop_receiver.c) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11107

2 1

[PATCH 0/1] MR11105: winewayland: Fix handling of numlock and right shift.
by Etaash Mathamsetty (＠etaash.mathamsetty) June 10, 2026

June 10, 2026

See user32 tests. MSDN says only numlock behaves this way, but right shift also does. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11105

3 6

[PATCH 0/6] MR11106: server: Move window extra info / id / instance / user data to shared memory.
by Rémi Bernon (＠rbernon) June 10, 2026

June 10, 2026

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

2 6

[PATCH 0/1] MR11104: winewayland: Do not place_above on a detached client surface.
by Etaash Mathamsetty (＠etaash.mathamsetty) June 10, 2026

June 10, 2026

``` if (toplevel && NtUserIsWindowVisible(hwnd)) wayland_client_surface_attach(client, toplevel); else wayland_client_surface_attach(client, NULL); ``` The above shows up in a few places in winewayland. What ends up happening is that the client surface gets detached, but its pointer is still present in wayland_win_data->client_surface. wayland_surface_reconfigure_subsurface would then try to place itself above the detached client surface without first checking if the client surface has a subsurface (i.e it is attached). Alternatively, we could check if the client surface has a toplevel hwnd set, but this is equivalent and clearer imo. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11104

3 2

[PATCH 0/2] MR11046: mfplat: Do not require CONTENT_DOES_NOT_HAVE_TO_MATCH_EXTENSION_OR_MIME_TYPE...
by Conor McCarthy (＠cmccarthy) June 10, 2026

June 10, 2026

The case where unknown extensions should be rejected is not fixed here because it looks prone to regression. We might not check all necessary extensions. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11046

3 5

[PATCH 0/1] MR11100: winevulkan: Update to VK spec version 1.4.353.
by Georg Lehmann (＠DadSchoorse) June 10, 2026

June 10, 2026

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

3 2