ファットバイナリ

1988年、アポロコンピュータのDomain/OS SR10.1では、 Motorola 680x0とApollo PRISMの実行可能ファイルのバイナリをバンドルした新しいファイルタイプ「cmpexe」（複合実行可能ファイル）が導入されました。^{[ 4 ]}

ファットバイナリ方式は、1994 年に始まったApple Macintoshの68kマイクロプロセッサからPowerPCマイクロプロセッサへの移行をスムーズにしました。古いプラットフォーム向けの多くのアプリケーションは、進化するエミュレーション方式の下で新しいプラットフォーム上で透過的に実行されましたが、エミュレートされたコードは一般的にネイティブ コードよりも遅く実行されます。「ファットバイナリ」としてリリースされたアプリケーションはより多くのストレージ スペースを消費しましたが、どちらのプラットフォームでもフルスピードで実行されました。これは、同じプログラムの 68k コンパイル バージョンと PowerPC コンパイル バージョンの両方を実行可能ファイルにパッケージ化することによって実現されました。^{[ 5 ] [ 6 ]}古い 68k コード (CFM-68K またはクラシック 68K) は引き続きリソース フォークに格納され、新しい PowerPC コードはPEF形式でデータ フォークに格納されました。^{[ 7 ] [ 8 ] [ 9 ]}

ファットバイナリは、PowerPCまたは68kのみをサポートするプログラムよりも大きかったため、不要なバージョンを削除するユーティリティが多数作成されました。^{[ 5 ] [ 6 ]} 80MBハードドライブが一般的なサイズであった小型ハードドライブの時代には、プログラムコードがドライブ全体の使用率の大部分を占めていたため、ファットバイナリの不要なメンバーを削除することでハードドライブのかなりのスペースを解放できたため、これらのユーティリティは役に立つことがありました。

Intel 8080 (およびZilog Z80 ) プロセッサフ​​ァミリ用のCP/M-80、MP/M-80、Concurrent CP/M、CP/M Plus、Personal CP/M-80、SCP 、およびMSX-DOS実行ファイルは、 Intel 8086バイナリ用のDOS互換オペレーティングシステムと同じ.COMファイル拡張子を使用します。^{[ nb 1 ]}どちらの場合も、プログラムはオフセット +100h にロードされ、ファイルの最初のバイトにジャンプして実行されます。^{[ 14 ] [ 15 ]} 2 つのプロセッサフ​​ァミリのオペコードは互換性がないため、間違ったオペレーティングシステムでプログラムを開始しようとすると、不正確で予測不可能な動作が発生します。

これを回避するために、CP/M-80 プログラムと DOS プログラムの両方を含むファット バイナリを作成する方法が考案されており、その前には両方のプラットフォームで正しく解釈される初期コードが続きます。^{[ 15 ]}これらの方法は、それぞれの環境用に作成された完全に機能する 2 つのプログラムを組み合わせるか、間違ったプロセッサで開始された場合にプログラムが適切に終了するようにするスタブを追加します。これが機能するためには、.COM ファイルの最初の数個の命令 (ガジェット ヘッダーとも呼ばれます^{[ 16 ]} ) が 8086 プロセッサと 8080 プロセッサの両方で有効なコードである必要があり、これによりプロセッサはコード内の異なる場所に分岐します。^{[ 16 ]} 例えば、Simeon Cran のエミュレータ MyZ80 のユーティリティは、オペコード シーケンスEBh、52h、EBhで始まります。^{[ 17 ] [ 18 ]} 8086 はこれをジャンプとみなし、オフセット +154h から次の命令を読み取りますが、8080 または互換プロセッサはそのまま進み、+103h から次の命令を読み取ります。この目的で使用される同様のシーケンスはEBh、03h、C3hです。^{[ 19 ] [ 20 ]} John C. Elliott の FATBIN ^{[ 21 ] [ 22 ] [ 23 ]}は、CP/M-80 と DOS .COM ファイルを 1 つの実行可能ファイルに結合するユーティリティです。^{[ 17 ] [ 24 ]}彼のオリジナルのPMsfxの派生版は、吉彦美野のPMarcによって作成されたアーカイブをCP/M-80 と DOS の両方で自己解凍できるように変更し、 EBh、18h、2Dh、70h、6Dh、73h、2Dhから始めて、自己解凍PMAアーカイブの "-pms-" シグネチャも含めるようにし、^{[ 25 ] [ 17 ] [ 24 ] [ 18 ]}それによって実行可能な ASCII コードの一形式も表しています。

DOS互換オペレーティングシステムがCP/M-80およびMSX-DOSマシン用の.COMプログラムを誤って実行しないようにするもう1つの方法は^{[ 15 ]}、8080コードをC3h、03h、01hで開始することです。これはx86プロセッサによって「RET」命令としてデコードされ、プログラムを正常に終了しますが^{[ nb 2 ]}、8080プロセッサでは「JP 103h」命令としてデコードされ、プログラム内の次の命令にジャンプするだけです。同様に、SLR SystemsのCP/MアセンブラZ80ASM+は、DOS上で誤って実行されるとエラーメッセージを表示します。^{[ 17 ]}

CP/M-80 3.0 .COM ファイルの中には、 GENCOMによって1 つ以上のRSXオーバーレイが添付されているものがあります。^{[ 26 ]}その場合、ファイルは追加の256 バイトのヘッダー (1ページ) で始まります。これを示すために、ヘッダーの最初のバイトはマジック バイトC9hに設定されます。これは、このタイプの COM ファイルを CP/M 3.0実行可能ローダーに識別する署名として機能するだけでなく、8080 互換プロセッサ用の「RET」命令としても機能し、古いバージョンの CP/M-80 でファイルが実行された場合に正常な終了につながります。^{[ nb 2 ]}

C9h は、どの x86 プロセッサでもプログラムの最初のバイトとして適切ではありません (世代によって意味が異なりますが、^{[ nb 3 ]}意味のある最初のバイトではありません)。DOS の一部のバージョンの実行可能ローダーは、C9hで始まる COM ファイルを拒否し、誤った動作を回避します。

同様の重複コードシーケンスは、Z80/ 6502 ^{[ 17 ]}、8086/ 68000 ^{[ 17 ]}、またはx86/ MIPS / ARMバイナリの組み合わせに対しても考案されている。^{[ 16 ]}

CP/M-86と DOS は実行可能ファイルのファイル拡張子を共有していません。^{[注 1 ]}そのため、通常は実行可能ファイルを混同することはありません。しかし、初期の DOS はアーキテクチャの点で CP/M と非常に多くの共通点があったため、初期の DOS プログラムの中には、実行可能コードを含むバイナリを共有するように開発されたものもありました。これを行ったことが知られているプログラムの 1 つはWordStar  3.2xで、 CP/M-86 とMS-DOSの移植版で同一のオーバーレイ ファイルを使用し、^{[ 27 ]}実行時にこれらのオペレーティングシステムの異なる呼び出し規約に適応するために動的に修正されたコードを使用していました。^{[ 27 ]}

Digital ResearchのCP/M-86およびDOS用のGSXも、バイナリ的に同一の16ビットドライバを共有している。^{[ 28 ]}

DOSデバイス ドライバ(通常、ファイル拡張子は.SYS ) は、慣例として最初の 4 バイトがFFFFFFFFhであるファイル ヘッダーで始まりますが、これは必須ではありません。 ^{[ 29 ]}これは、ドライバがロードされるとき(通常、DOS BIOSでCONFIG.SYSのDEVICEステートメントを実行するとき) にオペレーティングシステムによって動的に修正されます。DOS は、DEVICE ごとにロードされる .COM 拡張子のファイルを拒否せず、FFFFFFFFh をテストしないため、組み込み COM プログラムのエントリ ポイントへのジャンプ命令をファイルの最初の 4 バイト (通常は 3 バイトで十分) 内に配置することで、COM プログラムとデバイス ドライバを同じファイルに結合^{することが可能です}。^{[ 30] [ 29 ]}組み込みプログラムとデバイス ドライバのセクションが共通のコードまたはデータの一部を共有している場合、コードは、オフセット +0100h で .COM スタイルのプログラムとして、また +0000h でデバイス ドライバとしてロードされることを処理する必要があります。^{[ 30 ]}位置に依存しないよう^に設計されていない共有コードが「間違った」オフセットにロードされた場合、再配置ローダーによって既に実行されていたものと同様の内部アドレス修正が必要になります。ただし、^{この場合はロードされたプログラム自体が修正を}行う必要があります。これは自己再配置ドライバの状況に似ていますが、プログラムは既にオペレーティングシステムのローダーによってターゲットの場所にロードされています。

DOS では、慣例として、実際のファイルの種類を反映しないファイル拡張子を持つファイルがあります。^{[ nb 4 ]}例えば、COUNTRY.SYS ^{[ 31 ]}は DOS デバイス ドライバではなく、^{[ nb 5 ]} CONFIG.SYS COUNTRY ディレクティブとNLSFUNCドライバで使用するバイナリNLSデータベース ファイルです。^{[ 31 ]}同様に、PC DOSおよびDR-DOSシステム ファイルIBMBIO.COMおよびIBMDOS.COM は、ブートストラップ ローダーによってロードされる特別なバイナリ イメージであり、COM スタイルのプログラムではありません。^{[ nb 5 ]} DEVICE ステートメントを使用して COUNTRY.SYS をロードしようとしたり、コマンド プロンプトで IBMBIO.COM または IBMDOS.COM を実行したりすると、予期しない結果が生じます。^{[ nb 4 ] [ nb 6 ]}

上記と同様の手法を用いることで、これを回避できる場合もあります。例えば、DR-DOS 7.02以降では、Matthias R. Paulによって開発された安全機能が組み込まれています。^{[ 32 ]}これらのファイルが不適切に呼び出された場合、埋め込まれた小さなスタブがファイルのバージョン情報を表示して正常に終了します。^{[ 33 ] [ 32 ] [ 34 ] [ 31 ]}さらに、メッセージは、外部のNetWare & DR-DOS VERSIONファイル識別ユーティリティによって認識される特定の「マジック」パターンに従うように特別に作成されています。^{[ 31 ] [ 32 ] [ nb 7 ]}

同様の保護機能として、Jay Sage と Joe Wright のZ-Systemタイプ 3 およびタイプ 4 の "Z3ENV" プログラム^{[ 35 ] [ 36 ]}および "Z3TXT" 言語オーバーレイ ファイル^{[ 37 ]}の冒頭に 8080 命令C7h ("RST 0" ) があり、不適切にロードされた場合、CP/M-80 ではクラッシュではなくウォームブートとなる^{[ 35 ] [ 36 ] [ 37 ] [ nb 2 ]があった。} 

非常に似たような方法で、多くの（バイナリ）ファイル形式は慣例としてファイルの先頭付近に1Ahバイト（ASCII ^Z ）を含んでいます。この制御文字は、ファイルが非バイナリモードで開かれたときに「ソフト」ファイル終了（EOF）マーカーとして解釈されるため、多くのオペレーティングシステム（PDP-6モニタ^{[ 38 ]}、RT-11、VMS、TOPS-10 ^{[ 39 ]}、CP/M ^{[ 40 ] [ 41 ]}、DOS ^{[ 42 ]} 、 Windows ^{[ 43 ]}など）では、コンソールでファイルが誤って出力されたときに「バイナリのゴミ」が表示されるのを防ぎます。

FatELF ^{[ 44 ]}は、 Linuxやその他のUnix ライクなオペレーティングシステム向けのファットバイナリ実装でした。技術的には、FatELF バイナリは、どのアーキテクチャでどのバイナリを使用するかを示すメタデータを含むELFバイナリの連結でした。 ^{[ 45 ]} CPU アーキテクチャの抽象化 (バイト順序、ワードサイズ、CPU命令セットなど) に加えて、複数のカーネルABIとバージョンをサポートするバイナリの利点があります。

開発者によると、FatELFにはいくつかのユースケースがある。^{[ 44 ]}

• 配布版では、様々なプラットフォーム向けに個別のダウンロードファイルを用意する必要がなくなりました。
• OS ディレクトリ構造において、 /lib、/lib32、/lib64の分離ツリーはもはや必要ありません。
• 適切なバイナリとライブラリは、シェルスクリプトではなくシステムによって一元的に選択されます。
• 将来ELF ABIが変更された場合でも、既存ユーザーへのサポートは継続されます。
• 複数のプラットフォームでそのまま動作するウェブブラウザプラグインの配布。
• LinuxおよびBSD系OS間で動作する単一のアプリケーションファイルを、プラットフォーム互換性レイヤーなしで配布する。
• 開発や実験のために、1つのハードディスクパーティションを異なるCPUアーキテクチャを持つ複数のマシンで起動できます。ルートファイルシステムは同じですが、カーネルとCPUアーキテクチャが異なります。
• ネットワーク共有やUSBメモリで提供されるアプリケーションは、複数のシステムで動作します。これは、ポータブルアプリケーションや、異種システム向けのクラウドコンピューティングイメージを作成する際にも役立ちます。^{[ 46 ]}

概念実証用のUbuntu 9.04イメージが利用可能です。^{[ 47 ]} 2021年現在FatELFはLinuxカーネルのメインラインには統合されていません。^{[ 48 ] [ 49 ]}

Windowsで使用されるポータブル実行可能ファイル形式ではプラットフォームへのコード割り当てはできませんが、アーキテクチャに基づいてディスパッチするローダープログラムを作成することは可能です。これは、ARM上のWindowsデスクトップ版が32ビットx86エミュレーションをサポートしているため、有用な「ユニバーサル」マシンコードターゲットとなるからです。Fatpackは、この概念を示すローダーです。リソースセクションにパックされた実行可能ファイルを1つずつ実行しようとする32ビットx86プログラムが含まれています。^{[ 50 ]}

Windows 11 ARM64 の開発時に、Microsoft はArm64X と呼ばれるPortable Executableフォーマットを拡張する新しい方法を導入しました。 ^{[ 51 ]} Arm64X バイナリには、個別の x64/Arm64EC バイナリと Arm64 バイナリに含まれるすべてのコンテンツが含まれていますが、ディスク上でより効率的な 1 つのファイルに統合されています。Visual C++ ツールセットは、このようなバイナリの生成をサポートするようにアップグレードされています。また、Arm64X バイナリのビルドが技術的に難しい場合は、開発者は代わりに Arm64X ピュアフォワーダー DLL をビルドできます。^{[ 52 ]}

2007 年以降、異種プラットフォーム向けの特殊なコンパイラの中には、複数の種類のプロセッサ上で並列実行するためのコード ファイルを生成するものがあります。例えば、 Intel EXOCHI (Exoskeleton Sequencer) 開発スイートのCHI ( C for Heterogeneous Integration) コンパイラは、マルチスレッド用のOpenMPプラグマの概念を拡張し、異なる命令セット アーキテクチャ(ISA)用のコード セクションを含むファット バイナリを生成します。これにより、ランタイムローダは、異種システム環境で利用可能な複数の CPU コアとGPUコア上で並列実行を動的に開始できます。 ^{[ 53 ] [ 54 ]}

2006 年に導入されたNvidiaの並列コンピューティング プラットフォームCUDA (Compute Unified Device Architecture) は、GPU 上での汎用コンピューティング ( GPGPU ) を可能にするソフトウェアです。そのLLVMベースのコンパイラNVCC は、いわゆるPTX仮想アセンブリ(テキストとして) を含むELFベースのファット バイナリを作成できます。CUDAランタイム ドライバは、これを後で、実際に存在するターゲット GPU 用のSASS (Streaming Assembler ) バイナリ実行可能コードにジャストインタイムでコンパイルできます。実行可能ファイルには、CUDA ランタイムがロード時に選択できる、1 つ以上の特定の GPU アーキテクチャ専用の実行可能コード セクションを含む、いわゆるCUDA バイナリ(別名cubinファイル) も含まれる場合があります。 ^{[ 55 ] [ 56 ] [ 57 ] [ 58 ] [ 59 ] [ 60 ]}ファット バイナリは、2007 年に導入された GPUシミュレータであるGPGPU-Simでもサポートされています。^{[ 61 ] [ 62 ]}

Multi2Sim (M2S) は、OpenCL の異種システムシミュレータフレームワークであり (当初はMIPSまたは x86 CPUのみに対応していましたが、後にARM CPU や、AMD / ATI EvergreenおよびSouthern Islands 、 Nvidia FermiおよびKeplerファミリーなどの GPU もサポートするように拡張されました) ^{[ 63 ]}、ELF ベースのファットバイナリもサポートしています。^{[ 64 ] [ 63 ]}

GNU Compiler Collection (GCC) と LLVM にはファットバイナリ形式はありませんが、リンク時最適化(LTO)用のファットオブジェクトファイルがあります。LTO ではコンパイルをリンク時まで遅らせるため、オブジェクトファイルには中間表現(IR)を格納する必要がありますが、一方で (速度や互換性のために) マシンコードも格納する必要がある場合があります。IR とマシンコードの両方を含む LTO オブジェクトはファットオブジェクトとして知られています。^{[ 65 ]}

同じ命令セットアーキテクチャを対象とするプログラムやライブラリであっても、プログラマは古いCPUとの互換性を維持しながら、より新しい命令セット拡張機能を利用したい場合があります。これは、関数マルチバージョニング（FMV）によって実現できます。同じ関数のバージョンがプログラムに書き込まれ、コードの一部がCPUの機能（CPUIDなどを介して）を検出して、どのバージョンを使用するかを決定します。Intel C++ Compiler、GCC、およびLLVMはすべて、マルチバージョン関数を自動的に生成する機能を備えています。^{[ 66 ]}これは、意味的な影響のない動的ディスパッチの一種です。

多くの数学ライブラリには、CPU の機能に応じて自動的に選択される手書きのアセンブリルーチンが備わっている。例としては、glibc、Intel MKL、OpenBLASなどがある。さらに、glibc のライブラリローダーは、特定の CPU 機能のために代替パスからのロードをサポートしている。^{[ 67 ]}

同様の、しかしバイトレベルの粒度を持つアプローチは、元々は Matthias R. Paul と Axel C. Frinke によって考案されたもので、実行可能ファイルに埋め込まれた小さな自己破棄、緩和、再配置ローダーと、任意の数の代替バイナリ コード スニペットによって、ロード時に特定のターゲット環境で特定の機能を実行する（または実行しない）ために必要なプログラムまたはドライバのサイズまたは速度が最適化されたランタイム イメージを条件付きで構築するというものです。これは、ある種の動的デッド コード除去(DDCE)によって実現されます。 ^{[ 68 ] [ 69 ] [ 70 ] [ 71 ]}