- Wine-GitLab - list.winehq.org

Re: [PATCH v20 0/8] MR10515: Draft: vbscript: Bind local variables, class properties, and loop variables at compile time.
by Francis De Brabandere (＠francisdb) April 17, 2026

April 17, 2026

Notes to self for when this MR is merged: **Follow-up: Fast-path For-Each iteration over SAFEARRAY** Once this series merges, a straightforward follow-up is to bypass the IEnumVARIANT COM dispatch when the For-Each iterator is a SAFEARRAY. - Call a helper (safearray_iter_next) that reads elements directly from the array data, avoiding the COM vtable call and one intermediate VariantCopy per iteration. - For non-refcounted element types (VT_I2, VT_I4, VT_R8, etc.) skip VariantCopyInd/VariantClear too — plain struct assignment is enough. - Non-SAFEARRAY iterators (IDispatch collections, etc.) keep the current IEnumVARIANT_Next path. - Applies to both interp_enumnext and interp_enumnext_local (the compile-time-bound variant introduced in this series). Measured on Wine, 1M-element integer array: - empty For-Each body: 16ms → 8ms (2×) - acc = acc + v: 102ms → 86ms (~16%) Modest impact on realistic workloads, but the code is small and principled (eliminates COM overhead at no API cost). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10515#note_136796

1 0

[PATCH 0/2] MR10693: oleaut32: Let the 'Apply' button become active and handle it getting clicked
by Yaroslav Chvanov (＠yaroslav.chvanov) April 17, 2026

April 17, 2026

I've tested this with LAV Filters as described in commit messages. `make test` fails on my system (`make: *** [Makefile:4945: dlls/advapi32/tests/i386-windows/security.ok] Error 2`) so I have not been able to run any auto-tests, but it appears olepropframe doesn't have any anyway. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=42836 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10693

2 2

[PATCH v5 0/1] MR10383: vbscript: Support element access on public array properties of class instances.
by Francis De Brabandere (＠francisdb) April 17, 2026

April 17, 2026

On Windows, public array properties declared in a class (e.g. "Public arr(3)") can be accessed element-wise from outside the class using obj.arr(i) for both reading and writing. Wine failed to handle this because invoke_variant_prop() used V_ARRAY() which does not work for VT_ARRAY|VT_BYREF|VT_VARIANT arrays, and the property put path did not support indexed arguments at all. Fix both by adding a helper to extract the SAFEARRAY from either BYREF or direct array variants, and implementing indexed array element writes in the property put path. -- v5: vbscript: Support element access on public array properties of class instances. https://gitlab.winehq.org/wine/wine/-/merge_requests/10383

3 3

[PATCH v2 0/1] MR10497: vbscript: Return specific error codes for unterminated block statements.
by Francis De Brabandere (＠francisdb) April 17, 2026

April 17, 2026

When a block statement reaches EOF without its closing keyword, Windows returns a specific error code. Add error productions in the bison grammar for four unterminated block types: - If without End If (error 1014) - While without Wend (error 1018) - Do without Loop (error 1019) - For/For Each without Next (error 1020) Previously these all fell through to the generic E_FAIL path. -- v2: vbscript: Return specific error codes for unterminated block statements. https://gitlab.winehq.org/wine/wine/-/merge_requests/10497

3 2

[PATCH v2 0/2] MR8331: urlmon: Fix out-of-bound access when trying to remove dot segments from URI.
by Yuxuan Shui (＠yshui) April 17, 2026

April 17, 2026

Dot segments removal in parse_canonicalize makes the assumption that the entire path part of the URI fits into the output buffer (len is the length the output URI would have taken had the output buffer been large enough). So when the output buffer is too small, remove_dot_segments will access out-of-bound. Considering URI unescaping could be happening at the same time, there is no simple way to calculate the required output buffer size correctly without keeping the actual output URI in memory. * * * As you can see from the [test results](https://testbot.winehq.org/JobDetails.pl?Key=158742), this seems to be bugged on native. I don't know if we need to replicate native's behavior -- v2: iertutil: Fix out-of-bound access in remove_dot_segments. urlmon/tests: Test output length calculation when output buffer is too small. https://gitlab.winehq.org/wine/wine/-/merge_requests/8331

3 4

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

April 17, 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 Visual Pinball 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. -- v8: vbscript: Use indexed lookup for global variables. vbscript: Use indexed lookup for global functions. https://gitlab.winehq.org/wine/wine/-/merge_requests/10546

3 5

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

April 17, 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 | 413 ms | 234 ms | **1.8x** | 1.5x slower | | Arguments | 171 ms | 357 ms | 231 ms | **1.5x** | 1.4x slower | | Class props | 265 ms | 393 ms | 226 ms | **1.7x** | 0.9x (faster!) | ### For-loop variants (10M iterations) | Benchmark | Windows (VM) | Wine master | Wine (7 commits) | **Speedup** | vs Windows | |-----------|-------------|-------------|-------------------|---------|------------| | Empty For | 117 ms | 370 ms | 270 ms | **1.4x** | 2.3x slower | | For + assign | 203 ms | 613 ms | 430 ms | **1.4x** | 2.1x slower | | Do-While manual | 437 ms | 646 ms | 513 ms | **1.3x** | 1.2x slower | | For Step 2 | 62 ms | 370 ms | 271 ms | **1.4x** | 4.4x slower | | Nested For | 125 ms | 387 ms | 268 ms | **1.4x** | 2.1x slower | | For local Sub | 109 ms | 294 ms | 251 ms | **1.2x** | 2.3x slower | | For R8 counter | 203 ms | 2,812 ms | 2,529 ms | **1.1x** | 12x slower | | For-Each array | 7 ms | 286 ms | 62 ms | **4.6x** | 8.9x 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. -- v19: vbscript: Fast-path For-Each iteration over SAFEARRAY. https://gitlab.winehq.org/wine/wine/-/merge_requests/10515

3 12

[PATCH v4 0/1] MR10489: vbscript: Return specific error codes for missing keywords in parser.
by Francis De Brabandere (＠francisdb) April 17, 2026

April 17, 2026

Add error productions in the bison grammar for five cases where a specific keyword is expected after a recognized prefix: - Expected '=' after identifier in Const declaration (error 1011) - Expected 'To' after expression in For loop (error 1013) - Expected 'Then' after expression in If statement (error 1017) - Expected 'Case' after Select (error 1021) - Expected 'In' after identifier in For Each loop (error 1046) Previously these all fell through to the generic E_FAIL path in parser_error(). Now each sets the correct VBSE_EXPECTED_* error code via MAKE_VBSERROR before aborting the parse. -- v4: vbscript: Return specific error codes for missing keywords in parser. https://gitlab.winehq.org/wine/wine/-/merge_requests/10489

3 2

[PATCH v8 0/1] MR10592: vbscript: Add call depth limit to prevent stack overflow on infinite recursion.
by Francis De Brabandere (＠francisdb) April 17, 2026

April 17, 2026

Track call depth in script_ctx_t and return error 28 'Out of stack space' when it exceeds a fixed limit. Previously Wine would crash with a native stack overflow. -- v8: vbscript: Add call depth limit to prevent stack overflow on infinite recursion. https://gitlab.winehq.org/wine/wine/-/merge_requests/10592

3 2

Re: [PATCH v10 0/1] MR10518: wscript: Implement error messages, usage output, and //nologo banner. - approved
by Jacek Caban (＠jacek) April 17, 2026

April 17, 2026

This merge request was approved by Jacek Caban. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10518

1 0