[OSASK 1640] Re: ponyets2, toledo2.

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

  こんにちは、川合です。


Koyanagi Masaaki さんは 2001/04/13 00:52:04 の「[OSASK 1639] Re:
 ponyets2, toledo2.」で書きました：

>toledo2 の方で試しました。

  ご報告ありがとうございます。

>>   隠しコンソールで、「memory」と入力してみてください。メモリの使
>> 用状況が分かります。
>アプリを起動すると、16bit memory と 24bit memoryが減少するのですが、
>タスクの起動数制限(8個)を外すと、16bit memory がすぐに無くなってしまう
>ように見えますが大丈夫なんでしょうか？Windowsのシステムリソース
>みたいです。

  メモリの区分は、20, 24, 32bitです。20bitがいわゆるリアルメモリ
で、24bitと32bitメモリがプロテクトメモリです。アプリを起動すると
リアルメモリがわずかに減少し、プロテクトメモリがそれより多く減少
することでしょう。

  20bitメモリは640KBか768KBあります。24bitメモリは、最大で15MBで
す。32bitメモリは最大で4080MBです。

  20bitメモリを使うはめになっているのは、今までのなごりです。プ
ログラムコードをリアルメモリにロードしようとしているせいです。こ
れはそう遠くない将来に解消されます。なお、スタックはプロテクトメ
モリを優先して利用するようになっています。

  現在のOSASKには不可解な動作が随所に見られることでしょう。そし
てそれは不安をかき立てるかもしれません。その場合は、ぜひ今回のよ
うに質問してください。・・・たいていはOSASKの仕様に問題があるの
ではなく、開発を急ぐために書いた暫定ルーチンのせいです。・・・質
問していただければいつでも説明します。

>20bit memory はアプリを起動しても全然変化なしです。

  32bitメモリが無くなれば、24bitメモリを使うようになります。

  結局、20bitメモリが一番貴重なメモリで、ハードウェアの都合で、
このメモリでないとできない事があります。その次に貴重なのは24bit
メモリで、もっとも貴重でないのは32bitメモリです。本来の姿は、全
てを32bitメモリから取るようにすることです。

  なお、ponyets0やtoledo0にもmemoryコマンドがあり、今回のバージ
ョンの方がリアルメモリの使用量が改善されていることが、確認できる
でしょう（起動初期状態での差があるだけで、１アプリに対する使用状
況は変わっていませんが）。・・・あれ？もしかしたら、そこを改良し
たのはもっと前のバージョンだったかな？？？・・・すみません、忘れ
てしまいました（笑）。

>>   また、「mousespeed n」と入力してみてください。nの部分は、0〜4
>> くらいの数字（整数）を入れます。0だとマウスは動きません。1がデフ
>> ォルトです。
>0 でもマウスを動かすと countup4 の数値が減少するので、マウスドライバ
>は常に動いているということですね。

  そうです。・・・が、なるほど、0にしたらマウスドライバーそのも
のを止めてしまうというのは面白いかもしれません。差異を測定しやす
くなるでしょう。・・・今回は、単にマウスカーソルの移動速度を速く
するためだけに書いたのでそこまでは考えていませんでした。

>まず、filec001.c はこのままコンパイルできませんでした。
>動作確認をしてから関数の説明をコメントで入れたと思うのですが、
>/* */ が二重になっているため、正しく解釈されません。

  すみません、おっしゃるとおりです。

>コメントを #if 0 〜 #endif で括り直すとコンパイルできました。

  お手数かけました。

>さて、file001.c と file002.c を見ると、create_module() でモジュールを
>作成している場所がどちらも同じディレクトリであることに気がついたので、
>file002.c の次の 2か所をコメントアウトしました。

  なるほど。しかし、残念ながら、モジュールを生成している場所は同
じではないのです（詳細は、後述）。

>こうしてビルドしたfile002.bin と元のfile001.bin を使用して文字列の
>受け渡しができるかどうかを試してみました。

  僕の説明不足を検証するために、いろいろ試してみようというその姿
勢は、大変良いと思います。ベータテスターの鏡です。

>(1)file002.binを最初に起動します。当然何も書き込んでいないので、
>file002.binのウインドウにはゴミが表示されます。
>(2)file002.binを終了します。
>(3)file001.binを起動します。file001.binのウインドウには
>"this is test."が表示されます。
>(4)file001.binを終了します。
>(5)file002.binを起動します。
>file002.binのウインドウには"this is test."が表示されます。
>(6)file002.bin をもう 1つ起動します。
>file002.binのウインドウにはゴミが表示されます。
>(7)以後file002.bin を新規に起動すると全てゴミが表示されます。

  小柳さんにとってはとても不本意な結果であろうと思いますが、これ
は正常動作です。

>また条件を少し変えてみます。
>
>(1)file002.binを最初に起動します。当然何も書き込んでいないので、
>file002.binのウインドウにはゴミが表示されます。
>(2)file002.binを終了せずにfile001.binを起動します。
>file001.binのウインドウには"this is test."が表示されます。
>(3)file001.binを終了します。
>(4)file002.binを終了します。
>(5)file002.binを起動します。
>file002.binのウインドウにはゴミが表示されます。
>(6)file002.bin をもう 1つ起動します。
>file002.binのウインドウには"this is test."が表示されます。
>(7)以後file002.bin を新規に起動すると全てゴミが表示されます。
>
>1つのfile001.bin の文字列が渡るのは、起動順序によって決まるただ 1つの
> file002.binのみのようです。
>全てのfile002.binに文字列が渡る/全てのfile002.binに文字列が渡らない
>のどちらでもないのはなんとなくすっきりしません。

  なるほど。でも、これも僕には予想される状況で、かつ期待通りの動
作でもあります。

  まず、タスクディレクトリというディレクトリから説明します。

Hidemi KAWAI は 1998/11/13 23:19:44 の「[OSASK:109]タスクまわり
のディレクトリ.」で書きました：

>  どんなタスクも、今から挙げる４つのディレクトリをシェルに要求で
>きます。
>
>１．タスクディレクトリ
>２．ユーザ・アプリディレクトリ
>３．マシン・アプリディレクトリ
>４．ネットワーク・アプリディレクトリ
>
>  これらは、以下のようなルールに従います。
>
>１．各タスクごとに必ず存在する
>２．各ユーザごとに存在する
>３．各マシンごとに存在する
>４．ネットワーク全体でただ一つだけ存在する（ネットワーク対応OSAS
>    Kでサポート）
>
>  たとえば、スタックデータやワークエリアのモジュール、TSSイメー
>ジなどは、１．のタスクディレクトリ内につくられます。また、ゲーム
>のセーブデータなど、ユーザごとに設定を保存すべきであるような情報
>は、２．のディレクトリに保存します。３．には、インストール時の展
>開されたファイルなどがあり、４．は、ネットワーク全体で各タスクが
>協調したり、データをやりとりするために利用できます。
>
>  このディレクトリが実際にはどこのメディアのどこのディレクトリの
>もとにつくられることになるのかは、シェルの権限で決められます（そ
>れはすなわち、ユーザが指定することもできると言うことを意味する）
>。

  ここで説明されているタスクディレクトリと、init_handle()の説明
に書かれているタスクディレクトリは同一のものです。つまり、タスク
ディレクトリというのはタスクごとに生成され、タスクが死んでしまえ
ばいっしょに消去されてしまうんです（デバッグ時などのために、消去
されないようにもできますが）。

  これは、同じアプリであっても別のタスクであれば、違うディレクト
リを指します。そして当然ですが、違うアプリであれば、もちろん違う
ディレクトリです。したがって、filec001のタスクディレクトリ内に生
成したモジュールをfilec002が参照できないは仕様通りの動作なのです
。

  さて、条件を変えると、ある特定のタスクにだけfilec001のモジュー
ルがfilec002へ渡ったかのように見えた例がありました。これは、おそ
らく、filec001の終了後にモジュールがdeleteされて、空き領域扱いに
なります。そしてfilec002のあるタスクがモジュールを作った時に、た
またまそこを確保してしまったのでしょう。

  これで、小柳さんにも動作の不可解さはなくなったと思います。しか
し、ご不満かもしれません。なんといっても、あるタスクが作ったモジ
ュールを他のモジュールで読み込むことが出来ないんですから。

  ということで、そういうテストができるようなバージョンを今日中に
用意します。しばらくお待ちください。


  それでは。

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