May 2025 - wine-gitlab

[PATCH 0/1] MR7900: d2d1: Compile shaders on device creation instead of device context creation.
by Francisco Casas (＠fcasas) 02 May '25

02 May '25

Some applications generate many device contexts each render frame. Thus, compling these shaders each time this happens might make them laggy. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7900

4 4

[PATCH v8 0/4] MR7885: winebth.sys part 11: Support initiating pairing requests with remote devices.
by Vibhav Pant (＠vibhavp) 02 May '25

02 May '25

Add `IOCTL_WINEBTH_RADIO_START_AUTH`, which gets used to implement `BluetoothAuthenticateDeviceEx`. -- v8: bluetoothapis/tests: Add tests for BluetoothAuthenticateDeviceEx. bluetoothapis: Use a wizard GUI to respond to pairing requests if an authentication callback is not registered. bluetoothapis: Implement BluetoothAuthenticateDeviceEx. https://gitlab.winehq.org/wine/wine/-/merge_requests/7885

3 6

[PATCH v3 0/1] MR7947: ntdll: Make sure NT flag is not set before iretq in wine_syscall_dispatcher_return on x64.
by Paul Gofman (＠gofman) 02 May '25

02 May '25

-- v3: ntdll: Make sure NT flag is not set before iretq in wine_syscall_dispatcher_return on x64. https://gitlab.winehq.org/wine/wine/-/merge_requests/7947

2 2

[PATCH 0/3] MR7889: ntoskrnl.exe/tests: Test that calling some Io functions does not result in...
by Alexander Morozov (＠amorozov) 02 May '25

02 May '25

This is a set of tests to prove the correctness of a fix for bug 57588 which i am going to send in a separate PR. Also a small fix for getting DevicePropertyEnumeratorName is included. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7889

3 4

[PATCH v7 0/1] MR7676: winegstreamer: Make sure WMSyncReader never reads in the background.
by Yuxuan Shui (＠yshui) 02 May '25

02 May '25

WMSyncReader starts a background read thread that reads from the IStream passed to IWMSyncReader::OpenStream. This means it could use the IStream in the background even when no IWMSyncReader methods are being called. For well-behaved applications, this is probably OK. However, AQUARIUM (Steam 2515070) frees the IStream it passes to WMSyncReader _before_ it calls IWMSyncReader::Close, which stops the read thread. This causes the read thread to access freed memory. This is improper, but not unreasonable, as IWMSyncReader is supposed to be a synchronous interface, so one might assume when they weren't calling into IWMSyncReader methods, the IStream won't be used. This commit adds a `wg_parser_dont_read` function, which can be used to stop wg_parser from issuing read requests. This is used by IWMSyncReader to make sure read requests are only issued when IWMSyncReader methods are being called. -- v7: winegstreamer: Make sure WMSyncReader never reads in the background. https://gitlab.winehq.org/wine/wine/-/merge_requests/7676

3 3

[PATCH v2 0/1] MR7824: winegstreamer: Handle the Stream Group Done event.
by Brendan McGrath (＠redmcg) 02 May '25

02 May '25

This event indicates that there will be no more data. Handling it like an EOS fixes a dead lock that occurs when a stream completes. -- v2: winegstreamer: Handle the Stream Group Done event. https://gitlab.winehq.org/wine/wine/-/merge_requests/7824

3 4

[PATCH 0/1] MR7936: netapi32: Fix service names in NetStatisticsGet().
by Paul Gofman (＠gofman) 02 May '25

02 May '25

This fixes Defiant not being able to connect to game servers in game. That regressed because of the apparently accidental change of the service names in commit 1904227cc363e0fed0fc69d038a0902010f9331b. The game depends on at least NetStatisticsGet("LanmanWorkstation") to succeed ("LanmanServer" may fail on Windows as well). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7936

3 2

[PATCH v2 0/1] MR7947: ntdll: Make sure NT flag is not set before iretq in wine_syscall_dispatcher_return on x64.
by Paul Gofman (＠gofman) 02 May '25

02 May '25

-- v2: ntdll: Make sure NT flag is not set before iretq in wine_syscall_dispatcher_return on x64. https://gitlab.winehq.org/wine/wine/-/merge_requests/7947

3 10

[PATCH 0/1] MR7957: gdi32: Fix termination in destination string in logfont_AtoW.
by Bernhard Übelacker (＠bernhardu) 02 May '25

02 May '25

Followup of 1d3bfdc3ab. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7957

2 3

Re: [PATCH v4 0/1] MR7925: gdi32: Limit source string length in logfont_AtoW (ASan).
by Rémi Bernon (＠rbernon) 02 May '25

02 May '25

On Fri May 2 16:52:15 2025 +0000, Alex Henrie wrote: > I apologize for the stupid mistake. !7956 will fix it. Literally two > minutes after I sent it, Bernhard sent an alternative fix in !7957 which > would also be fine. > I recognize that this happened primarily due to human error on my part. > Nevertheless, another part of the problem is that the 32-bit tests > always fail, and somehow this mistake did not cause the 64-bit tests to > fail. That means that I need to spend some time helping with the > intermittent test failures because they're making it too easy for me to > overlook test failures that actually matter. Until the tests can be > expected to pass, I will have to remember to read through the entire > list of failures whenever I send a patch. The test-linux-64 test suite only run a few tests that are otherwise skipped in a old/new wow64 environment like the one used for test-linux-32. It's maybe a bit confusing but it otherwise would use another runner from >30min and it wasn't deemed useful to have a full test coverage run on every config. The test-linux-32 sadly fails often, spuriously, although there have been up and downs I think it's getting better now and hopefully we'll get back to some occasional failures only. Nevertheless, Gitlab now shows a short summary of failing tests (in the MRs "Test summary:" section, which can be expanded for a detailed list of failures) and I think we should be able to quickly check MR failures, and compare with other MRs or the testbot pattern page, to decide whether they are likely related or not. Usually there's only a handful of spurious failures, with some well known returning failures, and a large number of/unusual failures should already still stand out, if we're paying attention. Fwiw I'm not blaming you specifically here, it happens quite often (and I can be blamed for a fair amount the last few months). I'm mostly making sure it doesn't go unnoticed and try to raise awareness. At least as long as things get caught and fixed quickly it's probably fine. Fixing spurious failures would be nice too but that's much more difficult than it seems. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7925#note_102379

1 0

2025

2024

2023

2022

wine-gitlab May 2025