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

Re: [PATCH v9 0/4] MR10751: winscard: Implement SCardGetCardTypeProviderName and SCardListCards (smartcard database)
by Guillaume Raffin (＠TheElectronWill) May 25, 2026

May 25, 2026

On Mon May 25 13:40:41 2026 +0000, Guillaume Raffin wrote: > Tests that require a context are now skipped on `SCARD_E_NO_SERVICE`. Regarding the windows failures: * The smartcard db is not empty on a standard Windows install, I didn't think about that… I'll change the tests. * NULL parameters don't seem to be handled like my implementation. I'll see if I can run the tests on windows myself to catch undocumented behaviors. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10751#note_141239

1 0

Re: [PATCH v2 0/2] MR10980: vbscript: Propagate errors from a script-invoked function reference.
by Jacek Caban (＠jacek) May 25, 2026

May 25, 2026

Jacek Caban (@jacek) commented about dlls/vbscript/vbdisp.c: > if(dispIdMember != DISPID_VALUE) > return DISP_E_MEMBERNOTFOUND; > > - return exec_script(This->ctx, TRUE, This->func, NULL, pDispParams, pVarResult); > + /* When the reference is invoked from within running script (e.g. under the > + * caller's On Error Resume Next), the error must propagate back to that > + * caller as an HRESULT rather than be reported to the host. Only a call > + * originating outside the engine acts as an external caller. */ > + return exec_script(This->ctx, !This->ctx->current_exec, This->func, NULL, pDispParams, pVarResult); I think this is not accurate. If a script calls an external `IDispatch`, which then calls back the function reference then `current_exec` will be non-null, but the caller is external. In jscript, we have `DISPATCH_JSCRIPT_CALLEREXECSSOURCE` to distinguish that. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10980#note_141237

1 0

[PATCH 0/4] MR10982: combase: Share context token between MTA threads.
by Piotr Caban (＠piotr) May 25, 2026

May 25, 2026

These changes will be needed by IContextCallback::ContextCallback function. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10982

3 5

[PATCH v8 0/1] MR10906: sapi: Implement ISpVoice::GetStatus, SetPriority and GetPriority.
by Bohdan Tkachenko (＠BohdanTkachenko) May 25, 2026

May 25, 2026

Previously these three methods returned E_NOTIMPL. SetPriority/GetPriority store the priority on the voice and validate it against SPVPRI_NORMAL, SPVPRI_ALERT and SPVPRI_OVER. GetStatus populates SPVOICESTATUS from speech_voice state: - ulCurrentStream tracks the stream currently being processed by speak_proc (set at the start of the worker so it reflects the in-flight stream, and sticks at the last processed value when idle, per MSDN). Stored as last_stream_num on speech_voice. - ulLastStreamQueued reuses the existing cur_stream_num counter, which is incremented before each Speak queues a task. - hrLastResult is the HRESULT of the most recently completed speak (set at the end of speak_proc). - dwRunningState is derived from async_wait_queue_empty(&queue, 0) so it correctly reports SPRS_DONE both when idle and after a purge clears queued tasks. This unblocks Overwatch 2's Audio Captions accessibility TTS, which calls SetPriority during voice setup and tight-polls GetStatus for SPRS_DONE between Speak calls. Add tests covering priority round-trips, GetStatus with a NULL pointer, and status fields before, during and after sync and async Speak calls. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59749 -- v8: https://gitlab.winehq.org/wine/wine/-/merge_requests/10906

3 3

[PATCH v8 0/4] MR10751: winscard: Implement SCardGetCardTypeProviderName and SCardListCards (smartcard database)
by Guillaume Raffin (＠TheElectronWill) May 25, 2026

May 25, 2026

These functions are necessary to make some smartcard-based programs work. They rely on the "SmartCard Database", which can be found in the windows registry, at \`HKLM\\SOFTWARE\\Microsoft\\Cryptography\\Calais\\SmartCards\`. I have added extensive unit tests and validated the implementation with a real application (an internal program based on Atos CardOS). As this is my first PR here, please don't hesitate to tell me if something's wrong! I was wondering if the database-related code should be moved to a dedicated file `winscard-database.c`? same for the tests?), let me know what you think. -- v8: winscard: Implement SCardGetCardTypeProviderNameA winscard: Implement SCardListCardsA winscard: Implement SCardListCardsW winscard: Implement SCardGetCardTypeProviderNameW https://gitlab.winehq.org/wine/wine/-/merge_requests/10751

2 6

[PATCH v7 0/4] MR10751: winscard: Implement SCardGetCardTypeProviderName and SCardListCards (smartcard database)
by Guillaume Raffin (＠TheElectronWill) May 25, 2026

May 25, 2026

These functions are necessary to make some smartcard-based programs work. They rely on the "SmartCard Database", which can be found in the windows registry, at \`HKLM\\SOFTWARE\\Microsoft\\Cryptography\\Calais\\SmartCards\`. I have added extensive unit tests and validated the implementation with a real application (an internal program based on Atos CardOS). As this is my first PR here, please don't hesitate to tell me if something's wrong! I was wondering if the database-related code should be moved to a dedicated file `winscard-database.c`? same for the tests?), let me know what you think. -- v7: winscard: Implement SCardGetCardTypeProviderNameA winscard: Implement SCardListCardsA winscard: Implement SCardListCardsW winscard: Implement SCardGetCardTypeProviderNameW https://gitlab.winehq.org/wine/wine/-/merge_requests/10751

3 9

[PATCH v15 0/4] MR10569: wineandroid: rework Android integration and switch to split process model
by Twaik Yont (＠twaik) May 25, 2026

May 25, 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> -- v15: 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 https://gitlab.winehq.org/wine/wine/-/merge_requests/10569

2 6

[PATCH v2 0/1] MR10983: wined3d: Handle data aliasing when blitting to itself with FX transforms.
by Paul Gofman (＠gofman) May 25, 2026

May 25, 2026

-- v2: wined3d: Handle data aliasing when blitting to itself with FX transforms. https://gitlab.winehq.org/wine/wine/-/merge_requests/10983

3 3

[PATCH v3 0/2] MR10835: gdiplus: Add support for CMYK to ARGB pixel format conversion.
by Yongjie Yao (＠yaoyongjie) May 25, 2026

May 25, 2026

Add conversion from PixelFormat32bppCMYK to PixelFormat32bppARGB in convert_pixels(), using the standard subtractive color model formula where RGB = (255 - CMY) * (255 - K) / 255. -- v3: gdiplus: Fix return code for pixel format convertion. gdiplus/tests: Add test for pixel format conversion. https://gitlab.winehq.org/wine/wine/-/merge_requests/10835

2 2

Re: [PATCH v3 0/2] MR10809: comctl32: Fix VARHEIGHT rebar scaling when cyIntegral == 0
by Zhiyi Zhang (＠zhiyi) May 25, 2026

May 25, 2026

Zhiyi Zhang (@zhiyi) commented about dlls/comctl32/tests/rebar.c: > > DestroyWindow(hRebar); > > + /* VARHEIGHT resizing test with cyIntegral == 0 on a horizontal rebar */ > + hRebar = create_rebar_control(0); > + SetWindowLongA(hRebar, GWL_STYLE, GetWindowLongA(hRebar, GWL_STYLE) | RBS_AUTOSIZE); > + check_sizes(); > + rbi.fMask = RBBIM_CHILD | RBBIM_CHILDSIZE | RBBIM_SIZE | RBBIM_STYLE; > + rbi.fStyle = RBBS_VARIABLEHEIGHT; > + rbi.cxMinChild = 50; Why do you need three bands? The numbers are all pretty random, so it's not obvious what you are trying to test. Please simplify it more. Focus the test on the bug that you want to fix. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10809#note_141203

1 0