- wine-gitlab - winehq.org

[PATCH 0/6] MR9191: comctl32/tests: Add CCM_SETVERSION tests.
by Zhiyi Zhang (＠zhiyi) 16 Oct '25

16 Oct '25

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

3 10

[PATCH 0/1] MR9184: sane.ds: Adding saving scanner settings to the registry
by Ivan Lyugaev (＠valy) 16 Oct '25

16 Oct '25

The latest scanner settings are now automatically saved in the HKEY_CURRENT_USER\Software\ScannersSettings\Vendor\Product path. This modification was tested and worked correctly This is the second MR on this topic, and the first MR has been approved for a month, but it has not been added without merge :disappointed: Link: https://gitlab.winehq.org/wine/wine/-/merge_requests/8858 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9184

3 4

[PATCH 0/1] MR8931: winex11.drv: Fixing an issue where the window size was not saved after...
by Ivan Lyugaev (＠valy) 16 Oct '25

16 Oct '25

winex11.drv: Fixing an issue where the window size was not saved after switching from full-screen mode When switching from maximized window to windowed mode, the window retains the size of the entire screen. This bug is reproducible in xfce. Upon closer examination of the logs, I noticed that xfce was duplicating ConfigureNotify requests. The duplicate requests had the send_event=TRUE flag. These requests caused the window to resize incorrectly. The current implementation of wine uses the asynchronous ConfigureNotify event notification method - NtUserPosteMessage with the WM_WINE_WINDOW_STATE_CHANGED flag. I suggest returning to the synchronous method using Send_message. This bug is a regression. This issue first appeared in commit 0f1d999b, which moved the handling of GetWindowStateUpdates in win32u/message.c to the handle_internal_message function via NtUserPostMessage. I decided to revert the handling logic to before this patch was applied, adapting it to the current handling of GetWindowStateUpdates in win32u/message.c This solution was tested in xfce, mate, and a number of different programs. Everything worked correctly -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8931

3 8

[PATCH 0/1] MR9192: activeds: Remove misleading comments.
by Dmitry Timoshkov (＠dmitry) 16 Oct '25

16 Oct '25

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

2 1

[PATCH v2 0/1] MR9186: uxtheme: Add stub for GetThemeBitmap.
by Louis Lenders (＠xe) 16 Oct '25

16 Oct '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58747 -- v2: uxtheme: Add stub for GetThemeBitmap. https://gitlab.winehq.org/wine/wine/-/merge_requests/9186

3 2

[PATCH v2 0/1] MR9126: ntdll: On macOS, use separate mmap() and mprotect() calls when mapping files with PROT_EXEC.
by Brendan Shanks (＠bshanks) 16 Oct '25

16 Oct '25

Starting with macOS 10.15, `mmap()` for a file with `PROT_EXEC` fails with `EPERM`. But for some reason, doing separate `mmap()` and then `mprotect()` calls works. This fixes `NtUserRegisterClassExWOW: Failed to get shared session object for window class` errors seen when running a 32-bit EXE lacking the NX compat bit. The shared memory object being used for window classes was being mapped executable, this was failing because of the above, and then `map_file_into_view()` was falling back to `pread()` which doesn't make sense for a shared memory region. (It seems like a bug to use `pread()` in this scenario rather than return an error, although I'm not sure how that could be detected). I don't love the preprocessor black-magic to replace every mmap() call, but it avoids having to modify any other functions. If we want to avoid that, `map_pe_header()` and `map_file_into_view()` are the `mmap()` calls that I know need to be changed. CrossOver has used an almost-identical hack for years. -- v2: ntdll: On macOS, use separate mmap() and mprotect() calls when mapping files with PROT_EXEC. https://gitlab.winehq.org/wine/wine/-/merge_requests/9126

4 5

[PATCH 0/2] MR9190: win32u: Add stub and basic tests for D3DKMT keyed mutexes.
by Rémi Bernon (＠rbernon) 16 Oct '25

16 Oct '25

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

2 2

[PATCH v2 0/7] MR9189: mmdevapi/tests: Add a lot of capturing tests.
by Giovanni Mascellani (＠giomasce) 16 Oct '25

16 Oct '25

-- v2: mmdevapi/tests: Test extensible wave formats when capturing. https://gitlab.winehq.org/wine/wine/-/merge_requests/9189

2 7

[PATCH v2 0/2] MR9178: ntdll: Use ReadPointerAcquire to get pointer value in RtlRunOnceBeginInitialize
by Luca Bacci (＠lb90) 16 Oct '25

16 Oct '25

The `RtlRunOnce` family of functions are implemented using (a variant of) the Double Checked Locking Pattern (DCLP). The DCLP requires memory fences for correctness, on both the writer and reader sides. It's pretty obvious why it's needed on the writer side, but quite surprising that any is needed on the reader side! On strong memory model architectures (x86 and x86_64), only compiler-level fences are required. On weak memory model architectures like ARM64, instead, you need both CPU and compiler fences. That's explained well in books like _Concurrent Programming on Windows_ by Joe Duffy and in online resources like [1]. The Wine implementation has fences on the writing side (`RtlRunOnceComplete`). That's because `InterlockedCompareExchangePointer` inserts a full memory fence. However some code paths on the reader side (`RtlRunOnceBeginInitialize`) are missing fences, specifically the (`RTL_RUN_ONCE_CHECK_ONLY`) branch and the (`!RTL_RUN_ONCE_CHECK_ONLY && (val & 3) == 2`) branch. ~~Add the missing fences using GCC's atomic builtins [2]~~ **EDIT:** using `ReadPointerAcquire` now Note: with this MR, the generated code should change only for ARM64 ### References: 1. [Double-Checked Locking is Fixed In C++11](https://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp… 2. [GCC's Built-in Functions for Memory Model Aware Atomic Operations](https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.ht… -- v2: ntdll: Use ReadPointerAcquire to get pointer value in RtlRunOnceBeginInitialize include: add atomic read/write of pointers https://gitlab.winehq.org/wine/wine/-/merge_requests/9178

4 4

[PATCH v3 0/4] MR9155: d3dx10: Handle all D3DX10_IMAGE_LOAD_INFO fields.
by Connor McAdams (＠cmcadams) 16 Oct '25

16 Oct '25

This finishes up the handling of `D3DX10_IMAGE_LOAD_INFO` fields. :) The default filter values were confirmed using a test locally that I've pushed to a branch here: https://gitlab.winehq.org/cmcadams/wine/-/commits/d3dx10-filter-test -- v3: d3dx10: Pass D3DX10_IMAGE_LOAD_INFO texture creation arguments through in load_texture_data(). d3dx10: Handle FirstMipLevel argument in load_texture_data(). d3dx10: Add support for generating mipmaps to load_texture_data(). https://gitlab.winehq.org/wine/wine/-/merge_requests/9155

3 5

2025

2024

2023

2022

wine-gitlab