Various anticheat/DRM schemes actually do direct syscalls on Windows, so Proton has patches that use seccomp to trap them and jump to the intended Nt* syscall. There was actually a feature added to the Linux kernel a few years ago (syscall user dispatch) so that Wine could stop using seccomp for this, but Wine is still not using it.

Upstream Wine also supports direct syscalls on x86_64 macOS. macOS syscall numbers have a high bit set, so Windows syscall numbers (0 to ~300) are invalid macOS syscalls, that triggers SIGSYS, and then Wine jumps to the Nt* syscall.

There's actually a couple of reasons for Windows apps to make Linux syscalls. I'm pretty certain this is how VST bridging software works so you can use Windows VSTs in Linux DAWs.

The technique is also used in Discord RPC Bridge for Wine - allows Wine apps to communicate with Linux Discord - https://github.com/EnderIce2/rpc-bridge

I've done this before. There are valid reasons to do this, especially if you're too lazy to do a full Linux port of an application but are still willing to implement some workarounds.

Related, there is a stable way to detect whether your .exe is running under Wine and even which version by looking up the address of the export wine_get_version in ntdll [1]. Years ago I actually had to do this to work around some weird path bug when we were testing our Windows build under Wine (easier to setup Wine than a full Windows CI).

[1] https://www.winehq.org/pipermail/wine-devel/2008-September/0...