[OSASK 1852] bdarrel2, monaco2.

[Hidemi KAWAI <kawai !Atmark! imasy.org>]

  こんにちは、川合です。

  bdarrel2とmonaco2をベータリリースします。

  これで、前回のような制限はなくなりました。メモリもちゃんと戻っ
てきます。いじりたいところは残っていますが、時間が迫っていますの
で、これが一般公開候補版です。

  さて、ようやく「えせファイルシステム」を説明する時が来ました。
えせファイルシステムは、本来のファイルシステムと比べて、以下の点
が違います。

・オンデマンドでロードするのではなく、オープン時に全体がプリロー
  ドされる
・ライトができない（厳密には、ライトはできるが、メディアには書き
  込まれない）
・本来はPAPIが管理すべきなのに、シェルがやっている
・タグも事実上サポートされていない

  それ以外の点では、本来のファイルシステムとほとんど同じです。

  OSASKアプリでは、ファイルを指定する場合も、slot番号で指定しま
す。そのために、まずはslotが自分の望みのファイルを指し示すように
設定する必要があります。

lib_initmodulehandle1(0x0210 /* slot */, 1 /* num */, 16 /* sig */);

  これは、そのための関数呼び出しです。この関数の実行によって、sl
ot番号0x0210は、ファイルを指すようになります。どのファイルを指し
ているのかというと、それはシェル任せです。一般に、シェルはこの関
数の実行直後にファイルセレクタウィンドウを出し、ユーザーにファイ
ルを選ばせます。そして、選んだファイルがslot:0x210に設定される事
になります。

  numというのは、ファイルセレクタ番号です。値そのものに深い意味
はありません。とりあえず、適当に番号を付けておいてください。

  最後のsigは、slotの準備ができた時に送られてくるシグナル番号で
す。指定した値よりも大きな値が返ってきたら、それはエラーかキャン
セルされた事を意味します。なお、シェルは指定した値に最大でも15ま
でしか加えないので、それより大きな値は他のシグナルのために使えま
す。

  次に、tviewc00.cでは、

    filesize = lib_readmodulesize(0x0210)

を実行して、指定されたファイルのファイルサイズを獲得しています。
そしてついに、

lib_mapmodule(0x0000 /* opt */, 0x0210 /* slot */, 0x5 /* R-mode */,
    (filesize + 0xfff) & ~0xfff /* map-window size */, fp, 0);

で、このファイルをマッピングします。これで、自由に読めます。最初
の1バイトはfp[0]ですし、49バイト目はfp[48]です。fseek()などを使う
ことなく、好きなバイトを好きな時に読めます。

  なお、確保したマッピング領域へのポインタを獲得するために、

    fp = (char *) lib_readCSd(0x0010);

という処理を事前にやっています。この0x0010の部分はいつもこの値に
してください。

  より詳しい流れは、tviewc00.cを見てください。

  マッピング領域に入りきらないようなファイルの扱いを諦めれば、OS
ASKアプリによるファイルアクセスは至って簡単です。マッピング領域
を超えるようなサイズのファイルをまともに扱う場合は、必要に応じて
マッピングし直さなければいけないので、少々ややこしくなります。マ
ッピング領域を増やしてもメモリはほとんど減りませんから、気楽に25
6KBや512KBを指定してください。1MBや4MBとかでもいいんですが、16MB
はやりすぎだと思います。

---

  この流れの中で一度もファイルパスやファイル名を扱わずに済んでい
ますが、これは意図的なものです。OSASKアプリは、一般的に、自分が
アクセスしているファイルのフルパスを知ることはありません。また、
ファイルをパスで指定する方法も用意しますが、その場合も相対パスだ
けです。フルパスは使用禁止だと思ってください（例外を設ける事はで
きますが）。

  なぜこのような仕様になっているのかというと、セキュリティーのた
めです。Windows(95系)やMS-DOSなどでは、ファイルを指定するために
ファイルパスを指定するのはいたって当然の事です。アプリは、どんな
ファイルにもアクセスできますし、そのファイルのありかを知ることに
なります（書き込み禁止属性が付いていれば書き換えられませんが、で
もその属性を変更する事は容易にできるので、セキュリティーという面
では無力です）。

  これはきわめて危険な設計だと僕は思います。アプリが悪意を持って
いれば、どんなシステムファイルであっても改変、削除ができてしまい
ます。こんなシステムは、どんなにタスクの独立性やメモリ保護を充実
させても、いつかは壊れます。

  一方、UNIXなどでは、ファイルはパスを使って指定しますが、ディレ
クトリによっては入れるユーザーが制限されていたりするので、Window
sよりはかなりよくなっています。WinNTなどでは、ディレクトリに入る
ためのパスワードを設定する事もできるらしいです。・・・しかし、こ
れでも僕は満足できません。

  存在を知れば、クラックの対象になり得ます。アプリはクラックして
重要な情報を入手し、何かの拍子にどこかへ送信するかもしれません。
セキュリティーが硬ければ、攻撃されてもそれを検出してやめさせたり
、攻撃に耐えたりできるでしょう。でも、まぐれや巧妙なテクニックで
うまく行ってしまうかもしれません。そのわずかな危険性があることが
、僕は嫌です。

  そもそも、アプリがファイルパスやファイル名を知る必要なんてない
んです（ファイラーなどを除く）。目的のファイルがオープンできさえ
すればいいはずです。そのファイルがどのドライブにあろうと、そんな
ことをアプリに教えてやる義理はありません。

  一方、ファイラーなどはファイル名を変更したり、ファイルを目的の
ディレクトリへコピーしたりするのが仕事ですから、フルパスを知るこ
とは大いに必要です。このような場合は、ファイラーをアプリケーショ
ンではなくて、システムの一部であると考えてください。システムルー
チンなら、アプリが使えないようなファンクションも使えます。そのフ
ァンクションを使えば、フルパスでファイルを指定できますし、その他
のほとんどの事ができます。

  またアプリであっても、シェルなどの支援を得られれば、やはりフル
パスを扱う事はできます。そのようなシェルを設計する必要があれば、
設計すればいいでしょう。


  それでは。

--
    川合 秀実(KAWAI Hidemi)
川合堂社長 / OSASK計画総指揮 / カーネル開発班
E-mail:kawai !Atmark! imasy.org
Homepage http://www.imasy.org/~kawai/