July 2025 - wine-gitlab

[PATCH 0/1] MR8669: Draft: Map low level hooks coordinates correctly in win32u
by Santino Mazza (＠tati) 14 Aug '25

14 Aug '25

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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8669

3 3

[PATCH 0/4] MR8688: server: Start to expose Unix symlinks as NT reparse points.
by Elizabeth Figura (＠zfigura) 13 Aug '25

13 Aug '25

A Wine user has requested the ability to interact with Unix symlinks from Win32 code. While the generic functionality of NT reparse points is still not implemented upstream, it will probably involve a completely different code path than this, so there does not seem to me to be any point in waiting for that to be done before submitting these patches. This does not implement all the relevant functionality. FILE_OPEN_REPARSE_POINT is now respected, but returns an fd with no fd->unix_fd. Thus far only file disposition (i.e. deletion), renaming and hardlinking are implemented, and all other operations return the no_fd_status, for which STATUS_REPARSE_POINT_NOT_RESOLVED is arbitrarily chosen. This is probably going to be controversial. As controversial patches tend to get deferred forever, I'm going to at least try to pose some questions related to concept and implementation which may be easier to answer. * Do we want to expose Unix symlinks at all? This was requested by a Wine user, and it does seem a strong argument that Wine, in general, supports some measure of integration with the host, including exposing custom interfaces for programs written to take advantage of it. We also, currently, already expose Unix *directory* symlinks via NtQueryAttributesFile(). We don't currently expose such file symlinks (and this series does not change that particular point, but it would be done by follow-up patches). In a sense we are expanding existing partial support. On the other hand, Unix symlinks which are completely opaque can be useful, and some downstream distributions (CrossOver and Proton) currently rely on them to reduce disk space usage while keeping the application unaware of a symlink (even if it were to use FILE_OPEN_REPARSE_POINT. Not that any applications are currently known that would break if this were to change, and in any case they could simply revert these patches.) * Implementation-wise, is having unix_fd == -1 a non-starter? This can be true of other real fds in some specific cases... * It's also true that this current implementation suffers from some degree of TOCTOU problems: because we only store the name and not the FD anymore, the actual underlying object at that path can change. This would not be true on Windows. Is this a problem? * One alternate approach would be to use O_PATH (Linux, FreeBSD) and O_SYMLINK (Mac). I don't see any equivalent flag for NetBSD or Solaris, so we would probably just not be able to expose this functionality there. Note that while the documentation seems to imply that O_PATH only stores the path, manual testing shows that (at least on Linux) a fd opened with O_PATH will remain pointing at the same *inode* even if it is moved or deleted. So this would avoid the aforementioned TOCTOU problem. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8688

5 9

[PATCH 0/1] MR5155: user32: add stub for GetPointerDeviceRects.
by Etaash Mathamsetty (＠etaash.mathamsetty) 13 Aug '25

13 Aug '25

might fix https://bugs.winehq.org/show_bug.cgi?id=56363, waiting for a reply -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5155

3 4

[PATCH v6 0/41] MR6207: Draft: include: Introduce new COM implementation helper macros.
by Rémi Bernon (＠rbernon) 12 Aug '25

12 Aug '25

I think it would be very nice to have something like that to reduce the burden of implementing COM interfaces. This shows for instance on the windows.gaming.input module a 30% LoC reduction (from ~6800 to ~4700), even though the module already had a boilerplate helper macros already. The MR introduces macros to automatically implement each IUnknown method, as well as all of them at once. It also includes a helper to implement IInspectable methods at once, as well as macros to forward both interface methods to a base interface or an outer object. Last, it provides higher-level macros to implement a main interface and any number of sub interfaces and generate IUnknown, forwarding and vtables for all of them at once, with IInspectable support when needed. It uses widl to generate additional per-interface macros, for things like inheritance and vtable generation. The rest of the macros are otherwise shared in a Wine-specific header. The implementation is split to show individual macro being used, although they are later replaced by higher-level macros. The individual helpers are still useful in some corner cases where specific behavior needs to be implemented, or for aggregating classes. -- v6: widl: Generate return traces for COM classes. widl: Generate method traces for COM classes. widl: Generate COM class code for IClassFactory. windows.gaming.input: Generate the provider COM class. windows.gaming.input: Generate the vector COM classes. windows.gaming.input: Generate the async COM classes. windows.gaming.input: Generate the manager COM classes. windows.gaming.input: Generate the force feedback COM classes. windows.gaming.input: Generate the ramp effect COM classes. windows.gaming.input: Generate the periodic effect COM classes. windows.gaming.input: Generate the constant effect COM classes. windows.gaming.input: Generate the condition effect COM classes. (broken) windows.gaming.input: Generate the racing wheel COM classes. windows.gaming.input: Generate the gamepad COM classes. windows.gaming.input: rename controller to raw_controller widl: Generate initializers for COM classes. widl: Generate vtables for COM classes. widl: Generate impl unwrappers for COM classes. widl: Generate QueryInterface for COM classes. widl: generate some query interface helpers widl: Generate default IUnknown / IInspectable implementation. widl: Generate IUnkonwn and IInspectable forwarding for COM classes. widl: Generate impl_from helpers for COM classes. windows.gaming.input: Use the generated COM class structs. widl: Generate some structs for COM classes. widl: Parse a widl-specific impl attribute on structs. makedep: Generate some new impl.h headers from the IDLs. widl: Generate some new impl.h headers from the IDLs. windows.gaming.input: Use a separate interface for IAgileObject. widl: Introduce a new append_declspec helper. widl: Inline write_args into write_type_right. widl: Cleanup indentation and variables in write_type_right. widl: Remove now unnecessary write_callconv argument. widl: Introduce a new append_type_left helper. widl: Split write_type_left into a write_type_definition_left helper. widl: Cleanup indentation and variables in write_type_left. widl: Introduce a new write_record_type_definition helper. widl: Move some type name construction out of write_type_left. widl: Remove unnecessary recursion for TYPE_BITFIELD. widl: Introduce a new append_basic_type helper. widl: Wrap strappend parameters in a new struct strbuf. This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/6207

3 16

[PATCH v10 0/4] MR8553: kernelbase: implement VirtualProtectFromApp
by Kareem Aladli (＠karim_adli) 12 Aug '25

12 Aug '25

This implements the VirtualProtectFromApp function in kernelbase, which was previously a commented out stub. Even though this function is meant for UWP apps, it is usable in desktop apps, as specified in [Windows documentation](https://learn.microsoft.com/en-us/windows/win32/api/memoryap…. Fixes Wine-Bug: [https://bugs.winehq.org/show_bug.cgi?id=58482](https://bugs.winehq.org/show… -- v10: ntdll/tests: Add tests for NtProtectVirtualMemory() ntdll: Set old_prot to PAGE_NOACCESS in NtProtectVirtualMemory() if the range is not mapped or committed. kernelbase/tests: Add tests for VirtualProtectFromApp https://gitlab.winehq.org/wine/wine/-/merge_requests/8553

2 5

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

11 Aug '25

`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 11

[PATCH 0/1] MR8591: ntdll: Fill EnabledFeatures before return.
by Bernhard Übelacker (＠bernhardu) 09 Aug '25

09 Aug '25

Followup to 03039ab2ee. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58335 If I observed it right we currently leave `init_xstate_features` on older computers with EnabledFeatures being zero. This leads in `__wine_syscall_dispatcher` to getting the xsave64 getting called with "$rax = 0x0", therefore e.g. xmm6 gets not saved to the stack. But later e.g. xmm6 gets restored from stack in `__wine_syscall_dispatcher` (see [](https://gitlab.winehq.org/wine/wine/-/blob/wine-10.12/dlls/ntdll/unix/signal_x86_64.c?ref_type=tags#L2774-L2882)) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8591

7 19

[PATCH v4 0/8] MR8654: windows.devices.bluetooth: Add stubs for BluetoothLEAdvertisementWatcher
by Vibhav Pant (＠vibhavp) 08 Aug '25

08 Aug '25

`BluetoothLEAdvertisementWatcher` is required for LE device discovery on WinRT. Several WinRT apps, like Zwift will try getting this interface, and crash if they are not able to. -- v4: windows.devices.bluetooth: Implement BluetoothLEAdvertisementWatcher::get_{Min, Max}OutOfRangeTimeout. windows.devices.bluetooth: Implement BluetoothLEAdvertisementWatcher::get_{Min, Max}SamplingInterval. windows.devices.bluetooth: Add stubs for BluetoothLEAdvertisementWatcher. windows.devices.bluetooth/tests: Add tests for IBluetoothLEAdvertisementWatcher. windows.devices.bluetooth/tests: Add tests for BluetoothLEAdvertisementDataSection. windows.devices.bluetooth/tests: Add tests for IBluetoothLEAdvertisementBytePattern. windows.devices.bluetooth/tests: Add tests for BluetoothLEAdvertisementFilter. include: Add windows.devices.bluetooth.advertisement.idl. https://gitlab.winehq.org/wine/wine/-/merge_requests/8654

3 15

[PATCH v3 0/6] MR8445: server: Create inproc sync events for message queues.
by Rémi Bernon (＠rbernon) 08 Aug '25

08 Aug '25

The message queue needs both an inproc sync, to wake inproc waits on a message and trigger a server request, and a server sync, for when the wait is only on the queue and should be optimized into a single server request. It could be better to avoid a dedicated request to retrieve the queue inproc sync fd, for instance by sending an fd on thread init, but we can use this to duality to gradually introduce inproc syncs requests instead and avoid dead code (even though the code ultimately returns STATUS_NOT_IMPLEMENTED for now). We can change the way queue inproc sync fds are retrieved later on. -- v3: ntdll: Check inproc sync handle access rights on wait. server: Add a request to retrieve the inproc sync fds. server: Create inproc sync events for message queues. ntdll: Retrieve and cache an ntsync device on process init. ntdll: Add stub functions for in-process synchronization. ntdll: Add some traces to synchronization methods. https://gitlab.winehq.org/wine/wine/-/merge_requests/8445

4 12

[PATCH 0/4] MR8656: mshtml: Implement attribute nodes with gecko nodes in IE9+ modes.
by Gabriel Ivăncescu (＠insn) 07 Aug '25

07 Aug '25

For the IE9 attr node implementation (delegating to gecko attr nodes), this uses the existing infrastructure to keep track of the attributes in a collection (and so, associate DISPIDs for them, etc), since it also matches native (same DISPID broken behavior when removing attrs) and we already have the code for it. The current code is split into helpers called from many places already related to it, so instead I just extended the helpers with new code paths for IE9+ attrs. There's also appropriate FIXMEs for things that aren't properly handled by simple delegation to gecko (from my older patchset), so at least if we find something that needs it, it will be way easier to debug. The last patch is a bit big since it had to enable the new attr nodes everywhere in IE9+ modes, else either tests would fail or we wouldn't test anything, as I'm using existing tests (just in IE9 mode). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8656

3 9

2025

2024

2023

2022

wine-gitlab July 2025