Although I couldn't find other uses for `list_manager_create`, it seems that in this case is working just fine.
The list manager should be released once the `IEnumNetworkConnections` is destroyed.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1265
mrac tries to get function pointers for these functions using MmGetSystemRoutineAddress, I haven't seen them being used by it, but might as well implement it since they are very easy to implement.
--
v7: ntoskrnl.exe: Implement KeQueryActiveProcessorCount.
ntoskrnl.exe: implement KeQueryMaximumProcessorCount/Ex.
https://gitlab.winehq.org/wine/wine/-/merge_requests/914
Enforce proper atomic update so that other threads do not read stale
data from IO_STATUS_BLOCK.
Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com>
--
v16: ntdll: Fix reading stale Information from IOSB.
https://gitlab.winehq.org/wine/wine/-/merge_requests/155
This makes most vkd3d-shader insufficiencies a lot more obvious when used as an
embedded library.
The obvious disadvantage here is that vkd3d-compiler will basically print every
fixme message twice.
This is a bit of an RFC, since I'm not married to this patch. Other potential
approaches I see (not all mutually exclusive):
* Always print a FIXME if we return VKD3D_ERROR_NOT_IMPLEMENTED from
compile_hlsl(), but don't print messages for individual compilation errors.
Thus we clue in debuggers that a bug is related to HLSL, but let them use
VKD3D_SHADER_DEBUG to find out what the actual bug is. Since the first step is
most of the hard part I think this is a reasonable solution.
* Or do the same thing from d3dcompiler.
* Relegate hlsl_fixme to a separate vkd3d_shader_log_level, and print messages
from that log level in d3dcompiler by default. This isn't quite as simple as
that though, since currently all the messages are stored in a single blob.
* Extra APIs to control whether FIXMES are printed.
I'd also like to propose extending whichever of the above solutions to the
hlsl_error() / VKD3D_ERROR_INVALID_SHADER cases. That way we catch things which
we aren't going to catch via hlsl_fixme(), such as syntax errors from
unrecognized keywords. There's a counterargument that compiling an invalid
shader is valid usage, and that we (wine or vkd3d) shouldn't print any ERR/FIXME
messages when a program does something valid and implemented, but I'd counter
that in practice intentionally compiling an invalid shader should be exceedingly
rare, and especially for something like wine or vkd3d where debugging is
difficult, it's simply not worth insisting on "a correctly functioning program
should print no messages" if it's at the cost of making debugging that much
harder.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/41