据我了解模拟器（以简单的方式），它们确实将使用系统 X 的函数的程序的函数调用转换或替换为运行该程序的系统 Y 使用的函数。葡萄酒项目声称 Wine 不是模拟器，因为：
Wine 不是像虚拟机或模拟器那样模拟内部 Windows 逻辑，而是将 Windows API 调用即时转换为 POSIX 调用，消除了其他方法的性能和内存损失，并允许您将 Windows 应用程序干净地集成到桌面中。
那么，模拟器和虚拟机如何在主机非 Windows 系统上模拟内部 Windows 逻辑呢？那不就是把Windows系统调用翻译成主机自己各自的调用吗？模拟器和非模拟器（如 Wine）之间的区别在于模拟器模拟整个操作系统，然后应用程序使用该系统 API，而不知道它正在与模拟器对话，而非模拟器直接将应用程序的调用转换为主机的（并且应用程序也可能不知道）？额外的间接级别是模拟器和 Wine 之间的唯一区别吗？
答案1
那么，模拟器和虚拟机如何在主机非 Windows 系统上模拟内部 Windows 逻辑呢？那不就是将Windows系统调用翻译成主机自己各自的调用吗？
不，或者至少不像 WINE 那样——通过在用户空间中逐字翻译系统调用。模拟器通过更迂回的路线抽象地完成此操作；它不直接翻译系统调用。
一个真实的模拟器创建一个虚拟的机器（例如 x86-64），不是虚拟的操作系统。理论上，您可以运行任何针对该类型机器的操作系统。通常，“模拟器”包括操作系统，但这并不是它真正模拟的内容；它包含的操作系统与在真机上运行的操作系统相同。
模拟器有时用于模拟与主机不同的硬件，但也用于模拟完全相同的硬件，以便在一个操作系统中运行另一个操作系统。
WINE 与此不同，它实际上不是 Windows。您可以运行一个 x86-64 模拟器，其中包含 Windows 的真实副本，但这不是 WINE。他们声称它实际上比模拟器更高效，这是有道理的——仅仅转换系统调用的开销可能比运行虚拟机的开销要低。缺点是WINE只能是windows；你不能像其他操作系统一样使用它普通虚拟机。
答案2
考虑 Java 虚拟机。没有任何 JVM 会模仿其他任何 JVM，它们都是规范的实现。 Wine 并不是模拟 win32 api，而是它的一个实现。规格和现实不一定匹配，Microsoft 的实现和 Wine 的实现都有解决方法来使有缺陷的代码正常工作，并且对于任何给定项目来说，哪种实现是更好的目标并不一定明显。
答案3
Wine 是一个 shim，它拦截 Windows API 调用并将它们即时转换为相应的 Linux API 调用。模拟器或虚拟机模拟物理机。显然，垫片更有效，但可能无法完全模仿所需的功能。
答案4
Wine 就像 Python、Java 或其他运行时。 Wine 对于 Windows 可执行文件和在 Linux/Unix 上运行的库（如 Darling）是可运行的（MacOs 应用程序和动态库在 Linux 上运行）而且它不仅仅是运行时的模拟器。