只要体系结构相同，Windows .exe 文件可以在 Linux 系统上运行也就不足为奇了（如果它正确加载到 RAM 上）。但Linux和Windows的系统调用完全不同。因此，当 .exe 文件在 Linux 上调用系统调用时，结果将不是我们所期望的。
我认为 Wine 将 Windows 系统调用转换为 Linux 系统调用，但我无法想象如何转换。也许系统调用是通过int、syscall、systenter等实现的。Wine是否通过某种方式直接hook这样的操作？
答案1
目前正确答案
它不翻译系统调用。
系统调用通常不是由Windows下的软件本身进行的，而是通过对共享系统库的正常调用进行的。软件使用的Windows API主要是普通的库API，而不是专注于系统调用（其中大多数被认为是私有的，根本不被不属于Windows的软件使用），这使得Windows能够实现相当令人印象深刻的长-术语兼容性。
因此，wine 实现了 API，但没有实现 Windows 系统调用 - 它甚至无法做到这一点，它是用户态软件，因此无法捕获软件中断。
顺便一提，
只要架构相同，难怪Windows .exe文件可以在Linux系统上运行
低估了调用约定、文件抽象、目标文件格式和许多其他方面的差异。让一个为不同操作系统上使用的接口编写的软件成功运行、与本机系统进行调用和交换内存并不是那么容易的事情。
1 这很像您使用 C 函数（例如 ）read，通常实现 POSIX/libc 和 Linux API，并且很少自己进行系统调用。你很少会发现有人syscall(SYS_READ, …)在尝试编写 libc。
更好的答案，推测
葡萄酒仍然不能，而且目前还不清楚它是否会永远如此。如果您启用了正确的补丁，Wine staging 就可以（实验性地）实现。
虽然上述内容对于 WINE 模拟的大多数事物都是正确的，正如 @mbrig 在评论, 开始约2019年,wine-staging 做有能力捕获 Windows 系统调用。它通过使用 Linux 来做到这一点安全计算功能。
Seccomp 的发明是为了让进程告诉内核，例如：
嘿，亲爱的内核，我是一个服务器，我刚刚设置了所有监听套接字。除了服务网站所需之外，我没有任何理由进行系统调用，因此，如果我执行除
exit、read、write和 之外的任何系统调用sigreturn，请踢我的二进制底部。
prctl它通过使用参数执行系统调用来实现这一点PR_SET_SECCOMP。
由于这有点不灵活，后来添加了进程实际定义一段程序的能力，该程序应该检查系统调用及其参数是否正常。然而，这样的过滤器需要在进行系统调用时定义为 BPF 程序prctl(PR_SET_SECCOMP,…)。您还可以指定生成的信号处理程序应运行哪个函数。
现在，WINE 可以做到这一点，并且基本上除了检查 WINE 进程内进行的系统调用是否超出用于 Linux 系统调用的范围之外什么也不做。如果不是，则允许系统调用正常进行；如果是，则引发 SIGSYS，并执行单个 Windows 系统调用的调度程序。
小问题：尽我所能寻找在官方主线wine存储库中，该补丁尚未发布到“最终用户”wine。对于一个补丁来说，3 年的时间有点长了，我想这是因为这种方法存在问题（性能影响，以及与安全机制结合使用时的问题），并且可能或可能不是包含在主线 wine 中的机制，即您称为 的软件wine。