AROS
ベルナルド・イノセンティ(Bernardo Innocenti) (bernie@cosmos.it) - Amiga Life掲載記事
翻訳:ミヨシシンジ(ATO Japan,sdi00828@nifty.ne.jp)
AmigaOSのリライティング
1994年にコモドール社が倒産しAmigaの運命は決まったかに思えた。ウェストチェスタ研究センタが業務を停止し、もっとも革新的なオペレーティングシステムの開発は完全にストップした。Amigaコミュニティの多数のプログラマ達は、AmigaOSをこの悲惨な状況から救うために何かやるべきだと感じていた。AmigaOSのソースコードは秘密のままであったため、やるべきことは袖をまくり上げて新しいAmigaOSをゼロから開発するということだった。
その最初の試みは、しかしながらスタート前の時点で既に方向を誤っていた。Amigaのデベロッパ達は大人数であったため、全体を調整できない状態が長く続いた。最初のプロジェクトのメーリングリスト（参加者の間ではAOSと呼ばれていた）では、メモリプロテクションや非対称マルチプロセッサのような技術的詳細に関して無益な論争が行われているだけで、ついに１行のコードも書かれなかった。
AmigaリプレースメントOS
コモドール社倒産から約３年後、このようなプロジェクトには当初の情熱がほとんど無くなっており、論争も下火となっていた。その頃、Escom社が新バージョンのAmigaOSを新機種 Walker とともにリリースすると発表した。しかしご存知の通り完成前にEscom社が倒産してしまった。
|
当時AmigaOSのリライトを試みる多数のプロジェクトの中で、１つの新プロジェクトが目を引いた。1995年の冬に Aaron Digulla (アーロン・ディギュラ)は、膠着した状況からの出口を探ることにした。彼は RFC (Request For Comment)をAOSメーリングリストに送るとともに、新しいAmigaOSに必要最小限な仕様を決定することを提案した。この働きによって、彼は大勢のデベロッパが参加する新プロジェクトのコーディネータとなった。
以前のプロジェクトと異なり。AmigaリプレースメントOS（略称AROS）は、明確な目的を持ってスタートした。主な目標は、実際のOS3.1を完全に移植することであり、既存のアプリケーションがそのまま動作できるよう可能な限り互換性を保つことであった。実際のOS3.1と異なりAROSは、他のCPUおよびプラットフォームへの移植が容易なように、特に注意して設計されることになった。そのため、ほとんどのコードがプレーンなC言語で書かれており、ハードウェアに関係するモジュールは分離されている。
また、開発の初期段階におけるデバッグを容易にするため、AROSはLinux上で動く通常のプログラムとして書かれている。これによりデベロッパは強力で柔軟性のある開発環境を使うことができる。
|
|
パネル１ - AROS に関する数字
|
OS 3.1ライブラリに含まれる1234のファンクションのうち、
- 274 (20.2%) は未着手
- 160 (13.0%) は作業中
- 800 (64.8%) は完成済
上記ライブラリに含まれない56のファンクションのうち、
- 14 (25.0%) は未着手
- 35 (62.5%) は作業中
- 7 (12.5%) は完成済
|
|
オープン・ソース・デベロップメント
Amigaのほとんどのシェアウェア／パブリックドメインプログラムは１人のプログラマによって開発されているが、大きく複雑なソフトウェアの場合は明らかに限界がある。
UNIXデベロッパのコミュニティでは、プログラムのソースを直接公開して、誰かにバグ修正や機能改善を依頼することが習慣となっている。特別なツールを使用することにより、100人規模のフリーランス・プログラマが参加するような巨大プロジェクトの管理も可能である。
AROSでも同様な開発システムを使用している。ソースはインターネット上にある CVS サーバ(Concurrent Version System)で管理されている。CVSはデベロッパによるソース修正を遅滞なく記録し、修正の目的と担当デベロッパに関するログを保管する。
デベロッパは、サーバに保管されたソースのバージョンを新しくしたり、変更したソースを全デベロッパのためにアップロードすることができる。また、新機能追加に関する議論は、作業を開始する前に aros-dev メーリングリストでおこなうことができる。
各デベロッパは、オペレーティングシステム中の分担したい部分を自由に申し出ることができる。分担した作業の管理は特別なジョブ・サーバが行い、各作業の進捗を記録する。
|
表 1 - ジョブ・サーバのステータス
|
| モジュール | ファンクション数 | 未着手 | 作業中 | 完成済 | |
DevCMD | 129 | 70.54% | 27.13% | 2.33% | |
HIDG | 28 | 39.29% | 60.71% | 0.00% | |
alib_commodities | 7 | 0.00% | 100.00% | 0.00% | |
alib_stdio | 7 | 0.00% | 100.00% | 0.00% | |
arp | 70 | 52.86% | 2.86% | 44.29% | |
asl | 6 | 16.67% | 83.33% | 0.00% | |
battclock | 3 | 0.00% | 0.00% | 100.00% | |
commodities | 29 | 0.00% | 0.00% | 100.00% | |
console | 2 | 50.00% | 0.00% | 50.00% | |
datatypes | 15 | 0.00% | 0.00% | 100.00% | |
diskfont | 5 | 60.00% | 40.00% | 0.00% | |
dos | 154 | 11.69% | 7.14% | 81.17% | |
exec | 118 | 0.85% | 6.78% | 92.37% | |
expansion | 21 | 38.10% | 4.76% | 57.14% | |
gadtools | 19 | 0.00% | 47.37% | 52.63% | |
graphics | 165 | 18.79% | 9.09% | 72.12% | |
icon | 12 | 0.00% | 0.00% | 100.00% | |
iffparse | 40 | 0.00% | 0.00% | 100.00% | |
input | 1 | 0.00% | 0.00% | 100.00% | |
intuition | 124 | 25.81% | 4.84% | 69.35% | |
keymap | 4 | 0.00% | 25.00% | 75.00% | |
layers | 32 | 0.00% | 21.88% | 78.12% | |
locale | 24 | 0.00% | 8.33% | 91.67% | |
lowlevel | 15 | 73.33% | 26.67% | 0.00% | |
mathffp | 12 | 0.00% | 0.00% | 100.00% | |
mathieeedoubbas | 12 | 0.00% | 25.00% | 75.00% | |
mathieeedoubtrans | 17 | 0.00% | 11.76% | 88.24% | |
mathieeesingbas | 12 | 0.00% | 0.00% | 100.00% | |
mathieeesingtrans | 17 | 0.00% | 0.00% | 100.00% | |
mathtrans | 17 | 0.00% | 0.00% | 100.00% | |
misc | 2 | 0.00% | 0.00% | 100.00% | |
timer | 5 | 20.00% | 0.00% | 80.00% | |
utility | 38 | 0.00% | 0.00% | 100.00% |
|
|
AROS フレーバ
AROSは特別な 制作 システムをもっている。同じソースコードから異なるディストリビューションが派生することを許可しているのである。コンフィギュレーションを変えることにより、様々なCPUに対応して違ったフレーバ （味付け）のAROSを作ることが可能である。現在は主に以下の２つのフレーバがある。ネイティブ (native)は例えばm68k CPUで動作し、Amigaのアプリケーションに対してバイナリレベルで互換性を有している。もう１つの エミュレーション (emul)はホスト・オペレーティングシステム上で動作する。
実際にもっとも開発が進んでいるコンフィギュレーションは、UNIXシステム上でのエミュレーションで、それは多くのAROSデベロッパにとってUNIXが望ましい開発環境であったためである。AROSが動作可能なUNIXシステムは、Linux (i386 , m68k) と FreeBSD i386 である。m68k Linux版は、Kars de Jong により管理されており、ネイティブのAmigaアプリケーションが再コンパイルなしでそのまま動作できる予定である。
他のUNIXシステムへ移植する場合は、若干の変更を行うだけで良い。変更箇所は、タスク切替と割込み制御を行う exec ルーチンの調整などである。UNIX上で動作するすべてのエミュレーション版フレーバは既に、Amigaのイントゥーション ( Intuition, 訳注:AmigaOSのGUI ) の画面を表示するために、XWindow上にウィンドウをオープンすることができる。これは、UAEを使っている時と少し似ている。大事な違いは、AROSの全てのコードはホストCPU用にコンパイルされたものであり、ソフトウェアエミュレーションではない、ということである。
この他、ibmpc-ネイティブ フレーバもある。これは他のオペレーティングシステムが動いているような標準的なPCで動作する。現在、フロッピディスクからの起動だけが可能である。グラフィックカード用のドライバは作成中であるため、まだイントゥーションを表示できない。Michael Schultz がこのフレーバの主な作者であり、彼は足りないドライバの作成を行っている。
AROSは、Amigaでもコンパイルでき、Kickstart ROMとWorkBenchのバージョンに対応したライブラリと実行ファイルを持っている。arosboot と呼ばれるツールが、選択されたAROSライブラリ（再起動後に使用される）を読込む。
その行程が終了したら、コンピュータは再起動し、通常と違わないシステムパフォーマンスで動作するところを見ることができるだろう。
|
現在、OS3.1とバイナリレベルで十分な互換性のあるモジュールは、exec.strap, alert.hook, utility.library, keymap.library, commoditiesの各ライブラリである。他のライブラリは、ネイティブのAmigaでまだ使用できない。それはほとんどのデベロッパが Linuxフレーバを使用しており、彼等がAmigaOSの特徴に対して欠けている部分の移植をおこない、最後の作業としてネイティブ環境でのテストとデバッグをおこなっているためである。
AROSは多様な環境へ容易に移植できるように作られており、今あるフレーバも移植を始めたばかりである。AROSをネイティブまたはエミュレーションモードで他のシステムへ移植する際の問題は、作業をおこなうデベロッパが少ないということだけである。数ヶ月前には、メーリングリストで、PowerPCへ移植するための議論が始まった。
Przemyslaw Szczygielski は、Linux APUS, Linux PPC, MkLinux上で同様に動作するバージョンを作成している。
Claus Herrmann は、ネイティブAmiga PowerPCバージョンを作成している。これは Phase 5やHaage & Partnerの
製作した通常の新PPCカーネルとは異なる。AROSは完全なネイティブPowerPCシステムとなり、古い68000CPU用のアプリケーションがソフトウェアエミュレーション無しで動作するだろう。UNIXで動作するようなエミュレーションフレーバ版はすでにできており、PowerPC用AROSが自身の画面を表示して動作する間、オリジナルのAmigaOSも68000で動作する。
製作中
1998年の中頃、AROSプロジェクトは完全にスローダウンしてしまった。このプロジェクトは大変重要なところに達していた。
AmigaOSのカーネル部分(exec, dos, expansion, utility)をリライティングした後、AmigaOSのもっとも重要な部分 イントゥーションを完成させずには続けることができなかったのである。AmigaOSの設計の中で、イントゥーション、input.device、グラフィックス、レイヤーは密接に相互依存しているモジュールである。他の部分ができないままで、ある部分を作成するということは不可能だった。AROSでは、グラフィックと入力(input)にハードウェア抽象化レイヤ(Hardware Abstraction Layer,略称HAL)を導入していたため、問題は複雑なものとなっていた。
1998年末、堂々巡りの技術論争から抜出した後、プロジェクトは素早く再始動した。Nils Henrik Lorentzen, Stefan Berger, Henning Kiel, Bernhard Fastenrath によって作られた特別委員会が、数ヶ月でイントゥーション、グラフィックス、レイヤーを移植した。これによりプロジェクト全体を GadTools, Asl, Boopsiの開発に向けて進めることができた。
Johan Alfredsson はcommodities.library and datatypes.libraryを完成した後、realtime.library と console.deviceの不足部分を作成中である。これにより、Amigaと同じように、CON:ウィンドウとともにシェルを開くことができる。また、Michael Schultz が作成しているドライバが完成すれば、PCのハードディスク上にFastFileSystemパーティションを作ることができ、ibmpc-ネイティブ・バージョンでAROSを起動できるだろう。その間、Branko Collins はAROSのドキュメントの更新と修正をおこない、ウェブサイトを作り直し、9月から参加のデベロッパでない人たちにも使いやすくした。
１つのモジュールが完成に近づく間にも、Amiga用ソフトウェアをAROSに移植することは可能だろう。しかし人的リソースを無駄にしないために、AROSチームは、パブリックドメインで代替品のあるようなシステムユーティリティに関しては、リライティングしないことを決めた。事実、AmigaOS3.1を代替したり改良するようなソフトウェアがたくさん現れた。WorkBenchでさえもScalosやDirectory Opusに置きかえることができる。
本物のAmigaを使っている人たちは、このようなプログラムを、システムの外見や機能を向上するたくさんのパッチとともにインストールしている。機能向上のパッチはAROSにとっては無駄なものである。つまり、完全なソースコードを持っていることにより、このようなものを直接的に簡単にシステムへ織込むことができるので、パッチは不要である。
HIDD
AmigaOSのモジュールには、直接Amigaのハードウェアにアクセスするもの(graphic.library, gameport.device, keyboard.device, serial.device など) があるが、AROSにおいてはハードウェアに依存しないドライバを使用する。これをHIDD (Hardware Independent Device Driver)という。これは、実際には boopsi class だが、オブジェクト指向システムの典型的なインヘリタンス(継承)を使用しており、新しいドライバを実装する際の作業を少なくする狙いがある。正しく設計フェイズを経たならば、目立つような性能低下をすることなく柔軟性を有することができる。
新しいグラフィックボードのドライバは数時間で作ることができる。グラフィック・フレームバッファの初期化と単一ピクセルの描画を行うファンクションのコードを移植するだけである。HIDDドライバの他の全メソッドは、一般的な''graphic device''クラスから継承でき、どんな描画機能もWritePixelメソッドをコールするだけでエミュレートできる。当然ながら、ドライバは後に直接他のメソッド（グラフィックアクセラレーションを使用するもの）を用いて最適化することができる。
この方法によりAROSにおいて、graphics.library は、隠れたHIDDにアクセスする高レベルインターフェース、として簡単にすることができる。
現在、HIDDは 出力デバイスとして X11 window を使用できるようにし、マウスとキーボードの入力を得る部分にも使用されている。IBM-PCフレーバはPCのハードウェアに直接アクセスする同様なHIDDを持っている。Amigaハードウェア用のHIDDを誰も作り始めていないが、作成は容易である。
公開することの問題
皆さんの多くは、こんな重要なプロジェクトが３年近くも影に隠れていたことを不思議に思うだろう。その主な理由はAmiga Inc.(旧Amiga社)と法律上問題を生じる可能性があるためであった。
AmigaOSと同じ機能を持つオペレーティング・システムを配布することは、可能かもしれないが、確実ではない。それは
旧コモドール社が登録し当時のGateway2000社が有する特許を侵害するかもしれなかったからである。Amiga Inc.が法的なアクションを起こした場合、AROSチームはそれに対抗するための経済力を持ってないだろう。
この２年間で、Aaron Digulla とデベロッパ達は、Petro TyschTschenko, Jeff Schindler, Bill McEwenと
会うことを試みた。Amiga Inc.のスタッフの個人的な見解はいつもポジティブであったけれども、公的な回答は得られ
なかった。AROSの立場に関して正しい法的な情報を欠いたまま、熱中するデベロッパ達はソースコードにアクセスするしか
なかった。
パブリック・リリース
その後、U.S. Patent Office にあるコモドール社の特許内容を知ることが可能になった。これによると、特許の侵害を回避するために、イントゥーション部分を若干変更する必要があるようだった。
この情報公開により、AROSをパブリックドメインとしてリリースするための議論ができるようになった。議論の焦点はディストリビューションのライセンスである。デベロッパ全員が非商用のオープンソース・ライセンスとすることに同意したが、
問題は、GPLとBSDライセンシングのどちらにするかになった。これ以外のものが、新たに特別なライセンスを作ることも含めて、たくさん提案された。その結果、最後に決まったものは、MPLである。MPLはGPLに良く似ているが、AROSチームがソースコードを他のライセンス形式でサードパーティに提供したり、Amiga Inc, Phase5, Haage & Partner が商用製品を開発する際にAROSをその一部として使用することが許される。この時、彼等はソースを公開する必要はない。
そして、Aaron Digulla は AROS最初のパブリックリリースのdeadlineを決め、全デベロッパにリリース済の全作業内容を送るよう依頼した。最初のAminetへのアップロードは、World Of Amiga に時期を合わせて行なわれた。ディストリビューションは、sources, documentation, executables for Amiga , executables for Linux の４アーカイブであった。
終わりに
旧コモドール社倒産から６年仟ﾀｫﾀta( )柿匝YH$ｦ&D `仟ﾀ ｪﾀt( )
`hX ｦD B ! Q､ F2f ` q !
Q､ F2b
H
` ( ｿ待ｬ､@雪!hﾎl 1"h`Mﾀ待(ｦ @价!｡k四 1"h Oﾀｿｿﾎｫｽ各 @ｦﾐｴﾝ嬪#hyｫﾑｽ味ｵ'ρ+ｽ界 Tｦﾐｳｵﾝl+hyｫnﾑｽ硲ｱ'ｳｿｿ待,ｦ B低 ｡hﾎl 5"h`Oﾀ泊ﾒ(ｦB倔!｡nﾎl｡ 1"hｪ Oﾀｿｿﾎ+ｽﾊe Pｦﾐ稗ｵﾝ嬪'hy勤ﾁｵｶ｡ｵｷ鳶+ｽﾊe
Pｦﾒsｴ2]嬪/hyｫﾑｽｴ･ｵｷｿwﾛ峪ﾏ湶ｻGXﾔｾt賞&ｾ~oｳwﾛ廂ﾏ渾ﾗ~FXwTｾ蚕&ｿoｳ_鰤?ｿg裃ｹﾀ?儔/ｿﾐ-}{O~/壻矚i?g蜿ｽﾀ?Q?孺ｿﾐ/}O~.壻Aﾛﾏ渝Bﾘﾔpﾟﾜ6ｿmｷSﾊ俣ﾏ沒ｺﾗ>GXwﾛTｾ{\浬ｶ&桎oﾟ?g裃ｽﾁｿ冰?ｿｻﾐ/}O/壻cUiｿg蜿ｱﾀ7 ?ｿﾐ,=sGn/壻A=ﾟyﾙ･攷_輻｣ｲVｿ巉ﾝiｨ;nﾖ稠vﾟyﾙ攣\輾ｿ｣6Rｿﾝ?nﾖ稠Uﾛ化d$勦&皃deﾚﾙｩ2ﾉｵ<ﾃy音,$勦'盒e>eﾚﾛｹ2ﾉｵ}ｿﾟﾟｿﾟﾟｽ}ﾙ･攷ﾟ轎｣ｶVｿ滲i堊n稠w ﾟy勵 ｽ\4ｻΥVs泝ﾝi#n盆稠T化|$勵
gﾚﾙｹ:ﾉｵ8ﾋ{音$$勦~&皃d?eZ ｩ0ﾉｵﾖﾋ<ﾟﾟｿﾟﾟwﾛ9ﾏ渺~GXwﾔｾ|ﾎﾜ&ｾno努ﾛﾖﾏ湶ﾗWXTｾ浬&ｾmｳﾟ鴪?ｿg裃ｹﾀ?儔?ｿﾀ-}{G~/壻Aﾟiﾐ?g蝓ｹﾀ? Q=ｿﾐ/={O~/壻agaLife" width=146 height=37> |
![[Made On Amiga]](../../images/amiga.gif){kind=small}
