ファットバイナリ

ファットバイナリ（またはマルチアーキテクチャバイナリ）は、複数の命令セットに固有のコードで拡張（または「ファット化」）され、複数のプロセッサタイプで実行できるコンピュータ実行可能プログラムまたはライブラリです。 ^[1]これにより、通常の1つのアーキテクチャのバイナリファイルよりも大きなファイルが作成されるため、この名前が付けられています。

通常の実装方法は、各命令セットのマシン コードのバージョンを組み込み、その前にすべてのオペレーティング システムと互換性のあるコードを含む単一のエントリ ポイントを配置し、適切なセクションへのジャンプを実行するというものです。別の実装では、異なる実行可能ファイルを異なるフォークに格納し、それぞれにオペレーティング システムによって直接使用される独自のエントリ ポイントがあります。

ファットバイナリの使用はオペレーティングシステムソフトウェアでは一般的ではありません。同じ問題を解決するには、インストール時にアーキテクチャ固有のバイナリを選択するインストーラプログラムの使用（ Androidの複数のAPKなど）、実行時にアーキテクチャ固有のバイナリを選択する（Plan 9のユニオンディレクトリやGNUstepのファットバンドルなど)、^{[2] [3]}ソースコード形式でソフトウェアを配布し、その場でコンパイルしたり、仮想マシン( Javaなど)を使用してジャストインタイムコンパイルを行う方法がある。

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

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

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

ファットバイナリは、 NeXTのNeXTSTEP / OPENSTEPオペレーティングシステムの機能であり、NeXTSTEP 3.1 から始まりました。NeXTSTEP では、「マルチアーキテクチャバイナリ」と呼ばれていました。マルチアーキテクチャバイナリは元々、ソフトウェアをコンパイルして、NeXT の Motorola 68k ベースのハードウェアと、NeXTSTEP を実行している Intel IA-32ベースのPCの両方で実行できるようにすることを目的としていました。両方のプラットフォーム用の単一のバイナリファイルがありました。^{[10]これは後に、OPENSTEP アプリケーションを PC と OPENSTEP がサポートするさまざまな}RISCプラットフォームで実行できるようにするために使用されました。マルチアーキテクチャバイナリファイルは特別なアーカイブ形式であり、1 つのファイルに、マルチアーキテクチャバイナリでサポートされている各アーキテクチャの1 つ以上のMach-Oサブファイルが格納されます。すべてのマルチアーキテクチャバイナリは、2 つの符号なし整数を含む構造体 ( ) で始まります。最初の整数 (「マジック」) は、このファイルをファットバイナリとして識別するためのマジックナンバーstruct fat_headerとして使用されます。 2 番目の整数 ( nfat_arch ) は、アーカイブに含まれる Mach-O ファイルの数 (異なるアーキテクチャの同じプログラムのインスタンスの数) を定義します。このヘッダーの後には、nfat_arch個の fat_arch 構造体 ( ) があります。この構造体は、ファイルを検索するオフセット (ファイルの先頭から)、アラインメント、サイズ、および Mach-O バイナリ (アーカイブ内) が対象とする CPU タイプとサブタイプを定義します。 struct fat_arch

開発ツールに同梱されているGNU コンパイラ コレクションのバージョンでは、NeXTStepが実行できるさまざまなアーキテクチャのソース コードをクロスコンパイルできました。たとえば、複数の '-arch' オプション (アーキテクチャを引数として指定) を使用してターゲット アーキテクチャを選択できました。これは、さまざまなアーキテクチャで実行される NeXTStep のプログラムを配布する便利な方法でした。

異なるターゲット オブジェクト ファイルを使用して ライブラリを作成することも可能でした (たとえば、NeXTStep のlibtoolを使用)。

アップルコンピュータは1996年にNeXTを買収し、OPENSTEPコードを使い続けた。Mach-Oはアップルの無料のDarwinオペレーティングシステム（2000年）とアップルのMac OS X（2001年）のネイティブオブジェクトファイル形式となり、NeXTのマルチアーキテクチャバイナリはオペレーティングシステムで引き続きサポートされた。Mac OS Xでは、マルチアーキテクチャバイナリを使用して、たとえばPowerPC G3、PowerPC G4、およびPowerPC 970世代のプロセッサに最適化された32ビットコードの異なるバージョンを持つなど、アーキテクチャの複数のバリアントをサポートできる。また、32ビットと64ビットのPowerPC、PowerPCとx86、x86-64とARM64など、複数のアーキテクチャをサポートするためにも使用できる。^[11]

2005年、AppleはPowerPCプロセッサからIntel x86プロセッサへの新たな移行を発表しました。Appleは、マルチアーキテクチャバイナリ形式の実行ファイルを使用して、PowerPCとx86の両方をネイティブにサポートする新しいアプリケーションの配布を促進しました。^[12] Appleはそのようなプログラムを「ユニバーサルアプリケーション」と呼び、ファイル形式を「ユニバーサルバイナリ」と呼んでいますが、これはおそらく、この新しい移行を以前の移行やマルチアーキテクチャバイナリ形式の他の用途と区別する方法です。

ユニバーサルバイナリ形式は、既存のネイティブ PowerPC アプリケーションのフォワードマイグレーションには必要ありませんでした。2006 年から 2011 年にかけて、Apple は、この役割を果たすために、PowerPC (PPC) から x86 への動的バイナリトランスレータであるRosetta を提供しました。ただし、Rosetta のパフォーマンスオーバーヘッドはかなり急であったため、開発者はユニバーサルバイナリを使用して、PPC と Intel の両方のバイナリを提供するように推奨されました。ユニバーサルバイナリの明らかなコストは、インストールされるすべての実行可能ファイルが大きくなることですが、PPC のリリースから数年の間に、ハードドライブの容量は実行可能ファイルのサイズを大幅に上回っています。ユニバーサルバイナリは、同じアプリケーションの単一プラットフォームバージョンの 2 倍のサイズになる可能性がありますが、空き領域リソースは一般にコードサイズをはるかに上回るため、これは小さな問題になります。実際、プログラムリソースを重複させるのではなく共有できるため、ユニバーサルバイナリアプリケーションは、2 つの単一アーキテクチャアプリケーションよりも小さくなることがよくあります。すべてのアーキテクチャが必要でない場合は、lipoおよびdittoコマンドライン アプリケーションを使用して、マルチアーキテクチャ バイナリ イメージからバージョンを削除し、いわゆる「シン バイナリ」を作成できます。

さらに、マルチアーキテクチャ バイナリ実行可能ファイルには、PowerPC および x86 の 32 ビット バージョンと 64 ビット バージョンの両方のコードを含めることができるため、アプリケーションは 32 ビット プロセッサをサポートする形式で出荷され、64 ビット プロセッサで実行されるときには、より大きなアドレス空間とより広いデータ パスを利用できます。

Xcode開発環境のバージョン2.1 から 3.2 ( Mac OS X 10.4からMac OS X 10.6で実行) では、アプリケーションを Intel と PowerPC の両方のアーキテクチャを対象にできるようにするユーティリティが Apple に含まれていました。ユニバーサル バイナリには、最終的に最大 4 つのバージョンの実行可能コード (32 ビット PowerPC、32 ビット x86、64 ビット PowerPC、および64 ビット x86 ) を含めることができます。ただし、PowerPC サポートは Xcode 4.0 から削除されたため、 Mac OS X 10.7以降を 実行している開発者は利用できません。

2020年に、AppleはIntel x86プロセッサからAppleシリコン（ARM64アーキテクチャ）への新たな移行を発表しました。移行をスムーズにするために、AppleはUniversal 2バイナリ形式のサポートを追加しました。Universal 2バイナリファイルは、x86-64とARM64の両方の実行可能コードを含むマルチアーキテクチャバイナリファイルであり、バイナリを64ビットIntelと64ビットAppleシリコンの両方でネイティブに実行できます。さらに、Appleはx86から​​Arm64命令セットへのRosetta 2動的バイナリ変換を導入し、ユーザーがUniversalバイナリバリアントを持たないアプリケーションを実行できるようにしました。

2006年、AppleはPowerPCからIntel CPUに切り替え、Open FirmwareをEFIに置き換えました。しかし、2008年までに、一部のMacは32ビットEFIを使用し、一部は64ビットEFIを使用するようになりました。このため、Appleは32ビットと64ビットの両方のEFIバイナリを含む「ファット」バイナリでEFI仕様を拡張しました。^[13]

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ファイル拡張子を使用します。^{[注 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によって作成されたアーカイブを、 EBh、18h、2Dh、70h、6Dh、73h、2Dhで始まり、自己解凍型PMAアーカイブの「-pms-」署名も含め、CP/M-80とDOSの両方で自己解凍可能になるように変更し、[ 25 ] [ 17 ] [ ^{24 ] [ 18]}実行可能なASCIIコードの形式も表しています。

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

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

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

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

CP/M-86と DOS は、実行可能ファイルの拡張子を共有していません。^{[注 1]}そのため、通常、実行可能ファイルを混同することはありません。ただし、DOS の初期バージョンは、アーキテクチャの点で CP/M と非常に多くの共通点があったため、初期の DOS プログラムの中には、実行可能コードを含むバイナリを共有するように開発されたものもありました。これを実現していたプログラムとして知られているのは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 をテストしないため、ファイルの最初の 4 バイト (通常は 3 バイトで十分) 内に埋め込まれた COM プログラムのエントリ ポイントへのジャンプ命令を配置することにより、COM プログラムとデバイス ドライバを同じ^{ファイルに}結合できます [30] [29]。^[29]埋め込まれたプログラムとデバイス ドライバのセクションが共通のコード部分またはデータを共有する場合、コードは、.COM スタイル プログラムとしてオフセット +0100h にロードされ、デバイス ドライバとして +0000h にロードされることを処理する必要があります。^[30]「間違った」オフセットでロードされたが、位置に依存しないように設計されていない共有コードの場合、内部アドレスの修正^{[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]}

同様の保護機能として、ジェイ・セージとジョー・ライトのZシステムタイプ3およびタイプ4の「Z3ENV」プログラム^{[35] [36]}と「Z3TXT」言語オーバーレイファイル^{[37]の冒頭にある8080命令}C7h （「RST 0」）があり、不適切にロードされた場合、CP/M-80では（クラッシュではなく）ウォームブートが発生します。 ^{[35] [36] [37] [注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 が変更された場合でも、従来のユーザーは引き続きサポートされます。
• 複数のプラットフォームですぐに使用できる Web ブラウザー プラグインの配布。
• プラットフォーム互換性レイヤーなしで、Linux およびBSD OSバリアント間で動作する 1 つのアプリケーション ファイルの配布。
• 開発や実験のために、1 つのハード ドライブ パーティションを、異なる CPU アーキテクチャを持つ異なるマシンで起動できます。同じルート ファイル システム、異なるカーネルお​​よび CPU アーキテクチャ。
• ネットワーク共有やUSBスティックで提供されるアプリケーションは、複数のシステムで動作します。これは、ポータブルアプリケーションや異機種システム用のクラウドコンピューティングイメージの作成にも役立ちます。^[46]

概念実証用のUbuntu 9.04イメージが利用可能である。^[47] 2021年現在^{[アップデート]}、FatELFはメインラインのLinuxカーネルに統合されていない。^{[要出典] [48] [49]}

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

Windows 11 ARM64を開発する際、マイクロソフトは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  [de]でもサポートされています。^{[61] [62]}

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

GNUコンパイラコレクション（GCC）とLLVMにはファットバイナリフォーマットはありませんが、リンク時最適化（LTO）用のファットオブジェクトファイルはあります。LTOはコンパイルをリンク時に遅らせるため、オブジェクトファイルは中間表現（IR）を格納する必要がありますが、一方でマシンコードも格納する必要がある場合があります（速度や互換性のため）。IRとマシンコードの両方を含むLTOオブジェクトはファットオブジェクトと呼ばれます。^[65]

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

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

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

• クロスプラットフォームソフトウェア
• DOS スタブ
• ファットポインタ
• リニア実行可能ファイル(LX)
• 新しい実行ファイル(NE)
• ポータブル実行可能ファイル(PE)
• 位置独立コード(PIC)
• 副作用
• ユニバーサル 16 進形式、複数のプラットフォームを対象とした「ファット」 16 進ファイル形式
• 英数字の実行可能ファイル、実行可能コードをテキスト（場合によっては判読可能なテキスト）として偽装したもの
• マルチアーキテクチャ シェルコード、複数のプラットフォームをターゲットとするシェルコード (場合によっては英数字のテキストに偽装される)

• Tunney, Justine Alexandra Roberts (2021-02-11). 「ファットバイナリはどの程度ファットにする必要があるのか​​？」。cosmopolitan libc - 一度ビルドすればどこでも実行できる C ライブラリ / Cosmopolitan Communiqué。 2021-09-12 にオリジナルからアーカイブ。 2021-09-12に取得。; Tunney, Justine Alexandra Roberts (2021-02-11). 「ファットバイナリはどの程度ファットにする必要があるのか​​?」Hacker News . 2021-06-01 にオリジナルからアーカイブ。2021-09-12に取得。
• Tunney, Justine Alexandra Roberts (2020-08-24). 「αcτµαlly pδrταblε εxεcµταblε (Ape)」。2021-09-12にオリジナルよりアーカイブ。2021-09-12に閲覧。
• Gotham, Frederick (2020-10-22). 「Linux および Mac 用の Fat Binary の作成」. Narkive . 2021-09-12 にオリジナルからアーカイブ。2021-09-12に取得。
• Gotham, Frederick (2020-10-24). 「Fat Binary - MS-Windows と 4 つの Linux」. Narkive . 2021-09-12 にオリジナルからアーカイブ。2021-09-12に取得。
• Gotham, Frederick (2020-11-02). 「Fat Binary - DOS Windows Linux」. Narkive . 2021-09-12 にオリジナルからアーカイブ。2021-09-12に取得。
• 「Amiga - StormC を PowerPC および p-OS 向けに WarpUP するために開発しました」。Haage & Partner GmbH。1996年 9 月。2017 年 12 月 6 日時点のオリジナルよりアーカイブ。2021年 9 月 29 日閲覧。
• Münch, Matthias (2006) [2005]. 「AmigaOS 3.9 - 機能」. AmigaOS: マルチメディア、マルチスレッド、マルチタスク。2021-09-29にオリジナルからアーカイブ。2021-09-29に取得。