- Wine-GitLab - list.winehq.org

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

Feb. 24, 2026

[`ProcessPrng`] is documented as always returning TRUE. So I've modified `ProcessPrng` to abort on errors. This is I believe an import aspect of the function. See Microsoft's [The Windows 10 random number generation infrastructure] whitepaper. > We also have the property that a request for random bytes never fails. In the past our RNG functions could return an error code. We have observed that there are many callers that never check for the error code, even if they are generating cryptographic key material. This can lead to serious security vulnerabilities if an attacker manages to create a situation in which the RNG infrastructure returns an error. For that reason, the Win10 RNG infrastructure will never return an error code and always produce high-quality random bytes for every request. [`ProcessPrng`]: https://learn.microsoft.com/en-us/windows/win32/seccng/processprng [The Windows 10 random number generation infrastructure]: https://www.microsoft.com/en-us/security/blog/2019/11/25/going-in-depth-on-… -- v5: bcryptprimitives: Abort if ProcessPrng fails https://gitlab.winehq.org/wine/wine/-/merge_requests/10174

4 4

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

Feb. 24, 2026

[`ProcessPrng`] is documented as always returning TRUE. So I've modified `ProcessPrng` to abort on errors. This is I believe an import aspect of the function. See Microsoft's [The Windows 10 random number generation infrastructure] whitepaper. > We also have the property that a request for random bytes never fails. In the past our RNG functions could return an error code. We have observed that there are many callers that never check for the error code, even if they are generating cryptographic key material. This can lead to serious security vulnerabilities if an attacker manages to create a situation in which the RNG infrastructure returns an error. For that reason, the Win10 RNG infrastructure will never return an error code and always produce high-quality random bytes for every request. [`ProcessPrng`]: https://learn.microsoft.com/en-us/windows/win32/seccng/processprng [The Windows 10 random number generation infrastructure]: https://www.microsoft.com/en-us/security/blog/2019/11/25/going-in-depth-on-… -- v4: bcryptprimitives: Abort if ProcessPrng fails https://gitlab.winehq.org/wine/wine/-/merge_requests/10174

3 2

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

Feb. 24, 2026

[`ProcessPrng`] is documented as always returning TRUE. So I've modified `ProcessPrng` to abort on errors. This is I believe an import aspect of the function. See Microsoft's [The Windows 10 random number generation infrastructure] whitepaper. > We also have the property that a request for random bytes never fails. In the past our RNG functions could return an error code. We have observed that there are many callers that never check for the error code, even if they are generating cryptographic key material. This can lead to serious security vulnerabilities if an attacker manages to create a situation in which the RNG infrastructure returns an error. For that reason, the Win10 RNG infrastructure will never return an error code and always produce high-quality random bytes for every request. [`ProcessPrng`]: https://learn.microsoft.com/en-us/windows/win32/seccng/processprng [The Windows 10 random number generation infrastructure]: https://www.microsoft.com/en-us/security/blog/2019/11/25/going-in-depth-on-… -- v3: bcryptprimitives: Abort if ProcessPrng fails https://gitlab.winehq.org/wine/wine/-/merge_requests/10174

2 1

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

Feb. 24, 2026

[`ProcessPrng`] is documented as always returning TRUE. So I've modified `ProcessPrng` to abort on errors. This is I believe an import aspect of the function. See Microsoft's [The Windows 10 random number generation infrastructure] whitepaper. > We also have the property that a request for random bytes never fails. In the past our RNG functions could return an error code. We have observed that there are many callers that never check for the error code, even if they are generating cryptographic key material. This can lead to serious security vulnerabilities if an attacker manages to create a situation in which the RNG infrastructure returns an error. For that reason, the Win10 RNG infrastructure will never return an error code and always produce high-quality random bytes for every request. [`ProcessPrng`]: https://learn.microsoft.com/en-us/windows/win32/seccng/processprng [The Windows 10 random number generation infrastructure]: https://www.microsoft.com/en-us/security/blog/2019/11/25/going-in-depth-on-… -- v2: bcryptprimitives: Abort if ProcessPrng fails https://gitlab.winehq.org/wine/wine/-/merge_requests/10174

4 7

[PATCH 0/1] MR10178: compiler-rt: add __ctzdi2 to fix i386 mingw builds
by Maotong Zhang (＠xiaotong) Feb. 24, 2026

Feb. 24, 2026

Commit 8d8d871b switched mingw from -lgcc to compiler-rt. This breaks i386 builds with ccache: Capstone fails to link (AArch64/ARM disassemblers) due to an undefined __ctzdi2 symbol. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10178

2 1

[PATCH 0/1] MR10177: ntdll: Fix threadpool timer behavior on system time change.
by Piotr Caban (＠piotr) Feb. 24, 2026

Feb. 24, 2026

Threadpool timers are not handling system clock changes correctly. Observed while trying to start delayed-start service on DST change (service started after 1h02m instead of 2m). These patch changes threadpool timers to use NtCreateTimers internally. It matches with native implementation as documented here: https://github.com/SafeBreach-Labs/PoolParty. While it moves implementation closer to what native does I didn't work on making it binary compatible. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10177

2 1

[PATCH v2 0/3] MR10175: winmm/tests: Test a curated list of wave formats.
by Giovanni Mascellani (＠giomasce) Feb. 24, 2026

Feb. 24, 2026

This has of course a lot of code in common with the mmdevapi tests, but I don't know what would be a good place to share it. Happy to take suggestions. -- v2: winmm/tests: Test a curated list of wave formats. https://gitlab.winehq.org/wine/wine/-/merge_requests/10175

2 3

[PATCH 0/3] MR10176: cfgmgr32/tests: Tweak the test results for some testbot VMs.
by Rémi Bernon Feb. 24, 2026

Feb. 24, 2026

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

1 3

[PATCH 0/1] MR9988: msvcrt time: add overflow checks for avoiding year 2038 problem
by Herman Semenov (＠GermanAizek) Feb. 24, 2026

Feb. 24, 2026

There have already been type overflow checks in same code time.c, but they are not enough. https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/msvcrt/time.c#L336-3… References: - https://en.wikipedia.org/wiki/Year_2038_problem - https://www.gnu.org/software/gnulib/manual/html_node/Avoiding-the-year-2038… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9988

3 5

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

Feb. 24, 2026

[`ProcessPrng`] is documented as always returning TRUE. So I've modified `ProcessPrng` to abort on errors. This is I believe an import aspect of the function. See Microsoft's [The Windows 10 random number generation infrastructure] whitepaper. > We also have the property that a request for random bytes never fails. In the past our RNG functions could return an error code. We have observed that there are many callers that never check for the error code, even if they are generating cryptographic key material. This can lead to serious security vulnerabilities if an attacker manages to create a situation in which the RNG infrastructure returns an error. For that reason, the Win10 RNG infrastructure will never return an error code and always produce high-quality random bytes for every request. [`ProcessPrng`]: https://learn.microsoft.com/en-us/windows/win32/seccng/processprng [The Windows 10 random number generation infrastructure]: https://www.microsoft.com/en-us/security/blog/2019/11/25/going-in-depth-on-… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174

3 3

[PATCH 0/3] MR10175: winmm/tests: Test a curated list of wave formats.
by Giovanni Mascellani (＠giomasce) Feb. 24, 2026

Feb. 24, 2026

This has of course a lot of code in common with the mmdevapi tests, but I don't know what would be a good place to share it. Happy to take suggestions. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10175

2 3

[PATCH v11 0/8] MR10019: opengl32: Move wglGetProcAddress implementation to the PE side.
by Rémi Bernon Feb. 24, 2026

Feb. 24, 2026

This better splits client / host extension lists, allowing to more easily check for available host-side extensions in win32u later on, then moves the function registry to the PE side to get rid of the remaining extension logic in opengl32 unix side. Doing that, it also drops the driver function check, and always expose extension functions to the client if their extension dependency is satisfied. I'm not completely sure this is right, but I think the unix side tends to expose functions from eglGetProcAddress more often than the opposite. We could also keep a mechanism to check the driver availability, with a bit of additional complexity. On the unix side, all OpenGL functions are queried on initialization instead of just core functions, simplifying their use later on. -- v11: opengl32: Implement the function registry on the PE side. win32u: Query every OpenGL functions on initialization. opengl32: Implement client extension enumeration on the PE side. opengl32: Move major / minor version to the PE side context wrapper. opengl32: Parse host extension list to the opengl_extensions struct. opengl32: Remove now unused wgl pixel format unix thunks. opengl32: Implement wglGetExtensionsString(ARB|EXT) on the PE side. opengl32: Initialize enabled / disabled OpenGL extensions struct. https://gitlab.winehq.org/wine/wine/-/merge_requests/10019

1 8

[PATCH 0/6] MR10173: cfgmgr32: Remove setupapi dependency from DevObject* implementation (1/2).
by Rémi Bernon Feb. 24, 2026

Feb. 24, 2026

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

2 9

[PATCH v10 0/8] MR10019: opengl32: Move wglGetProcAddress implementation to the PE side.
by Rémi Bernon Feb. 24, 2026

Feb. 24, 2026

This better splits client / host extension lists, allowing to more easily check for available host-side extensions in win32u later on, then moves the function registry to the PE side to get rid of the remaining extension logic in opengl32 unix side. Doing that, it also drops the driver function check, and always expose extension functions to the client if their extension dependency is satisfied. I'm not completely sure this is right, but I think the unix side tends to expose functions from eglGetProcAddress more often than the opposite. We could also keep a mechanism to check the driver availability, with a bit of additional complexity. On the unix side, all OpenGL functions are queried on initialization instead of just core functions, simplifying their use later on. -- v10: opengl32: Implement the function registry on the PE side. win32u: Query every OpenGL functions on initialization. opengl32: Implement client extension enumeration on the PE side. opengl32: Move major / minor version to the PE side context wrapper. opengl32: Parse host extension list to the opengl_extensions struct. opengl32: Remove now unused wgl pixel format unix thunks. opengl32: Implement wglGetExtensionsString(ARB|EXT) on the PE side. opengl32: Initialize enabled / disabled OpenGL extensions struct. https://gitlab.winehq.org/wine/wine/-/merge_requests/10019

1 11

[PATCH 0/1] MR10041: win32u: When looking for duplicates in the external fonts list don't count not external fonts.
by Dmitry Timoshkov (＠dmitry) Feb. 24, 2026

Feb. 24, 2026

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

3 2

[PATCH 0/2] MR10168: winmm: Call WINMM_InitMMDevices once on systems without sound devices.
by Piotr Caban (＠piotr) Feb. 24, 2026

Feb. 24, 2026

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

3 3

[PATCH 0/1] MR10167: mmdevapi: Don't fail initialization when no drivers were loaded.
by Piotr Caban (＠piotr) Feb. 24, 2026

Feb. 24, 2026

Otherwise we keep trying to initializa the driver on systems without sound libraries. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10167

3 2

[PATCH v3 0/2] MR10093: comctl32: Fix zero-sized label for empty text in LISTVIEW_GetItemMetrics.
by Maotong Zhang (＠xiaotong) Feb. 23, 2026

Feb. 23, 2026

DrawTextW(..., DT_CALCRECT) returns a zero rectangle for empty strings, resulting in incorrect label size. Faststone Image Viewer does not show file names. Wine-Bug:https://bugs.winehq.org/show_bug.cgi?id=48872 -- v3: comctl32: Fix zero-sized label for empty text in LISTVIEW_GetItemMetrics. comctl32/tests: Test empty string item in icon view. https://gitlab.winehq.org/wine/wine/-/merge_requests/10093

3 8

[PATCH v16 0/3] MR9369: wininet: Return correct errors and put handle into invalid state when seeking beyond end of file.
by Torge Matthies (＠tmatthies) Feb. 23, 2026

Feb. 23, 2026

When `InternetSetFilePointer` is used to seek and then read beyond the size of the remote file, the initial read will fail with `ERROR_NOACCESS` and put the handle into an invalid state such that `InternetSetFilePointer`, `InternetReadFile`, and `InternetQueryDataAvailable` will return errors from then on. Based on !9644. -- v16: wininet: Return correct errors and put handle into invalid state when seeking beyond end of file. wininet/tests: Add tests for seeking beyond end of file. wininet/tests: Skip GetUrlCacheConfigInfo and CommitUrlCacheEntry tests if the functions return ERROR_CALL_NOT_IMPLEMENTED. https://gitlab.winehq.org/wine/wine/-/merge_requests/9369

3 5

[PATCH 0/7] MR10172: msxml/tests: Separate reader tests in a number of helpers.
by Nikolay Sivov (＠nsivov) Feb. 23, 2026

Feb. 23, 2026

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

2 7

Re: [PATCH v2 0/3] MR9777: mfplat: Implement mf d3d12 synchronization object.
by Nikolay Sivov (＠nsivov) Feb. 23, 2026

Feb. 23, 2026

@CharlottePabst in case you're waiting, I'll still need someone familiar with d3d12 concepts to effectively review this. Does this block other missing parts to get d3d12 buffers working? Right now we can't create such buffers at all. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9777#note_130294

1 0

[PATCH 0/1] MR10171: po: Update Lithuanian translation.
by Aurimas Fišeras Feb. 23, 2026

Feb. 23, 2026

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

1 1

Re: [PATCH v2 0/1] MR10170: kernelbase: Add a message string for CRYPT_E_NO_MATCH. - approved
by Alexandre Julliard (＠julliard) Feb. 23, 2026

Feb. 23, 2026

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

1 0

Re: [PATCH v3 0/1] MR10092: mf: Drop events and end draining on MFT flush. - approved
by Alexandre Julliard (＠julliard) Feb. 23, 2026

Feb. 23, 2026

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

1 0

Re: [PATCH v2 0/1] MR10125: mf/tests: Fix potential race conditions in test. - approved
by Alexandre Julliard (＠julliard) Feb. 23, 2026

Feb. 23, 2026

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

1 0