AmigaOS（アミガOS）は、パーソナルコンピュータ Amiga専用のOSである。アメリカ合衆国のコモドールが1985年に開発し、Amiga 1000と共にリリースした。初期のバージョン (1.0-3.9) はモトローラの68kシリーズの16ビットおよび32ビットのマイクロプロセッサで動作し、新しいAmigaOS 4はPowerPCマイクロプロセッサでのみ動作する。
概要 thumb|right|300px|Amiga 500 (1987年)
AmigaOSは、1985年に販売が開始されたときから、マルチタスクとカラーグラフィックスに対応するなど、当時としては先進的な機能が備えられていた。Execと呼ばれるプリエンプティブ・マルチタスク型カーネルの上に、Amigaの独特なハードウェアの抽象化層があり、ディスクオペレーティングシステムのAmigaDOS、ウィンドウシステムAPIのIntuition、グラフィカルユーザインタフェース (GUI) のWorkbenchが載っている。また、コマンド行インタフェース (CLI) のAmigaShellもシステムに含まれている。GUIとCLIは相補的であり、同等の機能を有する。
John C. Dvorakは1996年に、次のように記した。
ただし（Macintoshとの競争に敗れるなどして注 - Macintoshはライバルだったが、当時のWindowsはまだ発展途上で販売実績は小さく競争相手ではなかった。）1994年にコモドールが破産してしまい、一時は販売が停止してしまった。その後、コモドールの資産は数多くの企業に渡り、コモドール破産から5年後の1999年に、新たに誕生したAmiga.intによって数年ぶりにAmigaOS 3.5が販売されたものの、これには先進的な機能が備えられておらず、特にこれといった特徴もなかったため売り上げは低迷した。
だが2004年には、一気にバージョンアップされたAmigaOS 4.0が発表され。こちらは一新され、新機能が多数増加され、評判は良くなった。
2006年12月24日にはAmigaOne向けのAmigaOS 4.0がリリースされた。
現在のAmigaの知的資産を所有するのはAmiga Incである。同社はAmigaOS 4の開発を監督する立場にあるが、実際の開発はHyperion Entertainmentに委託している。2006年12月20日、Amiga IncはHypelionのAmigaOS 4の開発ライセンスを終了させた。しかし、2009年9月30日、HyperionはAmigaOS 3.1の全世界での独占的かつ永久的な使用・開発・改変・販売・配布の権利とAmigaOS 4.xとその後の（AmigaOS 5 を含む）バージョンを販売する権利を獲得した。
2015年12月にAmigaOS 3.1のソースコードがwebにリークされた。権利を持つHyperionもリークしたという事実は認めた
欧米と日本の人気度の差 北アメリカやヨーロッパでは、Amiga OSが小サイズなのに開発コンセプトが良くて高性能であること、当時としてはAmigaOSで出来ることが画期的であったこと、またデザインの良さでも人気が非常に高かった。欧米では、マルチタスクで画像処理でも日常の文書処理でも使える優秀なOSとして評価が非常に高かった。
日本では、テレビ業界の人々には、子供向けテレビ番組の『ウゴウゴルーガ』のCGアニメでAmigaが使用された場面が出たことでかなり有名である。ただしAmigaはマルチバイト文字への対応に消極的であったため、日本語の「文書」を扱うのには不向きで、一般人への日常用途での販売は伸びず、一般の日本人にはあまり知られないままになってしまった。
コンポーネント AmigaOSは、ROM上のKickstartとディスク上のWorkbenchに分かれている。KickstartとWorkbenchは同時にリリースされ、それぞれ対応したバージョン同士で使うようになっていた。しかし、コモドールがKickstartの開発をやめたため、Workbench 3.5以降はKickstart 3.1のROMにブート時にパッチをあてる形で対応していた。
Kickstart 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 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.x でのユーザインタフェースの改善 AmigaOS 2.0 までは統一的なルック・アンド・フィールのデザイン標準は存在しなかった。アプリケーション開発においてはそれぞれが自前のウィジェット（ボタンやメニュー）を用意する必要があり、Intuitionが提供するサポートは最小限の範囲だった。AmigaOS 2.0には標準ウィジェットセットを提供するgadtools.libraryが追加され、ルック・アンド・フィールのガイドラインとなるAmiga User Interface Style Guideができた。
また、それまでWorkbenchのスクリーンが唯一の共有可能スクリーンだったが、2.0以降ではアプリケーションが他のアプリケーションと共有可能なスクリーンを作成できるようになった。
また、AmigaOS 2.0では単純なハイパーテキストのマークアップ体系とブラウザであるAmigaGuideが導入され、アプリケーションのオンラインヘルプに使われた。また、LISP風のスクリプト言語で動作する標準のソフトウェアインストールプログラムInstallerも導入された。
AmigaOS 2.0までアプリケーションはキーボードやマウスの入力イベントを捉えるためにフックをしかけ、システム全体の入力ストリームを捉えるしかなかった。AmigaOS 2.0では入力イベントを修正したり詳細に調べたりするための標準インタフェースCommoditiesが提供されるようになった。これにより、グローバルな「ホットキー」のキー押下シーケンスの設定ができ、Commodities Exchangeというレジストリでユーザーがどんな入力イベントがあるかを見ることができるようになった。
AmigaOS 2.1ではlocale.libraryが導入され、AmigaOSの英語以外への翻訳が行えるようになった。
AmigaDOS AmigaDOS はAmigaOSのディスクオペレーティングシステム (DOS) 部分である。ファイルシステム、ファイルとディレクトリの操作、コマンド行インタフェース、ファイルのリダイレクト、コンソール・ウィンドウなどの機能を有する。コマンド・リダイレクション、パイプ、構造化プログラミング型のスクリプト言語、システムのグローバル変数やローカル変数といった仕組みを提供している。
AmigaOS 1.xではBCPLで書かれたTRIPOSをベースにしていた。しかし、他の言語とのインタフェースが難しく間違いやすいことがわかり、TRIPOSからの移植はあまり効率的ではなかった。
AmigaOS 2.x以降では1.xとの互換性を保ちつつC言語とアセンブリ言語に書き直された。また、サードパーティーで行われていたAmigaDOS Resource Project (ARP)http://uk.aminet.net/misc/antiq/ARP_13.readmeの成果も取り入れている。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) である 090427 amigau.com。AmigaOS 3.5ではいくつかのRTGシステムがOSに同梱されており、Amiga本来のチップセット以外のグラフィックスカードも一部サポートされた。主なRTGシステムとして、CyberGraphX、Picasso 96、EGSがある。
Amigaには3次元コンピュータグラフィックス機能がないため、3Dグラフィックス・インタフェースも標準化されていない。そのためグラフィックスカードのベンダーがそれぞれ独自の標準（MiniGL、Warp3D、StormMesa (agl.library)、CyberGLなど）を提供した。
Amigaが誕生したころ、デスクトップGUIや表示などに3Dグラフィックス・ライブラリを使うという考え方はほとんど存在しなかったが、Amigaはグラフィックス機能が強力だったため3DCGの開発プラットフォームとして広く使われた。初期の3DCG制作ソフトウェアとしてVideoScape 3DやTrueSpace 3Dがある。その後もImagineやLightWaveがAmiga向けにリリースされている。LightWaveは『バビロン5』などのテレビ番組のCG制作にも使われた。
また、Amigaはビデオ信号のゲンロック（同期）が容易だということでも知られているが、ビデオキャプチャ用インタフェースは内蔵していない。最盛期にはAmiga向けのサードパーティー製ビデオキャプチャ用インタフェースが数多く製造販売されていた。
AmigaOS本来のグラフィック・エンジン兼ウィジェット・ライブラリとしてintuition.libraryがある。AmigaOS 2.0ではそれがGadToolsに拡張された。Stefan Stuntzが開発したMagic User Interface (MUI) が2.0以降のAmigaシステムで使われ、AROSではMUIクローンのZuneを実装、MorphOSではMUIが標準のウィジェット・ツールキットとなっている。また、ClassACTというウィジェット・ツールキットはReAction GUIへと発展し、AmigaOS 3.0および4.0で使われている。AmigaOS 4.0ではReAction GUIが標準の1つとされている。CygnixはAmiga上でX11互換グラフィック環境を提供するものである。他にもcairoやAnti-Grain Geometryといったグラフィックライブラリが一部ベンダーから登場している。
現在のAmigaではクロスプラットフォームのSDL (Simple DirectMedia Layer) エンジンをゲームや他のマルチメディアプログラムによく使っている。
AmigaOS 4.1では3Dのハードウェアアクセラレーションに対応したPorter-Duff画像合成エンジンを採用している。
オーディオ AmigaOSはバージョン3.1まで、Amigaの元々のチップセットのサウンド機能のみをaudio.device経由でサポートしていた。サードパーティーのオーディオカードのサポートはベンダー任せだったが、デファクトスタンダードとしてAHIAHI — Retargetable Audio for AmigaOS et al.が採用されるようになった。AHIは68k系のAmigaOS 2.0以降でOSとは別にインストール可能であるhttp://arp2.berlios.de/ahi/#binaries 2010-11-19。AmigaOS自体がMIDIをサポートしたのは3.1になってからで、Roger Dannenbergのcamd.libraryが標準MIDI APIとして採用された。コモドール版のcamd.libraryにはシリアルポート用ドライバも組み込まれている。後にKjetil Matheussenが公開したオープンソース版camd.libraryにはシリアルポート用ドライバがないが、代わりに外部ドライバを提供している。
音声合成 Amigaには当初からSoftvoice, Inc.http://www.text2speech.com/#aboutsv の開発した音声合成ソフトウェアがあった。これは大まかに3つの部分に分けられる。アメリカ英語で使用するすべての音素を音響信号に変換するnarrator.device、英文テキストをアメリカ英語の音素列に変換するtranslator.library、コマンドラインのユーザーが出力を音声にリダイレクトできるSPEAK:ハンドラである。
AmigaOS 1.xにはユーティリティとしてSayプログラムがあり、AmigaBASICで音声を出力するデモプログラムが付属していた。
音声合成機能はサードパーティーのプログラムでも使われ、特に教育ソフトでの利用が多かった。ワープロソフトのProwriteと Excellence!には文書を読み上げる機能があった。
narrator.deviceの扱える音素には限界があったが、Francesco Devittは任意の言語を音素列に変換するtranslator.libraryを開発した。ただし対象言語には規則群を設定する必要があり、限定的な多言語音声合成を可能としたhttp://uk.aminet.net/util/libs/translator42.readme 。
Workbench 2.0まで音声合成がサポートされていたが、2.1以降は音声合成ソフトウェアが省かれている。
ARexx AmigaOSは、ARexx (Amiga Rexx) と呼ばれるREXX言語をサポートしている。REXXはスクリプト言語で、AppleScriptのようにOSのスクリプティングにも使え、Microsoft OfficeでのVBAのようにアプリケーション内のスクリプティングにも使え、プログラム間の通信にも使える。ユーザーにとっては1つのスクリプト言語であらゆることができるため、便利である。
プログラムは「ARexxポート」の文字列メッセージを待ち受けることができる。このメッセージをユーザーがマウスでボタンを押下したのと似たような形でプログラムが解釈できる。例えば、電子メールプログラム内で表示中の電子メールを読み取るARexxスクリプトを動作させ、外部のプログラムを起動して電子メールの内容を渡して処理するといったことができる。これを使えばアプリケーション間で一時ファイルを経由することなくメモリ上でデータをやりとりできる。
RAMディスク AmigaOSには動的に大きさの変わるRAMディスクがあり、内容によって自動的にサイズが変化する。AmigaOS 2.x以降、ブート時にシステム設定ファイルがRAMディスクにロードされ、OSの高速化を図っている。他のファイルもRAMディスクにコピーでき、アクセスを高速化できる。また、AmigaOS 2.x以降からRAMディスク上のファイルの更新を検知して通知する機能をサポートした。
固定サイズのRAMディスクもサポートしており、中身を退避させて立ち上げ時に再ロードできる。これは通常「RADディスク」と呼ばれており、（ブートセクタがあれば）ブートデバイスとしても使える。
ブートブロック Kickstartは立ち上げ時にブート可能デバイス（一般にフロッピーディスクまたはハードディスク）からのブートを試みる。フロッピーディスクの場合、ディスクの先頭の2セクタ（ブートブロック）をまず読み込み、そこに格納されているブート命令列を実行する。通常このコードはOS（AmigaDOSとGUI）をロードしてそれに制御を渡し、そのディスクをブートボリュームとして使用する。このようなディスクは他にどういう中身が格納されていても「ブートディスク」または「ブータブルディスク」と呼ばれる。"install" コマンドを使えば、ブランクディスクにブートブロックを書き込むことができる。ゲームなどのソフトウェアの媒体には独自のブートブロックが書かれている。そのためゲームやデモといったアプリケーションでは、AmigaOSを使わずにメモリやハードウェアを直接制御することになる。
ブートブロックはコンピュータウイルス作者の格好の攻撃対象となった。ブートブロックがウイルスに感染するとブートコードが書き換えられるため、ブートディスクはうまく起動できなくなる。そのような初期のウイルスとしてSCA virusがある。
技術概要
ライブラリとデバイス AmigaOSのモジュール化技法は動的読み込みの共有ライブラリが中心であり、ディスク上の ".library" という拡張子のついたファイルとして格納されているものと、Kickstart ROM内に格納されているものがある。ライブラリ関数へのアクセスは全て間接ジャンプテーブルを経由して行い、ジャンプテーブルにはライブラリのベースポインタからのオフセットが格納されている。そのため、全てのライブラリ関数に実行時にパッチをあてたりフックをしかけることができ、これはROMに格納されたライブラリでも同様である。
AmigaOSで最も重要なライブラリはexec.libraryであり、ライブラリであると同時にマイクロカーネルExecと見なすことができる。システム上で動作するタスク群のスケジューリングを行い、優先度付きのラウンドロビン・スケジューリングでプリエンプティブ・マルチタスクを実現する。Exec は他のライブラリへのアクセスを提供し、メッセージ・パッシングによる高度なプロセス間通信を提供する。一般にマイクロカーネル実装はメッセージをアドレス空間の間でコピーする必要があるため、性能に問題が生じる。しかし、AmigaOSは1つのアドレス空間しか持たないため、Exec によるメッセージパッシングは非常に効率的である。AmigaOS内で唯一の固定アドレス（アドレス4番地）にはexec.libraryへのポインタが格納されており、これを使って他のライブラリにアクセスすることができる。Exec はカール・サセンラスが設計・実装した。
それまでのOSとは異なり、Execカーネルは特権モードになっていない。当時の68kファミリ向けのOS（Atari TOS、SunOSなど）はトラップ命令でカーネルの機能を呼び出していた。それにより、カーネル機能は68kの「スーパーバイザモード」で動作し、ユーザーソフトウェアは特権のない「ユーザーモード」で動作する。68k上の Mac OS でさえスーパーバイザモードを使っていた。それに対して Exec ではユーザーモードでジャンプテーブル経由で機能を呼び出す。スーパーバイザモードが必要なときは（スーパーバイザモードでないと実行できない命令がある）、カーネルであってもユーザープログラムであってもライブラリ関数のSupervisor()またはSuperState()を使う。
デバイスドライバもライブラリになっているが、標準化されたインタフェースを実装している。アプリケーションは通常、デバイスドライバをライブラリとして直接呼び出すことはなく、exec.libraryのI/O機能を経由して間接的にアクセスする。デバイスドライバも、ディスク上のファイルの形で格納されているもの（拡張子は ".device"）とKickstart ROMに格納されているものがある。
Datatypes DatatypesはAmiga上のデータファイルを扱う独特の手法である。一連の "datatype" を扱う集中型システムであり、対応するdatatypeが存在する任意のデータファイルを読み書き、ロード/セーブできる一連の小さなプログラムの集合体と見ることができる。
ペイントプログラムなどのAmigaの生産性ソフトウェアは、存在する様々な画像ファイルを扱うためにそれぞれの記述子を埋め込む必要がない。Amiga向けソフトウェアの開発においては、Datatypesを扱うコードを埋め込めばよく、そうすることでDatatypesシステムが扱えるあらゆる画像ファイルをオープンしたりセーブしたりできるようになる。
例えば、jpeg.datatypeとtiff.datatypeはそれぞれ対応するファイルフォーマット（JPEGとTIFF画像ファイル）があり、Datatypesに対応したプログラムであれば、これらのdatatypeに対応した機能を自動的にロードして使うことができる。
datatypeのコードを書いて追加することもでき、新たに登場したファイルフォーマットにも対応可能である。
ハンドラとファイルシステム デバイスおよびリソース管理の上位層はライブラリとは異なるタスク型のハンドラ (handler) で制御され、メッセージ・パッシングでやり取りする。
重要な種類のハンドラとしてファイルシステム・ハンドラがある。AmigaOSではハンドラを書きさえすれば任意のファイルシステムを使用できる。これを利用したプログラムとしてAmiga以外のフロッピーディスクを扱えるようにした CrossDOS があり、OFSとFFSという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:Win/Amp または Work:Win/Amp とする。ただし、これらは完全に同じではない。後者の場合、ボリューム名が指定されているので、DF0:に "Work" というボリュームがない場合はDF0:にアクセスしない。その場合、"Work" というボリュームを入れるよう促すようなメッセージが表示される。