![[NYAOS.ICO]](../img/nyaosbnr.png)
| 葉山文書 8/13〜8/30の泣言篇 |
どうも、daemon(CWRP.exe)をひとつ走らせて、そいつに共有メモリを通じて指令 しているようなコード。やはり、自分自身のコンソールウインドウを操作すること はできないのか...
ところで、最近(大阪の)日本橋で、Hobbes OS/2 の CD-ROM を見かけないのは、何故?
★≡
XFree86 のインストールに再挑戦してみました。XFree86 は、I:/ に展開したの ですが、どうも「SET X11ROOT=I:/」としていたのが悪かったようだ。 「SET X11ROOT=I:」とルートを取ってやらなければいけなかったとは。 もっとインテリかと思ったのに...
さて、あとは OS/2 mag. のガイドに従って、結構ほいほい進んだのですが、
最後の startx で、X が起動しない、なぜだぁー。
OS/2 mag. を見直してみたところ、「TCP/IPの設定」を忘れていたようだ。
では、[システム設定]-[TCP/IPの設定(LAN)]...
あれ、アイコンが
(注意)
葉山は自分の PC を、LAN どころか、dialup でもネットワークに繋げたこと が無い。インターネット関係は全て、研究室のワークステーションでやっているのだ。 だから、無くても当然だったりする。それとも、Warp 4 では違うのだろうか...
それにしても、よくつまずいては、すぐ投げ出す奴だなぁ。 こんなありさまで、よくもまぁ、NYAOS を xterm に対応させるなどと 公言したものだ（笑）。
★≡
1.27 で NYAOS のアイコンを作ってみたのですが、いかがでしょうか。だいぶと前には、普通のアイコンが猫の写真、 小アイコンが透明地に黒い字で「猫」とだけ書いてある、 結構、キョーレツなものを使っていました (NYAOS の NYA と猫の「にゃー」をかけているわけです)。 でも、これ、前に OS/2 をクラッシュさせた時に失なわれてしまったんですよね...
ところで、OS/2 のアイコンファイルを GIF にコンバートするツールって 無いのでしょうかねぇ。 そうすれば、OS/2関係のバナーを簡単に作れるのに。 また、Hobbes でも探してみましょう。
さっそく、使ってみたのですが、どうも、二重引用符の中の バックスラッシュ(一般に「¥」ですな)の扱いが違っていて、困りました。 (少なくとも OS/2 の)REXX は バックスラッシュを特別扱いにしないはずなのに、 「"\"」と書いても、後の二重引用符が文字列終結と認識されないんです。 もしかしたら、FreeBSD あたりの REXX は、そういう仕様なのかもしれません。 (ftp-site の FreeBSD というディレクトリに置いてあった)
この rexx-mode.el。スペースバーやリターンキーを叩くと、 直前の単語が予約語だったら、小文字→大文字変換をしてくれるし、 インデントもバッチソなだけに、非常に残念です。 誰か、OS/2 仕様に改造してくれないかなぁ...
まぁ、別に 1.26 に致命的エラーがあったわけではないので、 そう慌てて、置き換えなくてもよかったのですが、 実は前の日に作ったばかりのアイコンとインストーラーを公開したかったという... 何回も Download された方、すみません。 どうも、脊髄反射で Upload してしまうなぁ... 次回のバージョンアップは、いつも通り、一ヶ月くらい先を目途にします。
NYAOS 1.25 の方は、今のところ、バグリポートは、いただいてません
(いただきました on 9/16)。
β公開などと言っていても、別に品質管理体制はいつも通りで、
単なる責任回避の為の文句に過ぎません。
ファイルを破壊するような、えげつないバグは、まぁ無いと思いますし、
β期間が過ぎたから、正式バージョンを新規に発行するかというと、そうではなく、
「はい、1.25 は、もう正式配布ですよー」と言うだけのつもりですので、
躊躇せずに Download されても、別に問題無いと思います、多分。
現在、open文にバグが見付かっています。 致命的なバグではないものの、ちょっと、無視したくないので、 β期間が過ぎたら、修正版を公開したいと思います。 あー言ったり、こー言ったり、ごめんなさい。
今回から、OS/2 の API 関数(と呼んでいいのかな)を、いくらか使ってみました。 まず、open命令を追加しました。これは、WPS でファイルのアイコンをダブルクリック するのと同じ動作を行なう命令で、今まで、よく REXX で実現されていました。 これの実現には「WinOpenObject」という関数を使うのですが、 j-pocket の CP*.INFファイル(フルネーム失念)に載っていなかったために、 長い間、使い方どころか、存在さえ分かりませんでした。 最近になって、os2emx.hのプロトタイプ宣言を見付けて、 「おお、こりはもしかして」と思い、適当に値を放りこんでみて、 使い方が分かった次第です。 本NYAOS版openは、なかなか起動が早くて、使える代物ではないでしょうか？ 一番、多い使い方は「open .」でカレントディレクトリを フォルダーとして開くという事でしょう。
あと、Double Byte文字の判定に、DosQueryDBCSEnv という関数を使うようにしました。 今までは、_nls_is_dbcs_lead関数 を使っていたのですが、どうもこいつは emxlibcs.dll の中に入っていないために、本格的に DLL を使って、 サイズを縮めるということができませんでした。 で、_nls_is_dbcs_lead の使用をやめたおかげで、DLL が使えるようになり、 実行ファイルのサイズが半分になったというわけです。
しかし、view.exe。あの使いにくさは、どーにかならないだろうか。 画面一杯に広がるもんだから、viewの画面を見ながら、 Mule でコーディングするのが、非常にしんどい。 どなたか、view.exe 互換の INFファイルリーダを作ってくれないだろうか。
★
NYAOS 1.25 と同時に、ELL 1.02 を公開しました。 こちらは、ファイル名の検索機能やヘルプなどを追加したのですが、 さっそくバグが出てしまいました。 再帰的に ELL自身を呼べなくなってしまい、 00index.txtや、書庫内書庫の参照が出来なくなっています。 こちらを「β公開」と称するべきでした。トホホ。 また、時間を見つけて、バグを取ります。ふと、思ったのですが、 OS/2 というのは、GUI環境とUNIX文化の理想的な共存環境でありますが、 さらに、DOS的な文化を匂わせるアプリにも最適のような気がします。 UNIXの強者は termcap 等を使って、OS/2 Promptを自在に操ることができますが、 そこまでいかなくとも、emx/gcc には <sys/video.h> に テキスト画面を操作する関数がわんさかあります。 だから、FDのようなソフトを作るのも、さほど難しくないはずなんです。 でも、以外とこの手のソフトの数が少ないですね。なぜでしょう。
一つに入門書が全く無いということがあるでしょう。 僕はプログラムを作る時に参照しているのは、ほとんどオンラインマニュアルで、 emxlib.doc を Mule の一ウインドウの中で開いて読んでいます。 でも、これ英語なんですよね。 OS/2 マガジンでも、emx の連載があったから、プログラミングの連載を期待 したのですけれども、ほとんどインストールガイドで終ってしまいましたね。 まぁ、役には立ちましたけど。
あと、DOSっぽいアプリは、まさしく、DOS 窓を使えばよいと思われているのでは ないでしょうか。でも、OS/2 Prompt ならば、HPFSの長いファイル名を使えたりするし、 いろんな制限が無い分、快適なはずなんですけどねー。 Windows95 user 達が、DOS Prompt で longname を何とか使おうとする姿には 涙を覚えます。誰か、OS/2 を教えてやってください（笑）
究極の理由としては、C言語なんぞ使わずとも、 REXXで簡単な PMアプリが作れてしまうからでしょう。 これは、どうしようもないな（笑） でも、OS/2上で、一番、速く快適なのは、 C言語で作った OS/2 Promptアプリです。 ただし、罫線が化けていない場合に限りますが（笑）
言ってはいけない理由として、OS/2 userの絶対数が...(ボカボカ)
★
「FAT で長いファイル名を使う計画」は、 宇野さんが REXX で一つの解を示そうとされているようです。 ううむ、僕も何かしなければいけないとは思うのだが... 思いっきり、卑怯な逃げ道を示すならば、ハードディスクは HPFS しか使わない、 フロッピーディスクは tar を通じて、テープデバイスとしてしか使わないという方法も ...あ、石を投げないで...。TVFSのようなFATにかぶさるような新しいファイルシステムを作るのが、 最もスマートなやりかたなんでしょうが、ファイルシステムを新たに作るとなると、 技術的には問題ないでしょうが、個人が趣味で作れるレベルをはるかに越していますね。 その上、FAT でも WPS上なら、問題無く、longname が使えますから、 商品としての魅力は無く、売りものとしても実現率は低そうです。 うまく、ゆきませんね。 やはり、置換・補完しかないのであらうか...
まず、環境変数 COMSPEC に NYAOS を指定できるようにしました。 といっても、CMD.EXE が入らなくなったわけではなく、 起動時に、COMSPEC 中に「NYAOS」という文字列が含まれていたら、 CMD.EXE に書き改めて、自分自身を無限に呼び出さないようにしているだけにすぎません。 これの為に、NYAOS 自身のオプションを、CMD.EXE 互換にしました。
あと、ファイル名を補完する際の大文字・小文字を、最初にヒットしたものに合わせていましたが、 これを最も短いものに合わせるようにしました。また「!str」の str も行末ではなく、空白までを 範囲にするよう、tcsh のそれに合わせました。
で、1.23 から、ほぼ一ヶ月経ったし、 あれもこれもと思って、手を出していると、いつまで経っても公開できないので、 ぼちぼち 1.25 を公開しようと思います。 xterm への対応や DOSVPATH については、今回ノータッチになりそうです。 まぁ、この辺は実装すると、1.30 扱いになりそうですから、 次の機会ということで...
しかし、こんな事を言うてる間に kterm がLHAの平松さんの手で移植されそう ですねぇ。その上、TCSH の日本語対応の移植もされると、NYAOS の存在意義というのは完全に無くなってしまうわけで。 まぁ、その時には、ELL みたいな、 OS/2 Prompt上のDOS的ツールの製作への道へ進みましょうかねぇ。
げげ、CMD.EXE って、標準で「&&」とか「||」を サポートしていたのか、知らんかった...ああ、恥ずかし。 さっそく、NYAOS のページから「&&」とかのサポート項を 消しておかなくては。
しかし、過去のバージョンのドキュメントは... まぁ、いいか。
しかし、こんなこと書いている場合なんだろうか、 明日（もう、今日か）の 6時30分 にバス停集合なのに、今、0時12分。おいおい。 まだ、OHP を少々手直ししている最中だという。 真面目な大学人の方々、なんてやつだと、石を投げないでくださいませ。
★
ロングファイル名については、 筑波大学の宇野さんから、 いろいろとアイデアをいただいております。 それに関しては、このページや宇野さんの「独り事」のページを 見比べていただければ、話の推移がお分かりになると思いますなかなか、効率を落さない実現方法というのは見付からないものです。 宇野さんのおっしゃるように、何かよい案がありましたら、 ぜひ、葉山にメイル をくださいませ。
NYAOS に関するメイルというのは、実際のところ、月に二、三通というところなので、 作者に入る情報量は非常に少ないです（そのほとんどはある特定の... いつも、ありがとうございます m(__)m ）。 ですから、メイルをいただいて、五月蝿いということは、決してありません。 今の百倍来ても平気です（本当だな、おい）。
ELL に関しても同様です。 最近になって、初めて使用者の方からメイルをいただいて感動しまくりました。 しかしながら、公開してから、もう一年くらい経つので、 プログラムについてほとんど忘れてしまったという... いや、ニーズがないように見えて、自分も機能にそれなりに満足していると、 ソースに手を加えることが無くなってしまうんですよね。 時間ができたら（いつだ？）、ゆっくりソースを眺めて、 記憶を呼び起こしたいと思います。
FAT のファイル名は 8.3 の制限にしばられますので、ロングネームは 拡張属性の .LONGNAME に保存されます。
NYAOS の対応といえば、今のところ eadir 命令でロングネームを右端に表示するだけです。 この eadir も 1.23 までは bug っていて、カレントディレクトリでの eadir でしか、 ロングネームを表示できなかったりしますが、次のバージョンでは 直っていますので、「alias ll="eadir %*%quot;」として使っても不都合ないと思います。
さて、コマンドラインでロングネームを差す場合となると、例によって、NYAOS 得意の置換処理となりますが、 なかなか、パス周りの置換というのは、やっかいなんですよ。 例えば「C:/foo123456789/b123456789/gar123456789」という絶対パスを指定された場合、その途中のディレクトリ、 「foo123456789」「bar123456789」「gar123456789」について全て、ロングファイル名が存在するか、 どうかチェックしなければなりません。
現実問題として、全ての引数についてチェックするのは、効率が悪すぎるので、 置換の目印となるような記号を置いてもらうようにしてもらうと、 シェルとしては楽になるんですがね（笑） 例えば、使用頻度の低いアットマークを使って 「C:/@foo123456789@/@b123456789@/@gar123456789@」などと使うと、 必要なところだけを置換すればいいので、処理が若干楽になるんです。 LONGNAME には正/逆スラッシュや空白も入り得ますから、まぁ妥当な方法ではないかと思います。 しかし、こんなややこしい方法をとるんだったら、ショートネームを使った方が 速いような気が... ここんとこ、どなたか、いいアイデアあったらメイルください（WWWでもよかったりして）。
なお、ロングネームをリネームするとか、加えるっていうコマンド程度なら すぐに出来ます。要は、comment命令と同じようにすればいいわけですから。 でも、この程度だったら、誰かが REXX で... (それが REXX を一度は否定したものの態度か！ はいっ（笑）)
VFAT のロングネームの対応については、実は前々から「考えは」していて、 「Windows95の中のDOS」とか「続・Windows95の中のDOS」といった本を 買ってたりします。でも、対応できたとしても、おそらく、eadir での表示と コマンドラインでのショートネームへの置換程度だと思います。 書き込みは...怖すぎる...（そこまで誰も期待していない!?）
しかし、どっちともワイルドカードの対応は、ちょっと一筋縄では、いきそうにないなぁ。 なんせ、emx に完全にオンブしてますし。
いや、これは別に僕が OS/2 に見きりをつけたとか、愛想をつかしたとか いうんぢゃなくて、単に OS/2 マシンが下宿にしかなくて、下宿でゆっくり 使ってやる時間がないっつーだけの話なんですね。対して、Solaris は、 研究室の Sun互換ワークステーションで使っていて、デスクトップタイプ だけど、ほとんどノートがわり。シャープペンシル持ってる時間よりも ワークステーションのキーボードに触っている時間の方が長いという...
だから、まぁ、ウェブのページは、研究の合間に気分転換に書くっていうことが できるんですが、NYAOS や ELL の改良は遅々として進まないという...。 うう、言いわけがましい。
XFree86 の xterm に対応すると申しましたが、XFree86 さえインストールしていない状況。 実は昨日、アーカイブを展開したあとのコマンド一つ二つくらい、 そう、RAMDAC を調べるコマンド前後まで進みました(そういうのは進んでいるうちに入らない?!)。 けれど、ビデオカードのチェックで、S3ViRGE なのに、SiS と勘違いしてよるんですよね。 いや、確かに SiS はマザーボードには内蔵しているんですけどね。 このまま進んでもいいのかなぁ。
ところで、NYAOS はここ半月ばかり、全然改良などしとりませんが、その前には
結構ごちゃごちゃといじくってますんで、
関係ありませんが、fj.binaries.msdos.dとか、 fj.os.msdosとかで、Windows95 の LongFileName と 補完のできるシェルの話題がちょっと前に盛り上がっていました。 LFN をUNIX風コマンドラインツールで扱うことに 関してですが、なかなかスマートにはいかないようで... OS/2 なら HPFS を使えばいいだけなんで、全く問題無いのにねぇ。
P.S.
最近、どこか（Web?）で相づちを打たれているような気がします。
気のせいでしょうか