- wine-gitlab - winehq.org

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Robert Lippmann (＠rlippmann) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:32:59 2025 +0000, Robert Lippmann wrote: > These are additional power related functions that were defined in > Windows Vista (the current code is like 20 years old). Oops, I just took the output of winedump and didn't change the numbers to @'s. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98761

1 0

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Robert Lippmann (＠rlippmann) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:37:26 2025 +0000, Nikolay Sivov wrote: > Do you have an application that depends on those functions returning anything? SteamVR's vrmonitor.exe tries to change the power profile and crashes with an access violation. Valve has been bugged about this for years, since they really shouldn't be doing it. So, I figure it will never be fixed by them. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98760

1 0

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Robert Lippmann (＠rlippmann) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:35:07 2025 +0000, Nikolay Sivov wrote: > Hi, @rlippmann. This needs some basic cleanup first - fixup commits > should be merged with main commits so that MR has a clean list of > wellformed changes. Note that you don't need to create a new MR every > time you want to change something. Just force push to the same branch. I've been trying to. Unfortunately the pipeline build fails every time saying it couldn't get my credentials even though I've set git global username and email address. I've been trying to figure out why that happens, hence the multiple (closed) merge requests. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98759

1 0

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Robert Lippmann (＠rlippmann) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:15:29 2025 +0000, Nikolay Sivov wrote: > Why do you need this? These are additional power related functions that were defined in Windows Vista (the current code is like 20 years old). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98758

1 0

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Robert Lippmann (＠rlippmann) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:15:29 2025 +0000, Nikolay Sivov wrote: > You probably don't need a new file for this. Well, according to the SDK, the header is now powersetting.h, not powrprof.h, which is why I created the new file. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98757

1 0

[PATCH 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Robert Lippmann (＠rlippmann) 22 Mar '25

22 Mar '25

These functions were split out in Windows Vista. This commit also updates the .spec with newer power related SDK calls. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644

3 15

[PATCH v3 0/8] MR7643: powrprof.dll: Move PowerGet/SetActiveScheme to powersetting.c
by Robert Lippmann (＠rlippmann) 22 Mar '25

22 Mar '25

This patch also adds stubs for power related functions added in Windows Vista. -- v3: powrprof.dll: more whitespace fixes https://gitlab.winehq.org/wine/wine/-/merge_requests/7643

2 9

[PATCH v4 0/1] MR7642: Draft: server: Fall back to epoll_wait if epoll_pwait2 isn't available at run-time.
by William Horvath (＠whrvt) 22 Mar '25

22 Mar '25

This fixes a real problem and improves behavior at the same time. - Fixes: hanging when trying to run Wine built with epoll_pwait2 headers available but epoll_pwait2 is missing in the run-time kernel (i.e. build 5.11->run 5.10) - Improvement: bring the improved timeout resolution to Wine builds which didn't have epoll_pwait2 at compile time, if the run-time kernel supports it (i.e. build 5.10->run 6.14) This last point is especially important in my opinion, as it applies to official Proton builds. Proton is (currently) built in Debian 11 with kernel 5.10, but SteamOS is a moving target with a much newer kernel version being used to run these Wine builds. These builds use the lower resolution timeouts if epoll_pwait2 is only checked for at compile-time, when it can cheaply and easily be done at run-time instead. Fixes: 87ca5db40e2c1b37423bdc25101a5c5e39e67e6f An alternative to !7640 that kills two birds with one stone. -- v4: server: Fall back to epoll_wait if epoll_pwait2 isn't available at run-time. https://gitlab.winehq.org/wine/wine/-/merge_requests/7642

2 1

Re: [PATCH 0/6] MR7639: powrprof.dll: Implement PowerGet/SetActiveScheme - closed
by Robert Lippmann (＠rlippmann) 22 Mar '25

22 Mar '25

This merge request was closed by Robert Lippmann. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7639

1 0

[PATCH v3 0/1] MR7642: Draft: server: Fall back to epoll_wait if epoll_pwait2 isn't available at run-time.
by William Horvath (＠whrvt) 22 Mar '25

22 Mar '25

This fixes a real problem and improves behavior at the same time. - Fixes: hanging when trying to run Wine built with epoll_pwait2 headers available but epoll_pwait2 is missing in the run-time kernel (i.e. build 5.11->run 5.10) - Improvement: bring the improved timeout resolution to Wine builds which didn't have epoll_pwait2 at compile time, if the run-time kernel supports it (i.e. build 5.10->run 6.14) This last point is especially important in my opinion, as it applies to official Proton builds. Proton is (currently) built in Debian 11 with kernel 5.10, but SteamOS is a moving target with a much newer kernel version being used to run these Wine builds. These builds use the lower resolution timeouts if epoll_pwait2 is only checked for at compile-time, when it can cheaply and easily be done at run-time instead. Fixes: 87ca5db40e2c1b37423bdc25101a5c5e39e67e6f An alternative to !7640 that kills two birds with one stone. -- v3: server: Fall back to epoll_wait if epoll_pwait2 isn't available at run-time. https://gitlab.winehq.org/wine/wine/-/merge_requests/7642

2 1

[PATCH v2 0/1] MR7642: server: Fall back to epoll_wait if epoll_pwait2 isn't available at run-time.
by William Horvath (＠whrvt) 22 Mar '25

22 Mar '25

This fixes a real problem and improves behavior at the same time. - Fixes: hanging when trying to run Wine built with epoll_pwait2 headers available but epoll_pwait2 is missing in the run-time kernel (i.e. build 5.11->run 5.10) - Improvement: bring the improved timeout resolution to Wine builds which didn't have epoll_pwait2 at compile time, if the run-time kernel supports it (i.e. build 5.10->run 6.14) This last point is especially important in my opinion, as it applies to official Proton builds. Proton is (currently) built in Debian 11 with kernel 5.10, but SteamOS is a moving target with a much newer kernel version being used to run these Wine builds. These builds use the lower resolution timeouts if epoll_pwait2 is only checked for at compile-time, when it can cheaply and easily be done at run-time instead. Fixes: 87ca5db40e2c1b37423bdc25101a5c5e39e67e6f An alternative to !7640 that kills two birds with one stone. -- v2: server: Fall back to epoll_wait if epoll_pwait2 isn't available at run-time. https://gitlab.winehq.org/wine/wine/-/merge_requests/7642

3 3

[PATCH 0/1] MR7642: server: Fall back to epoll_wait if epoll_pwait2 isn't available at run-time.
by William Horvath (＠whrvt) 22 Mar '25

22 Mar '25

This fixes a real problem and improves behavior at the same time. - Fixes: hanging when trying to run Wine built with epoll_pwait2 headers available but epoll_pwait2 is missing in the run-time kernel (i.e. build 5.11->run 5.10) - Improvement: bring the improved timeout resolution to Wine builds which didn't have epoll_pwait2 at compile time, if the run-time kernel supports it (i.e. build 5.10->run 6.14) This last point is especially important in my opinion, as it applies to official Proton builds. Proton is (currently) built in Debian 11 with kernel 5.10, but SteamOS is a moving target with a much newer kernel version being used to run these Wine builds. These builds use the lower resolution timeouts if epoll_pwait2 is only checked for at compile-time, when it can cheaply and easily be done at run-time instead. Fixes: 87ca5db40e2c1b37423bdc25101a5c5e39e67e6f An alternative to !7640 that kills two birds with one stone. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7642

2 1

[PATCH v2 0/2] MR7619: comctl32: Implement EVENT_OBJECT_VALUECHANGE for edit controls.
by Esme Povirk (＠madewokherd) 22 Mar '25

22 Mar '25

-- v2: comctl32/tests: Test MSAA events for edit controls. comctl32: Implement EVENT_OBJECT_VALUECHANGE for edit controls. https://gitlab.winehq.org/wine/wine/-/merge_requests/7619

3 5

[PATCH 0/1] MR7622: comctl32: Avoid segfault in PROPSHEET_DoCommand when psInfo is NULL.
by YuriK7 (＠riyu12383) 22 Mar '25

22 Mar '25

Fixes https://bugs.winehq.org/show_bug.cgi?id=57987. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7622

3 3

[PATCH 0/1] MR7640: server: Fall back to epoll_wait if epoll_pwait2 doesn't work
by Alfred Agrell (＠Alcaro) 22 Mar '25

22 Mar '25

Fixes hangs if Wine is built with newer headers than kernel -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7640

2 2

[PATCH 0/1] MR7641: ntdll: Added side effect of KiUserCallbackDispatcher needed for SkyrimSE CreationKit
by Keaton Ens (＠kgzod) 22 Mar '25

22 Mar '25

Push 0x7fff to the stack in __wine_syscall_dispatcher to recreate side effect of KiUserCallbackDispatcher needed by Skyrim Special Edition: Creation Kit to fix a menu resolution bug. Wine Bug: https://bugs.winehq.org/show_bug.cgi?id=58003 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7641

2 1

Re: [PATCH v6 0/2] MR7638: Draft: gdiplus: Fix matrix transformations for GdipGetPathWorldBounds function - closed
by Bartosz Kosiorek (＠gang65) 22 Mar '25

22 Mar '25

This merge request was closed by Bartosz Kosiorek. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7638

1 0

[PATCH v4 0/5] MR7630: winebth.sys part 7: Introduce support for authentication/pairing.
by Vibhav Pant (＠vibhavp) 22 Mar '25

22 Mar '25

Introduce infrastructure necessary to support receiving, sending and replying (to) Bluetooth authentication/pairing requests: - During startup, the Bluetooth driver now creates a "pairing agent" and registers it with BlueZ. The pairing agent is a DBus object implementing the `org.bluez.Agent1` interface (documented [here](https://github.com/bluez/bluez/blob/master/doc/org.bluez.Agent.rst)), which receives authentication requests from BlueZ. The pairing agent then forwards the request data to the PE driver, in form of a `WINEBLUETOOTH_EVENT_AUTH_EVENT` event. The agent is unregistered during driver shutdown. - Right now, the agent only supports Numeric Comparison pairing requests. - Create a new auxiliary device, `\??\WINEBTHAUTH` during driver startup. This device handles authentication functionality that is independent of radio PDOs on the system, which allows the userspace APIs to not track individual Bluetooth radio objects to implement authentication. `WINEBTHAUTH` right now serves two purposes: - Serve as the device object for which `GUID_WINEBTH_AUTHENTICATION_REQUEST` PnP events are broadcasted. This event is sent whenever the Bluetooth event loop in (`bluetooth_event_loop_thread_proc`) receives `WINEBLUETOOTH_EVENT_AUTH_EVENT`. The event's buffer contains a `struct winebth_authentication_request` value, which contains data relevant to the incoming auth request. - Handle the `IOCTL_WINEBTH_AUTH_REGISTER` IOCTL. This simply calls the [`RequestDefaultAgent` BlueZ method](https://github.com/bluez/bluez/blob/master/doc/org.bluez.AgentManag… right now, which asks BlueZ to send all incoming Bluetooth authentication requests to Wine's pairing agent (described above). This is not always strictly necessary, but is useful if there already is a default pairing agent set. - `WINEBTHAUTH` will also ultimately be in charge of responding to authentication requests, which I'll be adding in the next-ish MR(s). - Implement `BluetoothRegisterForAuthenticationEx` and `BluetoothUnregisterAuthentication`. Registration is done by invoking `IOCTL_WINEBTH_AUTH_REGISTER`, and then listening for `GUID_WINEBTH_AUTHENTICATION_REQUEST` events on a `HANDLE` to `\??\WINEBTHAUTH` using the newly added `CM_Register_Notifications`. To keep the MR from getting any larger, I have not included support for `BluetoothSendAuthenticationResponseEx`. That will likely be introduced in the future. -- v4: bluetoothapis/tests: Add tests for BluetoothRegisterForAuthenticationEx and BluetoothUnregisterAuthentication. https://gitlab.winehq.org/wine/wine/-/merge_requests/7630

2 6

[PATCH v4 0/2] MR7638: gdiplus: Fix matrix transformations for GdipGetPathWorldBounds function
by Bartosz Kosiorek (＠gang65) 22 Mar '25

22 Mar '25

-- v4: gdiplus: Fix matrix transformations for GdipGetPathWorldBounds https://gitlab.winehq.org/wine/wine/-/merge_requests/7638

2 2

[PATCH v3 0/2] MR7638: gdiplus: Fix matrix transformations for GdipGetPathWorldBounds function
by Bartosz Kosiorek (＠gang65) 22 Mar '25

22 Mar '25

-- v3: gdiplus: Fix matrix transformations for GdipGetPathWorldBounds https://gitlab.winehq.org/wine/wine/-/merge_requests/7638

2 2

[PATCH v3 0/5] MR7630: winebth.sys part 7: Introduce support for authentication/pairing.
by Vibhav Pant (＠vibhavp) 22 Mar '25

22 Mar '25

Introduce infrastructure necessary to support receiving, sending and replying (to) Bluetooth authentication/pairing requests: - During startup, the Bluetooth driver now creates a "pairing agent" and registers it with BlueZ. The pairing agent is a DBus object implementing the `org.bluez.Agent1` interface (documented [here](https://github.com/bluez/bluez/blob/master/doc/org.bluez.Agent.rst)), which receives authentication requests from BlueZ. The pairing agent then forwards the request data to the PE driver, in form of a `WINEBLUETOOTH_EVENT_AUTH_EVENT` event. The agent is unregistered during driver shutdown. - Right now, the agent only supports Numeric Comparison pairing requests. - Create a new auxiliary device, `\??\WINEBTHAUTH` during driver startup. This device handles authentication functionality that is independent of radio PDOs on the system, which allows the userspace APIs to not track individual Bluetooth radio objects to implement authentication. `WINEBTHAUTH` right now serves two purposes: - Serve as the device object for which `GUID_WINEBTH_AUTHENTICATION_REQUEST` PnP events are broadcasted. This event is sent whenever the Bluetooth event loop in (`bluetooth_event_loop_thread_proc`) receives `WINEBLUETOOTH_EVENT_AUTH_EVENT`. The event's buffer contains a `struct winebth_authentication_request` value, which contains data relevant to the incoming auth request. - Handle the `IOCTL_WINEBTH_AUTH_REGISTER` IOCTL. This simply calls the [`RequestDefaultAgent` BlueZ method](https://github.com/bluez/bluez/blob/master/doc/org.bluez.AgentManag… right now, which asks BlueZ to send all incoming Bluetooth authentication requests to Wine's pairing agent (described above). This is not always strictly necessary, but is useful if there already is a default pairing agent set. - `WINEBTHAUTH` will also ultimately be in charge of responding to authentication requests, which I'll be adding in the next-ish MR(s). - Implement `BluetoothRegisterForAuthenticationEx` and `BluetoothUnregisterAuthentication`. Registration is done by invoking `IOCTL_WINEBTH_AUTH_REGISTER`, and then listening for `GUID_WINEBTH_AUTHENTICATION_REQUEST` events on a `HANDLE` to `\??\WINEBTHAUTH` using the newly added `CM_Register_Notifications`. To keep the MR from getting any larger, I have not included support for `BluetoothSendAuthenticationResponseEx`. That will likely be introduced in the future. -- v3: bluetoothapis/tests: Add tests for BluetoothRegisterForAuthenticationEx and BluetoothUnregisterAuthentication. bluetoothapis: Implement BluetoothRegisterForAuthenticationEx and BluetoothUnregisterForAuthentication. winebth.sys: Implement IOCTL_WINEBTH_AUTH_REGISTER. winebth.sys: Broadcast a BLUETOOTH_AUTHENTICATION_REQUEST PnP event on receiving a RequestConfirmation request from BlueZ. https://gitlab.winehq.org/wine/wine/-/merge_requests/7630

2 5

[PATCH v9 0/9] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 21 Mar '25

21 Mar '25

Related Wine issue: https://bugs.winehq.org/show_bug.cgi?id=52714 I'm starting work on updating/extending Linux force feedback API and one of my goals is to expose the number and an array that contains the device's ffb-enabled axes. As I'm mainly working with USB PID driver, I already have a POC of obtaining this data. What prompted this is that currently Wine always creates virtual joysticks with two PID ffb axes. This causes issues with [Richard Burns Rally](https://github.com/ValveSoftware/Proton/issues/6702#issuecomment-267…, as this game incorrectly initializes a `CONSTANT_FORCE` effect with all the FFB axes that contain `DIDOI_FFACTUATOR` flag and then trying to update `cAxes` and `rgdwAxes` values which leads to `DIERR_INVALIDPARAM`. Now, this flag is set by wine while enumerating virtual device's axes and while `(axis index < FFB axes)`, flag is applied. This means, that every device which has FFB functionality and at least two axes, will report FFB on `X`, `Y`. While updated API would mean a lot of steering wheels would correctly report only 1 axis, a lot of USB PID wheels still include `X` and `Y` in their `AXES_ENABLE` and `DIRECTION` usages. This, again, would lead to broken FFB (in affected games). On Windows, there's a possibility of overwriting some joystick capabilities with registry entries, which ends up removing `DIDOI_FFACTUATOR` flag from a selected axis. This doesn't work in Wine. This MR allows Wine to add an arbitrary number (up to `PID_AXES_MAX`) of axes to the PID descriptor, based on the value of Haptic Axes from SDL or from Linux FF api in the future (I'm working on it). Additionally, to work around RBR and other games with similar, wrong FFB handling, I introduced a [hint](https://github.com/libsdl-org/SDL/issues/12341) to SDL that allows a dynamic overwrite of the number of haptic axes. For the Linux API, I'll figure out a nice way to override when the number of axes will be exposed. With these changes, I was able to successfully get force feedback on my Moza Racing R9 with all axes usable. With additional traces in the dinput code, I confirmed that with one axis defined in the PID descriptor, the game created a constant force effect with just one axis and `cAxes = 1`. -- v9: Try fixing tests https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 9

Re: [PATCH v5 0/2] MR7563: mf/tests: Tests timestamp values on output samples from the H.264 and WMV MFT decoders. - approved
by Alexandre Julliard (＠julliard) 21 Mar '25

21 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7563

1 0

Re: [PATCH v2 0/1] MR7629: winex11: Use -1 as fullscreen monitor indices to clear the property. - approved
by Alexandre Julliard (＠julliard) 21 Mar '25

21 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7629

1 0

Re: [PATCH v2 0/6] MR7635: wpcap: Fall back to a buffer copy if 32-bit mmap support is not available. - approved
by Alexandre Julliard (＠julliard) 21 Mar '25

21 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7635

1 0

[PATCH 0/2] MR7619: comctl32: Implement EVENT_OBJECT_VALUECHANGE for edit controls.
by Esme Povirk (＠madewokherd) 21 Mar '25

21 Mar '25

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

3 4

[PATCH v8 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 21 Mar '25

21 Mar '25

Related Wine issue: https://bugs.winehq.org/show_bug.cgi?id=52714 I'm starting work on updating/extending Linux force feedback API and one of my goals is to expose the number and an array that contains the device's ffb-enabled axes. As I'm mainly working with USB PID driver, I already have a POC of obtaining this data. What prompted this is that currently Wine always creates virtual joysticks with two PID ffb axes. This causes issues with [Richard Burns Rally](https://github.com/ValveSoftware/Proton/issues/6702#issuecomment-267…, as this game incorrectly initializes a `CONSTANT_FORCE` effect with all the FFB axes that contain `DIDOI_FFACTUATOR` flag and then trying to update `cAxes` and `rgdwAxes` values which leads to `DIERR_INVALIDPARAM`. Now, this flag is set by wine while enumerating virtual device's axes and while `(axis index < FFB axes)`, flag is applied. This means, that every device which has FFB functionality and at least two axes, will report FFB on `X`, `Y`. While updated API would mean a lot of steering wheels would correctly report only 1 axis, a lot of USB PID wheels still include `X` and `Y` in their `AXES_ENABLE` and `DIRECTION` usages. This, again, would lead to broken FFB (in affected games). On Windows, there's a possibility of overwriting some joystick capabilities with registry entries, which ends up removing `DIDOI_FFACTUATOR` flag from a selected axis. This doesn't work in Wine. This MR allows Wine to add an arbitrary number (up to `PID_AXES_MAX`) of axes to the PID descriptor, based on the value of Haptic Axes from SDL or from Linux FF api in the future (I'm working on it). Additionally, to work around RBR and other games with similar, wrong FFB handling, I introduced a [hint](https://github.com/libsdl-org/SDL/issues/12341) to SDL that allows a dynamic overwrite of the number of haptic axes. For the Linux API, I'll figure out a nice way to override when the number of axes will be exposed. With these changes, I was able to successfully get force feedback on my Moza Racing R9 with all axes usable. With additional traces in the dinput code, I confirmed that with one axis defined in the PID descriptor, the game created a constant force effect with just one axis and `cAxes = 1`. -- v8: dinput/tests: Add tests for 6-axis ff joystick winebus: Get the number of haptic axes from SDL winebus: Support creation of arbitrary number of PID axes winebus: Use physical->num_axes to compute effect_update report size winebus: Store the number of FFB axes of a unix_device winebus: Use PID_AXES_MAX in unix_private.h dinput: Use PID_AXES_MAX in joystick_hid for axes, directions, conditions hid: Define the max number of supported PID axes https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 8

[PATCH v4 0/2] MR7563: mf/tests: Tests timestamp values on output samples from the H.264 and WMV MFT decoders.
by Brendan McGrath (＠redmcg) 21 Mar '25

21 Mar '25

These tests serve to illustrate the output sample time and duration values from their respective native MFT video decoders with respect to the following circumstances: 1. When no frame rate nor input sample timestamps are provided; 2. When a frame rate is provided but there are no sample timestamps; and 3. When a frame rate is provided, but the input sample timestamps disagree with this value It also highlights the gap in our implementation. However, I don't believe this can be fixed without first confirming the correct output from our IMFMediaStream implementations. -- v4: mf/tests: Test timestamps in WMV decoder. mf/tests: Test timestamps in H264 decoder. https://gitlab.winehq.org/wine/wine/-/merge_requests/7563

3 4

[PATCH 0/1] MR7637: wow64: skip memcpy for null pointer
by Vitaly Lipatov (＠lav) 21 Mar '25

21 Mar '25

It looks like according to the C spec, calling memcpy(0, 0, 0) results in undefined behavior. See also https://developers.redhat.com/articles/2024/12/11/making-memcpynull-null-0-… Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56154 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7637

2 1

Re: [PATCH v2 0/5] MR7630: winebth.sys part 7: Introduce support for authentication/pairing.
by Elizabeth Figura (＠zfigura) 21 Mar '25

21 Mar '25

From 2/5: ``` The PE driver then broadcasts a GUID_BLUETOOTH_AUTHENTICATION_REQUEST PnP event on the newly added WINEBTHAUTH device, ``` That should be GUID_WINEBTH_AUTHENTICATION_REQUEST. We also need to correctly handle IRP_MJ_PNP requests for this new device. From 4/5: ``` + if (!addr) + return wine_dbg_sprintf( "%p", addr ); ``` Just "(null)" seems more idiomatic. ``` + work = CreateThreadpoolWork( tp_auth_callback_work_proc, data, NULL ); ``` Why the threadpool? Why can't we call the callback right now? ``` + struct bluetooth_auth_listener *hreg; ``` Bikeshedding, but "hreg" seems an odd variable name; why not "listener"? ``` +static DWORD bluetooth_auth_register( BOOL reg ) +{ + DWORD ret; + + if (reg) + { + ... + } + else + { + ... + } + + return ret; +} ``` This is what I like to call an "anti-helper". Just make this two separate functions, and probably inline at least the unregister side as it's literally two lines. ``` + DeviceIoControl( winebth_auth, IOCTL_WINEBTH_AUTH_REGISTER, NULL, 0, NULL, 0, &bytes, NULL ); + ret = GetLastError(); ``` Don't check GetLastError() without also checking the return of DeviceIoControl(). Most functions which update the last error don't update it on success. From 5/5: ``` SOURCES = \ + auth.c \ device.c \ radio.c \ sdp.c ``` I really should have said something earlier, but we don't need all these different source files with less than 500 lines in each of them, especially if it's going to necessitate an extra header for helpers. ``` + if (hreg) + ok( BluetoothUnregisterAuthentication( hreg ), "BluetoothUnregisterAuthentication failed: %lu\n", GetLastError() ); + if (hreg2) + ok( BluetoothUnregisterAuthentication( hreg2 ), "BluetoothUnregisterAuthentication failed: %lu\n", GetLastError() ); ``` You don't need the checks, you already checked those in an earlier ok(). Also, you don't want to test GetLastError() and the call at the same time, there's no sequence point between those. This is the one point where you *do* need to assign a bool to a temporary variable. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7630#note_98631

1 0

[PATCH v14 0/3] MR7542: ws2_32: Implement WSALookupService for Bluetooth device discovery.
by Vibhav Pant (＠vibhavp) 21 Mar '25

21 Mar '25

This MR adds an initial implementation of the winsock `WSALookupsService*` methods for performing Bluetooth device discovery (`LUP_CONTAINERS`). Pending !7472, the code will also eventually support performing device inquiry scans. -- v14: ws2_32: Implement WSALookupServiceNext for Bluetooth device discovery. ws2_32: Implement WSALookupServiceBegin for Bluetooth device discovery. ws2_32/tests: Add tests for Bluetooth device discovery in WSALookupServiceBegin/Next. https://gitlab.winehq.org/wine/wine/-/merge_requests/7542

3 7

[PATCH v4 0/6] MR7608: server: Avoid delegating console waits to other objects.
by Elizabeth Figura (＠zfigura) 21 Mar '25

21 Mar '25

Some console objects currently do several unique things: * Delegate waits onto the queue of another object. This is not really a problem for in-process waits, since we can just return the sync object for the delegate. However, it's also unnecessary, adds to the complexity of the server logic, and is one out of one places where this is done. * Make the wait state dependent on the process. This is difficult to emulate with ntsync and would require creating separate server objects for each process, hacking into duplicate_handle. * Fail a wait entirely in certain circumstances. This is pretty much impossible to emulate with in-process waits. Although ntsync has been in development for some time, I have regrettably failed to notice these problems until now. Fortunately, none of these behaviours happen on modern Windows. Although I/O on unbound handles delegates to the console of the current process, the signaled state does not. As the tests here show, the signaled state of a handle depends on the active console of the process in which the handle was created. If that console no longer exists, the signaled state is no longer updated [with one rather inexplicable exception]. Crucially, in current Windows waits never fail, and the state of an object is the same across all process which hold handles to it. Therefore this patch brings our behaviour to closer match current Windows. In theory these are fds and should use default_fd_signaled(). However, the points at which the handles are signaled are completely different, and I/O does not trigger console handles to become signaled when it normally would. Therefore for the time being I've kept the code using custom signaled ops. There is one other oddity related to consoles, which is the existence of console_add_queue(), which seeks to lazily create an input thread when a console is first waited on. This is one out of two places, after this patch, when the wait process is hijacked (the other being message queues). Fortunately this is easy to handle for in-process synchronization objects, by queueing the ioctl from the callback used to retrieve the in-process synchronization object itself. -- v4: server: Track unbound output signaled state based on its original console. server: Track unbound input signaled state based on its original console. server: Allow waiting on an orphaned screen buffer. server: Use a list of screen buffers per console. server: Fail to create an unbound input/output when there is no console. kernel32/tests: Add more tests for orphaned console handles. https://gitlab.winehq.org/wine/wine/-/merge_requests/7608

2 7

[PATCH v7 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 21 Mar '25

21 Mar '25

Related Wine issue: https://bugs.winehq.org/show_bug.cgi?id=52714 I'm starting work on updating/extending Linux force feedback API and one of my goals is to expose the number and an array that contains the device's ffb-enabled axes. As I'm mainly working with USB PID driver, I already have a POC of obtaining this data. What prompted this is that currently Wine always creates virtual joysticks with two PID ffb axes. This causes issues with [Richard Burns Rally](https://github.com/ValveSoftware/Proton/issues/6702#issuecomment-267…, as this game incorrectly initializes a `CONSTANT_FORCE` effect with all the FFB axes that contain `DIDOI_FFACTUATOR` flag and then trying to update `cAxes` and `rgdwAxes` values which leads to `DIERR_INVALIDPARAM`. Now, this flag is set by wine while enumerating virtual device's axes and while `(axis index < FFB axes)`, flag is applied. This means, that every device which has FFB functionality and at least two axes, will report FFB on `X`, `Y`. While updated API would mean a lot of steering wheels would correctly report only 1 axis, a lot of USB PID wheels still include `X` and `Y` in their `AXES_ENABLE` and `DIRECTION` usages. This, again, would lead to broken FFB (in affected games). On Windows, there's a possibility of overwriting some joystick capabilities with registry entries, which ends up removing `DIDOI_FFACTUATOR` flag from a selected axis. This doesn't work in Wine. This MR allows Wine to add an arbitrary number (up to `PID_AXES_MAX`) of axes to the PID descriptor, based on the value of Haptic Axes from SDL or from Linux FF api in the future (I'm working on it). Additionally, to work around RBR and other games with similar, wrong FFB handling, I introduced a [hint](https://github.com/libsdl-org/SDL/issues/12341) to SDL that allows a dynamic overwrite of the number of haptic axes. For the Linux API, I'll figure out a nice way to override when the number of axes will be exposed. With these changes, I was able to successfully get force feedback on my Moza Racing R9 with all axes usable. With additional traces in the dinput code, I confirmed that with one axis defined in the PID descriptor, the game created a constant force effect with just one axis and `cAxes = 1`. -- v7: dinput/tests: Add tests for 6-axis ff joystick winebus: Get the number of haptic axes from SDL winebus: Support creation of arbitrary number of PID axes https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 8

[PATCH 0/5] MR7632: server, ntdll: Return the correct base/actual thread/process priority.
by Rémi Bernon (＠rbernon) 21 Mar '25

21 Mar '25

Second part of https://gitlab.winehq.org/wine/wine/-/merge_requests/7516 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7632

2 7

[PATCH 0/5] MR7636: d3dx9: Implement saving to DDS files in D3DXSaveTextureToFileInMemory().
by Connor McAdams (＠cmcadams) 21 Mar '25

21 Mar '25

The last of the saving patches for d3dx9. :) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7636

2 5

[PATCH 0/6] MR7635: wpcap: Fall back to a buffer copy if 32-bit mmap support is not available.
by Hans Leidekker (＠hans) 21 Mar '25

21 Mar '25

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

2 6

[PATCH v2 0/4] MR7634: ws2_32, server: Add initial support for AF_BTH sockets and BTHPROTO_RFCOMM.
by Vibhav Pant (＠vibhavp) 21 Mar '25

21 Mar '25

-- v2: ws2_32: Support bind for Bluetooth RFCOMM addresses. ws2_32: Add bind tests for Bluetooth RFCOMM sockets. server: Add support for creating Bluetooth RFCOMM sockets. https://gitlab.winehq.org/wine/wine/-/merge_requests/7634

2 4

[PATCH v8 0/5] MR7610: win32u: Create a shared object for user handle entries.
by Rémi Bernon (＠rbernon) 21 Mar '25

21 Mar '25

For https://gitlab.winehq.org/wine/wine/-/merge_requests/7512 to use it to locate window shared objects. -- v8: win32u: Use the session shared object to implement is_window. win32u: Use the session shared object for user handle entries. server: Move the user object handle table to the shared memory. server: Use NTUSER_OBJ constants for user object types. server: Create a shared memory object for the global session. https://gitlab.winehq.org/wine/wine/-/merge_requests/7610

4 14

[PATCH 0/4] MR7634: ws2_32, server: Add initial support for AF_BTH sockets and BTHPROTO_RFCOMM.
by Vibhav Pant (＠vibhavp) 21 Mar '25

21 Mar '25

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

2 4

[PATCH 0/1] MR7633: win32u: Fixed the sign error in the conversion from FIXED to FT_Fixed
by Yeshun Ye (＠yeyeshun) 21 Mar '25

21 Mar '25

If the `FT_MULFIX_ASSEMBLER` macro is not used during the compilation of FreeType, unsigned extension to `FT_Fixed` will cause `FT_MulFix` to produce incorrect results. The usage of the attached code is for compilation with GCC on x86_64. Toggling the `FT_MULFIX_ASSEMBLER` macro will produce different results. demo: [main.c](/uploads/18e77f790be1cb5acf2ef8f52b61bf39/main.c) Signed-off-by: YeshunYe <yeyeshun(a)uniontech.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7633

3 4

[PATCH v3 0/6] MR7608: server: Avoid delegating console waits to other objects.
by Elizabeth Figura (＠zfigura) 21 Mar '25

21 Mar '25

Some console objects currently do several unique things: * Delegate waits onto the queue of another object. This is not really a problem for in-process waits, since we can just return the sync object for the delegate. However, it's also unnecessary, adds to the complexity of the server logic, and is one out of one places where this is done. * Make the wait state dependent on the process. This is difficult to emulate with ntsync and would require creating separate server objects for each process, hacking into duplicate_handle. * Fail a wait entirely in certain circumstances. This is pretty much impossible to emulate with in-process waits. Although ntsync has been in development for some time, I have regrettably failed to notice these problems until now. Fortunately, none of these behaviours happen on modern Windows. Although I/O on unbound handles delegates to the console of the current process, the signaled state does not. As the tests here show, the signaled state of a handle depends on the active console of the process in which the handle was created. If that console no longer exists, the signaled state is no longer updated [with one rather inexplicable exception]. Crucially, in current Windows waits never fail, and the state of an object is the same across all process which hold handles to it. Therefore this patch brings our behaviour to closer match current Windows. In theory these are fds and should use default_fd_signaled(). However, the points at which the handles are signaled are completely different, and I/O does not trigger console handles to become signaled when it normally would. Therefore for the time being I've kept the code using custom signaled ops. There is one other oddity related to consoles, which is the existence of console_add_queue(), which seeks to lazily create an input thread when a console is first waited on. This is one out of two places, after this patch, when the wait process is hijacked (the other being message queues). Fortunately this is easy to handle for in-process synchronization objects, by queueing the ioctl from the callback used to retrieve the in-process synchronization object itself. -- v3: server: Track unbound output signaled state based on its original console. server: Track unbound input signaled state based on its original console. server: Allow waiting on an orphaned screen buffer. server: Use a list of screen buffers per console. https://gitlab.winehq.org/wine/wine/-/merge_requests/7608

3 7

[PATCH 0/1] MR7629: winex11: Use -1 as fullscreen monitor indices to clear the property.
by Rémi Bernon (＠rbernon) 21 Mar '25

21 Mar '25

This property is the only way to move fullscreen windows across monitors with KWin, it needs to be set to avoid having to mess with _NET_WM_STATE workarounds. Both KWin and Mutter support cases with invalid indices and treat them mostly the same as clearing the property. For Mutter, see: * meta_x11_display_xinerama_index_to_logical_monitor[1] * meta_window_update_fullscreen_monitors[2] * meta_window_clear_fullscreen_monitors[3] For KWin, see: * NETFullscreenMonitors structure from KWindowSystem[4], * xineramaIndexToOutput[5] * fullscreenMonitorArea[6] Mostly reverts 70c9239cb2eef696eea109f3f8e7a58f80cd3823. [1] https://gitlab.gnome.org/GNOME/mutter/-/blob/9a1fa7e13b5feefb76902287ae7ca2… [2] https://gitlab.gnome.org/GNOME/mutter/-/blob/9a1fa7e13b5feefb76902287ae7ca2… [3] https://gitlab.gnome.org/GNOME/mutter/-/blob/9a1fa7e13b5feefb76902287ae7ca2… [4] https://github.com/KDE/kwindowsystem/blob/1399ec9c2f05107c36bc8661593df35ba… [5] https://invent.kde.org/plasma/kwin/-/blob/b488f3b6c6200aca9fa1f61cbf0253eed… [6] https://invent.kde.org/plasma/kwin/-/blob/b488f3b6c6200aca9fa1f61cbf0253eed… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7629

3 6

[PATCH 0/3] MR7590: light.msstyles: Introduce a CSS file to isolate colors from shapes.
by Stefan Dösinger (＠stefan) 21 Mar '25

21 Mar '25

The goal is to make it somewhat easier to define different color schemes. This MR should not result in any changes to the generated bitmap files. Many more will follow over time for all the other color values used in the SVG files. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7590

3 13

Re: [PATCH v2 0/5] MR7631: server: Clarify between effective thread priority and class/level. - approved
by Alexandre Julliard (＠julliard) 20 Mar '25

20 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7631

1 0

Re: [PATCH v2 0/1] MR7609: ntoskrnl.exe: Implement MmMapLockedPages. - approved
by Alexandre Julliard (＠julliard) 20 Mar '25

20 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7609

1 0

Re: [PATCH v2 0/1] MR7620: Shcore: Implement OS_TABLETPC and OS_MEDIACENTER - approved
by Alexandre Julliard (＠julliard) 20 Mar '25

20 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7620

1 0

Re: [PATCH v5 0/8] MR7597: wintypes: Implement IBufferByteAccess::Buffer(). - approved
by Alexandre Julliard (＠julliard) 20 Mar '25

20 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7597

1 0

Re: [PATCH v2 0/1] MR7628: win32u: Return 0 from NtUserGetKeyNameText if there is no translation. - approved
by Alexandre Julliard (＠julliard) 20 Mar '25

20 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7628

1 0

Re: [PATCH v3 0/4] MR7577: d3dx9: Implement D3DXSaveVolumeToFile{A,W,InMemory}(). - approved
by Alexandre Julliard (＠julliard) 20 Mar '25

20 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7577

1 0

Re: [PATCH v2 0/1] MR7617: wpcap: Implement pcap_set_immediate_mode - approved
by Alexandre Julliard (＠julliard) 20 Mar '25

20 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7617

1 0

[PATCH v2 0/5] MR7608: server: Avoid delegating console waits to other objects.
by Elizabeth Figura (＠zfigura) 20 Mar '25

20 Mar '25

Some console objects currently do several unique things: * Delegate waits onto the queue of another object. This is not really a problem for in-process waits, since we can just return the sync object for the delegate. However, it's also unnecessary, adds to the complexity of the server logic, and is one out of one places where this is done. * Make the wait state dependent on the process. This is difficult to emulate with ntsync and would require creating separate server objects for each process, hacking into duplicate_handle. * Fail a wait entirely in certain circumstances. This is pretty much impossible to emulate with in-process waits. Although ntsync has been in development for some time, I have regrettably failed to notice these problems until now. Fortunately, none of these behaviours happen on modern Windows. Although I/O on unbound handles delegates to the console of the current process, the signaled state does not. As the tests here show, the signaled state of a handle depends on the active console of the process in which the handle was created. If that console no longer exists, the signaled state is no longer updated [with one rather inexplicable exception]. Crucially, in current Windows waits never fail, and the state of an object is the same across all process which hold handles to it. Therefore this patch brings our behaviour to closer match current Windows. In theory these are fds and should use default_fd_signaled(). However, the points at which the handles are signaled are completely different, and I/O does not trigger console handles to become signaled when it normally would. Therefore for the time being I've kept the code using custom signaled ops. There is one other oddity related to consoles, which is the existence of console_add_queue(), which seeks to lazily create an input thread when a console is first waited on. This is one out of two places, after this patch, when the wait process is hijacked (the other being message queues). Fortunately this is easy to handle for in-process synchronization objects, by queueing the ioctl from the callback used to retrieve the in-process synchronization object itself. -- v2: server: Track unbound output signaled state based on its original console. server: Track unbound input signaled state based on its original console. server: Allow waiting on an orphaned screen buffer. server: Fail to create an unbound input/output when there is no console. kernel32/tests: Add more tests for orphaned console handles. https://gitlab.winehq.org/wine/wine/-/merge_requests/7608

3 11

[PATCH 0/5] MR7631: server: Clarify between effective thread priority and class/level.
by Rémi Bernon (＠rbernon) 20 Mar '25

20 Mar '25

Split from https://gitlab.winehq.org/wine/wine/-/merge_requests/7516, with some minor tweaks and putting the tests first. I'll send more adjustments for the rest after. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7631

2 6

[PATCH 0/1] MR7628: win32u: Return 0 from NtUserGetKeyNameText if there is no translation.
by Attila Fidan (＠atticf) 20 Mar '25

20 Mar '25

The Kirikiri Z [menu](https://github.com/krkrz/menu/blob/master/Main.cpp) plugin causes an exception to be raised (and the engine unloads the DLL) if GetKeyNameText returns a length of 1 with a null character. The affected applications later fail with script exception dialogs as menu.dll was unloaded. When using winex11 (and presumably winemac), the function returns the return value of the driver function for GetKeyNameText, and that returns 0 on an unsupported key which works. On winewayland (and the null driver), that isn't implemented, and instead the function continues and calls NtUserMapVirtualKeyEx with MAPVK_VK_TO_CHAR filling the buffer with one character which is 0 (no translation). The function then returns 1 for that null character and the applications don't seem to handle that well. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7628

3 2

[PATCH v13 0/3] MR7542: ws2_32: Implement WSALookupService for Bluetooth device discovery.
by Vibhav Pant (＠vibhavp) 20 Mar '25

20 Mar '25

This MR adds an initial implementation of the winsock `WSALookupsService*` methods for performing Bluetooth device discovery (`LUP_CONTAINERS`). Pending !7472, the code will also eventually support performing device inquiry scans. -- v13: ws2_32: Implement WSALookupServiceNext for Bluetooth device discovery. ws2_32: Implement WSALookupServiceBegin for Bluetooth device discovery. ws2_32/tests: Add tests for Bluetooth device discovery in WSALookupServiceBegin/Next. https://gitlab.winehq.org/wine/wine/-/merge_requests/7542

2 3

[PATCH 0/1] MR7534: ws2_32/tests: Add additional invalid parameter tests for WSALookupServiceBegin.
by Vibhav Pant (＠vibhavp) 20 Mar '25

20 Mar '25

WSALokkupServiceBegin fails with WSAEFAULT when provided with bad pointers to the query set or lookup handle parameters. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7534

2 2

[PATCH 0/5] MR7630: winebth.sys part 7: Introduce support for authentication/pairing.
by Vibhav Pant (＠vibhavp) 20 Mar '25

20 Mar '25

Introduce infrastructure necessary to support receiving, sending and replying (to) Bluetooth authentication/pairing requests: - During startup, the Bluetooth driver now creates a "pairing agent" and registers it with BlueZ. The pairing agent is a DBus object implementing the `org.bluez.Agent1` interface (documented [here](https://github.com/bluez/bluez/blob/master/doc/org.bluez.Agent.rst)), which receives authentication requests from BlueZ. The pairing agent then forwards the request data to the PE driver, in form of a `WINEBLUETOOTH_EVENT_AUTH_EVENT` event. The agent is unregistered during driver shutdown. - Right now, the agent only supports Numeric Comparison pairing requests. - Create a new auxiliary device, `\??\WINEBTHAUTH` during driver startup. This device handles authentication functionality that is independent of radio PDOs on the system, which allows the userspace APIs to not track individual Bluetooth radio objects to implement authentication. `WINEBTHAUTH` right now serves two purposes: - Serve as the device object for which `GUID_WINEBTH_AUTHENTICATION_REQUEST` PnP events are broadcasted. This event is sent whenever the Bluetooth event loop in (`bluetooth_event_loop_thread_proc`) receives `WINEBLUETOOTH_EVENT_AUTH_EVENT`. The event's buffer contains a `struct winebth_authentication_request` value, which contains data relevant to the incoming auth request. - Handle the `IOCTL_WINEBTH_AUTH_REGISTER` IOCTL. This simply calls the [`RequestDefaultAgent` BlueZ method](https://github.com/bluez/bluez/blob/master/doc/org.bluez.AgentManag… right now, which asks BlueZ to send all incoming Bluetooth authentication requests to Wine's pairing agent (described above). This is not always strictly necessary, but is useful if there already is a default pairing agent set. - `WINEBTHAUTH` will also ultimately be in charge of responding to authentication requests, which I'll be adding in the next-ish MR(s). - Implement `BluetoothRegisterForAuthenticationEx` and `BluetoothUnregisterAuthentication`. Registration is done by invoking `IOCTL_WINEBTH_AUTH_REGISTER`, and then listening for `GUID_WINEBTH_AUTHENTICATION_REQUEST` events on a `HANDLE` to `\??\WINEBTHAUTH` using the newly added `CM_Register_Notifications`. To keep the MR from getting any larger, I have not included support for `BluetoothSendAuthenticationResponseEx`. That will likely be introduced in the future. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7630

2 5

[PATCH v2 0/1] MR7181: winex11: Avoid creating windows with override-redirect flag set.
by Rémi Bernon (＠rbernon) 20 Mar '25

20 Mar '25

This confuses mutter and it manifests with spurious IconicState WM_STATE change when it decides to try managing the window, but it also makes it randomly lose focus or even fail to map the window back on screen. Adding the flag after the window has been created fixes the issue. -- v2: winex11: Avoid creating windows with override-redirect flag set. https://gitlab.winehq.org/wine/wine/-/merge_requests/7181

3 6

[PATCH v2 0/4] MR7577: d3dx9: Implement D3DXSaveVolumeToFile{A,W,InMemory}().
by Connor McAdams (＠cmcadams) 20 Mar '25

20 Mar '25

After this there is one more set of patches to finish up the file saving functions, I split it into two to hopefully make it easier to review. :) -- v2: d3dx9: Use D3DXSaveVolumeToFileInMemory() inside of D3DXSaveTextureToFileInMemory(). d3dx9: Implement D3DXSaveVolumeToFile{A,W,InMemory}(). d3dx9/tests: Add tests for D3DXSaveVolumeToFile{A,W,InMemory}(). d3dx9: Add stubs for D3DXSaveVolumeToFile{A,W,InMemory}(). https://gitlab.winehq.org/wine/wine/-/merge_requests/7577

3 16

[PATCH v3 0/2] MR7563: mf/tests: Tests timestamp values on output samples from the H.264 and WMV MFT decoders.
by Brendan McGrath (＠redmcg) 20 Mar '25

20 Mar '25

These tests serve to illustrate the output sample time and duration values from their respective native MFT video decoders with respect to the following circumstances: 1. When no frame rate nor input sample timestamps are provided; 2. When a frame rate is provided but there are no sample timestamps; and 3. When a frame rate is provided, but the input sample timestamps disagree with this value It also highlights the gap in our implementation. However, I don't believe this can be fixed without first confirming the correct output from our IMFMediaStream implementations. -- v3: mf/tests: Test timestamps in WMV decoder. mf/tests: Test timestamps in H264 decoder. https://gitlab.winehq.org/wine/wine/-/merge_requests/7563

3 3

[PATCH 0/1] MR7617: wpcap: Implement pcap_set_immediate_mode
by Ellington Santos (necropresto) (＠ellingtonsantos) 20 Mar '25

20 Mar '25

Implement missing wpcap pcap_set_immediate_mode -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7617

3 2

[PATCH 0/1] MR7626: winex11: Use the current state when deciding how to reply to WM_TAKE_FOCUS.
by Rémi Bernon (＠rbernon) 20 Mar '25

20 Mar '25

The Win32 state might not have been updated with the latest X11 state, and we want to take future updates into account when deciding to accept focus or not. At this point, and because we ignore WM_TAKE_FOCUS when a state change is pending, all the states are the same, we use current_state as the logic is to accept focus or not according to our current understanding of the X state. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7626

2 1

[PATCH 0/1] MR7625: winex11: Use the state tracker for the desktop window _NET_WM_STATE.
by Rémi Bernon (＠rbernon) 20 Mar '25

20 Mar '25

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

2 1

[PATCH v4 0/8] MR7597: wintypes: Implement IBufferByteAccess::Buffer().
by Mohamad Al-Jaf (＠maljaf) 20 Mar '25

20 Mar '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55759 -- v4: wintypes: Implement IBufferByteAccess::Buffer(). wintypes/tests: Add IBufferByteAccess::Buffer() tests. wintypes: Add IBufferByteAccess stub. wintypes: Implement IBuffer::get_Length(). wintypes: Implement IBuffer::put_Length(). wintypes: Implement IBuffer::get_Capacity(). wintypes: Implement IBufferFactory::Create(). wintypes/tests: Add IBufferFactory::Create() tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/7597

3 10

[PATCH v4 0/5] MR7466: mf: Fix some issues with seeking.
by Conor McCarthy (＠cmccarthy) 20 Mar '25

20 Mar '25

This fixes failure to play the prologue video in Planet of the Apes: Last Frontier, which unpauses by calling Start() with a location. The exact state leading to this issue does not occur in the Start() tests, and it's not clear how to reproduce it reliably. -- v4: mf: Reset transform nodes when seeking. mf: Initialise the grabber sample count when setting state after a seek. mf: Reset transform node outputs when seeking. mf: Drop transform node input events when unpausing at a specific position. https://gitlab.winehq.org/wine/wine/-/merge_requests/7466

2 6

[PATCH v3 0/5] MR7466: mf: Fix some issues with seeking.
by Conor McCarthy (＠cmccarthy) 20 Mar '25

20 Mar '25

This fixes failure to play the prologue video in Planet of the Apes: Last Frontier, which unpauses by calling Start() with a location. The exact state leading to this issue does not occur in the Start() tests, and it's not clear how to reproduce it reliably. -- v3: mf: Reset transform nodes when seeking. mf: Initialise the grabber sample count when setting state after a seek. mf: Reset transform node outputs when seeking. mf: Drop transform node input events when unpausing at a specific position. https://gitlab.winehq.org/wine/wine/-/merge_requests/7466

2 5

[PATCH 0/1] MR7624: qcap: Check the subtype of video format.
by Haoyang Chen (＠chenhaoyang) 20 Mar '25

20 Mar '25

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

2 1

[PATCH 0/3] MR7623: Draft: winegstreamer: Use provided PTS and duration in video_decoder.
by Brendan McGrath (＠redmcg) 20 Mar '25

20 Mar '25

This MR modifies winegstreamer to match Windows behaviour in that: 1. the video decoders will output the PTS and duration of the input sample (if provided); and 2. the WMV decoder will set any value not provided to zero It also adds support for supplying a DTS value to the MFTs. I've marked this as draft as it fixes the tests in MR !7563 (in addition to fixing some existing `test_wmv_decoder` tests). Also, as demonstrated in MR !7569, our demuxers output different timestamps to Windows. This change will result in those different timestamps being forwarded from the decoder. So we may also want to address that difference prior to accepting this MR. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623

2 3

[PATCH 0/1] MR7621: win32u: Default to exit when tracking top menu
by YuriK7 (＠riyu12383) 20 Mar '25

20 Mar '25

Split from https://gitlab.winehq.org/wine/wine/-/merge_requests/6199. Implements a behavior observed in https://bugs.winehq.org/show_bug.cgi?id=55336. Pressing the Alt key opens the alt key menu. Pressing any non-menu-related just after button will exit it. However if navigating in the menu, then it won't, as it only happens on the top menu. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7621

2 1

Re: [PATCH v12 0/1] MR6199: winewayland.drv: Fix alt-tabbing out opening the alt key menu
by YuriK7 (＠riyu12383) 19 Mar '25

19 Mar '25

I have split this merged so that this mr is completely related to winewyaland and just a one liner. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6199#note_98482

1 0

[PATCH 0/1] MR7620: Shcore: Implement OS_TABLETPC and OS_MEDIACENTER
by Anders Kjersem (＠anders) 19 Mar '25

19 Mar '25

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

2 1

Re: [PATCH v2 0/1] MR7616: win32u: Fix alpha blending in X11DRV_UpdateLayeredWindow. - approved
by Alexandre Julliard (＠julliard) 19 Mar '25

19 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7616

1 0

Re: [PATCH v2 0/8] MR7614: hidclass: Fix some possible crash when devices are unplugged. - approved
by Alexandre Julliard (＠julliard) 19 Mar '25

19 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7614

1 0

Re: [PATCH v2 0/5] MR7615: cfgmgr32: Implement CM_Register_Notification and CM_Unregister_Notification. - approved
by Alexandre Julliard (＠julliard) 19 Mar '25

19 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7615

1 0

Re: [PATCH v2 0/4] MR7612: PDB rewrite #4. - approved
by Alexandre Julliard (＠julliard) 19 Mar '25

19 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7612

1 0

Re: [PATCH v2 0/4] MR7613: winewayland: Clipboard support through core wl_data_device - approved
by Alexandre Julliard (＠julliard) 19 Mar '25

19 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7613

1 0

Re: [PATCH v2 0/1] MR7611: odbc32: Pass through result length pointers when PE/Unix pointer sizes are equal. - approved
by Alexandre Julliard (＠julliard) 19 Mar '25

19 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7611

1 0

Re: [PATCH v3 0/2] MR7606: user32/edit: Block key input when mouse input is captured. - approved
by Alexandre Julliard (＠julliard) 19 Mar '25

19 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7606

1 0

[PATCH v7 0/5] MR7610: Draft: win32u: Create a shared object for user handle entries.
by Rémi Bernon (＠rbernon) 19 Mar '25

19 Mar '25

For https://gitlab.winehq.org/wine/wine/-/merge_requests/7512 to use it to locate window shared objects. -- v7: win32u: Use the session shared object to implement is_window. win32u: Use the session shared object for user handle entries. server: Move the user object handle table to the shared memory. server: Use NTUSER_OBJ constants for user object types. server: Create a shared memory object for the global session. https://gitlab.winehq.org/wine/wine/-/merge_requests/7610

2 5

[PATCH v6 0/5] MR7610: Draft: win32u: Create a shared object for user handle entries.
by Rémi Bernon (＠rbernon) 19 Mar '25

19 Mar '25

For https://gitlab.winehq.org/wine/wine/-/merge_requests/7512 to use it to locate window shared objects. -- v6: win32u: Use the session shared object to implement is_window. win32u: Use the session shared object for user handle entries. server: Move the user object handle table to the shared memory. server: Use NTUSER_OBJ constants for user object types. server: Create a shared memory object for the global session. https://gitlab.winehq.org/wine/wine/-/merge_requests/7610

2 5

[PATCH v7 0/1] MR5145: opengl32: speed up wow64 mapping
by Etaash Mathamsetty (＠etaash.mathamsetty) 19 Mar '25

19 Mar '25

My hardware is Ryzen 7 4700u with the integrated graphics Flatout (Direct3D 9): 20 fps (renders correctly) Unigine Heaven (OpenGL): ~40-60 fps (renders correctly) Unigine Heaven (Direct3D 9): 20-30 fps (renders correctly) Unigine Heaven (Direct3D 11): 20-30 fps as well (renders correctly) Elder Scrolls IV (Direct3D 9): 20 fps (renders correctly) BeamNG Tech Demo 0.3 (Direct3D 9): 2 fps (renders correctly, but still runs poorly) Massive step up from getting 2 fps across many wined3d games, but it's still pretty bad, ~~and sometimes runs worse than the original code~~. Now with a combination of using the new and old code dynamically you can get the best of both worlds! Unfortunately, we lose the ability to get lucky with the mapping just happening to be in the 32 bit range. -- v7: opengl32: speed up wow64 mapping. https://gitlab.winehq.org/wine/wine/-/merge_requests/5145

5 6

[PATCH v4 0/1] MR7344: winex11: Fix alpha blending in X11DRV_UpdateLayeredWindow.
by Dmitry Timoshkov (＠dmitry) 19 Mar '25

19 Mar '25

Original patch description https://www.winehq.org/pipermail/wine-patches/2017-February/157574.html winehq.org no longer provides the wine-patches archives, so it's necessary to dig into [web.archive.org](https://web.archive.org/web/20211011014926/https://www.win…: https://web.archive.org/web/20211011014926/https://www.winehq.org/pipermail… https://web.archive.org/web/20211011014930/https://www.winehq.org/pipermail… =================================================================== Based on a patch by Dmitry Timoshkov. ## Signed-off-by: Sebastian Lackner sebastian(a)fds-team.de Fixes https://bugs.winehq.org/show_bug.cgi?id=33943. Battle.Net initially creates completely transparent popup windows and afterwards uses UpdateLayeredWindow without hdcSrc to let them fade in. Testing confirms that this works fine on Windows - on Wine however the original content is lost and no longer available. To avoid that, this patch stores the original content in the surface and uses \_NET_WM_WINDOW_OPACITY to create a transparency effect. The same method is already used by SetLayeredWindowAttributes. If compositing is disabled, the window content will be visible immediately. Dmitrys original patch used a different approach, and manually implemented the alpha blending in x11drv_surface_flush using additional buffers, however this shouldn't really be necessary (yet). We can still use it later if there is any benefit compared to using \_NET_WM_WINDOW_OPACITY. -- v4: winex11: Fix alpha blending in X11DRV_UpdateLayeredWindow. https://gitlab.winehq.org/wine/wine/-/merge_requests/7344

3 4

[PATCH 0/1] MR7616: win32u: Fix alpha blending in X11DRV_UpdateLayeredWindow.
by Rémi Bernon (＠rbernon) 19 Mar '25

19 Mar '25

Based on a patch by Dmitry Timoshkov. Supersedes https://gitlab.winehq.org/wine/wine/-/merge_requests/7344 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7616

3 3

[PATCH v11 0/3] MR7542: ws2_32: Implement WSALookupService for Bluetooth device discovery.
by Vibhav Pant (＠vibhavp) 19 Mar '25

19 Mar '25

This MR adds an initial implementation of the winsock `WSALookupsService*` methods for performing Bluetooth device discovery (`LUP_CONTAINERS`). Pending !7472, the code will also eventually support performing device inquiry scans. -- v11: ws2_32: Implement WSALookupServiceNext for Bluetooth device discovery. ws2_32: Implement WSALookupServiceBegin for Bluetooth device discovery. ws2_32/tests: Add tests for Bluetooth device discovery in WSALookupServiceBegin/Next. https://gitlab.winehq.org/wine/wine/-/merge_requests/7542

2 3

[PATCH v10 0/3] MR7542: ws2_32: Implement WSALookupService for Bluetooth device discovery.
by Vibhav Pant (＠vibhavp) 19 Mar '25

19 Mar '25

This MR adds an initial implementation of the winsock `WSALookupsService*` methods for performing Bluetooth device discovery (`LUP_CONTAINERS`). Pending !7472, the code will also eventually support performing device inquiry scans. -- v10: ws2_32: Implement WSALookupServiceNext for Bluetooth device discovery. ws2_32: Implement WSALookupServiceBegin for Bluetooth device discovery. ws2_32/tests: Add tests for Bluetooth device discovery in WSALookupServiceBegin/Next. https://gitlab.winehq.org/wine/wine/-/merge_requests/7542

3 8

[PATCH v5 0/5] MR7610: Draft: win32u: Create a shared object for user handle entries.
by Rémi Bernon (＠rbernon) 19 Mar '25

19 Mar '25

For https://gitlab.winehq.org/wine/wine/-/merge_requests/7512 to use it to locate window shared objects. -- v5: win32u: Use the session shared object to implement is_window. win32u: Use the session shared object for user handle entries. server: Move the user object handle table to the shared memory. server: Use NTUSER_OBJ constants for user object types. server: Create a shared memory object for the global session. https://gitlab.winehq.org/wine/wine/-/merge_requests/7610

2 5

[PATCH 0/5] MR7615: cfgmgr32: Implement CM_Register_Notification and CM_Unregister_Notification.
by Rémi Bernon (＠rbernon) 19 Mar '25

19 Mar '25

Supersedes https://gitlab.winehq.org/wine/wine/-/merge_requests/7559 with couple of additional tests and fixes. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7615

3 9

[PATCH v4 0/5] MR7559: cfgmgr32: Implement CM_Register_Notification and CM_Unregister_Notification.
by Vibhav Pant (＠vibhavp) 19 Mar '25

19 Mar '25

The methods are needed to implement Bluetooth device pairing in `bluetoothapis.dll` without having to create a dummy window for `RegisterDeviceNotification`, as that may break CLI applications. `CM_Register_Notification` is implemented as a thin wrapper over `I_ScRegisterDeviceNotification`, mapping `DBT_*` flags to their associated `CM_NOTIFY_*` constants. -- v4: user32: Remove incorrect FIXME warning while registering for DBT_DEVTYP_HANDLE notifications. cfgmgr32: Implement CM_Register_Notification and CM_Unregister_Notification. dinput/tests: Add tests for CM_Register_Notification. https://gitlab.winehq.org/wine/wine/-/merge_requests/7559

2 7

[PATCH v4 0/5] MR7610: Draft: win32u: Create a shared object for user handle entries.
by Rémi Bernon (＠rbernon) 19 Mar '25

19 Mar '25

For https://gitlab.winehq.org/wine/wine/-/merge_requests/7512 to use it to locate window shared objects. -- v4: win32u: Use the session shared object to implement is_window. win32u: Use the session shared object for user handle entries. server: Move the user object handle table to the shared memory. server: Use NTUSER_OBJ constants for user object types. server: Create a shared memory object for the global session. https://gitlab.winehq.org/wine/wine/-/merge_requests/7610

2 5

[PATCH v8 0/15] MR7516: Server-side thread priorities implementation (Part 3)
by Marc-Aurel Zent (＠mzent) 19 Mar '25

19 Mar '25

This is the continuation of https://gitlab.winehq.org/wine/wine/-/merge_requests/7317. There are a lot of smaller commits (some even no-op renames), because there are some inconsistencies in the codebase currently of what an NT thread priority vs a base thread priority should be (or even constant names being wrong), and I hope that this clears that up a bit. I tried making the commits as atomic as possible. I hope this is fine... There are still a few tiny details missing, like boosting and `KeSetPriorityThread` and friends, which are either stubs or not correctly working as well and have been moved to the next part. I wrote a pretty extensive test for all this too, since pretty much none of how this works is documented (or even misrepresented quite often). For testing, thread priority boosting has been disabled in order to make the behavior on Windows not flaky and dynamic. In fact, on Windows, there is some thread priority boost decay going on after the message has been processed and other mechanisms. The `last` field of `get_thread_info` reply was moved to a flag in order to make space for the thread base priority, since it is already at the limit of 64 bytes. -- v8: ntdll/tests: Add tests for process and thread priority. server, ntdll: Fetch both process priority and base_priority. server: Add process base priority helper. kernelbase: Use ProcessPriorityClass info class in GetPriorityClass. kernelbase: Use correct priority in GetThreadPriority. server, ntdll: Fetch both thread priority and base_priority. server, ntdll: Move last thread information to get_thread_info flags. ntdll: Implement ThreadPriority class in NtSetInformationThread. server: Implement setting thread priority directly. server: Add set_thread_priority helper. server: Rename thread priority to base_priority. server: Rename base_priority to effective_priority in apply_thread_priority. server: Infer process priority class in set_thread_priority. include: Use correct PROCESS_PRIORITY_CLASS_* names. include: Add thread priority constants. https://gitlab.winehq.org/wine/wine/-/merge_requests/7516

3 17

[PATCH 0/8] MR7614: hidclass: Fix some possible crash when devices are unplugged.
by Rémi Bernon (＠rbernon) 19 Mar '25

19 Mar '25

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

2 8

[PATCH 0/4] MR7613: winewayland: Clipboard support through core wl_data_device
by Alexandros Frantzis (＠afrantzis) 19 Mar '25

19 Mar '25

This MR adds a fallback path that implements clipboard support using the core protocol (wl_data_device) when wlr-data-control-unstable-v1 is missing. The reasons we want this fallback path, in spite of the extra complexity it introduces, are: 1. Some compositors don't (and likely won't ever) support {wlr,ext}-data-control-unstable-v1. 2. Even compositors that do support {wlr,ext}-data-control-unstable-v1, may not expose it to sandboxed applications. This MR allows Wine to support clipboard operations in such scenarios, in a way that's good enough for many common user clipboard interactions. A more comprehensive discussion of the limitations can be found in !7236. This MR differs from !7236 in that it creates a per-process clipboard thread and window, instead of using the desktop process clipboard thread and manually forwarding messages. Note that the per-process clipboard threads/windows are created only if we fall back to wl_data_device. In the wlr-data-control-unstable-v1 case nothing changes, we still use the desktop process clipboard thread as before. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7613

2 4

Re: [PATCH v7 0/15] MR7516: Server-side thread priorities implementation (Part 3)
by Marc-Aurel Zent (＠mzent) 19 Mar '25

19 Mar '25

On Tue Mar 18 15:03:51 2025 +0000, Rémi Bernon wrote: > I haven't found neither the PROCESS_PRIOCLASS nor the > PROCESS_PRIORITY_CLASS constants in the SDK headers, where are you > seeing them? I was originally looking into that since the reported process base priority was not matching what windows reported and they were set to these values, so I thought they were wrong (which turned out to be not true for a different reason...). In any case, [System Informer](https://systeminformer.sourceforge.io), which is luckily open-source and MIT licensed, displays them like so: ``` static CONST PH_KEY_VALUE_PAIR ProcessPriorityClassTypePairs[] = { SIP(SREF(L"Unknown"), PROCESS_PRIORITY_CLASS_UNKNOWN), SIP(SREF(L"Idle"), PROCESS_PRIORITY_CLASS_IDLE), SIP(SREF(L"Normal"), PROCESS_PRIORITY_CLASS_NORMAL), SIP(SREF(L"High"), PROCESS_PRIORITY_CLASS_HIGH), SIP(SREF(L"Real time"), PROCESS_PRIORITY_CLASS_REALTIME), SIP(SREF(L"Below normal"), PROCESS_PRIORITY_CLASS_BELOW_NORMAL), SIP(SREF(L"Above normal"), PROCESS_PRIORITY_CLASS_ABOVE_NORMAL), }; ``` A quick GitHub code search shows that these are used like so in a wide range of projects, whereas the current Wine naming of `PROCESS_PROCLASS_*` is basically only used by Wine. This also adds the unknown case and starts from `0`, which are both nice-to-haves, and leads me to believe that this is also the original private API naming scheme. If this is still not worth it to do, I can also just drop the commit as well. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7516#note_98393

1 0

[PATCH 0/4] MR7612: PDB rewrite #4.
by eric pouech (＠epo) 19 Mar '25

19 Mar '25

Main target of this serie is to support properly the SYMOPT_LOAD_LINES option flag to dbghelp (turning it off can save some memory). Adding support for 128bit integers in PDB base types, and silencing some more types. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7612

2 4

[PATCH 0/1] MR7611: odbc32: Pass through result length pointers when PE/Unix pointer sizes are equal.
by Hans Leidekker (＠hans) 19 Mar '25

19 Mar '25

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

2 1

[PATCH v3 0/5] MR7610: win32u: Create a shared object for user handle entries.
by Rémi Bernon (＠rbernon) 19 Mar '25

19 Mar '25

For https://gitlab.winehq.org/wine/wine/-/merge_requests/7512 to use it to locate window shared objects. -- v3: win32u: Use the session shared object to implement is_window. win32u: Use the session shared object for user handle entries. server: Move the user object handle table to the shared memory. server: Use NTUSER_OBJ constants for user object types. server: Create a shared memory object for the global session. https://gitlab.winehq.org/wine/wine/-/merge_requests/7610

2 5

[PATCH v2 0/5] MR7610: win32u: Create a shared object for user handle entries.
by Rémi Bernon (＠rbernon) 19 Mar '25

19 Mar '25

For https://gitlab.winehq.org/wine/wine/-/merge_requests/7512 to use it to locate window shared objects. -- v2: win32u: Use the session shared object to implement is_window. win32u: Use the session shared object for user handle entries. server: Move the user object handle table to the shared memory. server: Use NTUSER_OBJ constants for user object types. server: Create a shared memory object for the global session. https://gitlab.winehq.org/wine/wine/-/merge_requests/7610

2 5

[PATCH 0/5] MR7610: win32u: Create a shared object for user handle entries.
by Rémi Bernon (＠rbernon) 19 Mar '25

19 Mar '25

For https://gitlab.winehq.org/wine/wine/-/merge_requests/7512 to use it to locate window shared objects. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7610

2 6

[PATCH v12 0/2] MR7607: Draft: win32u: Add stub for NtUserSetAdditionalForegroundBoostProcesses.
by Louis Lenders (＠xe) 19 Mar '25

19 Mar '25

Microsoft Edge worked if windows version is set to win8.1 (or win7) but now crashes in current wine due to this unimplemented function. This patch makes it work again in win8.1 mode; (It's still broken in win10 mode, see https://bugs.winehq.org/show_bug.cgi?id=56378 for more info) -- v12: Fix typo https://gitlab.winehq.org/wine/wine/-/merge_requests/7607

2 2

[PATCH v3 0/8] MR7597: wintypes: Implement IBufferByteAccess::Buffer().
by Mohamad Al-Jaf (＠maljaf) 19 Mar '25

19 Mar '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55759 -- v3: wintypes: Implement IBufferByteAccess::Buffer(). wintypes/tests: Add IBufferByteAccess::Buffer() tests. wintypes: Add IBufferByteAccess stub. wintypes: Implement IBuffer::get_Length(). wintypes: Implement IBuffer::put_Length(). wintypes: Implement IBuffer::get_Capacity(). wintypes: Implement IBufferFactory::Create(). wintypes/tests: Add IBufferFactory::Create() tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/7597

3 9

Re: [PATCH v2 0/8] MR7597: wintypes: Implement IBufferByteAccess::Buffer().
by Mohamad Al-Jaf (＠maljaf) 19 Mar '25

19 Mar '25

On Wed Mar 19 05:07:09 2025 +0000, Mohamad Al-Jaf wrote: > changed this line in [version 2 of the diff](/wine/wine/-/merge_requests/7597/diffs?diff_id=165075&start_sha=0c9df529abfdeb01208ee618b4cb766a0961ba69#d430fdc14e90f656acc7b2f3eb52d29c37bb640f_331_308) That's a better method, thanks. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7597#note_98370

1 0

2025

2024

2023

2022

wine-gitlab