ARM64 ws2_32 issues

Hi all,
Sorry in advance if the subject doesn’t fit to this forum, but I’m quite desperate to find an answer to my question and I know this forum hosts windows internals experts.
I’m trying to use a native ARM64 DLL on HoloLens 2; this DLL implements a proprietary network protocol and works perfectly fine on native x64 architecture.
I compiled a UWP ARM64 version of this DLL that works on HoloLens 2, but the performance is ridiculous, so I try to use a native ARM64 DLL (not UWP). I can link it to ws2_32.lib ARM64 version, but when I try to run it on HoloLens 2, it doesn’t find the ARM64 ws2_32.dll. I searched the internet, and cannot find any information.
Does anybody here know how to use a native ARM64 DLL that use winsock2 on HoloLens 2?
Thanks in advance!
Best regards.
Note: my DLL is called from C# code inside Unity framework

Yet, I haven’t done anything with Windows on ARM, but I’ve heard about confusion regarding 32 and 64 bit versions of DLLs.
The reason is that, regardless of the naming, the directory c:\windows\system32 always contains the “native” version of a DLL.
This means that on 32 bit Windows the 32 bit versions of the DLLs are located there, while on 64 bit Windows the directory “system32” contains the 64 bit versions, and the 32 bit versions are in c:\windows\syswow64, where wow64 probably means “Windows (32) on Windows64”.
I don’t know if you have this on your mind, and I don’t know how ARM comes into the game, but I thought I’d drop this note anyway.

Sorry for the delay, thank you for your answer.
I know about the confusing folders namings but it’s not the same issue here.
Just trying to call native winsock2 APIs from within my ARM64 DLL

I’m confused by this, and perhaps I missed a staff meeting somewhere. I thought UWP was just a subset of the SDK with WinRT added in, and little more. Why would a UWP app have any performance issues compared to a desktop app? Surely the WinRT networking classes eventually call into Winsock. Doesn’t a UWP app destined for ARM64 have to be built for ARM64?

Perhaps you can quantify what ‘ridiculous’ performance is? Is it possible that this has more to do with porting the code to ARM than anything else?