- Wine-GitLab - list.winehq.org

[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 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 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