November 2025 - Wine-GitLab

[PATCH 0/3] MR9383: appbar: SHAppBarMessage: silence warnings about unknown message types
by Matthias Schwarzott (＠zzam) Nov. 6, 2025

Nov. 6, 2025

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 Nov. 6, 2025

Nov. 6, 2025

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 Nov. 6, 2025

Nov. 6, 2025

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) Nov. 6, 2025

Nov. 6, 2025

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 Nov. 6, 2025

Nov. 6, 2025

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) Nov. 6, 2025

Nov. 6, 2025

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

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

Nov. 6, 2025

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). -- v3: 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

[PATCH 0/1] MR9380: ole32: Add support for writing VT_R8 property.
by JiangYi Chen (＠meshine) Nov. 6, 2025

Nov. 6, 2025

As shown in the figure below: CAD software needs to read and write VT_R8 properties. ![截图_选择区域_20251106134015](/uploads/ac217f9974abf513b1f3d7a0624d9e69/截图_选择区域_20251106134015.png) Consistent with the reading of VT_R8 property in the propertystorage_read_scalar function, data of double type are not subjected to big-endian or little-endian conversion. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9380

2 1

[PATCH v2 0/3] MR9373: dmusic,dmsynth: Reduce memory usage part 2
by Anton Baskanov (＠baskanov) Nov. 6, 2025

Nov. 6, 2025

-- v2: dmsynth: Remove format and sample_count from struct wave. dmsynth: Allow zero-copy access to the sample data. dmusic: Defer releasing IDirectMusicDownload when can_free is FALSE. https://gitlab.winehq.org/wine/wine/-/merge_requests/9373

2 5

Re: [PATCH v5 0/1] MR8988: win32u: change the stretch mode of dst hdc from BlackOnWhite to ColorOnColor...
by Kun Yang (＠yangkun) Nov. 6, 2025

Nov. 6, 2025

@huw Please approve this merge request -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8988#note_120980

1 0