[OSASK 1661] Re: ponyets5, toledo5.

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

  こんにちは、川合です。


Koyanagi Masaaki さんは 2001/04/21 22:18:21 の「[OSASK 1660] Re:
 ponyets5, toledo5.」で書きました：

>ponyets5 の直接起動と toledo5 の DOS6 起動を試しました。

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

>tasklist コマンドでタスクリストが 28まで出るので、24タスク
>動いていると思います。これだけ動かすとタスクリストの最初の方が
>スクロールして見えなくなってしまうのは現在では仕方ないですね。

  tasklistコマンドは仮のものです。本来は、タスクマネージャーウィ
ンドウが出て、そこで確認できるようにするべきでしょう。また、コン
ソールにもバッファを付けて逆スクロールできるようにするべきでしょ
う。・・・でも、そういうことは僕は当面やりません。誰かにやってほ
しいとは思っていますが。

  あのコンソールは、全て仮のものです。GUIでウィンドウデザインを
考えるのがおっくうになったからコンソールがついたんです。いわば、
僕が新設した機能がちゃんと動いているかどうかを確認するためだけに
あるといってもいいでしょう。使いやすさは追求していません。それは
また別の話です。

>pokon11 console からタスク番号を指定してウインドウを閉じられるといい
>のですが、これも実現するためにはいろいろやらないといけないでしょうし。

  winman0とpokon0とのあいだでのデータ交換ができるようになりさえ
すれば、これはすぐに実現できそうです。・・・もともと、これは早期
に対応しようと思っていた事項です。ちょっとだけご期待ください（笑
）。

>また、これだけタスクが動いていると、ウインドウ移動時の画面
>書き換えが大忙しになりますね。
>Pentium 90MHz のTOWNSではそれでも一瞬ですが。

  結局、最大タスク数が大きく増えるなら、たとえある程度の制限があ
っても、事実上問題ないのではないかと思いつつあります。まあ、それ
でも改良をやめるつもりはさらさらありませんが。

（起動手順変更）
>TOWNS の方はpokon11が表示されてからFDDアクセスに行くので実感できたのです
>が、
>ponyets5 の直接起動は、ディスクアクセスが今まで通り 4回あってから
>画面が表示されるので、前との変化が分かりませんでした。

  直接起動では、差が出ません。boot時に読んだデーターだけで十分だ
からです。でも、直接起動ディスクからの起動であっても、再初期化時
には差が出ます。・・・でも、その再初期化がうまく行かないそうです
ね。・・・うーん、うちでは問題なかったように思うんですが・・・。

>あとこの変更のためだと思いますが、CTRL+ALT+INSERTがどちらにおいても正常
>動作しなくなりました。これはまずいです。

  あれれれ〜？・・・正常動作しなくなってしまいましたか。おかしい
ですねえ。うまく行くはずだったんですが・・・。

  こちらで追試したんですが、やっぱりうまく動いてしまいます。

>toledo5 の方は、
>・画面下部のタスクバー
>・マウスが左上
>を表示した後FDDアクセスしてpokon11が出ずにFDDアクセスランプが消えて、
>それ以後は CTRL+ALT+DELETE しか効きません。
>
>ponyets5 の方は成功したり、何も画面に出なかったり、
>General Protect が出たりします。再初期化に失敗するとやはり
>CTRL + ALT + DELETE しか効きません。

  これは、再初期化前にタスクをたくさん起動していたとか、そういう
ことはありますでしょうか？起動直後に再初期化してもアウトなんでし
ょうか？・・・もし、条件が判明したらぜひご報告ください。

  うーん、またアップロード時のバグだったらいやだなあ（笑）。

  こちらでも独自の調査をしたいと思います。

  ・・・実は、これに似た障害としてtapiのバグが見付かっています。
いや厳密にはtapiのバグであるかどうかは分かりません。しかし、タス
ク制御とシグナル制御が起動時に乱れるんです。今回はそのバグを修復
せずに回避しています。これが絡んでいる可能性を強く感じます（シグ
ナルの制御に失敗して、ハングアップしているように見えます）。

  このデバッグは難航間違いなしです。いつだって、tapiが絡むとデバ
ッグは大変困難なのです。時間がかかりますので、辛抱強くお待ちくだ
さい。

>確認しました。アプリケーションタスク番号は 5から始まっていて、新たに
>タスクを起動すると空いている番号の内で最も若いものが割り当てられる
>ようです。

  そうです。そういうアルゴリズムで動いています。

>動作確認しました。aball3でも
>sendsignalU 10 3 
>のようにするとゲームがスタートします。

  おお、なるほど。そう、それでいいんです。

>実際には各アプリに毎にどのシグナルが何に対応するか
>(アプリのsignal assign)を、知る必要がありますが、
>これはシェルに聞くことになるのでしょうか？

  これは良いご質問です。

  小柳さんの示唆の通り、シェルに聞くことになるかもしれません。そ
れは一つの方法でしょう。それが悪いとは思っていません。そういうシ
ェルがあってもいいです。でもここでは、僕の設計思想を書きます。

  今は、アプリの中でlib_definesignal1p0()などを使ってキーバイン
ドを指定しています。これは、僕にとってはあまり好ましい方法であり
ません。

  アプリが受け取っているのはキーコードではなくシグナルなんですか
ら、move2のドキュメントに

>  これは、画面のキャラクタをカーソルキーで上下左右に動かすプログラムです。

と書いてあるのはあまりよい表現ではないです。本来は、

>  これは、画面のキャラクタをシグナル4〜7で上下左右に動かすプログラムです。

と書くべきです。どのキーがどのシグナルに割り当てられるかは完全に
ユーザーの権限なのであって、シグナル番号を伏せて特定の割り当てを
前提にドキュメントを書くべきではありません（どのシグナルがどの機
能と関連しているか、読み手に伝わるならどんな書き方でもいいですが
）。

  また、アプリはlib_definesignal1p0()なんていう関数を呼ぶ必要は
ないんです。こんな手続きをしなくても、ユーザーがシェルを操作して
バインドを決定してしまえばいいんです。今はシェルのキーバインドを
設定する方法がありませんが、それができれば、lib_definesignal1p0(
)は「何もしない関数」になるかもしれません。

  しかし、毎回キーバインドをユーザーが指定するのは面倒極まりない
です。ですからそれは設定ファイルのようなものを作り、それをシェル
が読み込んで自動的にバインドしてくれればいいんです。そして、アプ
リ製作者はその設定ファイルのサンプルを付けておくといいでしょう。
この設定ファイルはアプリではなくシェルが読みます。つまり、アプリ
ごとに設定方法がまちまちなることはありません。ですから、この設定
ファイルをいじることは誰にでも容易でしょう。

  また、全てのシグナルに対してなんらかのバインドをしなければいけ
ないということはありません。たとえば、move2においてシグナル5〜7
には何らかのキーを割り振っておいて、シグナル4には全く言及しない
こともできます。そうすれば、どのキーを押してもシグナル4が送られ
ることはありません。ワンキーで左に動かしたいという気持ちがなけれ
ば、割り振る必要は全くありません。

  これを逆手にとる事ができます。move2を改造してシグナル8を受け付
けるようにして、シグナル8を受け取った時は、動くキャラクターの色
が変化するという風にしましょう。このシグナル8をlib_definesignal1
p0()でキーバインドしなければ、このシグナルは通常の方法では全く呼
び出されません。でも、コンソールでsendsignalUを使えば送信できま
す。・・・隠し機能というべきものでしょうか。まあ、バインドが自由
にできるようになれば、隠しでもなんでもないですが（あ、それでも、
ドキュメントで説明されていなければ「隠し」と言えるかもしれません
）。

  デバッグのために隠しシグナルを作るというのはどうでしょうか。

  ええと、話が脱線しつつあるので本線に戻ります。

  機能とシグナルの対応は、設定ファイルのような形で公開すべきだと
いうのが僕の設計思想ですが、これに異を唱えて、その都度アプリに尋
ねるべきだ、という主張をすることは可能です。シグナルの対応状況を
尋ねるためのプロトコルを作り、それをシェル-アプリ間やアプリ-アプ
リ間で通信しあうことで、どのシグナルにどの機能が割り振られている
のかを把握していくことです。シグナルを解釈するのはアプリであり、
そのアプリの仕様をアプリに聞くというのは発想としてかなり本質を突
いていると僕は思います。ですから、誰かがこの発想の元に必要なプロ
トコルを定め、新しいアプリケーション規格を作ってみるのは意味のあ
ることだと思います。

  僕は、「アプリに聞く」という方針を僕は今のところ支持しません。
理由は、以下の通りです。

・ほとんどの場合に有効な、融通のきくプロトコルを提唱する自信がな
  い。
・そのプロトコルに受け応えするためのプログラムコードの分だけアプ
  リケーションサイズが大きくなるのは、なんとなくいやだ。


  それでは。

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