- Wine-GitLab - list.winehq.org

[PATCH 0/15] MR10531: opengl32: Just use Zink (as PE-side OpenGL implementation).
by Rémi Bernon (＠rbernon) April 2, 2026

April 2, 2026

This embeds the Mesa 26.0.3 subset needed to build Zink, as an OpenGL PE-side implementation over PE-side Vulkan. Steam and "Star Wars: Knights of the Old Republic" work, which means everything else will as well. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10531

7 21

[PATCH v11 0/1] MR10532: 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. -- v11: crypt32: Implement PFXExportCertStoreEx support https://gitlab.winehq.org/wine/wine/-/merge_requests/10532

2 1

[PATCH v3 0/5] MR10467: iyuv/tests: Add stub DLL and tests.
by Brendan McGrath (＠redmcg) April 2, 2026

April 2, 2026

This MR adds a stub for the `iyuv_32.dll` and tests its functionality. -- v3: iyuv_32/tests: Add a compression test. iyuv_32/tests: Add a decompression test. iyuv_32/tests: Test which formats are supported. iyuv_32/tests: Add test stub. iyuv_32: Add stub dll. https://gitlab.winehq.org/wine/wine/-/merge_requests/10467

4 10

[PATCH v9 0/1] MR10532: 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. -- v9: crypt32: Implement PFXExportCertStoreEx support https://gitlab.winehq.org/wine/wine/-/merge_requests/10532

2 1

[PATCH v8 0/1] 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. -- v8: crypt32: Implement PFXExportCertStoreEx support https://gitlab.winehq.org/wine/wine/-/merge_requests/10532

2 1

[PATCH 0/3] MR10545: Add LGPL license exception to some C runtime files.
by Alexandre Julliard (＠julliard) April 2, 2026

April 2, 2026

When building an application or library with Wine, a few C runtime files get linked directly into the resulting binary. Since these files are under the LGPL, it means that the application would technically need to be distributed as object files to allow relinking. This is an onerous burden to impose, for a very small amount of LGPL code. Thus I propose that we relax the LGPL requirements by applying the GCC Runtime Library Exception to these few files. This is similar to what glibc is doing for its crt0 files. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10545

7 8

[PATCH v7 0/6] 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. -- v7: Fix Fix https://gitlab.winehq.org/wine/wine/-/merge_requests/10532

2 6

[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 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

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_1347_1347) haaa I see. Anyway my tests are passing so I have removed the todo_wine. Thanks for the clarification -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10192#note_134810

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_1343_1341) switched with dirname -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10192#note_134809

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_1333_1333) done -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10192#note_134808

1 0

[PATCH 0/1] 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} Related issue: https://bugs.winehq.org/show_bug.cgi?id=48955 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10543

4 7

[PATCH v2 0/1] MR10485: vbscript: Return proper errors for orphan Loop and Next keywords.
by Francis De Brabandere (＠francisdb) April 2, 2026

April 2, 2026

When Loop or Next appear outside their enclosing Do/For blocks, Windows returns specific error codes: 1038 ("loop without do") and 1055 ("unexpected Next"). Detect these tokens in parser_error() and set the proper HRESULT instead of the generic E_FAIL. -- v2: vbscript: Return proper errors for orphan Loop and Next keywords. https://gitlab.winehq.org/wine/wine/-/merge_requests/10485

2 1

[PATCH 0/1] MR10385: magnification: Add stub for MagInitialize.
by Louis Lenders (＠xe) April 2, 2026

April 2, 2026

This was reported at the forum for the game "War at Spain". Forum link: https://forum.winehq.org/viewtopic.php?t=42629 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10385

2 2

[PATCH v13 0/2] MR10460: msvcrt: Add support for %Z printf specifier.
by Trung Nguyen (＠trungnt2910) April 2, 2026

April 2, 2026

This specifier allows printing the `UNICODE_STRING` and `ANSI_STRING` structures. It is useful for running unit tests for kernel mode or shared components on WINE. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59563 -- v13: msvcrt/tests: Add tests for %Z printf specifier. msvcrt: Add support for %Z printf specifier. https://gitlab.winehq.org/wine/wine/-/merge_requests/10460

3 4

[PATCH v5 0/3] 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. -- v5: Minimal valid https://gitlab.winehq.org/wine/wine/-/merge_requests/10532

3 4

[PATCH v2 0/1] MR10544: vbscript: Use ASCII-only case-insensitive compare for identifier lookups.
by Francis De Brabandere (＠francisdb) April 2, 2026

April 2, 2026

VBScript identifiers are ASCII-only, Windows rejects all non-ASCII characters (Latin-1, Cyrillic, CJK) at the lexer level with error 1032 "Invalid character". Replace the locale-aware `wcsicmp()` with an inline ASCII-only `vbs_wcsicmp()` for all identifier comparisons. This avoids the expensive locale grab/free cycle (`get_current_locale_noalloc`/`free_locinfo`) that dominated profiling at 87–95% of CPU time in identifier lookup paths. Also restrict the lexer's `is_identifier_char()` and identifier-start check to ASCII-only, matching Windows behavior. Tests added for non-ASCII character rejection (é, ß, ü, Cyrillic) in identifiers. ### Benchmark results (best-of-3, before → after) | Benchmark | Before | After | Change | |---|---:|---:|---:| | Class prop read ×500k | 2558 ms | 160 ms | **−93.7%** | | GetRef loop ×200k | 15988 ms | 296 ms | **−98.1%** | | Empty For 10M | 4808 ms | 242 ms | **−95.0%** | | Nested For 10M | 6367 ms | 253 ms | **−96.0%** | | Local vars 10M | 9437 ms | 390 ms | **−95.9%** | | Dict.Exists ×100k | 300 ms | 113 ms | **−62.3%** | | If boolvar 10M | 7882 ms | 988 ms | **−87.5%** | | String concat ×2000 | 78 ms | 70 ms | −10.3% | Identifier-heavy operations see **10–50× speedups**. String concat (I/O-bound, not lookup-bound) is unchanged as expected. -- v2: vbscript: Use ASCII-only case-insensitive compare for identifier lookups. https://gitlab.winehq.org/wine/wine/-/merge_requests/10544

2 1