所有與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的實現定是不同的了，但沒人去關心它，編譯器會自動幫你連接到合適的庫）。