プログラムは、ある言語から ASM --> マシン コード (直接実行可能) にコンパイルされます。これがプラットフォーム依存であると言われる場合、作成されたバイナリは、x86、x86-64 などの同じ命令セット アーキテクチャを持つ CPU でのみ (正しく) 実行されることを意味します。ISA の違いにより、他のプロセスでは (誤って) 実行される場合や (まったく) 実行されない場合があります。そうですよね?
さて、バイナリの概念は私を混乱させています。すべては「マシン言語コード」と「CPU」に関するものです。OS はどこで機能するのでしょうか? つまり、コンパイルされたバイナリは、メモリにロードされると CPU に直接指示します。CPU は一度に 1 つの命令を実行します。プロセス管理以外では、オペレーティング システムの役割はどこにも見当たりません。リンクテキストオペレーティング システムに関係なく、同じ ISA の CPU 上で実行されるはずです。そうですよね?
しかし、そうではありません。Windows マシンで x86 用にコードをビルドすると、Mac x86 マシンや Linux x86 マシンでは実行されません。
何かが足りないようです。私の混乱を解消してください。
ベストアンサー1
まず、最近の CPU には (少なくとも) 2 つのモードがあります。オペレーティング システム自体のコアを実行するモード (「カーネル モード」) と、プログラムを実行するモード (「ユーザー モード」) です。ユーザー モードでは、CPU は多くのことを実行できません。
たとえば、マウスのクリックは通常、ユーザー モードではなくカーネルで認識されます。ただし、OS はイベントをユーザー モードにディスパッチし、そこから適切なプログラムにディスパッチします。逆の場合も協力が必要です。プログラムは自由に画面に描画することはできず、OS とカーネル モードを経由して描画する必要があります。
同様に、プログラムを起動する動作も通常は協力です。OS のシェル部分もユーザー モード プログラムです。マウス クリックを受け取り、それがプロセスを起動するためのマウス クリックであると判断します。次に、シェルは OS のカーネル モード部分にそのプログラムの新しいプロセスを開始するように指示します。
カーネル モードが新しいプロセスを開始する必要がある場合、まず記録用のメモリを割り当て、次にプログラムのロードに進みます。これにはバイナリからの命令の取得が含まれますが、プログラムを OS に接続することも含まれます。これには通常、int main(int argc, char** argv)バイナリのエントリ ポイント (従来は ) と、プログラムが OS を呼び出すすべてのポイントを見つける必要があります。
異なるオペレーティング システムでは、プログラムを OS に接続する方法が異なります。その結果、読み込みプロセスが異なり、バイナリのファイル形式も異なる場合があります。これは絶対的なものではありません。バイナリの ELF 形式は多くのオペレーティング システムで使用されており、Microsoft は現在のすべてのオペレーティング システムで PE 形式を使用しています。どちらの場合も、形式はバイナリの正確な形式を記述するため、OS はプログラムを OS に接続できるかどうかを判断できます。たとえば、Win32 バイナリの場合、PE 形式であるため、Linux はそれを読み込みませんが、Windows 2000 は読み込み、Windows 7-64 は読み込みます。一方、Win64 バイナリも PE 形式ですが、Windows 2000 はそれを拒否します。