- Wine-GitLab - list.winehq.org

[PATCH 0/1] MR10547: Increase the portability of unions
by Safocl Stollmannovic (＠safocl88) April 2, 2026

April 2, 2026

One special guarantee is made in order to simplify the use of unions: if a union contains several structures that share a common initial sequence (see below), and if the union object currently contains one of these structures, it is permitted to inspect the common initial part of any of them anywhere that a declaration of the complete type of the union is visible. Increase the portability of unions by using a common initial sequence. Also undefined behavior is fixed when the value of an object with automatic storage duration is used while it is indeterminate: ```c union U{ int i; struct {int i; int j;} s; }; U u; u.i = 42; // U::i is active member; u.s.j = 42; // U::s is the active member with initialized s.j, s.i is the indeterminate value; int i = u.s.i; // UB: accessing a value while it is indeterminate int i2 = u.i; // UB: U::i does not have the expected value, even if type-punning is supported ``` C-standart (ISO/IEC 9899:TC2 Committee Draft — May 6, 2005 WG14/N1124): > J.2 Undefined behavior > > — The value of an object with automatic storage duration is used while it is indeterminate (6.2.4, 6.7.8, 6.8). I'm not even sure that the original code would have type-punning behavior between a structure member (which is a member of a union) and a member of union of integer type. I also believe that not all compilers support this non-standard behavior, and while it's not undefined behavior in C, as it is in C++, it is unspecified behavior, which also makes it impossible to predict the program's behavior (the value of the data). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10547

3 4

[PATCH v2 0/2] MR10543: Change default dir to ~/.local/share/wine
by Fatih Bakal (＠Twig) April 2, 2026

April 2, 2026

I switched it to `~/.local/share/wine` to fit XDG. I will edit all the docs and what not if `~/.local/share/wine` is see fit by maintainers. Soo please let me know if it's fit or not ![winexdg](/uploads/cde0c4003db3beabc05ab334ce0c78a4/winexdg.webp){width=900 height=234} If $XDG_DATA_HOME isn't set on the machine + .local doesn't exist it uses the current `$HOME/.wine` Related issue (please see beforehand): https://bugs.winehq.org/show_bug.cgi?id=48955 -- v2: Stop hardcoding https://gitlab.winehq.org/wine/wine/-/merge_requests/10543

4 6

[PATCH 0/1] MR10548: po: update Polish translation
by Adam Markowski (＠AMark) April 2, 2026

April 2, 2026

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

2 1

[PATCH v6 0/4] MR10532: Draft: crypt32: Implement PFXExportCertStoreEx support
by Benoît Legat (＠blegat) April 2, 2026

April 2, 2026

Part 2 of my attempt to run the [Niko Home Control programming software](https://appdb.winehq.org/objectManager.php?sClass=application&iId… under Wine. This .NET application ends up calling \``PFXExportCertStoreEx` (or `PFXExportCertStore` ) since it redirects to it which is a stub at the moment. According to the [documentation](https://learn.microsoft.com/en-us/windows/win32/api/wincrypt…, if the `EXPORT_PRIVATE_KEYS` flag is set, we should export the private key as well. For this, we use `NCryptExportKey` which is part of `ncrypt` so we have to add `ncrypt` to the `Makefile.in` as well. For exporting, I used GnuTLS library. As it seems to be only available in the unix side, I added a helper in `unixlib.c`. **EDIT** Looking at the behavior of Windows with the tests, it seems that when `cert` is `NULL` we should not fail but instead produce a valid but empty `PKCS#12`. I changed this to reflect Windows' behavior. -- v6: Use advice from review comment https://gitlab.winehq.org/wine/wine/-/merge_requests/10532

2 4

[PATCH v2 0/2] MR10546: Draft: vbscript: Use indexed lookup for global functions.
by Francis De Brabandere (＠francisdb) April 2, 2026

April 2, 2026

Replace O(N) linear scans through `global_funcs[]` with O(log N) tree lookups for global function resolution. This affects `Global_GetRef`, `ScriptDisp_GetDispID`, `exec_global_code`, and `lookup_global_funcs` in the interpreter. Scripts that use `ExecuteGlobal` to dynamically generate functions (e.g. Visual Pinball's GLF framework generates ~1000 functions at startup) hit pathological O(N) scan behavior on every `GetRef` call and `GetDispID` lookup. With this change, `GetRef` dispatch over 1000 functions drops from 503ms to 58ms (**8.7×**), reaching parity with Windows (62ms). **Benchmark** (`bench_executeglobal.vbs`, 1000 dynamically created functions, best-of-3): | Benchmark | Before | After | Speedup | Windows | |-----------|--------|-------|---------|---------| | GetRef varied x100K | 503 ms | 58 ms | **8.7×** | 62 ms | | GetRef loop x200K | 292 ms | 82 ms | **3.6×** | 125 ms | | GetRef cached x200K | 35 ms | 35 ms | 1.0× | 85 ms | | Direct call x200K | 35 ms | 46 ms | ~1.0× | 31 ms | Depends on !10544 for the fast `vbs_wcsicmp` used in the tree comparator. -- v2: vbscript: Use indexed lookup for global functions. https://gitlab.winehq.org/wine/wine/-/merge_requests/10546

2 2

[PATCH 0/2] MR10546: Draft: vbscript: Use indexed lookup for global functions.
by Francis De Brabandere (＠francisdb) April 2, 2026

April 2, 2026

Replace O(N) linear scans through `global_funcs[]` with O(log N) tree lookups for global function resolution. This affects `Global_GetRef`, `ScriptDisp_GetDispID`, `exec_global_code`, and `lookup_global_funcs` in the interpreter. Scripts that use `ExecuteGlobal` to dynamically generate functions (e.g. Visual Pinball's GLF framework generates ~1000 functions at startup) hit pathological O(N) scan behavior on every `GetRef` call and `GetDispID` lookup. With this change, `GetRef` dispatch over 1000 functions drops from 503ms to 58ms (**8.7×**), reaching parity with Windows (62ms). **Benchmark** (`bench_executeglobal.vbs`, 1000 dynamically created functions, best-of-3): | Benchmark | Before | After | Speedup | Windows | |-----------|--------|-------|---------|---------| | GetRef varied x100K | 503 ms | 58 ms | **8.7×** | 62 ms | | GetRef loop x200K | 292 ms | 82 ms | **3.6×** | 125 ms | | GetRef cached x200K | 35 ms | 35 ms | 1.0× | 85 ms | | Direct call x200K | 35 ms | 46 ms | ~1.0× | 31 ms | Depends on !10544 for the fast `vbs_wcsicmp` used in the tree comparator. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10546

2 2

Re: [PATCH v46 0/1] MR10192: kernelbase: Handle extended length path prefix in GetLongPathNameW
by Vishnunithyasoundhar S (＠svishnunithyasoundhar) April 2, 2026

April 2, 2026

On Tue Mar 31 13:22:35 2026 +0000, Vishnunithyasoundhar S wrote: > changed this line in [version 37 of the diff](/wine/wine/-/merge_requests/10192/diffs?diff_id=256140&start_sha=7a130f62eca11da90ca6324b9232a523d61f70fa#6c845445f68f8d3b54ba3798c9bb9e781b28b2ec_2121_2120) good catch. fixed it thanks -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10192#note_134814

1 0

Re: [PATCH v46 0/1] MR10192: kernelbase: Handle extended length path prefix in GetLongPathNameW
by Vishnunithyasoundhar S (＠svishnunithyasoundhar) April 2, 2026

April 2, 2026

On Mon Mar 30 12:26:49 2026 +0000, Vishnunithyasoundhar S wrote: > I will take a look and address all the other comments too. Ty for the review I have addressed all ur comments @sgwaki Pls have a look thanks. Also currently, some tests that my code change didnt even touch are failing. Am I supposed to look into them too? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10192#note_134813

1 0

Re: [PATCH v46 0/1] MR10192: kernelbase: Handle extended length path prefix in GetLongPathNameW
by Vishnunithyasoundhar S (＠svishnunithyasoundhar) April 2, 2026

April 2, 2026

On Tue Mar 31 13:22:36 2026 +0000, Vishnunithyasoundhar S wrote: > changed this line in [version 37 of the diff](/wine/wine/-/merge_requests/10192/diffs?diff_id=256140&start_sha=7a130f62eca11da90ca6324b9232a523d61f70fa#6c845445f68f8d3b54ba3798c9bb9e781b28b2ec_2123_2123) done -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10192#note_134812

1 0

Re: [PATCH v46 0/1] MR10192: kernelbase: Handle extended length path prefix in GetLongPathNameW
by Vishnunithyasoundhar S (＠svishnunithyasoundhar) April 2, 2026

April 2, 2026

On Tue Mar 31 13:22:35 2026 +0000, Vishnunithyasoundhar S wrote: > changed this line in [version 37 of the diff](/wine/wine/-/merge_requests/10192/diffs?diff_id=256140&start_sha=7a130f62eca11da90ca6324b9232a523d61f70fa#ccbcb1301019e22467910d31043560ed0d42aafe_1350_1347) That's a good catch. Fixed it. Thanks -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10192#note_134811

1 0