- Wine-GitLab - list.winehq.org

Re: [PATCH v8 0/1] MR9406: wined3d: texture.c split vulkan and opengl for cleaner clarity
by Stian Low (＠stianlow) Nov. 11, 2025

Nov. 11, 2025

On Tue Nov 11 21:10:06 2025 +0000, Elizabeth Figura wrote: > I think this is a good idea, and at one point I was trying to do > something similar. > There are some further changes we can make here—some code that doesn't > look GL-specific probably is, and some code like alpha fixup should > probably be shared. Also, some code can be modernized a bit. In the > interest of expediency I'm going to take the liberty of fixing it up > myself and resubmitting, rather than just reviewing, if that's not going > to be too much of a problem. The split method was very simple. Basically just searched for gl and vk keywords for the most part and copied and pasted them to the corresponding files in the same order if they contained rendering backend specific code. Agreed there are some methods that seemed only relevant for GL but left some as generic in texture.c if they contained no rendering backend specific code. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9406#note_121534

1 0

[PATCH 0/1] MR9420: gdiplus: add memory cleanup on matrix inversion failure
by Jiajin Cui (＠jin-king1) Nov. 11, 2025

Nov. 11, 2025

Added proper cleanup for allocated memory when matrix inversion fails in GdipDrawImagePointsRect function. Previously, if GdipInvertMatrix returned an error status, the function would return immediately without freeing the src_data buffer that was allocated earlier in the function, causing a memory leak. This fix ensures that src_data is properly freed before returning when matrix inversion fails, preventing memory leaks in error conditions. Signed-off-by: Jiajin Cui <cuijiajin(a)uniontech.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9420

3 2

[PATCH v5 0/1] MR9399: dlls/sane.ds: Fix setting resolution in user interface
by Bernd Herd (＠herdsoft) Nov. 11, 2025

Nov. 11, 2025

This is a merge request to solve a problem that became visible by this merge request from Ivan Lyugaev: https://gitlab.winehq.org/wine/wine/-/merge_requests/9184#note_121010 When used with a HP Officejet Pro 8600 N911a, it is no longer possible to choose a scan resolution other than 75 DPI. The reason is that the code always set the "source" option after the "resolution" option, and setting the "source" option resets the resolution on that scanner to 75 DPI, even if it is not changed. Sane services are implemented in hplip. On Debian: ``` apt source hplip sed -n '560,563p' hplip-3.22.10+dfsg0/scan/sane/ledm.c i = session->adf_resolutionList[0] + 1; while(i--) session->resolutionList[i] = session->adf_resolutionList[i]; } ps->currentResolution = session->resolutionList[1]; ``` This new commit changes two things: 1. The order in which parameters are set in sane is changed. A parameter called "source" is set earlier than all other parameters. 2. If a parameter derived from a combobox of named options is not changed, it is not set in sane to the same value again. This seems to solve the problem on the HP Officejet Pro 8600 N911a, but other sane backends might have more dependencies that might still need to be addressed. -- v5: dlls/sane.ds: Fix setting resolution in user interface https://gitlab.winehq.org/wine/wine/-/merge_requests/9399

3 2

Re: [PATCH v2 0/1] MR9414: Draft: shlwapi: Handling of "C:\...xx" in PathCanonicalize[AW].
by Thomas Csovcsity (＠thc13) Nov. 11, 2025

Nov. 11, 2025

On Tue Nov 11 17:51:22 2025 +0000, Elizabeth Figura wrote: > Nope, that's my bad, two very similar but different functions >_> No problem. Actually i do not see any side effects and can not image why it should. I would like to remove the draft label and wait for review. What is you recommendation? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9414#note_121529

1 0

Re: [PATCH v8 0/1] MR9406: wined3d: texture.c split vulkan and opengl for cleaner clarity
by Elizabeth Figura (＠zfigura) Nov. 11, 2025

Nov. 11, 2025

I think this is a good idea, and at one point I was trying to do something similar. There are some further changes we can make here—some code that doesn't look GL-specific probably is, and some code like alpha fixup should probably be shared. Also, some code can be modernized a bit. In the interest of expediency I'm going to take the liberty of fixing it up myself and resubmitting, rather than just reviewing, if that's not going to be too much of a problem. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9406#note_121528

1 0

[PATCH 0/1] MR9418: winex11.drv: use proper timestamp for X11 clipboard selection
by Jiajin Cui (＠jin-king1) Nov. 11, 2025

Nov. 11, 2025

1. Replace CurrentTime with actual server timestamp in clipboard selection ownership 2. Add get_server_time function to retrieve current X11 server timestamp by generating PropertyNotify event 3. Store selection timestamp globally for use in export_timestamp function 4. Maintain original window event mask when getting server time The previous implementation used CurrentTime (0) which can cause issues with X11 clipboard handling. Using a proper server timestamp ensures correct synchronization and prevents potential race conditions in clipboard ownership transfers. Signed-off-by: Jiajin Cui <cuijiajin(a)uniontech.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9418

3 4

Re: [PATCH v2 0/1] MR9414: Draft: shlwapi: Handling of "C:\...xx" in PathCanonicalize[AW].
by Elizabeth Figura (＠zfigura) Nov. 11, 2025

Nov. 11, 2025

On Tue Nov 11 13:38:17 2025 +0000, Thomas Csovcsity wrote: > Sorry i do not get it. I modified [PathCanonicalizeW from > dlls/kernelbase/path.c](https://gitlab.winehq.org/wine/wine/-/merge_request…. > It seems you refer to UrlCanonicalizeW, which does not call > PathCanonicalizeW. That is why i am not sure of the deleted UNC part in > the old code. Maybe i missed something. I would appreciate a detailed > hint to understand it. Nope, that's my bad, two very similar but different functions >_> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9414#note_121523

1 0

[PATCH v2 0/2] MR9425: vccorlib140: Implement helper functions for delegates/events.
by Vibhav Pant (＠vibhavp) Nov. 11, 2025

Nov. 11, 2025

-- v2: vccorlib140: Implement delegate helper functions. vccorlib140: Add stubs for delegate/EventSource helper functions. https://gitlab.winehq.org/wine/wine/-/merge_requests/9425

2 2

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

Nov. 11, 2025

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

3 3

[PATCH 0/6] MR9422: comctl32/rebar: Add a helper to draw the gripper.
by Zhiyi Zhang (＠zhiyi) Nov. 11, 2025

Nov. 11, 2025

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

3 7

[PATCH 0/1] MR9417: uxtheme/tests: Verify GetCurrentThemeName() returns Aero\Aero.msstyles on Windows
by nikita pushkarev (＠strudelll) Nov. 11, 2025

Nov. 11, 2025

## WINELINKING environment variable `WINELINKING` is an optional environment variable that controls how Wine installs its built-in (“fake”) DLLs into a Wine prefix.\ Instead of always copying the PE template into the prefix, Wine can: * create a symbolic link to the original PE file, * create a hard link to the original PE file, or * attempt a filesystem-level copy-on-write (reflink) clone. This can significantly reduce disk usage and speed up prefix creation on filesystems that support these features. `WINELINKING` is only consulted when installing built-in DLLs (the fake DLLs generated by `setupapi`). It does **not** affect how applications copy or install their own files inside the prefix. ### Supported values `WINELINKING` recognizes the following values: * `WINELINKING=sym`\ Wine attempts to create a **symbolic link** in the prefix that points to the original built-in PE file in the Wine installation. * `WINELINKING=hard`\ Wine attempts to create a **hard link** to the original built-in PE file, so both paths refer to the same underlying file on disk. * `WINELINKING=cow`\ Wine attempts a **copy-on-write (CoW) / reflink clone** of the original PE file. On filesystems that support extent cloning, this creates a logical copy that shares physical blocks until one of the copies is modified. If `WINELINKING` is not set, or set to any other value, Wine falls back to the traditional behavior: the built-in DLL is copied into the prefix with a normal write. Signed-off-by: Nikita strudelll(a)etersoft.ru -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9417

3 3

Re: [PATCH v2 0/1] MR9414: Draft: shlwapi: Handling of "C:\...xx" in PathCanonicalize[AW].
by Thomas Csovcsity (＠thc13) Nov. 11, 2025

Nov. 11, 2025

## Test results from test bot: - patch and test execution - https://testbot.winehq.org/JobDetails.pl?Key=160728 - 0128:path: 66853 tests executed (9 marked as todo, 0 as flaky, **0 failures**), 0 skipped. - test execution without patch - https://testbot.winehq.org/JobDetails.pl?Key=160713 - 0124:path: 66853 tests executed (9 marked as todo, 0 as flaky, **4 failures**), 0 skipped. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9414#note_121509

1 0

[PATCH 0/1] MR9414: Draft: shlwapi: Handling of "C:\...xx" in PathCanonicalize[AW].
by Thomas Csovcsity (＠thc13) Nov. 11, 2025

Nov. 11, 2025

## Description This is intended to solve https://bugs.winehq.org/show_bug.cgi?id=58129 Add tests for verification, which pass on my locale win10 machine. ##Todo - [] Removed UNC path check which seems okay, but i am not sure why it was introduced. git blame did not help me, therefore any hints or examples to test are welcome. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9414

3 3

[PATCH v3 0/1] MR9423: ntdll: Warn when environment block is too large, instead of removing it
by Martino Fontana (＠tinozzo123) Nov. 11, 2025

Nov. 11, 2025

This partially reverts commit d4920360bffddaa5923a8da0b15f3ad9a2a97e78. Windows does support environment blocks of unlimited sizes, which makes the reverted commit a workaround for (at least) one defective application. And it's a very invasive workaround: there are multiple applications that run on Wine, but expect the user to supply environment variables from the Unix side (e.g. DXVK). The change breaks these configurations on users who may not even use the defective application(s). So, instead of breaking configurations, just warn the user that there may be issues due to the large environment block. -- v3: ntdll: Warn when environment block is too large, instead of removing it https://gitlab.winehq.org/wine/wine/-/merge_requests/9423

2 1

[PATCH 0/1] MR9424: shell32: Support SHARD_PATHW in SHAddToRecentDocs().
by Hans Leidekker (＠hans) Nov. 11, 2025

Nov. 11, 2025

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54626 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9424

2 1

[PATCH v2 0/1] MR9423: ntdll: Warn when environment block is too large, instead of removing it
by Martino Fontana (＠tinozzo123) Nov. 11, 2025

Nov. 11, 2025

This partially reverts commit d4920360bffddaa5923a8da0b15f3ad9a2a97e78. Windows does support environment blocks of unlimited sizes, which makes the reverted commit a workaround for (at least) one defective application. And it's a very invasive workaround: there are multiple applications that run on Wine, but expect the user to supply environment variables from the Unix side (e.g. DXVK). The change breaks these configurations on users who may not even use the defective application(s). So, instead of breaking configurations, just warn the user that there may be issues due to the large environment block. -- v2: ntdll: Warn when environment block is too large, instead of removing it https://gitlab.winehq.org/wine/wine/-/merge_requests/9423

2 1

[PATCH 0/1] MR9423: ntdll: Warn when environment block is too large, instead of removing it
by Martino Fontana (＠tinozzo123) Nov. 11, 2025

Nov. 11, 2025

This partially reverts commit d4920360bffddaa5923a8da0b15f3ad9a2a97e78. Windows does support environment blocks of unlimited sizes, which makes the reverted commit a workaround for (at least) one defective application. And it's a very invasive workaround: there are multiple applications that run on Wine, but expect the user to supply environment variables from the Unix side (e.g. DXVK). The change breaks these configurations on users who may not even use the defective application(s). So, instead of breaking configurations, just warn the user that there may be issues due to the large environment block. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9423

2 1

[PATCH v12 0/5] MR9112: XCOPY and COPY should not attempt to copy a file to itself.
by Joe Souza (＠JoeS209) Nov. 11, 2025

Nov. 11, 2025

Current code attempts to copy a file to itself. File is not actually copied; instead, a file sharing error is received. This result is ugly and differs from native. Behavior now appears to be the same as native with changes in this MR . -- v12: xcopy: Don't attempt to copy a file to itself. xcopy/tests: Add test for XCOPY to self. xcopy: Fix leaked resource in an error case. https://gitlab.winehq.org/wine/wine/-/merge_requests/9112

4 7

[PATCH 0/1] MR9421: comdlg32/tests: Force console subsystem version 5.2.
by Hans Leidekker (＠hans) Nov. 11, 2025

Nov. 11, 2025

Fixes a regression from 6a11792e257914e83d1f3a34391aeff7a29ad25a. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9421

2 1

[PATCH 0/1] MR9337: combase: Add stub for CoGetSystemSecurityPermissions.
by Louis Lenders (＠xe) Nov. 11, 2025

Nov. 11, 2025

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58903 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9337

3 4

[PATCH 0/1] MR9419: kernel32: handle root path in wine_get_dos_file_name
by Jiajin Cui (＠jin-king1) Nov. 11, 2025

Nov. 11, 2025

Fixed path concatenation issue in wine_get_dos_file_name function when dealing with root paths. The function now checks if the buffer contains a root path using PathIsRootW and adjusts the concatenation offset accordingly. When the path is a root path, it skips the trailing backslash in the NT name to avoid double backslashes in the final path. Signed-off-by: Jiajin Cui <cuijiajin(a)uniontech.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9419

2 1

[PATCH v2 0/3] MR9357: winegstreamer: Add ARGB32 format support and use bottom-up for AVI videos.
by Akihiro Sagawa (＠sgwaki) Nov. 10, 2025

Nov. 10, 2025

A certain game application requires both. -- v2: winegstreamer: Always use bottom-up for AVI RGB videos. winegstreamer: Add ARGB32 format support for 32 bpp AVI videos. quartz/tests: Add tests for 32 bpp AVI videos. https://gitlab.winehq.org/wine/wine/-/merge_requests/9357

3 4

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

Nov. 10, 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. -- v7: ntdll: Resolve IO_REPARSE_TAG_MOUNT_POINT during path lookup. ntdll: Pass attr and nt_name down to lookup_unix_name(). server: Implement FSCTL_GET_REPARSE_POINT. https://gitlab.winehq.org/wine/wine/-/merge_requests/9293

2 6

Re: [PATCH v5 0/5] MR9355: windows.perception.stub: Implement IHolographicSpace_get_PrimaryAdapterId(). - approved
by Alexandre Julliard (＠julliard) Nov. 10, 2025

Nov. 10, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9355

1 0

Re: [PATCH v4 0/6] MR9403: vccorlib140: Implement stringification functions. - approved
by Alexandre Julliard (＠julliard) Nov. 10, 2025

Nov. 10, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9403

1 0