OSASK-WikiのKの落書きの過去ログ

  • 本家:OSA:K
    • 過去ログにコメントしたい人も、本家のこめんと欄に突っ込んでください。
      • そのうちKによって下のこめんと欄に移動しますので。

OSASKアプリの仮想化について

  • (2004.08.16)
  • 背景
    • OSASKでは一般のアプリケーションが取得可能な情報はきわめて制限されていますし、動作できる内容はさらに制限されています。たとえばOSASKアプリは現在の解像度も色の状態もOSに尋ねることは許されず、解像度を指定することもできません。
    • 普通のOS作者は、気軽にこう考えます。・・・ゲームとかでは全画面でやりたいこともあるだろう、じゃあ画面モードを切り替えて解像度や色数を指定するAPIは必要だな、じゃあつけよう、と。でもOSASKはそうしません。
    • どうしてそういう機能がないのかといえば、そんな機能をつけたら「全画面でしか」プレイできないゲームになるからです。画面モード切り替えAPIがなくても、ユーザは画面モードを好きなように切り替えられますので、全画面でもウィンドウの中ででもどちらでもゲームできます。しかし画面モード切り替えAPIがあれば、ユーザの「選択の自由」は奪われるわけです(もちろんAPIがあってもOSがそれを無視するモードを付ければいいという考え方もできる。しかし無視されるかもしれないAPI呼び出しにいったいどんな意味があるだろうか?)。
    • またかつて話題になったタスクセーブ機能もあります。アクションゲームやシューティングゲームなどでは、どの瞬間でも好きなタイミングで状態セーブができてしまう、なんていうのはゲームプログラマにとって悪夢かもしれません。ここで普通のOS作者なら、そういうプログラマの要望に応える形で、OSに対してタスクセーブを禁じるようなAPIもつけるでしょう。しかしOSASKではそうしません。もちろん、「タスクセーブをしてほしくない」というアプリケーションからの意思表示APIはつけます(これがあるとタスクセーブ時に、「このアプリはタスクセーブしてほしくないと意思表示しています。それでもタスクセーブしますか?」という確認ダイアログが出る)。しかし結局ユーザがタスクセーブする、を選べばタスクセーブされることに変わりはありません。さらにアプリは自分がタスクセーブされたことを感知する手段は全くありません。だからタスクセーブされたらゲームオーバーにするとか、そういうこともできません。
    • 他にも典型的な例としては、一般アプリは広大なファイルシステムの中のごくごく一部にしかアクセスできません。基本的な発想としては自分がインストールされているディレクトリがルートみたいなもので、そこから出られないのです。なんでこんな制限があるのかというと、たとえばアプリがc:\windowsディレクトリや他のアプリがインストールされているディレクトリに勝手にアクセスして、個人情報や過去に扱ったファイル履歴などを暗号化して自分の内部に溜め込んで、なんかの拍子に送信したりしたらいやだからです。また大事なファイルを狙って消してくるかもしれません。
  • アプリケーションは誰の意思を反映したものだろうか?
    • 以上のような考え方のもとになっているのは、アプリプログラムの意思(=プログラマの意思)は、ユーザの意思を代弁しないことがありうる、ということです。
    • 普通のOSではそのようには考えません。たとえばLinuxの場合、僕がappというアプリを実行すれば、appは僕と同じアクセス権を有してその範囲で自由にアクセスできます。僕にできることはappにもできるのです。これをOSASKでやったとしたら、appは解像度を変えることができて(だって僕は自分のマシンの解像度を変えることができるから)、タスクセーブを抑止することもできて(だって僕はタスクセーブを我慢することだってできるから)、いろんなファイルにアクセスできます(もちろん許可のない他人のファイルは見えませんが)。
    • もし全てのユーザがプログラマで、しかも各自は自分が作ったアプリ(もしくは他人が作ったかもしれないけど、内容を完全に把握していて完全に意にかなったアプリ)だけを使っているのなら、この「普通のOS」仕様でいいのです。しかし今やパソコンユーザのほとんどはプログラマではありませんので、そんなことは望めないでしょう。また仮にプログラマであったとしても、自分が使用するアプリのソースは全てすみずみまで読んだから怪しい動作や気に入らない動作をしないと確信できる、なんて言える人がどれだけいるでしょうか。僕は今までたくさんアプリを書き、コンパイラもアセンブラもライブラリもアーカイバもみんな自作のものばかりを使っていますが(そしてそのうちにはOSもOSASKに移行することでさらに自作率は上がるでしょうが)、それでも他の人が作ったたくさんのアプリのお世話になっています。そのほとんどについてソースすら見ていません。
    • ということで、アプリケーション作者とユーザは、多くの場合では別人で、だから意思があわないことが十分にありえます。OSASKアプリではソースを非公開にしてもいいので、プログラムの動作が気に入らなければ、我慢して使うか、もしくは全く使わないかのどちらかしか選べないこともありえます。・・・さて、それでは、意思の不一致が起きた場合、どちらを優先するのか、ということになるのです。そして常にユーザの意思を尊重しよう、というのがOSASKの方針なのです。
  • プログラマから、制限が多くていやだ!の大合唱
    • まだ散発的にしか起きていませんが、そのうち「OSASKはいやだ。だってきいてくれよ、現在の解像度は分からないし、自分がインストールされているパスも教えてくれないし、どのキーを押したかも分からないし、本当の経過時間もわからないし、FPUがあるかどうかも、SSEがつかえるかどうかも、サウンドカードの名前も、ドライブ構成も、もうなんにも教えてくれないんだぜ。」なんていう意見がたくさん出るでしょう。
    • 彼らは言うのでしょう、「SSEが使えるかどうか分かれば、SSEがあるときは高速化できるっていうのに・・・」と。そういうプログラマは、普通のOSでのプログラミングに慣れきっているのです。実際にSSEが使えるかどうかにかかわりなく、ユーザがSSEを使ってほしいといえば(つまり設定ボックスで設定されたら)使えばいいのです。SSEがあってもSSEを使いたくないことはあるでしょう(SSEの有り無しでベンチマークしたいときとか、特定のCPUにバグがあってSSEのある命令はうまく動作しないとか、エミュレータ上で走らせる関係でSSEよりも通常命令のほうが速いとか)。
    • こういうプログラマは、もちろん悪意などなくて親切のために、各種のハードウェア情報を取得してあれこれ世話を焼こうとしています。でもそういう人に限って、まさかSSEが使えるのに使わないと設定する人がいるとは思えない、とかいうのです。・・・また真のゲームクリアのユーザにだけエンディングを見せたいと思うばかりに、タスクセーブが許せないのです。ユーザの中にはお金を出してゲームを買ったけど、結局1年がんばってもクリアできず、エンディングを見れないで終わった人もいるのです。そんなユーザの中には、タスクセーブを使ってクリアしたいと思う人がいるでしょう。その自由をうばってはいけないと思うのです。コンピュータは人間の道具であって、人間の意志に逆らうべきではありません。ゲームプログラムのせいで我慢しなければいけないなんて、僕はばかげていると思います。
    • OSASKの一般アプリ用APIが目指しているのは、どこまで実際のハードウェアの情報を伝えないで、多様なアプリを作れるようにするか、です。キー状態を取得できなくても、ユーザがAを入力したいという意思表示をすれば(そういう意思表示を受け取るAPIはある)Aを表示すればいいんです。狭いディレクトリの中だけでも、たいていのことはできます。
    • そしてそれだけではどうしてもできないことだけを、システムアプリケーションという扱いで克服するのです。ユーザはシステムアプリだけを警戒すればいいのです。
  • みんなプログラマにしてしまおう
    • 僕のこの発想は「ユーザはプログラマではない」という前提がありました。この前提を克服するという作戦もあります。UNIXなどではどちらかというとこの路線でしょうか。単機能アプリを作り、それをパイプなどでつないで使うわけです。こうすることで、ユーザはコマンドラインでごくごく簡単なプログラミングをしていることになり、つまりユーザは全てプログラマである、ということになります。
    • まあ要するに、プログラミングを簡単にすればいいのです。簡単にすればみんなプログラマになれます。・・・しかし、この「簡単にする」手法のほとんどすべては、パーツ(ライブラリ)を組み合わさせることを「プログラミング」としていて、そのパーツの中身を十分に理解しているとか、怪しい動作をしないかとか、そういうことに関して克服できているわけではありません。やぱり個々のパーツが不本意な動作をしないようにするAPIは必要だと思います。
    • また仮に自分がすべてプログラミングできたとしても、プログラムにはバグがあるかもしれない、という問題があります。自分で書いたプログラムだからといって常に信用できるというわけではありません。通常はうまく動いているように見えても、ある特定の条件が重なると、重要ファイルを削除してしまうようなバグがあるかもしれません。
  • まとめ
    • 結局OSASKのアプリAPIの仮想化はチャレンジなのです。こんなAPIではほとんどアプリが作れないということになり、だからほとんど全てのアプリがシステムアプリになってしまい、仮想化構想は失敗に終わるかもしれません。逆に、この制限下でも十分に多様なアプリを作ることができて、アプリがどんな悪意を持っていても自分を壊すことくらいしかできないような、ウイルスやバグに強いOSになるのかもしれません。
    • どっちになるのかは、まだ誰にも断言できないと思います。
  • 蛇足
    • 簡単な問題を簡単なプログラム(簡単なアルゴリズム)で解決することは、普通のことです。複雑な問題を複雑なプログラム(複雑なアルゴリズム)で解決するのも、これまた普通のことです。かっこいい(?)のは、複雑な問題を簡単なプログラム(簡単なアルゴリズム)で解決することです。・・・なお、簡単な問題を複雑なプログラムで解決するのは、ただの無能か手抜きだと思います。・・・一応断っておきますが、これはすべて僕の個人的な思想です。
    • 僕の発想を極論すれば、ウイルスを避けるにはウイルス的動作につながりうるようなあらゆるAPIをアプリから使えなくしてしまえばいい、という単純明快なものです。こうすればウイルスは進入するかもしれませんが、肝心の悪さができません。他のOSはこうはしません。ウイルスを入れないことばかりに苦悩します。過去との互換性のためだったり、移植性の関係でひとそろいのAPIをそろえることを優先するあまり、ウイルスを避けるために新しいファイルを保存するたびに膨大なパターンデータと比較してみたり、アプリに作者情報をつけてみたり(そしてそれを偽称されないようにまた苦労する)、認証機関で認証したものだけをアプリと認めるようにしてみたり、まあどうするのかわかりませんが、苦労しているなーと思います。

リロード   新規 編集 差分 添付   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS
Last-modified: 2006-02-16 (木) 17:59:57 (5977d)