windows 为什么“可执行文件”依赖于操作系统？

Why are "Executable files" operating system dependent?

提问by Mohamed_Ezz

I understand that each CPU/architecture has it's own instruction set, therefore a program(binary) written for a specific CPU cannot run on another. But what i don't really understand is why an executable file (binary like .exe for instance) cannot run on Linux but can run on windows even on the very same machine.

我知道每个 CPU/架构都有自己的指令集，因此为特定 CPU 编写的程序（二进制）不能在另一个 CPU 上运行。但我真正不明白的是为什么可执行文件（例如 .exe 之类的二进制文件）不能在 Linux 上运行，但即使在同一台机器上也可以在 Windows 上运行。

This is a basic question, and the answer i'm expecting is that .exe and other binary formats are probably not Raw machine instructions but they contain some data that is operating system dependent. If this is true, then what this OS dependent data is like? and as an example what is the format of an .exe file and the difference between it and Linux executables?

这是一个基本问题，我期待的答案是 .exe 和其他二进制格式可能不是原始机器指令，但它们包含一些依赖于操作系统的数据。如果这是真的，那么这个操作系统相关数据是什么样的？例如，.exe 文件的格式是什么以及它与 Linux 可执行文件之间的区别是什么？

Is there a source i can get brief and detailed information about this?

有没有我可以获得关于此的简要和详细信息的来源？

采纳答案by Alexander Gessler

In order to do something meaningful, applications will need to interface with the OS. Since system calls and user-space infrastructure look fundamentallydifferent on Windows and Unix/Linux, having different formats for executable programs is the smallest trouble. It's the program logicthat would need to be changed.

为了做一些有意义的事情，应用程序需要与操作系统交互。由于系统调用和用户空间基础结构在 Windows 和 Unix/Linux 上看起来根本不同，可执行程序的不同格式是最小的麻烦。这是需要更改的程序逻辑。

(You might argue that this is meaningless if you have a program that solely depends on standardized components, for example the C runtime library. This is theoretically true - but irrelevant for most applications since they are forced to use OS-dependent stuff).

（您可能会争辩说，如果您的程序仅依赖于标准化组件，例如 C 运行时库，那么这毫无意义。这在理论上是正确的 - 但对于大多数应用程序来说无关紧要，因为它们被迫使用依赖于操作系统的东西）。

The other differences between Windows PE(EXE,DLL,..) files and Linux ELFbinaries are related to the different image loaders and some design characteristics of both OSs. For example on Linux a separate program is used to resolve external library imports while this functionality is built-in on Windows. Another example: Linux shared libraries function differently than DLLs on Windows. Not to mention that both formats are optimized to enable the respective OS kernels to load programs as quick as possible.

Windows PE（EXE、DLL、..）文件和Linux ELF二进制文件之间的其他差异与两种操作系统的不同图像加载程序和一些设计特征有关。例如，在 Linux 上，一个单独的程序用于解析外部库导入，而此功能在 Windows 上是内置的。另一个示例：Linux 共享库的功能与 Windows 上的 DLL 不同。更不用说这两种格式都经过优化，使各自的操作系统内核能够尽可能快地加载程序。

Emulators like Wine try to fill the gap (and actually prove that the biggest problem is not the binary format but rather the OS interface!).

像 Wine 这样的模拟器试图填补这一空白（实际上证明最大的问题不是二进制格式，而是操作系统接口！）。

回答by S.Lott

.exe and other binary formats are [definitely] not Raw machine instructions but they contain some data that is operating system dependent.

.exe 和其他二进制格式 [绝对] 不是原始机器指令，但它们包含一些依赖于操作系统的数据。

what this OS dependent data is like? and as an example what is the format of an .exe file and the difference between it and Linux executables?

这个依赖于操作系统的数据是什么样的？例如，.exe 文件的格式是什么以及它与 Linux 可执行文件之间的区别是什么？

Well, I guess Google failed you utterly. .EXE formats are very well-defined by Windows documentation.

好吧，我猜谷歌彻底让你失望了。.EXE 格式在 Windows 文档中有很好的定义。

http://support.microsoft.com/kb/65122

http://support.microsoft.com/kb/65122

The Linux ldapplication loads an executable into memory prior to "exec" to that file. You could read up on ldformat or even the famous a.outfile.

Linuxld应用程序在“执行”该文件之前将可执行文件加载到内存中。您可以阅读ld格式甚至著名的a.out文件。

http://linux.die.net/man/1/ld

http://linux.die.net/man/1/ld

http://en.wikipedia.org/wiki/A.out

http://en.wikipedia.org/wiki/A.out

http://en.wikipedia.org/wiki/Executable

http://en.wikipedia.org/wiki/Executable

回答by Ingo

Apart from the executable format that must be recognized by the system loader (i.e. that part of an OS that brings the executable into memory) the real problem is the interface to the OS. You can think of an OS as a kind of API that provides entry points one must call for doing specific things, like for example, writing a character to the console.

除了系统加载程序必须识别的可执行格式（即，将可执行文件放入内存的操作系统部分）之外，真正的问题是操作系统的接口。您可以将操作系统视为一种 API，它提供了执行特定操作时必须调用的入口点，例如，将字符写入控制台。

These details are usually more or less hidden from the end user, so that you can achieve writing a character to the screen with the same source code in higher level languages. But often, things are more different, like for example the Windowing environment. Not all high level languages provide a windowing layer that abstracts even over those differences.

这些细节通常对最终用户或多或少是隐藏的，因此您可以使用更高级别的语言使用相同的源代码将字符写入屏幕。但通常情况下，情况更加不同，例如窗口环境。并不是所有的高级语言都提供了一个窗口层来抽象这些差异。

回答by khachik

A very naive answer:

一个很幼稚的回答：

1. Their structure are different because of different process loaders;
2. The use os-dependent features like syscalls, which vary from OS to OS.

1. 由于进程加载器不同，它们的结构也不同；
2. 使用依赖于操作系统的功能，如系统调用，这些功能因操作系统而异。

回答by Stephen Bailey

I can't comment too much on *nix but yes, the code part of the binary is typically happy to run on either environment, but it is the OS that places certain demands on the binary. In windows you should read up on PE Headers.

我不能对 *nix 发表太多评论，但是是的，二进制文件的代码部分通常很乐意在任一环境中运行，但操作系统对二进制文件提出了某些要求。在 Windows 中，您应该阅读PE Headers。

The second part is simply up to the developer, many times the code part will reference libaries that are OS specific - which is why you can have both portable and non-portable C++ code before being compiled into a binary.

第二部分完全取决于开发人员，很多时候代码部分将引用特定于操作系统的库 - 这就是为什么在编译成二进制文件之前您可以同时拥有可移植和不可移植 C++ 代码的原因。

回答by geekosaur

Programs need to know how to invoke operating system services. How this is done depends on the operating system: some use interrupts, some use the x86 lcallinstruction, some (notably Windows) have distinguished shared libraries and don't document how to directly invoke services. Old 680x0 Macs and some other 680x0 operating systems used a reserved instruction set area and trapped the resulting "invalid CPU opcode" exception. Moreover, even when the mechanism is the same, the order and argument format of system calls differs between operating systems (and sometimes different versions of the same operating system; see stat()in the Linux kernel for an example of an interface that has changed several times).

程序需要知道如何调用操作系统服务。这是如何完成的取决于操作系统：一些使用中断，一些使用 x86lcall指令，一些（特别是 Windows）有不同的共享库并且没有记录如何直接调用服务。旧的 680x0 Mac 和其他一些 680x0 操作系统使用保留的指令集区域并捕获由此产生的“无效 CPU 操作码”异常。而且，即使机制相同，系统调用的顺序和参数格式因操作系统而异（有时同一操作系统的不同版本；请参阅stat()Linux内核中多次更改的接口示例） .

There issome ability to deal with other operating systems' conventions: FreeBSD has the "linuxulator" which handles the Linux-specific kernel interface, NetBSD similarly has emulators for the system call formats of other operating systems using the same hardware (say, Ultrix on MIPS or OSF/1 on Alpha), Linux used to have iBCS2 to handle the UnixWare/SCO Unix kernel interface, Wine provides replacement shared libraries and a binary loader for PE-style Windows executables. (I don't recall if Wine also supports OS/2-style LX .exes; it probably does handle original format .exe; and then there's .comwhich is a raw memory dump with a header slapped on.) Even so, there is always some format that uses different conventions, and sometimes the conventions are similar enough to require hints to the OS as to how to deal with it. (See blesson FreeBSD, for example.)

这里是一些对付其它操作系统的惯例能力：FreeBSD的有‘linuxulator’它处理Linux特有内核接口，NetBSD的同样具有使用相同的硬件（比如，的Ultrix在其他操作系统的系统调用格式模拟器MIPS 或 OSF/1 on Alpha)，Linux 过去使用 iBCS2 来处理 UnixWare/SCO Unix 内核接口，Wine 为 PE 风格的 Windows 可执行文件提供替换共享库和二进制加载器。（我不记得 Wine 是否也支持 OS/2-style LX .exes；它可能确实处理原始格式.exe；然后还有.com这是一个带有标头的原始内存转储。）即便如此，总会有一些格式使用不同的约定，有时这些约定非常相似，需要向操作系统提供有关如何处理它的提示。（bless例如，参见FreeBSD。）