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

[PATCH 0/6] MR11111: libs: FFmpeg initial import
by Alexandre Julliard (＠julliard) June 10, 2026

June 10, 2026

Initial subset of !10687, without any asm optimizations. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11111

4 17

[PATCH 0/1] MR11115: comdlg32: Treat empty default extension as null.
by Esme Povirk (＠madewokherd) June 10, 2026

June 10, 2026

This (combined with another bug in path handling that I haven't figured out) causes a failure to save a new project in SMILE GAME BUILDER. I was able to reproduce the error using a .NET test program with the SaveFileDialog class. It seems SaveFileDialog, by default, sets the default extension to an empty string. Wine's itemdlg responds to this by appending a "." to the filename. I do not see the extra "." on Windows. Somehow (I haven't figured out how), SMILE GAME BUILDER takes this path and creates a directory with a name ending in ".", on the unix side. When it tries to add a file to that directory, that fails, claiming part of the path could not be found. On Windows, and usually on Wine, I am able to create a directory using a name ending in ".", but the "." is ignored. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11115

2 1

[PATCH v5 0/2] MR10298: mfreadwrite: Implement sample encoding.
by Ziqing Hui (＠zhui) June 10, 2026

June 10, 2026

-- v5: mfreadwrite: Process samples through converter and encoder. https://gitlab.winehq.org/wine/wine/-/merge_requests/10298

3 5

[PATCH v3 0/1] MR11103: winewayland: Implement support for FlashWindow.
by Etaash Mathamsetty (＠etaash.mathamsetty) June 10, 2026

June 10, 2026

Uses xdg-activation with no input serial to facilitate this. -- v3: winewayland: Implement support for FlashWindow. https://gitlab.winehq.org/wine/wine/-/merge_requests/11103

2 2

[PATCH v2 0/1] MR11103: winewayland: Implement support for FlashWindow.
by Etaash Mathamsetty (＠etaash.mathamsetty) June 10, 2026

June 10, 2026

Uses xdg-activation with no input serial to facilitate this. -- v2: winewayland: Implement support for FlashWindow. https://gitlab.winehq.org/wine/wine/-/merge_requests/11103

3 5

[PATCH 0/2] MR11114: ntdll: Fix building for arm64 with (really) old headers
by Martin Storsjö (＠mstorsjo) June 10, 2026

June 10, 2026

One fixes building without `HWCAP_CPUID`, and one without `ESR_MAGIC`/`esr_context`. The case with `HWCAP_CPUID` is quite recent. The one about `ESR_MAGIC`/`esr_context` has been around for many years. I submitted a patch about it to wine-devel in 2020, but that patch was much more complex (bringing back the old codepath from before 85c01202ac70af0c83f894d7a8986adf66983459, and a configure test). In the simplest form, just omit the reference to `esr_context` and `ESR_MAGIC` and return 0, instead of attempting any heuristics about the kind of access violation. It's not perfect, but should hopefully be less of a burden to carry around, for being able to build with ancient headers. (In this case, I'm building with an old cross sysroot, for an old SBC, with an old distribution, where I run wine. The install on the SBC is new enough to have `esr_context` itself, but the cross sysroot/toolchain happens to bundle even older kernel headers.) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11114

2 2

[PATCH v2 0/2] MR11094: cmd: Add wildcard expansion for type command.
by Barath Kannan (＠barath_kannan) June 10, 2026

June 10, 2026

Fixes: https://bugs.winehq.org/show_bug.cgi?id=59816 Signed-off-by: Barath Kannan barathrk11(a)gmail.com -- v2: cmd: Implement wildcard expansion for the type command's arguments. cmd: Add tests for type wildcard expansion. https://gitlab.winehq.org/wine/wine/-/merge_requests/11094

2 4

[PATCH 0/1] MR11113: imagehlp/tests: Accept zero checksum if the compiler emitted a zero checksum.
by Bernhard Übelacker (＠bernhardu) June 10, 2026

June 10, 2026

Clang (llvm-mingw) emits binaries with a CheckSum of zero in the OptionalHeader. But in this test the call to CheckSumMappedFile with a byte count of 0 relies on the OptionalHeader->CheckSum having some non-zero value. $ llvm-objdump -x dlls/imagehlp/tests/i386-windows/imagehlp_test.exe | grep -E "^CheckSum " CheckSum 00000000 This is observable back to at least llvm-mingw 10.0.0. CC: @mstorsjo -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11113

3 2

[PATCH 0/2] MR11094: cmd: Add wildcard expansion for type command.
by Barath Kannan (＠barath_kannan) June 10, 2026

June 10, 2026

Fixes: https://bugs.winehq.org/show_bug.cgi?id=59816 Signed-off-by: Barath Kannan barathrk11(a)gmail.com -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11094

3 13

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

June 10, 2026

-- v2: dxgi/tests: Fix tests with old Windows versions. https://gitlab.winehq.org/wine/wine/-/merge_requests/11110

3 5

[PATCH v9 0/3] 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. -- v9: Clean up nicely after test. https://gitlab.winehq.org/wine/wine/-/merge_requests/10869

2 4

[PATCH 0/1] MR11112: windows.ui.core.textinput/tests: Only check interfaces if retrieval succeeded.
by Bernhard Übelacker (＠bernhardu) June 10, 2026

June 10, 2026

This is an attempt to avoid the test crashing. [Test pattern page windows.ui.core.textinput:textinput](https://test.winehq.org/data/patterns.… [Testbot run with this patch](https://testbot.winehq.org/JobDetails.pl?Key=163330) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11112

2 1

[PATCH 0/1] MR11090: ddraw: Cap reported VRAM size at ~2GB.
by Paul Gofman (＠gofman) June 10, 2026

June 10, 2026

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

4 9

[PATCH v8 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. -- v8: Added tests for proper handling of WM_ATLGETCONTROL and WM_ATLGETHOST. atl: Implement registering ATL window messages. https://gitlab.winehq.org/wine/wine/-/merge_requests/10869

2 3

[PATCH v7 0/38] 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. -- v7: Added tests for proper handling of WM_ATLGETCONTROL and WM_ATLGETHOST. include: Define more runtimeclasses in windows.storage.streams.idl. bcrypt: Get rid of the unixlib. bcrypt: Use SymCrypt for keys. xml2: Remove unused files. vkd3d: Remove unused files. ldap: Remove unused files. icui18n: Remove unused files. icucommon: Remove unused files. gsm: Remove unused files. fluidsynth: Remove unused files. makedep: Also ignore missing headers when included from external lib header. makedep: Add a helper function to skip an initial directory. wineandroid: Raise minimum SDK version to 28 (Android 9.0). user32/tests: Fix test_window_extra_data_proc. user32: Set FNID for the builtin scrollbar window class. user32: Store a scroll_info pointer in the scrollbar control info. webservices/tests: Improve double tests. ddraw/tests: Remove extra backbuffer1 release in test_surface_attachment(). ntdll: Preserve nonvolatile registers across VEH callbacks. vbscript/tests: Add tests for sub declaration scope. vbscript: Handle class declaration scope in the parser. vbscript/tests: Add tests for class declaration scope. notices: Add a file to collect all third-party copyright notices. tomcrypt: Remove library. bcrypt: Use SymCrypt for hashes. opengl32: Track implicit buffer names allocation. opengl32: Track client-side buffer names allocation. opengl32: Query the context profile mask on init. opengl32: Share display lists in wglShareLists on the PE side. opengl32: Allocate display lists for client-side contexts. win32u: Fixed incorrect glyph outline size. riched20/tests: Expand editor tests to verify \pntext behaviour. riched20: Properly capture \pntext content. dsound/tests: Don't fail test if device cannot be opened the second time. dssenh: Use _aligned_free instead of free for aligned allocations (ASan). rsaenh: Use _aligned_free instead of free for aligned allocations (ASan). This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/10869

1 0

[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