OSASKの設計の歴史
(1) 第一世代OSASK
- 「エミュレータOS」構想
- (1-1)既存のOSはハードウェアの性能を引き出せていない。個性あるハードウェアは個性を生かせない（標準的な機能しか使ってもらえない）。ハードウェアがかわいそうだ。だからハードウェアの性能を引き出せるOSを作る。
- (1-2)既存のOSの設計に当たっては、既存のソフトウェア資産に配慮するあまり、大胆な再設計ができていない。だからハードウェアを生かせない。ハードウェアの設計が生かされるように、過去のソフトウェア資産なんて気にせずに設計すべきだ。本当に良い設計とは何かを考えるべきだ。
- (1-3)既存のソフトウェア資産についてはエミュレータで解決すればよい。したがってOSはエミュレータとの親和性が高くなければいけない。エミュレータが作りやすくなるような設計にするべきだ（例外機構や仮想記憶機構をエミュレータに対して開放しているとか）。自分の旧バージョンとの互換性もエミュレータで解決すればよい。だから何度でも設計は大胆に変更できるし、その際に互換性が絶たれても問題ない。
- (1-4)高度な仮想化を実現する。アプリがドライブやパスを直接指定して任意のリソースに自由にアクセスできるのはおかしい。アプリがどこにアクセスするのかを限定するべきだ。そうすればアンインストールは楽になるし、運用中のアプリ単位のバックアップも楽になる。そしてそのリソースの実体がメモリなのかディスクなのかネットワークの先なのかはユーザが制御できるようにしておけばいい。ディスクもドライブ名で指定するのはおかしい。ボリュームネームやボリュームIDで指定できるべきだ（つまり接続方式を変えてもパスは変わらない）。ネットワークパスも同様で、つまりサイトが引っ越してもURLが変わらないようなイメージ。そういう指定方式が標準で使えるべきだ。
- (1-5)タスクセーブ機能があるべきだ。つまりアプリは任意の時点で保存できなければいけないし、そのデータをもとに再開できなければいけない。
- (1-6)これら全てを満たしてもOSのインストールサイズは1MB以下である。
- これらの設計思想を「エミュレータOS」構想とする。OSASKはエミュレータOSである。
(2) KHBIOSとkhaba
- (2-1)OSASKのデバイスドライバを整備したい。それはOSASK用に限定せずに仕様をまとめたい。拡張汎用BIOSということでKHBIOSと命名された。
- (2-2)KHBIOSのデバイスドライバがCPUに依存することなく記述できれば、それはよりいっそう使いやすいだろう。そういうバイトコードを設計しよう。これはkhabaと名づけられた。この名前はJavaやその簡易版であるwabaにちなんで名づけられた。
- しかしどちらもうまく仕様をまとめることができず、これらのサブプロジェクトは中断してしまう。原因は当時のKの技術力不足。
(3) 「はりぼてOS」
- 書籍「30日でできる！OS自作入門」の中で作る教材用OS。難しいことは一切せず、分かりやすさ最優先で書いた。
(4) 第二世代OSASK（efg01）
- 第一世代OSASKを作っているときに気づいたことがある。
- (4-1)もしOSASKが完成すれば、OSASK上で他のOSのアプリケーションは自由に実行できるが、OSASKアプリはOSASK上でしか動かない。それでいいのか？・・・もしよくないのだとしたら、OSASKアプリを他のOS上で動かす仕組みを考えるべきなのではないか？その際はできればエミュレータは使わずに済ませたい。エミュレータは大規模になりがちなので最終手段であるべきだ。
- (4-2)既存のソフトウェアのうち、エミュレータを作ってまでして実行したいものが果たしてどれほどあるのだろうか（過去のソフトはそんなにいいものだろうか？）。それらをOSASK用に移植する手間の合計は、そんなに大きいのだろうか？・・・もし大きくないのだとしたら、エミュレータで解決する方法ではなく、移植させるという方向で考えてもいはずだ。・・・そもそも過去のソフトが色あせて見えるのなぜだ？そうとも、OSASKアプリがすごく小さくて高速に動くのに、過去のアプリは（エミュレータを使わずに実機で動かしたとしても）ムダに大きくてあまり速くはないからだ。それなら一度OSASK用に移植してしまったほうがいい。
- (4-3)これらから趣味でいろいろなアプリを作っていくに当たって、自分はどのOS用に作るのが一番賢明なのだろうか。Windows用？Linux用？第一世代OSASK用？もしこの予想が外れたら、自分はエミュレータ上で過去の自分のアプリを動かすか、もしくは移植しなければいけない。
- (4-4)第一世代OSASKのタスクセーブは実現していなかったが、しかし仮に実現しても基本的には同じハードウェアでしか再開できない設計だった。もし異なるアーキテクチャ上で再開しようとすれば、エミュレータが必要になってしまう。
- やはり理想はkhabaでアプリを書くことだと思えた。これならCPUの主流が変わっても対処できる。もちろんバイトコード方式なので、少し速度は落ちる。しかしそれでもエミュレータで動かすよりはずっと簡単なはずだ。
- (4-5)まとめると、エミュレータは全てを解決する最高の手段であるのは間違いないが、これに頼り切ってしまうのはよくない。なにしろエミュレータを作るのはそれなりに大変なのだから。エミュレータを使わずに解決できることはエミュレータを使わずに解決すべきだ。それで解決できない問題のためだけにエミュレータを使うべきだ。
- しかしkhabaは一度失敗しているので、まずはCPUアーキテクチャ以外の部分を再設計するこことにした。これが第二世代OSASKである。CPUアーキテクチャに関してはx86のままとした。
- (4-6)特定のハードウェアの性能を出し切るための設計をいったんやめて、既存のハードウェアにとらわれることなく、真に良い設計とは何かを考えた。
- (4-7)Windows上でもLinux上でも、エミュレータなしで実行できるようにした。つまりAPIの呼び出しを間接的にして、コードやデータがメモリ上のどこに配置されても平気なようにした。
- このように第二世代OSASKはエミュレータOSであるとはいえなくなった。しかし性能（特にサイズ）は第一世代よりもずっとよくなった。さらに他のOS上でもアプリを実行できるという特徴も実現した。
- (4-8)もっともエミュレータOSらしくないところはハードウェアの個性を生かそうとしなくなったことである。性能を完全に出し切ることもできない。・・・その代わり他の面ではエミュレータOSの方向性をより極めている。
- (4-9)基本的な方向性としては、「過去の資産をどう生かすか」ということよりも、「これから何を未来に残していくか」に重点を置いていた。
(5) blike
- 「C言語でグラフィックをもっと簡単に扱えるようにしよう、そうすれば初学者はもっと楽しくプログラミングをマスターできるはずだ」という思想のもと、KはWindows用の簡単なライブラリを書いた。これは有志によってLinuxやMacOSに移植された。
- これは横浜創英短期大学でプログラミングの講義を担当していたときに考えていた構想。
(6) 第三世代OSASK
- OSECPU-VMのrev1は「第2.8世代OSASK」
- (6-1)いろいろと開発経験を積んでいるうちに、今ならkhabaが作れるかもしれないという感触を持つようになった。しかも(5)のblikeがあるのでグラフィックAPIもWindows上に構築できそうだ。しかし時間がないしきっかけもない。
- (6-2)khaba用にずっと考えていた仮想CPUのアーキテクチャは、実はセキュリティのために生かすことも可能なんだと2011年のセキュリティ＆プログラミングキャンプで思いつく。それを確かめるために2013年のセキュリティキャンプで実際にVMとして作ってみた。これがOSECPU-VMのrev1である。rev1ではJITコンパイラも内蔵していた。つまりOSECPU-VMというのはkhabaVMの簡略版である。・・・これは大成功を収める。アプリは他を圧倒して寄せ付けないレベルのコード密度を達成し、それでいてVMは非常にコンパクトだった。
- OSECPU-VMのrev2は「第2.9世代OSASK」
- (6-3)OSECPU-VMのrev1を作ってみていろいろわかったので、その知識をフル活用し、またkhabaVMから省略していた仕様も復活させて、OSECPU-VMのrev2を作った（作っている）。
(7) ここまでの総括
こめんと欄
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
