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

[PATCH 0/3] MR8839: ntdll, kernelbase: Fixes for creating Unix processes via CreateProcess/NtCreateUserProcess
by Tim Clem (＠tclem) Aug. 26, 2025

Aug. 26, 2025

An application was spawning a Unix process with CreateProcess (which returned success only when the stack was favorable; see the first patch) and then closing the handles from the PROCESS_INFORMATION, which were garbage. That obviously caused havoc elsewhere if those garbage values happened to be valid handles. It's not quite clear to me what the "right" thing to do is when a Unix process is created this way, since it's kind of a hack. But we already zero out the PS_CREATE_INFO in NtCreateUserProcess, so zeroing the handles seems in keeping with that. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8839

2 3

Re: [PATCH v17 0/1] MR8778: sane.ds: Adding a window for loading and saving the scanner configuration
by Esme Povirk (＠madewokherd) Aug. 26, 2025

Aug. 26, 2025

On Tue Aug 26 09:09:44 2025 +0000, Ivan Lyugaev wrote: > Will my MR be considered further? I think using the registry would make this significantly cleaner, enough that I don't plan to review it further while it uses files. I'd consider multiple configurations an advanced feature, and that's still possible for the UI to provide based on the registry. Transferring configurations across different machines is going to be even less common. I don't think the improvement in discoverability for that use case is worth it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8778#note_113915

1 0

Re: [PATCH v30 0/1] MR8573: cmd: tab completion: Treat most delimiters as literals if user specified quotes.
by Joe Souza (＠JoeS209) Aug. 26, 2025

Aug. 26, 2025

On Tue Aug 26 16:38:49 2025 +0000, Alexandre Julliard wrote: > You should stop updating your MR every day. Not only is it a waste of CI > resources, but it makes it look like it's not ready since it keeps being updated. > Also you don't need additional forks, you can create a MR from a > different branch in the same fork. My apologies about the daily updating. This was a misunderstanding on my part, since the UI here states that checks have failed and that the MR is not ready for merging after the main project has taken commits. Due to that warning here, I had thought that it was necessary to keep this fork updated with main, until it has been merged with main. Since what you say here tells me that I was wrong about this, I will stop updating my fork. Thank you. This MR is ready. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8573#note_113910

1 0

[PATCH v9 0/6] MR8831: vccorlib140: Implement support for boxed values (aka IPropertyValue)
by Vibhav Pant (＠vibhavp) Aug. 26, 2025

Aug. 26, 2025

C++/CX exposes `IPropertyValue` through `Platform::Details::CreateValue`, which returns a `Platform::Object` (which just seems to be a `IPropertyValue` object + C++ RTTI) containing the boxed value. Apps don't seem to call `CreateValue` directly with a typecode. The code for boxing values gets generated when a value type gets assigned to a `Platform::Object` variable, as documented [here.](https://learn.microsoft.com/en-us/cpp/extensions/boxing-cpp-componen… The generated code will: 1. Call `__abi_make_type_id` with a `struct __abi_type_descriptor *` value, which is just a typecode + string pair. This returns a `Platform::Type` object. 2. Call `Platform::Type::GetTypeCode` on the returned `Platform::Type` object to get back the typecode. 3. Call `Platform::Details::CreateValue` with the typecode and a pointer to the actual value that needs to be boxed. Apart from the usual WinRT methods, `Platform::Type` obejcts also impement the `IEquatable` and `IPrintable` interfaces. I don't know what their vtables look like, though. The `Platform::Type` and `Platform::Object` classes also have associated RTTI (can be demonstrated by calling `__RTtypeid`), which we'll also need to emit at some point in the future. -- v9: vccorlib140: Use the correct symbol name for InitControlBlock on i386 and arm. vccorlib140: Implement Platform::Details::CreateValue. vccorlib140: Add stub for Platform::Details::CreateValue. vccorlib140: Implement Platform::Type::{Equals, GetTypeCode, ToString, FullName::get}. vccorlib140: Implement __abi_make_type_id. https://gitlab.winehq.org/wine/wine/-/merge_requests/8831

3 7

[PATCH v8 0/6] MR8831: vccorlib140: Implement support for boxed values (aka IPropertyValue)
by Vibhav Pant (＠vibhavp) Aug. 26, 2025

Aug. 26, 2025

C++/CX exposes `IPropertyValue` through `Platform::Details::CreateValue`, which returns a `Platform::Object` (which just seems to be a `IPropertyValue` object + C++ RTTI) containing the boxed value. Apps don't seem to call `CreateValue` directly with a typecode. The code for boxing values gets generated when a value type gets assigned to a `Platform::Object` variable, as documented [here.](https://learn.microsoft.com/en-us/cpp/extensions/boxing-cpp-componen… The generated code will: 1. Call `__abi_make_type_id` with a `struct __abi_type_descriptor *` value, which is just a typecode + string pair. This returns a `Platform::Type` object. 2. Call `Platform::Type::GetTypeCode` on the returned `Platform::Type` object to get back the typecode. 3. Call `Platform::Details::CreateValue` with the typecode and a pointer to the actual value that needs to be boxed. Apart from the usual WinRT methods, `Platform::Type` obejcts also impement the `IEquatable` and `IPrintable` interfaces. I don't know what their vtables look like, though. The `Platform::Type` and `Platform::Object` classes also have associated RTTI (can be demonstrated by calling `__RTtypeid`), which we'll also need to emit at some point in the future. -- v8: vccorlib140: Use the correct symbol name for InitControlBlock on i386 and arm. vccorlib140: Implement Platform::Details::CreateValue. vccorlib140: Add stub for Platform::Details::CreateValue. vccorlib140: Implement Platform::Type::{Equals, GetTypeCode, ToString, FullName::get}. vccorlib140: Implement __abi_make_type_id. https://gitlab.winehq.org/wine/wine/-/merge_requests/8831

4 12

[PATCH 0/5] MR8685: wintypes: Implement IMap::{Lookup, HasKey, Insert} for IPropertySet.
by Vibhav Pant (＠vibhavp) Aug. 26, 2025

Aug. 26, 2025

`IMap` is implemented on top of a `rb_tree` guarded with an `SRWLOCK`. We need the map to be thread safe as: * `PropertySet` is marked as `IAgileObject`. * I plan to use `PropertySet` as the backing store for [`DeviceInformation::Properties`](https://learn.microsoft.com/en-us/uwp/api/windows.devices.enumeration.deviceinformation.properties?view=winrt-26100). These properties can be updated by apps after receiving an [`Updated`](https://learn.microsoft.com/en-us/uwp/api/windows.devices.enumeration.devicewatcher.updated?view=winrt-26100#windows-devices-enumeration-devicewatcher-updated) event from the device watcher with [`DeviceInformation::Update`](https://learn.microsoft.com/en-us/uwp/api/windows.devices.enumeration.deviceinformation.update?view=winrt-26100). The current `DeviceWatcher` implementation dispatches the event delegates for `Update` from a separate thread. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8685

5 15

[PATCH 0/7] MR8837: opcservices: Add basic support for reading OPC packages.
by Vibhav Pant (＠vibhavp) Aug. 26, 2025

Aug. 26, 2025

This MR introduces an initial implementation for `ReadPackageFromStream` in order to be able to decompress/read OPC packages, and enumerate their parts. This is for supporting AppX packages, which themselves are OPC packages as well. As such, the code does not implement support for reading relationships or interleaved archives, as AppX does not support either (`APPX_E_RELATIONSHIPS_NOT_ALLOWED`, `APPX_E_INTERLEAVING_NOT_ALLOWED`). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8837

3 9

[PATCH v5 0/1] MR8134: d3d10/tests: Compile more test effects from sources.
by Nikolay Sivov (＠nsivov) Aug. 26, 2025

Aug. 26, 2025

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v5: d3d10/tests: Compile more test effects from sources. https://gitlab.winehq.org/wine/wine/-/merge_requests/8134

3 8

[PATCH v2 0/2] MR8697: combase: Don't marshal objects marked as IAgileObject in RoGetAgileReference.
by Vibhav Pant (＠vibhavp) Aug. 26, 2025

Aug. 26, 2025

[Chromium obtains an agile reference](https://source.chromium.org/chromium/chromium/src/+/main:device/… to WinRT activation factories with RoAgileReference. As we currently do not support marshaling WinRT objects, this fails. However, as objects marked with IAgileObject don't need to be marshaled across apartments, we can trivially implement `RoAgileReference` for such objects, as most activation factories tend to be agile. -- v2: combase: Don't marshal objects that implement IAgileObject in RoGetAgileReference. https://gitlab.winehq.org/wine/wine/-/merge_requests/8697

2 4

Re: [PATCH v10 0/6] MR6569: winex11: Refactor window state/config tracker to fix race conditions.
by Stian Low (＠stianlow) Aug. 26, 2025

Aug. 26, 2025

Thanks for feedback. I'll take a closer look at how Carla experimental features work which allow the VST DLLs to be loaded directly. Maybe yabridge is taking unnecessary control of windowing that Wine may be able to handle internally instead. Carla's VST DLL handler may help clarify where exactly diff occurs. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_113875

1 0

[PATCH v2 0/8] MR8705: d3dx10: Exclusively use shared code to implement get_image_info().
by Connor McAdams (＠cmcadams) Aug. 26, 2025

Aug. 26, 2025

-- v2: d3dx10: Exclusively use shared code for parsing all files in get_image_info(). d3dx10: Add support for d3dx10+ image file formats in shared code. d3dx10: Exclusively use shared code for parsing DDS files in get_image_info(). d3dx10: Add support for DXGI formats in d3dx_helpers. d3dx10: Only validate header size for DDS files in d3dx10. d3dx10: Add support for parsing DXT10 DDS headers to shared code. d3dx10/tests: Add more DDS file header handling tests. d3dx10/tests: Add more DDS file DXGI format mapping tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/8705

3 9

Re: [PATCH v10 0/6] MR6569: winex11: Refactor window state/config tracker to fix race conditions.
by Rémi Bernon Aug. 26, 2025

Aug. 26, 2025

It's not really a matter of DLL format or conversion, in both cases the module is run the same way from Wine perspective. The difference is that when using yabridge, yabridge redirects the X11 window creation and takes the role of the window manager for Wine windows, embedding them inside its own windows that are in turn managed by the host WM. When running the modules directly, the host window manager does everything. The problems probably come from yabridge behavior as a proxy window manager, how it manage Wine windows positions and and how it translates coordinates back and forth. This is what was improved in the yabridge wine10 branch, but it's still not completely right apparently. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_113863

1 0

[PATCH v7 0/6] MR8831: vccorlib140: Implement support for boxed values (aka IPropertyValue)
by Vibhav Pant (＠vibhavp) Aug. 26, 2025

Aug. 26, 2025

C++/CX exposes `IPropertyValue` through `Platform::Details::CreateValue`, which returns a `Platform::Object` (which just seems to be a `IPropertyValue` object + C++ RTTI) containing the boxed value. Apps don't seem to call `CreateValue` directly with a typecode. The code for boxing values gets generated when a value type gets assigned to a `Platform::Object` variable, as documented [here.](https://learn.microsoft.com/en-us/cpp/extensions/boxing-cpp-componen… The generated code will: 1. Call `__abi_make_type_id` with a `struct __abi_type_descriptor *` value, which is just a typecode + string pair. This returns a `Platform::Type` object. 2. Call `Platform::Type::GetTypeCode` on the returned `Platform::Type` object to get back the typecode. 3. Call `Platform::Details::CreateValue` with the typecode and a pointer to the actual value that needs to be boxed. Apart from the usual WinRT methods, `Platform::Type` obejcts also impement the `IEquatable` and `IPrintable` interfaces. I don't know what their vtables look like, though. The `Platform::Type` and `Platform::Object` classes also have associated RTTI (can be demonstrated by calling `__RTtypeid`), which we'll also need to emit at some point in the future. -- v7: vccorlib140: Use the correct symbol name for InitControlBlock on i386 and arm. vccorlib140: Implement Platform::Details::CreateValue. vccorlib140: Add stub for Platform::Details::CreateValue. https://gitlab.winehq.org/wine/wine/-/merge_requests/8831

2 8

[PATCH v5 0/6] MR8831: vccorlib140: Implement support for boxed values (aka IPropertyValue)
by Vibhav Pant (＠vibhavp) Aug. 26, 2025

Aug. 26, 2025

C++/CX exposes `IPropertyValue` through `Platform::Details::CreateValue`, which returns a `Platform::Object` (which just seems to be a `IPropertyValue` object + C++ RTTI) containing the boxed value. Apps don't seem to call `CreateValue` directly with a typecode. The code for boxing values gets generated when a value type gets assigned to a `Platform::Object` variable, as documented [here.](https://learn.microsoft.com/en-us/cpp/extensions/boxing-cpp-componen… The generated code will: 1. Call `__abi_make_type_id` with a `struct __abi_type_descriptor *` value, which is just a typecode + string pair. This returns a `Platform::Type` object. 2. Call `Platform::Type::GetTypeCode` on the returned `Platform::Type` object to get back the typecode. 3. Call `Platform::Details::CreateValue` with the typecode and a pointer to the actual value that needs to be boxed. Apart from the usual WinRT methods, `Platform::Type` obejcts also impement the `IEquatable` and `IPrintable` interfaces. I don't know what their vtables look like, though. The `Platform::Type` and `Platform::Object` classes also have associated RTTI (can be demonstrated by calling `__RTtypeid`), which we'll also need to emit at some point in the future. -- v5: vccorlib140: Use the correct symbol name for InitControlBlock on i386 and arm. vccorlib140: Implement Platform::Details::CreateValue. vccorlib140: Add stub for Platform::Details::CreateValue. vccorlib140: Implement Platform::Type::{Equals, GetTypeCode, ToString, FullName::get}. vccorlib140: Implement __abi_make_type_id. https://gitlab.winehq.org/wine/wine/-/merge_requests/8831

3 10

Re: [PATCH v10 0/6] MR6569: winex11: Refactor window state/config tracker to fix race conditions.
by Stian Low (＠stianlow) Aug. 26, 2025

Aug. 26, 2025

@rbernon do you know if winelib is expected to produce windowing bugs for .so files converted from DLL files vs running those DLL files through Wine runtime? yabridge uses winelib to produce VST.so files. Might winelib be missing components when exporting to .so files that otherwise exist for Wine runtime that fixes the bugs? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_113850

1 0

[PATCH 0/1] MR8836: kernelbase/tests: Fix test failing with old Windows 10.
by Bernhard Übelacker Aug. 26, 2025

Aug. 26, 2025

Followup to 8de32c977d. [Test pattern page](https://test.winehq.org/data/patterns.html#kernelbase:process) [Testbot run with this patch](https://testbot.winehq.org/JobDetails.pl?Key=159528) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8836

1 1

Re: [PATCH v17 0/1] MR8778: sane.ds: Adding a window for loading and saving the scanner configuration
by Ivan Lyugaev (＠valy) Aug. 26, 2025

Aug. 26, 2025

On Fri Aug 22 12:52:27 2025 +0000, Ivan Lyugaev wrote: > I understand, but would it be more convenient for them than opening a > regular file? Will my MR be considered further? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8778#note_113837

1 0

[PATCH 0/1] MR8822: d3dx10_43: Fix test for SDK version 40.
by Bernhard Übelacker Aug. 26, 2025

Aug. 26, 2025

Followup to: 3e67471d02 Looks like this sould be a >= as it affects just d3dx10_40, at least with it the test succeeds on testbot. [Test pattern page](https://test.winehq.org/data/patterns.html#d3dx10_40:d3dx10) [Test pattern page, Aug 21 Summary for build e155f7c04b7c](https://test.winehq.org/data/e155f7c04b7c529af9e0f64ee3db8ef3… [Testbot run with this patch](https://testbot.winehq.org/JobDetails.pl?Key=159474) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8822

2 6

[PATCH v2 0/1] MR8669: Draft: Map low level hooks coordinates correctly in win32u
by Santino Mazza (＠tati) Aug. 26, 2025

Aug. 26, 2025

Coordinates from mouse low level hook messages are not mapped the same way than WM_MOUSEMOVE or GetCursorPos. This causes problems on programs that make use of both values to calculate mouse movement, like the wine DirectInput implementation. I'm marking this as a draft since I was not able to find a way to write a test for this. I'm able to easily reproduce it on Proton, because it creates a scaled full screen window, on Wine this doesn't happen so the coordinates are not required to be mapped to a scaled window. Edit: I didn't realize that modesetting emulation was an experimental option! So, I was able to reproduce the bug by enabling it. -- v2: win32u: Map raw coordinates to virtual screen in low-level hooks. https://gitlab.winehq.org/wine/wine/-/merge_requests/8669

3 2

Re: [PATCH v30 0/1] MR8573: cmd: tab completion: Treat most delimiters as literals if user specified quotes.
by Alexandre Julliard (＠julliard) Aug. 26, 2025

Aug. 26, 2025

You should stop updating your MR every day. Not only is it a waste of CI resources, but it makes it look like it's not ready since it keeps being updated. Also you don't need additional forks, you can create a MR from a different branch in the same fork. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8573#note_113830

1 0

[PATCH 0/1] MR8835: bluetoothapis/tests: Avoid crash in gatt tests with some Windows versions.
by Bernhard Übelacker Aug. 26, 2025

Aug. 26, 2025

Without this patch a crash with 32-bit tests with versions Win8.1 to Win10-1607 is visible. [Test pattern page](https://test.winehq.org/data/patterns.html#bluetoothapis:gatt) [Testbot run with this patch](https://testbot.winehq.org/JobDetails.pl?Key=159525) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8835

1 1

Re: [PATCH v10 0/6] MR6569: winex11: Refactor window state/config tracker to fix race conditions.
by Stian Low (＠stianlow) Aug. 26, 2025

Aug. 26, 2025

Latest updates: https://bugs.winehq.org/show_bug.cgi?id=58552#c43 Carla offers experimental features supporting VST DLL direct usage via Wine similar to how Steam on Linux handles running Windows games. Carla direct VST DLL usage works without the GUI offsets. Carla VST.so converted by yabridge from VST DLLs have GUI offset bugs. Thus it seems yabridge may be handling windowing behavior better left to Wine if possible. Maybe whatever Wine internal windowing component that resolves the GUI offsets for direct DLL usage can be integrated to VST.so files so they may still be used without any other Wine runtime dependencies? These latest tests help further clarify where the underlying faults may lie regarding bug reports against this merge. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_113829

1 0

[PATCH 0/3] MR8834: server: Use process_vm_writev / process_vm_readv instead of ptrace when available.
by Paul Gofman (＠gofman) Aug. 26, 2025

Aug. 26, 2025

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

2 5

[PATCH 0/7] MR7367: winex11: Use _NET_ACTIVE_WINDOW to request/track foreground window.
by Rémi Bernon Aug. 26, 2025

Aug. 26, 2025

This should at least fix foreground window inconsistencies between Wine and X11, when _NET_ACTIVE_WINDOW is supported by the WM, allowing us to then better implement focus tracking (to avoid changing focus when not desired), as well as SWP_NOACTIVATE. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7367

3 11

Re: [PATCH v17 0/1] MR6199: winewayland: Fix release_all_keys's modifier filtering.
by Yuri Hérouard Aug. 26, 2025

Aug. 26, 2025

Closing as I was confused with my workaround. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6199#note_113817

1 0