This resolves 2 of 8 missing features needed by the Kirikiri visual novel engine.
--
v2: quartz: Delete some redundant members from struct quartz_vmr
quartz: Add test for VMR9SurfaceAllocatorNotify_ChangeD3DDevice
Add test for VMR9SurfaceAllocatorNotify_NotifyEvent
Recreate surfaces in VMR9SurfaceAllocatorNotify_ChangeD3DDevice
quartz: Fill in VMR9SurfaceAllocatorNotify_NotifyEvent stub
https://gitlab.winehq.org/wine/wine/-/merge_requests/3792
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