February 2026 - Wine-gitlab

[PATCH v2 0/8] MR10019: opengl32: Move wglGetProcAddress implementation to the PE side.
by Rémi Bernon (＠rbernon) 05 Feb '26

05 Feb '26

This better splits client / host extension lists, allowing to more easily check for available host-side extensions in win32u later on, then moves the function registry to the PE side to get rid of the remaining extension logic in opengl32 unix side. Doing that, it also drops the driver function check, and always expose extension functions to the client if their extension dependency is satisfied. I'm not completely sure this is right, but I think the unix side tends to expose functions from eglGetProcAddress more often than the opposite. We could also keep a mechanism to check the driver availability, with a bit of additional complexity. On the unix side, all OpenGL functions are queried on initialization instead of just core functions, simplifying their use later on. -- v2: opengl32: Implement the function registry on the PE side. win32u: Query every OpenGL functions on initialization. opengl32: Implement client extension enumeration on the PE side. opengl32: Move major / minor version to the PE side context wrapper. opengl32: Parse host extension list to the opengl_extensions struct. opengl32: Remove now unused wgl pixel format unix thunks. opengl32: Implement wglGetExtensionsString(ARB|EXT) on the PE side. opengl32: Initialize enabled / disabled OpenGL extensions struct. https://gitlab.winehq.org/wine/wine/-/merge_requests/10019

2 10

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

05 Feb '26

> 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) 05 Feb '26

05 Feb '26

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) 05 Feb '26

05 Feb '26

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) 05 Feb '26

05 Feb '26

> 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) 05 Feb '26

05 Feb '26

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) 05 Feb '26

05 Feb '26

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) 05 Feb '26

05 Feb '26

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) 05 Feb '26

05 Feb '26

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) 05 Feb '26

05 Feb '26

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

1 0