|
|
所有与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，还有for widnows的。
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的实现定是不同的了，但没人去关心它，编译器会自动帮你连接到合适的库）。
-----------------------------------------------------------
小弟愚见，请各位指正。
|
|
