FWIW: that whole frame is just wrong anyway. Microsoft breaks stuff constantly. Everyone out there (including anti-cheat vendors) is relying on hackery and tr

FWIW: that whole frame is just wrong anyway. Microsoft breaks stuff constantly. Everyone out there (including anti-cheat vendors) is relying on hackery and trickery to make their stuff work on windows. And every windows release a ton of that stuff breaks and these companies drop everything to re-reverse-engineer whatever it is they need. What works compatibly[1] is the win32 C API implemented along with the specific set of DLLs that you built your application against[2]. MS curates the kernel/driver interface below that fairly well[3]. But the kind of trickery EAC is doing here is right in the middle of things that absolutely do not work on windows either. [1] In the sense of "do this and your app won't break". [2] Which is why windows binaries ship their own C libraries. FWIW this model exists in Linux too. It's basically the way we package Docker and Snap containers. Had EAC been written against a particular Snap environment, we wouldn't be having this problem either because it would be frozen on a particular glibc version. [3] And above that level, there are often other runtimes like .NET to which you can portably target.