EmulatorOS のバックアップソース(No.1) :: OSASK計画

• 差分^[1] を表示
• 現在との差分^[2] を表示
• EmulatorOS^[3] へ行く。

* エミュレータOS の説明
--しばらくの間、[[K]]が独占的に編集していました。一通り書きおわったので、独占編集状態を解除しました。
--こちらに校正後の文章があります。 → http://www.imasy.org/~kawai/osask/boyaki.html (2003.08.20)
-エミュレータOSは、以下のような性質をそなえたOSのカテゴリ名で、それらの性質の目的も以下に示されている。「エミュレータOS」は固有名詞ではない。エミュレータOSを作成するプロジェクトの代表例は、[[OSASK]]計画である。

* エミュレータOS の語源と基本理念
-今まで大きく普及したOSは、既存のソフトウェア資産を利用できるようになっていた（MS-DOS、LinuxなどのUNIX系OS、Windows、MacOS・・・）。逆に既存のソフトウェア資産を活用できない独自仕様OSのほとんどは普及や発展面で苦戦するのがほとんどである（もちろんわずかな例外はある）。
-したがってOSを設計するならまずは既存のものとの互換性確保を第一に想定するのは当然だろう。しかしそうなると、どうも似たり寄ったりのOSができるだけになりがちである。これは結局既存のOSと大差なく、面白くないし、作る必要性も怪しくなる。
-しかし今やエミュレータという技術があり、これを活用すれば新OSが既存のものとの互換性を意識した設計をする必要はない。互換性の問題はエミュレータ技術を駆使して解決すればよい。そうすれば、おもしろくて大胆な設計ができるはずである。念のために書くが、エミュレータOSは特定のアーキテクチャとの互換性について意識しないというだけであり、どんな環境にも容易にマッチできるような汎用互換性については非常に意識する（たとえば徹底した仮想化設計など）。また互換性維持に縛られなくなった設計の余地を効率の追求や他のOSとの連携などに振り向けるという要請もある。
-これがエミュレータOSという語源であり、かつ、基本理念である。ネーミングからしてエミュレータに関するものだけに関わる概念と思われがちであるが、それは違う。[[K]]がエミュレータ時代の未来のOSはどうあるべきかを考えた理想OSの体系全体を指している。その辺を連想しにくいのでもっと他の名称にするべきだという意見は常にあるし、その件については全く同感だが、他によい名称にめぐりあえずここに至っている。強調しておきたいのは、エミュレータOSにあっては、エミュレータというのは以下の要件を[達成する／思い付く]ための[手段／きっかけ]でしかなく、目的ではないということである。

* エミュレータOS の要件
-足枷だった互換性を気にしなくてよいということで、では何を追求するべきか。エミュレータOSでは、単にエミュレータ技術を前提にするというだけではなく、その上で何を追求するべきかということも要件に含んでいる。
-徹底した仮想化
--ネイティブAPIの設計において徹底した仮想化をしなければいけない。たとえば、あるアプリケーションがあって、それはマシンの空きメモリに応じてテンポラリファイルの大きさを決めるような仕様だとする。このような仕様のアプリケーションはエミュレータOSではありえない。実際のハードウェアに応じてアプリ側が応対するというのは、アプリケーションが外環境に応じているということであり、そんなことはOSの仕事であると考えるのがエミュレータOSである。
--エミュレータOSの理念にあっては、アプリケーションに都合のよい環境を確実に提供するのがOSの使命である。だからFPUが使えるかどうかとか、MMXが使えるかどうかなど、そんなことを問い合わせる方法や必要がある仕様は、エミュレータOSのAPI仕様ではない。アプリは問答無用でFPUが使いたければ使うし、MMXが使いたければ使うし、テンポラリが必要なら十分な大きさを確保するのである。OS側はもしFPUが存在しないのならエミュレーションするし、MMXがないのならエミュレーションするし、メモリが足りなければ（仮想記憶などによって）エミュレーションするのである。
--これによりアプリは「FPUがない場合の計算ルーチン」「メモリが少ないときの処理ルーチン」などというエミュレータ的コードを背負うことなく、シンプルでコンパクトになるだろう。
--むろん、FPUがないときはOSがエミュレーションするよりも、アプリ側で「FPUがない場合の計算ルーチン」を使って計算するほうが一般的に高速に動作する。だから、これを禁止するような要件があるなんて、駄目な仕様だと思われるかもしれない。しかしそれは早とちりである。意外に思うかもしれないが、アプリはFPUを使う演算ルーチンとFPUを使わない演算ルーチンの両方を実装していてもよい。ただ、それが実マシンの状態によって切り替わるというのが駄目だと言っているわけである。ユーザが選択するのであれば良い。
--ユーザが選択するということは、実際にFPUがあるのにあえてFPUを使わないルーチンを使うとか、FPUがないのにFPU用ルーチンを使うということもありうるということである。またユーザが選択するといっても、実行時に毎回ダイアログが出るというわけではなく、問い合わせAPIによって指示を仰いだり、設定ファイル等から読み取ってもよい。
--これにより、たとえば仮にFPUを使わない計算ルーチンにバグがあっても、FPU用ルーチンを使うことでi486SXユーザがバグを回避できるなどというメリットもある。またFPU用ルーチンを使うとCPUによってはなぜか精度が悪いなんていう場合も、非FPU用ルーチンをわざと使わせることができるのである。
--つまりせっかくアプリが両方のルーチンを持っているのだから、実際のハードウェア状態によってどちらを使うか勝手に決まってしまうのではなく、どちらをつかうこともできるようにしよう、ということである。・・・むろん先に書いたように、どちらか一方の処理ルーチンしか持っていなくてもよい。
--エミュレータOSのアプリにあっては、ファイルの有無や状態なども「環境」である。これも仮想化しなければいけない。○○というファイルがあるか？という問い合わせはできない。どんなファイルがあるかという問い合わせもできない。○○というファイルを開けということはいえる。実際にファイルがあるかないかに関わらず、OSがそのファイルへのアクセスを受理すればアクセスできるし、受理しなければアクセスできない。それだけのことである。仮にそのファイルを無事に開けたとして、はたしてそのファイルはもともとそこにあったのか、それともOSが急いで生成して適当に中身を書いてでっち上げたのか、それを区別するすべはない。
--したがって、エミュレータOSのアプリにあっては、「ファイルがありません」というエラーメッセージはない。「ファイルが開けませんでした」ならありうる。実際にあるかないかはアプリには永久に分からないからである。またアプリは"ABC"というファイルを開くように指示したのに、OSからは"DEF"というファイルのハンドルを渡されることもありうる。しかしとにかくアプリとしては"ABC"を開いたつもりになるしかない。他に情報が得られないので判断できない。
--APIのバージョンを問い合わせるようなファンクションもありえない。ver.1では○○というファンクションを使い、ver.2では××というファンクションを使ってください、みたいなAPI仕様がありえないからである。つまりOSに関する情報も「外環境の情報」であり、これを取得したりこれに応じてアプリの動作が変わるような必要は全くないのである。（もしも相当することをやりたいのであれば）むしろ立場は反対であり、アプリは「今からver.2のファンクションを使うよ」と宣言するのである。アプリがOSに合わせるのではなく、OSがアプリに合わせる。
--当然のことながら、特定のハードウェアが不在かどうかとか、そういう問い合わせファンクションも存在しない。ビデオカードがあるビデオモードをサポートしているか、なんていう情報も取得できない。現在の画面モードも取得できない。独立して走っている他のタスクのことも知り得ない。アプリにとってはありとあらゆることが不明であり、意識する必要の無いものである。本当のことを検出する必要がないし、むしろ検出して動作を変更されたらそれは害でしかないので、検出する方法も極力つぶしておくのが望ましい。
--このような徹底した仮想化のおかげで、エミュレータOSのアプリの抽象度は高く、他のOS上で実行するに当たっては、かなり少ない労力で可能であろう。アプリ自身が根本的に環境に依存しないためである。
--APIコールについては、INT命令などタスクごとにローカルな設定ができないものはふさわしくない。タスクごとにAPIブリッジを使い分けたり、他のOSでブリッジを介して動作したりしやすいように、LDTなどのタスクローカルなものを使うのが望ましいだろう（もちろん、細工をすればINTやGDTもタスクローカルにできないことはないが、そんな苦労をしなくてもいい仕様のほうがより良いといえるだろう）。

-Win+VMwareなどはエミュレータOSとはいえない理由
--Windows環境にVMwareなどを使ってLinuxアプリケーションを走らせる、という方法でのソフトウェア資産の継承は、エミュレータOSの目指すところではない。その程度で我慢できるのなら、わざわざエミュレータOSなどということにこだわる必要はない（この手法は互換性の確保をアプリケーションに任せてしまうというものであり、エミュレータOSの思想と対立する考えかたである。エミュレータOSでは互換性の解決はあくまでもOSの側の責任と考えている）。
--エミュレータOSにあっては、WindowsにおけるDOSアプリケーションのエミュレーションのように（註：Windows_MeやNT系ではエミュレーションがどうなっているのかよくわからないが、ここではWin95やWin98などの場合を想定して書いている）、それぞれのアプリケーションはネイティブアプリケーションと同じ操作方法で起動し、普通のウィンドウになり、ネイティブアプリウィンドウと自由にオーバーラップし、カット／コピーバッファも共有され、そのほか原則としてネイティブアプリと対等に動作するものでなくてはならない。これさえ達成できれば、エミュレータ方式の詳細については、エミュレータOSという概念では特に規定されない。

-APIブリッジ・柔軟なファイルシステム・タスクセーブ
--APIブリッジというのは、本格的なエミュレーションを行なうことなくAPIをフックするだけでネイティブAPIでサポートされないアプリを実行させる仕組みである。エミュレータに頼るのは最後の手段ということにしておいて、APIブリッジで可能なものはAPIブリッジで実行するほうがいいだろう。
--エミュレータといえば、たいていディスクイメージを実ディスクのように扱う機能がある。そしてこれは実に便利でもある。エミュレータOSではエミュレータで培われた技術を積極的に取り入れていくので、この手の機能は当然のようにOS側に実装される。Linuxなどはディスクイメージをマウントすることができるが、これは有効な機能である。これも仮想化の一端である（デバイスの仮想化）。
--エミュレータOSはさまざまなOSのアプリケーションをエミュレーションするために、雑多なファイル属性をサポートする必要があるだろう。したがってそのような柔軟性をそなえたファイルシステムをサポートする必要がある。また任意のOSのメディアフォーマットを読み書きできる必要がある。
--優秀なエミュレータには状態保存機能があるが、エミュレータOSはタスクセーブ機能を持っていなければいけない。タスクセーブの方法はいろいろあると思うが、最低でも次の一つの方法はサポートしなければいけない。・・・タスクセーブしたことをアプリにまったく検出させることができない方法。またアプリケーションタスクは必ずセーブできなければいけない（システムタスクなどはセーブできなくともよい）。
--セーブしたタスクは容易に複製でき、また容易に同OSが走る別のマシンで実行できなければならない。
--タスクセーブをどのように実装するかについての詳細はエミュレータOSという概念においては特に規定されない。

-他のOSとの共存を前提に
--このOSはパーフェクトだから、他のOSと連携する必要などない！という態度は、エミュレータOSの設計とは無縁である。あらゆる手を尽くして他のOSとの連携をはかり、共存共栄を目指す。それがよい競争を生み、ひいては自分のOSの向上にも繋がるだろう。
--具体的にはたとえば、そのOSをインストールすると他のOSがインストールできないなどというのは非常によくない。それに加えて、相手OSの資産を活用するだけではなく、相手OSにとって自分のOSの資産が活用しやすい仕様を目指すべきである。・・・このような姿勢を守っていれば自分のOSがバージョンアップしたときに、簡易なAPIブリッジ程度で自己の過去の資産を容易に引き継げるだろうという期待も持てる。
--しかしだからといって、既存の仕様と似たり寄ったりのものを作ってもしょうがなく、技術的な必然性や妥当性があるなら革新的な仕様を採択するのは大変好ましい。ここで言っているのは、他のOS上で実行しにくくするために故意に仕様を複雑にしたりしてはいけないということである。
--OSを切り替えて使う人の利便を考えると、起動速度、終了速度が高速なことはとても望まれることである。KHBIOSとの連携機能を実装すれば、そのOSの終了と同時にブートセレクタを経由せずに目的のOSを起動する機能などが実装できるので、前向きに検討する価値があるだろう。

-高効率の追求
--エミュレータOSが他のOSの機能を有し、他のOSのアプリケーションやデータなどを利用できるということになれば、当然のことながら他のOSは機能的な優位性を誇ることはできない。勝手な推論であるが、競争の結果として最終的にすべての汎用OSはエミュレータOSになるだろう。そうなるとエミュレータOS同士の競争になる。エミュレータOS同士ということであれば、お互いに機能的にはほとんど差がないことになる。そうなると、優劣を決めるのは効率になるに違いない。だから、効率の追求もエミュレータOSの要件である。
--効率というのは、できるだけ少ないバイト数で、できるだけ高速に実行するということである。サイズについては当然のことながら、OSだけが小さければいいというわけではない。アプリケーションも小さくなるような工夫がなければ意味はない。データも小さくなるような工夫をするべきである。・・・なお、速さは低クロック動作でも快適に動作しうることにも直結するので、低消費電力という方面でも活躍できるだろう。
--一プログラマとして助言すると、最初に適当に機能優先でプログラムを作って、そしてボトルネックをちょちょっと書き直せば、確かに十分な機能を有して十分な速度のソフトウェアを作ることはできるだろう。しかし、これはサイズにおいては非常に不満な結果になる事が多い。もし最終的にサイズも十分なものを作ろうということであれば、慎重な設計と何回かの作り直しが欠かせないだろう。いい加減な設計をすると、その設計に思考が縛られてしまい柔軟な改良ができなくなることがある。それゆえ、最初からサイズや速度などの効率に気を配りつつプログラムを書いていくのが結局は近道であると思われる。もちろんそれでも作り直しは避けられないと思うが、作り直し回数は減らせるだろう。
--サイズへのこだわりや起動速度などに配慮すると、必要なモジュールをオンデマンドでOSにアタッチする機能が必要だろうと思われる。ついでにデタッチも付けよう。そうすれば再起動なしにOSの構成を変更できるし、不要なリソースを食わなくできるし、起動も速くなる。ということで、これらの機能も当然エミュレータOSの要件である。

-要件外の部分の具体例
--OSを作る動機として革新的な外観の実現を挙げる人がいるくらいに、OSがどのようなユーザインターフェースをもつかは重要な問題である。しかしエミュレータOSという概念としては、ユーザインターフェースについては一切規定しない。ただ、既存のOSのアプリを動作させる以上は、同等かもしくはそれ以上の操作性は確保してほしいところである。CUIでも、GUIでも、もしくはそれらを越える新しい操作スタイルであっても構わない。
--OSやアプリケーションをどんなプログラミング言語で作成するかということについても、エミュレータOSとしては規定しない。効率の追求をし始めるとある程度限定されるような気がするが、言語の進歩はまだまだいろいろと余地があるので、以上の要件さえ満たせるならなんでもよい。
--OSASKのメモリレスアーキテクチャなどもエミュレータOSの要件ではない。よりよい方法があるならそれを使ってよい。・・・というかメモリレスアーキテクチャはどちらかというとOS設計におけるチャレンジである。まだこれが既存の方法と比べて良いという実証が得られたわけではなく、したがって現段階の見解としては一般的な仮想記憶を使ったエミュレータOSがあってもよいだろう。
--新OSが出てくるとたいてい話題になる、モノリシックカーネルかマイクロカーネルかということについても、エミュレータOSという規定の上ではノータッチである。OS開発者がベストの道を見極めて進んでほしい。なんといっても、OSの構成方法はモノリシックカーネルかマイクロカーネルのどちらかしかないというわけはなく、そんなことにこだわってもしょうがない気もする。

* エミュレータOS の必要性・可能性
-十分な機能を有して、過去の資産を活用でき、そして速くてコンパクトで消費電力も抑えられて、その上新たに産まれたソフトウェア資産の活用も容易になるだろうということであれば、いったい他にどんな点を付け加える必要があるだろうか。・・・エミュレータOSによってもたらされる未来よりも輝かしい未来を他のOSが提供できるだろうか。まさに次世代OSを名乗るにふさわしいだろう。

* 補足
-もはや動けばそれで良いという時代は終わった。単に目的の動作をするプログラムがかければいいというわけではなく、それをどれだけうまく実現するか、という時代であろう。エミュレータOSというのはそういう時代の要請を敏感に察知して、打ち立てられた概念である（やや先走りすぎて、提唱者さえも要求を満たすOSを作るのに四苦八苦しているが・・・笑）。
-以上を読んでもらえれば分かると思うが、エミュレータOSにとってエミュレータドライバを揃えることは全体の要件からするとあまり大きなウェイトを占めない（むろんこれも必須条件であるので、無視していいわけではない）。むしろその他に要求される要件の難易度が高く、設計・実装に当たっては多くの考察が必要だろう。
-OSとして安定して動作するとか、マルチプロセッサに対応するなどということは原則として当然のことであり（効率を追求しておきながら、マルチプロセッサに対応できないなんてことは意味不明な方針すぎる）、そういう言うまでもないことはいちいち書いていない。こういうことはわざわざエミュレータOSの要件に組み入れなくてもいいと思うので、組み入れない。これらはエミュレータOS以前の問題であったり、方針の一貫性に関する問題である。

* みんなのコメント
-テスト -- [[K]] SIZE(10){2003-06-08 (日) 18:52:23}
-こんなペースで書いていたら、いったいどのくらいの長さになってしまうんだろうか・・・。 -- [[K]] SIZE(10){2003-06-08 (日) 23:32:39}
-一通り項目は埋めました。これからちまちまいじりますので、まだ独占編集させてください。 -- [[K]] SIZE(10){2003-06-09 (月) 16:51:10}
-2chのOSASKスレッド5の326さん、感想をありがとう！ -- [[K]] SIZE(10){2003-06-09 (月) 17:25:24}
-内容もまあまあまとまったし、手元にバックアップもとったので、独占編集を解除します。 -- [[K]] SIZE(10){2003-06-20 (金) 13:08:07}
-質問はこちらでいいですか?例えば、将来的に誰かがFreeDOSのアプリをOSASKで動かしてみようと思い立ったとします。(長いのでコメントからはみだします -- [[名無しさん]] SIZE(10){2003-10-09 (木) 15:42:33}

+DOSEMUをOSASKに移植し、OSASKのFDイメージを、DOSEMUと共有。FD内にはFreeDOSのKERNEL.SYS,COMMAND.COMが収まっている。DOSEMU.BINはOSASK.EXEに組み込まれている。ユーザーはその存在を意識する必要は無く、たとえばEDIT.COMを実行するとcons00で書かれたコンソール内でCOMMAND.COMがDOSEMU経由で実行され、EDIT.COM[\n]がコンソールに送り込まれる。
+KERNEL.SYSで使われているAPIやCOMMAND.COMをOSASK.EXEに実装。(移植と言うよりコード見ながらのクローン?)たとえばEDIT.COMを実行するとOSASK.EXEの持っているコンソールでネイティブなCOMMAND.COMが実行され、EDIT.COMを実行する。

エミュレーターOSは、後者の考えであっていますか？それともまた別の概念でしょうか？
-おお、ここに質問を書かれるとは思わなかった・・・が、ここは書いてもいいですので、お答えいたします。 -- [[K]] SIZE(10){2003-10-09 (木) 15:59:20}
-現状と理想がずいぶん離れてますよね。現状のAPIを使ってもエミュレータ－は作れるわけですが、KタンはOSが理想状態になったらエミュレータ－にとりかかろうという意見なんですか？ちょっともったいないなぁ。DOSより軽くて、DOSの制約にしばられない32ビットOSってプラットフォームとしてすごく魅力的だと思うのですよ、個人的には。 -- [[ベイサイド]] SIZE(10){2003-10-09 (木) 16:07:48}
-そうですねえ、FreeDOSエミュレータだとしたら、KERNEL.SYSはOSASK.EXE行きでしょう（ドライバという形で存在 -- このへんは2ですね）。COMMAND.COMはどっちになるか微妙なところです。しかしEIDT.COMの実行に際してはいちいちCOMMAND.COMを経由しないと思います。エミュレータドライバが、COMMAND.COMがやるような基本的な環境のセットアップをして、EDIT.COMをロードし実行すると思います。つまり、直接シェルを使わない範囲おいては、COMMAND.COMは不要というわけです。 -- [[K]] SIZE(10){2003-10-09 (木) 16:09:52}
-ありがとうございました。 -- [[名無しさん]] SIZE(10){2003-10-09 (木) 16:12:49}
-誤解を受けないでほしいのですが、はっきりいってゲームのエミュレータは作っている本人しか面白くないです（笑）。やるんだったら、LinuxとかDOSとかMacの実行エンジンを作るほうが実用性が高いでしょう。そういう意味ではQtやGtkの移植なんて面白そう。 -- [[ベイサイド]] SIZE(10){2003-10-09 (木) 16:14:38}
-今の順番はこうです。OSASKだけでmailとwebブラウザとIRCができるくらいまで仕上げる（まともなところもあるかもしれませんが、多分半分以上はえせ）、そしたらぼちぼち汎用エミュレータコアを書きたいなあと思っています。そんなわけで理想的な状態になるまでエミュレータドライバ周りを作らない、というわけではありません。＞ベイサイドさん　　でもベイサイドさんの意見でちょっとわからないのは、DOSより軽くてDOSの制約に縛られない32ビットOSというプラットフォームが魅力的、というところです。つまりエミュレータはなくてもいいということなんでしょうか？でも前半を読むと、はやくエミュレータに取り掛かるべき、という意見のように見える・・・。 -- [[K]] SIZE(10){2003-10-09 (木) 16:15:28}
-LinuxとかWinとかの実行エンジンはもちろん作りたいですが、そういう意味で今一番雰囲気が近いのはWaba2だと思います。きたいしています。 -- [[K]] SIZE(10){2003-10-09 (木) 16:20:24}
-エミュレータに取り掛かると2chでさんざん文句いっている連中が少しは減るかと。あと、世間的にも有名になるかと（ReactOSみたいに）。 -- [[ベイサイド]] SIZE(10){2003-10-09 (木) 16:21:30}
-プラットフォームが魅力的・・の部分に関しては、エミュであれ、普通のアプリであれ、640KBのメモリー制約にしばられなくていいのが、楽です。あと簡単に絵を書けるAPIがあるので使いやすいです。HTMLデコーダーは作りたいなぁ。でも、8.3形式でディレクトリのないファイルシステムだとちょっとつらいかな。 -- [[ベイサイド]] SIZE(10){2003-10-09 (木) 16:23:57}
-そうでしょう？・・・ということファイル周りとかも直して、それからエミュレータに行きたいわけです。なんというか、エミュレータOSにあっては、エミュレータは過去の資産を活用可能にして移行を促すためのものであって、ネイティブが魅力的でないとちょっといじってサヨナラパターンになりそうで・・・。そんなわけで、先にネイティブだけでもそれなりにはしたいわけです。2chとかでいいたい人は言わせておけばいいんです。本当に不満なら彼らは僕を説得できるような議論を展開するか、もしくは自分で作るでしょう。ただOSASKをけなしたいだけなら、けなせばいいんです。そんなつまらない遊びに付き合って、方針を変える必要はないと思っています。・・・まあ今はとにかくKHBIOS優先です。 -- [[K]] SIZE(10){2003-10-09 (木) 16:30:44}
-個人的な要望としては、KHBIOSとファイルシステムまわりがある程度逝けば、ネットまわりよりも先にエミュ関連がほしいなぁとか思います。 -- [[名無しさん]] SIZE(10){2003-10-09 (木) 18:37:23}
-質問。http://www.imasy.org/~kawai/osask/osask_qa.htmlを見ると、"ファミコンなどゲーム機のエミュレーションもしたい"とありますが、MLを見るとInfoNESはバンドルしないとあります。その理由の１つとしてROMのバンドルの話がありますが、これは、将来的にはバンドルできるROMがなくても、NESドライバーとしては用意されるのでしょうか？ -- [[名無しさん]] SIZE(10){2003-10-09 (木) 19:11:24}
-はい、そのとおりです。しかしそれはおそらく追加パックから追加でインストールすることになるでしょう。利用者が限られると思われますので、おすすめパッケージからは外されます。もちろん僕以外の人がリリースするディストリビューションに関してはこの限りではありません。 -- [[K]] SIZE(10){2003-10-09 (木) 19:20:11}
-わかりました。 -- [[名無しさん]] SIZE(10){2003-10-09 (木) 19:32:33}
-書き忘れましたが、「個人的な要望」はちゃんとチェックしました。要望を寄せてくださってありがとうございました。＞名無しさん -- [[K]] SIZE(10){2003-10-09 (木) 20:05:29}

#comment

• EmulatorOS のバックアップ一覧^[5]
• EmulatorOS のバックアップソース(No. All)
  • 0: - no date - ^[6]
  • 1: 2003-10-24 (金) 07:32:00
  • 2: 2004-04-15 (木) 15:37:23^[7]
  • 現: 2024-01-08 (月) 12:58:40^[8] ゲスト