如果编译器将源代码转换为特定处理器的机器代码（二进制）（比如说英特尔），为什么我们需要一个用于linux的编译器和一个不同的Windows编译器，这两个操作系统都有相同的处理器？为什么编译器平台依赖？
为什么't i run the binary compiled file (let'在没有重新编译的情况下可以在linux和widows上用 gcc -Wall -o file file.c 编译linux中的文件？
gcc -Wall -o file file.c
谢谢
想象一下，你有可执行文件 . 操作系统必须将其加载到内存中 . 即便这样也不便携 . 加载什么，代码在哪里，从其他DLL导入的函数等等都写在可执行文件中，每个操作系统都有自己的格式 . 看到这些链接：
http://en.wikipedia.org/wiki/Portable_Executable（Windows PE文件格式） .
http://en.wikipedia.org/wiki/Executable_and_Linkable_Format（Linux ELF文件格式） .
现在想象一下，由于魔术，操作系统拥有内存中的所有内容，与其结构映射，甚至知道要调用的主函数的地址 . 你的程序，即使在屏幕上写一个字符串也必须调用CRT函数或OS API . 使用CRT它不知道该怎么做，它们在两种环境中是不同的，甚至API也不同 .
即使再次想象（Windows实现了subset of POSIX API），它也有一个共同的功能，因为不同的calling conventions，它不知道如何调用它 .
1 回答
想象一下，你有可执行文件 . 操作系统必须将其加载到内存中 . 即便这样也不便携 . 加载什么，代码在哪里，从其他DLL导入的函数等等都写在可执行文件中，每个操作系统都有自己的格式 . 看到这些链接：
http://en.wikipedia.org/wiki/Portable_Executable（Windows PE文件格式） .
http://en.wikipedia.org/wiki/Executable_and_Linkable_Format（Linux ELF文件格式） .
现在想象一下，由于魔术，操作系统拥有内存中的所有内容，与其结构映射，甚至知道要调用的主函数的地址 . 你的程序，即使在屏幕上写一个字符串也必须调用CRT函数或OS API . 使用CRT它不知道该怎么做，它们在两种环境中是不同的，甚至API也不同 .
即使再次想象（Windows实现了subset of POSIX API），它也有一个共同的功能，因为不同的calling conventions，它不知道如何调用它 .