アミガ・ハンク

Hunkは、Motorola 68000 CPUおよび同じファミリーの他のプロセッサに基づくAmigaオペレーティングシステムのツールとプログラムの実行可能ファイル形式です。この種類の実行可能ファイルは、Amigaでプログラムされたソフトウェアが内部構造でhunksと呼ばれる多くの部分に分割され、すべての部分にコードまたはデータが含まれるという事実に由来しています。

ハンク構造

Amiga実行可能ファイルのハンクは、さまざまなタイプで存在する可能性があります。 32ビットハンク、16ビットハンク、さらには8ビットハンクがあります。

ハンクの種類はAmigaOSで標準化され、コモドールがAmigaコンピューターを製造していた年にAmigaでコーディングする方法をプログラマーに説明するためにCommodoreが編集したThe AmigaDOSマニュアルに詳しく記載されていました。それらの構造は公式に体系化されており、コモドール委員会によってのみ変更できました。その後、委員会は、Amigaオペレーティングシステムの新しいリリースの開発者に変更を通知しました。

Amigaハンクの構造は非常に単純です。ハンクの先頭に、その種類の「コードの一部」が既知の有効なAmigaハンクタイプであることを示すヘッダーがあり、その後にハンクの長さを示すIDが続きます。それ自体、そして一番下は実際のコードまたはデータを含むハンクのセグメントです。

Amiga実行可能ファイルの機能

Amigaの実行可能ファイルは、Amigaのグラフィカルシェル、ワークベンチ、またはAmigaのコマンドラインインタープリター（CLIと呼ばれる後のAmigaShell）から起動できます。

Amiga実行可能ファイルには、特定のファイル名拡張子は必要ありません。例えば、電卓アプレット「 電卓 」「Calculator.com」、「Calculator.exe」、「Calculator.bin」、あるいは「Calculator.jpeg」に名前を変更することができます。 AmigaOSはファイル名拡張子を区別しないため、これらはすべてプログラムまたはツールの有効な名前です。

AmigaOSは別の方法を採用して、有効な実行可能ファイルを処理していることを認識しました。ファイルヘッダーには特定のバイトシーケンスがあり、16進値$ 000003f3が生成されます。このシーケンスは、実行可能ファイルを意味し、自己実行可能にするもので、マジッククッキーと呼ばれます（ルイスキャロルによる不思議の国のアリスの冒険のマジッククッキーから）。

Amigaで実行可能ファイルを識別するこの種のソリューションは、UNIX / Unixのようなオペレーティングシステムで採用されている同様のソリューションからとられました。 マジッククッキーはマジックナンバーと呼ばれます 。

Amiga実行可能ファイルの構造

Amiga実行可能ファイルの内部構造は非常に単純です。ファイルの先頭にはマジックCookieがあり、実行可能ファイル内のハンクの合計数が宣言され、その直後に「0」（ゼロ）から始まるプログレッシブハンクの数が宣言されます。

最初のハンクには常にゼロの番号が付けられるため、実行可能ファイルが（たとえば）3つのハンクに細分される場合、最初のハンクには「0」、2番目に「1」、3番目に「2」などの番号が付けられます。 。

HUNK_CODE、HUNK_DATA、エトセトラ：本物のハンクが開始する前に、そのタイプ名によって記述各実行中に存在する任意のハンクの長さに関する情報を含むテーブルであり、ファイルの最後の部分で実際のハンクに配置されています。

構造の表現：

ハンクタイプ

Amigaの既知のハンクタイプは次のとおりです。

*拡張ハンク形式

メタデータ

Amigaは、この機能をサポートするためにハンク構造を簡単に適合させることができるため、メタデータをハンクに保存できますが、実行可能ファイルのハンク形式はELFを支持して放棄され、この機能を実装できる中央の権限はありませんAmiga標準の1つとして。

Amigaは、いくつかのメタデータを「.info」（拡張子の名前から呼ばれる）として知られるサイドカーファイルに保存します。

「.info」ファイルは、プロジェクト（データファイル）がディスクに保存されるたびに作成されます。例：ユーザーが「MyProject」というファイルを保存すると、「MyProject」および「MyProject.info」という2つのファイルがディスク上に作成されます。

「MyProject」ファイルにはプロジェクトファイルの実際のデータが含まれ、「MyProject.info」ファイルにはアイコン、およびファイルを作成したソフトウェアに関する情報が含まれているため、プロジェクトアイコンは、マウスを押すと、親ソフトウェアが開きます（ユーザーはいつでもこの情報を変更でき、他のプログラムは、物理的に作成した元のソフトウェアではなく、プロジェクトファイルを作成したと信じることができます）。

MacOSなどの他のシステムのように、AmigaOSにはアプリケーションバインディングは存在しません。

「.info」ファイルには、プロジェクトファイルの特定の特性とユーザーのコメントも含まれています。

「.info」ファイルはワークベンチ画面に表示されません（ワークベンチはデフォルトのAmiga Desktop GUIです）。デスクトップ画面には、「info」ファイルから取り出されたプロジェクトファイルのアイコンのみが表示されます。実際、アイコンはプロジェクト自体と「.info」に保存されているメタデータを接続する仮想メディアです。

ユーザーがマウスの左ボタンでアイコンをクリックすると、プロジェクト ".info"が元のプログラムを呼び出します。ユーザーが右ボタンでアイコンをクリックすると、ダイアログボックスが表示され、ユーザーは「.info」ファイルに含まれるメタデータを操作できます。

「.info」ファイルは、マウスでアイコンを移動することにより、関連するプロジェクトファイルと一緒にコピーまたは移動され、AmigaShellなどのAmigaのコマンドラインインターフェイスを介して、またはサードパーティのファイルマネージャーを使用してスタンドアロンファイルとして表示できます。 Directory OpusやDiskMasterなどのディレクトリリスタ。

「.info」ファイルが実行可能プログラムを表す場合、「。info」ファイルには、実行可能ファイル（たとえば、4096、8192、または16384バイト以上のRAM）に予約できるRAMバッファーのスタックに関する情報が含まれます。コマンドラインインターフェイスを使用して呼び出すことができる引数。たとえば、Amigaプログラムは、デスクトップ画面から独立した独自のグラフィックユーザーインターフェイス画面を開くことができます。 「Screen = 800x600」や「Depth = 8」などの引数を情報ファイルダイアログボックスに呼び出すことにより、ユーザーはこの情報を関連する「.info」ファイルに保存し、プログラムは生産性ソフトウェアを独自の画面サイズで開きます。 8ビットの色深度（256色に等しい）で800×600。

ユーザーは「.info」ファイルを削除することもできますが、デスクトップにプロジェクトファイルを表すアイコンがあることの利点を放棄し、それに含まれるすべてのメタデータも失います。

アイコン

「.info」メタデータファイルに含まれるビットマップアイコンの簡単なビュー：

アイコンは、「。info」ファイルに含まれるRAWビットマップデータであり、標準のAmiga IFF / LBMファイルではありません。ユーザーは、初期バージョン以降のオペレーティングシステムに存在するAmigaOS標準プログラム「IconEdit」を使用してアイコンを処理できます。 AmigaOSバージョン2.0以降、IconEditは、AmigaOSで標準グラフィックスファイルとして使用される通常のIFF / LBMファイルをインポートおよび保存できました。

CloantoのPersonal Paintのような一部のAmigaプログラムは、ビットマップデータを通常のAmigaアイコンまたは既存のAmiga ".info"ファイルとして表示、ロード、保存できます。

レガシーAmigaアイコンは、2つの異なるビットマップイメージを使用して、2つの状態のアイコンを持つことができます。最初のビットマップには、アイコンの「静かな状態」とも呼ばれる「静かな」アイコンのデータが含まれています。 2番目のビットマップイメージには、アイコンの「選択」状態のデータが含まれています。ユーザーがアイコンをクリックしてアクティブにすると、クワイエットアイコンビットマップデータが選択したアイコンビットマップデータに突然置き換えられます。このような振る舞いは、Amigaアイコンに動く漫画の効果を与えます。この2番目のビットマップが「.info」ファイルに存在しない場合（両方のビットマップを作成することは必須ではありません）、アイコンが選択されたときに逆カラー効果が使用されます。

サードパーティのアイコン「エンジン」が存在します。これは、AmigaOSの外観を他のオペレーティングシステムの最新の標準に合わせて最新の状態に維持しようとします。これらのプログラムは、アイコン処理専用のOSルーチンにパッチを適用し、カスタムルーチンに置き換えます。そのような試みの1つであるNewIconsは、AmigaOS 3.xのほぼ新しい事実上の標準になりました。人気が高かったため、AmigaOS 3.5以降で使用されている新しいアイコンシステムであるGlowIconsは、そのアイコンファイル形式に基づいています。

すべての最新のAmigaライクなオペレーティングシステム（AmigaOS 4、MorphOS、AROS）は、RAWビットマップデータ、IFF / LBMファイル、またはPNGファイルをアイコンの標準内部ビットマップイメージとして関連付けることができます。

オーバーレイされた実行可能ファイル

HUNK_OVERLAYタイプは、プログラムの実行に必要なRAMの量を減らすことを目的としています。オーバーレイ構造を持つ実行可能ファイルには、常にメモリ内にあるルートノードがあり、プログラムの残りの部分は、必要に応じて自動的にロードおよびアンロードされる小さなモジュールに分割されます。

オーバーレイ形式は、小さなスタブをコードに追加することで機能し、サブモジュールに分岐するときにオーバーレイマネージャーを呼び出して、必要なモジュールをロードします。 Commodoreは、Cコードがこれらのスタブを自動的に挿入できるように標準のオーバーレイマネージャーを定義し、標準のオーバーレイマネージャーが読み方を知っているオーバーレイテーブルも生成しました。

ただし、特に意図された方法では、オーバーレイ形式はほとんど使用されませんでした。カスタムオーバーレイマネージャーでより一般的に使用されていました。オーバーレイ形式の一般的な使用法は、実行可能ファイルを圧縮するTitanics Cruncherでした。展開する前に圧縮された実行可能ファイル全体をメモリにロードする代わりに、Titanics Cruncherはオーバーレイを使用したため、ごく小さなデクランチャーのみがメモリにロードされ、データを読み取って解凍しました。

Amigaで使用されるその他の実行可能ファイル形式

サードパーティアドオンを使用すると、AmigaOS 3.9までは、Motorola 68000用に作成されたハンク形式以外のさまざまな種類の実行可能ファイルを認識します。

エルフ

Phase5は、PowerUPアクセラレータボードにELF実行可能ファイルを実装しました。動的リンクのために面倒であることがわかりました。この形式は、AmigaOS 4.0、MorphOS、およびAROSによって標準として採用されました。 ELFサポートは、サードパーティの開発者によってWarpUpに追加され、Hyperion EntertainmentはELF形式のみで多数のWarpUpゲームをリリースしました。

拡張ハンク形式

1997年、Haage＆Partnerの開発者であるPowerUPアクセラレータボード用のWarpUp PowerPCカーネル。 ELFバイナリ形式の代わりに、既存のハンク形式を拡張することを選択しました。 ELFバイナリ形式の問題は、ユーザーがシステムにパッチを適用してELF実行可能ファイルをロードする必要があり、PPC / 68kコードを混在させることができないことでした。 Haage＆Partnerが開発したExtended Hunk Format（EHF）では、PowerPCアクセラレータがインストールされていない場合、既存のシステムを変更せずにPPCと68kコードを単一の実行可能ファイルに混在させることができました。 。

AmigaOS 4およびMorphOS

AmigaOS 4.0とMorphOSはELFをネイティブに実行できますが、これらのシステムはPowerPCプロセッサベースのマシンで実行するように設計されているため、開発者はAmigaOS 3.9で使用されるWarpUPソフトウェアとの互換性も追加しました。さらに、MorphOSは、PowerUPアクセラレータカード用にPhase5で実装されているPowerUpソフトウェア互換性を実装しています。

両方の新しいオペレーティングシステムは、AmigaOS 3.1に基づいた古いAmiga API環境を実装し、エミュレーションを介して68000コードを実行できるため、Amiga Hunk形式も実行できます。

• ノート：

1. ^ Amiga.HistoryサイトのAmigaのPPCプロセッサの歴史に関するページも参照してください。
2. ^ Haage＆PartnersサイトのEHF仕様（英語でも）。