- Wine-GitLab - list.winehq.org

[PATCH v6 0/5] MR8862: mmdevapi/tests: Rewrite capturing tests, part 1/4.
by Giovanni Mascellani (＠giomasce) Sept. 15, 2025

Sept. 15, 2025

I began working on this to address some flakyness (see e.g. https://gitlab.winehq.org/wine/wine/-/jobs/183916) and eventually I ended up rewriting `test_capture()` because the previous implementation looked somewhat incomplete. -- v6: mmdevapi/tests: Check that the received packet isn't larger than the padding. mmdevapi/tests: Check that GetBuffer() returns a packet of the expected size. mmdevapi/tests: Check that GetBuffer() fails when no packet is available. mmdevapi/tests: Introduce a helper to read many packets when capturing. https://gitlab.winehq.org/wine/wine/-/merge_requests/8862

3 7

Re: [PATCH v5 0/4] MR8941: nsi: Explicitly add loopback entries to ipv4 forward table on Linux. - approved
by Huw Davies (＠huw) Sept. 15, 2025

Sept. 15, 2025

This merge request was approved by Huw Davies. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8941

1 0

[PATCH v11 0/5] MR8890: windows.devices.enumeration: Add support for parsing AQS filter strings.
by Vibhav Pant (＠vibhavp) Sept. 14, 2025

Sept. 14, 2025

-- v11: maintainers: Add a section for Windows.Devices.Enumeration. windows.devices.enumeration: Support parsing AQS filters in IDeviceInformationStatics::{FindAllAsyncAqsFilter, CreateWatcherAqsFilter}. windows.devices.enumeration/tests: Add tests for IDeviceInformationStatics::{FindAllAsyncAqsFilter, CreateWatcherAqsFilter}. https://gitlab.winehq.org/wine/wine/-/merge_requests/8890

2 5

[PATCH 0/3] MR8967: user32: Refresh MDI menus when DefMDIChildProc(WM_SETTEXT) is called.
by Elizabeth Figura (＠zfigura) Sept. 14, 2025

Sept. 14, 2025

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

3 4

[PATCH 0/1] MR8970: kernel32/kernelbase: Implemented NUMA functions and improved affinity support
by Danny Waser (＠wasertech) Sept. 14, 2025

Sept. 14, 2025

This merge request implements several NUMA functions previously stubbed in kernel32 and kernelbase, adds a basic NUMA node discovery/topology layer, and enriches the associated tests. It also improves the traceability of SetThreadGroupAffinity. ## Context / Motivation Some Windows applications (game engines, middleware, runtimes) query the NUMA API to adapt memory allocation or thread distribution. The lack of an implementation returned errors (ERROR_CALL_NOT_IMPLEMENTED) or unhelpful values, which could degrade the internal heuristics of these programs. This first implementation provides: - A logical topology derived from GetLogicalProcessorInformation. - A reasonable approximation of available memory per node. - Consistent processor masks for the present nodes. It prepares for future optimizations (targeted memory allocation, better scheduling strategies) without modifying the existing behavior of generic allocations. ## Main Changes - `kernel32/process.c`: - Implementation of GetNumaNodeProcessorMask, GetNumaAvailableMemoryNode / Ex, GetNumaProcessorNode / Ex, GetNumaProximityNode. - Parameter validation and consistent error propagation (ERROR_INVALID_PARAMETER). - `kernelbase/memory.c`: - New NUMA infrastructure (topology cache, lazy initialization, dedicated critical lock). - Topology reading via GetLogicalProcessorInformation. - Runtime options via environment variables: - WINE_NUMA_FORCE_SINGLE: Force a single logical node. - WINE_NUMA_CONTIG: Remap masks to produce contiguous blocks. - Implementations of GetNumaHighestNodeNumber, GetNumaNodeProcessorMaskEx, GetNumaProximityNodeEx. - Robust fallback: if no NUMA info → single node. - `kernelbase/thread.c`: - Added detailed traces in SetThreadGroupAffinity (removed the redundant DECLSPEC_HOTPATCH here). - Tests (`dlls/kernel32/tests/process.c`): - Added a new test, test_NumaBasic, covering: - GetNumaHighestNodeNumber - GetNumaNodeProcessorMaskEx (nodes 0 and 1) - GetNumaProximityNodeEx - Tolerant behavior: accepts `ERROR_INVALID_FUNCTION` / `ERROR_INVALID_PARAMETER` depending on the platform. - Added the `WINE_DEFAULT_DEBUG_CHANNEL(numa)` debug channel for the subsystem. ## Assumptions / Limitations - Support for a single processor group (Group = 0) for now. - Memory approximation: equal division of available physical memory (improvable later with internal counters per node). - Proximity = node (simplistic direct mapping). - No impact yet on VirtualAlloc / Heap allocation by node. ## Security / Concurrency - Initialization protected by dedicated critical section (numa_cs). - Thread-safe lazy read. - Table bounded to 64 nodes (historical Windows limit). ## Compatibility Impact - Improves compatibility with software probing the NUMA API. - Low risk of regression: previously failed paths now return TRUE with consistent data. - In case of topology collection failure → single-node fallback (conservative behavior). ## Validation / Tests - New test_NumaBasic added and integrated into the process suite. - Traces (numa channel) allow for detection diagnostics. - Invalid parameters tested (NULL, nodes out of range). - Works in environments without real NUMA via fallback. ## Environment Variables (quick documentation) - WINE_NUMA_FORCE_SINGLE=1: Forces a single node (mask covering all CPUs). - WINE_NUMA_CONTIG=1: Reallocates compact bit blocks per node (useful if the topology returns sparse masks). ## Potential Next Steps (not included) - Implement true memory tracking per node (via allocation hooks). - Multi-group support (PROCESSOR_GROUP_INFO). - Improved VirtualAllocExNuma / First-touch implementation. - More accurate proximity-to-node mapping on complex NUMA platforms. - Dedicated tests for environment variables. ## Potential Risks / Regressions - Applications relying on the absence of an API may slightly change their strategy (low). - Masks remapped with WINE_NUMA_CONTIG could surprise a profiling tool (opt-in option). - Memory approximation too coarse for very fine-grained heuristics (no functional regression expected). ## Request for Review - Verify logging conventions and TRACE_(numa) usage. - Verify the relevance of removing DECLSPEC_HOTPATCH on SetThreadGroupAffinity (alignment with local conventions). - Opinion on error granularity (ERROR_INVALID_PARAMETER vs. ERROR_INVALID_FUNCTION) for more accurate mimicry. Once the kernel can handle those functions directly (in a NUMA module i.e.) we could use this implementation as a fallback when the kernel doesn't support NUMA natively (when the module cannot be loaded). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8970

2 2

[PATCH 0/1] MR8971: make_unicode: Add some halfwidth mapping exceptions.
by Bernhard Kölbl Sept. 14, 2025

Sept. 14, 2025

Signed-off-by: Bernhard Kölbl <bkoelbl(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8971

1 1

[PATCH v5 0/3] MR8920: cmd: Fix some TYPE command behavior (one more try).
by Joe Souza (＠JoeS209) Sept. 14, 2025

Sept. 14, 2025

Giving this one final shot. If this is not deemed acceptable, I will abandon the effort and just move on to other things, no hard feelings. This is IMO a cleaner, more conservative/less invasive change. What is fixed: - Bug #56381, "TYPE c:\windows\winhelp.exe >foo", i.e. binary mode operation. I would probably consider this the main reason for this change. I'm trying to get the compiler mentioned in the bug report working. - Ctrl-Z termination of TYPE output to the console. - "TYPE con >foo", with Ctrl-Z handling, functionally equivalent to "COPY con foo". Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56381 -- v5: cmd: Fix TYPE behavior (now uses WCMD_copy_loop). cmd: Refactor WCMD_copy_loop out of WCMD_ManualCopy, and stop copy loop at EOF for /a mode. cmd/tests: Add test to check for TYPE truncation in binary mode. https://gitlab.winehq.org/wine/wine/-/merge_requests/8920

3 5

[PATCH 0/4] MR8969: opengl32, win32u: Fix 16-bit PFD_DRAW_TO_BITMAP rendering.
by Zowie van Dillen (＠zowie) Sept. 14, 2025

Sept. 14, 2025

This MR fixes 16-bit PFD_DRAW_TO_BITMAP rendering, as tested with SimGolf and Civilization 3. The fix isn't super performant since it involves a lot of back-and-forth between CPU and GPU, which is mostly noticeable when moving staff around in SimGolf — it slows to around two or three fps —, but on the plus side it does work, which is a straight upgrade over the current version of Wine. Couple of notes: * The third commit touches several different subsystems because I had to add a constant that's visible from both opengl32 and win32u. I wasn't sure how to write this down in the commit message. * There's a bug in LLVMpipe where a 32-bit pbuffer will cause it to crash. I opened an issue for it here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13890. I needed a 32-bit pbuffer to make this work, so I added a special check that effectively disables 16-bit bitmap rendering for LLVMpipe. * I also had to use a workaround to make blitting & OpenGL rendering work together. I wrote about it pretty extensively below. ## Combining blitting & OpenGL rendering Something that's difficult about bitmap rendering is that it allows programs to combine OpenGL drawing with direct blitting onto bitmap memory. That's difficult to imitate with the pbuffer-based implementation because there's no way to replicate memory edits on the bitmap to the GPU-based pbuffer (since there's no API calls involved in the memory edit). This had to work to make the games actually work, so I used this workaround: Each time after overwriting the bitmap from the pbuffer, we clear the pbuffer with transparent. Also instead of "overwriting" the bitmap, we instead blend the pbuffer's pixels onto the bitmap. That way we're effectively overlaying the most recent OpenGL drawings on top of the bitmap. I'm pretty confident that that approach would also help with 32-bit and 24-bit bitmap rendering, but I don't know of any programs that use 32-bit or 24-bit bitmap rendering, so I wasn't able to check. I've just left 32-bit and 24-bit bitmaps as they were. While the workaround works really well for the games, I did have to edit another test because it used glReadPixels on 16-bit bitmaps. glReadPixels will grab pixels from the transparent-background pbuffer instead of the bitmap, which gives the wrong result. I'm not under the impression that any consumer programs use bitmap rendering together with glReadPixels (it doesn't make as much sense when you could just directly read the pixels from the bitmap), but it's possible to add a wrap_glReadPixels that grabs pixels from the bitmap in case of a 16-bit memory DC. It's not important to read but I wanted to write it down for the record: I also tried another workaround to make combining blitting & OpenGL work. The thought was to overwrite the pbuffer with the bitmap just before OpenGL draws to the pbuffer, to keep them in sync. It probably would have worked out if it was possible to add something to the front of the OpenGL command buffer in a glFinish/glFlush call — then I could have inserted glDrawPixels in the front, before all of the program's rendering operations —, but it's only possible to add things to the end of the command buffer unfortunately. I tried adding a wrapper to glBegin and glClear, which checks if they were the first render operation after a glFlush or glFinish. Unfortunately that didn't work at all. I'm guessing that Civ 3 and SimGolf still do direct bitmap edits after the first call to glBegin, so by the time the program gets to glFinish/glFlush the pixels that were uploaded in the glDrawPixels command are already stale (although I didn't really check). Anyhow, that approach was pretty fruitless. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8969

2 4

[PATCH 0/2] MR8968: setupapi: Parse a 0x prefix in SetupGetBinaryField().
by Elizabeth Figura (＠zfigura) Sept. 13, 2025

Sept. 13, 2025

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

2 2

[PATCH v10 0/5] MR8890: windows.devices.enumeration: Add support for parsing AQS filter strings.
by Vibhav Pant (＠vibhavp) Sept. 13, 2025

Sept. 13, 2025

-- v10: maintainers: Add a section for Windows.Devices.Enumeration. windows.devices.enumeration: Support parsing AQS filters in IDeviceInformationStatics::FindAllAsyncAqsFilter. https://gitlab.winehq.org/wine/wine/-/merge_requests/8890

2 5

[PATCH 0/8] MR8966: d3dx: Miscellaneous fixes.
by Connor McAdams (＠cmcadams) Sept. 12, 2025

Sept. 12, 2025

Add support for D3DFMT_CxV8U8, which is required for the game Biorage. Also add support for loading DDS files with header flag values of `DDS_PF_FOURCC` alongside other flag values. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8966

2 10

Re: [PATCH v3 0/1] MR8915: d3dx10_33/tests: Enable tests. - approved
by Alexandre Julliard (＠julliard) Sept. 12, 2025

Sept. 12, 2025

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

1 0

Re: [PATCH v2 0/1] MR8950: winetest: Print Windows revision (UBR). - approved
by Alexandre Julliard (＠julliard) Sept. 12, 2025

Sept. 12, 2025

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

1 0

Re: [PATCH v3 0/1] MR8962: dbghelp: Fix pointer truncation issues when parsing 64-bit Mach-O binaries in a Wow64 process - approved
by Alexandre Julliard (＠julliard) Sept. 12, 2025

Sept. 12, 2025

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

1 0

Re: [PATCH v3 0/1] MR8949: dxcore: Avoid races with the global adapter factory - approved
by Alexandre Julliard (＠julliard) Sept. 12, 2025

Sept. 12, 2025

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

1 0

Re: [PATCH v3 0/4] MR8958: win32u: Fixes for the OpenGL drawables mess. - approved
by Alexandre Julliard (＠julliard) Sept. 12, 2025

Sept. 12, 2025

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

1 0

Re: [PATCH v2 0/1] MR8956: nls: Update character tables to Unicode 17.0.0. - approved
by Alexandre Julliard (＠julliard) Sept. 12, 2025

Sept. 12, 2025

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

1 0

Re: [PATCH v6 0/3] MR8951: windows.media.playback.mediaplayer: Implement IMediaPlayer2::get_SystemMediaTransportControls(). - approved
by Alexandre Julliard (＠julliard) Sept. 12, 2025

Sept. 12, 2025

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

1 0

[PATCH 0/4] MR8688: server: Start to expose Unix symlinks as NT reparse points.
by Elizabeth Figura (＠zfigura) Sept. 12, 2025

Sept. 12, 2025

A Wine user has requested the ability to interact with Unix symlinks from Win32 code. While the generic functionality of NT reparse points is still not implemented upstream, it will probably involve a completely different code path than this, so there does not seem to me to be any point in waiting for that to be done before submitting these patches. This does not implement all the relevant functionality. FILE_OPEN_REPARSE_POINT is now respected, but returns an fd with no fd->unix_fd. Thus far only file disposition (i.e. deletion), renaming and hardlinking are implemented, and all other operations return the no_fd_status, for which STATUS_REPARSE_POINT_NOT_RESOLVED is arbitrarily chosen. This is probably going to be controversial. As controversial patches tend to get deferred forever, I'm going to at least try to pose some questions related to concept and implementation which may be easier to answer. * Do we want to expose Unix symlinks at all? This was requested by a Wine user, and it does seem a strong argument that Wine, in general, supports some measure of integration with the host, including exposing custom interfaces for programs written to take advantage of it. We also, currently, already expose Unix *directory* symlinks via NtQueryAttributesFile(). We don't currently expose such file symlinks (and this series does not change that particular point, but it would be done by follow-up patches). In a sense we are expanding existing partial support. On the other hand, Unix symlinks which are completely opaque can be useful, and some downstream distributions (CrossOver and Proton) currently rely on them to reduce disk space usage while keeping the application unaware of a symlink (even if it were to use FILE_OPEN_REPARSE_POINT. Not that any applications are currently known that would break if this were to change, and in any case they could simply revert these patches.) * Implementation-wise, is having unix_fd == -1 a non-starter? This can be true of other real fds in some specific cases... * It's also true that this current implementation suffers from some degree of TOCTOU problems: because we only store the name and not the FD anymore, the actual underlying object at that path can change. This would not be true on Windows. Is this a problem? * One alternate approach would be to use O_PATH (Linux, FreeBSD) and O_SYMLINK (Mac). I don't see any equivalent flag for NetBSD or Solaris, so we would probably just not be able to expose this functionality there. Note that while the documentation seems to imply that O_PATH only stores the path, manual testing shows that (at least on Linux) a fd opened with O_PATH will remain pointing at the same *inode* even if it is moved or deleted. So this would avoid the aforementioned TOCTOU problem. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8688

5 11

[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) Sept. 12, 2025

Sept. 12, 2025

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/4] MR8869: Draft: server: Post a WINE_WM_PRESENT for window surface present.
by Rémi Bernon Sept. 12, 2025

Sept. 12, 2025

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

1 8

[PATCH 0/8] MR8965: Draft: win32u: Flush window surfaces from owner thread, while waiting for messages.
by Rémi Bernon Sept. 12, 2025

Sept. 12, 2025

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

1 8

[PATCH 0/6] MR8878: ntdll: Avoid deadlock on SIGPIPE while holding virtual_mutex or fd_cache_mutex.
by Rémi Bernon Sept. 12, 2025

Sept. 12, 2025

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

3 14

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

Sept. 12, 2025

-- 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) Sept. 12, 2025

Sept. 12, 2025

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