November 2025 - Wine-gitlab

[PATCH 0/2] MR9384: vccorlib: Implement {Get, Weak}ResolveWeakReference.
by Vibhav Pant (＠vibhavp) 06 Nov '25

06 Nov '25

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

2 2

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

06 Nov '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

5 11

[PATCH v3 0/3] MR9383: appbar: SHAppBarMessage: silence warnings about unknown message types
by Matthias Schwarzott (＠zzam) 06 Nov '25

06 Nov '25

rate-limit these warnings: 0078:fixme:appbar:handle_appbarmessage SHAppBarMessage(ABM_GETSTATE): stub 0078:fixme:appbar:handle_appbarmessage SHAppBarMessage(ABM_GETTASKBARPOS, hwnd=...): stub silence these warnings: 0024:fixme:appbar:SHAppBarMessage unknown msg: 4 0024:fixme:appbar:SHAppBarMessage unknown msg: 1 -- v3: appbar: Limit the number of FIXME lines appbar: SHAppBarMessage: silence warnings about unknown message types appbar: Add test for ABM_GETSTATE https://gitlab.winehq.org/wine/wine/-/merge_requests/9383

2 3

[PATCH v2 0/3] MR9383: appbar: SHAppBarMessage: silence warnings about unknown message types
by Matthias Schwarzott (＠zzam) 06 Nov '25

06 Nov '25

rate-limit these warnings: 0078:fixme:appbar:handle_appbarmessage SHAppBarMessage(ABM_GETSTATE): stub 0078:fixme:appbar:handle_appbarmessage SHAppBarMessage(ABM_GETTASKBARPOS, hwnd=...): stub silence these warnings: 0024:fixme:appbar:SHAppBarMessage unknown msg: 4 0024:fixme:appbar:SHAppBarMessage unknown msg: 1 -- v2: appbar: Limit the number of FIXME lines appbar: SHAppBarMessage: silence warnings about unknown message types appbar: Add test for ABM_GETSTATE https://gitlab.winehq.org/wine/wine/-/merge_requests/9383

2 3

[PATCH 0/3] MR9383: appbar: SHAppBarMessage: silence warnings about unknown message types
by Matthias Schwarzott (＠zzam) 06 Nov '25

06 Nov '25

rate-limit these warnings: 0078:fixme:appbar:handle_appbarmessage SHAppBarMessage(ABM_GETSTATE): stub 0078:fixme:appbar:handle_appbarmessage SHAppBarMessage(ABM_GETTASKBARPOS, hwnd=...): stub silence these warnings: 0024:fixme:appbar:SHAppBarMessage unknown msg: 4 0024:fixme:appbar:SHAppBarMessage unknown msg: 1 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9383

2 3

Re: [PATCH v5 0/3] MR8834: server: Use process_vm_writev / process_vm_readv instead of ptrace when available.
by Rémi Bernon 06 Nov '25

06 Nov '25

CC @mzent -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8834#note_121000

1 0

[PATCH 0/4] MR9382: win32u: Keep internal pixel format and surfaces on the DCs.
by Rémi Bernon 06 Nov '25

06 Nov '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58846 Wine D3D resets the window pixel format to its original value when an internal pixel format was requested and the context done being used, and requests the internal pixel format again before it is used again. When internal pixel format and window pixel format don't match this causes any previously created OpenGL surface with a different format to be released (and destroyed as no context is current with it), creating a new one with the new format, back and forth. What we actually need here, is to keep the Wine D3D OpenGL client surface, with the internal pixel format, alive as long as it is being referenced by wined3d, as well as any OpenGL client surface that may have been created, with the window pixel format, by the application itself. It's not possible to rely on DCs for application-created OpenGL surfaces, as the application is free to release its DC and retrieve another one later on for the same window while still expecting it to use the same OpenGL surface. However with wined3d, we know that the DCs are being kept referenced until the context is being destroyed so we can safely use them to store the wined3d OpenGL surface. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9382

1 4

[PATCH v10 0/5] MR9112: XCOPY and COPY should not attempt to copy a file to itself.
by Joe Souza (＠JoeS209) 06 Nov '25

06 Nov '25

Current code attempts to copy a file to itself. File is not actually copied; instead, a file sharing error is received. This result is ugly and differs from native. Behavior now appears to be the same as native with changes in this MR . -- v10: xcopy: Don't attempt to copy a file to itself. https://gitlab.winehq.org/wine/wine/-/merge_requests/9112

3 10

[PATCH 0/2] MR9381: win32u: Don't strip semaphore / fence export info.
by Rémi Bernon 06 Nov '25

06 Nov '25

We now actually use it with host export types. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9381

1 2

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

06 Nov '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). -- v4: ole32/tests: Add tests for IContextCallback::ContextCallback and CoDisconnectContext. combase/tests: Add tests for delayed marshaling of objects with apartment affinity. https://gitlab.winehq.org/wine/wine/-/merge_requests/9299

2 2