- Wine-GitLab - list.winehq.org

[PATCH v6 0/2] MR10463: winemac: Replace OSAtomic functions with builtin __atomic counterparts.
by Marc-Aurel Zent (＠mzent) April 15, 2026

April 15, 2026

This fixes deprecated build warnings: `wine/dlls/winemac.drv/cocoa_event.m:280:21: warning: 'OSAtomicDecrement32Barrier' is deprecated: first deprecated in macOS 10.12` Also relaxes memory barriers where appropriate. -- v6: winemac: Relax builtin __atomic memory barriers. winemac: Replace OSAtomic functions with builtin __atomic counterparts. https://gitlab.winehq.org/wine/wine/-/merge_requests/10463

4 7

[PATCH 0/1] MR10650: vbscript: Fix crash when GetRef is called as a statement.
by Francis De Brabandere (＠francisdb) April 15, 2026

April 15, 2026

Global_GetRef() wrote to *res unconditionally. Callers that discard the return value (`Call GetRef("name")` or bare-call form) pass NULL, which segfaults on Wine but runs cleanly on Windows. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10650

3 2

[PATCH v8 0/2] MR10589: vbscript: Add missing runtime error constants and tests.
by Francis De Brabandere (＠francisdb) April 15, 2026

April 15, 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. -- v8: vbscript: Return proper error for New on undefined or non-class identifier. https://gitlab.winehq.org/wine/wine/-/merge_requests/10589

3 3

[PATCH 0/1] MR10658: vbscript: Silence FuncRef::QueryInterface(IID_IDispatchEx) warning.
by Francis De Brabandere (＠francisdb) April 15, 2026

April 15, 2026

The script engine probes IDispatchEx on every dispatch lookup (see get_disp_id() in vbdisp.c) and falls back cleanly to plain IDispatch on E_NOINTERFACE; the negative response is therefore expected, not exceptional. FuncRef objects returned by GetRef are plain IDispatch and don't implement IDispatchEx, so every callback through them currently emits a WARN. Mirror commit ce6c9f6d338a40c4f39b6758dae6d600823da767 ("vbscript: Silence BuiltinDisp::QueryInterface(IID_IDispatchEx) warning"): keep the catch-all WARN for genuinely unknown IIDs but skip it for IID_IDispatchEx specifically. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10658

3 2

[PATCH 0/1] MR10498: vbscript: Return correct error codes for missing statement separators.
by Francis De Brabandere (＠francisdb) April 15, 2026

April 15, 2026

When a statement and its closing keyword appear on the same line without a separator (newline or colon), Windows returns specific error codes: - 1042 (Must be first statement on the line) for End If, End Select - 1024 (Expected statement) for End While, End Class, Else End If - 1025 (Expected end of statement) for Wend, Loop Wine was returning generic E_FAIL (16389) for all of these. Add targeted error productions in the parser grammar to detect block-closing keywords following a statement without a separator, and set the appropriate VBScript error code before aborting. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10498

3 2

[PATCH 0/2] MR10651: Revert "kernelbase: Replace FileAllInformation with FileStatInformation in GetFileInformationByHandle()."
by Jinoh Kang (＠iamahuman) April 15, 2026

April 15, 2026

This reverts commit 1b0d8428dfc13b0fa5ea7d576dfef7aaf8a8c927. Some applications hook NtQueryInformationFile(FileAllInformation) and expect it to be called by GetFileInformationByHandle(). Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59644 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10651

4 9

[PATCH 0/1] MR10670: kernelbase: Add messsage string for ERROR_NOT_A_REPARSE_POINT
by Antoine Leresche (＠A2va) April 15, 2026

April 15, 2026

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59449 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10670

2 1

[PATCH v4 0/15] MR10349: opengl32: Implement wglGetProcAddress on the client side.
by Jacek Caban (＠jacek) April 15, 2026

April 15, 2026

And rework extensions parser. -- v4: opengl32: Implement wglGetProcAddress on the client side. win32u: Query every OpenGL functions on initialization. opengl32: Always check available extensions in wrap_wglGetProcAddress. opengl32: Introduce get_function_entry helper. opengl32: Store extensions an an enum in functions registry. opengl32: Store core GL version separate from extensions in the function registry. opengl32: Use parse_extensions in filter_extensions. opengl32: Initialize enabled / disabled OpenGL extensions struct. opengl32: Implement glGetStringi(GL_EXTENSIONS) on client side. opengl32: Store extension_array as opengl_extension. opengl32: Rename ALL_GL_CLIENT_EXTS to ALL_GL_EXTS. opengl32: Remove unexposed extensions for functions registry. opengl32: Move GL_NUM_EXTENSIONS to client side. opengl32: Implement wglGetExtensionsString(ARB|EXT) on the PE side. opengl32: Move major / minor version to the PE side context wrapper. https://gitlab.winehq.org/wine/wine/-/merge_requests/10349

4 17

Re: [PATCH v2 0/7] MR10582: opengl32: Misc simplifications to make_opengl and tests. - closed
by Rémi Bernon (＠rbernon) April 15, 2026

April 15, 2026

This merge request was closed by Rémi Bernon. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10582

1 0

[PATCH v3 0/15] MR10349: opengl32: Implement wglGetProcAddress on the client side.
by Jacek Caban (＠jacek) April 15, 2026

April 15, 2026

And rework extensions parser. -- v3: opengl32: Implement wglGetProcAddress on the client side. win32u: Query every OpenGL functions on initialization. opengl32: Always check available extensions in wrap_wglGetProcAddress. opengl32: Introduce get_function_entry helper. opengl32: Store extensions an an enum in functions registry. opengl32: Store core GL version separate from extensions in the function registry. opengl32: Use parse_extensions in filter_extensions. opengl32: Initialize enabled / disabled OpenGL extensions struct. opengl32: Implement glGetStringi(GL_EXTENSIONS) on client side. opengl32: Store extension_array as opengl_extension. opengl32: Rename ALL_GL_CLIENT_EXTS to ALL_GL_EXTS. opengl32: Remove unexposed extensions for functions registry. opengl32: Move GL_NUM_EXTENSIONS to client side. opengl32: Implement wglGetExtensionsString(ARB|EXT) on the PE side. opengl32: Move major / minor version to the PE side context wrapper. https://gitlab.winehq.org/wine/wine/-/merge_requests/10349

5 18

Re: [PATCH v2 0/4] MR10654: winegstreamer: Fix wg_parser/native video stride mismatch.
by Yuxuan Shui (＠yshui) April 15, 2026

April 15, 2026

> Do you know that it's exactly 2 bytes? Your test proves it's at most 2 bytes, but it could be 1 byte. Yeah I wanted to test with a 161 pixel width video, but h264 requires the width to be a multiple of 2. Maybe I should try a different codec or maybe raw video? But OTOH how would UV sub-sampling work with an alignment of 1 byte? I feel it would be pretty safe to assume the minimum would be 2 bytes. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10654#note_136288

1 0

[PATCH v2 0/2] MR10666: mf/tests: Check some IMFTransform / IMediaObject interop.
by Rémi Bernon (＠rbernon) April 15, 2026

April 15, 2026

-- v2: mf/tests: Check color converter IMFTransform / IMediaObject interop. mf/tests: Check resampler IMFTransform / IMediaObject interop. https://gitlab.winehq.org/wine/wine/-/merge_requests/10666

3 4

[PATCH 0/1] MR10667: mfplat: Support FORMAT_MFVideoFormat in MFInitMediaTypeFromAMMediaType.
by Rémi Bernon (＠rbernon) April 15, 2026

April 15, 2026

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

3 2

[PATCH 0/1] MR10668: mfplat: Don't set frame size or stride if missing from VIDEOINFOHEADER2.
by Rémi Bernon (＠rbernon) April 15, 2026

April 15, 2026

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

3 2

[PATCH v12 0/5] MR9992: Introduce ImeToAsciiEx() user driver function for use in winemac
by Marc-Aurel Zent (＠mzent) April 15, 2026

April 15, 2026

-- v12: win32u: Remove builtin WINE_IME_PROCESS_KEY driver call. winemac: Move macdrv_ImeProcessKey logic to ImeProcessKey and macdrv_ImeToAsciiEx. winemac: Implement and use macdrv_ImeToAsciiEx(). win32u: Move IME processing to ImeToAsciiEx. win32u: Introduce new ImeToAsciiEx user driver call. https://gitlab.winehq.org/wine/wine/-/merge_requests/9992

4 8

[PATCH v2 0/7] MR10669: odbc32: Implement sharing environment between connections.
by Piotr Caban (＠piotr) April 15, 2026

April 15, 2026

-- v2: odbc32: Don't leak connection object if it's reused in connect functions. odbc32: Implement sharing environment handle between connections. odbc32: Don't call into driver in SQLSetEnvAttr. odbc32: Don't call into driver in SQLGetEnvAttr. odbc32: Only set connection and login timeout if it was ever set. odbc32: Use SQLFreeHandle in SQLFreeStmt if possible. odbc32: Fix SQLBrowseConnect tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/10669

2 7

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

April 15, 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> -- v11: wineandroid: terminate activity when desktop client disconnects This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/10569

1 0

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

April 15, 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> -- v10: wineandroid: split Android driver and Wine into separate processes This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/10569

1 0

[PATCH 0/6] MR10669: odbc32: Implement sharing environment between connections.
by Piotr Caban (＠piotr) April 15, 2026

April 15, 2026

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

2 6

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

April 15, 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> -- v9: wineandroid: split Android driver and Wine into separate processes 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: simplify client pid handling wineandroid: use Android logging for ioctl dispatch paths wineandroid: load AHardwareBuffer symbols from libandroid wineandroid: switch java_* variables to direct linking wineandroid: set environment in Java and simplify wine_init wineandroid: fix loader path and library lookup for modern Wine/Android wineandroid: lower targetSdkVersion to avoid Android 10 W^X restrictions wineandroid: fix 64-bit crash in setCursor JNI call This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/10569

1 1

[PATCH 0/2] MR10072: shell32: Always update `outlen` (`pcchOut`) when querying strings
by Marijn Suijten (＠Marijn) April 15, 2026

April 15, 2026

At least `AssocQueryStringW()` is documented to update the character count in `pcchOut` to "the number of characters actually placed in the buffer" which requires us to update the value of `*outlen` even when the buffer size was sufficient: https://learn.microsoft.com/en-us/windows/win32/api/shlwapi/nf-shlwapi-asso… Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59402 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10072

2 3

[PATCH v7 0/7] MR10604: setupapi, ntoskrnl: Implement CM_Get_Parent with device tree properties
by Jan Robert Gerigk (＠RgSg86) April 15, 2026

April 15, 2026

Wine Bug: https://bugs.winehq.org/show_bug.cgi?id=59604 Implement CM_Get_Parent by storing device tree relationship properties when ntoskrnl enumerates child devices via IRP_MN_QUERY_DEVICE_RELATIONS: - DEVPKEY_Device_Parent on each child device - DEVPKEY_Device_Children on the parent device - DEVPKEY_Device_Siblings on each child device CM_Get_Parent reads DEVPKEY_Device_Parent through SetupDiGetDevicePropertyW. Also fix SETUPDI_EnumerateMatchingInterfaces to remove devices without interfaces from DIGCF_DEVICEINTERFACE enumeration results. --\> no more phantom devices Based on discussion with Rémi Bernon (Bug 59604) Tested on a fresh Wine 11.6 setup with KNX ETS 6.4.1: A USB HID license dongle (VID 2A07, PID 0102) is now correctly identified through CM_Get_Parent device tree navigation. -- v7: ntoskrnl/tests: Add DEVPKEY_Device_Parent test. setupapi/tests: Add CM_Get_Parent tests. cfgmgr32: Implement CM_Get_Parent using DEVPKEY_Device_Parent property. https://gitlab.winehq.org/wine/wine/-/merge_requests/10604

2 8

[PATCH 0/2] MR10666: mf/tests: Check some IMFTransform / IMediaObject interop.
by Rémi Bernon (＠rbernon) April 15, 2026

April 15, 2026

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

2 2

[PATCH v6 0/7] MR10604: setupapi, ntoskrnl: Implement CM_Get_Parent with device tree properties
by Jan Robert Gerigk (＠RgSg86) April 15, 2026

April 15, 2026

Wine Bug: https://bugs.winehq.org/show_bug.cgi?id=59604 Implement CM_Get_Parent by storing device tree relationship properties when ntoskrnl enumerates child devices via IRP_MN_QUERY_DEVICE_RELATIONS: - DEVPKEY_Device_Parent on each child device - DEVPKEY_Device_Children on the parent device - DEVPKEY_Device_Siblings on each child device CM_Get_Parent reads DEVPKEY_Device_Parent through SetupDiGetDevicePropertyW. Also fix SETUPDI_EnumerateMatchingInterfaces to remove devices without interfaces from DIGCF_DEVICEINTERFACE enumeration results. --\> no more phantom devices Based on discussion with Rémi Bernon (Bug 59604) Tested on a fresh Wine 11.6 setup with KNX ETS 6.4.1: A USB HID license dongle (VID 2A07, PID 0102) is now correctly identified through CM_Get_Parent device tree navigation. -- v6: ntoskrnl/tests: Add DEVPKEY_Device_Parent test. setupapi/tests: Add CM_Get_Parent tests. cfgmgr32: Implement CM_Get_Parent using DEVPKEY_Device_Parent property. ntoskrnl: Store DEVPKEY_Device_Siblings on each child after bus enumeration. ntoskrnl: Store DEVPKEY_Device_Children on parent after bus enumeration. ntoskrnl: Store DEVPKEY_Device_Parent when enumerating child devices. setupapi: Remove devices without interfaces from DIGCF_DEVICEINTERFACE enumeration. https://gitlab.winehq.org/wine/wine/-/merge_requests/10604

3 8

[PATCH v4 0/4] MR10561: Draft: Fix handling by SChannel for CNG/NCrypt client certificates for mTLS
by Benoît Legat (＠blegat) April 15, 2026

April 15, 2026

Part 3 of my attempt to run the [Niko Home Control programming software](https://appdb.winehq.org/objectManager.php?sClass=application&iId… under Wine. If I understand correctly, the current implementation only supports retrieving via the legacy CryptoAPI (CAPI). The Niko app uses Cryptography Next Generation (CNG/NCrypt) so this PRs adds support for it in acquire_credentials_handle. -- v4: Fixes https://gitlab.winehq.org/wine/wine/-/merge_requests/10561

3 6