- wine-gitlab - winehq.org

[PATCH v2 0/5] MR3792: Fill in some VMR9 stubs
by Alfred Agrell (＠Alcaro) 11 Sep '23

11 Sep '23

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

3 7

[PATCH 0/1] MR3790: server: Explicitly write terminating '\0' in the registry key names.
by Dmitry Timoshkov (＠dmitry) 11 Sep '23

11 Sep '23

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

3 6

[PATCH 0/4] MR3792: Fill in some VMR9 stubs
by Alfred Agrell (＠Alcaro) 11 Sep '23

11 Sep '23

This resolves 2 of 8 missing features needed by the Kirikiri visual novel engine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3792

4 8

[PATCH 0/1] MR3791: widl: Add initial implementation of the SLTG typelib generator.
by Dmitry Timoshkov (＠dmitry) 11 Sep '23

11 Sep '23

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

4 5

[PATCH v3 0/2] MR3372: ole32: Leave the RunningObjectTable Critical Section before unmarshalling object stream
by Lorenzo Ferrillo (＠llde) 11 Sep '23

11 Sep '23

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

4 5

[PATCH 0/2] MR3789: Improve media session handling of unexpected errors.
by Santino Mazza (＠tati1454) 11 Sep '23

11 Sep '23

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

3 3

[PATCH 0/11] MR3786: mshtml: Implement a unified QueryInterface on the dispex, part 3.
by Gabriel Ivăncescu (＠insn) 11 Sep '23

11 Sep '23

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

3 12

[PATCH 0/1] MR3768: msxml3/tests: Fix failure messages.
by Daniel Lehman (＠dlehman25) 11 Sep '23

11 Sep '23

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

3 3

[PATCH v6 0/11] MR317: vkd3d-shader: Begin validating the generated IR.
by Giovanni Mascellani (＠giomasce) 11 Sep '23

11 Sep '23

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

3 17

[PATCH v2 0/1] MR336: vkd3d-shader/hlsl: Fix float modulus for vector arguments.
by Nikolay Sivov (＠nsivov) 11 Sep '23

11 Sep '23

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: vkd3d-shader/hlsl: Fix float modulus for vector arguments. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/336

3 7

2025

2024

2023

2022

wine-gitlab