OSTRACISM CO.
■ 日本語エディタ「褌・エディット」−作文職人−の開発日記 巻之十一

 なかなか喉が直らない。Windows Expoのタイミングでひいた喉風邪が長引いている。まいったな。早いとこ体調の復帰を願いたいもんだ。へええNiigata 9で行間を5程度にすると日本語の文章では使いやすいな。でも、これを固定するのもソースを見るときうざったいからな。しかも選択範囲が下に延びるのかぁ。格好悪いな。こんな実装してたのね。
 次に考えねばならないのはインライン入力の高速化かなぁ。機能付加はもうどうでもいいや。高速化と安定化を考えよう。

褌1.2.6 / 1995.07.14

 COCO姉ちゃんから、タブサイズ設定メニューが有効にならないと指摘された。あれぇ? しまった、メニュー構成の変更のときに混入したミスだ。困ったなぁ。どこか公に指摘されるまでシカトしよう。私も滅多に使わないメニューだから気付かなかったってわけだしね。

 山下さんがマックに移植したJGAwkとの連携プレーの実験を始める。JGAwkのマニュアルを見ると、ちゃんとAppleEventでの使い方が掲載されている。どうにでもなりそうな気配だ。
 こっちとしても、AppleEventでSendを実装するのは初めてなので、手始めにJGAwkを終了させるためにQuitをSendしてみる。これが全く動かない。なんでだろう。悩んだ末一旦睡眠をとり、再び挑戦する。
 褌・エディットのコピーを用意して、Creatorを'HunE'から'HunX'に変更し、QuitをSendしてみる。見事に'HunX'の褌・エディットは終了する。なんでだろうなぁ、何が違うんだろう。
 褌・エディットからのSendはうまくいってるはずなので、JGAwkが受け取れないと判断。もしかしたらLaunchApplicationで起動してやらないと、AppleEventを受け取ってくれないような実装なのかもしれない。そういったわけで、QuitをSendするのはやめて、本来させたい動作に近いAppleEventをSendすることにした。

 JGAwkをLaunchApplicationする。
 JGAwkのTargetデスクリプトを作る。
 コマンドライン相当のデータをファイルから読み込む。
 EvalutionのAppleEventをSendする。
 戻ってきたテキストを受け取る。
 QuitのAppleEventをSendする。

 一発でとはいかないが、比較的すんなりと動作してしまった。なあんだやっぱりLaunchApplicationするってところに鍵があったんだ。こうなったらもう、できないことはなくなった。やりたいように実装するだけだ。
 実験で気が付いたが、データの受け渡しを"outData"のようにファイルを使うように記述すると、なぜかTHINK PascalのLightsBugで動作させたときに、Quit AppleEventを受け取ってくれないようだ。一連の動作としてタイムアウト判定なんてしてるのだろうか? どうもJGAwkのQuit AppleEvent Handlerの実装に、何かが潜んでいるような気がするのだが。どう?

褌1.2.7 / 1995.07.24

 JGAwkスクリプトをフィルタとして活用するための実装はなんとかなったが、それをパイプで複数連結しようとしたばあい、既存のプラグインフィルタと共存させなくてはならない。JGAwkスクリプトとプラグインフィルタがユーザからシームレスに見えるようにするということだ。あと、プラグインインサートも同じように扱うようにすべきだ。
 ユーザからシームレスということは、プログラム内部でも上位レベルでシームレスにならなくてはやってられない。
 そこでこれらをトランスレータというクラスでオブジェクト化(ラッピング)することにした。パイプで有効に扱えるように動作の細分化をすることになる。プラグインフィルタはパイプで使うために既に細分化してあるが、コードの共有のために厳密に定義しなくてはならない。
 このオブジェクト化の設計が難渋した。モノ(例えばウインドウなど)をオブジェクトとして扱うのではなく、機能をオブジェクトとして扱うのはクラスの設計として正しいのであろうか?という疑問がついてまわった。
 とはいえ目的はパイプの実装を楽にする点にある。最終的にトランスレータという名前のテキスト変換機械という「モノ」を想定することにした。これはモノだこれはモノだこれはモノだこれはハードにモノなんだぁ。
 そんなわけで、今までPascalのオブジェクト機能は避けてやってきたが、徐々に導入することにして、マニュアルをチェックしてみた。あれぇ?コンストラクタやデストラクタがない。あれれ?スタックベースのインスタンスが書けない。あ〜れ〜?ハンドルベースのクラス定義ができない。まいったなぁ、C++の文法と全然違う。でもまあ、継承があるだけマシかぁ。
 方針として一時的なインスタンスを除いて、動的なメモリハンドリングが必要な大きなデータ構造はオブジェクト化しないことにした。また、当面は気になる部分だけのオブジェクト化になるであろう。最終的に現在ハンドルで持っているToolBoxのTextEditに相当する部分のオブジェクト化までできたらなぁとも思うが、その前にC++へ移植すべきかもしれない。
 認識できるプラグインの最大数は各系列単位に16までである。これは少ないんじゃないかと思っているが、実際に私以外の人が書いたプラグインはほとんどないので、実用上問題は表面化していない。これはただ単に面倒だったから配列で情報を保持していたための制約で、こんなのはとっぱらった方が身のためである。そこで、プラグイン情報をリストで持つようにすることに決めた。でも、各トランスレータ毎にリストを実装したんじゃ手間ばかり増えてバグが潰れなくなる。ここはやっぱりクラス化して継承しましょ。もともと配列でグローバルに持ってたくらいのデータ構造だから、動的である必要もないしね。
 オブジェクト指向の入門書では相変わらず動物のクラスで説明をしているのだろうか。プログラミングの説明をするんだから、リストクラスの実装と効用を説明すればCからの移行プログラマは一発で理解すると思うのだがどうだろう。
 まずルートのクラスであるCListとCListItemを準備。CListItemはメソッドは必要ないのだが、どうやらメソッドなしのクラスを定義できないらしい。一応初期化のメソッドを用意した。Newされるとゼロクリアされるからいらないんだけどね。CListItemのメンバ変数はnext:CListItemのみ。THINK Pascalのクラスはポインタだから、特にはポインタとして書かなくても良い。
 CListのメンバ変数はtop:CListItemとcount:integerのみ。メソッドはAppend、GetNth、GetCountを用意。動的に使う予定はないので挿入やら削除はなし。必要になったら足せばいい。そこらへんが精神的に楽だ。
 いうまでもないが、CListクラスはCListItemクラスのリストを構成する。
 さらに、全トランスレータに共通のデータfName:Str31を加えたCFileNameListItemをCListItemから派生。GetName、GetFName、SetFNameメソッドを加える。
 また、CFileNameListItemを扱うためのCFileNameListクラスをCListから派生。GetByName、GetByMenuItemメソッドを加える。これでメニューで選択されたアイテムから目的の情報を引っ張ることができる。またパイプ(実体はSTR#)の名前だけからも持ってこれる。
 プラグイン系の情報の構造も含んだクラスも派生。JGAwkスクリプトの情報はファイル名以外は必要ないのでCFileNameListItemをそのまま使う。
 結局やってみて、ファイル情報のオブジェクトとトランスレータのオブジェクトの分化が明確になった。前よりはある程度見通しが良くなったのではないかと思う。あとは両クラスの結合だ。あ、トランスレータオブジェクトにラッピングされるべきルーチンは書かなくちゃしょうがないな。

褌1.2.7 / 1995.08.14

 トランスレータオブジェクトと各アイテム情報オブジェクトの実装が済んだ。ラッピングをこえて、作り込みのほうに比重が高くなった。もはや既存の構造はあまり残ってない。CFileNameListItemクラスに仮想関数としてdoProcを用意した。プラグイン系とJGAwkスクリプト系を分け隔てなく使うためだ。当然どちらのサブクラス側にもdoProc関数をoverride指定で用意。実行時にメソッドが動的にバインドされるのはオブジェクト指向言語の醍醐味だよね。各サブクラスでのdoProcの中身は変換ルーチンの呼び出しそのものだ。プラグイン系はコードリソースへのジャンプで、JGAwkスクリプト系はApple Eventを使ったプロセス間通信。インターフェイスは共通でも、やってることに共通性は全くない。
 テストをしているうちに、どうも不安定だとわかり、メモリハンドル関連を調べていくと、スクラッププールに取っておいたメモリを勝手に破棄しているようだと気付いた。プラグインの動作が不安定だとのCOCO姉ちゃんの報告の原因である可能性が高い。これをちゃんとスクラッププール向けのルーチンで破棄すると安定度が高まったようだ(ようだとしかいえないんだよなぁ)。
 メモリハンドル関連の調査向けにNewHandleとDisposeHandleのタイミング全てをログに書くようにしたのだが、どうもDisposeHandleが呼ばれない。呼ばないはずがないのに呼ばれてない。発見して驚いたのだが、昔のDisposHandle(DisposeでなくDispos、トラップは全く同じ)で書かれている部分が多かったのである。これでは検索に引っ掛からないわけだ。昔のリンカの制限とはいえ、こんなんでバグがでちゃったら泣いちゃうよ。
 意地悪な試験をすると、オブジェクトの実行時エラーがいくつかでてきた。パイプで名前を持っていても、実際には既になくなっているスクリプトだったりするからだ。インスタンスがNilだったときにメソッドを呼んだら普通は落ちるな。
 メモリ内部の構成をグラフィックで見るツールを使って、パイプ動作をしていると、どうやらメモリリークが発生していると気付いた。メモリ内容はパイプスクリプトそのものだ。リソースのデタッチをしていたのに、それを破棄し忘れていたためだ。また、通常のプラグインのコードも、毎回解放するようにした。
 JGAwkの起動はまだ試験的な実装のままだった。でも、最終的にはJGAwkがどこに入っていようが起動できるようにしなくてはならない。いままでこんなことは実装したことがない。JGAwk Interfaceではできているから、できないはずはないんだ。さあInside Macintoshとにらめっこだ。
 クリエータとアプリの関係を確実に引っ張ってきているのはファインダだ。Finder Interfaceの項にDesktop DBへのアクセス方法が載っている。これだこれだ。GetAPPLなんていうズバリそのものがあった。でもDesktop DBをアクセスするにはボリュームを指定しなくてはならない。はてさて。
 ボリュームを特定する方法はInside Macintosh VIには発見できず、古典的File Managerの説明にあった。特には新しくなってないAPIだったのね。ともかくこの組み合わせでJGAwkを自動的に起動することに成功した。よかったよかった。ひと安心。
 あとはJGAwkが既に起動していたときにユーザに警告するようにしなくてはいけない。読むべきなのはInside Macintosh VIのProcess Managerあたりだろうな。

 LASER5から送られてきたCD-ROMに入ってたテキストエディタのBeachTextを見てみると、プラグインによるテキスト変換のフィルタがあった。ついにこの部分も褌・エディットの独擅場ではなくなった。こういった形態に価値があるという判断であろうか? それとも単純にユーザからの要望でもあったのかな? とはいえ、まさかJGAwkとの連係プレーを目論んでいるなんて思ってもみないだろうな。これを真似て実装するエディタが、はたして他に現れるであろうか?

褌1.2.7 / 1995.08.16

 テキストエディタを構造という観点から見たばあい、主に2種類に分かれます。それは改行指向かそうでないかの違いです。ユーザの観点から思い当たるのは、ASLEdit+などの行折り返しのないテキストエディタとTeachTextなどの行折り返しのあるテキストエディタでしょう。ただし、行を折り返しているテキストエディタが非改行指向かというと、そうではありません。マックには32KByte以上を扱える非改行指向のテキストエディタはほとんどありません。褌・エディットは32KByte以上を扱える数少ない非改行指向のマック用テキストエディタです。
 改行指向と非改行指向はプログラム内部でのテキストデータの扱いかたの違いを示すもので、一般的なユーザが見たばあいその違いは顕著には判明できません。また、通常はこの分類のしかたそのものを知らないでしょう。テキストエディタを作ってみないとわからないことだといえます。
 マックにはOSとしての機能を補佐するToolboxルーチンがあります。このなかにTextEdit Toolboxがあり、これを使うと比較的簡単にテキストエディタが作れます。TeachTextはそうやって作られています。ほとんどのNotePad系ユーティリティはTextEdit Toolboxを使っていると予測されます。また、案外多くのテキストエディタも使っています。32KByte制限のあるテキストエディタは確実にTextEdit Toolboxを使っています。この32KByte制限はTextEdit Toolboxの制約のひとつで、ユーザから見たばあい、最も重要なテキストエディタ分類の目安となります。
 TextEdit Toolboxを使って、行折り返しを行うようにしているテキストエディタは、作った本人が意識せずとも非改行指向になっています。なぜ、本人が意識していないなんて表現をするかといえば、テキストエディタの要であるテキストハンドリングを自力で実装していないからです。TextEdit Toolboxを使ったテキストエディタは、結局SimpleTextを最終形とするものでしかありません。TextEdit Toolboxは非改行指向で動作するように構成されています。
 YooEdit、Edit7、BeachTextなどは改行指向です。改行指向テキストエディタの特色は、いわゆる物理行でのみジャンプができるという点に現れます。それに対し褌・エディットは非改行指向で、いわゆる論理行でのみジャンプができます。Jeditもどうやら珍しく非改行指向らしいのですが徹底されているわけでもなさそうで、高速化のための様々な妥協があるように思われます。
 普通にテキストを扱うには改行指向の方が断然スピード的に有利になります。改行単位でテキストをリストで保持するという方法はテキスト内での移動に全く負荷がかかりません。ところが、褌・エディットは敢えてこの構造を採用しませんでした。なぜならば、明らかに開発目的に反するからです。
 褌・エディットはそもそも、ミニコミ誌作成のためのテキスト整形を目的として開発が始まりました。褌・エディットのプラグインフィルターはオマケなのではなく、むしろ褌・エディット本体のテキストエディタとしての機能がオマケなのです(ちといいすぎかな)。フィルターを使うための基盤として褌・エディットがあるのです。
 テキスト整形の基盤としてどうあるべきかを考えると、おのずと改行指向では破綻するとわかります。重要な整形の一つに、改行の削除があります。パーソナルワープロから持ってきた文書には各行に改行が入っているものがあります。それをDTPソフトに食わせるにはプレーンなテキストに整形しなくてはなりません。その際の途中の過程に無改行のテキストという状態があります。改行指向ではこの無改行のテキストを何気なく扱えるなんてことはできません。指向しようにも改行がないのですから。
 BeachTextがプラグインフィルターを使えるようになったのですが、いかんせん元が改行指向のテキストエディタですから、改行削除のフィルターを作ったとたんユーザが疑問を感じる動きになってしまうでしょう。
 無改行のテキストを読み込ませるとどうなるかやってみるのが、テキストエディタの改行指向と非改行指向の違いを肌で感じる良い方法です。Edit7は驚きました。
 多くのワープロは非改行指向です。たいてい、無改行のテキストを何気なく扱えます。褌・エディットのテキストハンドリングの方法はテキストエディタよりはワープロに近いといえるかもしれません。これは一般的なテキストエディタの使い勝手といったレベルの要求を無視して作られています。
 褌・エディットを作るときに自分自身に要求した機能は、
  1.無改行のテキスト扱っても性能が落ちないこと。
  2.どのようなバイナリもなんとか扱えること。
  3.空きメモリに制限されない大きさのファイルを扱えること。
  4.コケにくいこと。
の4点です。
 これらの機能は、一般的には評価されるものではありません。よって、これらすべてを実現しているエディタはほとんどないでしょう。

褌1.2.7 / 1995.08.17

 JGAwk関係の実装がすんだ。やっと終わった。まさかエラーコードをshortで返しているとは思わなかった。longで要求すると0しか返ってこないってのもまいったな。もうちょっとAppleEvantがフレキシブルにできていればいいのにね。また、エラー終了後の画面の回復がどうも変なので、強制的に再描画することにした。
 ファイルのカーソル位置を次回オープン時に再現するオプションが、正常に動作していなかったのだが、解決。もう、ローレベルのルーチンで何をやっているかなんてぐちゃぐちゃだ。
 プラグインに渡すメモリハンドルはスクラッププールでなくするという修正を入れる。また、スクラッププールの側でもサイズのチェックをするようにした。2重3重のチェックはこういった部分ではかかせない。多少効率は悪くなってもね(たいしたことじゃないが)。
 JGAwkプロセスがすでに起動されているばあい、警告をだすようにしたが、その実装に意外にてこずってしまった。プロセス情報のレコードは、あらかじめ値を入れておかないといけない部分が何カ所かあったのね。Inside Macintoshの例をちゃんと見るんだった。
 今回のバージョンはぐっと上げて1.5とする。よく考えたら最近はバグフィックスでもないのにバグフィックス番号しか上げてなかったからね。
 明日は久しぶりにCOCO姉ちゃんに逢える。うふふふ。

褌1.5b / 1995.08.18

 毎度のMAC POWER(アスキー)ネタだ。以下1995年9月号のハナシ。
 桂英史の「ユーザーシップの時代」は、今年から新たに始まった学者によるエッセイ3本のうちの一つだ。のこりの二つは、常々私が嫌がっている上野俊哉と粉川哲夫。
 桂のエッセイはいままでのところ、ユーザーという言葉をキーワードに大部分は真面目にだろうが、ちょっと変った(面白い)モノの見方を綴ってきた。で、今回は「西洋のユーザー」だ。
 この「西洋のユーザー」で指摘される「自称国際派知識人」はまぎれもなく上野や粉川のことであろうし、電算機業界にはそういった学者が溢れかえっている。
 また、日本におけるアラン・ケイの過大評価のハナシもでてくる。メディア論の浜野が、その普及に大きく寄与した。間違いなく浜野も「自称国際派知識人」であり、「西洋のユーザー」だ。
 アラン・ケイは確かに70年代に、現在のパソコン・ワークステーション環境の基礎となる研究をしていたし、そこで作られた技術が活かされているのは事実だが、なにも彼ひとりを祭り上げる必然性はどこにもない。彼は「未来を予測するには、それを作ってしまえばいい」とうそぶいたことで有名なだけなのではないかと思っている。ジェフ・ラスキンのほうがよっぽど偉いよ。偶然だろうが、林信行が編集したドン・ノーマンのインタビュー記事にもアラン・ケイを批判しているらしき一文が見うけられる。
 そう、当然インターネット騒動ともいえる昨今の風潮も俎上にあげられている。
 まあ、ようするに明治以来福沢諭吉やら森鴎外やらの伝統の西洋かぶれに対する批判で、「ありがちな」なんて評は受けるかもしれない。でも私は、西洋というよりは米国かぶれを多く読者層に抱えるはずのMAC POWERであえて掲載されたことを評価したい。また、同じ紙面上の執筆者への間接的(私には直接的に見える)攻撃を行ってしまったことも高感度大である。

褌1.5b / 1995.08.21

 「Linuxお気楽極楽インストール」(丸池樟著、カットシステム)という本がある。以前にLinux本を買いにいって、「Linux入門」と並んで置いてあり、パラパラと見比べて内容が薄かった(添付CD-ROMに何が入っているか書いてなかった)ため買わなかった方である。その後、この極楽本に対する非難が雑誌に掲載されるようになった。(以下全て1995年発刊)

 最初に見つけたのは「Software Design」7月号(技術評論社)の特集記事で、「フリーソフトの集大成Linuxの世界」(山崎康宏著)においてだ。以下引用。
 『この本の著者はフリーソフトの理念を理解していないようです。わたしこと山崎康宏は、このような本の出版を残念に思います。』

 次は「bit」8月号(共立出版)の連載記事で、「計算の迷宮」(電脳遊戯団著)より。以下引用。
 『(追記:この章を書き終えた後のことである。付録CD-ROMにGNUソフトを入れているにもかかわらず、GNUとストールマンに対し中傷誹謗をしている本を教えられた。実際読んでみて、その内容に愕然とすると同時に憤りを通り越し、情けない気持ちになってしまった。)』
 bitの記事は明確には極楽本を示していないが、確実に同書のことである。

 で、同僚にこの記事を見せると、彼の発見した記事を紹介してもらった。
 「SUPER ASCII」7月号(アスキー)の連載「Environments PC UNIX」(生越昌己著)より。以下引用(結構長い)。
 『もうひとつは「Linuxお気楽極楽Install」(カットシステム刊)である。この本の著者は我々の持つLinuxの世界観とずいぶん違う感覚を持っているようである。そのこと自体は価値観が多様化しているということで、これまた「普及の証」であるし、何も「Linuxは我々が独占している」などとは思っていないので、とやかくいおうとは思わない。しかしその本の中でGNUプロジェクトおよびその提唱者であるRechard M. Stallman(以下RMS)に触れた部分があり、RMSのことを「アメリカ乞食」と書いたり、「GNUはタダで配っているのだから、使っているからといって寄付する必要はない。そんな金があったら他のことに使え」などと書いている。確かにRMSは乞食風(あるネットで「GNUの教祖とオウムの教祖とLinuxの教祖は似ている」と書かれていた^^)であるし、GNUは再配布可能だから、確かにタダであるのも事実である。「乞食風」の話はおいておくにしても「GNUはタダだから寄付しなくてよい」というのは間違いであるし、そのようなことはちょっと考えてみれば分かるはずである。GNUは「思想」であるから、その思想を受け入れられる人とそうでない人がいるのは当然であるが、GNUプロダクトを使っているのなら、どのような形であれ何らかの「寄付」をするべきである。まぁ、そういう難しい話ではなくても、GNUプロダクトに「お世話になっている」という意識があるのなら、あのような書き方はできないと思う。まったく常識を欠いた本である。』

 で、あとひとつ。「Software Design」8月号(技術評論社)の連載「フリーソフト道楽」(柴田みゆき著)より。以下引用。
 『ところが、私にとって許せない内容の書物が出ているのを発見しました。「Linuxお気楽極楽インストール」(丸池樟著、カットシステム刊)という本です。「わかってないよな、この人」とわかる他は何もない内容ですが、絶対に見過ごせないのはFSFおよびR.Stallmanのことを、乞食呼ばわりしている点です。
 彼らの長年にわたる功績や理念とそのための努力を理解することなくしてフリーソフトを語れるとでも思っているのでしょうか。この著者にはLinuxのことを語る資格はないと思っています。』
 また、この記事の欄外に注釈がある。以下引用。
 『初版第2刷では、この部分が削除されているようです。知人によると、とある本屋さんで、初刷をすべて店頭からひきあげて第2刷におきかえている場面に遭遇したそうです。一体何があったのでしょうか。』

 これだけ引用すれば、いかに極楽本がUNIX界の人々の怒りを買ったかわかるであろう。この怒りは私の毎日コミュニケーションズに対する怒りと同じものである。丸池樟はRMSを乞食呼ばわりしたそうだが、丸池樟こそが乞食といえる。添付CD-ROMという形でGNUソフトを売ってお金を得ているのだから、GNUを非難するということにおける自分の立場の危うさに思い至らなかったのであろう。第一等に馬鹿だ。

 最後に再び「bit」8月号(共立出版)の「計算の迷宮」(電脳遊戯団著)より引用する。
 『新しいGNUのソフトウエアが公開された瞬間にインターネット経由でワッと群がるのが日本からのアクセスだそうである。そんなにGNUを熱狂的に支持しているのかというと、そうでもなく、無料のソフトウエアという以上には興味がないらしい。(中略)その影響なのかどうかは知らないが、リチャード・ストールマンは日本はあまり好きではないという話を伝え聞く。ある人が「日本には友人の竹内(NTTの竹内郁雄氏)や岸田(SRAの岸田孝一氏)がいるではないか」と言ったところ、彼はこう言ったそうだ。「彼らは別だ。日本人じゃない」』

 ビル・ゲイツは日本が好きだそうだ。
 類は友を呼ぶ。

褌1.5b / 1995.08.22

 こんばんはCOCO姉ちゃん。
 褌がBusErrorでコケる原因をひたすら追及して、理論的に問題が発生すると確信できる部分を発見しました。
 褌はメモリが足りなくなると、現在最前面にある文書以外の文書の占有しているメモリを優先的にディスクに吐き出します。TxPurgeOtherCacheというそれっぽい名前の関数で行っています。え〜、なんでキャッシュなのかといえば、内部構造的には画面に見えてない部分の文書データは本来ディスクにあるものとして設計されています。で、文書用メモリは文書単位にディスクのキャッシュとして管理しているわけです。これは与えられたメモリより大きいサイズの文書を扱うためです。たいていの文書はキャッシュ内で収まってますね。
 で、TxPurgeOtherCacheにおいて「現在最前面にある文書以外の文書」というやつを判定しているんですが、すでにCloseされた文書の情報ブロックを有効な値として判断していると判明しました。Closeされた文書の情報ブロックは値が不定なので、もはや何が起きても不思議はなくなります。
 てなわけで、複数の文書をとっかえひっかえ編集して、さらにメモリが足りないような状態にするとほぼ確実にコケます。
 このバグは、褌が初期の頃から抱えてたものです。どこかのタイミングで混入したモノではありません。いやはや古い問題です。

 褌1.5β2を送ります。

褌1.5b2 / 1995.09.04

 32Kバイト繰り返し問題は褌のバグでした。これもまた初期から抱えていたバグであると判明。1.0になる以前にSaveでそのパターンが発見されていたんですが、Loadでも同じ問題を抱えていたとわかりました。うひゃぁ、そこらじゅうでファイルの破壊をしてたんじゃないかな。まいったまいった。発見ありがとう。
 行番号付きのでっかいテキストを作るというアイディアは効果抜群。

褌1.5b2 / 1995.09.08

 さて、久しぶりにPlusで書いている。褌はまだまだPlusで使えるように作っている。まあ、System7以降かどうかの判定が随所にあるってことなんだけどね。今回のOpen At、Open File、Save As Atの実装でも、いろいろと苦労させられた。
 System 7.5になって標準ダイアログを使ったときに、どのフォルダが開くかの中途半端な余計な機能がついた。これがいろいろと問題を複雑にしてくれた。これまでは標準ダイアログはSystem 6との互換性を考えて古いパターンのものを使っていたのだが、もはやそれを使っていては開くときのフォルダの場所の制御ができなくなってしまったのである。Inside Macintoshの中でもなんとも解りづらい部分にSystem 7以降の標準ダイアログ制御の方法が記載されていた。FMACPROでの質問に応えてくれた六角さん、ありがとう。
 ついに標準ダイアログ周りをSystem 6とSystem 7で変えることになってしまったのだが、フォルダの制御の方法を確信するまで時間がかかってしまった。ボリュームリファレンス番号だけでファイルスペックを作ると、何故か目的のフォルダの一つ上のフォルダを開いてしまうのだ。デバッガで見るとどうもファイルスペック内部で一番下の階層のフォルダ部分が文字列になっていることが原因のようだ。ボリュームリファレンス番号だけでなくダミーのファイル名も加えてファイルスペックを作ると目的のフォルダが開いた。問題が全くないわけでもなく、ファイルスペックに残ってるダミーのファイル名を自力で空にしなくてはならない。直接の書き換えは推奨されないはずなので、何かが間違っているような気がするが、まあいい。
 ファイル名がメニューマネージャの認識するメタキャラクタを含んでいたときという問題があり、今までWindowsメニューではなんのチェックもなく文字列をそのまま渡していた。これはやっぱりなんらかの対処をしなくてはならない。その前に他のソフトではどうやってるか調査すべきか。
 Open Atシリーズの実装中にメニュー周りの実装間違いが発見された。GetMenuしたメニューハンドルをDisposeMenuしていたのである。DisposeMenuはNewMenuして得たメニューハンドルにしか使ってはいけないものだ。ときどきデバッガに落ちて、_InitMenu近辺のアドレスを表示していたのは、このあたりが原因かもしれない。
 いやはや、しかし9インチモニタって、小さいもんねぇ。
 あ、Plusのモニタに比べると15インチポートレートモニタって映りが悪いなぁ。

褌1.5b2 / 1995.09.15

 昨年、引っ越しをしたときに幾つかのソフト会社および代理店に住所変更の通知を入れました。カメオインタラクティブ(以下カメオ)も例外ではありません。
 米Passport社製品の取り扱い中止に伴う最後の(サポート外の)バージョンアップとしてMaster Tracks Proをカメオに注文したのは今年の2〜3月頃だったでしょうか。
 6月頃に「あれ?まだ製品が届いていない」と気づき、カメオに連絡を入れると「宅配便で送りましたが、戻ってきてしまいました。1カ月ほど前です」との返事でした。まさかと思い、住所を確認すると昨年引っ越した前の旧い住所でした。ちゃんと住所変更の通知はしたし、今回の注文書にももちろん新しい住所を明記したにもかかわらず、古い住所で送って、しかも届かなかったら原因を調べることもせず(手掛かりは全部カメオにあったわけです。ユーザデータベースの更新の責任は代理店にあるでしょう)、私からの連絡がなかったらいつまでも捨て置いたわけでしょうか。
 まあ、これはもういいことです。解決しましたから。

 コルグが米Passport社製品を扱うことになりました。既存の米Passport社製品ユーザに対する登録キャンペーン(らしきこと)をやっていると雑誌で読み、早速コルグに電話してみました。
 コルグからは、カメオ扱いのMaster Tracks Proユーザには日本語版6.0が完成しだいDMにて連絡する予定だと聞きました。すなわちユーザデータベースをコルグが買ったのでしょう。それはサービス移行に必要なことです。
 そこでです、念のため私の登録されている住所を聞くと、なんとまあ旧い住所でした。私からカメオへの電話はその場限りで、結局何の処理も行われていなかったのです。コルグからの案内が届かなくなっていたところです。

 これって明らかに「オ・ソ・マ・ツ」じゃないでしょうか?

褌1.5b2 / 1995.10.23

 米Gateway2000社のマシンを買おうと決めて、非常に値段の安い輸入代行業者に当時最高機種のP5-120XLを注文したのが6月の前半であった。マシンの代金を銀行で振り込んで確認してもらい、マシンの納品予定が7月末となった。私は暑い盛りに何を好きこのんで暖房機を買うんだろうなぁなどと思っていた。
 ところが7月末になっても返事がないので打診すると、マシンが届くには届いたが、注文品とはまったく違う変な486マシンだったそうだ。返して待つかキャンセルするかの選択になったが、5週以内に解決するだろうというということなので待つことにした。米Gateway2000社の営業はキャンセルを認めないことで有名だそうで、キャンセルした場合はさらに解決に時間がかかるだろうとのコメントもあったためである。
 注文した頃には考えもよらなかったのだが、日本ゲートウェイ2000という法人が設立され、輸入に頼らなくても国内で米Gateway2000社のマシンが手に入る状況ができてきていた(日商岩井は論外ね、ああいう商売を詐欺といわずになんという)。しかも日本ゲートウェイ2000の事務所は横浜のYBPで、まさしく勤務先の近所だ。私は恨めしい気持ちで窓から牛デザインの箱の山を見つめるばかりだ。
 8月末に輸入代行業者に再度打診すると、米Gateway2000社とはとりたてて進展がないそうだが、「9月20日頃までにはなんとかなる」といっているそうだ。しょうがない、待つしかないじゃないか。9月20日を過ぎたらキャンセルするよう伝えた。
 米Gateway2000社の上層部は日本からの注文は日本ゲートウェイ2000を通したいと考えており、その思惑が現場の営業の意識と完全にズレているのが今回のトラブルの大きな原因だ。あのねぇ、私が注文した時には日本ゲートウェイ2000なんてどこにもなかったのよ。わかってんのぉ?
 9月21日、輸入代行業者からキャンセルした旨を受けた。ただし、次は代金返却の問題が残っている。米Gateway2000社は契約不履行として詐欺罪に問われてもいいのだが、いかんせん中間に輸入代行業者があるため直接には何もできないのであった。
 10月3日に日本ゲートウェイ2000にクレームの手紙を出す。翌日勤務先に電話が来た。「大変すみませんが、私どもにもできることはあまりありません。ファイルングしておきます」という内容であった。国内で注文してもトラブルがやたらと多いとのことだ。まだ設立2ヶ月じゃね。
 で、10月下旬、私の手元にはいまだに代金もマシンもない。

褌1.5b2 / 1995.10.24

 カメオへのクレームをカメオのサポート会議室に書き込んだところ、すぐに返事がメールされてきた。結局は具体的に何かを求めるものではないので、これでオシマイなことではある。ひとつひっかかるのは、私が出した住所変更通知をカメオ側が捜し出せなかったことだ。引越しのタイミングで通知を出したと思っていたが、よく考えたら振込用紙を送ってもらうためのFAXで通知したんだと思い出した。どのみちオソマツさはかわりはしない。
 カメオがコルグにユーザDBを売ってからもうずいぶん経っているから、コルグがいざDMを出そうとしても、多くが住所不明で返ってくるだろうね。困ったハナシだ。

 Plusで使っているときに行末行頭へのジャンプのためのCommand-Arrowがきかないという問題があるのだが、まあ、誰からも指摘されないくらい個人的な問題だ。Plusで褌を使ってる人はほとんどいないだろうね。
 問題はVJE-βが入っているときなので、なんらかの理由でキーが奪われていると考えてよい。しょうがないので、Option-Arrowで代用させることにする。単語移動よりは明らかに頻繁に使うからだ。
 にしてもコントロールキーのないシステムってのは使いやすいものではないねぇ(何をいまさら)。Shift+Arrowの使い勝手もFEPがONになってると変だしね。

 10月中に返ってくるはずのマシンの代金は、もう11月もかなり過ぎたというのにいまだ振り込まれてこない。非常に憂鬱だ。怒りのぶつけ場所がない。

 フルパスからファイル参照番号に変換するルーチンをちゃんと書いたので、Open AtやOpen Fileでボリュームのルートレベルに入っているファイルもちゃんとアクセスできるようになった。よかったよかった。
 JGAwkとの連携動作で、パイプによる連続動作で問題がある。AESendが-908というエラーを返してくるのだ。これはもうお手上げに近い。known bugとしてリリースしてしまうことにする。
 ファイル名として使っている文字列で、そのままメニューに渡したのでは問題が出るパターンが存在することはわかっているのだが、前に調べたときに何の記録も残してなかったみたいだ。もう一回チェックしてどこかに書いておこう。
 どういったときに問題になるのかというと、メニューに現在の文書の名前を入れるという実装が普通だからだ。エディタでファイルがメニューで選べないのはSimpleText以外はないのではないだろうか。「-9」という名前のファイルを開いてみると良い。Edit7など大抵のエディタはさすがなもので、ちゃんとメニューで表示できる。Nisus Writerではファイルアクセスメニューで表示はするが、どうも先頭にスペースを入れるという方法のようだ。ウインドウメニューではセパレータに化けてしまう。
 褌では先頭に$0Dすなわち改行を入れるようにしてみた。改行は文字幅を持たないため、表示上は何も先頭に入れていないように見える。はたしてEdit7も同じ方法だろうか? 誰もがやってる一般的な方法というものがあるのだろうか。

褌1.5b3 / 1995.11.11

 先週の土曜日、11/11の夜中に突然外付け1G HDDがイオン^H^H^H異音を発した。どうやら埃がつまってファンが止まっており、かなり熱を持っている。異音は以前に聞き覚えのあるもので、何度かケースを開けてドライブを取り出したりしてたためSCSI IDを決めるスイッチが接触不良を起こしやすくなっており、ガチャガチャというSCSI IDが内蔵ディスクとぶつかったときに出す、不愉快な音だ。
 しょうがないのでIIcxの内蔵ディスクを取り出して1Gディスクと交換した。もう1Gディスクで使っているケースは信用できないからだ。外付けには漢字Talk 7.1の軽い純システムが入っているので、ターミネータをちゃんとつけると起動した。
 夏頃にディスクがイカレてしまったClassic IIにIIcxで使っていた内蔵ディスクを入れてフロッピーで起動した。IIcx向けのシステムはClassic IIでは起動しない。さてここからが問題だ。IIcx向けのSystem 7.5.1をClassic IIからIIcxに転送しなくてはいけない。
 Classic IIに入れたディスクにClassic II向けのSystem 6.0.7.1をインストールして、AppleTalkが動くようにした。IIcxへLocalTalkで転送するしかない。
 長かった。
 転送後、転送されたシステムへスイッチして再起動するとSystem 7.5.1が起動した。一安心だ。ところがだ、使ってて違和感がある。プロセスの切り替え等が異常に遅い。やられた。これはSystem 7.5を最初にインストールしたときにでた症状だ。結局HDDをイニシャライズして、空っぽにしてから再インストールして解決したやつだ。やばい。
 1Gディスクをイニシャライズして、綺麗な状態でシステムをインストールしなくてはならない。当然だがバックアップが必須だ。しかし1Gディスクをバックアップする方法がない。まいったな。
 土曜日はそのまま寝て、日曜日。
 迷った末MOを買いに行った。
 新宿のT-ZONEでウイン・システムのC20-230MIIという230MByteのMOを買ってきた。ドライブはまあ安かったのだが、ケーブルが高かった。ハーフピッチのSCSI端子なのだ。
 帰ってきてさっそくバックアップだ。C20-230MIIはターミネータのスイッチがあり、ターミネータに敏感な1Gディスクのため、CD-ROMが終端にあるにもかかわらずONにして接続しなければならなかった。IIcxは現在、内蔵されたディスクだけではターミネータを外に付けないと起動もしない。ちょいと敏感すぎるよ、このディスクは。
 MOは思ったよりは速い。Classic IIに内蔵したかつてのIIcx内蔵ディスクに匹敵するスピードではないだろうか。もうちょっと重いか、さすがに。IIcxに内蔵してたディスクだって、後から買ってきた外付けを交換して入れたものだ。
 全部バックアップして1Gディスクのフォーマットの段階になり、C20-230MIIに付属してきたCONIGLIO DRIVERというフォーマッタを使ってみようかと思ったのが運のつき(もうハナからつきてたっけか)。フォーマットを開始すると突然画面がフリッカー状態になってしまった。ビヨビヨビヨ。ゲゲゲと思い、いきなり電源を切った。フロッピーで起動すると、1Gディスクを認識する段階でまたビヨビヨビヨだ。あれ〜、起動すらできなくなってしまった。
 しょうがないんで、一旦1Gディスクのインターフェースケーブルを抜いてフロッピーでシステムを起動し、別のフォーマッタを起動してから、ケーブルを差した。スキャンするとちゃんと認識してくれた。ラッキーとフォーマットを始めた。しかしどうもフォーマットをしている気配が感じられないので(実際にはやってたらしい)なんとなくまた電源を切ってしまった。
 再び起動するとビヨビヨビヨはでないのだが、フォーマッタにコマンドを無視されてしまうのだ。
 ああ、フォーマットの途中で電源を切った私が悪うござんした。
 1Gディスクに付属してきたフォーマッタを探し出してフォーマットさせると、さまざまなエラーを表示した後でパーマネントフォーマットを始めた。ああ、ちゃんと修復能力のあるソフトだったのね。助かった。マジに助かった。
 フォーマット終了後System 7.5.1のインストールを始めた。ついうっかりSystem 6.0.7で始めたもんだから、インストールの最終段階で「存在しないトラップ」でコケてしまった。ガ〜ン。
 まあ、なんだかんだあったが、ようやく環境も回復した。
 MOってラクチンだね。 
 意図せずしてClassic IIが復活することになってしまった。

褌1.5 / 1995.11.18

 今週の月曜日にようやく、やっと、ついに、マシン代が帰ってきた。5カ月ぶりである。どうやら輸入代行業者にはいまだ米Gateway2000社からの返金はないようだ。輸入代行業者が立て替えてくれたのである。ともかくこれで別のPC/AT互換機を買うことができるってわけだ。
 即、月曜日にPCダイレクトに電話して550Si/100を注文した。SiSのチップセットにPentium 100MHzの組み合わせだ。ビデオカードに関してPCダイレクト側はより高速なIO-DATAのドラゴンとかいうものでどうかときた。「Linuxでの動作の確認はありますか?」と尋ねたところ「IO-DATA側に聞いてみます。電話を掛け直しますのでよろしく」となった。
 IO-DATAからの返事がどんなものだったかは具体的には知らないが、「DOSのVGAで動作するならば問題ありません」というチンブンカンプンなものだった。あのね、LinuxとDOSは関係ないのよ。LinuxってOSよ、DOSアプリかなにかと思ったのかね。ビデオチップメーカとしては老舗のトライデントだそうだが、XFree86で性能を活かせるドライバがあるとはとうてい思えない。
 そういうわけで「そういう返答をする会社のボードは論外ですね」とS3 Trio64で2MByte VRAMで注文した。あと、メインメモリを32MByteにしたのだが、8MByte * 4の構成の可能性があるときた。「メモリのスロットは?」「4つです」「論外だねぇ」「メモリ増設時に考慮いたします」。
 注文書が届いてから電話したらメモリ構成は8MByte * 4になってしまったそうで、11/22に16MByte SIMMが入荷するので、それを送付したら交換してほしいということになった。あれぇイキナリ最初からメモリの交換かよぉ。ま、いいけどね、16MByte * 2になるなら。
 で、11/17に留守の昼間に佐川急便がやってきていて、再配達の電話を入れた。
 11/18の午前中に来るはずがまったくこない。佐川急便に電話を入れるとミスで遅れてしまったそうだ。忘れられてたんだね。とことん互換機購入はトラブるなぁ。
 で、来た見た動いた。さすがにミドルタワーはでかいでかいでかい、9500クラスのサイズだ。しかも結構重い。我が家で最も重いパソコンはIIcxなので、無茶苦茶重く感じる。仕事ではいまだにDOS/V 5.0を使っているので6.2を長時間使うのは始めてだ。HDにしかインストールされていないソフトをFDにバックアップして、ひととおり動作を確認した。VRAMが2MByteあるってことをどうやって確認するかが残ってしまったが。BIOSはAwordだった。AMIだと予測していたが、違ったわけだ。
 ケースを開けて中を観察することにした。ネジなしで空けられるってのは驚いた。これは評価に値する。こういうケースもちゃんとあったのね。
 なかのボードはなんだかんだとたくさん部品が列んでいた。IIcxのシンプルなボードとは全然違う。SIMMはHDDをハズさないと交換できないようだ。ああ、面倒ね。センチュリー製のISAバスモデムカードH-1414の部品が1個妙に背が高く、隣のPCIバスまではみ出ていた。これはPCIカードが増えてきたら場所を変えないといけなくなるだろう。音源ボードは純正サウンドブラスター16であった。これが一番でかい拡張ボードだ。IDEの4倍速CD-ROMドライブは鳥取三洋電機製のようだ。あ、HDDのメーカを確認するの忘れていた。
 ケースを開けるのは簡単だったのだが、閉めるのが案外苦労する。ネジがないから何カ所かで出っ張りをハメないといけないのだ。これはあんまり気軽に開け閉めできないぞ。
 ひととおりDOSを楽しんだら(ああ私ってばこんなものを楽しめる体なのね)Linuxのインストールが始まる。どんな障害が発生するかは次回のお楽しみ。ではアップだ。
 音つきでDOOMをやるのは初めて。

褌1.5 / 1995.11.19

「ホーム」へ戻る
「読まなくてもいいよ12」
OSTRACISM CO.
OSTRA / Takeshi Yoneki