There is no need to go through kernel32 for these functions.
Signed-off-by: Alistair Leslie-Hughes leslie_alistair@hotmail.com --- dlls/ws2_32/ws2_32.spec | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/dlls/ws2_32/ws2_32.spec b/dlls/ws2_32/ws2_32.spec index 87e0bdfa2f..5b5d323a51 100644 --- a/dlls/ws2_32/ws2_32.spec +++ b/dlls/ws2_32/ws2_32.spec @@ -102,19 +102,19 @@ @ stdcall WSARecvDisconnect(long ptr) @ stdcall WSARecvFrom(long ptr long ptr ptr ptr ptr ptr ptr ) @ stdcall WSARemoveServiceClass(ptr) -@ stdcall WSAResetEvent(long) kernel32.ResetEvent +@ stdcall WSAResetEvent(long) kernelbase.ResetEvent @ stdcall WSASend(long ptr long ptr long ptr ptr) @ stdcall WSASendDisconnect(long ptr) @ stdcall WSASendMsg(long ptr long ptr ptr ptr) @ stdcall WSASendTo(long ptr long ptr long ptr long ptr ptr) -@ stdcall WSASetEvent(long) kernel32.SetEvent +@ stdcall WSASetEvent(long) kernelbase.SetEvent @ stdcall WSASetServiceA(ptr long long) @ stdcall WSASetServiceW(ptr long long) @ stdcall WSASocketA(long long long ptr long long) @ stdcall WSASocketW(long long long ptr long long) @ stdcall WSAStringToAddressA(str long ptr ptr ptr) @ stdcall WSAStringToAddressW(wstr long ptr ptr ptr) -@ stdcall WSAWaitForMultipleEvents(long ptr long long long) kernel32.WaitForMultipleObjectsEx +@ stdcall WSAWaitForMultipleEvents(long ptr long long long) kernelbase.WaitForMultipleObjectsEx @ stdcall WSCDeinstallProvider(ptr ptr) @ stdcall WSCEnableNSProvider(ptr long) @ stdcall WSCEnumProtocols(ptr ptr ptr ptr)
What difference does this make?
Hi Nikolay,
On 10/8/20 9:00 pm, Nikolay Sivov wrote:
What difference does this make?
Really the only difference is that it stops one extra function call.
Since these functions have been moved to kernelbase, doesn't it make sense to point the forward to where it actually is?
Alistair
Am 11.08.20 um 01:25 schrieb Alistair Leslie-Hughes:
Hi Nikolay,
On 10/8/20 9:00 pm, Nikolay Sivov wrote:
What difference does this make?
Really the only difference is that it stops one extra function call.
The PE forward should get resolved at load time if I understand it right. If it is not, benchmarks showing it to be a problem are needed.
Since these functions have been moved to kernelbase, doesn't it make sense to point the forward to where it actually is?
Yeah, but that's a kernel32.dll implementation detail that ws2_32 shouldn't rely on without good reason.
Another possible consideration is compatibility with what native ws2_32 imports. If e.g. is is liked to kernelbase on modern windows and some application breaks because kernel32.dll get loaded although it should not then that would be a sound reason to change the import in our ws2_32 too.
Hi Stefan,
On 11/8/20 8:49 pm, Stefan Dösinger wrote:
Am 11.08.20 um 01:25 schrieb Alistair Leslie-Hughes:
Hi Nikolay,
On 10/8/20 9:00 pm, Nikolay Sivov wrote:
What difference does this make?
Really the only difference is that it stops one extra function call.
The PE forward should get resolved at load time if I understand it right. If it is not, benchmarks showing it to be a problem are needed.
In this case, ws2_32 then kernel32 has a -import on these functions, so the the first forward would be resolved but then kernel32 has the function wrapped in the hot swap goodness to call the kernalbase one.
Since these functions have been moved to kernelbase, doesn't it make sense to point the forward to where it actually is?
Yeah, but that's a kernel32.dll implementation detail that ws2_32 shouldn't rely on without good reason.
Another possible consideration is compatibility with what native ws2_32 imports. If e.g. is is liked to kernelbase on modern windows and some application breaks because kernel32.dll get loaded although it should not then that would be a sound reason to change the import in our ws2_32 too. On Windows 10, ws2_32 only has a kernelbase.dll reference.
Regards Alistair.
-
Alistair Leslie-Hughes -
Nikolay Sivov -
Stefan Dösinger