Wine64如何处理macOS系统？

Question

Wine64如何处理macOS系统？

6

多年来，这一直是一个巨大的障碍。根据报道，它被认为是不可能的。论坛讨论涉及到关于设置和还原GS的问题。 Wine HQ FAQ仍然引用了ABI不兼容页面，但这不是一个当前的维基页面，而是一个新闻存档链接。 Wine 2.0宣布支持macOS 64位。但是……怎么做到的呢？这不是所有macOS黑客都应该知道的吗？也许对于任何x86-64黑客来说，这是有趣的优雅（或肮脏）技巧。

- OCTAGRAM

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Ken Thomases · Accepted Answer

主要问题是CPU在操作系统控制下维护的GS段基地址（GS.base）存在冲突。

在64位Windows上，GS.base用于保存每个线程的线程环境块（TEB）结构体的地址。Windows应用程序希望使用%gs相对地址访问TEB。这是硬编码到应用程序代码中而不是在API函数后面。

在macOS上，GS.base用于保存线程的struct _pthread的线程本地存储区域的基地址，这是Pthreads实现的内部实现细节。Mac应用程序很少硬编码%gs相对访问，但有些应用程序和系统库会这样做。

在Linux上，GS.base可供64位应用程序用于自己的目的。因此，在那里，Wine只需使用操作系统提供的机制设置它。Wine无法在macOS上执行此操作。操作系统不仅没有提供任何机制来执行此操作，而且如果Wine可以这样做，它将破坏系统库。（它还可能在上下文切换时对内核造成潜在问题，或者内核可能无法恢复Wine可能设置的任何值。）

我们想出的解决方案只是一个部分解决方案。TEB结构最常访问的字段是"self"字段 (%gs:0x30) 和线程本地存储实现的一个字段(%gs:0x58)。通常，如果应用程序需要访问其他字段，它们首先读取self字段，然后引用该字段。

在macOS上，%gs:0x30和%gs:0x58对应于线程本地存储区的特定槽位。它们位于一个保留给苹果公司 (而不是应用程序使用) 的部分中。我们发现其中一个槽位未使用。另一个槽位用于C库中的ttyname()函数。恰好，Wine从未调用该函数，并且没有理由期望它所使用的任何系统库也会这样做。

因此，Wine只需将适当的值插入到这些%gs相关位置。因此，当64位Windows应用程序代码读取它们时，它会得到所需的内容。Wine分配的实际TEB位于其他位置(在堆分配的内存中)，但应用程序在它们期望的TEB self字段位置找到了TEB的地址，因此它们以这种方式找到了它。

苹果公司已经慷慨地永久保留了这两个槽位，供像Wine这样的使用。ttyname()现在使用不同的槽位。

如上所述，这个解决方案只是部分地解决了问题。一些应用程序直接使用%gs相对地址访问TEB的其他字段，偏移量不是0x30或0x58。当它们这样做时，它们会获得垃圾值和/或覆盖系统其他部分使用的值。因此，Wine对于macOS上的64位Windows应用程序的支持并不完整。一些这样的应用程序会崩溃或表现不当。幸运的是，它发生得不太频繁，在实践中不是很大的问题。

以下是实施此解决方案的提交记录：

http://source.winehq.org/git/wine.git/?a=commit;h=7501942008f91a9a137fe598ce5ce7cb47de5522 http://source.winehq.org/git/wine.git/?a=commit;h=3d8efb238808a519902e047d8673237debb0f0a2