Re^3:WK32004a.LZH WKISS32 v0.04a

>WKISSが非アクティブ時はfkiss動作を中断するようにしています。
>これは、Win3.1で重いfkissデータを表示している時に
>ダイアログがなかなか開かないという事が起こっていたからです。

ううむmmm... こいつはマズいぞ。
処理を停止してる時間が長ければ、
その間に処理することがたまってしまうので
例のルーチンだと間に合わなくなりますね。
どうしましょうか？ 困ったな...

Windowsの詳しいことは知らんのですが、
噂にきいたところ、Window SystemのI/O queueが全部で１個だったと思います。
だとしたら確かにfkissだけがむやみやたらとqueueを消費するのも問題だし。
このへん誰か教えて！

ちなみに、X11のfkissの場合、
クライアント毎にqueueが独立なので多少改善はされますが、
やはり同様の問題が発生します。
そのクライアントのqueueが肥大して仮想記憶を食い尽くしたらコアダンプです。

このように重いデータについては、いろいろ弊害も出てきますが、
まあ実際に重いデータなんだからしょうがないだろうという気もしています。
重いって話題に関して、以前から思ってたんですが、
半透明処理って、やっぱ重いですね。
はっきり言って私のとこの環境じゃ、とても実用にはならない速度です。
やはり正式採用は見送ったほうがいいでしょうか？

半透明でない256色でも、
目パチをさせると操作性が悪くなるのでやめることにしたとかいう話すら
聞くくらいですから、KISS本来の操作性に障害がでることは
できるだけ避けたほうがいいと思ったりもしています。

プログラムを作る側としては、
もうちょっとマシなマシンを使ってくれよ
と言いたくもなるかもしれないんだけど、
それを言ってしまったら MicroSoftと一緒になってしまうからイヤだ！

ついでにこのさい、MicroSoftへの悪口を言っておこう。
... (親の親ディレクトリ)とか
%CMDLINE (最後に実行したコマンドライン)なんかの
command.comの安直な拡張はもうやめてくれ！

CMDLINEとか、bashの _ のまねっこだと思うんですが
便利そうだと思ったら考えもなしに拡張して！
勝手に環境変数領域を食いつぶすのはやめろバカ！
それに ... とか、これまでもドライブの問題でパス解析面倒だったのに
もうつきあってらんないぞ！

こんなしょーもない拡張する暇があったら、
コマンドラインの制限を128文字以上にするとか
やることいっぱいあるだろう！

あー、言いたいこといったらすっきりした。

                                        yav@mte.biglobe.ne.jp
                                        UHD98984@biglobe.ne.jp
                                                        yav