Welcome to Princeland depends on that.
Added tests show that NtQueryDirectoryFile mask handling is different from FindFirstFile (even though it doesn't quite match Windows too, the details are different, e. g., on Windows mask "*." will select file "ea" with FindFirstFile but not with NtQueryDirectoryFile). So the correct way is probably do the wildcards matching in kernelbase directly without relying on NtQueryDirectoryFile.
Having files not apprearing in the output of FindFirstFile is not obvious on Windows as well as the mask matches generated short names and that might provide an unexpected output. However, the part with not returning the files with extension when mask requires so looks rather straightforward and depending on that is not probably supposed to semi-randomly break on Windows. While checking the tests before after the changes I was checking that besides not introducing new TODOs no test files are appearing in the missing part in todo tests (as starting to incorrectly missing some files in the output has an obvious regression potential).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3697
Now that we can write HLSL intrinsics in HLSL, cleaning up missing
functions becomes much easier.
This commit also extends the trigonometry tests a little bit to make
sure that tan works right.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/321
On Thu Aug 31 13:00:04 2023 +0000, Yuxuan Shui wrote:
> So is the native SRWLOCK. I can make a small change to this MR which
> makes it less fair, but brings the performance on par with native (for
> this one test that I have).
That's kind of surprising; win32 futexes are fair and we're using them internally. Why aren't our SRW locks fair?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_43978