爲什麼編譯的機器碼（EXE，PE，APP）無法在所有平臺上工作？

-1

當C代碼被編譯爲exe/pe/app時，（據我所知）它被轉換成機器代碼。這可以由處理器運行。爲什麼編譯的機器碼（EXE，PE，APP）無法在所有平臺上工作？

我的問題是，因爲這是非常低的水平，它不應該做出OS特定功能的任何電話（因爲這些將已經被編譯成機器代碼以及）。那麼爲什麼它不能在不同的平臺上運行，比如Linux，Windows，OSX？

2016-04-27 Melkor

首先，二進制格式不同，所以你需要一個合適的加載程序。其次，它可能會使用具有不同調用約定的庫。第三，一般DOES中的代碼調用操作系統特定的功能，哪些可用，以及如何調用它們取決於操作系統。 linux上的'wine'幾乎在純模式下運行windows代碼，模擬必要的庫和操作系統接口。 – Jester

@Jester但是鏈接器不會將操作系統特定函數中的彙編代碼添加到您的主要可執行文件中，因此它只是可以在不同平臺上運行的程序集？ – Melkor

操作系統不是可執行文件的一部分，它是另一層，它有能力啓動可執行文件並提供服務。而且操作系統在每個平臺上都會有所不同，編譯器無論如何都沒有針對所有不同平臺的所有操作系統的庫。 –

這個問題的前提是基於對計算機如何工作的一大誤區。

編譯一個簡單的「Hello World」的可執行文件。拆開它，或者let the Godbolt Compiler Explorer do that for you。

是否包含庫實現的puts/printf的副本？不需要。它是dynamically linked來libc因此每個程序不需要它使用的每個庫函數的自己的副本。

是否包含圖形驅動程序實際繪製在顯存中的文本？不，當然不是，對於運行在multi-tasking OS with memory protection中的程序甚至是不可能的：操作系統不能讓進程直接訪問硬件;他們可以使計算機崩潰或在對方的窗戶上畫畫。

相反，過程進行系統調用與自身以外的事情進行交互。

留下所有這些，有多個體繫結構不能理解彼此的機器碼。因此，即使在同一個操作系統中，x86二進制文件也不會在ARM CPU上本地運行。

來源

2016-04-27 16:31:45

還有很多要補充的內容：調用約定（cdecl vs fastcall vs ...），二進制格式（精靈vs mach-o vs win32 vs ...）等等。 – Leandros

@Leandros：我試圖想到一個基於這樣一個錯誤前提的這個問題的緊密原因;太廣泛可能會這樣做。我打算髮表評論，但這足以成爲一個答案。你是對的：一個完整的答案將是一本書。 –

我已經downvoted不是因爲信息不好。這個問題顯然很寬泛（我低估了它，並且因爲同樣的原因而被推薦爲近乎），我認爲用廣泛的答案回答一個廣泛的問題並不是有幫助的（你確實承認答案可能是一本書）。評論可能會更好。我會高調回答這個問題（如果它不那麼寬泛）並且與某個具體問題相關聯。你可以寫出更具體的自己的問題，並提供具體的答案，其中包含一些信息。你的開場線有點對立 –

爲什麼編譯的機器碼（EXE，PE，APP）無法在所有平臺上工作？

回答

相關問題