September 2025 - wine-gitlab

[PATCH v2 0/4] MR9060: ntdll: Fix crashes in syscall dispatcher due to attempt to restore unitialized data.
by Paul Gofman (＠gofman) 27 Sep '25

27 Sep '25

-- v2: ntdll: Handle invalid FP state in usr1_handler() on i386. https://gitlab.winehq.org/wine/wine/-/merge_requests/9060

2 5

[PATCH 0/4] MR9060: ntdll: Fix crashes in syscall dispatcher due to attempt to restore unitialized data.
by Paul Gofman (＠gofman) 27 Sep '25

27 Sep '25

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

2 6

[PATCH v3 0/4] MR8394: Fix Clip Studio Paint crash with Windows 10 compatibility mode
by Ignacy Kuchciński (＠ignapk) 26 Sep '25

26 Sep '25

This fixes the crash when launching ClipStudioPaint.exe with Windows 10 compatiblity mode by adding the minimum required windows.ui and windows.storage definitions and stubs. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58254 -- v3: windows.storage: Add stubs for StorageFile class. https://gitlab.winehq.org/wine/wine/-/merge_requests/8394

2 5

[PATCH v2 0/5] MR8394: Draft: Fix Clip Studio Paint crash with Windows 10 compatibility mode
by Ignacy Kuchciński (＠ignapk) 26 Sep '25

26 Sep '25

This fixes the crash when launching ClipStudioPaint.exe with Windows 10 compatiblity mode by adding the minimum required windows.ui and windows.storage definitions and stubs. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58254 -- v2: temporary fix windows.storage: Add stubs for StorageFile class. include: Add Windows.Storage.StorageFile missing definitions. windows.ui: Add stubs for RadialController classes. include: Add Windows.UI.Input.RadialController definitions. https://gitlab.winehq.org/wine/wine/-/merge_requests/8394

2 7

[PATCH 0/5] MR9059: xmllite/writer: Improve error handling in WriteChars().
by Nikolay Sivov (＠nsivov) 26 Sep '25

26 Sep '25

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9059

2 5

[PATCH 0/1] MR9056: msxml3/element: Implement removeAttributeNode function.
by Reinhold Gschweicher (＠neroburner) 26 Sep '25

26 Sep '25

Implement the function `IXMLDOMElement_removeAttributeNode`. Essentially pass the hard work to `IXMLDOMNamedNodeMap_removeNamedItem`. Use the fact, that attribute names are unique in elements. One case that isn't checked is wheter or not the value of the provided attribute match with the one stored in the dom-element. This MR implements according to the tests introduced in https://gitlab.winehq.org/wine/wine/-/merge_requests/8928 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9056

3 4

[PATCH 0/3] MR9032: Draft: opengl32: Support wow64 buffer storage and persistent memory mapping using Vulkan.
by Jacek Caban (＠jacek) 26 Sep '25

26 Sep '25

I'm opening this MR as an RFC. It's an initial attempt to support OpenGL persistent memory mapping in the new wow64. The implementation is not complete yet (details below), but it's intentionally kept as simple as possible for a proof of concept. Since we can't control where OpenGL maps memory, the idea is to use the available Vulkan extension with enough glue between them. Because of how GL–VK interop works, this requires creating a memory object on the Vulkan side and importing it into OpenGL. Once that's done, all operations on such buffers are performed through GL, except for mapping, which is handled by Vulkan. This is achieved by hooking `gl*BufferStorage` and reimplementing it on top of `glImportMemoryFdEXT` for mappable buffers. Recently introduced buffer wrappers make further tracking of these buffers straightforward. If we move forward with this, the feature will need to be enabled based on available driver capabilities (for now, it's force-enabled). Some parts might also be worth moving into win32u. This alone seems enough to claim persistent memory support and thus expose OpenGL 4.6 on the new wow64. Performance looks good in my limited testing, although that hasn't been a focus yet. Possible improvements include: - Currently only GL buffers created with `gl*BufferStorage` are affected. Other cases still fall back to the slow memcpy path. - The draft just picks the first host-visible coherent memory type exposed by Vulkan. We could try harder to pick an optimal type taking into account GL flags. - The draft allocates a new Vulkan memory and fd for each mapped buffer. This is inefficient for small buffers, for which a suballocator could help. - The draft always picks the first GPU reported by Vulkan. We may need to ensure that the selected device matches the one OpenGL actually uses. An alternative would be a new OpenGL extension. A driver-level solution could be more efficient, and it would certainly be nice to have. However, since such an extension doesn't exist yet, and even if we have it soon, I think it's still valuable to have a fallback solution that works with existing drivers. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9032

3 5

Re: [PATCH v2 0/1] MR9057: shell32 shlwapi: Call of ShellMessageBoxW works like Windows 11.
by Jinoh Kang (＠iamahuman) 26 Sep '25

26 Sep '25

Jinoh Kang (@iamahuman) commented about dlls/shell32/shell32.spec: > 179 stdcall -ordinal SHGetNewLinkInfoA(str str ptr ptr long) > 180 stdcall -ordinal SHGetNewLinkInfoW(wstr wstr ptr ptr long) > 181 stdcall -noname RegisterShellHook(long long) > - 182 varargs -ordinal ShellMessageBoxW(long long wstr wstr long) > + 182 varargs -private ShellMessageBoxW(long long wstr wstr long) shlwapi.ShellMessageBoxW Please add a test (in dlls/shlwapi/tests/) that shows `GetProcAddress(hDLLShell32, "ShellMessageBoxW") == GetProcAddress(hDLLShlwapi, "ShellMessageBoxW")`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9057#note_116874

1 0

Re: [PATCH v2 0/1] MR9057: shell32 shlwapi: Call of ShellMessageBoxW works like Windows 11.
by Jinoh Kang (＠iamahuman) 26 Sep '25

26 Sep '25

On Fri Sep 26 12:12:08 2025 +0000, Matthias Zorn wrote: > I programmed it with the MinGW compilers (mingw32 and mingw64) in MSYS2. > I tested the program on Windows 2000, Windows XP, Windows 7, and Windows > 11. The program runs on Windows 7 and Windows 11: > ![windows11.png](/uploads/90fff4868e9cacc3a6d1bc209a08e94e/windows11.png){width=278 > height=251} > When I start the program with Windows 2000 or Windows XP, I only get the > following error message: > ![windowsxp.PNG](/uploads/cfbc137637f6ef774bec1eb7d47b5355/windowsxp.PNG) Great, thanks! -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9057#note_116872

1 0

Re: [PATCH v2 0/1] MR9057: shell32 shlwapi: Call of ShellMessageBoxW works like Windows 11.
by Jinoh Kang (＠iamahuman) 26 Sep '25

26 Sep '25

Jinoh Kang (@iamahuman) commented about dlls/shlwapi/shlwapi.spec: > 385 stub -noname SHLoadRawAccelerators > 386 stub -noname SHQueryRawAccelerator > 387 stub -noname SHQueryRawAcceleratorMsg > -388 varargs -ordinal ShellMessageBoxWrapW(long long wstr wstr long) > +388 varargs ShellMessageBoxW(long long wstr wstr long) The CI tests are not passing due to the following build failure: ``` ../dlls/shlwapi/ordinal.c:3988:13: error: 'ShellMessageBoxW' redeclared without dllimport attribute: previous dllimport ignored [-Werror=attributes] 3988 | INT WINAPIV ShellMessageBoxW(HINSTANCE hInstance, HWND hWnd, LPCWSTR lpText, | ^~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make: *** [Makefile:151583: dlls/shlwapi/x86_64-windows/ordinal.o] Error 1 ``` To fix this, can you keep the ShellMessageBoxWrapW name and use aliasing to export it as ShellMessageBox**W** (no Wrap)? Aliases look like this: ```suggestion:-0+0 388 varargs ShellMessageBoxW(long long wstr wstr long) ShellMessageBoxWrapW ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9057#note_116871

1 0

2025

2024

2023

2022

wine-gitlab September 2025