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

[Jacek Caban]

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);
}


Thanks,

Jacek