- Wine-GitLab - list.winehq.org

[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

[PATCH 0/2] MR8368: libs/xml2: Import upstream release 2.13.8.
by Daniel Lehman (＠dlehman25) Feb. 5, 2026

Feb. 5, 2026

import with 2 small changes: - config.h -> win32config.h - comment out deprecation to avoid warnings while preserving `xmlThrDefTreeIndentString` (for 8c792c25) https://testbot.winehq.org/JobDetails.pl?Key=158748 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8368

5 6

[PATCH v3 0/1] MR9956: wined3d: Check invalid addresses when copying buffer objects.
by Zhiyi Zhang (＠zhiyi) Feb. 5, 2026

Feb. 5, 2026

When a thread that created windows is being closed, the destination buffer address might be NULL. For example: 1. context_gl->internal_format_set is set to 1 in wined3d_context_gl_set_pixel_format(). 2. A thread gets destroyed, all the windows in the thread get destroyed. 3. wined3d_context_gl_set_pixel_format() fails because WindowFromDC() returns NULL. 4. get_dc_pixel_format() fails in win32u_wglMakeContextCurrentARB(). 5. wined3d_buffer_gl_create_buffer_object() fails to create a buffer object. 6. wined3d_buffer_get_memory() returns a struct wined3d_bo_address with addr being NULL. Adding a NULL check in wined3d_context_gl_copy_bo_address() avoids triggering write segfaults when terminating a thread. This could happen for React Native applications. -- v3: wined3d: Reset internal format when using the backup DC. https://gitlab.winehq.org/wine/wine/-/merge_requests/9956

3 5