为什么不能做到一次编译处处运行?

所有与CPU有关的计算任务（ＯＳ也好,你自己的程序也好）最终都要转化为CPU的指令调用.

CPU本身有它固有的指令集,CPU也只听命于它指令集范围内的指令.

IBM-PC机的CPU指令系统大家在汇编语言课程中应有所接触了.

那么,有一点可以肯定的是,CPU接受指令工作是与OS无关的,不会因为在Windows下工作，跳转指令就

100101(假设),而在Linux下要用011010,这个层面(CPU工作)是远在OS层面以下的(即OS本身也是遵守CPU指令工作的).(btw,操作系统进行CPU调度是操作系统为了实现多任务进行的，不是你的程序指定的，所以与OS调度无关)

那么逻辑上说一条命令请求:计算1 + 1(假设是00101001010111111001),它是与平台无关的,只要是通过某种手段提交给CPU,CPU就应正常运作.

但实际的情况并没有1+1这么简单:

int main()

{

int a = 1 + 1;

printf("%d\n",a);

}

这段C代码可以在各个OS平台下正常编译得到相应的可执行文件Linux:test_l windows下test_w.exe

且都能正常工作.

但test_l和test_w 2个文件如果用工具比较的话,大不相同.

why?

a.

因为一个可执行文件本身并不是仅仅包括对CPU的指令调用请求那么简单.还包括对全程序数据区,共享数据区,代码区的定义,程序中用到的字串需要在文件中存储,还要有对其它库调用信息的存储。因此一个可执行文件需要有一个结构,操作系统来解释这个结构,并按结构的定义分配内存,把代码加载到内存中的代码段,内存MAPPING,加载一些库...之后才是让CPU来执行此代码.

由上述，每个可执行文件都有自已的结构,这个结构也没有在业内形成统一标准(POSIX标准被WINDOWS支持如何?),就产生了不同的文件结构分类:WINDOWS下的COM 、MZ、NE、LE、PE... UNIX下的ELF COFF...

当然，这些不同结构的解释工作就归OS负责了。这一点就可以说明为什么在LINUX产生的ELF结构的可执行文件不可以被WINDOWS执行，也说明为什么GCC有for linux，还有forwidnows的。

b.抛开从技术上讲可不可以让WINDOWS来执行ELF文件，还有一点就足以让一次编译，处处运行的愿望破灭（ＪＡＶＡ就不提它了，它的VM为什么有FOR WINDOWS和LINUX之分？）。

因为程序除了自身的计算之外，很多工作是需要让OS来完成的，比如输出printf("%d\n",a);

原则上说你可以通过CMOS中断自已搞定（这也可以实现平台无关了），但一般都是调用操作系统现成的接口，类似的情况很多，在WINDOWS下叫它们API，在UNIX下叫SYSTEM CALL。对相关DLL或SO的调用信息也是写在可执行文件内部的，试问一个指定了要调用linux.so2的某个函数的可执行文件让WINDOWS如何来解决呢？

至此，剩下的只有感激了，感谢C标准委员会在WINDOWS平台和LINUX平台下使用stdio.h 中的打印函数都用printf(没有printf_for_win32 printf_for_linux64)之分，让开发者可以在一定范围内实现一次编写，到处编译（windows下和LINUX下printf的实现定是不同的了，但没人去关心它，编译器会自动帮你连接到合适的库）。

-----------------------------------------------------------

小弟愚见，请各位指正。