c - Linux和Windows程序有何不同

Question

Closed. This question needs to be more focused。它当前不接受答案。












想改善这个问题吗？更新问题，使其仅关注 editing this post的一个问题。

6年前关闭。



Improve this question




我在GCC中编译了一个小的“Hello World”程序，并在Linux中工作。然后，我在程序中添加了.exe扩展名，以查看它是否与Windows兼容。但这没有用。是什么原因导致该程序无法在Windows中运行。基本上，二进制和汇编指令与在Windows和linux下编译的程序相同(如果未使用特定于操作系统的库)。操作系统只需将程序加载到RAM中，处理器就会执行该程序。所以，为什么它不起作用。

最佳答案

我将把您的问题分解成更小的子集

I Compiled a small "Hello World" Program in GCC & it worked in Linux.

这是可以预料的，因为系统上安装的常规GCC和binutils配置为在执行它们时针对相同的目标和主机进行编译。用外行术语来说，它们将生成适用于Linux内核和GNU C标准库(或兼容的libc)运行时的可执行文件。

还有一些编译器可以构建程序，使其运行在与它们本身不同的操作系统和/或CPU体系结构上。这些所谓的交叉编译器，例如，您正在使用它们在台式计算机上构建Smartphone应用程序。当您使用Windows Android NDK创建 native Android可执行文件时，实际上是在交叉编译Linux内核和其他CPU(很可能是ARM或MIPS)。

Then i added .exe extension to the program, to see if it works with windows or not.

在这里，您因一个误解而迷失了方向，我永远无法理解为什么它首先出现。文件名后缀必须尽其所能。 Windows使用它在注册表中查找该怎么做，仅此而已。在Windows中，您可以注册要被识别为“可执行”的任何后缀。 Linux(是Unixoid)的功能更简单，但是恕我直言，功能更强大:每个文件都带有一组标志(如果可以执行，如果可以执行，则由谁真正执行)。

但是，要想作为一个可以运行的程序对系统真正有用，就需要有所不同，并且所有可执行文件(对于给定的OS)都必须共享，而不论它们的文件名是什么:一种特定的内部格式。 Windows使用所谓的 PE格式(PE表示可移植可执行文件，这有点可笑，因为支持它的唯一操作系统是Windows)。 Linux和* BSD使用ELF(可执行和链接格式)，而MacOS X使用称为Mach Binary格式的东西，并向Intel CPU扩展为Mach Universal Binary格式。从技术上讲，Mach内核(MacOS X的基础)也可以理解ELF格式，但是MacOS X中未启用AFAIK。

尽管两种文件格式本质上都具有相同的作用(描述如何将文件加载到内存中，它依赖于哪个库，必须加载它们以及在何处加载它们，以及程序的实际启动位置)，但它们的结构却截然不同。 Windows不知道如何加载和执行ELF，而Linux不知道如何加载和执行PE。

即使其中一个支持另一个，系统仍将缺少程序希望加载并运行的库。至少您需要(操作系统)相关的运行时环境，该环境负责诸如从OS检索启动参数，为OS特定的内存管理功能提供接口(interface)等“平凡”的事情，等等。在Linux和Windows之间有所不同。

请注意，完全有可能提供一个基于OS特定内容构建的兼容性包装程序，该程序将其他OS模拟到一个程序，并且知道如何加载，链接和启动外部可执行文件。在Linux上加载和执行Windows程序的包装器称为WINE，还存在相反的东西，称为LINE，它在Windows上运行Linux可执行文件。

But it did not work. Whats the reason for the program to not work in windows.

Windows与Linux不同。它具有完全不同的系统级API，它使用不同的二进制格式，甚至诸如stdin/stdout(由C标准库定义)之类的基本内容也实现方式也大不相同。哎呀，他们甚至使用不同的 calling conventions

Linux使用标准的C调用约定(stdcall)。 Windows主要使用cdecl约定，这是pascal和stdcall约定的混合体。

Basically the Binary & assembly instructions are same in the Programs compiled under windows & linux (If OS specific library not used).

嗯，不，他们绝对不是。调用约定中的差异所有人产生不同的程序集。

The OS has to just load the Program in the RAM & processor will execute it.

没那么简单。该程序还必须“连接”到操作系统，以执行任何有用的操作。您想在控制台上看到一个字符串吗？然后，您必须将其连接到某些操作系统功能，然后执行此操作。

在Linux中，控制台已经存在，并且有特殊文件 /dev/console， /dev/stdin， /dev/stdout， /dev/stderr，它们内部绑定(bind)到当前 pts或 tty。在此过程中， 总是映射到文件描述符0、1和2。

在Windows中，程序可能打开或不必打开自己的控制台窗口(如果从CLI启动，它将使用该窗口)。因此，它必须调用 AllocConsole，如果失败则作为后备 AttachConsole(parent_PID)；然后就可以使用 GetStdHandle来获取stdin，stdout，stderr。此获取的 HANDLE是任意的，需要连接到C stdio(printf，fwrite等)和C++ iostream的内部实现。

同样，CPU不会“神奇地”执行一段二进制代码，只是因为它最终会结束RAM中的某个位置。操作系统必须创建一个新进程，并必须知道某些重要代码位于二进制文件的哪些位置(入口)，以执行此操作。这些入口点(除其他外)在二进制文件格式的特殊位置描述。正如我已经解释的，Windows与Linux只能理解非常不同的可执行二进制格式(PE)。二进制文件一旦加载并链接，就必须实际启动。如上所述，启动二进制文件的步骤在Linux和Windows之间也有所不同。

后期编辑，但必须编写为:

*同样重要的是要了解，在程序启动时，可执行文件的二进制文件根本不会完全加载到RAM中。发生的是，创建了所谓的“虚拟内存映射”。这意味着操作系统将创建虚拟地址空间，并与其他一些数据结构一起通常称为进程。虚拟地址空间又由一组所谓的“页面”支持，页面是映射到实际内存或存储设备的地址空间块。实际上，RAM通常总是用作磁盘操作的缓存。映射程序二进制文件时，虚拟内存页面将始终指向磁盘存储，而RAM仅充当其缓存。动态分配的内存是从在存储设备上缓存交换空间的磁盘缓存中获取的。如果没有交换设备，则仅从通用磁盘缓存中获取。*

如您所见，这些是完全不同的任务列表。除此之外，调用约定和二进制格式也有所不同。

So, why does it not work.

因为可执行文件不仅包含惰性汇编指令，还包含更多内容。程序需要与操作系统对话以产生有意义的东西。 Windows和Linux非常非常不同。

关于c - Linux和Windows程序有何不同，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19766426/

上一篇：c++ - 在 Windows 下使用共享内存。如何传递不同的数据

下一篇：c++ - 弃用的 OpenGL 功能

相关文章：

c++ - 通过 tcp 传输的文件末尾的额外换行符

linux - Tar命令备份错误

windows - 使用 NSIS 复制目录。

c# - 使用 C# 以编程方式打开魅力栏、电源栏和开始菜单

c - 宏作为 C 中宏的参数

c - 内部静态数组(K&R month_name() 函数)

linux - 在 Linux 中，内存映射了哪些文件？

windows - Powershell - 使桌面背景更改立即生效

c - 在 AVX2 中屏蔽单个位的最佳方法？

linux - 在 Linux(通常是 POSIX)中，如何确定线程是否在系统调用中？

Answer 1

我将把您的问题分解成更小的子集

I Compiled a small "Hello World" Program in GCC & it worked in Linux.

这是可以预料的，因为系统上安装的常规GCC和binutils配置为在执行它们时针对相同的目标和主机进行编译。用外行术语来说，它们将生成适用于Linux内核和GNU C标准库(或兼容的libc)运行时的可执行文件。

还有一些编译器可以构建程序，使其运行在与它们本身不同的操作系统和/或CPU体系结构上。这些所谓的交叉编译器，例如，您正在使用它们在台式计算机上构建Smartphone应用程序。当您使用Windows Android NDK创建 native Android可执行文件时，实际上是在交叉编译Linux内核和其他CPU(很可能是ARM或MIPS)。

Then i added .exe extension to the program, to see if it works with windows or not.

在这里，您因一个误解而迷失了方向，我永远无法理解为什么它首先出现。文件名后缀必须尽其所能。 Windows使用它在注册表中查找该怎么做，仅此而已。在Windows中，您可以注册要被识别为“可执行”的任何后缀。 Linux(是Unixoid)的功能更简单，但是恕我直言，功能更强大:每个文件都带有一组标志(如果可以执行，如果可以执行，则由谁真正执行)。

但是，要想作为一个可以运行的程序对系统真正有用，就需要有所不同，并且所有可执行文件(对于给定的OS)都必须共享，而不论它们的文件名是什么:一种特定的内部格式。 Windows使用所谓的 PE格式(PE表示可移植可执行文件，这有点可笑，因为支持它的唯一操作系统是Windows)。 Linux和* BSD使用ELF(可执行和链接格式)，而MacOS X使用称为Mach Binary格式的东西，并向Intel CPU扩展为Mach Universal Binary格式。从技术上讲，Mach内核(MacOS X的基础)也可以理解ELF格式，但是MacOS X中未启用AFAIK。

尽管两种文件格式本质上都具有相同的作用(描述如何将文件加载到内存中，它依赖于哪个库，必须加载它们以及在何处加载它们，以及程序的实际启动位置)，但它们的结构却截然不同。 Windows不知道如何加载和执行ELF，而Linux不知道如何加载和执行PE。

即使其中一个支持另一个，系统仍将缺少程序希望加载并运行的库。至少您需要(操作系统)相关的运行时环境，该环境负责诸如从OS检索启动参数，为OS特定的内存管理功能提供接口(interface)等“平凡”的事情，等等。在Linux和Windows之间有所不同。

请注意，完全有可能提供一个基于OS特定内容构建的兼容性包装程序，该程序将其他OS模拟到一个程序，并且知道如何加载，链接和启动外部可执行文件。在Linux上加载和执行Windows程序的包装器称为WINE，还存在相反的东西，称为LINE，它在Windows上运行Linux可执行文件。

But it did not work. Whats the reason for the program to not work in windows.

Windows与Linux不同。它具有完全不同的系统级API，它使用不同的二进制格式，甚至诸如stdin/stdout(由C标准库定义)之类的基本内容也实现方式也大不相同。哎呀，他们甚至使用不同的 calling conventions

Linux使用标准的C调用约定(stdcall)。 Windows主要使用cdecl约定，这是pascal和stdcall约定的混合体。

Basically the Binary & assembly instructions are same in the Programs compiled under windows & linux (If OS specific library not used).

嗯，不，他们绝对不是。调用约定中的差异所有人产生不同的程序集。

The OS has to just load the Program in the RAM & processor will execute it.

没那么简单。该程序还必须“连接”到操作系统，以执行任何有用的操作。您想在控制台上看到一个字符串吗？然后，您必须将其连接到某些操作系统功能，然后执行此操作。

在Linux中，控制台已经存在，并且有特殊文件 /dev/console， /dev/stdin， /dev/stdout， /dev/stderr，它们内部绑定(bind)到当前 pts或 tty。在此过程中， 总是映射到文件描述符0、1和2。

在Windows中，程序可能打开或不必打开自己的控制台窗口(如果从CLI启动，它将使用该窗口)。因此，它必须调用 AllocConsole，如果失败则作为后备 AttachConsole(parent_PID)；然后就可以使用 GetStdHandle来获取stdin，stdout，stderr。此获取的 HANDLE是任意的，需要连接到C stdio(printf，fwrite等)和C++ iostream的内部实现。

同样，CPU不会“神奇地”执行一段二进制代码，只是因为它最终会结束RAM中的某个位置。操作系统必须创建一个新进程，并必须知道某些重要代码位于二进制文件的哪些位置(入口)，以执行此操作。这些入口点(除其他外)在二进制文件格式的特殊位置描述。正如我已经解释的，Windows与Linux只能理解非常不同的可执行二进制格式(PE)。二进制文件一旦加载并链接，就必须实际启动。如上所述，启动二进制文件的步骤在Linux和Windows之间也有所不同。

后期编辑，但必须编写为:

*同样重要的是要了解，在程序启动时，可执行文件的二进制文件根本不会完全加载到RAM中。发生的是，创建了所谓的“虚拟内存映射”。这意味着操作系统将创建虚拟地址空间，并与其他一些数据结构一起通常称为进程。虚拟地址空间又由一组所谓的“页面”支持，页面是映射到实际内存或存储设备的地址空间块。实际上，RAM通常总是用作磁盘操作的缓存。映射程序二进制文件时，虚拟内存页面将始终指向磁盘存储，而RAM仅充当其缓存。动态分配的内存是从在存储设备上缓存交换空间的磁盘缓存中获取的。如果没有交换设备，则仅从通用磁盘缓存中获取。*

如您所见，这些是完全不同的任务列表。除此之外，调用约定和二进制格式也有所不同。

So, why does it not work.

因为可执行文件不仅包含惰性汇编指令，还包含更多内容。程序需要与操作系统对话以产生有意义的东西。 Windows和Linux非常非常不同。