- Wine-GitLab - list.winehq.org

[PATCH 0/8] MR10596: mf/topology_loader: Lookup best matching types when connecting transforms.
by Rémi Bernon (＠rbernon) April 8, 2026

April 8, 2026

And improve compatibility more generally. Supersedes !10009 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10596

3 9

[PATCH v8 0/1] MR10314: vbscript: Convert string to number for comparison operators.
by Francis De Brabandere (＠francisdb) April 8, 2026

April 8, 2026

When one operand was a string and the other numeric, VBScript should have converted the string to a double before comparing. VarCmp did not do this automatically, resulting in incorrect string comparison. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56281 -- v8: vbscript: Convert string to number for comparison operators. https://gitlab.winehq.org/wine/wine/-/merge_requests/10314

2 1

[PATCH v5 0/1] MR10589: Draft: vbscript: Add missing runtime error constants and tests.
by Francis De Brabandere (＠francisdb) April 8, 2026

April 8, 2026

Add VBSE_DUPLICATE_KEY (457) and VBSE_CLASS_NOT_DEFINED (506) error code definitions with their string resources, and add tests for runtime errors 11, 94, 429, 451, 457, and 506. Errors 94 and 506 are marked todo_wine as Wine currently returns incorrect error codes for those cases. Error 28 (out of stack space) is included commented out as Wine crashes with a stack overflow instead of raising the error. -- v5: vbscript: Add missing runtime error constants and tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/10589

2 1

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

April 8, 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. -- v11: 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 7

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

April 8, 2026

On Fri Apr 3 20:04:22 2026 +0000, Vishnunithyasoundhar S wrote: > changed this line in [version 47 of the diff](/wine/wine/-/merge_requests/10192/diffs?diff_id=257621&start_sha=267d9f37cec72f59a0358c255be5fbcb283054c4#ccbcb1301019e22467910d31043560ed0d42aafe_1338_1338) haa yes . I forgot to remove it ty. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10192#note_135413

1 0

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

April 8, 2026

On Fri Apr 3 20:04:22 2026 +0000, Vishnunithyasoundhar S wrote: > changed this line in [version 47 of the diff](/wine/wine/-/merge_requests/10192/diffs?diff_id=257621&start_sha=267d9f37cec72f59a0358c255be5fbcb283054c4#ccbcb1301019e22467910d31043560ed0d42aafe_1342_1338) changed to `lstrcmpiW` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10192#note_135412

1 0

[PATCH 0/3] MR10595: amstream: Reject filter when top-down image is not accepted.
by Brendan McGrath (＠redmcg) April 8, 2026

April 8, 2026

On Windows, when the ddraw media stream receives a `ReceiveConnection` request and the media type has a positive height value (i.e. a bottom-up image), it will call `AcceptQuery` on the peers Pin with the sign of the height flipped (i.e. it checks if the peer can produce a top-down image). It will reject the `ReceiveConnection` attempt with `VFW_E_TYPE_NOT_ACCEPTED` if the `AcceptQuery` returns `S_FALSE`. This MR also modifies the return code of `IPin::Disconnect` when not already connected. MS documentation says it should return `S_FALSE` but the implementation actually returns `S_OK`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10595

2 3

Re: [PATCH v15 0/6] MR10419: ntdll: Fix thread stops inside __wine_syscall_dispatcher
by Hoshino Lina (＠hoshinolina) April 8, 2026

April 8, 2026

On Wed Apr 8 01:21:04 2026 +0000, Hoshino Lina wrote: > This is a server call. If the server sends a SIGUSR1 here and we do not > handle it, presumably the server could deadlock waiting for the ack to > the SIGUSR1 while we make the call. Even if that wouldn't happen in the > trivial case (not sure how the server is implemented in terms of > async/etc), one could imagine an application code sequence that would > create this dependency and deadlock (think: two threads trying to set > each others' context). I moved the unblock inside the if, since I think that makes more sense. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10419#note_135398

1 0

Re: [PATCH v15 0/6] MR10419: ntdll: Fix thread stops inside __wine_syscall_dispatcher
by Hoshino Lina (＠hoshinolina) April 8, 2026

April 8, 2026

On Tue Apr 7 21:34:10 2026 +0000, Jinoh Kang wrote: > Is there a reason we're temporarily unblocking here? This is a server call. If the server sends a SIGUSR1 here and we do not handle it, presumably the server could deadlock waiting for the ack to the SIGUSR1 while we make the call. Even if that wouldn't happen in the trivial case (not sure how the server is implemented in terms of async/etc), one could imagine an application code sequence that would create this dependency and deadlock (think: two threads trying to set each others' context). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10419#note_135396

1 0

[PATCH v55 0/2] MR10291: Fix GetModuleFileName string termination
by Trent Waddington (＠trent.waddington) April 7, 2026

April 7, 2026

After Windows XP the string termination behavior of GetModuleFileName was changed to always terminate the path returned, even if the buffer is insufficient to contain the null terminator. -- v55: kernel32: Fix string termination of GetModuleFileName. Add tests for GetModuleFileName string termination. https://gitlab.winehq.org/wine/wine/-/merge_requests/10291

2 2