- wine-gitlab - winehq.org

[PATCH 0/6] MR8960: mshtml: Implement XDomainRequest.
by Gabriel Ivăncescu (＠insn) 12 Sep '25

12 Sep '25

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

3 8

[PATCH v2 0/1] MR8962: dbghelp: Fix pointer truncation issues when parsing 64-bit Mach-O binaries in a Wow64 process
by Brendan Shanks (＠bshanks) 12 Sep '25

12 Sep '25

When running `SymInitializeW(GetCurrentProcess(), NULL, TRUE)` in a 32-bit EXE on 64-bit macOS, there are a number of syscall faults resulting from 64-bit pointers being truncated to 32 bits and then passed to `ReadProcessMemory()`. Fix these, mostly by widening variables to 64 bits. -- v2: dbghelp: Don't try to load 64-bit ELF/Mach-O debug info in a Wow64 process. https://gitlab.winehq.org/wine/wine/-/merge_requests/8962

2 2

[PATCH v2 0/8] MR8965: Draft: win32u: Flush window surfaces from owner thread, while waiting for messages.
by Rémi Bernon (＠rbernon) 12 Sep '25

12 Sep '25

Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/8869 I think this would be a much lighter and less complicated approach than trying to wake the window threads with internal messages. And it should be able to avoid spurious wake ups when there's no window surfaces involved. What I'm not completely sure about is whether this is going to flush the surfaces frequently enough, and if we can assume the window thread will always either peek or wait for messages. -- v2: win32u: Keep window surfaces in a per-thread linked list. win32u: Remove window surface flush in expose_window_surface. win32u: Remove window surface flush on lock / unlock. win32u: Remove some less useful flush_window_surfaces. win32u: Flush window surfaces while waiting for messages. win32u: Use an absolute wait timeout in wait_message. win32u: Remove unnecessary window_surface exports. win32u: Dispatch NtUserUpdateLayeredWindow to the owner thread. https://gitlab.winehq.org/wine/wine/-/merge_requests/8965

2 8

[PATCH v2 0/4] MR8869: Draft: server: Post a WINE_WM_PRESENT for window surface present.
by Rémi Bernon (＠rbernon) 12 Sep '25

12 Sep '25

Every 33ms on toplevel windows with a non-dummy, non-offscreen window surface. Making sure the window surfaces are flushed from their owner thread instead of any other thread that might draw to it and trigger an occasional flush. This removes the need for tracking window surfaces to additionally flush them in win32u. It will make it easier to implement GL-based window surfaces for compositing, and simplify context management. Instead of one context per window, made current on the flushing thread we can have a single context on each thread owning a window that is used to flush them. -- v2: win32u: Remove now unnecessary window surfaces list. win32u: Flush window surfaces in process_wine_present. server: Post a WINE_WM_PRESENT for window surface present. win32u: Remove unnecessary window_surface exports. https://gitlab.winehq.org/wine/wine/-/merge_requests/8869

2 8

[PATCH 0/8] MR8965: Draft: win32u: Flush window surfaces from owner thread, while waiting for messages.
by Rémi Bernon (＠rbernon) 12 Sep '25

12 Sep '25

Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/8869 I think this would be a much lighter and less complicated approach than trying to wake the window threads with internal messages. And it should be able to avoid spurious wake ups when there's no window surfaces involved. What I'm not completely sure about is whether this is going to flush the surfaces frequently enough, and if we can assume the window thread will always either peek or wait for messages. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8965

2 8

[PATCH 0/6] MR8878: ntdll: Avoid deadlock on SIGPIPE while holding virtual_mutex or fd_cache_mutex.
by Rémi Bernon (＠rbernon) 12 Sep '25

12 Sep '25

This manifested with https://gitlab.winehq.org/wine/wine/-/merge_requests/8875, as it adds fd_cache_mutex lock on thread init to receive the new inproc sync file descriptors. The kernel32:sync test creates a thread then immediately terminates it, which causes wineserver to close its pipe while it is initializing, triggering a SIGPIPE that is receive while the thread is within the server_init_thread call and request. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8878

4 14

[PATCH 0/1] MR8800: mfreadwrite/tests: Fix test failures with Windows 7.
by Bernhard Übelacker (＠bernhardu) 12 Sep '25

12 Sep '25

[Test pattern page](https://test.winehq.org/data/patterns.html#mfreadwrite:mfplat) [Testbot run with this patch](https://testbot.winehq.org/JobDetails.pl?Key=159453) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8800

3 3

[PATCH 0/1] MR8964: winebuild: Use .rdata section instead of .rodata on PE targets.
by Jacek Caban (＠jacek) 12 Sep '25

12 Sep '25

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

2 1

[PATCH v5 0/3] MR8951: windows.media.playback.mediaplayer: Implement IMediaPlayer2::get_SystemMediaTransportControls().
by Mohamad Al-Jaf (＠maljaf) 12 Sep '25

12 Sep '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58631 -- v5: windows.media.playback.mediaplayer: Implement IMediaPlayer2::get_SystemMediaTransportControls(). windows.media.playback.mediaplayer: Add IMediaPlayer2 stub. include: Add IMediaPlayer2 definition. https://gitlab.winehq.org/wine/wine/-/merge_requests/8951

3 5

[PATCH 0/4] MR8963: ntdll: Add helpers to send / receive fds with a request.
by Rémi Bernon (＠rbernon) 12 Sep '25

12 Sep '25

This will be useful if not necessary at some point for shared resources, to send / receive fds with the D3DKMT requests. There's maybe an option to use `wine_server_fd_to_handle` / `wine_server_handle_to_fd` instead, but that would require creating file objects for every resource on the server side, and that seemed a bit unnecessary. Also, on the macOS side, we will likely want to extend these helper and the fd_type enum, to include and support sending / receiving mach_port_t fd types, as shared resources are backed by those on that platform. This probably doesn't fit too well with the otherwise unix file fds and the fd cache. It's maybe a bit awkward to squeeze the fd type bits into the request header but I didn't find a good other way and increasing its size breaks the size <= 64 assumption. It could be a pointer within the request struct passed to the helper call, but it seem a bit awkward from a usage point of view: hard to make it clear that it needs to be within the request struct. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8963

3 11

2025

2024

2023

2022

wine-gitlab