AmigaOS
AmigaOS（アミガOS）は、パーソナルコンピュータ Amiga専用のOSである。アメリカ合衆国のコモドールが1985年に開発し、Amiga 1000と共にリリースした。初期のバージョン (1.0-3.9) はモトローラの68kシリーズの16ビットおよび32ビットのマイクロプロセッサで動作し、新しいAmigaOS 4はPowerPCマイクロプロセッサでのみ動作する。
日本では一般的な知名度は低いが、子供向けテレビ番組のウゴウゴルーガのCGアニメでAmigaが使用された場面が出たことで一部では有名。日本語を含むマルチバイト文字への対応に消極的であったため日本での販売は伸びなかったが、北アメリカやヨーロッパでは、そのユニークなデザインで人気が高い。
AmigaOSは、1985年に販売が開始されたときから、マルチタスクとカラーグラフィックスに対応するなど、当時としては先進的な機能が備えられていた。Execと呼ばれるプリエンプティブ・マルチタスク型カーネルの上に、Amigaの独特なハードウェアの抽象化層があり、ディスクオペレーティングシステムの"AmigaDOS"、ウィンドウシステムAPIの"Intuition"、グラフィカルユーザインタフェース (GUI) の"Workbench"が載っている。また、コマンド行インタフェース (CLI) の"AmigaShell"もシステムに含まれている。GUIとCLIは相補的であり、同等の機能を有する。
しかし、ライバルのWindowsやMacintoshとの競争に敗れ、1994年にコモドールが破産してしまい、一時は販売が停止してしまった。その後、コモドールの資産は数多くの企業に渡り、コモドール破産から5年後の1999年に、新たに誕生したAmiga.intによって数年ぶりにAmigaOS 3.5が販売されたものの、先進的な機能が備えられておらず、特にこれといった特徴もなかったため、売り上げは低迷していた。
そんな中、2004年に、一気にバージョンアップされたAmigaOS 4.0が発表。失敗に近かったAmigaOS 3.5よりも、新機能が多数増加され、一新された。
現在のAmigaの知的資産を所有するのはである。同社はAmigaOS 4の開発を監督する立場にあるが、実際の開発はに委託している。2006年12月20日、Amiga IncはHypelionのAmigaOS 4の開発ライセンスを終了させた。しかし、2009年9月30日、HyperionはAmigaOS 3.1の全世界での独占的かつ永久的な使用・開発・改変・販売・配布の権利とAmigaOS 4.xとその後の（AmigaOS 5 を含む）バージョンを販売する権利を獲得した。
2006年12月24日にAmigaOne向けのAmigaOS 4.0がリリースされた。
現在は、過去ほどの人気は失ったものの、再び人気を取り戻そうとしている。
AmigaOSは、ROM上の"Kickstart"とディスク上の"Workbench"に分かれている。KickstartとWorkbenchは同時にリリースされ、それぞれ対応したバージョン同士で使うようになっていた。しかし、コモドールがKickstartの開発をやめたため、Workbench 3.5以降はKickstart 3.1のROMにブート時にパッチをあてる形で対応していた。
KickstartはブートストラップROMである。Kickstartには標準的なAmigaハードウェアをブートするのに必要なコードと、AmigaOSの中核コンポーネントの多くを含んでいる。Kickstartの機能はPC/AT互換機で言えば、BIOSとOSのカーネルの主要部分に相当する。しかし、Kickstartはブート時に典型的なPCよりも多くの機能を提供でき、例えば完全なウィンドウ環境が立ち上げ途中でも利用可能である。
KickstartにはAmigaOSの "Exec"、"Intuition"、"AmigaDOS" 中核部、"Autoconfig" によって拡張ハードウェアを使う機能などが含まれる。つまり、Amigaは電源を入れただけでOSの基本的部分の多くを既に使える状態になっている。後のバージョンではIDEおよびSCSIコントローラのドライバやPCカードポートのドライバなど、Amiga本体に追加されたハードウェアのドライバが追加されている。
立ち上げ時やリセット時、Kickstartは診断やシステムチェックを行い、Amigaのチップセットを初期化し、OS中核コンポーネントを初期化する。次に接続されているブートデバイスを調べ、優先度の高い方からブートを試みる。ブートデバイスが全くない場合、ユーザーに対してブートデバイス（通常フロッピーディスク）を挿入するよううながすメッセージをディスプレイに表示する。
WorkbenchはAmiga用の標準のグラフィカル・デスクトップ環境である。WorkbenchはOSそのものではなく、その上で動作するデスクトップ環境である。ソフトウェアを動作させるのにWorkbench環境は必須ではない。実際多くのゲームは自前でハードウェアとメモリを制御するため、Kickstartから直接ブートできるようになっていた（フロッピーディスク上にブートブロックがある）。
名前が示す通り、作業台（ワークベンチ）のメタファーを使っており、厳密にはデスクトップではない。ディレクトリは「引き出し」、実行ファイルは「工具（ツール）」、データファイルは「プロジェクト」、GUIウィジェットは「小道具（ガジェット）」とされている。多くの面でインタフェースはMac OSに似ている。メインデスクトップには挿入されているディスクのアイコンとハードディスクドライブのパーティションのアイコンが表示され、それぞれのスクリーンの上部に1つのメニューバーがある。Macintoshとは異なり、マウスは2ボタン式だったが、右ボタンだけでMacintoshのようにプルダウンメニューを操作できる（ボタンを離したときに選択される）。
AmigaOS独特の機能として「マルチスクリーン」がある。AmigaOSのスクリーンはWorkbenchのデスクトップ環境を必要としない。それらのスクリーンは概念的には X Window Systemの仮想デスクトップやワークスペースに似ているが、必要に応じてアプリケーションプログラムが動的に生成する。それぞれのスクリーンは解像度や色深度をそれぞれ別々に設定できる。スクリーンの右上端のガジェットでスクリーンを切り替える。OSが全スクリーンの内容をメモリ上に保持しており、描画をその時点で素早く行う。スクリーン上端のタイトルバーでスクリーンを上下にドラッグすることもできる。かつてのAmigaは専用チップセットの機能を使ってこれを実現していたが、AmigaOS 4では新たな技法を採用しており任意の方向にスクリーンをドラッグできる。異なるスクリーン間でのドラッグ・アンド・ドロップもできる。
Workbenchの基盤となっているのが"Intuition"というウィンドウシステムである。スクリーン / ウィンドウ / ガジェットの制御と描画、キーボードとマウスの入力の処理、プログラムへのメッセージパッシングなどを行う。
AmigaOS 2.0 までは統一的なルック・アンド・フィールのデザイン標準は存在しなかった。アプリケーション開発においてはそれぞれが自前のウィジェット（ボタンやメニュー）を用意する必要があり、Intuitionが提供するサポートは最小限の範囲だった。AmigaOS 2.0には標準ウィジェットセットを提供する"gadtools.library"が追加され、ルック・アンド・フィールのガイドラインとなる"Amiga User Interface Style Guide"ができた。
また、それまでWorkbenchのスクリーンが唯一の共有可能スクリーンだったが、2.0以降ではアプリケーションが他のアプリケーションと共有可能なスクリーンを作成できるようになった。
また、AmigaOS 2.0では単純なハイパーテキストのマークアップ体系とブラウザである""が導入され、アプリケーションのオンラインヘルプに使われた。また、LISP風のスクリプト言語で動作する標準のソフトウェアインストールプログラム"Installer"も導入された。
AmigaOS 2.0までアプリケーションはキーボードやマウスの入力イベントを捉えるためにフックをしかけ、システム全体の入力ストリームを捉えるしかなかった。AmigaOS 2.0では入力イベントを修正したり詳細に調べたりするための標準インタフェース"Commodities"が提供されるようになった。これにより、グローバルな「ホットキー」のキー押下シーケンスの設定ができ、"Commodities Exchange"というレジストリでユーザーがどんな入力イベントがあるかを見ることができるようになった。
AmigaOS 2.1では"locale.library"が導入され、AmigaOSの英語以外への翻訳が行えるようになった。
AmigaDOS はAmigaOSのディスクオペレーティングシステム (DOS) 部分である。ファイルシステム、ファイルとディレクトリの操作、コマンド行インタフェース、ファイルのリダイレクト、コンソール・ウィンドウなどの機能を有する。コマンド・リダイレクション、パイプ、構造化プログラミング型のスクリプト言語、システムのグローバル変数やローカル変数といった仕組みを提供している。
AmigaOS 1.xではBCPLで書かれたTRIPOSをベースにしていた。しかし、他の言語とのインタフェースが難しく間違いやすいことがわかり、TRIPOSからの移植はあまり効率的ではなかった。
AmigaOS 2.x以降では1.xとの互換性を保ちつつC言語とアセンブリ言語に書き直された。また、サードパーティーで行われていた"AmigaDOS Resource Project" (ARP)の成果も取り入れている。ARPでも独自にBCPLで書かれたユーティリティやインタフェースを書き換えていた。
ARPはまた、Amiga向けの標準化されたファイル・リクエスター（ファイル選択ダイアログのようなもの）を提供し、UNIX風のワイルドカードをコマンドのパラメータに使えるようにした。他にもコマンドが受け付ける日付フォーマットの範囲を改善し、コマンドをメモリに常駐させてロード回数を減らす機能も追加された。
AmigaOS 4.0ではBCPLからの遺産は完全に払拭され、AmigaOS 4.1で64ビットサポートのための改造が行われている。
ファイル拡張子はAmigaOSでもよく使われるが必須ではなく、AmigaDOSも拡張子を特別に扱うことはない。単にユーザーがファイルの種類を名前から推測しやすくしているだけである。実行ファイルはマジックナンバー (プログラム)を使って認識する。
AmigaOSはバージョン3までAmigaの本来のグラフィックス・チップセットのみを"graphics.library"経由でサポートしていた。このためアプリケーションではOSの機能を使わずに直接ハードウェアを操作するものが多かった。サードパーティー製グラフィックスカードは公式にはサポートされなかった。
AmigaOSが任意のグラフィックスシステムを直接サポートできる体系が"retargetable graphics" (RTG) である。AmigaOS 3.5ではいくつかのRTGシステムがOSに同梱されており、Amiga本来のチップセット以外のグラフィックスカードも一部サポートされた。主なRTGシステムとして、、Picasso 96、EGSがある。
Amigaには3次元コンピュータグラフィックス機能がないため、3Dグラフィックス・インタフェースも標準化されていない。そのためグラフィックスカードのベンダーがそれぞれ独自の標準（、、StormMesa ("agl.library")、CyberGLなど）を提供した。
Amigaが誕生したころ、デスクトップGUIや表示などに3Dグラフィックス・ライブラリを使うという考え方はほとんど存在しなかったが、Amigaはグラフィックス機能が強力だったため3DCGの開発プラットフォームとして広く使われた。初期の3DCG制作ソフトウェアとしてVideoScape 3Dや 3Dがある。その後もやLightWaveがAmiga向けにリリースされている。LightWaveは『バビロン5』などのテレビ番組のCG制作にも使われた。
また、Amigaはビデオ信号のゲンロック（同期）が容易だということでも知られているが、ビデオキャプチャ用インタフェースは内蔵していない。最盛期にはAmiga向けのサードパーティー製ビデオキャプチャ用インタフェースが数多く製造販売されていた。
AmigaOS本来のグラフィック・エンジン兼ウィジェット・ライブラリとして"intuition.library"がある。AmigaOS 2.0ではそれがGadToolsに拡張された。Stefan Stuntzが開発した (MUI) が2.0以降のAmigaシステムで使われ、AROSではMUIクローンのを実装、MorphOSではMUIが標準のウィジェット・ツールキットとなっている。また、ClassACTというウィジェット・ツールキットはへと発展し、AmigaOS 3.0および4.0で使われている。AmigaOS 4.0ではReAction GUIが標準の1つとされている。CygnixはAmiga上でX11互換グラフィック環境を提供するものである。他にもcairoやといったグラフィックライブラリが一部ベンダーから登場している。
現在のAmigaではクロスプラットフォームのSDL (Simple DirectMedia Layer) エンジンをゲームや他のマルチメディアプログラムによく使っている。
AmigaOS 4.1では3Dのハードウェアアクセラレーションに対応したPorter-Duff画像合成エンジンを採用している。
AmigaOSはバージョン3.1まで、Amigaの元々のチップセットのサウンド機能のみを"audio.device"経由でサポートしていた。サードパーティーのオーディオカードのサポートはベンダー任せだったが、デファクトスタンダードとしてが採用されるようになった。AHIは68k系のAmigaOS 2.0以降でOSとは別にインストール可能である。AmigaOS自体がMIDIをサポートしたのは3.1になってからで、Roger Dannenbergの"camd.library"が標準MIDI APIとして採用された。コモドール版の"camd.library"にはシリアルポート用ドライバも組み込まれている。後にKjetil Matheussenが公開したオープンソース版"camd.library"にはシリアルポート用ドライバがないが、代わりに外部ドライバを提供している。
Amigaには当初からSoftvoice, Inc.の開発した音声合成ソフトウェアがあった。これは大まかに3つの部分に分けられる。アメリカ英語で使用するすべての音素を音響信号に変換する"narrator.device"、英文テキストをアメリカ英語の音素列に変換する"translator.library"、コマンドラインのユーザーが出力を音声にリダイレクトできる"SPEAK:"ハンドラである。
AmigaOS 1.xにはユーティリティとして"Say"プログラムがあり、AmigaBASICで音声を出力するデモプログラムが付属していた。
音声合成機能はサードパーティーのプログラムでも使われ、特に教育ソフトでの利用が多かった。ワープロソフトのProwriteと Excellence!には文書を読み上げる機能があった。
"narrator.device"の扱える音素には限界があったが、Francesco Devittは任意の言語を音素列に変換する"translator.library"を開発した。ただし対象言語には規則群を設定する必要があり、限定的な多言語音声合成を可能とした。
Workbench 2.0まで音声合成がサポートされていたが、2.1以降は音声合成ソフトウェアが省かれている。
AmigaOSは、ARexx (Amiga Rexx) と呼ばれるREXX言語をサポートしている。REXXはスクリプト言語で、AppleScriptのようにOSのスクリプティングにも使え、Microsoft OfficeでのVBAのようにアプリケーション内のスクリプティングにも使え、プログラム間の通信にも使える。ユーザーにとっては1つのスクリプト言語であらゆることができるため、便利である。
プログラムは「ARexxポート」の文字列メッセージを待ち受けることができる。このメッセージをユーザーがマウスでボタンを押下したのと似たような形でプログラムが解釈できる。例えば、電子メールプログラム内で表示中の電子メールを読み取るARexxスクリプトを動作させ、外部のプログラムを起動して電子メールの内容を渡して処理するといったことができる。これを使えばアプリケーション間で一時ファイルを経由することなくメモリ上でデータをやりとりできる。
AmigaOSには動的に大きさの変わるRAMディスクがあり、内容によって自動的にサイズが変化する。AmigaOS 2.x以降、ブート時にシステム設定ファイルがRAMディスクにロードされ、OSの高速化を図っている。他のファイルもRAMディスクにコピーでき、アクセスを高速化できる。また、AmigaOS 2.x以降からRAMディスク上のファイルの更新を検知して通知する機能をサポートした。
固定サイズのRAMディスクもサポートしており、中身を退避させて立ち上げ時に再ロードできる。これは通常「RADディスク」と呼ばれており、（ブートセクタがあれば）ブートデバイスとしても使える。
Kickstartは立ち上げ時にブート可能デバイス（一般にフロッピーディスクまたはハードディスク）からのブートを試みる。フロッピーディスクの場合、ディスクの先頭の2セクタ（ブートブロック）をまず読み込み、そこに格納されているブート命令列を実行する。通常このコードはOS（AmigaDOSとGUI）をロードしてそれに制御を渡し、そのディスクをブートボリュームとして使用する。このようなディスクは他にどういう中身が格納されていても「ブートディスク」または「ブータブルディスク」と呼ばれる。"install" コマンドを使えば、ブランクディスクにブートブロックを書き込むことができる。ゲームなどのソフトウェアの媒体には独自のブートブロックが書かれている。そのためゲームやデモといったアプリケーションでは、AmigaOSを使わずにメモリやハードウェアを直接制御することになる。
ブートブロックはコンピュータウイルス作者の格好の攻撃対象となった。ブートブロックがウイルスに感染するとブートコードが書き換えられるため、ブートディスクはうまく起動できなくなる。そのような初期のウイルスとしてがある。
は1996年、次のように記している。
AmigaOSのモジュール化技法は動的読み込みの共有ライブラリが中心であり、ディスク上の "codice_1" という拡張子のついたファイルとして格納されているものと、Kickstart ROM内に格納されているものがある。ライブラリ関数へのアクセスは全て間接ジャンプテーブルを経由して行い、ジャンプテーブルにはライブラリのベースポインタからのオフセットが格納されている。そのため、全てのライブラリ関数に実行時にパッチをあてたりフックをしかけることができ、これはROMに格納されたライブラリでも同様である。
AmigaOSで最も重要なライブラリは"exec.library"であり、ライブラリであると同時にマイクロカーネル"Exec"と見なすことができる。システム上で動作するタスク群のスケジューリングを行い、優先度付きのラウンドロビン・スケジューリングでプリエンプティブ・マルチタスクを実現する。Exec は他のライブラリへのアクセスを提供し、メッセージ・パッシングによる高度なプロセス間通信を提供する。一般にマイクロカーネル実装はメッセージをアドレス空間の間でコピーする必要があるため、性能に問題が生じる。しかし、AmigaOSは1つのアドレス空間しか持たないため、Exec によるメッセージパッシングは非常に効率的である。AmigaOS内で唯一の固定アドレス（アドレス4番地）には"exec.library"へのポインタが格納されており、これを使って他のライブラリにアクセスすることができる。Exec はカール・サセンラスが設計・実装した。
それまでのOSとは異なり、Execカーネルは特権モードになっていない。当時の68kファミリ向けのOS（、SunOSなど）はトラップ命令でカーネルの機能を呼び出していた。それにより、カーネル機能は68kの「スーパーバイザモード」で動作し、ユーザーソフトウェアは特権のない「ユーザーモード」で動作する。68k上の Mac OS でさえスーパーバイザモードを使っていた。それに対して Exec ではユーザーモードでジャンプテーブル経由で機能を呼び出す。スーパーバイザモードが必要なときは（スーパーバイザモードでないと実行できない命令がある）、カーネルであってもユーザープログラムであってもライブラリ関数のSupervisor()またはSuperState()を使う。
デバイスドライバもライブラリになっているが、標準化されたインタフェースを実装している。アプリケーションは通常、デバイスドライバをライブラリとして直接呼び出すことはなく、"exec.library"のI/O機能を経由して間接的にアクセスする。デバイスドライバも、ディスク上のファイルの形で格納されているもの（拡張子は "codice_2"）とKickstart ROMに格納されているものがある。
DatatypesはAmiga上のデータファイルを扱う独特の手法である。一連の "datatype" を扱う集中型システムであり、対応するdatatypeが存在する任意のデータファイルを読み書き、ロード/セーブできる一連の小さなプログラムの集合体と見ることができる。
ペイントプログラムなどのAmigaの生産性ソフトウェアは、存在する様々な画像ファイルを扱うためにそれぞれの記述子を埋め込む必要がない。Amiga向けソフトウェアの開発においては、Datatypesを扱うコードを埋め込めばよく、そうすることでDatatypesシステムが扱えるあらゆる画像ファイルをオープンしたりセーブしたりできるようになる。
例えば、codice_3とcodice_4はそれぞれ対応するファイルフォーマット（JPEGとTIFF画像ファイル）があり、Datatypesに対応したプログラムであれば、これらのdatatypeに対応した機能を自動的にロードして使うことができる。
datatypeのコードを書いて追加することもでき、新たに登場したファイルフォーマットにも対応可能である。
デバイスおよびリソース管理の上位層はライブラリとは異なるタスク型のハンドラ (handler) で制御され、メッセージ・パッシングでやり取りする。
重要な種類のハンドラとしてファイルシステム・ハンドラがある。AmigaOSではハンドラを書きさえすれば任意のファイルシステムを使用できる。これを利用したプログラムとしてAmiga以外のフロッピーディスクを扱えるようにした があり、とというAmigaOSの標準ファイルシステム以外のファイルシステムも少数ながら存在する。これを使えば、ジャーナリングやファイルパーミッションなど標準では存在しない機能を追加することもできる。
ハンドラはDOSに対して「デバイス名」で提示されることが多く、それを使ってそのハンドラに対応する周辺機器にアクセスできる。
例えば、"SPEAK:"ハンドラにはテキストを送ることができる。そのハンドラは"translator.library"を使ってテキストを音素列に変換し、それらを"narrator.device"に送ると音素列が音声信号に変換され、そこから"audio.device"に音声信号を送ってAmigaのオーディオ・ハードウェアで音声を再生する。
デバイス名は大文字と小文字を区別しない文字列で表され（通常、大文字で表現）、その後ろにコロンが付く。コロンの後に規則子 (specifier) を付けることができ、それによって「何」に「どのように」アクセスするのかという情報を補足できる。ファイルシステムの場合、規則子としてそのファイルシステム内のファイルのパス名を指定することが多い。他のハンドラの場合、使いたい入出力チャンネルの指定などを規則子で行う。例えばシリアルポート "SER:" の場合、規則子にビットレート、スタートビット、ストップビットなどといった情報を指定する。
ファイルシステムではデバイス名として「ドライブ名」を提示する。例えば"DF0:"はデフォルトでは1台目のフロッピーディスクドライブを指す。多くのシステムでは"DH0:"が1台目のハードディスクドライブを指す。
ファイルシステムはデバイス名と同様の形式で「ボリューム名」でも指定できる。この場合、対象周辺機器に挿入されている特定の媒体を識別できる。例えば"DF0:"に挿入されているフロッピーディスクの名前が "Workbench" なら、"Workbench:"とボリューム名を指定することで"DF0:"にある特定のフロッピーディスクを指定できる。
"DF0:"ドライブに "Work" というディスクがあり、そのファイルシステムの "Win" というディレクトリにある "Amp" というファイルにアクセスしたい場合、
または
とする。ただし、これらは完全に同じではない。後者の場合、ボリューム名が指定されているので、"DF0:"に "Work" というボリュームがない場合は"DF0:"にアクセスしない。その場合、"Wrok" というボリュームを入れるよう促すようなメッセージが表示される。
プログラムは、絶対位置（ドライブ、ボリュームなど）が不明なファイルにアクセスしなければならないことがある。その場合わかっているのは「論理パス」だけであり、そのファイルがライブラリなのか文書ファイルなのか、あるいはプログラムのメッセージの翻訳なのかなどということしかわからない。
このような場合、AmigaOSでは「アサイン (assign)」を使う。アサインもデバイス名と同じ形式だが、特定のファイルシステムのディレクトリを指している。1つのアサインが指す場所はユーザーが好きなようにいつでも変更できる。これはMS-DOSの"subst"コマンドと似ているが、同一ではない。アサインはまた、1つで複数の物理的位置を同時に示すこともでき、物理的に別々の実体のあるものを論理的にまとめることもできる。AmigaOSシステムで標準的に使われているアサインとして以下のものがある。
AmigaOS 4.0の最新アップデート版では、物理メモリを割り当て、システムが不活発なときにデフラグメンテーションを行う新たな知的システムを導入した。スラブアロケーション方式に基づくもので、ページングメモリを扱う機能もあり、AmigaOSでも物理メモリの内容を二次記憶装置に退避させスワップする一種の仮想記憶が可能となった。その後、ページング方式が評価され AmigaOS 4.1で最終的に実装された。AmigaOS 4.0では物理メモリの操作にバディ・システム・アルゴリズムを使っている。
AmigaOS 4.1では、オプションで任意の大きさのスワップパーティションを作成でき、OSインストール時に独立したパーティションとしてフォーマットする。スワップメモリは、デフラグメンテーションを行ってもメモリ要求を満たせないときに自動的に使われる。スワップメモリを使うかどうかは AmigaOS システムの Preferences にあるオプションボタンで指定でき、任意の時点で物理メモリのみで動作するよう設定できる。
AmigaOSからは少なくとも2つの「クローン」オペレーティングシステムが生まれている。
AmigaOSの一部バージョンには著作権メッセージがイースター・エッグになっていて、ちょっとしたトリッキーなアクセスで表示できる。