- Wine-GitLab - list.winehq.org

[PATCH 0/1] MR10040: inkobj: Correct install path.
by Alistair Leslie-Hughes (＠alesliehughes) Feb. 6, 2026

Feb. 6, 2026

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

2 1

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

Feb. 6, 2026

This merge request was closed by Kun Yang. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10034

1 0

[PATCH v5 0/1] MR10036: winemac.drv: Unconditionally use CreateIconFromResourceEx for app icons.
by Tim Clem (＠tclem) Feb. 5, 2026

Feb. 5, 2026

Sidesteps an issue cause by some apps having an inaccurate size for the resource in the GRPICONDIR size ; CreateIconFromResourceEx handles that case, but the old CGImage path would fault if the GRPICONDIR size was too large. --- It seems that some apps have different sizes in the GRPICONDIR and the IMAGE_RESOURCE_DATA_ENTRY. winemenubuilder has had a workaround for this since 2014 - see c205e6800a63a5df9960d8484a2e67687d53bc50. The size difference is great enough in some situations (e.g. Brotato) that the attempt read the resource may fault, but that's only because we passed the PNG data over to the Unix side of winemac.drv directly, and used CG methods to deal with it, which will attempt to copy in the entire array of bytes. If we use CreateIconFromResourceEx instead, for all cases (it can handle pngs), we do not fault, since that method does not attempt to copy the entire resource size. The original mailing list discussion about the winemenubuilder patch is [here](https://marc.info/?l=wine-patches&m=140903555724711&w=2). Huge thanks to @bshanks for spotting that patch. This has apparently always been faulting for some apps, but only became an issue after !10032. The subsequent syscall fault unwinds out of the pthread_once that !10032 added, so future threads that wind up there will hang. -- v5: winemac.drv: Unconditionally use CreateIconFromResourceEx for app icons. https://gitlab.winehq.org/wine/wine/-/merge_requests/10036

3 3

Re: [PATCH v2 0/2] MR10035: kernelbase: Don't write *result on async NtWriteFile returns. - approved
by Alexandre Julliard (＠julliard) Feb. 5, 2026

Feb. 5, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10035

1 0

Re: [PATCH v2 0/2] MR10014: ntdll, mountmgr.sys: Report free space for "important" data on macOS. - approved
by Alexandre Julliard (＠julliard) Feb. 5, 2026

Feb. 5, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10014

1 0

[PATCH v4 0/1] MR10036: winemac.drv: Unconditionally use CreateIconFromResourceEx for app icons.
by Tim Clem (＠tclem) Feb. 5, 2026

Feb. 5, 2026

Sidesteps an issue cause by some apps having an inaccurate size for the resource in the GRPICONDIR size ; CreateIconFromResourceEx handles that case, but the old CGImage path would fault if the GRPICONDIR size was too large. --- It seems that some apps have different sizes in the GRPICONDIR and the IMAGE_RESOURCE_DATA_ENTRY. winemenubuilder has had a workaround for this since 2014 - see c205e6800a63a5df9960d8484a2e67687d53bc50. The size difference is great enough in some situations (e.g. Brotato) that the attempt read the resource may fault, but that's only because we passed the PNG data over to the Unix side of winemac.drv directly, and used CG methods to deal with it, which will attempt to copy in the entire array of bytes. If we use CreateIconFromResourceEx instead, for all cases (it can handle pngs), we do not fault, since that method does not attempt to copy the entire resource size. The original mailing list discussion about the winemenubuilder patch is [here](https://marc.info/?l=wine-patches&m=140903555724711&w=2). Huge thanks to @bshanks for spotting that patch. This has apparently always been faulting for some apps, but only became an issue after !10032. The subsequent syscall fault unwinds out of the pthread_once that !10032 added, so future threads that wind up there will hang. -- v4: winemac.drv: Unconditionally use CreateIconFromResourceEx for app icons. https://gitlab.winehq.org/wine/wine/-/merge_requests/10036

3 3

[PATCH v3 0/1] MR10036: winemac.drv: Unconditionally use CreateIconFromResourceEx for app icons.
by Tim Clem (＠tclem) Feb. 5, 2026

Feb. 5, 2026

Sidesteps an issue cause by some apps having an inaccurate size for the resource in the GRPICONDIR size ; CreateIconFromResourceEx handles that case, but the old CGImage path would fault if the GRPICONDIR size was too large. --- It seems that some apps have different sizes in the GRPICONDIR and the IMAGE_RESOURCE_DATA_ENTRY. winemenubuilder has had a workaround for this since 2014 - see c205e6800a63a5df9960d8484a2e67687d53bc50. The size difference is great enough in some situations (e.g. Brotato) that the attempt read the resource may fault, but that's only because we passed the PNG data over to the Unix side of winemac.drv directly, and used CG methods to deal with it, which will attempt to copy in the entire array of bytes. If we use CreateIconFromResourceEx instead, for all cases (it can handle pngs), we do not fault, since that method does not attempt to copy the entire resource size. The original mailing list discussion about the winemenubuilder patch is [here](https://marc.info/?l=wine-patches&m=140903555724711&w=2). Huge thanks to @bshanks for spotting that patch. This has apparently always been faulting for some apps, but only became an issue after !10032. The subsequent syscall fault unwinds out of the pthread_once that !10032 added, so future threads that wind up there will hang. -- v3: winemac.drv: Unconditionally use CreateIconFromResourceEx for app icons. https://gitlab.winehq.org/wine/wine/-/merge_requests/10036

4 7

[PATCH v2 0/1] MR10036: winemac.drv: Attempt to correct the size of icon resources.
by Tim Clem (＠tclem) Feb. 5, 2026

Feb. 5, 2026

It seems that some apps have different sizes in the GRPICONDIR and the IMAGE_RESOURCE_DATA_ENTRY. winemenubuilder has had the same workaround since 2014 - see c205e6800a63a5df9960d8484a2e67687d53bc50. --- The size difference is great enough in some situations (e.g. Brotato) that the attempt read the resource may fault. The original mailing list discussion about the winemenubuilder patch is [here](https://marc.info/?l=wine-patches&m=140903555724711&w=2). Huge thanks to @bshanks for spotting that patch. This has apparently always been faulting for some apps, but only became an issue after !10032. The subsequent syscall fault unwinds out of the pthread_once that !10032 added, so future threads that wind up there will hang. -- v2: winemac.drv: Attempt to correct the size of icon resources. https://gitlab.winehq.org/wine/wine/-/merge_requests/10036

4 9

[PATCH 0/1] MR10036: winemac.drv: Attempt to correct the size of icon resources.
by Tim Clem (＠tclem) Feb. 5, 2026

Feb. 5, 2026

It seems that some apps have different sizes in the GRPICONDIR and the IMAGE_RESOURCE_DATA_ENTRY. winemenubuilder has had the same workaround since 2014 - see c205e6800a63a5df9960d8484a2e67687d53bc50. --- The size difference is great enough in some situations (e.g. Brotato) that the attempt read the resource may fault. The original mailing list discussion about the winemenubuilder patch is [here](https://marc.info/?l=wine-patches&m=140903555724711&w=2). Huge thanks to @bshanks for spotting that patch. This has apparently always been faulting for some apps, but only became an issue after !10032. The subsequent syscall fault unwinds out of the pthread_once that !10032 added, so future threads that wind up there will hang. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10036

3 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

> Please explain in more details what's happening here. Probably you meant the reason it grows to 2GB. I believe it is caused by `-Wl,-Ttext=0x7d400000` (introduced in cbd2af9213fb76e2ed2e7d7a9151100f45f0679c). This option forces the `.text` segment to be placed at a high virtual address. When combined with `-Wl,--no-rosegment` (which is implicitly passed for older Android SDK levels), the linker changes how it groups sections into `PT_LOAD` segments. To preserve the required relation between virtual addresses and file offsets inside a `PT_LOAD` segment, the linker ends up assigning a very large file offset (`0x7d400000`) to the segment containing `.text`. This creates a huge sparse gap in the output file, making its apparent size close to 2GB. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9977#note_128885

1 0

[PATCH 0/1] MR9874: Draft: wineandroid.drv: experimental bring-up fixes for Android 7.1.x (discussion starter)
by Twaik Yont (＠twaik) Feb. 5, 2026

Feb. 5, 2026

#### 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. It is primarily intended as a discussion starter rather than a final or polished solution. 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. At the moment, all changes are provided as a single patch. This is intentional: until at least one of the proposed changes is confirmed as a valid or acceptable fix, the patchset is kept consolidated to simplify iteration. Once individual changes are reviewed or agreed upon, the history can be rewritten (via force-push) to split them into logical, self-contained commits. #### Test environment and context All testing so far was performed on Android 7.1.2 x86 images from the Android-x86 project. 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. `virtual_alloc_first_teb` failure Wine frequently failed early during startup with: ``` err:virtual:virtual_alloc_first_teb wine: failed to map the shared user data: c0000018 ``` This failure was not observed on older Wine versions. It appears to be related to JNI interaction occurring too early during initialization, interfering with allocation of the shared user data region at the required fixed address. This was resolved by moving the call to `virtual_init()` earlier in `wine_init_jni()`, before JNI-related activity begins. 2. Missing exported JNI symbols The symbols `java_vm`, `java_object`, and `java_gdt_sel` were no longer visible when accessed via `dlopen`/`dlsym`. This appears to be a consequence of newer toolchain and linker behavior. The issue was resolved by explicitly exporting these symbols using `DECLSPEC_EXPORT`. 3. Desktop thread assertion during startup Wine aborted with the following assertion: ``` dlls/wineandroid.drv/window.c:519: int wait_events(int): assertion "GetCurrentThreadId() == desktop_tid" failed ``` The failure happens because `pCreateDesktop()` is now invoked before `pCreateWindow()`, while the existing code expected `desktop_tid` to be set during `pCreateWindow()`. As a result, the event waiting path may execute before `desktop_tid` is initialized. This was addressed by moving `init_event_queue()` and `start_android_device()` from `pCreateWindow()` into `pCreateDesktop()`, ensuring the event queue and device startup occur before `wait_events()` is used. 4. Recursive desktop recreation The change described above introduced a new problem: `create_desktop_window()` could be triggered repeatedly. Each Java-side content window creation/layout initialization caused additional resolution/configuration change notifications, which in turn could cause repeated desktop window recreation. This was mitigated by changing the Java/native glue so that when a window/view is being created, the code explicitly checks whether the target is the desktop window and passes this information to Java as a flag. This avoids triggering repeated content-window initialization paths during desktop recreation. 5. WineAndroid device path change Opening the device using `\\.\WineAndroid` no longer works. Switching to `\Device\WineAndroid` resolved the issue. The fix itself is simple but required for basic functionality. 6. Rendering stalls and USER lock assertion Rendering occasionally stalled or crashed with: ``` err:system:user_check_not_lock BUG: holding USER lock ``` Adding TRACE statements often caused the issue to disappear, making it difficult to debug and reproduce reliably. After extensive experimentation, it was discovered that inserting a full memory barrier: ``` __sync_synchronize(); ``` at a specific point makes the issue reliably disappear in the tested setup. This suggests a race or memory visibility/ordering problem. At this time it is unclear whether the root cause is an internal behavioral change in Wine, NDK toolchain/codegen changes, or some other interaction specific to the Android 7.1.x environment. The current change should be treated as a workaround and a starting point for further investigation rather than a definitive fix. #### 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.** -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9874

4 6

[PATCH 0/1] MR10033: winex11.drv: Fix x11drv_egl_surface_swap() swap for the case of absent current context.
by Paul Gofman (＠gofman) Feb. 5, 2026

Feb. 5, 2026

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

3 7

[PATCH 0/2] MR10035: kernelbase: Don't write *result on async NtWriteFile returns.
by Stefan Dösinger Feb. 5, 2026

Feb. 5, 2026

If the caller passes the same pointer to WriteFile as it passes to GetOverlappedResult in another thread, the writes to the memory location in the two files will race each other. --- Is there ever a case where piosb->Information != 0 when status != 0 (or NT_ERROR(status))? If an error status always suggests a 0 length, we can remove the check for overlapped != NULL here. DeviceIoControl is potentially affected too, but it doesn't set *returned=0 in any situation. I think ws2_32:AcceptEx might be affected by the same problem too. The other ws32_32 functions look ok. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10035

1 2

[PATCH v2 0/8] MR10019: opengl32: Move wglGetProcAddress implementation to the PE side.
by Rémi Bernon Feb. 5, 2026

Feb. 5, 2026

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

1 10

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

[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