- Wine-GitLab - list.winehq.org

[PATCH v5 0/6] MR9061: cabinet: Add LZX compression support to FCI
by Eric Lasota (＠ejlasota) Sept. 27, 2025

Sept. 27, 2025

This adds LZX compression support to FCI. Most of the work for this was done here: https://github.com/elasota/liblzx The LZX compression code is based on the LZX compression code from wimlib with modifications to support the cabinet variant and streaming compression. Eric Biggers (the author of wimlib) has given permission to redistribute the modified LZX code under LGPLv2 terms: https://wimlib.net/forums/viewtopic.php?t=854 I've been testing this against some large data sets (dumped game assets, Visual Studio installation) with a test program and decompressing with 7-zip and diffs have been coming back OK. -- v5: cabinet: Fix missing malloc.h https://gitlab.winehq.org/wine/wine/-/merge_requests/9061

3 8

[PATCH v4 0/5] MR9061: cabinet: Add LZX compression support to FCI
by Eric Lasota (＠ejlasota) Sept. 27, 2025

Sept. 27, 2025

This adds LZX compression support to FCI. Most of the work for this was done here: https://github.com/elasota/liblzx The LZX compression code is based on the LZX compression code from wimlib with modifications to support the cabinet variant and streaming compression. Eric Biggers (the author of wimlib) has given permission to redistribute the modified LZX code under LGPLv2 terms: https://wimlib.net/forums/viewtopic.php?t=854 I've been testing this against some large data sets (dumped game assets, Visual Studio installation) with a test program and decompressing with 7-zip and diffs have been coming back OK. -- v4: cabinet: Use alloca instead of VLA https://gitlab.winehq.org/wine/wine/-/merge_requests/9061

2 5

[PATCH v3 0/4] MR9061: cabinet: Add LZX compression support to FCI
by Eric Lasota (＠ejlasota) Sept. 27, 2025

Sept. 27, 2025

This adds LZX compression support to FCI. Most of the work for this was done here: https://github.com/elasota/liblzx The LZX compression code is based on the LZX compression code from wimlib with modifications to support the cabinet variant and streaming compression. Eric Biggers (the author of wimlib) has given permission to redistribute the modified LZX code under LGPLv2 terms: https://wimlib.net/forums/viewtopic.php?t=854 I've been testing this against some large data sets (dumped game assets, Visual Studio installation) with a test program and decompressing with 7-zip and diffs have been coming back OK. -- v3: cabinet: Fix static asserts not compiling https://gitlab.winehq.org/wine/wine/-/merge_requests/9061

3 5

[PATCH v2 0/4] MR9061: cabinet: Add LZX compression support to FCI
by Eric Lasota (＠ejlasota) Sept. 27, 2025

Sept. 27, 2025

This adds LZX compression support to FCI. Most of the work for this was done here: https://github.com/elasota/liblzx The LZX compression code is based on the LZX compression code from wimlib with modifications to support the cabinet variant and streaming compression. Eric Biggers (the author of wimlib) has given permission to redistribute the modified LZX code under LGPLv2 terms: https://wimlib.net/forums/viewtopic.php?t=854 I've been testing this against some large data sets (dumped game assets, Visual Studio installation) with a test program and decompressing with 7-zip and diffs have been coming back OK. -- v2: cabinet: Fix static asserts not compiling https://gitlab.winehq.org/wine/wine/-/merge_requests/9061

2 4

[PATCH 0/3] MR9061: cabinet: Add LZX compression support to FCI
by Eric Lasota (＠ejlasota) Sept. 27, 2025

Sept. 27, 2025

This adds LZX compression support to FCI. Most of the work for this was done here: https://github.com/elasota/liblzx The LZX compression code is based on the LZX compression code from wimlib with modifications to support the cabinet variant and streaming compression. Eric Biggers (the author of wimlib) has given permission to redistribute the modified LZX code under LGPLv2 terms: https://wimlib.net/forums/viewtopic.php?t=854 I've been testing this against some large data sets (dumped game assets, Visual Studio installation) with a test program and decompressing with 7-zip and diffs have been coming back OK. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9061

2 3

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

Sept. 27, 2025

-- 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) Sept. 27, 2025

Sept. 27, 2025

-- 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 Sept. 27, 2025

Sept. 27, 2025

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

1 5

[PATCH v2 0/5] MR8394: Draft: Fix Clip Studio Paint crash with Windows 10 compatibility mode
by Ignacy Kuchciński Sept. 26, 2025

Sept. 26, 2025

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

1 7

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

Sept. 26, 2025

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) Sept. 26, 2025

Sept. 26, 2025

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) Sept. 26, 2025

Sept. 26, 2025

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) Sept. 26, 2025

Sept. 26, 2025

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) Sept. 26, 2025

Sept. 26, 2025

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) Sept. 26, 2025

Sept. 26, 2025

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

[PATCH 0/1] MR9041: msi: fix MsiEnumFeatures[AW]() by make it look at the correct registry
by Ratchanan Srirattanamet (＠ratchanan.sr) Sept. 26, 2025

Sept. 26, 2025

For some reason, MsiEnumFeaturesW() still look for the list of features in the registry key which Wine itself has not been writing to since commit af56e28f ("msi: Don't publish features to an invalid location."), authored in 2008. Make it look in the new registry location which is used by ACTION_PublishFeatures(). While we're at it, remove the helper function used only by MsiEnumFeaturesW(). A conformance test is added. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9041

3 2

[PATCH v2 0/1] MR9035: wbemprox: Use setupapi to enumerate video controllers.
by Tim Clem (＠tclem) Sept. 26, 2025

Sept. 26, 2025

So that we can access the correct device IDs. --- The EA launcher uses WMI to query system information to tie licenses to particular machines. It expects that a video controller's PNPDeviceID will be valid (i.e. something under CurrentControlSet\Enum), which it no longer is since we stopped using DXGI in d511872a3d0dce5148d23ce5cbf80c989d484b26 / !7450. That information is available from setupapi, which is presumably faster than DXGI (speed was the motivating factor for !7450 - see the original bug https://bugs.winehq.org/show_bug.cgi?id=38879) I'm all ears if there's a better way to associate the devices under CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318} with those that setupapi reads from ...\Enum, or if there's a way to get the stuff that's in ...\Class out of setupapi (e.g. the RAM and DAC type). -- v2: wbemprox: Use setupapi to enumerate video controllers. https://gitlab.winehq.org/wine/wine/-/merge_requests/9035

3 3

Re: [PATCH v2 0/1] MR9057: shell32 shlwapi: Call of ShellMessageBoxW works like Windows 11.
by Matthias Zorn (＠Matthias-Zorn.0178) Sept. 26, 2025

Sept. 26, 2025

On Thu Sep 25 22:36:32 2025 +0000, Jinoh Kang wrote: > Hello, thanks for your reply! > You built your program with MinGW, right? It seems MinGW has a problem > with shlwapi. > Does your program run correctly on Windows when built *with* MinGW? > Would you post a screenshot on Windows? 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) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9057#note_116867

1 0

[PATCH v3 0/2] MR9040: cmd: Allow DIR /Oxxx at the command line to override DIRCMD=/Oyyy set in the environment.
by Joe Souza (＠JoeS209) Sept. 26, 2025

Sept. 26, 2025

Fix regression, likely caused by me, where DIR /O options entered at the command line do not override any /O options that might be set in the DIRCMD environment variable. Fix is to reset applicable sort order state whenever /O is encountered in the options list. -- v3: cmd: Allow DIR /Oxxx at the command line to override DIRCMD=/Oyyy set in the environment. cmd/tests: Duplicate DIR /O tests, but specify parameters via DIRCMD environment variable. https://gitlab.winehq.org/wine/wine/-/merge_requests/9040

3 4

[PATCH v3 0/3] MR9036: wined3d: Conditionally update saved window state in fullscreen mode.
by Matteo Bruni (＠Mystral) Sept. 26, 2025

Sept. 26, 2025

For Assassin's Creed Syndicate. When switching from fullscreen to a smaller windowed resolution, it calls `SetWindowPos()` centering the window, then calls `ResizeTarget()` and finally `SetFullscreenState()`, and expects the window to preserve the position. Window style handling is a bit iffy because of the manipulation we do when entering fullscreen, but that's not really new. -- v3: dxgi/tests: Test window states tracking and restoration in fullscreen mode. https://gitlab.winehq.org/wine/wine/-/merge_requests/9036

4 7

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

Sept. 25, 2025

On Thu Sep 25 22:36:32 2025 +0000, Matthias Zorn wrote: > I wanted to program the PickIconDlg function for WineHQ, so I developed > a program under Windows that calls my own implementation of this > function (I called it PickIconDlg2). I looked at the source code of Wine > and got the impression that the ShellMessageBoxW function is already > implemented correctly and saw that this function is also called > internally by Wine under certain circumstances. I programmed > PickIconDlg2 to also use ShellMessageBoxW and was optimistic that the > program would run well under Wine. However, when I started the program > with Wine, it only displayed a long error message. The reason for the > program crash was that ShellMessageBoxW could not be called. So I tried > to modify ShellMessageBoxW so that the program would also run with Wine. > I compiled the program with mingw-w64 and it tried to call > ShellMessageBoxW in shlwapi.dll. Hello, thanks for your reply! You built your program with MinGW, right? It seems MinGW has a problem with shlwapi. Does your program run correctly on Windows when built *with* MinGW? Would you post a screenshot on Windows? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9057#note_116859

1 0

Re: [PATCH v2 0/1] MR9057: shell32 shlwapi: Call of ShellMessageBoxW works like Windows 11.
by Matthias Zorn (＠Matthias-Zorn.0178) Sept. 25, 2025

Sept. 25, 2025

I wanted to program the PickIconDlg function for WineHQ, so I developed a program under Windows that calls my own implementation of this function (I called it PickIconDlg2). I looked at the source code of Wine and got the impression that the ShellMessageBoxW function is already implemented correctly and saw that this function is also called internally by Wine under certain circumstances. I programmed PickIconDlg2 to also use ShellMessageBoxW and was optimistic that the program would run well under Wine. However, when I started the program with Wine, it only displayed a long error message. The reason for the program crash was that ShellMessageBoxW could not be called. So I tried to modify ShellMessageBoxW so that the program would also run with Wine. I compiled the program with mingw-w64 and it tried to call ShellMessageBoxW in shlwapi.dll. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9057#note_116855

1 0

Re: [PATCH v15 0/2] MR8367: shell32: Add shield icon.
by Joel Holdsworth (＠jhol) Sept. 25, 2025

Sept. 25, 2025

> And my prior patches have been asked for extensive changes, tests, etc, then someone else submits the EXACT same diff, and it passes with no commentary. You're not the first person I've heard complaining about this. It seems that patches from within Crossover have an easier time getting integrated because Julliard has an ongoing relationship with these engineers. If you're absolutely out of patience, I don't might doing some work on the graphics side, though I can't guarantee when I will have time to look at it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8367#note_116854

1 0

Re: [PATCH v15 0/2] MR8367: shell32: Add shield icon.
by James McDonnell (＠ElementalWarrior) Sept. 25, 2025

Sept. 25, 2025

> 16-color VGA palette I kind of just assumed the color palette would have been handled by gimp's ico export. So when I imported it into inkscape it would be correct. Which is why everything was a raster. > These should be a vector images I did not find a svg for the 16x16 icon. Just a png. Maybe I didn't look hard enough. > prevent blurriness I had to delete most of the feathered edge and put in a hard border for this icon to look remotely nice. The 16x16 icon did not want to export to ico well, hence why the right looks slightly different than the left. It even seemed to look different between different exports. I didn't think the 256 image was even exported... Yeah I thought this MR would just have been a quick (load some obvious 'missing' icon if the other icon is not present). I barely can get myself to work on this ticket, as it is rather frustrating when you try to match examples of existing source, to be told don't do it that way, because "I don't like it that way". And my prior patches have been asked for extensive changes, tests, etc, then someone else submits the EXACT same diff, and it passes with no commentary. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8367#note_116853

1 0

Re: [PATCH v15 0/2] MR8367: shell32: Add shield icon.
by Joel Holdsworth (＠jhol) Sept. 25, 2025

Sept. 25, 2025

On Thu Sep 25 07:31:33 2025 +0000, James McDonnell wrote: > Please review the svg changes again. Great progress indeed. A couple of points I spotted: * The 4-bit icons need to use only colors from the [16-color VGA palette](https://en.wikipedia.org/wiki/List_of_8-bit_computer_hardware_grap…. * The 4 and 8-bit icons need to be paletted, rather than RGB. * In the 16-4 image, it looks to me that the bottom right of the shield could use some tidy up in the pixel art. It looks slightly jagged. * The 48-32, 32-32 and 16-32 icons are raster images. These should be a vector images (the 16-32 is sometimes raster in some of the other icons). It is important to keep the lines properly aligned to the pixel grid to prevent blurriness with 1px thickness. Are these included in the Tango sources? This would have been done in the original Tango source, but if the size you need is not available, you can achieve the same thing by tweaking the geometry. If you look at the other Wine icons and turn on a pixel grid in Inkscape, you will see how they have been aligned to the pixel grid. * The 48-8 and 48-4 images do not have the ids attributes set, so they won't render out. * The 256-32 image (and 48-32, 32-32 and 16-32 vector images that I am requesting), do not have the invisible rectangle element with the id set to `<rect id="icon:32-32" height="32" width="32" y="236" x="440" style="fill:none" />`, so they won't render out either. [control.svg](https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/shell32… demonstrates these points most clearly. I know this is all very pedantic, but it's necessary to achieve best results. You can understand why my [original Tango icons project](https://www.omgubuntu.co.uk/2010/05/wine-icon-facelift-on-target-for-june-looks-immeasurably-better-already) took around 14-months to complete! I thought it would be done in a weekend. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8367#note_116852

1 0