I have an application that creates its special registry key using
NtCreateKey(parent, "Something\0"), and then expects to be able to
open this key with NtOpenKey("Something\0") on start up. Currently
this fails because terminating '\0' in the key name doesn't survive
saving/loading the registry. parse_strW() helper already supports
loading such key names.
As the tests show after creating a kernel object with the name "Something\0"
it's possible to only open it as "Something\0", and an attempt opening it
as "Something" fails with STATUS_OBJECT_NAME_NOT_FOUND, and vice versa.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3790
In certain circumstances unmarshalling an object stream from the RunningObjectTable can cause the unmarshalling routines to interrogate the same
table (maybe to resolve a dependant object?) in a different thread causing a deadlock while getting the critical section lock. Leaving the Critical Section before unmarshalling the object stream solve this problem.
Visual Studio 2019 deadlock on start without this.
I'm not sure how to test this properly.
Also add debug info for this critical section so it show a significant name in the log.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v3: ole32: Add debug info to RunningObjectTable critical section
https://gitlab.winehq.org/wine/wine/-/merge_requests/3372
The validation code is meant both as a check that the frontend is behaving properly and as a sort of the documentation to establish what is allowed and what is not in the IR.
~~Currently an assertion is thrown if validation fails. I realize this is a rather strong proposal, but it's of course up for debate. In theory asserting here is the right thing, as it is expected that the frontend is generating correct IR code. However vkd3d is already used in production for many programs, and it could very well be that some of those are working properly even if the generated IR is somewhat out of specs; allowing the assertion might cause regressions as soon as enough checks are implemented in the validator. Please let me know your opinions.~~ **Solved in favor of a softer failure, and only when validation is enabled**
--
v6: vkd3d-shader/ir: Validate source parameters.
vkd3d-shader/ir: Validate destination parameters.
vkd3d-shader/ir: Validate register types.
vkd3d-shader/ir: Validate instruction handlers.
vkd3d-shader/ir: Introduce a boilerplate to validate the generated IR.
vkd3d-shader: Embed the parsing location in vkd3d_shader_instruction.
vkd3d-shader/dxil: Destroy the SM6 parser on parsing errors.
vkd3d-shader/tpf: Destroy the SM4 parser on parsing errors.
vkd3d-shader/d3dbc: Destroy the SM1 parser on parsing errors.
vkd3d-shader/d3dbc: Ignore DCL source parameters.
vkd3d-shader/ir: Simplify the control flow in shader_instruction_normalise_io_params().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/317
This is the last series I have to use hlsl_block instead of list manipulation.
There is still some list manipulation around, but it's a little trickier to get
rid of, and questionably worthwhile. At any rate things are a lot better now
than they were.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/334