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

Re: [PATCH v2 0/7] MR10688: msxml3: Improvements to setAttribute().
by Nikolay Sivov (＠nsivov) April 21, 2026

April 21, 2026

On Tue Apr 21 07:42:53 2026 +0000, Bernhard Übelacker wrote: > And also silence from the [gitlab run](https://gitlab.winehq.org/bernhardu/wine/-/pipelines/64016). That's very good, thank you for reporting. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10688#note_137190

1 0

Re: [PATCH v2 0/7] MR10688: msxml3: Improvements to setAttribute().
by Bernhard Übelacker (＠bernhardu) April 21, 2026

April 21, 2026

On Mon Apr 20 21:28:41 2026 +0000, Bernhard Übelacker wrote: > With 7cb26d6936 applied ASan stays silent on my local system, with > x86_64 and i386. And also silence from the [gitlab run](https://gitlab.winehq.org/bernhardu/wine/-/pipelines/64016). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10688#note_137186

1 0

[PATCH v13 0/12] MR10569: wineandroid: rework Android integration and switch to split process model
by Twaik Yont (＠twaik) April 21, 2026

April 21, 2026

This series reworks the wineandroid driver and moves it away from the current “Wine inside JVM process” model to a split architecture where the Android activity (UI) and Wine run in separate processes. The existing model relies on running Wine inside the JVM process and interacting with Android through JNI callbacks and APC/unixlib-based dispatch. This approach no longer works reliably on modern Android: - Android 10+ applies seccomp restrictions to app processes, making a number of required syscalls unavailable inside the activity process, while processes started via fork/exec are not subject to the same limitations. - The implementation depends on Wine thread context (TEB), signal handling, and register state assumptions that conflict with the JVM runtime (e.g. segment register usage on x86), requiring fragile workarounds. - Due to sandboxing, it is difficult to reliably debug or even observe all failure modes, and future Android changes are likely to tighten these restrictions further. At the same time, downstream projects such as MiceWine, Winlator, Termux’s Wine environment, GameHub and GameNative already use a model where the UI (activity) and Wine run in separate processes and communicate via IPC, which has proven to work reliably on current Android systems. This series implements that model in wineandroid: - Wine is now started in a separate process via fork/exec instead of running inside the JVM process. - Android-facing code no longer depends on the Wine APC/unixlib execution path and runs on the UI thread where appropriate (e.g. native window registration). - ioctl handling is reworked to remove reliance on Wine thread context, with explicit JNIEnv usage and fd-based reply plumbing. - Environment setup and initialization are moved to the Java side, simplifying the native startup path. - Logging for ioctl paths is routed through Android logcat without depending on a Wine TEB. The changes are split into multiple bisect-safe commits to keep intermediate states functional while migrating the code step by step. With Wine running in a separate process, it is no longer subject to JVM seccomp restrictions, and there are no longer conflicts between JVM and Wine execution contexts (signals, thread state, register usage, etc.). <details> <summary>Old message</summary> wineandroid: move ioctl handling to dedicated Java-only thread Move ioctl handling out of the Wine APC/unixlib execution path into a dedicated Java-only thread without Wine context. On Android 10+ a number of syscalls are restricted inside the activity process via seccomp, while processes started via fork/exec are not subject to the same limitations. Decoupling ioctl handling from the Wine context is required to eventually run this code outside of the activity process. This change introduces a new transport and execution model where ioctl dispatch no longer depends on Wine thread state, preparing for moving the Android backend into a separate process. The refactor is intentionally split into multiple bisect-safe commits to keep intermediate states functional while gradually migrating the dispatch path. Since this is a fairly large chunk of work, I’d like to make sure we’re aligned before continuing. </details> -- v13: wineandroid: split Android driver and Wine into separate processes wineandroid: terminate activity when desktop client disconnects wineandroid: make JNI initialization work with direct JVM loading wineandroid: create desktop view via ioctl and pass event pipe wineandroid: return ioctl errors directly wineandroid: remove unixlib/ntoskrnl ioctl path wineandroid: switch dequeueBuffer to socket transport wineandroid: switch ioctl dispatch to socket transport on main thread looper wineandroid: pass JNIEnv explicitly through ioctl handlers wineandroid: add reply_fd plumbing to ioctl path wineandroid: move native window registration to surface_changed wineandroid: use Android logging for ioctl dispatch paths https://gitlab.winehq.org/wine/wine/-/merge_requests/10569

2 12

[PATCH v3 0/1] MR10541: vbscript: Fast-path assign_value for simple non-refcounted types.
by Francis De Brabandere (＠francisdb) April 21, 2026

April 21, 2026

Skip VariantCopyInd and VariantClear when both source and destination are simple scalar types (VT_I2, VT_I4, VT_R8, VT_BOOL, VT_EMPTY, etc.) that require no memory management. A direct struct assignment suffices for these types. Benchmarks (10M iterations, measured in isolation on top of master): - Do-While loop: 824 -> 472 ms (1.75×) - For + assignment: 324 -> 265 ms (1.22×) - Dict.Items iteration: 683 -> 324 ms (2.1×) - If-Else branching: 726 -> 644 ms (1.13×) Every variable assignment in the interpreter benefits. The fast path eliminates two cross-DLL calls to oleaut32 (VariantCopyInd + VariantClear) for each assignment of simple scalar types (VT_I2, VT_I4, VT_R8, VT_BOOL, etc.), replacing them with a single struct copy. -- v3: vbscript: Fast-path assign_value for simple non-refcounted types. https://gitlab.winehq.org/wine/wine/-/merge_requests/10541

2 1

[PATCH v3 0/1] MR10485: vbscript: Return proper errors for orphan Loop and Next keywords.
by Francis De Brabandere (＠francisdb) April 21, 2026

April 21, 2026

When Loop or Next appear outside their enclosing Do/For blocks, Windows returns specific error codes: 1038 ("loop without do") and 1055 ("unexpected Next"). Detect these tokens in parser_error() and set the proper HRESULT instead of the generic E_FAIL. -- v3: vbscript: Return proper errors for orphan Loop and Next keywords. https://gitlab.winehq.org/wine/wine/-/merge_requests/10485

2 1

Re: [PATCH v2 0/4] MR10654: winegstreamer: Fix wg_parser/native video stride mismatch.
by Brendan McGrath (＠redmcg) April 20, 2026

April 20, 2026

> I check the `MF_MT_DEFAULT_STRIDE` and the bitmap info stride, both are 162 re: the `MF_MT_DEFAULT_STRIDE`, I've found with the source reader, you can get the `MF_SOURCE_READERF_CURRENTMEDIATYPECHANGED` flag once you start reading samples. I wonder if the `MF_MT_DEFAULT_STRIDE` value is updated at that point. Otherwise it feels like an MS bug to report one thing and do another. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10654#note_137178

1 0

Re: [PATCH v2 0/4] MR10654: winegstreamer: Fix wg_parser/native video stride mismatch.
by Brendan McGrath (＠redmcg) April 20, 2026

April 20, 2026

On Mon Apr 20 21:30:04 2026 +0000, Yuxuan Shui wrote: > > check divisibility? > And that was how I was figuring out the stride. Brief explanation of my observations: > Video I used: yuv420p pixel format, size 162x120. > I create source reader then set output type to YV12. I check the > `MF_MT_DEFAULT_STRIDE` and the bitmap info stride, both are 162. I then > `IMFMediaBuffer::Lock` it. The buffer size reported by `Lock` is `33792`. > I calculated the Y plan size: `33792 / 3 * 2 = 22528`, and realized that > it's not divisible by 162: `22528 = 162*139+10`. So I tried rounding up > to 8-bytes `22528 / 168`, doesn't work. Then rounding up to 16-bytes > `22528 / 176 = 128`. Oh interesting. I was curious how the `IMF2DBuffer::ContiguousCopyFrom` and `IMF2DBuffer::ContiguousCopyTo` methods would work in this case and that led me to this: https://learn.microsoft.com/en-us/windows/win32/api/mfobjects/nn-mfobjects-… That states: > Every video format defines a contiguous or packed representation. This representation is compatible with the standard layout of a DirectX surface in system memory, with no additional padding. So maybe that's where the 16-byte alignment comes from. But that would break compatibility with older MFTs that aren't aware to check for the `IMF2DBuffer` interface (in order to determine which rule is being used). Edit: Although I guess if the media type for the output has `MF_MT_DEFAULT_STRIDE` and that is honoured by the MFT, then it would still work. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10654#note_137177

1 0

[PATCH 0/1] MR10707: po: update Polish translation
by Adam Markowski (＠AMark) April 20, 2026

April 20, 2026

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10707

2 1

[PATCH 0/5] MR10706: msxml3: Respect document encoding in Save().
by Nikolay Sivov (＠nsivov) April 20, 2026

April 20, 2026

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10706

2 5

[PATCH v12 0/1] MR10484: vbscript: Return "Invalid for loop control variable" error for member expressions.
by Francis De Brabandere (＠francisdb) April 20, 2026

April 20, 2026

Windows VBScript rejects member expressions (e.g. x.y) as For/For Each loop control variables with error 1040. Accept MemberExpression in the parser rules and check for obj_expr to report the proper error instead of a generic syntax error. -- v12: vbscript: Return "Invalid for loop control variable" error for member expressions. https://gitlab.winehq.org/wine/wine/-/merge_requests/10484

2 1