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

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

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

アポロ

アポロの複合実行ファイル

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

りんご

Appleのファットバイナリ

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

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

NeXT/Appleのマルチアーキテクチャバイナリ

NeXTSTEP マルチアーキテクチャバイナリ

ファットバイナリは、 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を使用)。

Mach-O と Mac OS X

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

Appleのユニバーサルバイナリ

Appleユニバーサルバイナリロゴ

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

Apple Fat EFIバイナリ

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

CP/M と DOS

CP/M-80 と DOS 用の COM スタイルバイナリの組み合わせ

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で作成されたアーカイブを、EBh、18h、2Dh、70h、6Dh、73h、2Dhで始まり、CP/M-80とDOSの両方で自己解凍可能になるように修正し、自己解凍型PMAアーカイブの「-pms-」署名も含め、[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の統合バイナリ

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]

COMフ​​ァイルとSYSファイルの結合

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] [注 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: Linux 用ユニバーサルバイナリ

FatELFロゴ

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

開発者によると、FatELFにはいくつかの使用例がある。[44]

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

ウィンドウズ

ファットパック

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

アーム64X

Windows 11 ARM64の開発において、MicrosoftはPortable Executable形式を拡張する新しい方法であるArm64Xを導入しました。[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]

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

参照

注記

  1. ^ ab CP/M-86 、 CP /M-86 Plus 、Personal CP/M-86 、 S5-DOS 、Concurrent CP/M-86 、Concurrent DOS 、Concurrent DOS 286 、FlexOS、Concurrent DOS 386、DOS Plus、Multiuser DOS、System Manager、およびREAL/32の CP / M-86 スタイルの実行可能ファイルでは、ファイル拡張子.COMではなく.CMDが使用されるため、これは問題になりません。(ただし、.CMD 拡張子は、 OS /2およびWindows NTオペレーティング システム ファミリのコマンド ライン プロセッサCMD.EXE用に作成されたバッチジョブのファイル拡張子と競合します。)
  2. ^ abc CP/M-80、CP/M-86、DOSでは、オペコード、正確な条件、基本的なメカニズムは異なりますが、 （適切な）戻り命令を使用してプログラムを終了できるため、これが機能します。 CP/M-80 では、プログラムは、ゼロ ページの 0 にジャンプすることによって終了できます。これには、RST 0（8080 / 8085 / Z80オペコード C7h）で直接、またはCALL 5インターフェイスを通じてBDOS関数 0 を呼び出すことによって終了できます（つまり、BIOS にウォーム ブートします）。 あるいは、スタックは、ロードされたプログラムに制御を渡す前に0 の戻りアドレスを保持する準備ができているので、スタックがフラットである限り、RET（オペコード C9h）命令を発行することによっても終了でき、それによってゼロ ページのオフセット 0 の終了コードになります。 DOS には専用のINT 20h割り込みと、プログラムを終了させるためのINT 21h APIサブ関数がありますが (より複雑なプログラムに適しています)、機械翻訳されたプログラムについては、DOS は CP/M の動作もある程度エミュレートします。プログラムは、システムが以前に INT 20h 命令を埋め込んだPSPのオフセット 0 (CP/M のゼロ ページに相当) にジャンプすることで自身を終了できます。また、ロードされたプログラムの初期スタックは 0 のワードを保持するように準備されるため、ニア リターン RETN ( 8088/8086オペコードC3h) を発行するプログラムは暗黙的にそのコード セグメントの先頭にもジャンプし、最終的に INT 20h にも到達します。[ a] CP/M-86 では、ゼロ ページの構造が異なり、CALL 5 インターフェイスはありませんが、スタック リターン メソッドと BDOS 関数 0 (ただし、INT E0h経由) はどちらも同様に機能します。
  3. ^ 8088/8086プロセッサでは、オペコードC9hはCBh ("RETF"、スタックから CS:IP をポップする)の文書化されていないエイリアスですが、 80188 / 80186以降のプロセッサでは "LEAVE" (SPをBP に設定し、BP をポップする) としてデコードされます。
  4. ^ abこの問題は、競合しない ファイル拡張子を選択することで回避できますが、一度導入されると、これらの特定のファイル名は、これらの特定のファイル名を期待するようにハードワイヤードされた (サードパーティの) ツールとの互換性を保つために、 MS-DOS / PC DOSの非常に初期のバージョンから保持されました。
  5. ^ ab このタイプの他のDOSファイルには、 MS-DOSおよびPC DOSのキーボード ドライバーKEYB用のバイナリキーボード レイアウトデータベース ファイルであるKEYBOARD.SYS、 MS-DOS のDOS BIOSを含むIO.SYS 、およびWindows 95 / MS-DOS 7.0以降ではテキスト構成ファイルであるが、元は MS-DOSカーネルを含むバイナリ システム ファイルであるMSDOS.SYSがあります。ただし、 MS-DOS および PC DOS はクラッシュ保護されたシステム ファイルをまったく提供せず、これらのファイル名はクラッシュ保護されたシステム ファイルを提供するDR-DOS 7.02以降では使用されず、必要もありません。
  6. ^ これらのファイルに隠し属性が設定され、デフォルトではリストされないようにすることで、誤って呼び出されるリスクを軽減しているのはこのためです。
  7. ^ MS-DOS / PC DOSとDR-DOSファミリーのオペレーティングシステムでサポートされているファイル形式は、類似したデータを含んでいますが、構成が異なり、互換性がありません。データ構造へのエントリポイントはファイル内の異なるオフセットにあるため、両方のDOSファミリーで使用できる「ファット」データベースを作成することが可能です。 [b]しかし、 DR-DOS 7.02とそのNLSFUNC 4.00（およびそれ以降）には、両方の形式（およびその派生形式）を同時に読み取ることができる改良されたパーサーが含まれているため、 Janusヘッダーファイルは不要です。 [c] [d]それでもなお、同梱のファイルは、不適切に呼び出された際に埋め込みメッセージを表示するだけの小さな実行可能スタブを含んでいるため、「ファット」です。 [d] [b]COUNTRY.SYSCOUNTRY.SYS

参考文献

  1. ^ Devanbu, Premkumar T.; Fong, Philip WL; Stubblebine, Stuart G. (1998年4月19日～25日). 「信頼できるソフトウェアエンジニアリングのための技術」(PDF) .第20回国際ソフトウェアエンジニアリング会議論文集. IEEE. pp. 126–135 [131]. doi :10.1109/ICSE.1998.671109. ISBN 0-8186-8368-6. ISSN  0270-5257. 2014年1月16日時点のオリジナルよりアーカイブ（PDF） . 2021年9月29日閲覧。（10ページ）
  2. ^ Pero, Nicola (2008年12月18日). 「gnustep/tools-make: README.Packaging」. GitHub . 2022年5月25日時点のオリジナルよりアーカイブ。2022年5月26日閲覧。
  3. ^ “PackagingDrafts/GNUstep”. Fedora Project Wiki . 2009年2月25日. 2022年5月25日時点のオリジナルよりアーカイブ。 2022年5月26日閲覧。
  4. ^ 「ドメインシステムソフトウェアリリースノート、ソフトウェアリリース10.1」（PDF）（初版）。米国マサチューセッツ州チェルムズフォード：Apollo Computer Inc. 、1988年12月。p. 2-16。注文番号：005809-A03。 2023年5月26日時点のオリジナルからアーカイブ（PDF） 。 2022年7月24日閲覧。（256ページ）
  5. ^ ab Engst, Adam C. (1994-08-22). 「脂肪バイナリーダイエットはすべきか？」TidBITS . No. 240. TidBITS Publishing Inc. ISSN  1090-7017. 2021年9月29日時点のオリジナルよりアーカイブ。2021年9月29日閲覧。
  6. ^ ab Engst, Adam C. (1994-08-29). 「Fat Binary Comments」. TidBITS . No. 241. TidBITS Publishing Inc. ISSN  1090-7017. 2021年9月29日時点のオリジナルよりアーカイブ。 2021年9月29日閲覧。
  7. ^ 「第1章 - リソースマネージャ / リソースマネージャリファレンス - リソースファイルフォーマット」。Inside Macintosh: Mac OS ランタイムアーキテクチャ。Apple Computer。1996年7月6日。2021年9月29日時点のオリジナルよりアーカイブ。 2021年9月29日閲覧。
  8. ^ 「第7章 - ファットバイナリプログラム - ファットバイナリプログラムの作成」。Inside Macintosh: Mac OS ランタイムアーキテクチャ。Apple Computer。1997年3月11日。2021年9月29日時点のオリジナルよりアーカイブ。 2011年6月20日閲覧。[1]
  9. ^ 「第8章 PEF構造」. Inside Macintosh: Mac OS ランタイムアーキテクチャ. Apple Computer . 1997年3月11日. 2021年9月29日時点のオリジナルよりアーカイブ。 2021年9月29日閲覧。
  10. ^ Tevanian, Avadis; DeMoney, Michael; Enderby, Kevin; Wiebe, Douglas; Snyder, Garth (1995-07-11) [1993-08-20]. 「アーキテクチャに依存しない実行ファイルのための方法および装置」(PDF) . 米国カリフォルニア州レッドウッドシティ: NeXT Computer, Inc.米国特許5432937A. 2020年12月14日時点のオリジナルよりアーカイブ(PDF) . 2022年5月26日閲覧。[2] (9ページ); Tevanian, Avadis; DeMoney, Michael; Enderby, Kevin; Wiebe, Douglas; Snyder, Garth (1997-02-18) [1995-02-28]. 「アーキテクチャに依存しない実行ファイルのための方法および装置」(PDF) . 米国カリフォルニア州レッドウッドシティ: NeXT Computer, Inc.米国特許5604905A. 2022年5月26日時点のオリジナルよりアーカイブ(PDF) . 2022年5月26日閲覧。（9ページ）
  11. ^ 「ユニバーサルバイナリと32ビット/64ビットPowerPCバイナリ」。Mac OS X ABI Mach-Oファイルフォーマットリファレンス。Apple Inc. 2009年2月4日 [2003]。2012年4月27日時点のオリジナルよりアーカイブ。
  12. ^ Singh, Amit (2006-06-19). 「2.6.2 Fat Binaries」. Mac OS X 内部構造 - システムアプローチ.ピアソン・エデュケーション. p. 66. ISBN 978-0-13270226-3. 2021年9月28日閲覧。
  13. ^ 「rEFIt - EFI Fat Binaries」. refit.sourceforge.net . 2022年10月18日閲覧。
  14. ^ Paul, Matthias R. (2002-10-07) [2000]. 「Re: COMファイルの実行」.ニュースグループ: alt.msdos.programmer. 2017年9月3日時点のオリジナルよりアーカイブ。 2017年9月3日閲覧。[3] （注：DOS COMプログラムの呼び出し規約の詳細が記載されています。）
  15. ^ abc Wilkinson, William "Bill" Albert (2005-04-02) [2003, 1999-02-16, 1987年2月, 1986-11-15, 1986-11-10]. Heath Company, USAで執筆。「Something COMmon About MS-DOS and CP/M」. REMark . Vol. 8, no. 2. St. Joseph, Michigan, USA: Heath/Zenith Users' Group (HUG). pp.  55– 57. #85. P/N 885-2085. 2021年12月13日時点のオリジナルよりアーカイブ。[4]
  16. ^ abc Cha, Sang Kil; Pak, Brian; Brumley, David ; Lipton, Richard Jay (2010-10-08) [2010-10-04]. プラットフォーム非依存プログラム(PDF) . Proceedings of the 17th ACM conference on Computer and Communications Security (CCS'10). Chicago, Illinois, USA: Carnegie Mellon University , Pittsburgh, Pennsylvania, USA / Georgia Institute of Technology , Atlanta, Georgia, USA. pp.  547– 558. doi :10.1145/1866307.1866369. ISBN 978-1-4503-0244-9. 2022年5月26日時点のオリジナルよりアーカイブ（PDF） . 2022年5月26日閲覧。[5] (12ページ) (参照: [6])(注: CP/MおよびDOSの場合のように、 8080と8086 の 命令セット アーキテクチャのシナリオに特有のシナリオには対処していませんが、 x86 、MIPS、ARM のガジェット ヘッダー(つまり、プログラム ロジックのチャンク。ROPガジェットと混同しないでください)と呼ばれるものを通じて、プラットフォームに依存しないプログラム (PIP)の一般的な「自己識別プログラム」の概念について説明します。つまり 、0Eh、B2h、02h、A9h、0Eh、B2h、02h、3Ah、24h、77h、01h、04hまたは90h、EBh、20h、2Ah、90h、EBh、20h、3Ah、24h、77h、01h、04h です。)
  17. ^ abcdef Wilkinson, William "Bill" Albert; Seligman, Cory; Drushel, Richard F.; Harston, Jonathan Graham; Elliott, John C. (1999-02-17). 「MS-DOS & CP/M-Compatible Binaries」.ニュースグループ: comp.os.cpm. 2021年12月13日時点のオリジナルよりアーカイブ。 2021年12月13日閲覧。(注: Elliott のサンプル コード内の一部のオペコード ( EBh、44h、EBh、 EBh 、04h、... ) は混同されている可能性があります。)
  18. ^ ab Elliott, John C. (2009-10-27). "CP/M info program".ニュースグループ: comp.os.cpm. オリジナルから2021年12月13日にアーカイブ。 2021年12月13日閲覧。[…] DOS保護機能 […] このアイデアは、Simeon Cran氏のMYZ80エミュレータのユーティリティに基づいています。これらのDOS保護ヘッダーは、Z80レジスタを一切変更しないという点でさらに優れています。マジックシーケンスはEB 52 EB: […] XCHG […] MOV D,D […] XCHG […] ですが、これはDOSコードがプログラムの開始位置からかなり離れた位置で実行されることを意味します。 […] 自己解凍型のPMArcアーカイブを使えば、さらに楽しむことができます。 1 つを […] defb 0EBh、018h、'-pms-' […] で開始すると、PMA ユーティリティによって有効なアーカイブとして扱われ、8086プロセッサが 011Ah に、Z80 プロセッサが 0130h に送信されます。 […]
  19. ^ ChristW (2012-11-14) [2012-11-13]. Chen, Raymond (編). 「Microsoft Money がアカウント取引のインポート中、またはダウンロードした取引の受取人を変更する際にクラッシュする」. The New Old Thing . 2018年7月5日時点のオリジナルからのアーカイブ。 2018年5月19日閲覧。[…] バイトシーケンス […] EB 03 C3 yy xx […]これらの5バイトを先頭として.COMファイルを作成すると […] 'JMP SHORT 3' が表示され、その後に3バイトのゴミバイトが続きます。[…] Z80の逆アセンブリを見ると[…] これは 'EX DE,HL; INC BC;' と解釈されます。 […] 3番目のバイトは「JUMP」で、その後にyy xxで指定された16ビットのアドレスが続きます […] MS-DOSおよび[…] CP/Mで実行される.COMファイルが作成されます[…](注: 著者は Z80 について説明していますが、このシーケンスは8080および互換プロセッサでも動作します。)
  20. ^ Brehm, Andrew J. (2016). 「CP/M と MS-DOS Fat Binary」. DesertPenguin.org . 2018年5月19日時点のオリジナルよりアーカイブ。 2018年5月19日閲覧。(注: この記事ではZ80について説明していますが、コード シーケンスは8080および互換プロセッサでも動作します。)
  21. ^ Elliott, John C. (1996-06-13). "micros.hensa.ac.uk へのアップロード".ニュースグループ: comp.os.cpm. 2021年12月13日アーカイブ. 2021年12月13日閲覧. […] FATBIN 1.00 - CP/M .COMファイルとDOS .COMファイルを結合し、両方のプラットフォームで動作するファイルを作成します。[…] 以下のファイルの作成に使用されました: […] MSODBALL 2.05 - フロッピーディスクをAmstrad 706k形式とDOS 706k形式間で変換します。[…] どちらのプログラムもCP/M-80とDOSで動作します。[…]
  22. ^ Elliott, John C. (1998-06-28) [1997-04-01]. 「FATBIN v1.01」。1998年6月28日時点のオリジナルよりアーカイブ。(NB. FATBN101.COM 22k 1997-04-01 FATBIN v1.01。CP/M と DOS の両方で実行される fat バイナリ ファイルを作成します。CP /M-80 および DOS 用の自己解凍アーカイブで配布されます。)
  23. ^ Elliott, John C. (2002-03-11). 「DSKWRITE v1.00」. Fossies - the Fresh Open Source Software Archive . 2021年12月12日時点のオリジナルからのアーカイブ。 2021年12月12日閲覧。 […] DSKWRITE.Z80にはCP/M版のソースが含まれています。[…] DSKWRITE.ASMにはDOS版のソースが含まれています。[…] 単一の.COMファイルを取得するには、FBMAKEを使用する必要があります。[…][7] （注：FATBNSEA.COMパッケージのFBMAKEについて言及しています。）
  24. ^ ab Elliott, John C. (2012-06-20) [2005-01-05]. 「Generic CP/M」. Seasip.info . 2021年11月17日アーカイブ。 2021年12月12日閲覧。[…]自己解凍アーカイブは、多数の小さなファイルを含む.COMファイルです。アーカイブを実行すると、その中の小さなファイルが作成されます[…] 自己解凍アーカイブプログラムは、 DOS（2以降）またはCP/Mで実行でき、結果は同じです。Unixで解凍するには、ZXCCを使用できます[…] FATBNSEA.COM[…] FATBINは、CP/M-80の.COMファイルとDOSの.COMファイルを結合して、両方のシステムで動作するファイルを生成します。 […] M3C4SEA.COM […] M3CONV バージョン 4 - .Z80 または .SNA 形式のSpectrumスナップショットをMultiface 3形式に変換します（Multiface 3からZ80形式への変換は PC のみ）。 […] PMSFX21X.COM […] PMSFXは、これらの自動解凍アーカイブを生成するために使用されたプログラムです。このバージョン (2.11) では、CP/M または DOS で自動解凍されるアーカイブを生成できます。PMSFX を使用するにはPMARC が必要です。新機能: DOS では、正確なファイルサイズをサポートします。 […] SP2BMSEA.COM […] Stop Press Canvas ファイルをWindows の.BMP に変換します […][8]
  25. ^ Elliott, John C. (1997-01-18) [1997-01-11]. "PMSFX 2".ニュースグループ: comp.os.cpm. オリジナルから2021年12月13日にアーカイブ。2021年12月13日閲覧。[…] 私は、DOSとCP/Mで解凍できない.COMファイル（最初の3バイトは有効なZ80コード、有効な8086コード、有効なPMAヘッダー）を生成するPMSFXのバージョンを作成しました。[…]自己解凍型アーカイブとして。[…]
  26. ^ Elliott, John C.; Lopushinsky, Jim (2002) [1998-04-11]. 「CP/M 3 COMファイルヘッダー」Seasip.info . 2016年8月30日時点のオリジナルよりアーカイブ。 2016年8月29日閲覧。
  27. ^ ab Necasek, Michal (2018-01-30) [2018-01-28, 2018-01-26]. 「WordStar Again」. OS/2 Museum . オリジナルから2019-07-28にアーカイブ。2019-07-28に取得。[…] このような違いが疑われる理由は、バージョン3.2xがCP/M-86もサポートしていたためです（オーバーレイはDOSとCP/M-86で同一で、メインの実行ファイルのみが異なります） […] .OVRファイルはDOSとCP/M-86で100%同一で、実行時にフラグ（WordStar 3.20のマニュアルに明記されています）で切り替えます […] WordStarのOSインターフェースは非常に狭く、抽象化されています […] WordStar 3.2xのオーバーレイは、DOS版とCP/M-86版で100%同一です。 INT 21h (DOS) と INT E0h (CP/M-86) のどちらを呼び出すかを選択するランタイムスイッチがあります。WS.COM は DOS と CP/M-86 で同じではありませんが、おそらくそれほど大きな違いはありません。[…]
  28. ^ Lineback, Nathan. 「GSXスクリーンショット」. Toastytech.com . 2020年1月15日時点のオリジナルよりアーカイブ。 2020年1月15日閲覧。
  29. ^ abc Paul, Matthias R. (2002-04-11). "Re: [fd-dev] ANNOUNCE: CuteMouse 2.0 alpha 1". freedos-dev . オリジナルから2020年2月21日にアーカイブ。 2020年2月21日閲覧。[…] FreeKEYBは[…] 真の.COMおよび.SYSドライバー（小型モデル）を1つにまとめたものです。最初のJMPを安全に上書きできます。これが私が「トリッキーなヘッダー」と言った理由の一部です。[…] FFFFh:FFFFhを3バイトジャンプと保留中のDB FFhに置き換えることができます。MS-DOS、PC DOS、DR-DOS、そしておそらく他のDOSの問題にも動作します。[…]
  30. ^ abc Paul, Matthias R. (2002-04-06). "Re: [fd-dev] ANNOUNCE: CuteMouse 2.0 alpha 1". freedos-dev . 2020-02-07にオリジナルからアーカイブ。2020-02-07に取得。 […] CTMOUSEが通常のTSRとデバイスドライバーの両方を1つにまとめることができるように、ドライバーにSYSデバイスドライバーヘッダーを追加します。これは、FreeKEYBアドバンスドキーボードドライバーに似ています。[…] INSTALL =はDR DOS 3.41以降でサポートされており、DR DOSは[D]CONFIG.SYSディレクティブの順序を保持するため、 DR DOSでは実際には必要ありません。 […] しかし、[…] MS-DOS / PC DOSシステムでの柔軟性が向上します。[…] ファイル内の順序に関係なく、常にINSTALL =ステートメントよりも前にDEVICE =ディレクティブが実行されます。 […] ソフトウェアは、マウスドライバをデバイスドライバとして提供することを要求する場合があります。これは、昔からマウスドライバは常にデバイスドライバであったためです。これらのマウスドライバは、使用するプロトコルに応じて固有のデバイスドライバ名（例えば、マウスシステムモードの場合は「 PC$MOUSE」）を持っており、一部のソフトウェアは、使用するマウスの種類を特定するためにこれらのドライバを検索する場合があります。[…] もう1つの利点は、デバイスドライバは通常、メモリ消費量が少ないことです（環境変数やPSPは不要）。[…] これは基本的に、扱いにくいファイルヘッダー、コマンドラインを解析するための別のコード、異なるエントリポイントと終了行、そしてORG 0 / ORG 100hの違いを克服するためのいくつかのセグメントマジックです。デバイスドライバの自己ロードハイディングは、ドライバヘッダーをそのままにして、ドライバの残りの部分のみを再配置する必要があるため、少し扱いに​​くくなります。[…]
  31. ^ abcd Paul, Matthias R. (2001-06-10) [1995]. 「DOS COUNTRY.SYS ファイルフォーマット」（COUNTRY.LST ファイル）（1.44 ed.）. 2016年4月20日時点のオリジナルよりアーカイブ。2016年8月20日閲覧。
  32. ^ abc ポール、マティアス R. (1997-07-30) [1994-05-01]. 「第 II.4 章。外部コマンドの管理 - SYS.COM」。 NWDOS-TIP — Novell DOS 7 に関するヒントとコツ、詳細、バグ、回避策を含む Blick です。 MPDOSTIP (ドイツ語) (第 3 版)。 2017-09-10 のオリジナルからアーカイブ。2014 年 8 月 6 日に取得。カルデラの OpenDOS 7.01 をアップデートして、 IBMBIO.COMのスタートコードを修正してください - 正常なプログラムを開始してください - 完全なコマンドを実行してください。バージョン Einzug halten wird の機能をすべて使用すると、次の操作が可能になります。（注：NWDOSTIP.TXTはNovell DOS 7とOpenDOS 7.01に関する包括的な資料であり、多くの未文書化の機能や内部構造の説明も含まれています。これは著者がMPDOSTIP.ZIP2001年まで維持し、当時多くのサイトで配布していた大規模なコレクションの一部です。提供されているリンクは、HTMLに変換された古いバージョンのファイルを指していますNWDOSTIP.TXT。）[9]
  33. ^ Paul, Matthias R. (1997年10月2日). 「Caldera OpenDOS 7.01/7.02 Update Alpha 3 IBMBIO.COM README.TXT」. 2003年10月4日時点のオリジナルよりアーカイブ。 2009年3月29日閲覧。[10]
  34. ^ DR-DOS 7.03 WHATSNEW.TXT - DR-DOS 7.02 から DR-DOS 7.03 への変更。カルデラ社、 1998 年 12 月 24 日。 2019年4月8日のオリジナルからアーカイブ。2019年4月8日に取得。
  35. ^ ab Sage, Jay (1988年5～6月). Carlson, Art (編). 「ZCPR 3.4 - タイプ4プログラム」. The Computer Journal (TCJ) - プログラミング、ユーザーサポート、アプリケーション. ZCPR3コーナー (32). コロンビアフォールズ, モンタナ州, 米国: 10～17 [16]. ISSN  0748-9331. ark:/13960/t1wd4v943 . 2021年11月29日閲覧。[11][12]
  36. ^ ab Sage, Jay (1992年5～6月) [1992年3～6月]. Carlson, Art; McEwen, Chris (編). 「Type-3 and Type-4 Programs」. The Computer Journal (TCJ) - プログラミング、ユーザーサポート、アプリケーション. Z-System Corner - Some New Applications of Type-4 Programs (55). S. Plainfield, New Jersey, USA: Socrates Press: 13–19 [14, 16]. ISSN  0748-9331. ark:/13960/t4dn54d22 . 2021年11月29日閲覧。[13][14]
  37. ^ ab Sage, Jay (1992年11月～12月). Carlson, Art; Kibler, Bill D. (編). 「Regular Feature, ZCPR Support, Language Independence, part 2」. The Computer Journal (TCJ) - Programming, User Support, Applications . The Z-System Corner (58). Lincoln, CA, USA: 7– 10. ISSN  0748-9331. ark:/13960/t70v9g87h . 2020年2月9日閲覧. […] 「RST 0」というオペコードがあり、これを実行するとウォームブートが発生します。Z3TXTモジュールを含むファイルは実行されるべきではありませんが、1バイトを犠牲にすることで、そのような可能性から身を守ることができます。ヘッダーには、「 Z3TXT」という文字列とそれに続くヌルバイト（0）も含まれていました。多くのZ-Systemモジュールにはこのような識別子が含まれています。このカテゴリには、常駐コマンドパッケージ（RCP）、フローコマンドパッケージ（FCP）、環境記述子モジュール（Z3ENV）が含まれます。Bridger Mitchellの[…] JETLDR.COMなどのプログラムは、これらのモジュールをファイルからメモリにロードし、ID文字列を使用してファイルを検証できます。つまり、ユーザーが指定した種類のモジュールであることを確認します。これにより、ユーザーのミスや破損したファイルを検出できます。[…] したがって、ヘッダーは次のようになります。[…] rst […] db 'Z3TXT',0 ; ヌル終端ID […] ; 12345678 ; 8文字である必要があります[…] db 'PROGNAME' ; スペースで埋める[…] ; 123 ; 3文字である必要があります[…] db 'ENG' ; 言語名[…] dw LENGTH ; モジュールの長さ[…][15][16]
  38. ^ 「IOデバイス特性表 - コンソールまたはテレタイプライター」PDP-6マルチプログラミングシステムマニュアル(PDF)。マサチューセッツ州メイナード、米国：Digital Equipment Corporation (DEC)。1965年。p. 43。DEC-6-0-EX-SYS-UM-IP-PRE00。2014年7月14日時点のオリジナルからアーカイブ(PDF) 。 2014年7月10日閲覧。（1+84+10ページ）
  39. ^ 「5.1.1.1. デバイス依存機能 - データモード - 全二重ソフトウェア A(ASCII) および AL(ASCII ライン)」 PDP-10 リファレンスハンドブック：モニターとの通信 - タイムシェアリングモニター(PDF)。第3巻。Digital Equipment Corporation (DEC)。1969年。pp. 5-3–5-6 [5-5 (431)]。 2011年11月15日時点のオリジナルからアーカイブ(PDF) 。 2014年7月10日閲覧。（207ページ）
  40. ^ 「2. オペレーティングシステム呼び出し規約」CP/M 2.0 インターフェースガイド(PDF) (第1版)。米国カリフォルニア州パシフィックグローブ：Digital Research。1979年。5ページ。2020年2月28日にオリジナルからアーカイブ(PDF) 。 2020年2月28日閲覧。 […] ASCIIファイルの終了は、 CP/Mの読み取り操作によって返される制御Z文字(1AH)または実際のファイル終了によって示されます。ただし、マシンコードファイル（例： COMファイル）に埋め込まれた制御Z文字は無視され、CP/Mによって返されるファイル終了条件は読み取り操作の終了に使用されます。[…]（56ページ）
  41. ^ Hogan, Thom (1982). 「3. CP/M トランジェントコマンド」. Osborne CP/M ユーザーガイド - すべての CP/M ユーザー向け (第2版). 米国カリフォルニア州バークレー: A. Osborne/McGraw-Hill . p. 74. ISBN 0-931988-82-9. 2020年2月28日取得。[…] CP/Mは、ファイル内の最後のデータ文字の後にCONTROL-Z文字を配置することで、 ASCIIファイルの終わりをマークします。ファイルに128の倍数の文字が含まれている場合、CONTROL-Zを追加すると127文字が無駄になるため、CP/Mはそうしません。CONTROL-Z文字をファイル終了マーカーとして使用することは可能です。これは、ASCIIファイルではCONTROL-Zがデータとして使用されることはほとんどないためです。ただし、非ASCIIファイルでは、CONTROL-Zは他の文字と同じくらい発生する可能性があります。したがって、ファイル終了マーカーとして使用することはできません。CP/Mは、非ASCIIファイルの終わりをマークするために別の方法を使用します。CP/Mは、ファイルに割り当てられた最後のレコード（ディスクスペースの基本単位）を読み取ると、ファイルの終わりに到達したと見なします。各ファイルのディスクディレクトリエントリには、そのファイルに割り当てられたディスクレコードのリストが含まれています。この方法では、ファイルの内容ではなくサイズに基づいてファイルの末尾を特定します。[…][17][18]
  42. ^ BC_Programmer (2010-01-31) [2010-01-30]. 「Re: 複数のファイルを結合するコピーコマンドは、末尾にSUBという単語をタグ付けします」. Computer Hope Forum . 2020年2月26日時点のオリジナルよりアーカイブ。 2020年2月26日閲覧。
  43. ^ 「LinuxとWindowsの.txtファイルの違いは何ですか（Unicodeエンコード）」Superuser . 2011年8月3日 [2011年6月8日]. 2020年2月26日時点のオリジナルよりアーカイブ。 2020年2月26日閲覧。
  44. ^ ab Gordon, Ryan C. (2009年10月). 「FatELF: Linux用ユニバーサルバイナリ」. icculus.org . 2020年8月27日時点のオリジナルよりアーカイブ。 2010年7月13日閲覧。
  45. ^ Gordon, Ryan C. (2009年11月). 「FatELF仕様 バージョン1」. icculus.org . 2020年8月27日時点のオリジナルよりアーカイブ。 2010年7月25日閲覧。
  46. ^ Windisch, Eric (2009-11-03). 「Subject: Newsgroups: gmane.linux.kernel, Re: FatELF patches...」gmane.org. 2016年11月15日時点のオリジナルよりアーカイブ。 2010年7月8日閲覧。
  47. ^ Gordon, Ryan C. (2009). 「FatELF: Linux用ユニバーサルバイナリ - 概念実証仮想マシンのダウンロードページ」. icculus.org . 2022年5月21日時点のオリジナルよりアーカイブ。 2022年5月26日閲覧。(注: Fat Binary をサポートする Ubuntu 9.04 の VM イメージ)
  48. ^ Holwerda, Thom (2009年11月5日). 「Ryan GordonがFatELFプロジェクトを停止」. Linux. osnews.com. 2022年5月26日時点のオリジナルよりアーカイブ。2010年7月5日閲覧。
  49. ^ Brockmeier, Joe "Zonker" (2010年6月23日). 「SELF: （疑惑の）失敗の分析」LWN.net . Linux Weekly News. 2022年5月26日時点のオリジナルよりアーカイブ。 2011年2月6日閲覧。
  50. ^ Mulder, Sijmen J. (2021-03-06) [2018-04-25]. 「sjmulder/fatpack - Windows用マルチアーキテクチャ「fat」バイナリの構築」. GitHub . 2022年5月26日時点のオリジナルよりアーカイブ。2022年5月26日閲覧。
  51. ^ “Arm64X PE ファイル”. learn.microsoft.com . Microsoft . 2022年8月13日. 2023年8月20日時点のオリジナルよりアーカイブ。2023年3月31日閲覧。
  52. ^ 「Arm64Xバイナリのビルド」. learn.microsoft.com . Microsoft . 2023年3月10日. 2023年8月20日時点のオリジナルよりアーカイブ。2023年3月31日閲覧。
  53. ^ Wang, Perry H.; Collins, Jamison D.; Chinya, Gautham N.; Jiang, Hong; Tian, Xinmin; Girkar, Milind; Yang, Nick Y.; Lueh, Guei-Yuan; Wang, Hong (2007年6月). 「EXOCHI: 異機種マルチコア・マルチスレッドシステムのためのアーキテクチャとプログラミング環境」 . ACM SIGPLAN Notices . 42 (6): 156– 166. doi :10.1145/1273442.1250753.（11ページ）
  54. ^ Wang, Perry H.; Collins, Jamison D.; Chinya, Gautham N.; Jiang, Hong; Tian, Xinmin; Girkar, Milind; Pearce, Lisa; Lueh, Guei-Yuan; Yakoushkin, Sergey; Wang, Hong (2007-08-22). 「アクセラレータ外骨格」（PDF） . Intel Technology Journal . 11: Tera-scale Computing (3). Intel Corporation : 185– 196. doi :10.1535/itj.1103. ISSN  1535-864X. 2022年5月26日時点のオリジナルよりアーカイブ（PDF）. 2022年5月26日閲覧。(12/1+vii+90+1 ページ)
  55. ^ "cudaFatFormat.h / ptxomp.c". 1.13. Nvidia Corporation . 2004年11月15日. 2022年5月26日時点のオリジナルよりアーカイブ。 2022年5月26日閲覧。
  56. ^ Harris, Mark J. (2014-05-08) [2013-06-05]. 「テクニカルウォークスルー：CUDAプロのヒント：ファットバイナリとJITキャッシュの理解」. Nvidia Developer . Nvidia . 2022年3月23日時点のオリジナルよりアーカイブ。 2022年5月26日閲覧。
  57. ^ 「CUDAバイナリユーティリティ」（PDF）（アプリケーションノート）。6.0。Nvidia 。 2014年2月。DA-06762-001_v6.0。2022年5月25日時点のオリジナルからアーカイブ（PDF） 。 2022年5月25日閲覧。
  58. ^ "fatbinary - help". helpmanual.io . 8.0. 2016. 2022年5月25日時点のオリジナルよりアーカイブ。 2022年5月25日閲覧。
  59. ^ 「CUDAコンパイラドライバー NVCC - リファレンスガイド」(PDF) . 11.7. Nvidia . 2022年5月. TRM-06721-001_v11.7. 2022年5月25日時点のオリジナルよりアーカイブ(PDF) . 2022年5月25日閲覧。
  60. ^ Braun, Lorenz; Frönin, Holger (2019-11-18). 「CUDA Flux: CUDAアプリケーション向け軽量命令プロファイラー」(PDF) . 2019 IEEE/ACM 高性能コンピュータシステムの性能モデリング、ベンチマーク、シミュレーション (PMBS) . IEEE . pp.  73– 81. doi :10.1109/PMBS49563.2019.00014. ISBN 978-1-7281-5977-5. 2022年3月21日時点のオリジナルよりアーカイブ（PDF） . 2022年5月26日閲覧。
  61. ^ Fung, Wilson WL; Sham, Ivan; Yuan, George; Aamodt, Tor M. (2007). 「Dynamic Warp Formation and Scheduling for Efficient GPU Control Flow」(PDF) . バンクーバー、ブリティッシュコロンビア州、カナダ. 2022年5月26日時点のオリジナルよりアーカイブ(PDF) . 2022年5月26日閲覧。（12ページ）
  62. ^ Bakhoda, Ali; Yuan, George L.; Fung, Wilson WL; Wong, Henry; Aamodt, Tor M. (2009-04-28) [2009-04-26]. 「詳細なGPUシミュレータを用いたCUDAワークロードの分析」(PDF) . 2009 IEEE International Symposium on Performance Analysis of Systems and Software . pp.  163– 174. doi :10.1109/ISPASS.2009.4919648. ISBN 978-1-4244-4184-6. 2022年5月26日時点のオリジナルよりアーカイブ（PDF） . 2022年5月6日閲覧。[19]
  63. ^ ab "13.4 AMDコンパイララッパー：ファットバイナリ". Multi2Simシミュレーションフレームワーク - ヘテロジニアスコンピューティングのためのCPU-GPUモデル(PDF) . v4.2. Multi2Sim. 2013. pp. 173–176 [176]. 2022年5月25日時点のオリジナルよりアーカイブ(PDF) . 2022年5月25日閲覧。（210ページ中4ページ）
  64. ^ Ubal, Rafael; Jang, Byunghyun; Mistry, Perhaad; Schaa, Dana; Kaeli, David R. (2012-09-23) [2012-09-19]. 「Multi2Sim: CPU-GPUコンピューティングのためのシミュレーションフレームワーク」(PDF) .第21回国際並列アーキテクチャおよびコンパイル技術会議 (PACT) . 米国ミネソタ州ミネアポリス: IEEE . ISBN 978-1-4503-1182-3. 2022年5月25日時点のオリジナルよりアーカイブ（PDF） . 2022年5月25日閲覧。（10ページ）
  65. ^ “LTO Overview (GNU Compiler Collection (GCC) Internals)”. gcc.gnu.org . 2021年9月12日時点のオリジナルよりアーカイブ。 2021年9月12日閲覧。
  66. ^ Wennborg, Hans (2018). 「Clangの属性」. Clang 7ドキュメント. 2022年4月7日時点のオリジナルよりアーカイブ。 2022年5月26日閲覧。
  67. ^ Bahena, Victor Rodriguez (2018年4月3日). 「Intelアーキテクチャ向けに最適化されたライブラリパッケージの透過的な使用」. 電力とパフォーマンス. Clear Linuxプロジェクト. Intel Corporation . 2022年5月26日時点のオリジナルよりアーカイブ。 2022年5月26日閲覧。
  68. ^ Paul, Matthias R.; Frinke, Axel C. (1997-10-13) [1991], FreeKEYB - 拡張 DOS キーボードおよびコンソール ドライバ(ユーザー マニュアル) (v6.5 版)[20] (注: FreeKEYB は、ほとんどのキーボード レイアウト、コード ページ、および国コードをサポートする、 Unicodeベースの動的に構成可能な K3PLUS の後継です。既製のマクロ アセンブラと、依存関係とコード モーフィングのメタデータを生成して実行ファイルにバイナリ コードと一緒に埋め込む自動前処理および後処理分析ツールのフレームワーク、および自己破棄、緩和、再配置を行うローダーを使用することで、このドライバは、ロード時にバイトレベルの粒度の高い動的なデッド コード除去と再配置技術を実装するほか、実行時に自己修正コードと再構成機能を実装し、基盤となるハードウェア、オペレーティング システム、ドライバ構成、および選択された機能セットとロケール (数百のオプションを持つ約 60 個の構成スイッチでほぼ無制限の組み合わせが可能) に応じてメモリ フットプリントを標準形式に近づけます。この複雑さとダイナミクスは、従来のドライバと同じように単一の実行可能ファイルを扱うユーザーからは見えません。)
  69. ^ Paul, Matthias R. (2002-04-06). "[fd-dev] Ctrl+Alt+Del". freedos-dev . オリジナルから2019-04-27にアーカイブ。2019-04-27に取得。[…] FreeKEYBは、ロード先のマシンの種類、キーボードの種類、レイアウト、国、コードページ、インストールされているマウスとビデオアダプタの種類、そのシステムにロードされている他のドライバ、オペレーティングシステムとロードおよび再配置方法、含まれる個々の機能、コマンドラインで指定された設定オプションに応じて、初期化時にドライバのランタイムイメージを構築します。サポートされているコマンドラインスイッチとオプションの数が非常に多いため[…]（約50個のスイッチ[…]、複数の設定が可能）無数の依存関係を持つ機能の組み合わせが多数存在し、[…]、結果として[…]、無数の[…]異なるターゲットイメージが生成されます。 FreeKEYB の動的デッドコード除去技術は、[…] これらの […] 依存関係を解決し、[…] デッドコードとデータを削除します […] は、[…] 従来の TSR プログラミングのように、ある程度限られた数のモジュールまたはサブルーチン全体を含めたり除外したり、一部のディスパッチ テーブルを修正したりするだけではありません。[…] バイト レベルで動作し、[…] 大きなルーチンの途中にある個々の命令を削除できます […] 特定のケースを処理したり、特定の機能をサポートしたりするためにコード全体に分散されています […] 特別なツールを使用してコードを分析します […] および […] フィックスアップ テーブルを自動的に作成します […] 条件定義を使用してさまざまなケースを宣言します […] アセンブリ時だけでなく初期化時にもオプションです […] ランタイム イメージに少なくともある程度のデッドコードが残るオーバーヘッドなしで […] これらの条件間のすべての依存関係を追跡し、ランタイム イメージを動的に構築および再配置し、これらの小さな変更および移動するバイナリ部分間のすべての参照を修正します […] 小さな .COM/.SYS スタイルのモデルを使用できます […] は初期化時に実行されます […]
  70. ^ Paul, Matthias R. (2001-08-21). 「[fd-dev] FreeDOS のコードページ変更」. freedos-dev . オリジナルから2019年4月19日にアーカイブ。 2019年4月20日閲覧。[…] 独自の[…]機能である「動的デッドコード除去」により、インストール時に[…] ドライバのどのコンポーネントが必要で、どのコンポーネントが不要かを指定できます。これは、これまでDOSでは見たことのない、動的ロード可能なモジュール化と遅延リンクのレベルに達しています。スクリーンセーバー、マクロ、電卓、マウスサポート、その他<ほぼすべて>が不要な場合は、コマンドラインで指定できます。FreeKEYBは、ルーチン間の依存関係をすべて考慮しながら、ドライバがイメージをターゲット位置に再配置して常駐する前に、その機能を扱うコードフラグメントを完全に削除します。[…]
  71. ^ ポール、マティアス R. (2001-04-10)。 「[ANN] FreeDOS ベータ 6 がリリースされました」(ドイツ語)。ニュースグループ: de.comp.os.msdos。 2017-09-09 のオリジナルからアーカイブ。2017 年 7 月 2 日に取得。[…] brandneue[s] 機能、デッド コード排除の機能、宝石ではなく、最高のインストールと再構築を行うため、コードの日付を変更する必要があります (zB wenn jemand ein) Bestimmtes FreeKEYB-Feature nicht benötigt)。 […]

さらに読む

  • Tunney, Justine Alexandra Roberts (2021年2月11日). 「ファットバイナリはどの程度のファットサイズが必要か？」. cosmopolitan libc - 一度ビルドすればどこでも実行できるCライブラリ / Cosmopolitan Communiqué . 2021年9月12日時点のオリジナルよりアーカイブ。2021年9月12日閲覧。; Tunney, Justine Alexandra Roberts (2021年2月11日). 「ファットバイナリはどの程度のファットさが必要なのか？」Hacker News . 2021年6月1日時点のオリジナルよりアーカイブ。 2021年9月12日閲覧。
  • Tunney, Justine Alexandra Roberts (2020年8月24日). “αcτµαlly pδrταblε εxεcµταblε (Ape)”. 2021年9月12日時点のオリジナルよりアーカイブ。 2021年9月12日閲覧。
  • Gotham, Frederick (2020-10-22). 「LinuxとMac用のFatバイナリの作成」Narkive . 2021年9月12日時点のオリジナルよりアーカイブ。 2021年9月12日閲覧。
  • Gotham, Frederick (2020年10月24日). 「Fat Binary - MS-Windowsと4つのLinux」. Narkive . 2021年9月12日時点のオリジナルよりアーカイブ。 2021年9月12日閲覧。
  • Gotham, Frederick (2020年11月2日). 「Fat Binary - DOS Windows Linux」. Narkive . 2021年9月12日時点のオリジナルよりアーカイブ。 2021年9月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年9月29日時点のオリジナルよりアーカイブ。 2021年9月29日閲覧。