我对不同机器代码/二进制可执行文件的新手理解是，它们特定于操作系统和编译所用的体系结构。尽管如此，似乎反汇编机器代码是一个已解决的问题。尽管反编译仍然是一个挑战，但人们可能会想，不同的汇编语言和特定于体系结构的指令集是否可能在不同的汇编程序(例如，MASM、NASM、YASM、GAS…(和符号(Intel和AT&T(之间同构？如果这是真的，那么我们应该有机器代码转换器，可以在不同的平台之间转换二进制可执行文件，据我所知，到目前为止我们还没有。我的意思是，作为世界上最足智多谋的公司，苹果在从PowerPC迁移到英特尔，后来又迁移到ARM的同时，不得不开发模拟器(罗塞塔和罗塞塔2(，这是不可能的。为了吸引Linux用户，微软不得不开发WSL/WSL2。Linux用户必须使用Wine作为某种形式的"Wine"；兼容性层"；为了让Windows应用程序在其操作系统上运行。。。
所以我的问题具体是：
- 机器代码是否可以本地移植到其他操作系统和体系结构
- 如果是，那么为什么它不常见？(示例将不胜感激(
- 如果没有，阻碍我们这样做的主要问题是什么
对于其他操作系统，我想理论上，如果您构建了一组兼容库，您的可执行文件可以使用这些库。但这意味着也要传输每个程序使用的每个库，你会这样做吗，这样它们也可以作为新操作系统上其他本机程序的本机库？而不是，只是供翻译后的二进制文件使用。WINE使用本机DLL的能力只需要插入它自己的一些低级Windows DLL的特殊版本，以及其他Windows风格的东西。
现有"；模拟器"；像Rosetta-2这样的框架已经对本地机器代码进行了动态翻译。在这种情况下，不需要模拟不同的系统调用接口，因为在任何一种情况下都是MacOS。与WINE非常不同，在WINE中，Windows系统调用API具有不同的语义(不仅仅是相同函数的不同名称(，尤其是在绘制UI时。
正如@cem所指出的，QEMU也进行动态翻译，类似于Rosetta-2所做的，但它纯粹是实时JIT，而不是像Rosetta-2那样将优化翻译的机器代码缓存在文件中以备将来运行时使用。JIT动态翻译是一种标准的模拟技术，如果做得好，它的性能会比纯解释更好，就像JVM在实际硬件上运行Java字节码一样。
跨运行缓存结果可以让您在翻译过程中花更多时间进行优化，就像Rosetta-2一样。
让Qemu或Rosetta-2这样的主机框架参与运行外部二进制文件是有意义的，而不是将其副本嵌入每个单独的翻译二进制文件中这样可以减少磁盘空间。
并且它避免了手动缓存/更新问题；用户可以直接使用外来二进制文件，而不必首先手动翻译它们。系统负责翻译它们。
二进制到二进制的翻译通常无法达到从源代码为目标机器编译的效果，因为很难知道寄存器或内存上的副作用是什么时候以后的代码会实际读取的，或者这是否只是一个私人的临时性影响。(关于标准调用约定的假设可能会有所帮助，但带有一些手写asm的模糊二进制文件可能会使这些假设无效。(