When f7332ab4a6e199d03e4318d82c0b16a0396b935c switched load_so_dll
over to a proper Unix syscall, ntdll.so started providing the
symbol __wine_unix_call_funcs.
When a DLL calls NtQueryVirtualMemory(MemoryWineUnixFuncs), it can
do so speculatively, not knowing whether the corresponding unix
lib actually does provide anything.
When ntdll.so started providing this symbol, then such speculative
calls to NtQueryVirtualMemory(MemoryWineUnixFuncs) would end up
returning ntdll's __wine_unix_call_funcs if the intended DLL's
unix library lacked one.
This is the case with bcrypt, where the unix library doesn't
provide __wine_unix_call_funcs if gnutls is unavailable.
This fixes crashes after f7332ab4a6e199d03e4318d82c0b16a0396b935c,
in builds without gnutls.
Signed-off-by: Martin Storsjö <martin(a)martin.st>
--
v2: ntdll: Avoid accidentally picking up ntdll's __wine_unix_call_funcs for other DLLs
https://gitlab.winehq.org/wine/wine/-/merge_requests/1525
When f7332ab4a6e199d03e4318d82c0b16a0396b935c switched load_so_dll
over to a proper Unix syscall, ntdll.so started providing the
symbol __wine_unix_call_funcs.
When a DLL calls NtQueryVirtualMemory(MemoryWineUnixFuncs), it can
do so speculatively, not knowing whether the corresponding unix
lib actually does provide anything.
When ntdll.so started providing this symbol, then such speculative
calls to NtQueryVirtualMemory(MemoryWineUnixFuncs) would end up
returning ntdll's __wine_unix_call_funcs if the intended DLL's
unix library lacked one.
This is the case with bcrypt, where the unix library doesn't
provide __wine_unix_call_funcs if gnutls is unavailable.
This fixes crashes after f7332ab4a6e199d03e4318d82c0b16a0396b935c,
in builds without gnutls.
Signed-off-by: Martin Storsjö <martin(a)martin.st>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1525
This will end up moving window around only if the old virtual screen
origin is different from the new one. Don't send unnecessary messages
if it didn't change.
This helps speeding up D3D tests on the testbot VMs with multiple
displays and hopefully solve the timeout problems.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1524
Overwatch 2 verifies that every kernel callback that is run, lives in user32. Introduce a callback in user32 that just forwards to the other modules' callbacks.
--
v18: include: Add a comment explaining why all kernel callbacks must be in user32.
user32: Remove NtUserDriverCallback* kernel callbacks.
winex11.drv: Route kernel callbacks through user32.
winex11.drv: Pass a struct to x11drv_ime_set_result.
winex11.drv: Pass a struct to x11drv_dnd_post_drop.
winemac.drv: Route kernel callbacks through user32.
wineandroid.drv: Route kernel callbacks through user32.
opengl32: Route kernel callbacks through user32.
winevulkan: Route kernel callbacks through user32.
user32: Add NtUserDispatchCallback kernel callback.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1180
Jacek Caban (@jacek) commented about dlls/winevulkan/vulkan_thunks.c:
> return (void *)out;
> }
>
> +static inline void convert_VkDeviceOrHostAddressKHR_win32_to_host(const VkDeviceOrHostAddressKHR32 *in, VkDeviceOrHostAddressKHR *out)
> +{
> + if (!in) return;
> +
> + out->deviceAddress = in->deviceAddress;
> + out->hostAddress = (void *)UlongToPtr(in->hostAddress);
FWIW, this will not do the right thing on wow64 when the address is meant to be device address. It will override the upper part of deviceAddress. It was broken in a different way before that commit by not zeroing upper 32 bits when host address should be used, so it essentially depended on caller to initialize that part. Unfortunately, I don't see a good way of solving it properly.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1508#note_17182