- Wine-gitlab - list.winehq.org

Re: [PATCH v2 0/1] MR10177: ntdll: Fix threadpool timer behavior on system time change. - approved
by Alexandre Julliard (＠julliard) 25 Feb '26

25 Feb '26

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

1 0

Re: [PATCH v2 0/1] MR10185: winemac: Call client_surface_present when OpenGL surface gets presented. - approved
by Alexandre Julliard (＠julliard) 25 Feb '26

25 Feb '26

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

1 0

Re: [PATCH v3 0/6] MR10183: msxml/tests: Extend PI test with newlines. - approved
by Alexandre Julliard (＠julliard) 25 Feb '26

25 Feb '26

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

1 0

[PATCH 0/3] MR10189: kernel32, ntdll: Fix some test failures related to NtQueryDirectoryFile().
by Elizabeth Figura (＠zfigura) 25 Feb '26

25 Feb '26

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

2 3

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

25 Feb '26

On Wed Feb 25 18:54:58 2026 +0000, Paul Gofman wrote: > > I don't really understand why we're doing this in the first place. The > documentation often claims things that are wrong especially as related > to edge cases. If there's not a foreseeable case where RtlGenRandom() > could fail (and I don't think memory exhaustion counts as foreseeable > either) then I don't think it's worth touching. > Yeah. And I honestly don't see how even memory exhaustion is a bad case > here, there is no new allocations on the way. And if page in for > previously allocated buffer space fails the process will be OOM killed > without our abort. There is actually one real thing in that place: > int fd = open( "/dev/urandom", O_RDONLY ); That can fail due to fd exhaustion. But instead of asserting we'd probably be better off caching the fd, file open takes time while getting random values may happen often in some cases (and get_random is used very early for the first time, to fill process cookie). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130526

1 0

[PATCH v3 0/1] MR10187: bcryptprimitives: Ensure ProcessPrng fills the whole buffer
by Christopher Denton (＠cdenton) 25 Feb '26

25 Feb '26

[`ProcessPrng`](https://learn.microsoft.com/en-us/windows/win32/seccng/processprng) takes a `SIZE_T` argument for its length whereas [`RtlGenRandom`](https://learn.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-rtlgenrandom) takes a `ULONG`, which may be smaller. -- v3: bcryptprimitives: Ensure ProcessPrng fills the whole buffer https://gitlab.winehq.org/wine/wine/-/merge_requests/10187

2 1

[PATCH 0/2] MR10188: msxml/tests: Add some more tests for the ownerDocument() property.
by Nikolay Sivov (＠nsivov) 25 Feb '26

25 Feb '26

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10188

2 2

[PATCH 0/1] MR10187: bcryptprimitives: Ensure ProcessPrng fills the whole buffer
by Christopher Denton (＠cdenton) 25 Feb '26

25 Feb '26

[`ProcessPrng`](https://learn.microsoft.com/en-us/windows/win32/seccng/processprng) takes a `SIZE_T` argument for its length whereas [`RtlGenRandom`](https://learn.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-rtlgenrandom) takes a `ULONG`, which may be smaller. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10187

2 1

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

25 Feb '26

> I don't really understand why we're doing this in the first place. The documentation often claims things that are wrong especially as related to edge cases. If there's not a foreseeable case where RtlGenRandom() could fail (and I don't think memory exhaustion counts as foreseeable either) then I don't think it's worth touching. Yeah. And I honestly don't see how even memory exhaustion is a bad case here, there is no new allocations on the way. And if page in for previously allocated buffer space fails the process will be OOM killed without our abort. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130523

1 0

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

25 Feb '26

On Wed Feb 25 18:50:59 2026 +0000, Elizabeth Figura wrote: > I don't really understand why we're doing this in the first place. The > documentation often claims things that are wrong especially as related > to edge cases. If there's not a foreseeable case where RtlGenRandom() > could fail (and I don't think memory exhaustion counts as foreseeable > either) then I don't think it's worth touching. The documentation is right as far as I'm aware and the whitepaper explains that it was an intentional decision that people can rely on. So I do think that wine should behave as close to Windows as reasonably possible. And after looking at it closer I think wine already does exhibit the same behaviour in practice. So I'm coming round to the idea that this doesn't need to be handled in `ProcessPrng`. I am thinking it might be appropriate to more strongly guarantee this at the actual point where we return an error, e.g. https://gitlab.winehq.org/cdenton/wine/-/commit/93ed99966b316f4c9c1e03af7de… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130522

1 0