June 2026 - Wine-GitLab - list.winehq.org

[PATCH v3 0/1] MR11268: crypt32: Avoid conflict between unnamed containers
by Benoît Legat (＠blegat) June 30, 2026

June 30, 2026

Part 5 of my attempt to run the [Niko Home Control programming software](https://appdb.winehq.org/objectManager.php?sClass=application&iId… under Wine. Fixes the following bug: 1. First PFXImport: CryptAcquireContextW(NULL container, CRYPT_NEWKEYSET) -\> CSP creates container "blegat" (the default user name) and imports key K1 into it. set_key_prov_info then writes pwszContainerName="blegat" onto cert1. 2. Second PFXImport: same call fails with NTE_EXISTS (the default container already exists), the existing retry opens it without CRYPT_NEWKEYSET, then CryptImportKey writes K2 into that container, overwriting K1. set_key_prov_info writes pwszContainerName="blegat" onto cert2. 3. State: container "blegat" holds K2. Cert1's CRYPT_KEY_PROV_INFO.pwszContainerName still says "blegat". Anyone asking "what's cert1's private key?" reads its container name, opens "blegat", and gets K2, the second cert's key. I followed the UUID creation pattern from `CRYPT_CreateKeyProv` to stay consistent with existing code in Wine. I added a test, without the change, the tests fail with ``` store.c:1107: Test marked todo: CertOpenStore failed: 00000006 store.c:505: Test marked todo: Cert was not saved in AppData at 3 (3) store.c:2139: Test marked todo: Store registration (dwFlags=00040000) failed, last error 0 store.c:2143: Tests skipped: Nothing to test without registered store at 00040000 store.c:2139: Test marked todo: Store registration (dwFlags=00090000) failed, last error 0 store.c:2143: Tests skipped: Nothing to test without registered store at 00090000 store.c:389: Test marked todo: file store -> system store: expected size 188, got 156 store.c:398: Test marked todo: file store -> system store: unexpected value store.c:2864: Test marked todo: Unexpected cert3 store.c:3583: Test failed: two PFX imports collided into the same container L"blegat" â the second import would have overwritten the first cert's private key 0020:store: 651 tests executed (7 marked as todo, 0 as flaky, 1 failure), 2 skipped. ``` And after the fix, the tests pass ``` store.c:1107: Test marked todo: CertOpenStore failed: 00000006 store.c:505: Test marked todo: Cert was not saved in AppData at 3 (3) store.c:2139: Test marked todo: Store registration (dwFlags=00040000) failed, last error 0 store.c:2143: Tests skipped: Nothing to test without registered store at 00040000 store.c:2139: Test marked todo: Store registration (dwFlags=00090000) failed, last error 0 store.c:2143: Tests skipped: Nothing to test without registered store at 00090000 store.c:389: Test marked todo: file store -> system store: expected size 188, got 156 store.c:398: Test marked todo: file store -> system store: unexpected value store.c:2864: Test marked todo: Unexpected cert3 0020:store: 651 tests executed (7 marked as todo, 0 as flaky, 0 failures), 2 skipped. ``` -- v3: crypt32: Avoid conflict between unnamed containers https://gitlab.winehq.org/wine/wine/-/merge_requests/11268

3 3

[PATCH 0/1] MR11285: winex11: Use the desired state for mapping delays.
by Rémi Bernon (＠rbernon) June 30, 2026

June 30, 2026

This matches the state the host window is supposed to be in, whereas pending_state is the state we have requested yet but which may need further requests. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59932 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11285

2 1

[PATCH v7 0/5] MR11173: server: Update window zorder directly in queue_mouse_message.
by Rémi Bernon (＠rbernon) June 30, 2026

June 30, 2026

Instead of using an extra request on every mouse motion event. -- v7: winex11: Remove now unnecessary update_window_zorder call. winemac: Remove now unnecessary update_window_zorder call. wineandroid: Remove now unnecessary update_window_zorder call. server: Update window zorder directly in queue_mouse_message. server: Map update_window_zorder rect from raw to virtual coordinates. https://gitlab.winehq.org/wine/wine/-/merge_requests/11173

2 5

Re: [PATCH v6 0/5] MR11173: server: Update window zorder directly in queue_mouse_message.
by Rémi Bernon (＠rbernon) June 30, 2026

June 30, 2026

v3: Check the capture window directly in wineserver, remove the unnecessary code entirely in the drivers. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11173#note_144519

1 0

[PATCH v3 0/1] MR11204: hidclass: Return the full report length from IOCTL_HID_WRITE_REPORT.
by Thomas Portal (＠OursCodeur) June 30, 2026

June 30, 2026

### What WriteFile on a numbered HID output report returns one byte less than the buffer the application submitted. hidclass subtracts the report ID byte from the transfer length on the IOCTL_HID_WRITE_REPORT path (`params->padding = 1 - offset`). Windows returns the full length with the report ID byte included. ### Why it matters An application that watches the WriteFile return value to advance an upload never makes progress. The Elgato Stream Deck desktop app hits this: its per-key image upload resends the first page forever because the count it gets back is always one short, so the keys never render. Removing the subtraction lets the upload finish and the keys draw. ### How I checked the Windows behaviour A small Win32 probe writes an OutputReportByteLength buffer to the device and reads back the count. On Windows OutputReportByteLength is 1024 and WriteFile returns 1024. hidapi uses the same convention: hid_write returns report length + 1 (the report ID byte) for a numbered report. ### The test test_write_file already asserts the Windows value (a numbered report returns report_len), and it passes on Windows. It also passed on Wine, for the wrong reason. The mock bus driver returns report_len + 1, and the hidclass subtraction cancelled the extra byte. A real minidriver returns the bytes it wrote, which is report_len, so nothing cancels the subtraction and the WriteFile result is short by one. This sets the mock's returned length to report_len, matching what a real bus reports, and drops the padding. The asserted WriteFile results do not change (report_len for both numbered and unnumbered reports). Only the mock's intermediate value and the hidclass compensation change. The hid test passes with both changes and no failures. Reverting the hidclass change on its own turns test_write_file red, so the test guards the behaviour directly. For history: 94e5945102 (2021) introduced the subtraction, and a7d67c1c90 (2022) carried it forward as the padding field during the async rewrite. Signed-off-by: Thomas Portal portal.thomas(a)protonmail.com -- v3: hidclass: Return the full report length from IOCTL_HID_WRITE_REPORT. https://gitlab.winehq.org/wine/wine/-/merge_requests/11204

3 3

Re: [PATCH 0/1] MR11284: kernel32/tests: Test filename case preservation when opening existing file.
by Paul Gofman (＠gofman) June 30, 2026

June 30, 2026

Commit af35741d3681f21222a85900b54d95ee422fe074 regressed Dishonored - Definitive Edition which now not saving settings. It actually saves those as SETTINGS.sav file, but then when it opens it as "SETTINGS.SAV" and then GetGetFinalPathNameByHandleW() returns "SETTINGS.SAV" and not "SETTINGS.sav" it is unhappy and writes initial settings over. There are different aspects how this change regresses the filename read back. I started fixing that locally and fixed some aspects of that, but then realized that I am not sure which overall direction will be preferred. One side aspect is that now renaming file (e. g., with MoveFileW, as also covered by this test) does not change open file NT name (as it is different handle). This is possible to address by traversing all the files from the same inode in the server and changing NT name in each. Then, fixing up different case in lookup_unix_name(), when it takes part by part path, is also straigtforwatd, the name read from directory can easily fixup NT name (replacing attr->ObjectName with nt_name same way as it is done for reparse point translation and trailing slash removal). But then on case-insensitive FS this path is not taken and shortcut file open path in lookup_unix_name() succeeds while NT name may differ in case (the same may happen in find_file_in_dir). My test case, been locally fixed for case-sensitive Linux FS expectedly fails again in the Wine prefix created in case-insensitive fs ("mkfs.ext4 -O casefold -E encoding=utf8 /dev/..."). Now it looks like the only way is getting Unix file na me for the found file similar to how that was done back then in server's fd.c:set_unix_name_of_fd() (now that is removed), which reads /proc/self/fd/ on Linux to get the path or uses fcntl( F_GETPATH ) elsewhere. On top of that (this is currently not covered by this test but I tested separately), creating file with "c:\\<path>" still results in uppercase "C" on Windows (while not in Wine currently, drive part also inherits requested path). Doing these parts (especially the last one) seems like largely re-introducing removed unix_to_nt_file_name() logic. So I am not sure, maybe instead of trying to fix all these various parts it is better to essentially revert offending commit in some way, re-implementing file name queries from server unix file name instead of relying on user provided NT file name anyhow? Also, while this is probably not directly related here, IIRC NtQueryObject() does not return file names at all on Windows, that is not mapped as kernel objects and is something for NtQueryInformationFile(), so maybe unifying file name query in wineserver this way is not too much useful going forward? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11284#note_144509

1 0

[PATCH v7 0/2] MR11135: win32u/tests: add test for swp_owner_popups self-reference fix
by Jiajin Cui (＠jin-king1) June 30, 2026

June 30, 2026

Add test_swp_owner_popups to verify that swp_owner_popups restores initial_after when it becomes the window itself. When an owned popup is immediately above its owner in z-order and is moved after the owner, the function incorrectly sets after = hwnd (self-reference). The fix restores initial_after, and the test verifies this via WM_WINDOWPOSCHANGED hwndInsertAfter capture. Change-Id: I1f63fc4046d65ea767beafbcae4f6f26b25a26ba Signed-off-by: Jiajin Cui <cuijiajin(a)uniontech.com> -- v7: win32u: restore initial after value in swp_owner_popups win32u/tests: add test for swp_owner_popups self-reference fix https://gitlab.winehq.org/wine/wine/-/merge_requests/11135

2 3

[PATCH v2 0/1] MR11269: kernelbase: implement ReadConsoleInputEx
by Deep Agrawal (＠de-ep) June 29, 2026

June 29, 2026

Wine Bug: https://bugs.winehq.org/show_bug.cgi?id=58252 Let me know if this needs any improvement! -- v2: kernelbase: implement ReadConsoleInputEx https://gitlab.winehq.org/wine/wine/-/merge_requests/11269

3 2

Re: [PATCH v2 0/4] MR10967: Prefer builtin for d3d helper libraries.
by Elizabeth Figura (＠zfigura) June 29, 2026

June 29, 2026

> I realize that there might be other considerations why preferring builtin might still be making sense, but it seems to me the argument for forcing builtin for the purpose of easier getting aware of builtin bugs is a bit counter-intuitive, it reads to me like adding a hack, and, curiously, with the purpose to break things intentionally. This was never my primary intention, no. I do enjoy working on the HLSL compiler, but my comment above was not meant to be taken as an actual rationale for this patch series. Rather, see !10943 and !10955. Essentially, I found it odd that prefer-native was present in some places where native either surely couldn't work or wasn't redistributable, and wanted to remove them. In response Alexandre expressed a preference to get rid of prefer-native entirely. I understand this to indeed mean a preference for all DLLs to be builtin even when the Microsoft DLL is redistributable, and I suppose this is a philosophical difference (whether Wine's goal is simply to run programs, or whether it is to reimplement win32). I don't personally have much of an opinion on that question, but I saw no reason not to do what the maintainer requested in regards to a simple task. It was my intention to keep sending patches and eventually remove most if not all prefer-native annotations, although for various reasons I haven't done so for a couple weeks. On the other hand, seeing as there's some pushback, I'll hold off for now, at least for the DLLs that frequently get redistributables... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10967#note_144499

1 0

Re: [PATCH v2 0/4] MR10967: Prefer builtin for d3d helper libraries.
by Paul Gofman (＠gofman) June 29, 2026

June 29, 2026

On Mon Jun 29 20:01:03 2026 +0000, Paul Gofman wrote: > Note also that technically preferring builtin when native should be > loaded according to dll path resolution rules is functionally wrong > behaviour: it introduces difference between the dll present on disk (at > the loaded dll path) and the actual memory image, certain things might > be unhappy about that. There are some native dlls which have no chances > of working by present design (like native MS d3d dlls) and where there > is just no point to load that, but in the other cases (like d3d helper > libraries, MSVC runtime libraries) isn't replacing that with builtin is > just functionally wrong? I realize that there might be other considerations why preferring builtin might still be making sense, but it seems to me the argument for forcing builtin for the purpose of easier getting aware of builtin bugs is a bit counter-intuitive, it reads to me like adding a hack, and, curiously, with the purpose to break things intentionally. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10967#note_144497

1 0