- Wine-GitLab - list.winehq.org

[PATCH v4 0/1] MR8914: msxml: IXMLDOMNamedNodeMap::getNamedItem to handle global namespace.
by Alistair Leslie-Hughes (＠alesliehughes) Nov. 3, 2025

Nov. 3, 2025

-- v4: msxml: IXMLDOMNamedNodeMap::getNamedItem to handle global namespace. https://gitlab.winehq.org/wine/wine/-/merge_requests/8914

2 1

[PATCH 0/1] MR9253: winemac.drv: Create window data for message-only windows.
by Tim Clem (＠tclem) Nov. 3, 2025

Nov. 3, 2025

Their surfaces may be used. --- x11drv already supports this (and we test for it in opengl32/tests/opengl.c:test_message_window). x11drv doesn't make an x11drv_win_data for message-only windows when they are initially created in X11DRV_create_win_data, but does later if a surface is requested (x11drv_client_surface_create -> create_client_window). I don't see much of a reason to do it lazily in macdrv. We won't make a Cocoa window for message-only windows in macdrv_create_win_data since the parent isn't the desktop, so we're really just allocating space for the macdrv_win_data. And plus opengl.c:macdrv_surface_create uses `get_win_data(hwnd)` as its check for whether a hwnd is in-process; we'd have to adjust that logic (and shuffle some things around in that function) if we were to have macdrv_client_surface_create potentially create a macdrv_win_data. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9253

3 2

[PATCH 0/1] MR9344: d2d1: Fix incorrect union member access in radial gradient brush
by Yeshun Ye (＠yeyeshun) Nov. 3, 2025

Nov. 3, 2025

Fixed union member misuse in d2d_brush_fill_cb() function where radial gradient brush processing incorrectly accessed brush->u.linear.gradient instead of brush->u.radial.gradient. Signed-off-by: YeshunYe <yeyeshun(a)uniontech.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9344

3 4

[PATCH v2 0/2] MR9323: user32: Fix loading comctl32 v5 after comctl32 v6 is loaded.
by Zhiyi Zhang (＠zhiyi) Nov. 3, 2025

Nov. 3, 2025

When comctl32 v6 is loaded and v6 manifest is disabled, comctl32 v5 should be used when creating a common control window. However, before this patch, GetModuleHandleW(L"comctl32") return a handle to comctl32 v6 in this case, so comctl32 v5 doesn't get loaded and creating comctl32 v5 windows fails. We need to check if comctl32 v5 is actually loaded by using GetModuleHandleW() with the absolute path of the comctl32 v5 dll. Fix Word 2010 file open dialog doesn't show a listview. -- v2: comctl32: Use a magic value to check if an image list is valid. comctl32/tests: Test image list interoperation with comctl32 v5 and v6. https://gitlab.winehq.org/wine/wine/-/merge_requests/9323

3 4

[PATCH 0/4] MR9323: user32: Fix loading comctl32 v5 after comctl32 v6 is loaded.
by Zhiyi Zhang (＠zhiyi) Nov. 3, 2025

Nov. 3, 2025

When comctl32 v6 is loaded and v6 manifest is disabled, comctl32 v5 should be used when creating a common control window. However, before this patch, GetModuleHandleW(L"comctl32") return a handle to comctl32 v6 in this case, so comctl32 v5 doesn't get loaded and creating comctl32 v5 windows fails. We need to check if comctl32 v5 is actually loaded by using GetModuleHandleW() with the absolute path of the comctl32 v5 dll. Fix Word 2010 file open dialog doesn't show a listview. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9323

3 8

[PATCH 0/1] MR9342: dxcore/tests: Do not test for 0 deviceID.
by Nikolay Sivov (＠nsivov) Nov. 3, 2025

Nov. 3, 2025

Apparently it does not have to be set on e.g. llvmpipe. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9342

3 2

[PATCH 0/1] MR9334: comctl32/tests: Terminate string literal by double null character (ASan).
by Bernhard Übelacker Nov. 3, 2025

Nov. 3, 2025

The TB_ADDSTRINGA expects the last string to be terminated by two null characters, to be able to detect the array end. [ASan report details](https://gitlab.winehq.org/bernhardu/wine/-/blob/asan-pe_2025-10-18… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9334

3 3

Re: [PATCH v5 0/6] MR9032: opengl32: Support wow64 buffer storage and persistent memory mapping using Vulkan.
by Re-a (＠Liverel) Nov. 3, 2025

Nov. 3, 2025

I have a laptop that supports up to OpenGL 4.2 and Vulkan 1.2, and also another laptop that supports OpenGL 4.6 and Vulkan 1.2, and still fix doesn't work on both laptops. Wine still falls back to the slow mapping; you can see it in the logs. What am I missing? Is there going to be an alternative that works on more systems at some point? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9032#note_120407

1 0

[PATCH 0/1] MR9341: ntdll/tests: Remove some noisy traces.
by Nikolay Sivov (＠nsivov) Nov. 2, 2025

Nov. 2, 2025

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

2 1

[PATCH v2 0/5] MR9340: d2d1/effect: Add a description for the Gaussian Blur effect.
by Nikolay Sivov (＠nsivov) Nov. 2, 2025

Nov. 2, 2025

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: d2d1/effect: Add property definitions for the Shadow effect. d2d1/tests: Reduce test run count for some tests. d2d1/effect: Add a description for the Arithmetic Composite effect. d2d1/effect: Add a description for the Point Specular effect. d2d1/effect: Add a description for the Gaussian Blur effect. https://gitlab.winehq.org/wine/wine/-/merge_requests/9340

2 5

Re: [PATCH v5 0/1] MR9303: ntdll/tests: Add NtRenameKey tests checking subkey after rename. - approved
by Nikolay Sivov (＠nsivov) Nov. 2, 2025

Nov. 2, 2025

This merge request was approved by Nikolay Sivov. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9303

1 0

[PATCH v2 0/1] MR9333: dwrite: Add explicit inline helper for whitespace checks.
by Nikolay Sivov (＠nsivov) Nov. 2, 2025

Nov. 2, 2025

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: dwrite: Add explicit inline helper for whitespace checks. https://gitlab.winehq.org/wine/wine/-/merge_requests/9333

2 1

Re: [PATCH v15 0/11] MR8857: Resource "Open with" association file programs shell32/New : winemenumgr - closed
by Allan Rémy Nov. 2, 2025

Nov. 2, 2025

This merge request was closed by Allan Rémy. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8857

1 0

[PATCH 0/4] MR9340: d2d1/effect: Add a description for the Gaussian Blur effect.
by Nikolay Sivov (＠nsivov) Nov. 2, 2025

Nov. 2, 2025

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

2 4

[PATCH 0/1] MR9339: winhttp/tests: Avoid buffer-overflow in WinHttpCreateUrl_test (ASan).
by Bernhard Übelacker Nov. 2, 2025

Nov. 2, 2025

The test sets in fill_url_components the dwPasswordLength to 8, therefore the memcpy copies 8 wide characters. But before this patch variable empty allocates just one wide character. [ASan report details](https://gitlab.winehq.org/bernhardu/wine/-/blob/asan-pe_2025-10-18… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9339

2 2

[PATCH 0/1] MR9338: itss: Avoid reading beyond buffer end in ITSProtocol_Start (ASan).
by Bernhard Übelacker Nov. 2, 2025

Nov. 2, 2025

[ASan report details](https://gitlab.winehq.org/bernhardu/wine/-/blob/asan-pe_2025-10-18… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9338

1 1

[PATCH v10 0/4] MR9330: Draft: PickiconDlg
by Matthias Zorn (＠Matthias-Zorn.0178) Nov. 2, 2025

Nov. 2, 2025

Added PickiconDlg dialog resources as a test -- v10: shell32: Implement PickIconDlg function https://gitlab.winehq.org/wine/wine/-/merge_requests/9330

3 7

[PATCH v4 0/5] MR9332: combase: Implement RoOriginateError.
by Vibhav Pant (＠vibhavp) Nov. 2, 2025

Nov. 2, 2025

-- v4: combase: Implement RoOriginateError(W) and GetRestrictedErrorInfo. https://gitlab.winehq.org/wine/wine/-/merge_requests/9332

2 5

[PATCH v3 0/5] MR9332: combase: Implement RoOriginateError.
by Vibhav Pant (＠vibhavp) Nov. 2, 2025

Nov. 2, 2025

-- v3: combase: Implement RoOriginateError(W) and GetRestrictedErrorInfo. combase: Implement Ro{Get,Set}ErrorReportingFlags. combase/tests: Add tests for GetRestrictedErrorInfo. combase/tests: Add tests for RoOriginateError(W). https://gitlab.winehq.org/wine/wine/-/merge_requests/9332

4 9

Re: [PATCH v5 0/6] MR9032: opengl32: Support wow64 buffer storage and persistent memory mapping using Vulkan.
by Shmerl (＠shmerl) Nov. 2, 2025

Nov. 2, 2025

FYI, it fixed performance for Vampire: The Masquerade — Redemption (dx7 era game that has to rely on wined3d). Thanks a lot! ![vtm_redemption](/uploads/914f5d7edeed82f4191af32b32fe869b/vtm_redemption.png) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9032#note_120381

1 0

[PATCH v4 0/6] MR9293: Reparse points, part 1.
by Elizabeth Figura (＠zfigura) Nov. 2, 2025

Nov. 2, 2025

As prescribed some time ago, this attempts to implement correct reparse behaviour simply without attempting at all to make reparse points resolvable Unix symlinks. A reparse point consists two files. For a file whose NT name is "foobar", the contents of the file or directory (and note that a reparse point *can* have arbitrary contents) is stored in a file or directory "foobar?". The contents of the reparse point are stored in a file "foobar*". Both * and ? are valid in POSIX filenames but not NT, so no collision should be possible. The actual file "foobar" does not exist in this case. This is to allow the case where there are no reparse points (which is most common) to work as it currently does, without any extra overhead to check for a reparse point. [Simply guarding this behind FILE_OPEN_REPARSE_POINT does not seem good enough to me; that flag is used for example by many builtin functions like MoveFile().] When failing to locate a path segment "foobar", we check for "foobar*" and attempt to parse and resolve that reparse point. Issues: (1) Since we are manipulating two files, are there any race conditions? I believe there are no meaningful races. Read/write races: - When setting a reparse point, we move the contents file out of the way last, so attempts to open the file before that will see a normal file. Attempts to read the reparse point might see a partial file, but we treat that as failure. - When removing a reparse point from a file, we move the contents file back first, so attempts to open or read will see a normal file. - When deleting a reparse point entirely, we delete the contents first, so attempts to open the file will see neither a normal file nor the contents of the symlink, and fail. Attempts to query attributes don't need to open the contents, only the data, which will either be present or not. Write/write races: - Races involving file deletion don't matter, because deletion doesn't take effect until all handles to an inode are closed. - If we try to simultaneously set the reparse point from two different threads, one will fail with no effect since we create the reparse data file with O_EXCL. - If we try to remove the reparse point while setting it, the contents won't be in the right place and we'll fail. - If we try to remove the reparse point from two different threads, one will fail to move the contents back or delete them. (2) How does this interact with hard links? Creating a hard link to an existing reparse point is not too hard to do; we can just hard link both the data file and the contents file. However, turning an existing hardlinked file into a reparse point cannot work. This is also a limitation of other approaches that have been proposed. For this reason I've elected to forbid hard link interaction for now. One alternative approach that would allow turning hardlinked files into reparse points would be to store the reparse data in xattr. This would be less portable though. -- v4: ntdll: Resolve IO_REPARSE_TAG_MOUNT_POINT during path lookup. https://gitlab.winehq.org/wine/wine/-/merge_requests/9293

2 7

[PATCH v2 0/5] MR9293: Reparse points, part 1.
by Elizabeth Figura (＠zfigura) Nov. 2, 2025

Nov. 2, 2025

As prescribed some time ago, this attempts to implement correct reparse behaviour simply without attempting at all to make reparse points resolvable Unix symlinks. A reparse point consists two files. For a file whose NT name is "foobar", the contents of the file or directory (and note that a reparse point *can* have arbitrary contents) is stored in a file or directory "foobar?". The contents of the reparse point are stored in a file "foobar*". Both * and ? are valid in POSIX filenames but not NT, so no collision should be possible. The actual file "foobar" does not exist in this case. This is to allow the case where there are no reparse points (which is most common) to work as it currently does, without any extra overhead to check for a reparse point. [Simply guarding this behind FILE_OPEN_REPARSE_POINT does not seem good enough to me; that flag is used for example by many builtin functions like MoveFile().] When failing to locate a path segment "foobar", we check for "foobar*" and attempt to parse and resolve that reparse point. Issues: (1) Since we are manipulating two files, are there any race conditions? I believe there are no meaningful races. Read/write races: - When setting a reparse point, we move the contents file out of the way last, so attempts to open the file before that will see a normal file. Attempts to read the reparse point might see a partial file, but we treat that as failure. - When removing a reparse point from a file, we move the contents file back first, so attempts to open or read will see a normal file. - When deleting a reparse point entirely, we delete the contents first, so attempts to open the file will see neither a normal file nor the contents of the symlink, and fail. Attempts to query attributes don't need to open the contents, only the data, which will either be present or not. Write/write races: - Races involving file deletion don't matter, because deletion doesn't take effect until all handles to an inode are closed. - If we try to simultaneously set the reparse point from two different threads, one will fail with no effect since we create the reparse data file with O_EXCL. - If we try to remove the reparse point while setting it, the contents won't be in the right place and we'll fail. - If we try to remove the reparse point from two different threads, one will fail to move the contents back or delete them. (2) How does this interact with hard links? Creating a hard link to an existing reparse point is not too hard to do; we can just hard link both the data file and the contents file. However, turning an existing hardlinked file into a reparse point cannot work. This is also a limitation of other approaches that have been proposed. For this reason I've elected to forbid hard link interaction for now. One alternative approach that would allow turning hardlinked files into reparse points would be to store the reparse data in xattr. This would be less portable though. -- v2: ntdll: Pass attr and nt_name down to lookup_unix_name(). server: Implement FSCTL_GET_REPARSE_POINT. server: Implement FSCTL_DELETE_REPARSE_POINT. server: Implement FSCTL_SET_REPARSE_POINT. ntdll/tests: Fix reparse test failures. https://gitlab.winehq.org/wine/wine/-/merge_requests/9293

2 5

[PATCH v2 0/2] MR9287: uxtheme: Handle NULL options in DrawThemeTextEx().
by Mohamad Al-Jaf (＠maljaf) Nov. 1, 2025

Nov. 1, 2025

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54927 -- v2: uxtheme/tests: Add some DrawThemeTextEx() tests. uxtheme: Handle NULL options in DrawThemeTextEx(). https://gitlab.winehq.org/wine/wine/-/merge_requests/9287

2 3

Re: [PATCH v5 0/6] MR9032: opengl32: Support wow64 buffer storage and persistent memory mapping using Vulkan.
by Jacek Caban (＠jacek) Nov. 1, 2025

Nov. 1, 2025

On Sat Nov 1 18:46:55 2025 +0000, QwertyChouskie wrote: > > Good point, thanks. It does seem possible to use that extension, but I > think we also need to support Nvidia. We could maybe have it as an > alternative, though I’m not sure there are cases where it would actually > help (that is, cases where the extension is available but a sufficient > Vulkan driver isn’t). > r600 (assuming it supports this extension) is certainly one case that > comes to mind for something that is reasonably performant for older > games but doesn't support Vulkan. It also turned out that llvmpipe doesn’t support VK_EXT_map_memory_placed, and GL_AMD_pinned_memory would be a good fit for it. I plan to give that a try. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9032#note_120365

1 0

[PATCH v2 0/1] MR9336: ntdll/tests: Fix reparse test failures.
by Elizabeth Figura (＠zfigura) Nov. 1, 2025

Nov. 1, 2025

-- v2: ntdll/tests: Fix reparse test failures. https://gitlab.winehq.org/wine/wine/-/merge_requests/9336

2 1