October 2025 - Wine-GitLab - list.winehq.org

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

Oct. 16, 2025

-- 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) Oct. 16, 2025

Oct. 16, 2025

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) Oct. 16, 2025

Oct. 16, 2025

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 Oct. 16, 2025

Oct. 16, 2025

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

1 2

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

Oct. 16, 2025

-- 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) Oct. 16, 2025

Oct. 16, 2025

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) Oct. 16, 2025

Oct. 16, 2025

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

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

Oct. 16, 2025

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

3 2

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

Oct. 16, 2025

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

2 7

[PATCH 0/3] MR9188: win32u: Use local handles in D3DKMT_ESCAPE_UPDATE_RESOURCE_WINE.
by Rémi Bernon Oct. 16, 2025

Oct. 16, 2025

And some misc fixes. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9188

1 3