The cast there seems safe from looking at the struct definitions, and is also used elsewhere in the codebase (dlls/kernelbase/locale.c:5682).
It's obviously not a full implementation, but works well enough for my usecase and maybe others as well.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4851
I'm starting to consider wrapping more vulkan objects in win32u, I think it'll be useful to implement compositing (and incidentally shared resources with interop with the D3DKMT/NtGdi API), starting with nulldrv/offscreen swapchains. Alternatively we could export more functions from win32u and keep all the wrappers in winevulkan, but having access to win32u internals with a generic vulkan object wrapping mechanism seems to be more interesting.
Right now this is not very convenient because the vulkan object hierarchy is only available in winevulkan. This introduces shared structures and API between win32u and winevulkan so they can manipulate the wrapped objects from both side. The interface would only expose what is necessary, ie: the object hierarchy and wrapped handles, the instance and device functions, and the objects rbtree for debugging, so win32u can insert its wrapper there as well.
After moving the surface and swapchain wrappers to win32u, the interface would look like this: https://gitlab.winehq.org/rbernon/wine/-/blob/65ca1280d46a2dff792e298c22242… (I pushed a complete WIP branch to https://gitlab.winehq.org/rbernon/wine/-/commits/wip/vulkan-win32u-driver?r…). We can also consider moving all the winevulkan wrappers to win32u but it's not clear whether it's necessary or desirable, and we can also do that later using this interface.
--
v4: winevulkan: Introduce a new vulkan_physical_device base structure.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6427
On Tue Nov 26 09:45:58 2024 +0000, Michele Dionisio wrote:
> I remove the check as you request. but in my opinion now the test fails
> on linux and windows too
they fail on linux when run from a unix console, I don't see failure on windows
you can add the attached patch to work around this
[patch-timeout](/uploads/e311af5c8318f780aad5ff66a714ba26/patch-timeout)
I let you fix the remaining failure
Note: since MR!6888 has been merged, you don't need to take care of returning STATUS_CONTROL_C_EXIT, it's done by the default handlers now
Note2: the SetStdHandle() call between FreeConsole() and AllocConsole() in this patch looks suspicious : it's not needed under Windows, so likely another Wine bug (but it's needed for now, esp. when running the tests under Wine from a unix console)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6869#note_88940