January 2024 - Wine-GitLab - list.winehq.org

[PATCH v2 0/2] MR4900: ntoskrnl: Reimplement ExAllocatePool* on top of ExAllocatePool2.
by Alex Henrie (＠alexhenrie) Jan. 21, 2024

Jan. 21, 2024

Microsoft deprecated all of these functions except ExAllocatePool2 and ExAllocatePool3, so it's a safe bet that in Windows the old functions are just wrappers around the new ones now. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54362 -- v2: ntoskrnl: Reimplement ExAllocatePool* on top of ExAllocatePool2. https://gitlab.winehq.org/wine/wine/-/merge_requests/4900

2 2

[PATCH 0/2] MR4900: ntoskrnl: Reimplement ExAllocatePool* on top of ExAllocatePool2.
by Alex Henrie (＠alexhenrie) Jan. 21, 2024

Jan. 21, 2024

Microsoft deprecated all of these functions except ExAllocatePool2 and ExAllocatePool3, so it's a safe bet that in Windows the old functions are just wrappers around the new ones now. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54362 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4900

2 2

Re: [PATCH v3 0/3] MR4857: Draft: gdi32,win32u: Implement D3DKMTEnumAdapters2.
by Zhiyi Zhang (＠zhiyi) Jan. 21, 2024

Jan. 21, 2024

On Fri Jan 19 22:20:34 2024 +0000, Krzysztof Bogacki wrote: > Indeed, but I thought it would be safer to allocate some memory for a > temporary working area, try enumerating adapters and only copy the > result if the entire operation did not fail halfway through rather than > using the array I was passed by the caller directly and risk writing > some partially misleading garbage to it. I also wasn't sure how to > proceed in such case: if I already wrote some LUIDs and handles, should > I try to `memset(0)` them just in case or leave the data there and trust > that all callers of this API will ignore whatever was written, treating > the content as unspecified? > It's also somewhat tricky to cause Windows to fail here so I don't know > how exactly does it behave when it encounters some error internally. > Copying the full result only on full success seemed like an easy way out > that allowed me to not bother figuring this out, even if it costs an > extra allocation. > But I can revert to writing to `pAdapters` directly if you'd prefer it > that way. If an error occurs, an error code is returned and the application shouldn't use the buffer. But just to be safe, you can do a memset(0) when it fails. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4857#note_58359

1 0

Re: [PATCH v3 0/3] MR4857: Draft: gdi32,win32u: Implement D3DKMTEnumAdapters2.
by Zhiyi Zhang (＠zhiyi) Jan. 21, 2024

Jan. 21, 2024

> For what it's worth, I haven't seen any adapter to report TRUE here on Windows. So it might be safer to default to FALSE instead. That's fine. You can add tests for this as well. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4857#note_58358

1 0

Re: [PATCH v3 0/3] MR4857: Draft: gdi32,win32u: Implement D3DKMTEnumAdapters2.
by Zhiyi Zhang (＠zhiyi) Jan. 21, 2024

Jan. 21, 2024

On Fri Jan 19 22:20:33 2024 +0000, Krzysztof Bogacki wrote: > While two separate Windows machines on which I queried the size of array > to allocate did return 32, this number isn't something that's documented > anywhere and probably shouldn't be relied on directly. I can add a test > that checks that `NumAdapters` is always set to `32` if `pAdapters` is > `NULL` and it might even pass on most if not all Windows versions > currently out there but Microsoft could one day decide that in such > cases `64` should now be returned and there would be nothing wrong with > that… or so I believe. Otherwise, this is already tested by first > `ok(enum_adapters_2_desc.NumAdapters, "Expect not zero.\n");`, although > not very strictly. > I'm also not sure what would Windows return on systems with more than 32 > adapters. Can Windows even support that many GPUs at the same time? Let's make the test stricter by comparing it to 32. If the test fails one day, we can enlarge the number. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4857#note_58357

1 0

Re: [PATCH v3 0/3] MR4857: Draft: gdi32,win32u: Implement D3DKMTEnumAdapters2.
by Zhiyi Zhang (＠zhiyi) Jan. 21, 2024

Jan. 21, 2024

On Fri Jan 19 22:20:33 2024 +0000, Krzysztof Bogacki wrote: > Together with the +1 above, this was meant to verify that array entries > past number returned by the call that actually fills them are untouched > (and +1 was for the case where the implementation returns exactly as > many adapters as the length of the array that was passed). If you > believe it's not something worth testing, I'll just remove this and +1 above. Yes, let's remove these. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4857#note_58356

1 0

[PATCH v11 0/4] MR519: vkd3d-shader/dxil: Support minimum precision.
by Conor McCarthy (＠cmccarthy) Jan. 21, 2024

Jan. 21, 2024

-- v11: vkd3d-shader/dxil: Support 16-bit types. vkd3d-shader/spirv: Introduce HALF and UINT16 types for minimum precision. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/519

2 4

[PATCH 0/2] MR4884: include/winnt.h against clang++.
by eric pouech (＠epo) Jan. 21, 2024

Jan. 21, 2024

Clang++ fails to compile Wine's include/winnt.h. This is caused by Wine defining some function inline, while the compiler provides an intrinsic version. This is fine with a C compilation, but fails in a C++ compilation. This serie fixes the compilation by better detecting the various cases and giving favor to intrinsic when defined (on clang/clang++). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4884

3 3

[PATCH v2 0/1] MR4885: ntdll: Return STATUS_DEBUGGER_INACTIVE from NtSystemDebugControl() stub.
by Paul Gofman (＠gofman) Jan. 21, 2024

Jan. 21, 2024

Need for The Finals. -- v2: ntdll: Return STATUS_DEBUGGER_INACTIVE from NtSystemDebugControl() stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/4885

2 1

[PATCH 0/4] MR4898: d2d1/effect: Use XML description for builtin effects.
by Nikolay Sivov (＠nsivov) Jan. 21, 2024

Jan. 21, 2024

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

3 5