February 2026 - Wine-GitLab

Re: [PATCH v2 0/1] MR10021: ntdll: Don't fix gsbase on execution fault exception.
by Brendan Shanks (＠bshanks) Feb. 25, 2026

Feb. 25, 2026

Tested and looks good on an Intel Mac (Rosetta doesn't emulate resetting GSBASE on a `pop %gs`) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10021#note_130513

1 0

Re: [PATCH v10 0/2] MR7064: ntdll: Check for invalid GS base in the 64-bit segv_handler.
by Brendan Shanks (＠bshanks) Feb. 25, 2026

Feb. 25, 2026

Also !10021 fixes an infinite loop when an instruction starts in one page and extends into an inaccessible page -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7064#note_130511

1 0

Re: [PATCH v2 0/1] MR10021: ntdll: Don't fix gsbase on execution fault exception. - approved
by Brendan Shanks (＠bshanks) Feb. 25, 2026

Feb. 25, 2026

This merge request was approved by Brendan Shanks. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10021

1 0

Re: [PATCH v7 0/1] MR10174: bcryptprimitives: Abort if `ProcessPrng` fails
by Paul Gofman (＠gofman) Feb. 25, 2026

Feb. 25, 2026

On Wed Feb 25 17:39:43 2026 +0000, Christopher Denton wrote: > Just to clarify something, would you agree that emitting an `ERR` here > makes sense? Even for ERR I'd also think a formally better place for that would be ntdll/unix/system.c:read_dev_urandom() (after checking that read to the requested size actually succeeded). But yet I am still failing to see how that changes anything in practice, the code is not supposed to fail there as well. Maybe assert( ret == len ) in the end of the function (with appropriate move ret definition) would make some sense. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130509

1 0

Re: [PATCH v7 0/1] MR10174: bcryptprimitives: Abort if `ProcessPrng` fails
by Christopher Denton (＠cdenton) Feb. 25, 2026

Feb. 25, 2026

On Wed Feb 25 16:11:00 2026 +0000, Paul Gofman wrote: > This whole discussion is focusing on formal handling of return status, > but is missing the fact that read_dev_urandom() in ntdll (the only place > where something can *theoretically* fail outside of process memory > corruption, inventive hotpatching and such) doesn't have error checking > / return at all. If this is a real concern it would make more sense to > check the result and assert there instead of putting wrong things to the > PE side (while I am personally still not sure about how that is useful > too, reading random bytes is not supposed to fail in Unix the same way > as on Windows, reinforcing that system is not totally broken in some > arbitrary places doesn't look too much useful to me). Just to clarify something, would you agree that emitting an `ERR` here makes sense? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130508

1 0

[PATCH 0/1] MR10186: ntdll: Remove unnecessary strdup call
by Nikola Kuburović Feb. 25, 2026

Feb. 25, 2026

Use the wineloader string directly because execv in preloader_exec only reads it, so there should be no worries about it getting modified. Fix the memory leak that happens because duplicated wineloader string memory isn't freed. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10186

2 3

Re: [PATCH v7 0/1] MR10174: bcryptprimitives: Abort if `ProcessPrng` fails
by Paul Gofman (＠gofman) Feb. 25, 2026

Feb. 25, 2026

On Wed Feb 25 16:00:26 2026 +0000, Christopher Denton wrote: > The point of having an abort in the function is not security in itself. > The aborting code path should never be hit. If it is then it's a bug in > the underlying implementation that should *ideally* be fixed. And if > such a bug does occur then users shouldn't rely on it (even if > unintentionally). So the `abort` ensure the function fulfils the > documented behaviour even if something else goes wrong. This whole discussion is focusing on formal handling of return status, but is missing the fact that read_dev_urandom() in ntdll (the only place where something can *theoretically* fail outside of process memory corruption, inventive hotpatching and such) doesn't have error checking / return at all. If this is a real concern it would make more sense to check the result and assert there instead of putting wrong things to the PE side (while I am personally still not sure about how that is useful too, reading random bytes is not supposed to fail in Unix the same way as on Windows, reinforcing that system is not totally broken in some arbitrary places doesn't look too much useful to me). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130506

1 0

Re: [PATCH v7 0/1] MR10174: bcryptprimitives: Abort if `ProcessPrng` fails
by Christopher Denton (＠cdenton) Feb. 25, 2026

Feb. 25, 2026

On Wed Feb 25 14:26:15 2026 +0000, Paul Gofman wrote: > Note that we can't protect things this way securely anyway. E. g., if > app does random memory access and hits our random data buffer used in > SystemFunction36, this won't be detected by return value check. The point of having an abort in the function is not security in itself. The aborting code path should never be hit. If it is then it's a bug in the underlying implementation that should *ideally* be fixed. And if such a bug does occur then users shouldn't rely on it (even if unintentionally). So the `abort` ensure the function fulfils the documented behaviour even if something else goes wrong. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130505

1 0

[PATCH 0/1] MR10185: winemac: Call client_surface_present when OpenGL surface gets presented.
by Rémi Bernon Feb. 25, 2026

Feb. 25, 2026

Making sure the surface client cocoa frame is associated as the current client frame for the window. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10185

1 1

[PATCH v5 0/3] MR9704: winmm, msvfw32: DGV window shenanigans with audio only files
by Bernhard Kölbl Feb. 25, 2026

Feb. 25, 2026

Basically, check if we can set a HWND in the driver, before doing so. Right now, msvfw32 + mciqtz32 error out on audio only playbacks, breaking the game Transcendence. -- v5: msvfw32: Only attempt to set a digital-video window, when the driver has a window itself. msvfw32/tests: Add a basic audio playback test. https://gitlab.winehq.org/wine/wine/-/merge_requests/9704

1 3