- Wine-GitLab - list.winehq.org

Re: [PATCH v6 0/2] MR10324: win32u: Fix deadlock when setting hdc_src to the window's self DC. - approved
by Alexandre Julliard (＠julliard) April 2, 2026

April 2, 2026

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

1 0

Re: [PATCH v14 0/2] MR10460: msvcrt: Add support for %Z printf specifier. - approved
by Alexandre Julliard (＠julliard) April 2, 2026

April 2, 2026

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

1 0

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

April 2, 2026

Replace O(N) linear scans through `global_funcs[]` and `global_vars[]` with O(log N) tree lookups for global function and variable resolution. **Global functions:** 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.7x**), reaching parity with Windows (62ms). | Benchmark (1000 dynamic functions) | Before | After | Speedup | Windows | |-----------|--------|-------|---------|---------| | GetRef varied x100K | 503 ms | 58 ms | **8.7x** | 62 ms | | GetRef loop x200K | 292 ms | 82 ms | **3.6x** | 125 ms | | GetRef cached x200K | 35 ms | 35 ms | 1.0x | 85 ms | | Direct call x200K | 35 ms | 46 ms | ~1.0x | 31 ms | **Global variables:** Profiling a real-world 75K-line table script with 3000+ global variables (registered via multiple `ExecuteGlobal` calls) shows `lookup_identifier`'s linear scan over `global_vars[]` consuming ~55% of total CPU time. Compile-time binding (`bind_local`) does not help here because it only resolves variables declared within the same compilation unit, variables from prior `ExecuteGlobal` calls remain unbound at runtime. Depends on !10544 for the fast `vbs_wcsicmp` used in the tree comparators. -- v3: vbscript: Use indexed lookup for global variables. https://gitlab.winehq.org/wine/wine/-/merge_requests/10546

2 3

[PATCH v8 0/7] MR10515: vbscript: Bind local variables, class properties, and loop variables at compile time.
by Francis De Brabandere (＠francisdb) April 2, 2026

April 2, 2026

Resolve identifiers to direct indices during compilation instead of doing runtime `wcsicmp` string scans in `lookup_identifier()`. This adds new opcodes that access local variables, function arguments, class properties, and loop variables by index, eliminating the linear string comparison overhead for the most common cases. **New opcodes:** - `OP_local` / `OP_assign_local` / `OP_set_local` - read/write local vars and args by index - `OP_local_prop` / `OP_assign_local_prop` / `OP_set_local_prop` - read/write class properties by index - `OP_step_local` / `OP_incc_local` - For-loop step/increment with indexed counter - `OP_enumnext_local` - For-Each iteration with indexed loop variable This mirrors jscript's `OP_local` / `bind_local()` optimization (`dlls/jscript/compile.c`) and addresses the FIXME in `lookup_identifier()` noting that class property access should be bound at compile time. Names that cannot be resolved at compile time (globals in Execute/ExecuteGlobal code, dynamic vars, host objects) continue to use the existing string-based path. The last commit also adds a fast path for SAFEARRAY iteration that bypasses the `IEnumVARIANT` COM vtable dispatch and copies elements directly from the array data, eliminating one intermediate `VariantCopy` per iteration. ### Local variable / argument / class property access (1M iterations, 10 reads per iteration) | Benchmark | Windows (VM) | Wine master | Wine (7 commits) | **Speedup** | vs Windows | |-----------|-------------|-------------|-------------------|---------|------------| | Local vars | 156 ms | 10,134 ms | 960 ms | **10.6x** | 6.2x slower | | Arguments | 171 ms | 6,656 ms | 968 ms | **6.9x** | 5.7x slower | | Class props | 265 ms | 6,673 ms | 964 ms | **6.9x** | 3.6x slower | ### For-loop variants (10M iterations) | Benchmark | Windows (VM) | Wine master | Wine (7 commits) | **Speedup** | vs Windows | |-----------|-------------|-------------|-------------------|---------|------------| | Empty For | 117 ms | 6,222 ms | 1,531 ms | **4.1x** | 13x slower | | For + assign | 203 ms | 10,226 ms | 1,710 ms | **6.0x** | 8.4x slower | | Do-While manual | 437 ms | 8,773 ms | 1,820 ms | **4.8x** | 4.2x slower | | For Step 2 | 62 ms | 6,125 ms | 1,527 ms | **4.0x** | 25x slower | | Nested For | 125 ms | 7,742 ms | 1,546 ms | **5.0x** | 12x slower | | For local Sub | 109 ms | 3,062 ms | 1,531 ms | **2.0x** | 14x slower | | For R8 counter | 203 ms | 10,882 ms | 1,492 ms | **7.3x** | 7.4x slower | | For-Each array | 7 ms | 6,339 ms | 58 ms | **109x** | 8.3x slower | The remaining 4-13x gap vs Windows in For-loops is from `VarAdd`/`VarCmp` going through full `VariantChangeTypeEx` machinery (including locale alloc/free per call). A separate MR ([!10528](https://gitlab.winehq.org/wine/wine/-/merge_requests/10529)) adds I2/I4 fast paths in oleaut32 that bring integer loops within 1.2-1.9x of Windows when combined with this branch. -- v8: vbscript: Fast-path For-Each iteration over SAFEARRAY. vbscript: Bind For-Each loop variable at compile time. vbscript: Bind global-scope Dim variables at compile time. vbscript: Bind class properties at compile time. vbscript: Bind For-loop variables at compile time. vbscript: Bind local variable assignments at compile time. vbscript: Bind local variables and arguments at compile time. https://gitlab.winehq.org/wine/wine/-/merge_requests/10515

2 9

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