二进制文件和操作系统有联系吗？

应该不能 操作系统可运行程序 都是特定数据结构的二进制，不同操作系统 数据结构不一样

这和系统的装载器有关系，它会根据文件头把对应位置的东西摆成特定的内存布局，修复外部连接的符号之类的，再跳转到入口执行。一般来说不可以，毕竟不同系统的 API 都不一样，但是再不用系统 API 的情况下，可以通过特殊方式修改 PE 文件头让 windows 和 linux 的加载器都能识别，然后就能运行了，但是可以实现的功能很有限。

比如 Java 常用的包管理器 maven macOS 和 windows 下只是启动文件不一样，但最终都指向同一个二进制文件

1. 有关联
2. 有一些魔法 https://justine.lol/ape.html

@Gav1nw #4 Windows 的 java.exe 和 macOS 的 java 不是同一个二进制文件。

如果多花点心思精心去构造，可以得到一个在同架构 CPU 的好几个操作系统里都能跑的可执行文件。

但是这是一种极端情况。构造出来的程序只能做简单的 PoC ，对于实际使用价值的程序来说，几乎不可能做到，因为一个实际使用价值的程序至少要依赖系统的动态链接库去干实际的活。

不行，二进制可执行文件里面都是机器码，不同 CPU 架构的机器码是不一样的。x86 跟 arm 的不一样。

操作系统本身也是一个可执行的二进制文件。操作系统也是由多条机器码（汇编指令）堆叠起来的。

不一定，万一程序用了 win 或者 linux 内核函数

同一个指令集架构，不同操作系统之间的 ABI 可能完全不一样。

不可以哦

CPU 决定的是指令，不同 CPU 对应的程序的指令（也就是汇编语言或者机器语言机器码）是不一样
同时，不同的操作系统的系统调用（ systemcall ，例如 int 0x80 中断）是不一样的；不同操作系统的程序封装格式也是不一样的，例如 Windows 程序的封装格式是 PE ，Linux 是 ELF 格式，不同操作系统解析程序的方式不一样

可以看我写的文章

https://www.nosuchfield.com/2018/11/23/Program-compilation-linking-loading-and-running/

一般是不能，无法避免与操作系统打交道的。
裸机程序倒是可以，参考裸机 hello world

https://zhuanlan.zhihu.com/p/420610342

好像还有一种混合二进制，将 bsd 和 linux 的代码段混合在一个 ELF 里面，但做不到任意 OS ，至少 Windows 这种不使用 ELF 格式的就不好搞。

linux 可执行文件文件是 elf 格式 windows 是 pe 格式
详细的可以看 [程序员的自我修养：链接、装载与库]这本书

如果设计的比较精巧，那么某种情况下，同一个二进制文件的确可以在多个架构下运行。参加这篇文章：
https://www.robertxiao.ca/hacking/defcon2018-assembly-polyglot/

二楼发的那个有点意思啊

Maven 本身就是用 Java 写的，和.class 程序或可执行.jar 没啥区别，所以要先装 Java 且设定好 JAVA_HOME

虽然.class 是跨平台的，但它是要运行在 Java 虚拟机上的，而提供 Java 虚拟机的 JDK/JRE 程序不是跨平台的

所以你在下载 JDK/JRE 的时候要指定操作系统、架构，下载 Maven 、ZooKeepr 、JMeter 等的时候不会区分什么系统

可以了解下指令集？

不同 CPU 平台不行，指令集都不同。二进制代码，汇编这东西，和硬件关系很大。操作系统反而影响没有硬件强。

这个帖子让我想到了前段时间看到的一篇关于 Wine 的文章（[How Wine works 101]( https://werat.dev/blog/how-wine-works-101/)，[中文译文]( https://www.freebuf.com/articles/system/346955.html)）。

实际上无论是什么操作系统，最终运行二进制文件都是 CPU 的工作，操作系统只是负责把二进制文件加载到 CPU 上去执行。而相同架构的 CPU 的指令又是一样的，所以理论上是可以把在 Windows 的编译的二进制文件移植到 Linux 上去的，

再看二进制文件，它其实是有结构的，可以简单理解成由 header 和 body 组成。header 部分是给操作系统来读取进行加载的，这部分不同的操作系统之间是有差别的。body 部分是 CPU 的指令，是真正要运行的部分，这部分的内容是和操作系统无关的。

所以可以这样理解，Wine 的主要工作是读取了二进制文件中的 body 部分，并加载到 CPU 运行。另外，它还 hook 了一些 Windows 上的系统函数，转成在的 Linux 里面的实现。

所以，理论上来说，用 Wine 运行 Windows 的程序，其性能并不会比在 Windows 中差，甚至有的时候还会更快。

更新链接：How Wine works 101： https://werat.dev/blog/how-wine-works-101/

可执行二进制文件，排除 jar 和 pyc 这种解释执行，单说已经汇编成为机器指令的二进制文件，其中操作系统相关的有：
操作系统内核提供的系统调用
操作系统其他库提供的函数调用
操作系统 ABI ，包括：二进制文件容器格式，二进制程序加载方式，函数参数和返回方式，等

通过精巧的设计，可以实现很多兼容性。比如
在 windows 上执行 linux 程序的 colinu
在 linux 系统执行 windows 程序的 Longene

甚至可以自定义 ABI ，然后实现各个平台的加载器，基础库，以及系统调用转发库。达到一次编译多平台运行的目的。

另外，汇编成机器指令的二进制文件直接执行是 CPU 架构相关的，如果需要跨 CPU 架构，需要考虑解释执行。

我之前的理解只知道二进制文件和 CPU 架构的相容性，并没想过系统调用等和特定系统接口绑定的情况。之上一直做 JAVA Web 对于真正底层的工作只能说是一知半解，最近研究 ESP32 所以发出次疑惑总之谢谢朋友们的解答了

@misaka19000 谢谢写的好详细

@Gav1nw #4 .class 文件不是直接运行在 CPU 上的，它是运行在 JVM 上的，而 JVM 在不同的系统和 CPU 架构上有不同的实现，这对 .class 文件来说是透明的，Java 也正是靠不同平台的 JVM 实现了跨平台。

@dcsuibian 我刚看了一下发现确实底层包的.jar 下次研究透再问

@yuezk java 这块我还算了解，只是对 c 代码这块，我原来一直想的是编译后应该是结合 CPU 指令集的代码，没想到还有系统调用等

给个最简单的例子，操作系统 A 和 B ，均使用 ARM64 处理器。在操作系统 A 把程序 main.cpp build 成一个 binary C ，在操作系统 B 把同样的程序 main.cpp build 成一个 binary D 。想要运行 binary ，需要有对应的 runtime ，runtime 会读取 binary ，然后执行 binary 里面的指令。这两个程序的执行的指令是一样的，意味着 runtime 解读 binary 之后执行的指令需要一样，而不是 binary 需要一样。不同的 runtime 解读不同的 binary 也可以运行相同的指令。比方说 binary C 是 010101 ，binary D 是 101010 ，操作系统 A 的 runtime 是正着读，操作系统 B 的 runtime 是反着读，那么最终他们读的都是同的。这也说明，理论上，通过特殊设计，是可以让同一个 binary 在同一个 CPU 的不同操作系统里运行的。

1 、有关系
2 、不能

参考大部分项目的编译产物，都是以[文件名]-[系统]-[架构].xxx 命名

对于 CPU 来说都一样，但是应用程序和 CPU 之间还隔着一个操作系统。所以二进制文件和操作系统是密切相关的。
你没发现现在流行的几个操作系统都有一个对应的编译器么。

@Gav1nw 不是同一文件。

@Gav1nw Java 虚拟机敉平了平台差异，可以用相同的字节码文件

@leimao 我对现代操作系统的理解是，负责进程调度、系统资源分配等，操作系统通过虚拟地址等，让每个进程都以为自己独占整个系统资源，所以程序不是应该对系统是无感知的吗？

java 这不就是我嘛