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

[PATCH 0/1] MR9301: winemac.drv: Explicitly track the shape layer used for letter/pillarboxes.
by Tim Clem (＠tclem) 28 Oct '25

28 Oct '25

The content view's layer can have internal sublayers from Cocoa, so assuming anything about the hierarchy is dangerous and can result in us removing backing layers for visible content. --- Fixes solid grey fullscreen windows in some games. It's not clear to me why the content view layer only sometimes has sublayers; it may be a macOS version difference or something, but either way we should not assume anything about what's going on in there. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9301

3 2

[PATCH 0/6] MR9300: vccorlib140: Platform::Exceptions stubs and tests.
by Piotr Caban (＠piotr) 28 Oct '25

28 Oct '25

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

2 8

[PATCH v2 0/1] MR7410: test-linux32: Disable broken tests that are already released broken
by Damien Zammit (＠zamaudio) 28 Oct '25

28 Oct '25

This should allow the CI to fully pass on this merge request. If it does, master branch could have CI tests enabled to ensure any actual broken test caused by a merge request is visible just by the CI status, and master can also reflect the passing status. Signed-off-by: Damien Zammit <damien(a)zamaudio.com> -- v2: test-linux32: Disable broken tests that are already released broken https://gitlab.winehq.org/wine/wine/-/merge_requests/7410

4 4

[PATCH 0/2] MR9299: ole32, combase: Add tests for COM context switching and delayed marshaling.
by Vibhav Pant (＠vibhavp) 28 Oct '25

28 Oct '25

When `RoGetAgileReference` is used with `AGILEREFERENCE_DELAYEDMARSHAL`, the returned `IAgileReference` also contains a reference to the apartment the object belongs to. Thus, when `IAgileReference::Resolve()` gets called, the object will get marshaled inside the owning apartment, not the caller's apartment. This seems to be made possible by the `IContextCallback` interface. It provides a way to (ab)use the marshaller to execute arbitrary code inside a COM context, which is an additional bit of state nested inside apartments. An apartment can contain multiple COM contexts, and the standard marshaller will keep track of which context a marshaled interface is bound to. All method calls through that marshalled pointer will be wrapped around a context-switch, even when the caller is in the same apartment. Additionally, creating an instance of the class `CLSID_IContextCallback` allows us to create new contexts inside an apartment. C++/WinRT makes use of `IContextCallback` to [implement support for C++ coroutines ](https://github.com/microsoft/cppwinrt/blob/ebace4abb8f48b6b9a612e8b84667e6044976a47/strings/base_coroutine_threadpool.h#L51)(co_await, et al) inside application STA code. Another use of COM contexts seems to be the UI code in WinRT applications, where certain objects can only be `Released`/destructed from the apartment they were created in. (I was able to find another instance of `IContextCallback` usage in the wild [here](https://github.com/Open-Shell/Open-Shell-Menu/blob/4ebeadd949d0550642…, to get an `IAccessible` implementation that has apartment-affinity). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9299

3 7

[PATCH 0/1] MR9298: ntdll: Remove unused parameter from linux_query_event_obj().
by Marc-Aurel Zent (＠mzent) 28 Oct '25

28 Oct '25

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

2 1

[PATCH 0/1] MR3228: Update heap.c removed return NULL at line 985. Prevents Wing Commander...
by James Carthew (＠dmjc) 28 Oct '25

28 Oct '25

Update heap.c removed return NULL at line 985. Prevents Wing Commander Prophecy and Secret Ops for loading/playing. Fixes WINE bug 55176. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3228

5 4

Re: [PATCH v8 0/5] MR9209: vccorlib140: Implement Platform::Exceptions.
by Piotr Caban (＠piotr) 28 Oct '25

28 Oct '25

I'm going to move some patches from this MR to a new one to make future reviews easier (this comment is mainly to make sure there's no work duplication). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9209#note_119861

1 0

[PATCH 0/4] MR9297: ntdll: Add wow64 support for IOCTL_SCSI_PASS_THROUGH_DIRECT.
by Akihiro Sagawa (＠sgwaki) 28 Oct '25

28 Oct '25

This is the second part intended to replace !8120. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58257 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9297

2 4

Re: [PATCH v8 0/5] MR9209: vccorlib140: Implement Platform::Exceptions.
by Piotr Caban (＠piotr) 28 Oct '25

28 Oct '25

Some of the recent fixes where added to wrong patches (first patch has base set incorrectly, it's fixed in second patch). Another problem is that there's something wrong with how the WinRT exceptions are handled/implemented. With code from this MR it's not possible to mix native and builtin ucrtbase and vccorlib140 (we're getting ACCESS_VIOLATION while using exception throwing functions). While it might be not critical I would like to understand what's going on. I'm planning to look into it more. I guess it might be some kind of side-effect of trying to make these exceptions working with older exception handlers. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9209#note_119856

1 0

[PATCH v3 0/6] MR9032: opengl32: Support wow64 buffer storage and persistent memory mapping using Vulkan.
by Jacek Caban (＠jacek) 28 Oct '25

28 Oct '25

I'm opening this MR as an RFC. It's an initial attempt to support OpenGL persistent memory mapping in the new wow64. The implementation is not complete yet (details below), but it's intentionally kept as simple as possible for a proof of concept. Since we can't control where OpenGL maps memory, the idea is to use the available Vulkan extension with enough glue between them. Because of how GL–VK interop works, this requires creating a memory object on the Vulkan side and importing it into OpenGL. Once that's done, all operations on such buffers are performed through GL, except for mapping, which is handled by Vulkan. This is achieved by hooking `gl*BufferStorage` and reimplementing it on top of `glImportMemoryFdEXT` for mappable buffers. Recently introduced buffer wrappers make further tracking of these buffers straightforward. If we move forward with this, the feature will need to be enabled based on available driver capabilities (for now, it's force-enabled). Some parts might also be worth moving into win32u. This alone seems enough to claim persistent memory support and thus expose OpenGL 4.6 on the new wow64. Performance looks good in my limited testing, although that hasn't been a focus yet. Possible improvements include: - Currently only GL buffers created with `gl*BufferStorage` are affected. Other cases still fall back to the slow memcpy path. - The draft just picks the first host-visible coherent memory type exposed by Vulkan. We could try harder to pick an optimal type taking into account GL flags. - The draft allocates a new Vulkan memory and fd for each mapped buffer. This is inefficient for small buffers, for which a suballocator could help. - The draft always picks the first GPU reported by Vulkan. We may need to ensure that the selected device matches the one OpenGL actually uses. An alternative would be a new OpenGL extension. A driver-level solution could be more efficient, and it would certainly be nice to have. However, since such an extension doesn't exist yet, and even if we have it soon, I think it's still valuable to have a fallback solution that works with existing drivers. -- v3: opengl32: Support wow64 buffer storage and persistent memory mapping using Vulkan. opengl32: Wrap buffer storage functions. opengl32: Use stored extensions in filter_extensions. opengl32: Use stored extension list in is_extension_supported. opengl32: Compute supported extensions in make_context_current. opengl32: Split extensions by null bytes in the registry. https://gitlab.winehq.org/wine/wine/-/merge_requests/9032

2 7