February 2026 - Wine-GitLab

Re: [PATCH v6 0/6] MR9977: wineandroid: Fix build issues and early runtime regressions on modern Android toolchains
by Twaik Yont (＠twaik) Feb. 5, 2026

Feb. 5, 2026

> We don't use strings.h in Wine. Other places use \__builtin_ffs which is probably what we want here. I can make the patch for this, but I am not sure I can properly test it. But I think CI should catch any related regression. Not sure about MacOS related builds. Do you want me to make a separate MR for this? > There's nothing Android-specific about this. It should check for the availability of the corresponding function or define (assuming we really need a robust mutex here, I'm not sure that's the case). On Android the check will report that the mutex attribute and defines are available, but the code will fail in runtime. Or probably the runtime linker will report missing function during application startup. It only means NDK contains required exports, but device's bionic libc (on old devices) may not contain them or can not handled them properly. > Please explain in more details what's happening here. I thought it was r22 change but seems like I am wrong. Or at least it is stated in https://github.com/android/ndk/wiki/Changelog-r22 but we've got this problem only when switched to the new NDK release. > Issue 1196: Backtraces for crashes on devices older than API 29 are now correct when using LLD if using ndk-build or the CMake toolchain file. If using a different system and targeting devices older than API 29, use -Wl,--no-rosegment when linking. See the Build System Maintainers Guide for more information. Termux maintainers found out that NDK (starting with r29) implicitly passes `-Wl,--no-rosegment` to the linker (or probably they make it the new default?) and we are required to push that into our `LDFLAGS` (at least in our build configuration). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9977#note_128852

1 0

[PATCH 0/1] MR10034: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails.
by Kun Yang (＠yangkun) Feb. 5, 2026

Feb. 5, 2026

When I was porting a software from windows, I met a problem that the icons in the imagelist were not displaying correctly. In the Application, the correct icons are: ![1](/uploads/7274d570f0fd04beeefebf978b92ab1d/1.bmp){width=269 height=29} But when I run it under wine is like this: ![2](/uploads/ba6abd5d54fdfe3acccb63480441875a/2.bmp){width=271 height=29} When I disassable the application code I found that the Application calls ImageList_Create by given a very large cInitial, which is 0xc0c0c0. This will lead to CreateDIBSection fail. Then the source hbitmap is lost, only hMask is left and shown up on the screen. I use windbg to debug this application on windows, I found that after ImageList_Create is called on Winodws, there is a valid hbitmap handle generated. When ImageList_Add is called for 4 times, it changed and called Bitblt to copy the hbitmap already added. So I guess windows has the error handling for ImageList_Create. If CreateDIBSection failes due to the large image count, it reduced the image count. By observing the action in ImageList_Add, I think the reduced count is 1 (4x1). Then fix the cMaxImage to 1+1 which is same as ImageListImpl_Initialize to make the hbitmap expand. The example in the attachment can reproduce this bug. [imagelist.7z](/uploads/1dc389930eb809adc02be617f05b771e/imagelist.7z) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10034

2 1

[PATCH v8 0/1] MR9999: winex11.drv: Fix window stacking order with insert_after parameter.
by Zhao Yi (＠Zhaoyi) Feb. 5, 2026

Feb. 5, 2026

When calling the SetWindowPos function to change the window Z-order with an insert_after parameter as a real window handle, the expected result is that the insert_after window appears above the specified window hwnd. For example, calling SetWindowPos(g_hwndB, g_hwndA, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_SHOWWINDOW | SWP_NOACTIVATE) should result in window A appearing above window B. Below is a demo showing test results on Windows versus Wine: The initial z-order of WindowA and WindowB is: WindowB is above WindowA: ![zo-1.png](/uploads/a190a622181ab71682ecd2908d5d649b/zo-1.png){width=781 height=399} Next, click the "Place WindowA above WindowB" button on Windows and Wine respectively. The test results are as follows: On Windows, After clicking the button, WindowA is placed above WindowB: ![zo-2.png](/uploads/220a8889e7f08943f20824121ebedd66/zo-2.png){width=801 height=439} \ On wine, After clicking the button, the Z-order of WindowA and WindowB remains unchanged: ![image.png](/uploads/158905a1fa6702fcd9fb0e5e810e2ad5/image.png){width=900 height=444} demo： [demo.cpp](/uploads/6e3a44e8b223e54d28c2d65e66856d40/demo.cpp) Signed-off-by: Zhao Yi zhaoyi(a)uniontech.com -- v8: winex11.drv: Fix window stacking order with insert_after parameter. https://gitlab.winehq.org/wine/wine/-/merge_requests/9999

2 1

Re: [PATCH v6 0/6] MR9977: wineandroid: Fix build issues and early runtime regressions on modern Android toolchains
by Alexandre Julliard (＠julliard) Feb. 5, 2026

Feb. 5, 2026

> Including <strings.h> only makes the dependency explicit and does not change behavior on platforms where it was already indirectly included. We don't use strings.h in Wine. Other places use __builtin_ffs which is probably what we want here. > winepulse: Do not use pthread mutex attributes on Android There's nothing Android-specific about this. It should check for the availability of the corresponding function or define (assuming we really need a robust mutex here, I'm not sure that's the case). > Without --rosegment the linker may generate a wine-preloader ELF roughly 2GB in size due to segment layout. Please explain in more details what's happening here. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9977#note_128849

1 0

[PATCH 0/1] MR9998: shell32: ShellExecute uses SW_SHOWDEFAULT by default
by Fan Zhou (＠zhoufan_uniontech) Feb. 5, 2026

Feb. 5, 2026

This patch applies to applications that launch processes via ShellDispatch without specifying a show mode (such as WPS PDF Editor). When no show parameter is specified, VT_EMPTY is converted to the integer 0 (i.e., SW_HIDE), causing the main window to be hidden by default. This behavior is now adjusted to use the default show mode. The modification references Microsoft’s official description of the IShellDispatch2.ShellExecute interface: "If this parameter is not specified, the application uses its default value." -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9998

2 2

Re: [PATCH v6 0/6] MR9977: wineandroid: Fix build issues and early runtime regressions on modern Android toolchains
by Twaik Yont (＠twaik) Feb. 5, 2026

Feb. 5, 2026

On Thu Feb 5 07:05:30 2026 +0000, Alexandre Julliard wrote: > I merged most of these, the remaining ones will need some more thought. Thanks for looking at these patches. About the remaining commits: 1) `ntdll: Include <strings.h> for ffs() declaration` This change should be harmless. ffs() is already implicitly pulled in through other headers, which is why this issue usually does not surface. However, with stricter C99+ toolchains (e.g. clang used in Termux / Android environments), implicit function declarations are rejected and this results in build failures like: ``` /home/twaik/.termux-build/wine-stable/src/dlls/ntdll/unix/unix_private.h:660:26: error: call to undeclared function 'ffs'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 660 | idx = idx * 32 + ffs( ~ldt_bitmap[idx] ) - 1; | ^ 1 error generated. make: *** [Makefile:250029: dlls/ntdll/unix/loadorder.o] Error 1 ``` Including <strings.h> only makes the dependency explicit and does not change behavior on platforms where it was already indirectly included. --- 2) `winepulse: Do not use pthread mutex attributes on Android` This change is Android-only and does not affect other platforms. Android only provides pthread_mutexattr_setprotocol() starting from API 28 and does not support robust mutexes at all. Attempting to use these attributes prevents winepulse from building in Android environments. Falling back to a default mutex on Android keeps existing behavior elsewhere unchanged. This is particularly useful for downstream Android-based projects (compiling Wine with Android NDK: Termux, Winlator-bionic, MiceWine, etc.) which rely on PulseAudio for sound output and currently have no alternative backend. --- 3) `wineandroid: force --rosegment for wine-preloader` This change is inside the Android-specific configure section and should not affect other platforms. Without --rosegment the linker may generate a wine-preloader ELF roughly 2GB in size due to segment layout. The patch only appends the flag to WINEPRELOADER_LDFLAGS and only when the toolchain supports it, so it should be safe and fully isolated to Android builds. --- Should I make separate merge request for these changes? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9977#note_128846

1 0

Re: [PATCH v5 0/7] MR9979: mf/tests: Test SAR's IMFPresentationTimeSource interface.
by Brendan McGrath (＠redmcg) Feb. 5, 2026

Feb. 5, 2026

v5: - rebase to master -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9979#note_128845

1 0

Re: [PATCH v3 0/6] MR9969: mf: Fix seeking on sample grabber by matching Windows.
by Brendan McGrath (＠redmcg) Feb. 5, 2026

Feb. 5, 2026

v3: - rebase to master -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9969#note_128842

1 0

Re: [PATCH v11 0/6] MR9646: mf/tests: Scrubbing tests
by Brendan McGrath (＠redmcg) Feb. 5, 2026

Feb. 5, 2026

v11: - rebase to master -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9646#note_128840

1 0

Re: [PATCH v4 0/7] MR9979: mf/tests: Test SAR's IMFPresentationTimeSource interface.
by Brendan McGrath (＠redmcg) Feb. 5, 2026

Feb. 5, 2026

On Thu Jan 29 20:11:09 2026 +0000, Brendan McGrath wrote: > Sorry, I still haven't looked in to this. One thing I did recall seeing > is ([src](https://learn.microsoft.com/en-us/windows/win32/medfound/streaming-aud…) > > If the playback rate is faster or slower than 1×, the SAR > automatically adjusts the pitch. > This makes it sound like SAR itself does pitch scaling and therefore > probably also defines those values. But I'll need to investigate further > to be sure. I suspect this may be hard coded in SAR. I tried every media type (using `IMFMediaTypeHandler::SetCurrentMediaType`) on every device (using `MF_AUDIO_RENDERER_ATTRIBUTE_ENDPOINT_ID`) and it was always the same result: ``` slowest rate 0.125000 fastest rate 8.000000 ``` I tested the following devices: ``` Speakers (3- High Definition Audio Device) Headphones (3- High Definition Audio Device) SMBX2450 (NVIDIA High Definition Audio) Digital Audio (S/PDIF) (3- High Definition Audio Device) ``` And the following subtypes: ``` MFAudioFormat_Dolby_AC3_SPDIF MFAudioFormat_DTS MFAudioFormat_Float MFAudioFormat_Float_SpatialObjects ``` The only sample rate I tested though was 48kHz. None of the devices on my PC offered a media type with a different value. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9979#note_128838

1 0