ポータブル実行ファイル

ポータブル実行可能ファイル( PE ) 形式は、32 ビット版および 64 ビット版の Windows オペレーティング システム、および UEFI 環境で使用される実行可能ファイル、オブジェクト コード、DLL などのファイル形式です。[ 2 ] PE形式は、 Windows OSローダーがラップさ^れた実行可能コードを管理するために必要な情報をカプセル化するデータ構造です。これには、リンク用の動的ライブラリ参照、APIエクスポートおよびインポート テーブル、リソース管理データ、スレッド ローカル ストレージ(TLS) データが含まれます。NT オペレーティング システムでは、 PE 形式はEXE、DLL、SYS (デバイス ドライバー)、MUI、およびその他のファイル タイプに使用されます。Unified Extensible Firmware Interface (UEFI)仕様では、PE が EFI 環境の標準実行可能形式であると規定されています。^[3]

Windows NT オペレーティングシステムでは、PE は現在IA-32、x86-64 (AMD64/Intel 64)、IA-64、ARM、ARM64 命令セットアーキテクチャ(ISA) をサポートしています。Windows 2000より前は、Windows NT (および PE) はMIPS、Alpha、およびPowerPC ISA をサポートしていました。PE はWindows CEで使用されるため、MIPS、 ARM ( Thumbを含む)、およびSuperH ISAのいくつかのバリエーションを引き続きサポートします。^[4]

PE に類似した形式としては、ELF ( LinuxおよびUnixのほとんどの他のバージョンで使用) とMach-O ( macOSおよびiOSで使用) があります。

Microsoft は、Windows NT 3.1オペレーティング システムの導入に伴い、16 ビットNE形式から PE 形式に移行しました。Windows 95/98/ME やWindows 3.1x に追加されたWin32sなど、それ以降のすべてのバージョンの Windows は、このファイル構造をサポートしています。この形式は、 DOSベース システムと NT システムの間のギャップを埋めるために、限定的なレガシー サポートを保持しています。たとえば、PE/COFF ヘッダーには、DOS 実行可能プログラムがまだ含まれています。これは、デフォルトでは「このプログラムは DOS モードで実行できません」などのメッセージを表示するDOS スタブですが、プログラムの完全な DOS バージョンになることもあります (後の注目すべきケースは、Windows 98 SE インストーラーです)。Microsoft のリンカーには、これをアタッチするスイッチがあります。^{[5]これは、}ファット バイナリの一種です。 /STUB

PE は、変化し続ける Windows プラットフォームにも引き続き対応しています。拡張機能には、.NET PE 形式、PE32+ と呼ばれる 64 ビット アドレス空間をサポートするバージョン、Windows CE の仕様などがあります。

実行可能コードが32ビットか64ビットかは、IMAGE_FILE_HEADERのMachineフィールドをチェックすることで確認できます。^[6]実行可能ファイル内のアドレスが32ビットか64ビットかは、IMAGE_OPTIONAL_HEADERのMagicフィールドをチェックすることで確認できます。10B _16はPE32ファイルを示し、20B _16はPE32+ファイルを示します。^[7]

PE ファイルは、ファイルをメモリにマップする方法を動的リンカーに通知する多数のヘッダーとセクションで構成されています。実行可能イメージは複数の異なる領域で構成され、それぞれに異なるメモリ保護が必要です。そのため、各セクションの開始はページ境界に揃える必要があります。 ^[8]たとえば、通常、.textセクション (プログラム コードを保持) は実行/読み取り専用としてマップされ、.dataセクション (グローバル変数を保持) は実行不可/読み取り書き込みとしてマップされます。ただし、スペースの無駄を避けるため、各セクションはディスク上でページ揃えされていません。動的リンカーの仕事の一部は、各セクションを個別にメモリにマップし、ヘッダーにある指示に従って、結果の領域に適切な権限を割り当てることです。^[9]

注目すべきセクションの 1 つは、インポート アドレス テーブル(IAT) です。これは、アプリケーションが別のモジュールの関数を呼び出すときにルックアップ テーブルとして使用されます。これは、順序によるインポートと名前によるインポートの両方の形式になります。コンパイルされたプログラムは、依存するライブラリのメモリ位置を知ることができないため、API 呼び出しが行われるたびに間接ジャンプが必要になります。動的リンカーはモジュールをロードして結合するときに、実際のアドレスを IAT スロットに書き込み、対応するライブラリ関数のメモリ位置を指すようにします。これにより、モジュール内呼び出しのコストに余分なジャンプが追加され、パフォーマンスが低下しますが、重要な利点があります。ローダーによってコピーオンライトで変更される必要があるメモリ ページの数が最小限に抑えられ、メモリとディスクの I/O 時間が節約されます。コンパイラが、呼び出しがモジュール間になることを事前に知っている場合 (dllimport 属性経由)、間接呼び出しオペコードになるだけの、より最適化されたコードを生成できます。 [ ^9]

PE ファイルには、通常、位置独立コードが含まれていません。代わりに、優先ベース アドレスにコンパイルされ、コンパイラ/リンカーによって発行されるすべてのアドレスは事前に固定されます。PE ファイルを優先アドレスにロードできない場合 (すでに他の何かによって使用されているため)、オペレーティング システムはそれをリベースします。これには、すべての絶対アドレスの再計算と、新しい値を使用するようにコードの変更が含まれます。ローダーは、優先ロード アドレスと実際のロード アドレスを比較し、デルタ値を計算することでこれを実行します。次に、これを優先アドレスに追加して、メモリ位置の新しいアドレスを作成します。ベース再配置はリストに格納され、必要に応じて既存のメモリ位置に追加されます。結果として得られるコードはプロセス専用になり、共有できなくなります。そのため、このシナリオでは、DLL のメモリ節約の利点の多くが失われます。また、モジュールのロード速度が大幅に低下します。このため、リベースは可能な限り回避する必要があり、Microsoft が出荷する DLL では、ベース アドレスが重複しないように事前に計算されています。したがって、リベースがない場合、PE は非常に効率的なコードという利点がありますが、リベースがある場合、メモリ使用量が大きくなる可能性があります。これは、ロード時の再配置よりも完全に位置に依存しないコードが優先されることが多いELFとは対照的であり、実行時間を犠牲にしてメモリ使用量を削減します。

.NET 実行可能ファイルでは、PE コード セクションに、Visual Basic実行可能ファイルの場合と同様に、CLR仮想マシンのスタートアップ エントリ_CorExeMain(または) を呼び出すスタブが含まれています。仮想マシンは、存在する .NET メタデータを使用します。そのルート(「CLR ヘッダー」とも呼ばれます)は、 PE ヘッダーのデータ ディレクトリのエントリ(このエントリは、以前はCOM+ アプリケーションのCOM+メタデータに使用されていたため、名前は^{[引用が必要]}です) によってポイントされます。PEのオプション ヘッダーに非常によく似ており、基本的に CLR ローダーの役割を果たします。^[4]_CorDllMainmscoree.dllIMAGE_COR20_HEADERIMAGE_DIRECTORY_ENTRY_COMHEADERIMAGE_COR20_HEADER

ルート構造自体を含む CLR 関連データは、通常、共通コード セクションに含まれています.text。これは、メタデータ、埋め込みリソース、厳密な名前、およびネイティブ コードの相互運用性のためのいくつかのディレクトリで構成されています。メタデータ ディレクトリは、アセンブリ内のすべての個別の .NET エンティティ (型、メソッド、フィールド、定数、イベント、およびそれらの間の参照と他のアセンブリへの参照) を一覧表示するテーブルのセットです。

PE 形式はReactOSでも使用されています。ReactOS は Windows とのバイナリ互換性を目的としているためです。歴史的には、 SkyOSやBeOS R3など、他の多くのオペレーティング システムでも使用されていました。ただし、SkyOS と BeOS はどちらも最終的にELFに移行しました。^{[引用が必要]}

Mono 開発プラットフォームは、 Microsoft .NET Frameworkとのバイナリ互換性を保つことを意図しているため、Microsoft 実装と同じ PE 形式を使用します。Microsoft 独自のクロスプラットフォーム.NET Coreについても同様です。

x86 (-64) Unix ライクなオペレーティング システムでは、Windows バイナリ (PE 形式) をWineで実行できます。HX DOS Extender はネイティブ DOS 32 ビット バイナリに PE 形式も使用し、ある程度は既存の Windows バイナリを DOS で実行できるため、DOS 用の Wine と同等の働きをします。

Mac OS X 10.5はPEファイルを読み込み解析する機能を持っていますが、Windowsとのバイナリ互換性はありません。^[10]

UEFIおよび EFI ファームウェアは、アプリケーションに対してポータブル実行可能ファイルと Windows ABI x64呼び出し規約を使用します。

• a.アウト
• 実行ファイル形式の比較
• 実行ファイルの圧縮
• ar (Unix)すべてのCOFFライブラリが同じ形式を使用するため
• アプリケーション仮想化

• PE 形式 (最新のオンライン ドキュメント、時間による変更)
• Microsoft ポータブル実行可能ファイルおよび共通オブジェクト ファイル形式の仕様。リビジョン 11.0、2017 年 1 月、リビジョン 10.0、2016 年 6 月、リビジョン 8.3、2013 年 2 月、リビジョン 8.2、2010 年 9 月、リビジョン 8.1、2008 年 2 月、リビジョン 8.0、2006 年 5 月、リビジョン 6.0、1999 年 2 月、リビジョン 5.0、1997 年 10 月、リビジョン 4.1、1994 年 8 月、リビジョン 4.0、1993 年 9 月
• Windows 用ツール インターフェイス標準 (TIS) フォーマット仕様 バージョン 1.0 (Intel 注文番号 241597、TIS 委員会、1993 年 2 月)
• ポータブル実行可能形式 (Micheal J. O'Leary、Microsoft 開発者サポート)
• PE の内部を覗く: Win32 ポータブル実行可能ファイル形式のツアー。Matt Pietrek、Microsoft Systems Journal、1994 年 3 月
• Win32 ポータブル実行可能ファイル形式の徹底解説。Matt Pietrek、MSDNマガジン。パート I、2002 年 2 月、パート II、2002 年 3 月
• .NET ファイル形式 (Daniel Pistelli 著)
• Ero CarreraのブログではPEヘッダーとその使い方について説明しています
• PE内部はポータブル実行ファイル形式を簡単に学習する方法を提供します
• PE エクスプローラー