January 2026 - Wine-gitlab - list.winehq.org

Re: [PATCH v7 0/2] MR2044: ntoskrnl.exe: Implement acquiring and releasing guarded mutexes
by Etaash Mathamsetty (＠etaash.mathamsetty) 23 Jan '26

23 Jan '26

On Fri Jan 23 08:55:17 2026 +0000, Colleirose wrote: > To add to my previous post: Endfield is indeed working with the Dawn > Winery patched version, and the patch to prevent the DNA executable from > checking if Wine drivers are signed > (https://dawn.wine/dawn-winery/dwproton/src/branch/main/patches/wine/0003-dn…) > doesn't affect Endfield but the game still works. > As for what @etaash.mathamsetty said, that makes sense - I will probably > work on these if nobody else does but it's fine if someone else wants to > work on it because it'll probably take me a while to make working tests > for these kind of obscure APIs anyway. Here is the original repo they got the patches from: https://github.com/Etaash-mathamsetty/wine-valve.git -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2044#note_127773

1 0

[PATCH 0/1] MR9956: wined3d: Check invalid addresses when copying buffer objects.
by Zhiyi Zhang (＠zhiyi) 23 Jan '26

23 Jan '26

When a thread that created windows is being closed, the destination buffer address address might be NULL. For example: 1. context_gl->internal_format_set is set to 1 in wined3d_context_gl_set_pixel_format(). 2. A thread gets destroyed, all the windows in the thread get destroyed. 3. wined3d_context_gl_set_pixel_format() fails because WindowFromDC() returns NULL. 4. get_dc_pixel_format() fails in win32u_wglMakeContextCurrentARB(). 5. wined3d_buffer_gl_create_buffer_object() fails to create a buffer object. 6. wined3d_buffer_get_memory() returns a struct wined3d_bo_address with addr being NULL. Adding a NULL check in wined3d_context_gl_copy_bo_address() avoids triggering write segfaults when terminating a thread. This could happen for React Native applications. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9956

3 2

[PATCH v8 0/6] MR9646: mf/tests: Scrubbing tests
by Brendan McGrath (＠redmcg) 23 Jan '26

23 Jan '26

This MR adds tests for how scrubbing and rate changes work within the Media Session. -- v8: mf/tests: Check that Rate change in PLAY state is ignored. mf/tests: Test that there is no pre-roll during scrubbing. mf/tests: Fix leaks in test source. mf/tests: Add ClockStateSink to test media sink. mf/tests: Modify test_media_sink to store test_stream_sink. mf/tests: Modify test_seek_clock_sink to be ref counted. https://gitlab.winehq.org/wine/wine/-/merge_requests/9646

3 15

[PATCH v8 0/7] MR9489: mf: Fix seeking within sample grabber.
by Brendan McGrath (＠redmcg) 23 Jan '26

23 Jan '26

This fixes seeking within sample grabber by matching Windows functionality. -- v8: mf/tests: Test sample grabber pause and resume. mf/tests: Check contents of sample collection. mf/tests: Test seek with sample grabber whilst ignoring clock. mf/tests: Test samplegrabber flush then seek. mf/tests: Check StreamSinkMarker event. mf/tests: Test sample grabber {Set,Cancel}Timer. mf/tests: Add test for sample grabber seek. https://gitlab.winehq.org/wine/wine/-/merge_requests/9489

3 15

[PATCH v5 0/1] MR9719: mfmediaengine/tests: Test we receive a frame before calling Play.
by Brendan McGrath (＠redmcg) 23 Jan '26

23 Jan '26

Media Engine on Windows appears to use scrubbing to receive a frame before `IMFMediaEngine::Play` is called. This adds a test to confirm we can receive said frame. -- v5: mfmediaengine/tests: Test we receive a frame before calling Play. https://gitlab.winehq.org/wine/wine/-/merge_requests/9719

3 8

[PATCH 0/7] MR9953: opengl32: Move handle allocation to the PE side.
by Rémi Bernon (＠rbernon) 23 Jan '26

23 Jan '26

Introducing a proper separation of client side / unix side objects, similar to what is done in winevulkan, with client side wrappers which we can later use to store some client-specific information such as client extension list, some strings to avoid bogus wow64 string reuse, etc. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9953

2 7

Re: [PATCH v7 0/2] MR2044: ntoskrnl.exe: Implement acquiring and releasing guarded mutexes
by Colleirose (＠colleirose) 23 Jan '26

23 Jan '26

On Fri Jan 23 05:20:27 2026 +0000, Etaash Mathamsetty wrote: > Most of these are also my patches, and I would upstream them, but I > don't really have the energy to go through and make tests (and correct > my past mistakes) for everything partially because I have no idea how to > get the expected values from windows. I've been spending more time on > winewayland and idk if I will be able to find time to upstream that work > either. So feel free to adapt this code in your own implementation if > you want to. Also, the last time I worked on this a few people got mad > at me (for justified reasons) and I don't really want to touch again To add to my previous post: Endfield is indeed working with the Dawn Winery patched version, and the patch to prevent the DNA executable from checking if Wine drivers are signed (https://dawn.wine/dawn-winery/dwproton/src/branch/main/patches/wine/0003-dn…) doesn't affect Endfield but the game still works. As for what @etaash.mathamsetty said, that makes sense - I will probably work on these if nobody else does but it's fine if someone else wants to work on it because it'll probably take me a while to make working tests for these kind of obscure APIs anyway. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2044#note_127758

1 0

Re: [PATCH v7 0/2] MR2044: ntoskrnl.exe: Implement acquiring and releasing guarded mutexes
by Etaash Mathamsetty (＠etaash.mathamsetty) 23 Jan '26

23 Jan '26

On Fri Jan 23 04:43:11 2026 +0000, Colleirose wrote: > There's several more that AntiCheatExpert requires, you can find a full > list here but some of the patches don't work on their own and have a > subsequent patch that fixes them: > https://dawn.wine/dawn-winery/dwproton/src/branch/main/patches/wine/0003-dna > I've tested that those fix Duet Night Abyss, but I haven't tried them > with other AntiCheatExpert games; I will test them with Endfield > probably later today or tomorrow (I've been downloading Endfield but > have very slow Internet). I spent a bit of time trying to reorganize and > reformat the patches to be compliant with Wine's requirements a day or > two ago but haven't had time to test the changed versions or develop > test cases so I'll need to see later what else is required. > While most of these patches clearly just implement missing functions and > lead to ACE running the same as it does natively, there's also one that > seems to be intended to prevent the anticheat from detecting that the > user is on Wine, > https://dawn.wine/dawn-winery/dwproton/src/branch/main/patches/wine/0003-dn… > which to my understanding is out of scope for normal Wine; I haven't > tried seeing what happens when that particular patch is removed but the > game is run with the others, I will later though. > Notably, other ACE games become more compatible when they detect they > are running under Wine; it seems that there's different versions of ACE > that have different levels of Wine compatibility. Wuthering Waves uses > ACE and their version specifically skips several parts of the anticheat > if it detects the user is using Wine, while the version in Duet Night > Abyss will probe the user's hardware to see if they have a Steam Deck > specifically and disable parts of the anticheat only on Steam Deck > devices. I believe Honkai: Star Rail also had a version of ACE for a > while that was compatible with Linux, though they removed ACE over a > year ago. Honkai Impact 3rd also requires ACE and to my understanding > has been reported as playable but I haven't tested it. > Other games that are broken according to a search on the Valve GitHub > are Infinity Nikki and Fate Trigger: > https://github.com/ValveSoftware/Proton/issues/9258, https://github.com/ValveSoftware/Proton/issues/8988 Most of these are also my patches, and I would upstream them, but I don't really have the energy to go through and make tests (and correct my past mistakes) for everything partially because I have no idea how to get the expected values from windows. I've been spending more time on winewayland and idk if I will be able to find time to upstream that work either. So feel free to adapt this code in your own implementation if you want to. Also, the last time I worked on this a few people got mad at me (for justified reasons) and I don't really want to touch again -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2044#note_127756

1 0

Re: [PATCH v7 0/2] MR2044: ntoskrnl.exe: Implement acquiring and releasing guarded mutexes
by Colleirose (＠colleirose) 23 Jan '26

23 Jan '26

On Thu Jan 22 06:50:56 2026 +0000, Jactry Zeng wrote: > Hi, > Does this series exactly fix the issue and make those games playable? > AFAIU, it is AntiCheatExpert requires these functions, and sometimes > just implementing a couple of functions is far from making the game > playable; what is worse, maybe some other game will become unplayable > because the exposing of these functions guides them to another code path > (e.g. it goes further in the anti-cheat detection) that has issues on Wine. > btw, Arknights: Endfield, which ships AntiCheatExpert, depends on > KeAcquireGuardedMutex() too. There's several more that AntiCheatExpert requires, you can find a full list here but some of the patches don't work on their own and have a subsequent patch that fixes them: https://dawn.wine/dawn-winery/dwproton/src/branch/main/patches/wine/0003-dna I've tested that those fix Duet Night Abyss, but I haven't tried them with other AntiCheatExpert games; I will test them with Endfield probably later today or tomorrow. While most of these patches clearly just implement missing functions and lead to ACE running the same as it does natively, there's also one that seems to be intended to prevent the anticheat from detecting that the user is on Wine, https://dawn.wine/dawn-winery/dwproton/src/branch/main/patches/wine/0003-dn… which to my understanding is out of scope for normal Wine, but notably other ACE games become more compatible when they detect they are running under Wine; it seems that there's different versions of ACE that have different levels of Wine compatibility. Wuthering Waves uses ACE and their version specifically skips several parts of the anticheat if it detects the user is using Wine, while the version in Duet Night Abyss will probe the user's hardware to see if they have a Steam Deck specifically and disable parts of the anticheat only on Steam Deck devices. I believe Honkai: Star Rail also had a version of ACE for a wh ile that was compatible with Linux, though they removed ACE over a year ago. Honkai Impact 3rd also requires ACE and to my understanding has been reported as playable but I haven't tested it. Other games that are broken according to a search on the Valve GitHub are Infinity Nikki and Fate Trigger: https://github.com/ValveSoftware/Proton/issues/9258, https://github.com/ValveSoftware/Proton/issues/8988 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2044#note_127755

1 0

[PATCH v2 0/1] MR9952: ntdll: Add stub function for NtWorkerFactoryWorkerReady().
by Paul Gofman (＠gofman) 22 Jan '26

22 Jan '26

-- v2: ntdll: Add stub function for NtWorkerFactoryWorkerReady(). https://gitlab.winehq.org/wine/wine/-/merge_requests/9952

2 1