April 2026 - Wine-GitLab - list.winehq.org

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

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

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

2 2

[PATCH 0/1] MR10594: Draft: vbscript: Log call stack trace on runtime errors.
by Francis De Brabandere (＠francisdb) April 7, 2026

April 7, 2026

Add WARN-level trace output showing the call chain when a runtime error propagates through nested function calls. This helps diagnose errors in ExecuteGlobal/Execute code where the reported error location has no context about which call chain led to it. ``` Example output for WINEDEBUG=warn+vbscript: error 0x80020012 in L"Broken", line 3 called from L"Wrapper", line 2 called from <global>, line 16 ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10594

2 2

[PATCH v7 0/3] MR10025: mshtml/msxml3: Add XMLSerializer, embedded XML declaration handling
by Phiality (＠PhialsBasement) April 7, 2026

April 7, 2026

This patchset adds XMLSerializer support and fixes several compatibility issues for Adobe Creative Cloud installer and similar applications. XMLSerializer implementation (mshtml) - Implements the `IXMLSerializer` interface with `serializeToString()` method - Allows JavaScript to serialize DOM elements to XML strings Embedded XML declaration handling (msxml3) - Adds CDATA wrapping for embedded `<?xml?>` declarations inside elements - Windows MSXML tolerates these nested declarations but libxml2 rejects them - The preprocessing step wraps problematic content in CDATA sections before parsing ~~DISPATCH_METHOD|DISPATCH_PROPERTYGET fixes (jscript/mshtml)~~ This was already done !10004 Also added tests for XMLSerializer (empty elements, text nodes, special characters, nested elements, multiple children), embedded XML declaration handling (multiple declarations, deeply nested, encoding attributes, self-closing elements) and DISPATCH_METHOD|DISPATCH_PROPERTYGET behavior in both quirks and standards modes - Filip Bakreski -- v7: mshtml/msxml3/tests: Add tests for XMLSerializer and embedded XML declarations. libs/xml2: Tolerate embedded XML declarations inside elements. mshtml: Add IXMLSerializer implementation. https://gitlab.winehq.org/wine/wine/-/merge_requests/10025

6 10

[PATCH v2 0/1] MR10495: vbscript: Return error 1010 for keyword used where identifier expected in Dim.
by Francis De Brabandere (＠francisdb) April 7, 2026

April 7, 2026

When a reserved keyword like If appears after Dim where an identifier is expected (e.g. "Dim If"), Windows returns error 1010 ("expected identifier"). Add an error production in DimDeclList that sets the correct VBSE_EXPECTED_IDENTIFIER error code. -- v2: vbscript: Return error 1010 for keyword used where identifier expected in Dim. https://gitlab.winehq.org/wine/wine/-/merge_requests/10495

2 1

Re: [PATCH v15 0/6] MR10419: ntdll: Fix thread stops inside __wine_syscall_dispatcher
by Jinoh Kang (＠iamahuman) April 7, 2026

April 7, 2026

Jinoh Kang (@iamahuman) commented about dlls/ntdll/unix/signal_x86_64.c: > } > } > > + block_sigusr1(); Is there a reason we're temporarily unblocking here? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10419#note_135375

1 0