[PATCH 1/4] winevulkan: Use standard CRT memory allocators.

[Georg Lehmann]

Thanks for the explanation!

On 13.04.21 14:45, Jacek Caban wrote:
> Hi Georg,
> 
> On 13.04.2021 09:52, Georg Lehmann wrote:
>> On 13.04.21 00:53, Jacek Caban wrote:
>>> Signed-off-by: Jacek Caban <jacek at codeweavers.com>
>>> ---
>>> In preparation for split PE/.so parts.
>>>
>>>   dlls/winevulkan/make_vulkan |   8 +--
>>>   dlls/winevulkan/vulkan.c    | 111 ++++++++++++++++++------------------
>>>   2 files changed, 60 insertions(+), 59 deletions(-)
>>>
>>>
>>
>> Hi,
>>
>> could you give an overview of all the changes that you are planning to
>> make for the .so/PE split? winevulkan had quite a few contributors over
>> the past years, and I think those who aren't part of codeweavers aren't
>> super familiar with wine internals. I would certainly like to know more
>> about the implications of this rework. 
> 
> 
> Sure. Generally, Wine is moving towards stricter separation between 
> PE/Windows side and Unix side. This already has a great effect on 
> compatibility with stuff like API hooking, DRMs, debuggers etc. In the 
> future, this will be also needed for stuff like 32on64.
> 
> 
> In practice, in its current shape, it means that winevulkan should be 
> built as a PE file. As such, it may do Windows calls, but not direct 
> Unix calls. For Unix calls, it will have a separated .so library. .so 
> library exports its internal interface to PE side and can do any Unix 
> calls. However, .so part should avoid calling PE side, so it's very 
> limited to what win32 APIs it can use. #pragma makedep unix controls 
> which side given source file lives on.
> 
> 
> In case of winevulkan, the transition is quite straightforward. Most of 
> the code can live in .so part (namely, vulkan.c and vulkan_thunks.c). 
> There are a few Windows calls that we need to be moved out of there and 
> this series moves most of win32 calls out of vulkan.c. We will also need 
> dispatch tables and exported functions on PE part, so that will need 
> another thin layer of thunking. Using wine_vkResetEvent as an example, 
> in my WIP tree, there is a new PE function for PE side:
> 
> 
> VkResult WINAPI wine_vkResetEvent(VkDevice device, VkEvent event)
> {
>      return unix_funcs->p_vkResetEvent(device, event);
> }
> 
> 
> That's what applications can see, while unix_funcs->p_vkResetEvent 
> points to the existing vkResetEvent thunk living in .so part:
> 
> 
> VkResult WINAPI unix_vkResetEvent(VkDevice device, VkEvent event)
> {
>      TRACE("%p, 0x%s\n", device, wine_dbgstr_longlong(event));
>      return device->funcs.p_vkResetEvent(device->device, event);
> }
> 

This sounds like it could potentially negatively affect performance up
to a measurable degree due to another indirection. But I guess there's
no way to have a function in the unix library (with the correct calling
convention and everything) and to return that from the PE in
vkGet*ProcAddr?

Thanks,

Georg