1074: ff 15 4e 2f 00 00 call *0x2f4e(%rip) # 3fc8 <__libc_start_main@GLIBC_2.2.5>

107a: f4 hlt

107b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)

...

为了 "运行 "可执行文件，操作系统将二进制文件加载到内存中（特别是.text部分），将当前指令指针设置为代码所在的地址，就这样，可执行文件开始运行。我们可以对Windows的可执行文件做同样的事情吗？

是的! 可执行文件内的代码在Windows和Linux之间是 "可移植 "的（假设CPU架构相同）。如果我们只是把代码从Windows的可执行文件中取出来，加载到内存中，并把%rip指向正确的地方--处理器会很高兴地执行它。

你好，Wine！本质上，wine是Windows可执行文件的 "动态加载器"。它是一个原生的Linux二进制文件，因此它可以正常运行，而且它知道如何处理EXE和DLLs。它有点类似于ld-linux-x86-64.so.2。

# running an ELF binary

❯ /lib64/ld-linux-x86-64.so.2 ./app

# running a PE binary

❯ wine64 HalfLife4.exe

wine将Windows可执行文件加载到内存中，解析它，找出依赖关系，找出可执行代码的位置（即.text部分），然后最终跳转到该代码。

好吧，在现实中，它跳入类似ntdll.dll!RtlUserThreadStart()的东西，这是Windows世界中的 "用户空间 "入口点。它最终会进入mainCRTStartup()（相当于_start），然后最终进入实际的main()。

在这一点上，我们的Linux系统正在执行最初为Windows编译的代码，一切似乎都在工作。除了...

系统调用系统调用，或简称为syscalls，是使Wine如此复杂的原因。Syscall是对一个函数的调用，这个函数是在操作系统中实现的（因此是系统调用），而不是在应用程序的二进制文件或其任何动态库中。操作系统提供的一套syscall本质上是操作系统的API。

Linux上的例子：read, write, open, brk, getpid

Windows上的例子：NtReadFile, NtCreateProcess, NtCreateMutant 囧

系统调用不是代码中的常规函数调用。例如，打开一个文件，必须由内核自己执行，因为它是跟踪文件描述符的人。因此，应用程序代码需要一种方法来 "中断 "自己，将控制权交给内核（这种操作通常称为上下文切换）。

在每个操作系统上，操作系统所暴露的函数集和调用这些函数的方式都是不同的。例如，在Linux上，为了调用read()，二进制文件会把文件描述符放到寄存器%rdi中，把缓冲区指针放到%rsi中，把要读取的字节数放到%rdx中。然而，在Windows系统中，内核中没有read()函数。这些参数也没有任何意义。因此，为Windows编译的二进制文件将使用Windows的方式进行系统调用，这在Linux上是行不通的。我不会深入研究syscalls到底是如何工作的，这里有一篇关于Linux实现的好文章--https://blog.packagecloud.io/the-definitive-guide-to-linux-system-calls/。

让我们再编译一个小程序，比较一下在Linux和Windows上生成的代码。

#include

int main() {

printf("Hello!\n");

return 0;

}

(左 - Linux, 右 - Windows)

这一次我们从标准库中调用一个函数，而这个函数最终会执行一个系统调用。在上面的截图中，Linux版本调用puts，而Windows版本则调用printf。这些函数来自标准库（Linux的libc.so，Windows的ucrtbase.dll），应用程序使用它来简化与内核的通信。在Linux上，现在建立静态链接的二进制文件是相当普遍的，它不依赖于任何动态库。在这种情况下，put的实现被嵌入到二进制文件中，在运行时没有libc.so的参与。

在Windows上，至少在不久前，"只有恶意软件才会使用直接的系统调用"[引用者注]。正常的应用程序总是依赖于kernel32.dll/kernelbase.dll/ntdll.dll，它们隐藏了与内核通信的低级魔法。应用程序只是调用一个函数，其余的由库来处理。

(感谢 https://alice.climent-pommeret.red/posts/a-syscall-journey-in-the-windows-kernel/)

在这一点上，你可能已经对我们接下来要做的事情有了感觉 2333。

系统调用的运行时翻译如果我们能 "拦截 "一个系统调用呢？比如，每当应用程序调用NtWriteFile()时，我们就会介入，调用write()，并以二进制文件所期望的格式返回结果。这应该是可行的。上面的例子的简单粗暴的解决方案可能看起来像这样。

// HelloWorld.exe

lea rcx, OFFSET FLAT:`string'

call printf

↓↓

// "Fake" ucrtbase.dll

mov edi, rcx // Convert the arguments to Linux ABI

call puts@PLT // Call the real Linux implementation

↓↓

// Real libc.so

mov rdi, // write to STDOUT

mov rsi, edi // pointer to "Hello"

mov rdx, 5 // how many chars to write

syscall

我们可以提供一个自定义版本的ucrtbase.dll，它将有一个特殊的printf实现。它不会试图调用Windows内核，而是遵循Linux ABI，调用libc.so的写函数。然而，在实践中，应用程序可以静态地与ucrtbase.dll链接，而且我们不能修改二进制文件的代码，原因有很多--这很混乱和复杂，会弄乱DRM，等等。

因此，我们将修改介于二进制文件和内核之间的地方 - ntdll.dll。这是进入内核的 "网关"，Wine确实提供了它的自定义实现。在Wine的最新版本中，它由两部分组成：ntdll.dll（这是一个PE库）和ntdll.so（这是一个ELF库）。第一个部分是一个薄层，只是将调用重定向到ELF对应部分。ELF对应库包含一个名为__wine_syscall_dispatcher的特殊函数，它执行了一个将当前堆栈从Windows转换到Linux并返回的魔术。

因此，当进行系统调用时，与Wine一起运行的进程的调用栈看起来像这样。

系统调用调度器是连接Windows世界和Linux世界的桥梁。它负责处理调用惯例--分配一些堆栈空间，移动寄存器，等等。一旦在Linux库（ntdll.so）中执行，我们就可以自由地使用任何常规的Linux API（例如libc或syscall），并可以实际读/写文件，锁定/解锁互斥等等。

是这样吗？这听起来几乎太容易了。而且确实如此。首先，有大量的Windows APIs。而且它们的文档很差，有已知的（和未知的，哈哈）错误，必须完全按原样保留。Wine的大部分源代码是各种Windows DLLs的实现。

第二，有不同的方法来执行系统调用。从技术上讲，没有什么可以阻止应用程序通过syscall指令进行直接的系统调用，理想情况下这也应该是可行的（记住，Windows游戏会做各种疯狂的事情）。Linux内核有一个特殊的机制来处理这个问题，当然这只会增加复杂性。

第三，还有这整个32位与64位的兼容问题。有很多老的32位游戏，它们永远不会被重新发布为64位。Wine对两者都有支持，这再次增加了系统的整体复杂性。

第四，我甚至没有提到Wine-server--一个由Wine催生的独立进程，它维护着内核的 "状态"（打开的文件描述符、互斥符等）。

第五，哦，你想运行一个游戏吗？而不仅仅是一个hello world？那么你需要处理DirectX、音频、输入设备（游戏手柄、操纵杆）等等。这是一个很大的工作!

Wine已经开发了很多年，并取得了长足的进步。今天，你可以运行最新的游戏，如《赛博朋克2077》或《Elden Ring》，没有任何问题。该死的，有时候Wine的性能甚至比Windows还要好! 这是一个怎样的时代啊...

我希望这篇文章能让您对Wine的工作原理有一个基本的了解。正如我在免责声明中警告的那样，我简化了一大堆事情，在一些细节上可能是错误的(希望不会太多)。如果你发现我完全是在误导别人，请伸出援手纠正我！

作者：Andy Hippo, 原文地址：https://werat.dev/blog/how-wine-works-101/