August 2026 - Wine-GitLab - list.winehq.org

[PATCH v3 0/1] MR11701: loader: detect circular export forwarders and return the appropriate error
by Kyle Yang (＠kyle) Aug. 24, 2026

Aug. 24, 2026

When export forwarders have circular dependencies, Wine currently causes a stack overflow, which differs from Windows behavior. This patch uses a stack to detect circular dependencies and returns the same error code as Windows. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=60130 Signed-off-by: Kyle Yang kyle.chaoxin.yang(a)gmail.com -- v3: loader: detect circular export forwarders and return the appropriate error https://gitlab.winehq.org/wine/wine/-/merge_requests/11701

2 1

[PATCH v10 0/1] MR11315: winevdm.c: Fix how Wine handles DOS-era PIF files.
by Iain S. McCluney (＠BigBlueGnu) Aug. 24, 2026

Aug. 24, 2026

This merge request has been split into three, the other two being [here](https://gitlab.winehq.org/wine/wine/-/merge_requests/11498) and [here](https://gitlab.winehq.org/wine/wine/-/merge_requests/11487). This one focuses on a patch for Wine's handling of PIF files as described in [issue 3638](https://bugs.winehq.org/show_bug.cgi?id=3638). -- v10: winevdm.c: Fix how Wine handles DOS-era PIF files. https://gitlab.winehq.org/wine/wine/-/merge_requests/11315

2 3

[PATCH v2 0/2] MR11333: winemac, ntdll: Convert the main thread to a Wine system thread when needed.
by Rémi Bernon (＠rbernon) Aug. 24, 2026

Aug. 24, 2026

Similar to what https://gitlab.winehq.org/wine/wine/-/merge_requests/9579 and https://gitlab.winehq.org/wine/wine/-/merge_requests/10058 were doing. This is just for winemac, the magic happens in ntdll where CFRunLoopRun start proc is treated specifically by `spawn_thread` and doesn't actually spawns a new thread but schedules a server_init_thread call in the pre-existing main loop, initializing Wine thread data and recursively calling the macOS main loop without (I think?) returning from it. It then makes it possible at least to use Wine tracing subsystem in winemac main thread, and ultimately should make it possible to call some win32u functions directly from it too. We cannot process window messages there, it's a system thread without a user stack, but it can interact with win32u state and post messages to other threads. It's still going to be a long road ahead if we want to replace winemac internal events (which I think would be nice), because many things still expect some winemac specific threading, but it would be possible at least. Ultimately I still think that it would be nice to generalize this "main" system thread into a ntdll "sched"-uling subsystem that could back all of the win32u drivers host fd polling / UI event processing / scheduling needs, including for an in-process window compositor, as well as any extra unixlib fd polling / timer / scheduling we might find useful to have. There was for instance some discussion about how to integrate DBus connection polling nicely, and this could use it. On macOS this would be the main thread, on other platforms a system thread would be spawned as needed. -- v2: ntdll: Allow converting the macOS main thread into a Wine thread. winemac: Return early on failures in macdrv_start_cocoa_app. https://gitlab.winehq.org/wine/wine/-/merge_requests/11333

3 11

Re: [PATCH v3 0/1] MR11692: wined3d: Cast UINT64 handles through UINT_PTR to avoid compiler warnings.
by Sven Baars (＠sbaars) Aug. 24, 2026

Aug. 24, 2026

`(uintptr_t)` is used elsewhere in this file, so using that may be preferred. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11692#note_149630

1 0

[PATCH v2 0/1] MR11740: compobj: Ensure compobj_malloc is initialized in CoGetMalloc16.
by Alex Henrie (＠alexhenrie) Aug. 24, 2026

Aug. 24, 2026

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=60229 -- v2: compobj: Ensure compobj_malloc is initialized in CoGetMalloc16. https://gitlab.winehq.org/wine/wine/-/merge_requests/11740

2 1

[PATCH 0/2] MR11739: pdh: Avoid access violation in PdhCloseQuery if a bad handle is passed.
by Ziia Shi (＠mkrsym1) Aug. 24, 2026

Aug. 24, 2026

This behavior is observed in the global release of the game Wuthering Waves, specifically in the Tencent PerfSight component. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11739

2 2

[PATCH 0/2] MR11738: win87em, krnl386: Set and call application-defined floating-point error handler.
by Alex Henrie (＠alexhenrie) Aug. 24, 2026

Aug. 24, 2026

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=60230 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11738

2 2

[PATCH v2 0/2] MR11717: faudio: Initialize COM before creating the WMA decoder.
by Nello De Gregoris (＠bluechxin) Aug. 23, 2026

Aug. 23, 2026

Found while testing STEINS;GATE RE:BOOT (https://store.steampowered.com/app/4012810/STEINSGATE_REBOOT/) The visual novel voiceovers were not playing and every time one was supposed to play, the following showed up in logs: `err:ole:com_get_class_object apartment not initialised` Tracing this led me to `FAudio_WMADEC_init`, which runs CoCreateInstance on the thread the application called IXAudio2::CreateSourceVoice() from, with FAudio however never initializing COM on that path. That makes combase then reject the call with the decoder never being created. I believe most games don't run into this because Media Foundation is usually initialized before this code path is hit, which leaves a process-wide MTA in place. Since the voiceovers play correctly on Windows, handling it in FAudio seemed like the right call. -- v2: faudio: Initialize MTA in FAudio_PlatformAddRef(). xaudio2/tests: Test creating an xWMA source voice without COM. https://gitlab.winehq.org/wine/wine/-/merge_requests/11717

4 7

[PATCH 0/1] MR11736: ntdll: Keep reserved area bounds page aligned when avoiding 4GB wrap-around
by Nat Brown (＠natbro) Aug. 23, 2026

Aug. 23, 2026

A latent issue found in ntdll while adding Apple Silicon macOS host support for building Proton (https://github.com/ValveSoftware/Proton/pull/10087) Proton's Wine version builds and then runs 64-bit and 32-bit versions of wine in order to create a base prefix as part of a redistributable package phase, all within a guest linux/amd64 container. 32-bit i386 processes translate with QEMU in this host context, while 64-bit x86_64 uses the host's Rosetta 2 translation system. It is likely but not confirmed that QEMU would similarly be used and 32-bit wine would fail to run when virtualizing linux/amd64 on linux/arm64 hardware. mmap_add_reserved_area() and mmap_remove_reserved_area() trim a single byte when addr + size wraps to 0, which leaves an area whose end is 0xffffffff. alloc_virtual_heap() then derives its mapping address from that end and passes an unaligned address to anon_mmap_fixed(), tripping the alignment assertions added in d813ffc3557 (ntdll: Align virtual memory allocations to the host page size). Trim a whole page instead so the area bounds stay aligned. The wrap-around trim dates to 94d74b5fedf (2004), long before the alignment invariant existed. It is only reached when a reserved area ends exactly at 4GB, which requires mmap_init() to take the reserve_area( user_space_limit, 0 ) branch -- that is, when the initial stack is not near the top of the 32-bit address space. Native Linux and all other native x86 platforms place it near the top, so the branch is dead there; qemu-user lays out the guest address space itself and maps the stack around 0x40000000, making it reachable and aborting every 32-bit process at startup. Nothing verifies requested against recorded area bounds, and the top 64k allocation granularity block was already unusable due to the one-byte trim, so widening it to a page costs nothing allocatable. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11736

2 1

[PATCH 0/1] MR11735: mfplat/tests: Remove todo on now succeeding test.
by Nikolay Sivov (＠nsivov) Aug. 23, 2026

Aug. 23, 2026

This one was fixed by d3d11 changes e980a920092d5f16aa75bb4a5c6d8a3bb8d32cfc. Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11735

2 1