読まなくてもいいよ１２

OSTRACISM CO.

■　開発日記　巻之十二

OSTRA / Takeshi Yoneki

　６月に注文した米Gateway2000社のマシンは結局届かず、９月にキャンセルして、１１月中頃にやっと代金が返ってきた。トラブルなしで米Gateway2000社のマシンを購入できた人の話なんて聞いたこともないが、ここまでひどいのも珍しかろう。
　で、さっそくPCダイレクト社に電話してマシンを注文した。マシンスペック的に欲張るのはやめて、その分を確実にパフォーマンスに影響のでるメモリ増設に当てた。
　米Gateway2000社は５ヶ月来なかったがPCダイレクト社は５日で来た。なんてこったい。
　Pemtium 100MHz、32MByte RAM、256KByte Cache、SiSチップセット、S3 Trio64 2MByte VRAM、ATAPI ４倍速CD-ROM、E-IDE 1GByte HDD、14400モデムカード、サウンドブラスター１６、ミドルタワーケース、ってなところか。ケースは予想以上にかなりでかくて重い。ネジなしで開けられるってのは評価に値するが、閉めるのが案外面倒くさい。
　ちょうどSUPER ASCIIにWindows NT 3.51のβ版がついてきたのでインストール。セットアップ時にまだありもしない、一応買う予定のNE2000互換イーサボードの指定なんてしちゃったのが悪かった。ワークステーションサービスが起動できなくなり、新規ユーザ登録をできなくなってしまった。
　で、また全部ディスクから消して入れなおし。今度は素直に入れたら何の問題もでなかった。NTには嘘はつけない。
　NTはサウンドブラスター１６も、当然ATAPIもドライバがあるので、大抵のことは基本的にWindows3.1でなくてはならないことはない。QuickTime for Windowsも問題なく動作する。マルチメディア（Ｈ CD-ROM）のOSとして使える。
　閑話休題。
　本題はLinuxである。
　CQ出版のLinux本を買ってきてあまり考えずに進めたが、一番最初はそもそもブートフロッピーも動作できなかった。で、いくつかやってたら最初のブートがちゃんと進むやつもあったが、どうもCD-ROMを認識しない。
　まさかとnewというディレクトリの方を探すとIDECDというそれっぽいブートイメージがあり、そのドキュメントにちゃんとATAPIとあった。LinuxにとってはまだまだATAPIってのは新しいのね。
　で、Linuxのインストールに進むことができるのだが、インストーラを使うといろんな種類のカーネルを「入れるか？」と聞いてくることに気付くのに時間がかかった。で、どうにも合致するカーネルイメージがない。
　メッセージをよく読むと他のCD-ROMを使うやつはQシリーズのカーネルを使えとある。Qシリーズを見るとここにもやっぱりIDECDってのがあった。このカーネルを使わなくちゃCD-ROMは認識しない。
　何度も入れては再フォーマットをくり返し、気がつくと512MByteあてたLinuxパーティションはdfで５０％をこえてしまった。結構入れたな。dfでDOSのパーティションも見れるってのが面白いね。早くも1G DISKの半分は使ってしまっている。TeXなんて使うかどうかもわかんないものまで全部入れちゃったからねぇ。
　X-Windowの設定にxf86configというプログラムを使った。XF86Configとは違うようだ。RAMDAC云々の話がよくわかんなかったが、適当にやったら簡単に起動までは行けた。でも画面が希望と違っていた。etcにあるコンフィグファイルを見てて思ったのが「なんで複数設定があるんだろう、どれが選ばれるんだろう」で、１つ残して残りをコメントアウトしたら希望する画面でXが立ち上がった。やったついに家庭でX-Windowだ。
　まだCannaをFEPとして使ってMuleを-nwで動作している段階だが、Vzと比較できるくらい軽いね。さすがPemtiumだ。実際Windows95よりはX-Windowの方が軽いかもしれないな。Windows3.1とはどっこいどっこいってところだろうけど。
　日本語環境の本格的整備はこれから。twmってシンプルでいいね。

褌1.5 / 1995.11.12

Subject: PC/AT
Date: Fri, 01 Dec 95 16:52:54 +0900
From: Takeshi Yoneki

こんばんは、米木です。
代金が振り込まれて即、PCダイレクトにマシンを注文しました。11/13に電
話したら11/18には届きましたので5日で配達されたということになります。
普通はこうなんでしょうね。

ひとつ質問ですが、米Gateway2000社からの返済はあったんでしょうか？解
決に要した時間とその経緯を知りたいと思います。また別のトラブルが発生
しているならそれも知っておきたいと思います。

マシン構成はCPUランクを下げて（Pentium 100MHz）、メモリを増やしまし
た（32MByte / Cache 256KByte / VRAM 2MByte）。Triton + EDO RAMは現在
性能ではなく名前だけで値段が高くなっているので、SiS + DRAMといういた
って普通の構成です。

快調にLinuxが動作しています。体感スピードはまるでRS/6000ですね。CISC
のNEWSとは大違いです。

Takeshi Yoneki

　同僚のほりけんがAT互換機見物に来て、Classic IIでグライダーをやろうとしたときにそもそも変であった。マウスとキーボードが全く効かなくなっていた。ADB関係のトラブルらしい。ADBのトラブルは初めてだ。しばらくガチャガチャしてたら動き始めたので、何らかの接触不良じゃないかということにしておいた。
　AT互換機のLinuxをホストとして、シリアルでClassic IIをつないで端末にしようと思い、インターリンクケーブルすなわちリバースケーブルを買ってきた。Linux側のinittabにおける-Lオプションに気づくまでは悩んだが、なんとか端末として接続できた。マック側はモデム接続用のケーブルがそのままインターリンクケーブルに接続できる。AT互換機のシリアルポートは98とはオスメスが逆なので違和感を持っていたが、そのままケーブル２つをつなげられるってのは面白いと思う。
　Classic IIを起動した時にマウスのスピードが遅いことに気がついた。キャッシュも32KByteになっている。メニューの点滅も３回だ。やられた、電池切れだ。
　本体を開けてリチウム電池を取りだしてテスターで計ってみると案の定電圧が低い。ＣＯＣＯ姉ちゃんのハナシによると今年はClassic II電池切れの当たり年だそうだ。早速新宿T-ZONEに電話を入れた。

「Classic IIのリチウム電池は在庫ありますか？」
「取り寄せですが、修理扱いになります」
「修理？なんで」
「逆に入れたりすると飛んじゃうんですよ」
「はあ、いくらです？」
「７千円です」
「えぇ、たかが電池交換に７千円だって？」
「そうです」
「どこかに電池売ってませんか？」
「メーカーが修理用としてしか出さないんですよ。秋葉原に行ってもたぶん手に入らないでしょう」
「そうですか、わかりました」

　そんな馬鹿なハナシはないはずと、結局いつものマイルストーンに電話した。

「Classic IIのリチウム電池取り寄せできますか？」
「はい、えぇと９百円になります」
「あ、取り寄せられるんですね」
「もちろんです。ご自分で交換なさいますか？」
「はい、いま手にとってしげしげと見てるところです」
「では入荷したらお電話差し上げます」

　T-ZONEって比較的信頼性の高いショップではなかったのか？新宿店だけの問題か、それともたまたま質の悪い店員にあたっただけか？これじゃ意味のない５年保証のソフマップと同じじゃないか。

NEmacs / 1995.12.04

To: Satomi Nakano
Subject: THANK YOU
Date: Wed, 06 Dec 95 16:47:20 +0900
From: Takeshi Yoneki

こんばんはＣＯＣＯ姉ちゃん。
コードヲリャー届きました。うれしいうれしいうれしいな。
予定金額よりだいぶんオーバーしたんじゃなかろうか。
でもうれしいうれしいうれしいな。
まったく、お姉ちゃんにこんないいもの買って貰ってしあわせモノだよウチ
のIIcx改は。ちゃんとお礼をいうんだよ。

Takeshi Yoneki

　さて、Linuxだ。
　.emacsにcannaのロードを記述するとFEPとしてでなく、Muleがきちんとcannaを認識してくれた。仕事ではNEmacs+Egg+Wnnを使ってるのだが、とくに使いやすいとも思っていないのでcannaを試してみることにした。
　X-Windowのウインドウマネージャであるfvwmのデフォルトの設定はあまりにもダサいので、なんとかNeXT風に渋くしようとしてしまったのは、やはりNeXTアイコンがデフォルトでインストールされてたからであろう。ハマったハマった。ウインドウタイトルが黒いのはなんともお葬式風でいただけないが、他の色ではNeXT的雰囲気がでない。ううん、どうしようなぁ。
　２ボタンによる３ボタンのエミュレーションは動きのぎこちないところが多々あるとわかったので、一応予定していたロジテックの３ボタンマウスを買ってきた。これでコピー＆ペーストが自然にできる。それにしてもなんともでかいマウスだ。普段使ってるのはマックの旧式マウスと（仕事で）ＭＳの旧式のマウスだからなぁ。
　モデムボードが活きてるかどうかのテストをまだしていなかったので、WTERMを使ってATコマンドを打ってみた。AT ReturnでOKが返ってくるまで10数秒かかった。あれぇ、おかしい。なにかがおかしい。ぜったいどこかがぶつかってる。
　PC-DIRECTから送られてきたデフォルトの状態ではモデムは明らかに使えなかった。マニュアルとニラメッコしながらIRQとI/Oアドレスを試行錯誤した。どうもマニュアルの記述に合点のいかないところがある。
　内蔵シリアルのひとつはマウスにとられているので、もう一つのシリアルとモデムを両立させたいと思っていたのだが、どうにも動かないのでシリアルをDisableにしてモデムだけ有効になるようBIOSを設定した。ちゃんとモデムが動き出した。
　ＣＯＣＯ姉ちゃんに話すと、もうひとつのシリアルを他のCOMナンバーにできないの？といわれた。おお、そうだそうだ。なかなかいいヒントだ。マウスをCOM1、モデムをCOM2、シリアルをCOM4にして、シリアルとモデムを同時に使わなければ動くとわかった。さんきゅＣＯＣＯ姉ちゃん。最近はAT互換機ばかりにかまけてて御免ねぇ。
　JFのドキュメントから、LinuxでRTするにはstk（Emacsマクロ）が使えるとわかったが、stkはkermit（通信ソフト）を必要とする。kermitがどのCD-ROMにもない。Nifty-ServeのFUNIXには、非常に古いckermitはあるのだが、BSD指定でコンパイルしても通らない。I/O Controlでエラーになるのだ。絶対Linuxで動いているkermitはあるはずなのだが、どうにもお手上げ状態になってしまった。「Linux入門」によるとkermitは配布条件が特殊なためCD-ROMには添付していないが、簡単に手に入るであろうとある。その簡単な方法ってのはなにかい？コロンビア大学までftpすることかい。まいったね。
　「Linux入門」を良く読むと、xc（通信ソフト）でもEmacsに組み込んで使えるとある。おおお、xcならFUNIXにあるぞ。早速ダウンロードだ。
　xcのコンパイルは何気なく終ったのだが、どうしても起動してくれない。モデムポートがオープンできないとおっしゃる。rootでもuserでも同じだ。はあ、期待したのに。
　「Linux入門」のCD-ROMをブラウズしていたらotherディレクトリでxcを発見した。ああ？これはバージョンが違うんじゃなかろうか。試しにuserで起動したら同じようにポートがオープンできないときた。次にrootで起動したら、見事にコマンド画面に進んだ。やったぁ。FUNIXからダウンしたのは1991年のバージョン。CD-ROMに収録されていたのは1994年のバージョンだ。
　userでもモデムポートを使えるように/devの下をchemod 666 *した。666ってのは誰でも読み書き自由って意味だ。今まではフロッピーにmdirやmwriteするにもsuしてたから、こんなことは早くすべきだったと思った。UNIXとしては邪道だって？ふぅん、どうみてもこれはパソコンだぜ。
　Muleにstkを組み込むと一応動き出すが、どうやら一部の関数が解釈できないときたもんだ。へいへい。あとは何をしましょうか。
　MuleでダメならNEmacsだということで、NEmacsのインストールだ。最初canna指定しなかったせいでcanna非対応のNEmacsが入ってしまった。もう一度入れ直し、.emacsの設定をきちんとするとNemacsが動くようになった。ほう、やはりMuleよりは軽いエディタだね。悪くない悪くない。
　stkを使うとちゃんとxcを呼び出してくれた。chatモードにもちゃんと行ける。やった。組み込み成功。ATDT117もちゃんと動く。あとは通信設定をするだけだ。
　ちゃんとNiftyでチャットができるようになった。めでたしめでたしなのだが、問題も残っている。半角カナが化けるのだ。NiftyユーザはUNIXと縁のない人が会員に多いので半角カナが読めないことにはかなり苦労させられることになる。まいったな。あと、リダイアルができるようにマクロを組まないといけない。LISPの経験なんてないぞぉ。

Nemacs / 1995.12.10

　AT互換機とマック向けにLANボードを買って来た。AT互換機はLONGSHINEのNE2000互換ISA Busボード、マックには正体不明のNuBusボード。互換機向けはツートップで６千円、マック向けは秋葉エレパで１万円であった。
　AT互換機はIRQの設定にやはり迷った。いろいろ試してみて、空いてたIRQ 11を使うことにした。Windows95はIRQ12が何かに使われていると警告する。何がIRQ12を使っているか私にもわからない。今度SCSIボード入れるときに本格的に調べないとなぁ。
　最初は確実な環境でチェックしようとWindows NT 3.51のβ版で始めた。どうもうんともすんともいわない。pingでマックから返事がないのだ。Windows95でやってみると、何かのはずみでpingに返事が返って来た。マック側のコンパネでネットワークをEtherTalkにしないとダメらしいと気づいたのはかなり時間が経ってからだ。Windows NT 3.51β版ではいまだにpingは返って来ない。制約でもはいってるんだろうか。
　Linuxはカーネルの再構築が必要だろうなと、起動してみたら、メッセージの中にNE2000という文字があった。すでにLANボードは認識されていた。ラッキー！
　マックへのpingに問題はない。マック側の設定によってpingが返って来ないときがあるが、やはりコンパネのネットワークの設定による。LocalTalkとの共存はデフォルトでは存在しないようだ。ううむ。
　マックでFetchを使ってアクセスすると、ちゃんとファイルの一覧がでてきた。NCSA Telnetでちゃんとログインもできる。つながった。
　マックでNCSA TelnetにてLinuxにログインして、NEmacsとxcとSTKを使って互換機のモデムボードでパソコン通信するなんていうこともできてしまった。
　パシフィック・ハイテックから送られて来た「Net-Mac」附属のCD-ROMをFTPをキーにして検索をかけた。そこでFTP'dというもしやというものを発見した。予想通りマック上のFTP demonであった。これでLinuxやWindows95からマックに対してFTPできる。

NEmacs / 1995.12.11

　どうもマック側が最初の起動時にEtherNetを認識しないことが多いようだ、リセットすると認識するからまあいいかとは思うがなんとも気になる。何か不安定要素があるんだろうな。メーカー名も不明なボードだからしょうがないかな。
　マックにpingってのはないのかな。基本的なTCP/IPツールだと思うんだが、発見できない。あらためて作るってほどのものでもないしどうしよう。Linuxのソースがあったら移植してみるのも手だな。ＣＯＣＯ姉ちゃんからの誕生日プレゼントのCodeWarriorでね。
　Windows NT 3.51βでマックにpingが飛ばなかったのは、まだEtherボードを入れてなかったときに疑似的にネットワーク環境をNTに認識させるためにLoopbackアダプタをインストールしていたのが原因だった。それをアンインストールすると一気に認識した。Fetchからも問題なく見える。
　EtherNetが使えるようになると、あえてAT互換機にSCSIボードを入れる意義がなくなってしまった。バックアップはFTPを使ってマックのMOに入れれば問題ない。マック用のMOドライブがAT互換機でちゃんと動作するかどうかの問題もある。妙に安い値段で売ってるQIC-80テープドライブが気になるのはなんでだろうな。なんとなく欲しいと思ってしまう私はなに？　メディアの値段によっては衝動買いするかも。

NEmacs / 1995.12.12

注：
　その後マックのネットワーク設定をLocalTalk側にしたままでTCP/IP接続ができると判明。EtherTalkとTCP/IPは関係なかった。マック側のEtherボードが不安定だという状況は変わっていない。

　関係者各位

　最近ワープロやエディタを使っていて「どうも使いにくいな」と思うことがあります。それはスクロールバーの矢印をクリックして画面をスクロールさせたときのソフトの動作が原因だとわかりました。最近のワープロやエディタはスクロール動作が一様でないものが多くなっているようです。これが使いにくい原因です。
　スクロールバーの矢印をクリックしたときの動作はだいたい以下のようになります。

１．１行ずつスクロールする。
２．最初１行ずつスクロールするが、何行目かに複数行スクロールするようになる。
３．最初から複数行スクロールする。

　使いにくいのは２．の実装をされたワープロやエディタです。大量の移動を行いたいときはスクロールバーのサムのないところをクリックすればいいのですから、この機能の有効性に非常に疑問を感じます。もうちょっと下を見たくてクリックするにもかかわらずどんどん行き過ぎてしまって、結局また戻るという行為を強制されてしまいます。はたしてこれは使いやすい機能でしょうか。

　なぜこのような機能が実装されるようになったかの原因を考えると、パソコン雑誌でのワープロやエディタのスクロールスピード比較があります。大きな文書ファイルを開いて、スクロールバーの矢印をクリックしつづけ、一番下のテキストが表示されるまでの時間を計測する比較テストです。このテストで好成績を取るための実装が２．です。
　使いやすさを犠牲にしてまで雑誌での性能比較での結果を重要視しているということになります。これは使いやすいソフトが欲しいという立場から見たら明らかに弊害です。パソコン雑誌編集者の顔色を伺ったソフト開発の端的な問題点でしょう。
　スクロールスピード比較と性能には何の相関関係もありません。非常に重いワープロのMacWORDやMS-WORDがスクロールスピード比較で必ず好成績を納めるのは、１．で実装されたものと２．で実装されたものという、まったく違う機能を比較しているからにすぎません。別の機能を何の説明もなく比較して何かを表現することは無意味です。いや、無意味どころか大きな弊害があります。
　雑誌での評価が製品売り上げに大きく影響を与える業界ですから、雑誌編集者やそこでのライターの意識が低いままでは良い製品が現れることはないでしょう。

　そういったわけで、無意味なスクロールスピード比較記事に対して抗議します。スクロールスピード比較記事に何らかの意義があるというならばそれをきちんと示してください。でなければこれはその記事を書いた人物の無能ぶりを示しているとみなします。「定量的に性能を比較する良い方法が他にない」というのは理由になりません。なぜならスクロールスピード比較は性能を示せないのですから。

1995.12.21

　LinuxでRTをしようとしたばあい、結局のところ選択肢にはNEmacs（エディタ）+Xc（通信ソフト）+STK（エディタで通信ソフトを使うマクロ）しかないというわけで何度か使ってみた。使い勝手は結局はEmacsなのでまあ好きずきではあろうが、最大の問題は半角カナが表示できないことだ。
　半角カナが入力できないことは問題にならない。そもそも私は半角カナを極力使わないように文章を書く癖をつけている。しかし読めないというのはパソコン通信においては致命傷である。私が書かなくとも皆が頻繁に半角カナを使うからである。
　RTでは「今Linuxなんで半角カナはご勘弁を」と、半角カナを使わないように頼んでいる。それでも顔文字を日本語入力FEPに登録してたりするので(-_-メ)なんてのが化けたりする。使ってる本人は半角カナを使っていると意識してないのだ。
　会議室はもうどうあがいてもNEmacs+Xc+STKでは読めない。十数本に１本は必ず半角カナを使った文章がある。また、Nifty Serveではときどきログイン後の最初のメッセージに半角カナが使われていることがある。これはかなり迷惑。
　問題はXcの日本語対応にあるのであろうと考え、Kermitを使うべく何度かFTPをトライしたがどうもつながらない。やっぱ米国は遠いわ。
　ところがXcを直接使ってアクセスしてみたら半角カナが表示できた。あれぇ？　もしかしたらNEmacsが半角カナを通さないだけ？　そういえばNEWSでも思い当たるフシがある。たしか端末では半角カナが読めたはずだ。NEmacsの問題だったんだ。やられた。
　半角カナを含んだ文書をMuleで見るときちんと表示される。やはりそうか。半角カナはMuleじゃないとEmacsでは使えないんだ。というわけで、問題は「STKをMuleで使えるように改造する」という点にしぼられた。STKはEmacsマクロで、すなわちE-Lispで書かれている。
　Muleに「そんなもん知らんぞ」と怒られる関数はattribute-off-regionとattribute-on-regionである。それを含んだ処理を削除していったが、どうも知らない言語ではどうにもやりにくい。何度か失敗した後で「ダミー関数を作るか」となった。

    (defun attribute-off-region(arg1 arg2 arg3))
    (defun attribute-on-region(arg1 arg2 arg3))

の２行を加えたら快調に動き出した。この２つ以外はちゃんと互換性が保たれているようだ。アクセスして半角カナを表示させると問題なく通った。ラッキー！　これで本格的にLinuxで通信ができる。

1996.01.11

　IDGコミュニケーションズの「Windows World」９６年１月号の特集「さようならMacintosh」が物議をかもしていているのはご承知の通り。一方、マックワールドコミュニケーションズジャパンの「Mac World」９６年２月号に「こんな記事を書く雑誌と同じ出版社のマック雑誌なんて買えない」と抗議がきたとあり、読者の不信を誤解だとして説得を試みている。たしかに編集部はお互いに完全に別物で経営（会社組織）も別かもしれないが、同じIDG傘下の雑誌だという大前提のもとではあまり説得力がない。
　「Windows World」９６年２月号では明確な事実誤認の訂正に１ページ、読者投稿に２ページ、（DOS/Vの神様）西川氏の連載での苦言１ページと案外扱いは小さい。また、編集部の姿勢がまったく説明されていない。
　読者投稿２ページを半分が是、半分が非として掲載している。同じ量だけ是非が載っているのだが、これは編集側の情報操作であろう。Windows World編集部は自分達が何をしてしまったかに気付いていないのかもしれない。
　Windows World編集部は自分たちの無知と無責任をさらけ出してしまった。Expoのタイミングとぶつかって編集部にあまり人がいなかった時期だったのではないかと西川氏が指摘していたが、たとえそうだとしてもあまりに無責任な編集である。匿名記事の責任は編集部にある、すなわち責任をとる人物がいない。編集長を責めてもあまり意味がない（それでも責めるべきであることは勿論のこと）。
　あのような幼稚な文章を書きたがる人物はこの業界には少なからずいる。しかしそれが幼稚だと判断できる読者ばかりではない。あまつさえ支持しようとする読者さえいる。この特集記事を支持する層はここに書かれた何が問題かを判断できない人々だといえる。西川氏も「もうそろそろ読者がマニアばかりでないことに気付くべきだ」と苦言で書いている。
　件の匿名記事は具体的事例に一切基づいていない単なる煽動であり、それを掲載した編集者の正気を疑うべきものといえる。正直読んで吐き気がした。こんな幼稚な文章を読まされてしまったことに腹が立った。あまりの情けなさに茫然としてしまった。
　雑誌が業界に与えるインパクトは非常に大きいが、編集現場ではそれを意識することは少ないのかもしれない。しかし例えば、現実にワープロソフトが使いにくくなってしまったのは無能な編集者やライターによってくり返し大々的に書かれた機能一覧比較が一因であることは間違いない。残念なことにそういった自覚はないと思える。
　あの「The BASIC」でさえ、あそこまでひどい記事はなかった。結局私にできることはIDGコミュニケーションズの製品を買わないことだけである。そもそも今まで買ったことがないので何の影響もないであろうが。
　たぶんこの問題はこのまま他のパソコン雑誌に取り上げられることもなく消滅してしまうであろう。パソコン雑誌はジャーナリズムではなく商品カタログなんだよね。

　それにしても匿名記事を書いたライターはマック版一太郎を使ったことがあるのかなぁ。多分使ってたらああいう書き方はしてないだろうな。

1996.01.12

　相変わらずのLinuxネタではある。
　NEmacs+STK+Xcでの通信は半角カナが表示できないということで結構致命的だったのだが、STKをちょっと変更することでMuleで通信できるようになった。XcではなくNEmacsが半角カナを通さなかったのであった。Muleはちゃんと半角カナが通る。EUCを使っても半角カナが通る。なんでNEmacsは半角カナを通さないようにしてたんだろう。おかげでUNIXでは半角カナは御法度にまでなってしまっている。影響力の強いソフトだ。
　Cannaの馬鹿さ加減にみんな憤りしてるんじゃないかと思うんだが、辞書サイズが700KByteだからしょうがないといえばしょうがない。私が驚いたのは「姪」がでなかったことだ。「甥」はでるのにである。私には姪はいるが、甥はいない。男尊女卑もはなはだしい。さすがは日電（関係ないね）。
　で、試しにVJE Deltaで使ってたユーザ辞書をCannaに持ち込んだ。単純なjgawkスクリプトで変換することができた。Cannaのマニュアルをきちんと見れない（TeXスクリプトのコンパイルがうまくいかない）ため、制御命令をひたすら無視しながら.texファイルを直接読んでの作業であった。もうTeXなんて恐くない。
　ユーザ辞書に直接ペーストしたのだが、きちんと動作するようになった。今では一発で「仏説摩訶般若波羅蜜多心経」とか「毘盧遮那仏」なんてのがでる。
　こうなるとやはり慾がでるもので、VJE Deltaのメイン辞書の変換をして使えないかと考えたわけだ。で、実はマックでのメイン辞書のテキスト化に一番苦労した。どうにも途中でコケるのだ。もしやと思いインストールフロッピーから新品の辞書をもってきたら、問題なく変換できた。どうも普段は壊れた辞書を使っていたらしい。
　さすがに4MByteをこえるテキストの変換にマックのjgawkは使えないと思ったので（きちんと動くとしても、スピードが問題）、Linuxに持ってきてからgawkを使った。さすがにちょっと（２分くらいか？）かかったが、無事変換した。明らかにスクリプトを書く方が時間がかかった。
　できた辞書テキストvjedwm.tを/usr/local/canna/lib/dic/canna/にもっていってchmodしてdict.dirに加えて、.cannaを設定してから再起動すると、きちんと認識した。Emacsの起動に異常に時間がかかるようになったがきちんと「服部嵐雪」なんてのも変換する。らっきー。
　でもまぁやはりEmacsの起動に時間がかかりすぎるので、ものは試しとmkbindicを使って辞書をテキスト形式からバイナリ形式に変換した。もう一回dict.dirを書き直して再起動すると、Emacsの起動が格段に速い。きちんと「海部俊樹」も「海江田万里」も変換できる。大ラッキー！　3MByte辞書の威力はでかい。

1996.01.20

　Plusのモニターのうなりが絶えられなくなってきた。古くなったモニタ特有のあのキーンというやつだ。もはや寿命であろうか。あとで秋葉のジャンクを漁ろうとは思うが、さすがにモニタの交換は非常に危険だとは思う。このままオブジェにするのも悪くはないが、やっぱ動いてこそパソコン。なんとか復帰させたいものだ。
　そこで当面というかやっとというか、Classic IIをPlusの代用品として本格的に使おうかと考えている。これもいまさらではある。Classic IIユーザはとっくにこのマシンを見捨てている時代になってるというのに、ようやくサブマシンとして使おうってんだから。ま、いままでPlusが完全に現役だったから出番がなかったんだよね。Plusが故障してたときに代用として買ったにもかかわらず、Plusを修理して結局はほとんど使わずじまい。ただあるだけのマシンだったなぁ。これから使い倒してあげましょう。電池も交換したし、ディスクもおさがりだけど100MByteあるし。
　Classic IIでMaster Tracks Pro 4.5を普通に使ったのではオリジナルドライバのバグで音飛びが激しくてどうにもならない。そのせいでPlusからClassic IIへなかなか移行できなかったのだ。
　漢字Talk 7.1を入れて、Master Tracks Pro 6.0を使ってみたが、はっきりいって忍耐の限界をこえている。英語System 7.1でも同様。Master Tracks Pro 6.0はSystem 7.0以降じゃないとオリジナルMIDIドライバを使ってくれないのだ。最悪の仕様になっちまったもんだ。MIDI Managerが重くて使えないってのはマックのシーケンサーではあたりまえなハナシ。軽いシステムでこそオリジナルドライバを使いたいのに米Passportは何を考えてるのやら。
　結局System 6.0.7.1でMaster Tracks Pro 4.5をMIDI Managerで使うのが最もレスポンスがいいと判った。ふう、結局MIDI Managerを使うことになるのね。
　Master Tracks Pro 6.0のマニュアルには「もしSystem 6.0.7で使いたかったらMIDI ManagerかOMSを使ってくれ」と書いてある。OMSとは米Opcode社のMIDIドライバーで、MIDI Managerに代わって標準ドライバーになるとかいうやつだ。ところが、System 6.0.7.1にOMSをインストールしてもMaster Tracks Pro 6.0は認識してくれない。どうしてこうなのかは全くわからない。どのみちMIDI Managerを使わなければならないのなら軽い古いソフトのほうが良いのでMaster Tracks Pro 4.5＋MIDI Managerという組み合わせになるのであった。
　IIcx改をシーケンサとして使うのが最も正しいんだろうけど、部屋のレイアウトを改造しなくてはならないから面倒面倒。最低限キーボードスタンドが必須だな（持ってないってのは論外っぽいが）。

1996.01.26

　CodeWarrior 8が届いたので、途中で中断していた褌・エディットのTHINKからCodeWarriorへの移行を再開した。どうにもリストクラスCListがクラスとして認識されなかったのだ。この問題はUniversal Interfaceを検索して解決した。すでにcList（カラーリスト？）というConstが存在したからだ。Pascalは大文字と小文字を区別しない。今まではパレットマネージャなんてInterfaceはインクルードしてなかったから問題がなかったのであった。ぶつかってた名前は他にもあった。気を付けねばならない。CListはCListBaseに変更した。CodeWarriorの一括置換は実に高速で便利だ。
　古いToolBox関数名を機械的にUniversal Interfaceでの新しい名前に変更していって、最終的にリンクまで終わって「やれやれ」とできた褌・エディットを起動するとバスエラーでコケた。あららら。
　アプリメモリをデフォルトの300KByte程しか与えてないことに気付き、本来のサイズに変更するとすんなり起動した。特に問題もなさそうだ。実行モジュールはTHINKよりもいくらか大きくなっている。でも動作は全く同じ。移行は終了。
　今後はCodeWarriorで手を加えることになるだろう。

　CodeWarriorに移行すれば単純にPowerPC対応できるのではないかと思っていたが、PowerPC向けPascalコンパイラはIntegerを32Bitで扱うとある。16Bitを表現するときは何を使うのだろうか？　PPC化の可能性はこれから探ることになる。まあ、まだウチにはPPCマシンがないのだが。

　C++で進めているNasuTenプロジェクトの方もリストクラスの名前をCListからCListBaseに変更しておいた。やっぱり気持ち悪いからね。

1996.02.22

　注：
　「PowerPC向けPascalコンパイラはIntegerを32Bitで扱う」というのはCodeWarriorユーザースガイドU-12-21の「注意：」にある「PowerPC Pascalコンパイラもint型は常に４バイト整数です」という記述をそのまま鵜呑みにしただけのことである。
　最近、そもそもこの記述が表現しようとしていることが何か別のことなんじゃないかと思っている。２バイト整数を表現できないとToolBoxが全く使えなくなるからだ。ウチにPowerPCマシンもコンパイラもないため全く確認できないのがもどかしい。

　２月のエキスポ前にCD-ROMパラダイスから買ってきてたDOOM IIとLaser 5 Linux + JE4をやっとAT互換機にインストールすることができた。せっかく買ってきたのに、實篤にかまけててまる１ヶ月抛っておいてしまった。
　DOOMは、まあ、動いてあたりまえなので書くことはないな。なぜか知らないけど、ウチの環境では音楽と効果音を同時に鳴らすとコケるのだ（動いてないじゃん）。DOOM IIでの問題でなく付録のDOOM Iだけなので、まあこんなもんだろうとあきらめている。効果音は重要だけど音楽は邪魔なんでどうでもいい。
　Laser 5 LinuxはJE4（日本語４版）であり、ELF（i386共通バイナリ形式）化されたLinuxだ。これはnetatalk（un*xをマックのファイルサーバにするプログラム）も使えるバージョンのはずだ。
　Linuxのユーザ環境をまるごとバックアップ（ユーザ単位にtarしてgzip）し、Cannaの辞書や念のため/etcもまるごとバックアップしてからインストールを始めた。
　前回の苦労を活かして、まずQシリーズから当たりをつけた、しかしどうにも合致するカーネルがない。何度か色々なカーネルを入れてみたが起動すらできないものがほとんどだった。何かがおかしい。
　なにげなく基本的なツールの入っているAシリーズの一覧を見ると（一覧からインストールできるようになった）カーネルが２つ用意されている。一般的にはこのどちらかで十分のはずだというカーネルだ。説明を読むと確かに片方は私の求めていたカーネルであった。前回はnewというディレクトリやQシリーズから探さなくてはならなかったATAPI CD-ROM向けカーネルが、今回は一気に最もメジャーなカーネルになっていた。もはやLinuxはSCSIが必須ではない。
　結局は下手に自分で探さずに何も考えずにインストールすれば動くカーネルが入っていたはずだと気付いた。前回苦労したのがあだになってしまったのであった。
　動くカーネルが入ったらもうこっちのもの。その後の作業は寝ててもできる（インストーラが自動的に展開するから本当に寝てていいんだが）。一通り必要なアプリを全部入れたらX-Windowの設定だ。これも慣れたもんだ。そしてユーザ環境を復元し、Xcを入れ直したら全く同じ環境ができた。案外単純なのね。
　一つだけ変化している部分があった。X-Window環境で、BSキーがDELにされていないのだ。MuleでBSを押すとヘルプが出てくる。これでは使いにくい。MuleのマクロでBSをDEL相当にした。ところがftpでやはりBSが使えない。結局はxmodemapでBSをDEL相当にした。本当はktermだけに有効にすべきなんだろうな。
　なんでもNetscapeがBSをDELにしてるとダメなんだそうで、「デフォルトでBSをDELにする」という「親切」をやめたとか。いやはや迷惑なソフトだ。
　Linux向けDOOMが/usr/gameにインストールされるが、起動して数秒デモをするとコケてしまう。キー入力も効いてるんだか効いてないんだかよくわからない。画面は止まったままだ。しかたがないのでマックからtelnetで入ってsuしてrebootするはめになる。実際にはDOS版のDOOMをするから問題はないんだけど、なんとも口惜しい。

1996.03.19

　１９９６年２月初頭から約１ヶ月半かけてやってきた「茄子天プロジェクト」も最初のβリリースが近づいてきた。ブラウザの実行モジュールの名前は「Saneatsu Lite」となる予定だ。アイコンからわかるように「實篤」である。茄子なんだけど茄子じゃないという意味を込めてある。また、やはり「仲良きことは．．．」は通信ソフトやログカットソフトとの連携プレーを前提とするログブラウザの動作理念ともいえる。

　「實篤」はC++を用いた防衛的プログラミングに徹している。既存の茄子互換ブラウザに比べて格段の安定性を持っている。普通にＣで書いたのではやはりどうしてもメモリ破壊問題を完全になくすのは難しい。
　「實篤」を作るにあたっての基本方針は以下の通り。
　　１．全ての機能をC++のクラスにする。
　　２．整数を４バイトにし、PPCへの移植を容易にする。
　　３．アプリケーションヒープのことはあまり考えずに作る。
　　４．既存のクラスライブラリを使わない。
　１と２は現在では常識と思われる。プログラマには３は乱暴に映るかもしれないが、アプリケーションの性格上ヒープが足らなくても努力するというロジックは、その実装の労力が無駄になるとの判断だ。これはどのタイミングでも必要なヒープがあまり変動しないアプリなので問題はない。ほとんどのメモリブロックは固定ブロックで（newで）獲得している。どの程度使うとヒープの分断が致命的になるかわからないが、さほど心配することでもない。ヒープがなくなったら終わるだけだ。コケるわけではない。実際はヒープがなくなって終わるというのは現段階では見たことがない。20MByteメモリーが貧乏の時代、これはもういいだろう。
　４の既存のクラスライブラリを何故使わなかったかという理由は、さほど積極的なものではない。ただ単にクラスの勉強が嫌だったのと、他人の作ったクラスのデバッグに時間を掛けたくなかったからだ。「實篤」作成と同時にToolboxをラッピングしたTen Tool Class Libraryをも作成することになった。「實篤」ソース１万２千行のうち半分はクラスライブラリである。もちろん「實篤」で使わないToolboxのクラスは書いてない。
　既存のクラスライブラリに依存しないということで、「實篤」はCodeWarriorとSymantec C++の両方でコンパイルできる。ただし、Universal HeaderはCodeWarrior付属を使わないといけないかもしれない。私はSymantec C++でのコンパイルにはCodeWarrior付属のUniversal Headerを使っている。なぜなら、Symantec C++ 6.0から地道にネットワークにアップされたアップデータのみで7.0.4(8.0)にしているからだ。Symantec C++向けのUniversal Headerを持っていないのである。Symantecのクラスライブラリも持っていない（いらないけど）。

　「實篤」を実装するにあたって、小倉さんの「茄子」ソースを参照した。これは主に茄子形式ファイルのリソースの使い方の確認のためである。「實篤」と「茄子」両方のソースを読む機会があればわかるが、全く似てない。だがしかし、クリーン設計とはいえない。ごく一部流用したロジックもある。
　「Saneatsu Lite」は私が使う機能を実装したのみで、これ以上の拡張は私にとって必然性は全くない。もし拡張するとしたら、それはシェアウエアとなるであろう。

　小倉さんの茄子ソースを読んでの感想を以下にノベルはNetWare。
　やたらあちこちで、再帰的関数呼出しが使われている。これは絶対素人には読めないとの確信を得た。小倉さんはLisperであろうか？
　ただ、Toolboxの初期化のタイミングでスタックのことは何も触れていない。デフォルトサイズのスタックで再帰的関数呼出しを多用したらどうなるであろう。マックはスタックオーバーフローを検知しないマシンなので、もしかしたらログのサイズやメッセージリンクの構成によってはかなりヤバいことになっている可能性が高い。
　もちろんLisperでない私は、ほとんどの処理をループで書いている（ちょっとだけ再帰的関数呼出しはあるけどね）。
　小倉さん本人は「汚いソースだ」と強く主張しているが、思ったほど汚くはない。確かにフラグのON/OFFに即値を使ったりしている部分は多い。私は仕事柄、汚いソースはうんざりするほど見てきたが、妙ちくりんなロジックや怪しげな記述がないという意味では「読める」ソースであった。関数や変数のネーミングも妥当だ。世の中、ソースだけでは何をしたいのか解読できないものも多い。

1996.03.22

　マックエキスポで買ったPascalWriteが、EvenBetterBusErrorのNULLハンドルアサインチェックにひっかかる件を有限会社パスカルにレポートしていたのだが、いきなりE-mailで800KByteのBinHexファイルが送られてきた。1.0.2mというテストバージョンだそうで、私の環境でチェックして欲しいとのことだ。あたしゃテスタじゃないんですけど。
　EvenBetterBusErrorではもう問題はでなくなっている。はっきりいえば、非常に安定度が向上したと思われる。前がひどかったのであるが、今回は一気に高安定アプリになったようだ。これはいいや。
　NisusWriterで書いていた實篤・取扱説明書をPascalWriteへ持っていった。PascalWriteは最近では珍しくグラフィックデータを自分で作れないソフトなのだが、そんなのは他のグラフィックソフトで作ってペーストすればいいのだし、それが本来のマックの使い方なのでこういった姿勢は好きだ。ワープロのグラフィック機能って使いますか？　私は今回初めてNisusWriterのグラフィック機能を使ってたんだけど、結局それはやめることになった。
　なぜPascalWriteに持っていったかというと、SimpleTextのグラフィックつきデータを作れるからだ。NisusWriterで配布してもNisusWriterを持ってない人はグラフィックつきで読めないので迷っていたのだ。
　PascalWriteに対して要望を書き始めるときりがないので書かないが、こういうシンプルなワープロは大好きだ。昔のByWordを思い起こさせる。私が使ってたのはWritePalというByWordのOEM?だけどね。有限会社パスカルの社長さんはWriteNowのようなワープロが欲しかったそうだ。ByWordはWriteNowのようなワープロを実現したわけなので、結局ルック＆フィールは同じになる。
　ただ、インラインでの入力のスピードはNisusWriterに勝てない。文書が大きくなると入力は重くなる。しかし、全体的に軽めに作られていて、レスポンスは悪くない。こういう普通のシンプルなワープロが欲しかった。入力スピードさえ向上すれば、あとはたいして文句はない。MacWORDに比べれば断然速いけどね。
　なんでWritePalを使わないかというと、BusError INITという、EvenBetterBusErrorの前身のツールで、チェックにひかかったからだ。あまり安定して使えたわけでない。また、漢字Talk 7.1に対応していないのであった。
　箸にも棒にもつかないワープロが蔓延しているが、PascalWriteはきちんと修正してくれたってところが嬉しい。

　私のワープロ歴
１．WriteNow 英文ワープロをSweetJAMで使ってた。これが原点。
２．WaltzWord 最悪に不安定。これで１文書でさえ作れなかった。ひたすら爆弾。
３．WritePal 悪くないんだが、やっぱちょっと不安定。
４．MacWORD 最高に安定しているが、入力も最高に重い。速けりゃ文句はない。
５．WordPerfect カット＆ペーストにバグがあって使えなかった。論外。
６．NisusWriter 入力は軽いが、起動は重い。身勝手な動作もある。比較的安定。
７．PascalWrite 入力はちと重い。起動は速い。一番原点に近い。安定した。

　ほとんど毎年ワープロ買ってます。

　付録：仕事で使わざるを得なかったワープロ
１．一太郎 DOS版のver 3～4。ま、しょうがない、仕事だし。
２．OASYS30 専用機。論外。仕事でなけりゃ使ってない。
３．FM-OASYS FMR用OASYS。専用機よりはいいが、使いたいものではない。
４．DWord DOS版。98でOASYSの代用品として使ってた。専用機よりはまし。
５．MS-WORD Windows版のver 5は486-100MHzなら悪くないな。

　私はOASYSを憎んでます。

1996.03.31

　機能を取り去ることで軽くなったなんて、知ったかぶりして説明する人がでるかもしれないので明記します。少なくとも「茄子」のようなプログラムは機能の有無程度では処理の重さは「全く」変りません。最も関係するのはプログラムの持つデータ構造とそのハンドリング、すなわちアルゴリズムです。端的にいってアルゴリズムが変わると２桁のオーダで処理速度は変わります。茄子形式ファイルを扱うばあい「實篤」が本来の速度であり、たぶんこれ以上の速度はファイル構造（ＤＢ構造）的に不可能だと思います。
　また「實篤」は「茄子」を改造したプログラムなのではなく、茄子形式ファイルを読める全く独自の別プログラムです。
　機能の数とプログラムの速度はもちろん相関がありますが、プログラムの速度に無影響の機能も多いのです。ログカッターの「魔法のナイフ」はバージョンが上がるごとにどんどん重くなりましたが、あれは実際に処理ループに入る文字列判断処理の数に依存するので、高機能化（汎用化）そればするほど重くなります。それに対して例えば「實篤」には印刷機能がありませんが、これが次の未読発言への移動の速度に全く影響を与えないのは誰でも理解できるでしょう。
　最近の高機能アプリは機能の数を速度の低下の免罪符にしているフシがありますが、あれはちっとも本来の速度がでていないと断言できます。アルゴリズムを工夫することによる高速化のアプローチは高速なハードウエアが安くなった現在では鑑みられないことなのかもしれません。また、製品開発の権限を握っている人々（普通は開発者そのものではありません）にとってはメリットの見えにくいものなのでしょう。そう、解りにくいことなのかもしれません。機能が増えるってのは実に解りやすいですからね。
　高速化と高安定化への道は孤独です。報われることはありません。

1996.04.02

「ホーム」へ戻る
「読まなくてもいいよ１３」

OSTRACISM CO.
OSTRA / Takeshi Yoneki