- Wine-GitLab - list.winehq.org

Re: [PATCH v12 0/1] MR10461: Draft: vbscript: Implement IDispatch::GetTypeInfo for class instances.
by Francis De Brabandere (＠francisdb) April 2, 2026

April 2, 2026

put on draft because this introduces wcsicmp, should be reworked once !10544 is merged -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10461#note_134864

1 0

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