- Wine-GitLab - list.winehq.org

[PATCH v3 0/3] MR9874: wineandroid.drv: experimental bring-up fixes for Android 7.1.x
by Twaik Yont (＠twaik) Feb. 24, 2026

Feb. 24, 2026

Requires #10067, fixup/followup to e0d3683d8947cd9a3cb20acdf69091b183a90861 and 4b5311c7e02aa7ab2409f8fdcd22233f116dc4bc. #### Note on authorship and language This text was translated into English and structured with the assistance of ChatGPT. The author is not a native English speaker and may struggle with written technical English; any wording issues are unintentional. #### Description This merge request is an experimental attempt to bring wineandroid.drv back to a minimally functional state on Android 7.1.x. The current Android support appears to have bit-rotted over time, likely due to a combination of internal contract changes in Wine, toolchain and NDK evolution, and the absence of continuous Android testing. The changes proposed here aim to re-establish a working baseline and make the regressions more concrete and easier to reason about. #### Test environment and context All testing so far was performed on Android 7.1.2 x86 images from the Android-x86 project, published on osboxes.org ([link](https://www.osboxes.org/android-x86/)) The primary target is i386 Wine running on x86 Android userspace. Because no up-to-date official Android build scripts were available, Wine was built using Termux as an unsupported but convenient environment for rapid testing. The Java part (WineActivity and related glue code) was built with `sharedUserId = com.termux` purely for convenience (filesystem access and faster prototyping). **Termux is explicitly not considered a supported environment and is mentioned only to provide context for the testing setup.** The build uses Android NDK r29. Since the last known functional Android Wine builds, the NDK and linker behavior have changed multiple times, including symbol visibility and relocation handling. These changes appear to have directly affected several failure modes described below. There is also a known issue with wine-preloader producing excessively large binaries under recent toolchains; a workaround exists but is not included here and is mentioned only as additional context. #### Scope of changes This merge request currently modifies only Android-specific code: - `wineandroid.drv` (native code and Java glue, including WineActivity) - android-only paths in `dlls/ntdll/unix/loader.c` No non-Android platforms are affected. #### Summary of resolved issues 1) Desktop initialization ordering regression After recent `CreateDesktopW`-related changes, `ANDROID_CreateDesktop` started running before the DESKTOP window was created. The Java glue assumed the opposite order. The fix splits desktop initialization into two phases (view setup first, desktop window attachment later via an explicit is_desktop flag) and corrects the `ANDROID_CreateDesktop` success return value. 2) Rendering stalls and `USER lock assertion` Occasional crashes with: ``` err:system:user_check_not_lock BUG: holding USER lock ``` A full memory barrier was added in the dequeue path to avoid a likely memory ordering issue. Additionally, a guard was added for a `NULL` buffer returned on successful dequeue. 3) Early startup failure in `virtual_alloc_first_teb` Wine frequently failed with: ``` err:virtual:virtual_alloc_first_teb wine: failed to map the shared user data: c0000018 ``` `virtual_init()` is now called from `JNI_OnLoad()` to reduce the likelihood of the JVM reserving the required address range before Wine initializes its virtual memory subsystem. #### Remaining issues - Window focus handling is partially broken: windows receive focus on click, but are not always raised to the front. - Despite the available desktop area being larger (e.g. 1024x696), Wine consistently reports a display resolution of 800x600. #### Limitations Wine on Android stopped functioning entirely starting with Android 8. As a result, all testing so far has been limited to Android 7.1.x. No claims are made about behavior on newer Android versions. #### Out of scope This merge request intentionally does not attempt to: - redesign IPC mechanisms - introduce new Android integration models - address Android 8+ compatibility The sole goal is to re-establish a minimally working baseline on Android 7.1.x and enable informed discussion about what regressed and how to proceed. **This is my first contribution to Wine, and I am aware that some parts of this analysis or implementation may be flawed. I would be grateful for any review comments or suggestions.** <details> <summary>Also, the screenshot of the working prototype.</summary> ![image](/uploads/d2420de5d9b3b95b8f5184f8a60550d0/image.png){width=743 height=600} </details> -- v3: ntdll: call virtual_init from JNI_OnLoad to avoid early virtual_alloc_first_teb failure Wineandroid: Sanitize dequeueBuffer result and reject missing buffers. wineandroid: fix desktop init ordering after CreateDesktopW changes https://gitlab.winehq.org/wine/wine/-/merge_requests/9874

2 3

Re: [PATCH v28 0/1] MR9442: comctl32/treeview: check for child item before SendExpanding
by Thomas Csovcsity (＠thc13) Feb. 24, 2026

Feb. 24, 2026

Thomas Csovcsity (@thc13) commented about dlls/comctl32/treeview.c: > if (!TREEVIEW_HasChildren(infoPtr, item)) > return FALSE; > > - if (bUser && TREEVIEW_SendExpanding(infoPtr, item, action)) > - return TRUE; > - > + /* > + * the child items may not actually exist, they could be virtual. > + * Just use item->firstChild to check for physical children, > + * before TREEVIEW_SendExpanding may change it. > + */ Commet is from https://gitlab.winehq.org/thc13/wine/-/edit/treeview_bug-23077/dlls/comctl3… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9442#note_130393

1 0

[PATCH 0/1] MR10179: po: update Polish translation
by Adam Markowski (＠AMark) Feb. 24, 2026

Feb. 24, 2026

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

2 1

Re: [PATCH v6 0/1] MR10174: bcryptprimitives: Make ProcessPrng always return `TRUE`
by Christopher Denton (＠cdenton) Feb. 24, 2026

Feb. 24, 2026

On Tue Feb 24 15:53:32 2026 +0000, Paul Gofman wrote: > At very least, that could maybe use some test, if there are reasons why > it is useful which I am missing. What will happen on Windows if the > buffer is invalid (or unaligned) pointer, if buffer is NULL, if size is > ~0u? Will it cause access violation, program abort without exception or > maybe will just fail with an error? Testing on Windows, it causes an access violation if the buffer is NULL or otherwise not writeable. I've not found any other cases that fail. It works on bytes so alignment isn't an issue. Looking at the implementation of `get_random` in https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/unix/system.c#…, it doesn't look like the wine implementation can fail either except if the buffer is NULL. The only place I can see that returns an error is: https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/unix/system.c#… ```c len = peb->NumberOfProcessors * sizeof(SYSTEM_INTERRUPT_INFORMATION); if (size >= len) { if (!info) ret = STATUS_ACCESS_VIOLATION; else get_random( info, len ); } ``` The `if (size >= len)` check in that function will trivially succeed because the `fill_random_buffer` function ensures that `size` is small enough. And if `NtQuerySystemInformation` returns successfully then every other function up the chain will return successfully too. So it seems the behaviour is aligned with Windows except for that NULL check. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130382

1 0

[PATCH v6 0/3] MR9915: mmdevapi: Device name changes.
by Bernhard Kölbl Feb. 24, 2026

Feb. 24, 2026

Phasmophobia needs this to get in-game voice chat working. -- v6: mmdevapi: Adjust device names. mmdevapi/tests: Check device friendly name pattern. mmdevapi/tests: Simplify a trace. https://gitlab.winehq.org/wine/wine/-/merge_requests/9915

2 4

Re: [PATCH v6 0/1] MR10174: bcryptprimitives: Make ProcessPrng always return `TRUE`
by Paul Gofman (＠gofman) Feb. 24, 2026

Feb. 24, 2026

At very least, that could maybe use some test, if there are reasons why it is useful which I am missing. What will happen on Windows if the buffer is invalid (or unaligned) pointer, if buffer is NULL, if size is ~0u? Will it cause access violation, program abort without exception or maybe will just fail with an error? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130375

1 0

[PATCH v5 0/1] MR10174: bcryptprimitives: Abort if ProcessPrng fails
by Christopher Denton (＠cdenton) Feb. 24, 2026

Feb. 24, 2026

[`ProcessPrng`] is documented as always returning TRUE. So I've modified `ProcessPrng` to abort on errors. This is I believe an import aspect of the function. See Microsoft's [The Windows 10 random number generation infrastructure] whitepaper. > We also have the property that a request for random bytes never fails. In the past our RNG functions could return an error code. We have observed that there are many callers that never check for the error code, even if they are generating cryptographic key material. This can lead to serious security vulnerabilities if an attacker manages to create a situation in which the RNG infrastructure returns an error. For that reason, the Win10 RNG infrastructure will never return an error code and always produce high-quality random bytes for every request. [`ProcessPrng`]: https://learn.microsoft.com/en-us/windows/win32/seccng/processprng [The Windows 10 random number generation infrastructure]: https://www.microsoft.com/en-us/security/blog/2019/11/25/going-in-depth-on-… -- v5: bcryptprimitives: Abort if ProcessPrng fails https://gitlab.winehq.org/wine/wine/-/merge_requests/10174

4 4

[PATCH v4 0/1] MR10174: bcryptprimitives: Abort if ProcessPrng fails
by Christopher Denton (＠cdenton) Feb. 24, 2026

Feb. 24, 2026

[`ProcessPrng`] is documented as always returning TRUE. So I've modified `ProcessPrng` to abort on errors. This is I believe an import aspect of the function. See Microsoft's [The Windows 10 random number generation infrastructure] whitepaper. > We also have the property that a request for random bytes never fails. In the past our RNG functions could return an error code. We have observed that there are many callers that never check for the error code, even if they are generating cryptographic key material. This can lead to serious security vulnerabilities if an attacker manages to create a situation in which the RNG infrastructure returns an error. For that reason, the Win10 RNG infrastructure will never return an error code and always produce high-quality random bytes for every request. [`ProcessPrng`]: https://learn.microsoft.com/en-us/windows/win32/seccng/processprng [The Windows 10 random number generation infrastructure]: https://www.microsoft.com/en-us/security/blog/2019/11/25/going-in-depth-on-… -- v4: bcryptprimitives: Abort if ProcessPrng fails https://gitlab.winehq.org/wine/wine/-/merge_requests/10174

3 2

[PATCH v3 0/1] MR10174: bcryptprimitives: Abort if ProcessPrng fails
by Christopher Denton (＠cdenton) Feb. 24, 2026

Feb. 24, 2026

[`ProcessPrng`] is documented as always returning TRUE. So I've modified `ProcessPrng` to abort on errors. This is I believe an import aspect of the function. See Microsoft's [The Windows 10 random number generation infrastructure] whitepaper. > We also have the property that a request for random bytes never fails. In the past our RNG functions could return an error code. We have observed that there are many callers that never check for the error code, even if they are generating cryptographic key material. This can lead to serious security vulnerabilities if an attacker manages to create a situation in which the RNG infrastructure returns an error. For that reason, the Win10 RNG infrastructure will never return an error code and always produce high-quality random bytes for every request. [`ProcessPrng`]: https://learn.microsoft.com/en-us/windows/win32/seccng/processprng [The Windows 10 random number generation infrastructure]: https://www.microsoft.com/en-us/security/blog/2019/11/25/going-in-depth-on-… -- v3: bcryptprimitives: Abort if ProcessPrng fails https://gitlab.winehq.org/wine/wine/-/merge_requests/10174

2 1

[PATCH v2 0/1] MR10174: bcryptprimitives: Abort if ProcessPrng fails
by Christopher Denton (＠cdenton) Feb. 24, 2026

Feb. 24, 2026

[`ProcessPrng`] is documented as always returning TRUE. So I've modified `ProcessPrng` to abort on errors. This is I believe an import aspect of the function. See Microsoft's [The Windows 10 random number generation infrastructure] whitepaper. > We also have the property that a request for random bytes never fails. In the past our RNG functions could return an error code. We have observed that there are many callers that never check for the error code, even if they are generating cryptographic key material. This can lead to serious security vulnerabilities if an attacker manages to create a situation in which the RNG infrastructure returns an error. For that reason, the Win10 RNG infrastructure will never return an error code and always produce high-quality random bytes for every request. [`ProcessPrng`]: https://learn.microsoft.com/en-us/windows/win32/seccng/processprng [The Windows 10 random number generation infrastructure]: https://www.microsoft.com/en-us/security/blog/2019/11/25/going-in-depth-on-… -- v2: bcryptprimitives: Abort if ProcessPrng fails https://gitlab.winehq.org/wine/wine/-/merge_requests/10174

4 7