第二世代OSASKについて :: OSASK計画

第二世代OSASKとは？ ^[1]

ものすごく簡単に言えば、ほぼゼロから新しく興しなおす。第一世代OSASKの作り直しバージョンだと思ってください。

• 第一世代OSASKとは？
  • 2000年5月頃から川合秀実氏が発表を続けていた独自OS。2004年12月発表のVer4.7を最後に休眠。

※以下、上記第一世代OSASKを第一世代、第二世代OSASKを単に第二世代と呼ぶ

なぜ作り直すのか ^[2]

• ことの経緯は第一世代の Ver.4.8(試作。一般公開はなし）に手を入れていたあたり
• この頃はKHBIOS、はりぼてOSが作くられていた。特にはりぼてOSは書籍用のもの。かなり時間を割いて専念していたらしい。
• 川合氏曰く、これらを作るために猛烈に新しい技術等を勉強していたとのこと。
• さてはりぼても無事完成。ひさしぶりに第一世代のソースを眺めてみて・・・げー！これじゃダメだ！って思ったんだそうです。（勉強したりいろんなものを作っていく上で川合氏自身のスキルや考え方が大きく変化したらしい）
• ・・・で！　それら新しい技術で試しにいくつかのAPIやツールを試作してみると、第一世代よりずっといい感じに仕上がってしまったと。
• 「こりゃばかばかしい。これで最初から作っちゃったほうがいいじゃないか！」と。
• で、手元にある改良が容易なはりぼてOSにAPIをどんどん乗せていくと・・・いけるいける！と。
• そんなわけで、はりぼてを土台にした第二世代の試作が形になってきた。こういう流れだそうです。
• もっとも改良しすぎてもうはりぼては見る影もなくなっちゃっているそうですがｗ

第一世代を建て増してゆくのに限界が出てきた。ヘタに手直しするより新しい技術・新しいツール・新しい設計で作り直したほうが早く良いものができるかもしれない。こうした考えから始動したものです。

※ただし。この第二世代は第一世代のように単独で動作するOSという形にはなりえていません。誤解を恐れずに言えば、第三世代へのたたき台・部分試作的な色合いが強いです。第二世代の技術やノウハウを元に第一世代のように単独で動き、起動可能な第三世代へに着手が予定されています。

よく「OSASKはもう終わった」という発言がありますがそれは間違いです。新設計の元、作り直しているのです。

作り直しによる成果 ^[3]

せっかく動いていた第一世代を事実上凍結してまで行った作り直し。その成果は？？？

アプリのサイズ： ^[4]

まずは川合氏拘り(笑)のファイルサイズについてです。*1

アプリの実行ファイルがコンパクトにできることを最優先に、徹底的に再設計されたようです。

川合氏にとって「人生の最高傑作」といっても恥ずかしくないレベルに達っすることができたとのこと。なにしろ世界最高の仕様を目指したようなので。

• いくつかの例

• • コンソール画面に「hello, world\n」と表示するアプリを、わずか16バイト！
    • アプリの先頭の2バイトは誤認防止用のシグネチャが入っており、DOSの.COMファイルのようなヘッダのないフォーマットではありません（このシグネチャは全ての第二世代用・第三世代用のアプリに共通して含まれます）。
    • 「hello, world\n」はそれだけで13バイトあります。アプリのフォーマットの効率の高さ（無駄の少なさ）が察せられるのではないでしょうか？
    • 「hello, world\n」に特化したAPIを持つなどの卑怯なことはしないで実現しています
    • （参考：DOSの.COMファイルで書くと22バイトになります）。

• • コンソールに「 !"#$%&'() ... uvwxyz{|}~」と、キャラクタコード0x20から0x7eを出力するプログラムを作ると、第二世代用はたった13バイトになります。
    • あったりまえですがこれは16bitアプリではなくもちろん32bitのネイティブアプリです。
    • （参考：DOSの.COMファイルで書くと17バイトになります）。

• • 第二世代用のアプリにはcpy.g01というものがあり、これはファイルのコピーや連結を行うことができるアプリです。このアプリは引数無しで起動すると、usageが出力されます。

　　　　　 usage>cpy.g01 [in:]input-file [[in:]input-file]... out:output-file

• • • これの文字数を数えると、66文字あります。しかしながらこのcpy.g01というファイルは45バイトしかありません。たったの45バイトでも、コピーや連結ができる上に、66バイトものusage出力が可能なのです。
    • 第一世代用のものでもとても小さいことがウリでしたが、第二世代はさらにその上を行きます。（そしてこれが、x86の本当の能力なのです。）

• 誤解がありそうなので書いておきますが、ただアプリを縮めるのではありません。こんな小さなサイズでもキチンと動作できるAPI。普通に作っても小さくなってしまうAPI。これが第二世代の能力です。

アプリの互換性 ^[5]

第二世代～のアプリは他のOS上で実行可能！？？

第一世代のアプリはQEMU等のエミュレータ無しではWindows上で実行することができませんでした（そらそーだｗ）。

しかし第二世代用のアプリはのエミュレータを使わずにefg01と呼ばれる20KB程度のローダを使うだけで、Windows上での実行が可能です（efg01の大きさはバージョンabcdw014時のもの）。

• efg01つーのが専用のエミュレータってところか？
• そんなふうに考えてもらっていいと思います。
• 「なんだよQUMEがあるのにわざわざ独自エミュ作ったのかよバカバカしい！」
• まぁそんなふうに考えることもできるでしょう。

• なんでヘンな独自エミュ作るの？qumeでいいじゃん！
  • まずは。圧倒的に小さい小さいってこと。QUME等はPC/ATが持つすべての機能をエミュレートしないといけません。機能・プログラムは複雑になり、速度も問題になってきます。efg01は本体がたったの20kbです。

他の独自OS(第一世代を含む)

ネイティブアプリ → 各種独自OS → QEMU → 実際のOS(Win・Linux・MacOSX等）→ 実機が動作

efg01を使い、OSASK-HBアプリを実行

ネイティブアプリ → eg01 → 実際のOS(Win・Linux・MacOSX等）→ 実機が動作

• • これを見ただけでも無駄を大きく省いていることが解ると思います。

efg01は既にLinux用・MonaOS用・MEG-OS用もある ^[6]

はりぼてOS用・第一世代用、その気になればTownsOS用やDOS汎用（DOS|Extender的なもの）も可能なはずです。
基本的にx86用32bitOSであれば、ほとんど対応可能なはずです。 efg01の移植には多少の苦労が伴いますが、それさえできれば、第二世代用のアプリは再コンパイルしなくてもバイナリのまま動いてしまいます。それに苦労といってもたかが20KBのアプリです。それだけで全ての第二世代用のアプリが使えるようになります。

第二世代用（のAPIを利用した）アプリは単に機能密度が高いというだけではなく、OS横断的な共通互換アプリしての資質まで備えているのです。

• Javaでいいじゃんｗｗｗ
  • Javaや.netというすばらしい先人がいます。これらはx86という壁も越えているので、互換性に関しては格が違います。
    しかしその代償としてJavaや.netのランタイムは非常に大きく、waba等の軽量実装でさえ40KBを切ることは非常に難しいです。
    また第二世代用のアプリはx86ネイティブなので、JIT等が不要で実行開始までのレイテンシもほとんどありません。そして多分Javaや.netでは.g01よりも小さく作ることはできないでしょう。・・・したがって第二世代を「バイトコードを使わずにやったらどこまでいけるのか」の実験例としてみていただければと思います。

この「エミュレータなしで実行可能にする」を実現しようとすると、APIの設計の選択肢が減ります。そのため第一世代用アプリでは実現できませんでしたし、他のOS用のアプリでもこのような特徴を挙げているものはほとんどないと思います。サイズの追求という面とは競合もしています。つまりこのバイナリ互換を捨てれば、アプリサイズはもっと小さくできたのです。・・・しかしこれは逆にとらえてほしいです。互換性まで盛り込みながらも、このサイズを達成できているのだ、と。

バイナリのまま互換を保てることで生まれる可能性 ^[7]

• 当然ですが、第一世代用に作ったアプリを他のOSで動かそうとすると丸々移植・・・いやそれどころか事実上作り直しになるでしょう。
• せっかく苦労してアプリを作ってもOSASKでしか動かない。アプリを作ってくださる人のモチベーションを大きく下げる要因かもしれません
• しかし第二世代用に作ったアプリはソース互換どころかefg01によってバイナリが直接動作します。つまり、「移植をする」という手間どころか概念が不要になるのです！

実用性 ^[8]

APIがいくらもない物が小さくても当たり前だろｗ なんも作れネェよこんなんじゃｗｗｗ

おっと。こう考える人もいるかもしれませんね。（現にまだまだAPIは不足しています）
でもそう考えるのは早計ですよ。アナタが望むアプリはまだ作れないかもしれませんが、既に十分実用できるものが作られ、実際に動いています。

• 例：nask
  • 第一世代(OSASK)や「はりぼてOS」の開発ツールの定番に、naskというアセンブラがあります。（naskについてはこちら）
  • naskはwin32版で27,648というサイズで、x86用アセンブラとしては世界最小をうたっています。このサイズは当時から「さすがだ」とたくさんの人に評価していただいています。
  • このnaskはすでに第二世代用（efg01で動く）に移植が完了していて、そのサイズは22,824です。つまり4,824バイトも小さくなっているのです。
  • naskは決して多機能とは呼べない（GAS等のモンスター級に比べればｗ）単機能アセンブラですが、現に第一世代（OSASK）・そのアプリ・はりぼてOSのコンパイルに実際に使用されています。そしてこの移植時にそれらの機能はなにも損なっていません。
  • 先のefg01を持っていれば、この小さくなったnaskもWindows上で実行できますしLinux上でも動いています。（当然eft01さえ移植すれば、他のOS上でも動きます。）
  • こんなに小さくなったのに・・・・

移植したのはnaskだけではありません。以下に代表的な例を挙げます。

           ・obj2bim　　	12,800 → 6,272	　汎用リンカ
           ・gas2nask　　	11,155 → 4,559	　gccの出力するアセンブラをnask用に変換
           ・bim2hrb　　	4,096 → 384	　「はりぼてOS」用のリンカ
           ・makefont　　	3,072 → 72	　OSASKと「はりぼてOS」用の半角フォントデータ生成プログラム

これはある意味福音かもしれませんな。
実際に極初期のこれらのツールをLinuxに移植した時はすごく大変でした。
（今は元の段階から他OSへの移植を考慮されているので技術的にはずいぶん楽にはなりましたが）
技術的なことはもちろんでしたがとにかく数が多い！
アレを移植して次にこれを移植して・・・
少なくともバイナリのままで動き、移植はefg01のみに集中できればどれほど楽か・・・ね。

問題点は？ ^[9]

• 残念ながら現時点ではGUIまわりのAPIが装備されていません。
• 第二世代用のアプリケーションフォーマットやAPIは、残念ながら第一世代とは互換性のないものになっています（とはいえ、APIブリッジなどでサポート可能ではありますが）。
• ドキュメントやサンプル等、作ってみたい人へのフォローが貧弱すぎる（汗

リンク ^[10]

技術的な細部に興味があるひとは、とりあえず http://wiki.osask.jp/?OsaTech^[11] を見てください

第二世代の構想の最中、K氏によって書かれた文書郡