OSTRACISM CO.
■ 開発日記 巻之十四

OSTRA / Takeshi Yoneki

 CodeWarrior9が届いた。Bronzeがなくなったことの説明書にGoldを配布するとある。よくみたらCD-ROMはGoldであった。しかも契約更新料が大幅に値下げされている。こりゃ嬉しいね。
 IDEは1.6にバージョンが上がっていた。GripGropを再コンパイルすると、実行モジュールが1割ほど小さくなった。へええ、68Kコンパイルのコード効率が上がっている。実行速度が落ちてなけりゃいいのだが、それは後で調べることにしよう。いままでCodeWarriorでできたコードはSymantec C++でできたコードに比べちょっと大きめであった。そのかわり実行スピードはCodeWarriorの方が速かった(少なくともGripGropでは)。オブジェクトインスタンス形成のロジックの違いが速度差の最大原因なのではないかと思うのだが、そこらへんは実験したことがないのでなんともいえない。

1996.06.07

 テックwith戸田誠司の音楽CD「ポリゴン番長」を買ってきた。アスキーのTechWinに毎月連載?している歌謡曲の昨年分を収録したものだ。2曲目の「はじめてのC」が実にいい。B-52's風のアレンジで女の子に歌わせる題材として非常にマッチしている。こういうの私がやりたかったんだよぉ。
 全編なんらかのパロディ形式をとっているという意味で、幻の「タモリ3」や「服部」以降のユニコーンに通じる面白さがある。あたしゃこういうのすきだわさ。
 戸田誠司って優秀なポップスメーカとしての実力を持ってるのになんであんまり評価されないのかな。小西、松浦、戸田すなわちピッチカート5、PSY・S、フェアチャイルドの順で評価が高いみたいだけど、私の好きな順番は逆転してるなぁ。

1996.06.08

 茄子Rと實篤間の非互換性に関する確認が、Nifty-ServeのFJAMEPフォーラム16番会議室において#3947からのスレッドで展開されました。興味のある方はそちらを参照確認してください。
 本題と無関係のやりとりが多いですが、無視して読み進める方が良いでしょう。
 RANDOMさんの考え方と私の考え方はかなり正反対といえますが、どちらが良いとか悪いとか決められるものではありません。お互いの信念の違いともいえます。最終的な判断はユーザに委ねられるものです。

1996.06.09

AfterDark3.0dと褌・エディットのインライン問題

 AfterDark3.0dのモードに入ったとき、褌・エディットにはDeactivateイベントは送られないし、復帰したときにActivateイベントは送られない。褌・エディット側からは「勝手にインプットメソッドが死んでいる」ように見える。

 AfterDark3.0dのモードから復帰して以降も褌・エディットはTSMイベントを受け取っている。しかしそれが正常にハンドリングできなくなっている。
 褌・エディットはどのWindowに対するインライン要求かをTSMに対してrefConにIDを入れることで識別している。
 AfterDark3.0dのモードから復帰して以降はそのrefConを得ようとすると-1701のエラーとなる。これは「デスクリプタレコードが見つかりません」というエラーで、インプットメソッドがtsmIDとrefConの結びつけをするときに混乱しているということを示している。仕様的にtsmIDはWindowと結びついているため、Windowの認識に問題が生じていると推測される。

 褌・エディットでResumeとSuspendイベントを受け取れるようにすると、AfterDark3.0dのモードから復帰したときにResumeが送られる。しかしここでやれそうなことはやってみたが、refConがきちんと受け取れるようにはできなかった。
 refConをWindow識別のために使うという実装は(かなり一般的なはずだが)私の独特な方法で、これがAfterDark3.0dと完全にぶつかっていると思われる。TSMTEを使った實篤でも同じようにrefConをWindow識別のために使っている。

 ともかくAfterDark3.0dがインプットメソッドに重大な悪影響を与えていることは間違いないと思われる。

1996.06.15

 さてとLinux。
 netatalkを使うにはカーネルの再構築が必須だということで、make configで設定したあとmake dep、make clean、make zdiskをした。しかしmbuf.hがないとかで怒られる。カーネルが古いのかなぁとおもいつつあきらめて電源を落とした。ああああぁ、電源落としちゃった! shutdownしてないぞ!
 再度電源を入れたらファイルシステムのチェックが始まった。システムは起動した。しかし、もはやshutdownコマンドが使えなくなっていた。shutodownやrebootをすると「すでにshutdownは動いてる」なんて怒られる。まいったなぁ、こりゃ再インストールだ。
 翌日、ユーザファイルを中心にファイルをtarしてgzipしてDOSのパーティションにバックアップした。念のためマックのDISKにもftpしておいた。久々のLinuxインストールが始まる。
 Lazer5 Linux CD-ROMから、ブート向けKernelを探すところから始めた。それらしいカーネルのどれを入れても起動時にKernel Panicになってしまう。よくよくCD-ROMを探すとKERNELというディレクトリでなくBOOTDISKというディレクトリがあった。あ、このディレクトリのイメージを使わないとBOOTフロッピーは作れないんだった。すっかりもう忘れている。
 やっとBOOT可能なフロッピーが出来上がり、DISKの消去、カーネルのインストールと進んだ。前回悩んだところはさすがに覚えていたので、すんなりカーネルは入った。で、ツールやネットやX-Windowのインストールをして、JEを入れた。
 作業の途中でいちいちrootになるのが面倒くさくなったので、/USR以下全部 chmod -R 777 * をした。これがいけなかった。いきなりX-Windowが一般ユーザで起動できなくなったのだ。rootでは起動できる。ファイルの権限は下手にいじくれないのね。
 しかたがないのでX-Windowをもう一回入れなおした。きちんと起動できるようになった。ふう。
 何故かは知らないがfvwmのボックスに張ってたアイコンが1つ全然違うイメージになっていた。元々使っていたアイコンがどうにも見つからない。古いLinux CD-ROMもかなり探した。あのアイコンはどこから手に入れたんだろう。とりあえずは別のアイコンを張っておくことにした。
 で、普通にインストールするとカーネルは1.2.xなので、1.3.xのソースをインストールして、それを再構築することにした。netatalkは1.3.xの方が楽に導入できると新田さんから聞いたからだ。make configの動作が1.2.xと1.3.xとで若干違う。で、make dep、make clean、make zdiskした。問題なくBOOTフロッピーが出来上がった。BOOTフロッピーは問題なく起動する。起動時にスピーカーが「ボツ!」と音を立てるようになった。サウンドの設定が有効になっている証拠だ。今までカーネルの再構築はしたことがなかったのでLinuxはサウンドなしだったのであった。
 make zliloして、再起動。ついに1.3.20のLinuxが登場。いやはや世間からは半年遅れてるぞ。試しにDOOMを起動した。音もばっちり。問題なく動く。やはり以前動作させたときにコケたのはサウンドの設定がなかったからであろうと結論。しかし、つくづくDOSのDOOMと同じだなぁ。
 肝心のnetatalkをmake。ドキュメントに書いてあるようにヘッダファイルを用意しようとしたら既にあった。ふむ、1.2.xとは違うねぇ。しかし、「uio.hで定義が2重化されてる」と怒られる。uio.hを見るとやけに小さい。「多分他のところで定義されてるんだろう」ということで、ソースの #include をコメントアウトした。同じエラーが何度もでて、その都度コメントアウトした。何度もコメントアウトしてはmakeをかけると遂にnetatalkの実行モジュールができあがった。make installしてから、/etc/local/atalk/etc/rc.atalkを起動すると、マック(organon)からLinux(monado)が見えるようになった。/home/organonに.AppleVolumeを用意して、有効にするディレクトリを指定すると、ついにマックからLinuxのディレクトリをマウントできた。やった!
 /etc/rc.d/rc.localにnetatalk起動のコマンドを追加、再起動すると、なんともdaemon起動にやたら時間を食う。これはしかたのないことなのだろうか。何か余計なチェックをしていそうな気がする。

 ファイルタイプの規定されていない拡張子のファイルや'TEXT'にされているファイルは勝手に改行の変換をしている。これは完全にやらないようにできないのだろうか。何かスイッチがあるはずだとは思う。
 マック側からLinuxディレクトリをマウントしたままLinuxのrebootやshutdounをすると、マックは「切れたよ」とダイアログを出すのだが、その後黙りこくってしまう。マック側をきちんとアンマウント(ごみ箱へポイのことね)してからでないとLinuxのrebootはしてはいけないみたいだ。ま、サーバなんだからあたりまえなんだろうけど。

1996.06.25

注:
 uio.hで定義が二重化されるのは、uio.hが2カ所にあるためです。GNUのライブラリ向けのuio.hとLinuxカーネル構築向けのuio.hの2つがあります。
 ヘッダファイルを作るテクニックのひとつに、ヘッダファイル固有の#defineを用意して、何度インクルードされても二重定義されるのを防ぐという書き方があります。ところが、この2つのuio.hは#defineが違うため、二重定義が発生することになります。
 netatalkのドキュメントには片方をもう片方のリンクにするよう書いてあります。しかしこの方法は後にカーネルの再構築をするときに問題になる可能性を持っています。Linuxカーネル構築向けのuio.hにしかない値の定義があるからです。

 まだまだLinux。
 Laser5 Linux CD-ROMのOther Diskにはさまざまなソフトが入っている。NCSAのhttpdもそのひとつだ。自宅のLinuxをWWWサーバにできるということだ。WorldでWideなWebではなく、LocalでNarrowなStringだということにはなるが。
 Linux向けのパッチはhttpd_1.4.1のひとつ上の階層で patch -R < ...としなくてはいけなかった。で、make linuxでバイナリはできあがり。よしよし。
 HTMLの書式なんて知らないので、笹塚の紀伊國屋でテキトーに入門書を買ってきた。エーアイ出版の「HTML & CGI入門」と技術評論社の「はじめてのJava」。いや、べつに推奨するとかの意味はない。はっきりいってどれを買っても同じようなもんだと思う。きちんと使いこなすには別途ちゃんとしたリファレンスマニュアルが必要で、その前の取っ掛かりとして読むだけだ。両方合わせて3時間程度拾い読みすればいい。「HTML & CGI入門」の著者はまだ22歳で、ムチャクチャ若い。例題に使われているイラストの趣味が私とは合わないのはまあ、しかたがなかろう。
 マックのNetscapeで.htmlファイルの書き方の練習をしてから、Linuxのhttpdに戻ってきた。README.FIRSTを眺めているとなんだか初期動作の例のようだ。この後半のシェルスクリプトの部分をマシン設定に合わせ(たつもり)、実行させてみたがifconfigのところでつまずいてしまう。なんだろうなぁ、明日だ明日だ。
 なんかないかなぁと「HTML & CGI入門」をめくってたらUNIX向けhttpdの設定なんてことが簡単に説明されていた。ラッキー。/confにあるファイルを.confの形にしないといけないのね。でも、初期起動の方法が書いていないなぁ。まさかなぁ。デフォルトの.confファイルの中身を読むと/usr/local/etc/confなんて記述もある。もしやとただ単に引数もなくhttpdを起動したら/usr/local/etc/confに.confファイルがないと怒る。次に.confファイルを移動してから起動したら/usr/local/etc/conf/logにログがとれないと怒る。ディレクトリを用意してからまた起動したら、何のメッセージもなかった。へ? ps xしたらきちんとhttpdがいる。これだけでいいの? あのシェルスクリプトはなんだったの?
 .confの記述通りに/home/wwwを準備してtest01.htmlを書いた。
 マックでNetscapeを起動し、URLをhttp://monado/test01.htmlとしたら、でたでた月がでたでたヨイヨイ。「Hell World!!」
 ついに家庭でWWWサーバが起ち上がった。

 もひとつ、CW9にJava開発環境(ちゃんと68K環境もある)が入っていたので、これも最初の取っ掛かりを始めた。「はじめてのJava」を見ながらHellWorld.javaを書き、コンパイルした。.htmlファイルがないとAppletは動作しないのでHellWorld.htmlも書いた。でも、なぜか動作しない。Metroworks Javaのメッセージは正しそうなのに何かがおかしい。結局これは.htmlファイルでの<applet>指定で、widthとheightの間に「,」を入れていたことが原因と判明。どうしてもCプログラマの癖が出る。こういった文法間違いは無視されるだけなので高さ0で動作していたのであろう。.htmlファイルの文法チェッカーは必要だよなぁ。ブラウザのモードで何かないのかな。
 でまあ、やっと初Java Appletが表示された。「Hell World!!」

 Linuxのnetatalkの設定で、拡張子「.」のみというものを用意すると、設定外のファイルが全部「.」で指定されたクリエータとファイルタイプになると判明。これでLinux-マック間でバイナリがやりとりできる。改行変換されるのはファイルタイプが'TEXT'のものだけのようだ。
 Linux側ののCD-ROMにある.movファイルを直接SimplePlayerで開くと「見つからない」エラーがでる。どうやらnetatalkでマウントされたボリュームではQuickTimeは動作できないようだ。真相はわからない。
 「Hell World!!」

1996.06.26

 それでもLinux。
 「HTML & CGI入門」でのhttpd向けのcgi-bin/imagemapの説明を参照に動作確認してみた。パスの指定やらなんだかんだと試行錯誤しながらなんとかイメージマップが動作できた。Netscapeに依存する方法でなく、CGIを使う方法だ。ただ、図形の座標を自分で調べあげて.mapファイルを書かないといけないってのはちとやる気をなくす。マッピングのためのGUIツールは各OSにあるようだが、そこまでするほどのLANでもないし。ふうむ。
 イメージマップに使える画像ファイルはなぜかJPEGではダメで、GIFにしないといけなかった。ここにチョッとハマッてしまった。httpdとNetscapeのどちらの制限かはなんともわからない。

1996.06.27

 VxDに関する文献はたくさん売ってるからま、会社の経費でガンガン買って読めばよろしい。実は私はVxDは詳しくないのだが、今回の質問で「リニアモード」アドレスという耳慣れない言葉がでてきたので、「Windows3.1プログラミングバイブル」(アスキー出版局)を引っ張り出してきて確認した。これには山中の知りたかったことはばっちり載っていた。
 「リニアモードアドレッシング」という言葉自体は怪しい響きがあるが、「リニアアドレス」という言葉はある。これは80386の仮想番地をデコードした結果の実番地のことだ。VxDはセレクタに0を指定して実番地を直接アクセスできるようになっている。たぶんこれを「リニアモード」と呼んでるのであろう。
 8086、80286、80386とどういうふうにアドレスの扱いが変わってきたかを何かCPUのアセンブラ解説本でも呼んで理解しておいた方が良い。私は「80386の使い方」(オーム社)を使っている。386以上はソフト的に同じなので気にしなくてよい。
 Windows3.1にはリアルモード、プロテクトモード、エンハンスモードの3つがあったけど、これは8086、80286、80386にそのまま対応しているわけじゃない。リアルモードは8086に、プロテクトモードは80286に対応するが、エンハンスモードは80386にそのまま対応はしていない。80386を活かしきっていないのである。80386の持つ仮想86モードを利用しているだけで、80286のプロテクトモードとアドレッシングは同じ。エンハンスモードでも相変わらずセグメントは64KByteだったよね。
 80286のプロテクトモードと80386のプロテクトモードはそれぞれ16bitプロテクトモード、32bitプロテクトモードとでも呼ぶべきもので、Windows3.1までは32bitプロテクトモードでは動いていない。
 80386の32bitプロテクトモードに対応するのはWindows95だ。1セグメントは32bitになったので、メモリで悩むことはなくなった。
 で、本来プロテクトモードは別のセグメントアクセスに対して警告を出す。保護(プロテクト)されてるわけだ。でも、VxDは特権レベル(リング)0でしかもセレクタ値0の32bitアドレス直接で書けるので、どんな悪いこともできる。現在動いているプロセス全部覗き見ることができる。
 80386は仮想記憶としては46bitだけど、実記憶は32bitで、1セグメントも32bitだ。ここらへんの扱いは完全に80386特有の世界の話だな。他のCPUはもっと単純よ。たまたま実記憶と1セグメントが同じ大きさだから「リニアモード」なんてもっともな言葉があるんだろな。普通他のCPUではセグメントなんて言葉はない。
 80286の仮想記憶は24bitで、1セグメントが16bit。ゴミCPUと言われたゆえん。比較的最近まではプロテクトモードといえば80286の16bitプロテクトモードのことだった。
、8086に至っては仮想はなく実記憶20bitのみ。実モード(リアルモード)ってのは8086のこと。脳梗塞のCPUといわれるわけだ。

1996.07.25

昭和古賀メロディー『實篤エレジー・仲良きことは』

Produced by Takeshi Yoneki
Composed and Written by Yusuke Yamanaka
Arranged by Satoshi Ikeda

右を向いても 左を見ても
とかくこの世は 世知辛い
一人寂しく トォテチィテェタァ
どうせおいらは 蚊帳の外
カボチャは何も ああ云わないけれど
親父のォ〜 銭が飛ぶ

Copyright (C) 1996 OSTRACISM CO.
OSTRA / Takeshi Yoneki

1996.07.29

 長いことパソコンを使ってるが、最初からROMに焼かれているとかバンドルされているとかいうこと以外では初めてマイクロソフトのパッケージを買った。DOSやWindowsを使ってるという意味ではマイクロソフトに対してパソコン税は既に払っているのだが、内税なので実感はあまりない。そこがマイクロソフトの商売の巧さである。
 そう、AT互換機を買った目的のひとつであった「Microsoft Flight Simulator Ver 5.1」(MSFS5)を買ってきた。本当はプレイステーションの「KING'S FIELD III」を買いに行ったのだが、ついでにパソコンショップに寄ったのが悪かった。MSFS5ばかりか「ALONE IN THE DARK」の1〜3まで入った欧州版パックと「LONGBOW」とかいうヘリコプターものまで買ってしまった。「ALONE IN THE DARK」は全然進んでないうちに進藤さんに返さなくちゃいけないので自分で買っちゃったわけだ。
 「LONGBOW」はインストールに100MByte食うとあったので、始めるのはHDDを増設してからだ。DOOMやMSFS5を消してまでやるものかどうか。
 「ALONE IN THE DARK」は3つとも全部CD-ROMで、フロッピー版にあった小冊子プロテクトはなかった。CD-ROMからデータを読み込むことでプロテクトの代りにするようだ。この方がプレイするときは楽でいい。
 以前に買ってあったロジテックのWingMan(操舵タイプのジョイスティック)がやっと使える。モニタの上で完全に埃を被っていた。そういえばウチはロジテック製品が多い。先日マックの純正マウスを開けたらロジテックであった。マック用の外付けCD-ROMもロジテック(ドライブはSONY)。X-Window向けにとAT互換機に付けた3ボタンマウスはロジテックのMouseManである。
 MSFS5は地味で真面目でいいね。やっぱすごいや。でも全然わかんないんでDART社の解説本を買ってきた。航空機用語や概念なんて全く知らないから重宝する。ただ、訓練向けに想定して解説してあるのが別売のJapanシナリオだってのはいただけない。デフォルトで可能なシナリオにすべきだろう。
 解説本を読んでMSFSシリーズがマイクロソフト製でないということもわかった。ということはマイクロソフトで開発されたパッケージはまだ買ってないことになる。ふうむ。
 ともかく見よう見まね、ちと違う、試行錯誤を繰り返し、最高にイージーなモードでやっとこさ着陸できた(離陸は誰でもできる。着陸ができない)。いや、必ず着陸できるわけではない。確率は1/5位であろうか。ひたすらクラッシュばかりしてる。解説本に沿って訓練すべきなんだろうな。ラダー制御用のフットペダルが必要か? そこまでハマるかなぁ。

1996.07.01

Subject: Re^16: KF3
Date: Thu, 04 Jul 96 15:28:29 +0900
From: Takeshi Yoneki

> メレルウルを倒すとKF Iの地下洞窟にいけるとか

こらこらこら、こういう人の楽しみを奪うことは書いちゃダメ。しかしドラ
クエ3のパターンだね、これ。

> マルチエンディングのすべてのパターンをみるとかってなると、それこそ、
> ひとつぶで10度くらいおいしそうですね。

マルチエンディングってあんまり好きじゃないなぁ。すっきりポンと終って
欲しい。

ハイパープレイステーション買ってきて読んだら、なんかやたら隠し扉が多
いね。牢屋の鍵が隠し扉の先にあるってのは、ちと問題だと思った。KF3は
KF1と違って隠し扉が壁と判別できないし、あんまりヒントもないからねぇ。

あとは概ね不満なし。やっぱいいねぇ。この独特の世界は。
難易度も下げてあるみたいだし、やっぱFK2は難しかったと判断したのかな。
ドラクエみたいに難易度の高いシリーズ2作目が最も(マニアに)評価が高
いということになるだろうね。
米国でKF2の評価が高いそうだけど、あのMYSTの評価の高い国なのであんま
り信じてない。米国では難しいソフトがゲームマスコミに受けるみたいなん
で、手放しには喜べないな。日本国内では評価されなさすぎなんで、いい刺
激にはなるかもしれない。

Takeshi Yoneki

 UNIXのテキストとパソコン(マック・PC)のテキストではかなり作法が違う。いや、改行コードのことを言っているのではない。改行コードがUNIX・マック・PCで違うのはご承知の通りだが、そういったレベルのことではない。焦点はテキストの論理構造と呼ぶべき部分についてであろうか。
 UNIXのツールは「ま、なんとか使えればいいや、不都合は運用でカバーすれば良い」ということで作られているものが多い。そのため、多くのUNIXツールは「行」という概念を持っている。そしてその概念はテキストエディタにまで敷延されている。
 UNIXのエディタに行サイズの大きいテキストを読み込ませることはできない。viは明確にエラーを表示するし、Emacsでは読めたとしてもエディットが実にやりにくい。これはUNIXでは「適切なサイズで改行したテキスト」を使うという文化になっていることを示している。
 HTMLファイルを書いた人ならわかるだろうが、文中の改行はデフォルトでは無視され、改行を表現する方法が別に用意されている。TeXも同じく改行は明確に提示しなくてはいけない。C言語はそもそもプログラムがフリーフォーマットに近く、見やすさのためのインデントや改行の制限はほとんどない。これは結局、エディットするときに入れる改行は最終生成物では無視してあげますよ、という約束事をあてにしてツールが作られているということだ。明文化されているわけではないが「適切なサイズで改行したテキスト」が作法として実際に運用されている。
 こういった明文化されていない約束事はUNIXに限らずコンピュータ全般にさまざまなものがある。例えばマックではクリエータという4文字の識別子の利用に関して明文化されていない約束事がある。この識別子はあくまでドキュメントを開くアプリケーションを特定するためのものであり、それ以外の意味は持たせてはいけないと多くのデベロッパは考え、了解している。SuperPaintで作った'PICT'とPhotoshopで作った'PICT'はどちらからも同じように扱われなくてはいけない。独自の情報を付加することもかまわないが、それはリソースを付け加え、それで判断することになる。もちろんクリエータはファイルの種別を表すものではない。ファイルの種別はファイルタイプという識別子が存在するのでそれを利用すれば良いだけだ。
 約束事を破っているアプリケーションもときどきある。NisusWriterはワープロ文書を'TEXT'というファイルタイプで保存する。他のエディタ等で作られた'TEXT'との区別はクリエータで行っているようだ。これはあまり誉められた実装方法ではない。
 WindowsのMS-WORDが拡張子.DOCを使うのも、それまでの作法を無視した最悪の実装といえる。
 作法の話に戻そう。
 UNIXでは「適切なサイズで改行したテキスト」を前提としたツールを作っても有効なのだが、それはパソコンでは通用しない。PageMaker等のDTPソフトの要求する「プレーンテキスト」は「適切なサイズで改行したテキスト」ではない。改行があったらそれは確実に改行として認識される。パソコンでは「段落内に改行を入れないテキスト」が一般的に使われている。そう、UNIXとパソコンでは同じように「テキスト」と言っていても実は違うものと考えた方が良い。
 パソコン通信やE-Mailで使われているテキストはUNIXでの約束事のテキストに近い。というかそのものであろう。これらのシステムのテキストに対してはUNIX的なツールが有効に使えることになる。
 適切なサイズで改行があることを前提とすると、ツールが非常に書きやすくなる。行バッファという扱いやすい単位で処理を記述できるからだ。しかしそういうツールにパソコンで普通に作られたテキストを通すと、たいていは無茶苦茶になる。
 褌・エディットはパソコンにおけるテキストを扱うという前提で、「段落内に改行を入れないテキスト」はおろか「無改行のテキスト」までなにげなく扱えることを目標とした。マックの多くのエディタは「段落内に改行を入れないテキスト」には普通に対応できる。たいていは段落が常識をこえて大きいことはない、という前提で作られている。それはそれである程度の約束事に近い。100KByteの無改行テキストなんてのは約束違反なのであろうと思う。
 結局、何がいいたかったかというと、「マックやPCで使うテキストをUNIXのツールでは作れない」ということだ。Emacsでは段落を無改行で書くのは至難の技だ。本来Emacsはプログラムを書くためのツールだからそれで散文を書こうというのが間違っているのだろうが、UNIXでは散文もプログラムと同じように改行まじりで書かなくてはいけない。そして、改行まじりででき上がった散文はパソコンに持ってきてもそのままでは使えない。
 困ったもんだねぇ。どう運用すべきかねぇ。

1996.08.23

 そういえばなんで實篤等の私の作品をシェアウエアにしたのかを明確には書いてなかった。一応何をどう考えシェアウエア化したかを書こうと思う。

 私のメインマシンはIIcxである。Daystarの030-50MHzアクセラレータを入れてあるのでIIfx相当のパフォーマンスはでている(いくらか劣るが)。グラフィックを扱わないため、この環境で困ったことはほとんどない。こんな古臭いマシンがいまだにメインで使えること自体がAppleの問題なのかもしれないが。
 コンパイラをCodeWarriorにしたらスピードも速く、ますます高スピードへの要求はなくなってしまった。Windowsでは最新のVisual C++4.0を使うと100MHz Pentiumでも「悲しいくらい重い」そうで、改造IIcx程度で快適な開発環境だということが嘘みたいである。もちろんCodeWarriorは最新である。

 Nifty-Serveのログを読むのに茄子(実際には茄子R)を使うのに慣れ切ってしまっていた。完全に生活の一部となっていた。そういう人は多いと思う。しかし、安定性に欠けるため、使った後に再起動しなくては安心できない点が問題であった。プログラミング関連の発言を参照しながらプログラミングできないのだ。これは苦痛であった。そこで實篤を開発することに決めた。
 安定した茄子の開発は誰かがやらねばならないとずっと思っていたのだが、たまたま最初に痺れを切らしたのが私だったということだ。それだけだ。

 實篤はフリーソフトとして始まったし、私もそれでいいと思っていた。しかし、このプロダクトは今までの私のプロダクトに比べかなり社会性が高いということに気がついた。もちろん発表された全てのソフトウエアは幾らかの社会性を持つのだが、「安定した茄子」を開発するという必然性は本来私にはないという意味で、實篤は私個人の勝手気ままなプロダクトとは違うと気がついた。
 社会性というのはある種の責任である。せっかく茄子互換ブラウザを作ったのだから、さらにそれを有効なツールに仕上げるべきだ。そう、PowerPC化である。
 社会性をさらに押し進めると、PowerPC化をすべきだという新たな目標が明らかになってきた。開発者がPowerMacintoshを持っていないがためにPowerPC化できないなんてあまりにばかばかしい。

 PowerPC化することで私は何も恩恵は受けない。私自身にはPowerPC化する必然性は全くない。それでもPowerPC化をすべきだと考えると、これはコストを受益者負担とするのがスジであろうと思う。
 實篤および関連ツールのシェアフィーはPowerPC化のために使われることになる。具体的には開発者である私の手元にPowerMacintoshおよび関連資料がなくてはどうにも進まないということだ。

 蛇足。
 そうそう、オリジナル茄子作者の小倉さんは茄子が完成したらシェアウエアにしようとしてましたね。彼自身の手で完成できなかったことはつくづく残念です。
 私がこのプロダクトを放棄するときは先例にならってソースの公開をしようと思う。過去の放棄された重要なプロダクト(商品を含む)は全てソースを公開すべきだと思うんだがなぁ。そうもいかんか。

1996.08.24

関係各位

■ 米木 武と中野 里美の入籍をネタにした大宴会

1996年10月19日に下記の要領で大宴会を行ないますので、是非ご参加ください。ビンゴはやりません。カラオケは禁止です。間をもたすアトラクションは全く用意しません。司会もいません。各グループで久しぶりに集まって勝手にご歓談ください。元「たなか」のメンバーはフォークギターを持ち込もう。尾形と若林も何か頼む。乾杯はもちろんナカジーしかいない。

■ 日時

 1996年10月19日土曜日
 開場:午後5時30分
 開始:午後6時

■ 場所

 新宿歌舞伎町「歌声喫茶カチューシャ」
160 東京都新宿区歌舞伎町 1-13-2
TEL: 03-5273-4276

■ 会費

 6000円

■ インターネット(または伝言ゲーム)方式連絡網 敬称略
ルート   ノード
米木 -+- 新井 彼方などの関係
      +- 小川 理創、旧理創関係
      +- 丸山 関東の新潟関係
      +- 斎藤 新潟関係
    * +- 小松 幹事、通信関係
      +- 村山 ソニー関係
      +- 蜂屋 大学関係
      +- 米木 縁戚関係
勝手に決めました。ご協力お願いします。

ルートからの最初のノード(ドメイン)の一覧です。各ノードから先のノードは各自決めてください。規模が小さい場合はフラットなモデルでも良いでしょう。新井、小川、斎藤はそうでしょう。

要領はチェーンメール(不幸の手紙)そのものです。違いは終端が存在することです。「たぶんあいつには連絡が行ってないだろう」と思われる場合は自発的にサブノードになってください。蜂屋は若林や山川には連絡が取れても宮坂には取れないんじゃないかな。そういうことです。誰か里の居場所知ってるか? 松島は? 堀内はまだ米国か? 青木を忘れるなよ(^^)。

幹事の役割は当日の集金です。規模から考えて入口での徴収になるでしょう。誰か有志に手伝ってもらいたいのですが、ソニー関係はいかがですか? 幹事は横浜在住独身です(あんまし関係ないか)。ハンサムではないんでそのへんは期待しないように(^^;)。

蜂屋はたくさんサブノード作らないとやってられないだろう。旧三人娘には平野または水谷をサブノードにするのが現実的。みんな蜂屋に協力してやってくれ。佐々木祐の連絡先は知ってるかな。パラランは九州なんで来ないだろうけど、連絡先教えるぞ。蜂屋は池田を自由に使う許可を与える。使えないかぁ。洋ちゃんあたりも協力を請う。

マルさんから伊藤(敬)へは連絡つくのかな。あいつへは連絡がつかんという情報もルートへ返して貰えると嬉しい。伊藤はエビにつけるんだぞ。

新井クンは久保寺さん(偽名)にちゃんと連絡してください。Mには連絡取れるかどうかはなんともいえないな。

小川さんは石西、木村、中西さんと連絡つくかな? 飲めなくても後藤クンは誘おう。

「オレ正式に連絡受け取ってない」なんていうバカなことは言わないこと。正式な連絡は存在しないのだから。なんらかのルートで嗅ぎつけたらどこかのノードまたはルートにレスポンスすること。私が呼ぶのでなくあなたが来るのです。

村山さんの範疇はE-Mailがきくので楽そう。一応連絡範疇は村上、伊藤(AC)、山口、松井(旧PAW)、新田、上村(他部署)さんなどを含みます。島どんや進藤さんはもちろん。そうそうソニーにいる理創関係も含んでください。

典子さんは東京見物のきっかけが欲しいのでしょうから、利用してください。

人数確認が目的なんで、連絡は必ずするように。

実費はルートに請求しましょう。

各ノードはこの文面をコピーして、あと別に付加情報でも添えて配布してください。
電子ファイルで欲しい人はルートの米木に連絡をしてください。電子メールなら簡単ですし、DOSまたはMacintoshの形式ならフロッピーでも渡せます。

■ 集める情報

必須情報
1.参加の可否と人数
オプション
2.住所
3.電話番号
あれば
4.電子メールのアドレス

■ タイムテーブル

各ノードは9月19日までにルートの米木まで経過を知らせてください。各人はそれが可能なように各ノードに連絡をするかルートに直接連絡するかしてください。
各ノードは10月1日までに最終集計をお願いします。これが会場の予約人数になります。
微調整は10月16までにします。土壇場で来れなくなってもともかく連絡だけはお願いします。ギリギリの予算でやりますので、人数は正確に把握しなくてはいけません。

1996.08.30

注:
 宴会は盛況でした。FMACPROからはBergさん夫妻が参加してコンドームをプレゼントしてくれました。おいおいそっちも新婚だろうよ。

CAppleObjectを継承するクラスで実装しなければならない関数

CAppleObjectを継承するクラスは各自実装しなくてはいけない仮想関数を持つ。
ただし、完全に全て実装しなくてはいけないわけではない。
デフォルトの動作のままで良いことも多い。

ここで使われる「番号」は「順序数」であり、formAbsolutePositionで有効な
値でなくてはいけない。
すなわち、番号でのアクセスは1〜となる。
Windowはウィンドウメニューの並びではなく画面上の前後関係(Zオーダー)
である。

各オブジェクトのデスクリプタタイプを返す
virtual DescType GetObjectType();
	アプリケーション独自の型(bbsとかforumとか)ならば、クラスとタイプは
	一致するのだが、例えば「名前」なんてのは'cnum'で'TEXT'なので、こういう
	場合は'TEXT'を返す。というか'TEXT'しか返せないであろう。「名前」の
	ためのクラスを用意するわけではないのだから。
	エレメントはクラスとタイプが一致してプロパティは一致しない傾向があるが、
	厳密なことではない。オブジェクトスペシファイアを作成する時に参照されるが
	確実な実装かどうかはなんともいえない。
	各クラス独立なので必須。

各オブジェクトの名前を返す 名前のないクラスはありえる
virtual char *GetObjectName();
	最初はchar *でなくCStringで実装したが、CString自身をCAppleObjectの
	サブクラスにできないとわかり、結局char *にした。そんなわけで、この
	仮想関数で返す名前はスタック(自動変数)ではいけないことになる。
	オプションだがエレメントは必須に近い。

オブジェクト自身の順序数を返す
virtual long GetObjectNumber();
	通常は親オブジェクトにリスト管理されているであろうという前提で
	デフォルトでm_containerに対するGetOrder(this) + 1を返している。
	cWindowはZオーダー。
	エレメントは必須だが、通常デフォルトで良い。

任意のオブジェクト番号を得る(カレントを意味してもよい)
virtual long GetAnyContainedObjectNumber();
	本来ランダムな値を返すものと決まっているが、当面実装としてカレントを
	意味するようにしたいと思う。
	一応例えばApplicationのプロパティにcurrent bbsといったものを用意する
	ことで、極力これは使わないようにしたい。

順序数で含有オブジェクトを得る
virtual CAppleObject *GetContainedObjectByNumber(
	DescType desiredClass, int n);
	通常は親オブジェクトにリスト管理されているであろうという前提で
	デフォルトでGetNth(n - 1)を返している。
	cWindowはZオーダー。
	エレメントは必須だが、通常デフォルトで良い。

含有オブジェクトをキーで引っ張る
virtual CAppleObject *GetContainedObject(
	DescType desiredClass, DescType keyForm, const AEDesc *keyData);
	オブジェクトが持っているオブジェクトを返す
	なるべくCAppleObjectの持っているメソッドで解決できるようにしているので、
	これをそのまま使って良い。
	エレメントは必須だが、通常デフォルトで良い。

プロパティを得る
virtual CAppleObject *GetObjectProperty(
	DescType desiredClass, DescType keyForm, const AEDesc *keyData);
	プロパティを持つクラスは必ずこれを実装しなくてはいけない。
	エレメントは必須。

含有オブジェクトの数を得る
	virtual long CountContainedObjects(DescType desiredClass);
	エレメントを一種類しか持たないクラスはデフォルトのGetCount()のみで良い。
	エレメントは必須だが、通常デフォルトで良い。

オブジェクトの比較
	virtual Boolean CompareObjects(DescType oper, CAppleObject *obj);
	デフォルトではオブジェクトの順序数でのみ比較するように実装しているので、
	それでは意味がない場合はオーバーライドしなくてはいけない。
	エレメントは必須だが、通常デフォルトで良い。

イベント処理
virtual OSErr OnAppleEvent(
	AEEventID eventID, DescType desiredClass, 
	const AppleEvent *aev, AppleEvent *reply);
	各オブジェクトに対するイベントを直接渡す。
	ここの実装がスクリプト対応の心臓部。
	イベントを受け取るクラスは必須。

親へのイベントフック
virtual OSErr OnAdhocForContainer(
	CToken *token, AEEventID eventID, 
	const AppleEvent *aev, AppleEvent *reply);
	目的のオブジェクトにイベントを渡すだけでは動作として完結できないことが
	多いため、その親のオブジェクトにもイベントを渡す。
	例えば名前の変更は文字列クラスに直接行くが、それを画面やファイルに反映
	させる権限(というか方法)はその親クラスにしかないのが通常。
	イベントを受け取るクラスの親クラスはほぼ必須。

オブジェクトスペシファイアを得る
virtual OSErr GetObjSpecifier(DescType desiredClass, AEDesc *objSpec);
	この実装では順序数での指定となる。
	create elementの戻り値などで使うオブジェクトスペシファイアを作るが、
	通常はデフォルトの実装で良いと思われる。違ったオブジェクト間の同じ
	メソッドという再帰なんだか違うんだか良くわからない実装になっている。
	内部的にクラスが存在しても、スクリプトに現れないものはGetObjSpecifierで
	通り抜けをさせなくてはいけないのでThroughObjSpecifierというメソッドを
	用意している。
1996.09.06

 9月2日の朝、練馬区役所に婚姻届を提出して、COCO姉ちゃんと私の新婚(貧困)生活が始まった。お金がないなぁ、部屋の契約料と引っ越し代がでかかった。家賃も結構負担だ。部屋はいまだに片付いていない。
 ウチの会社で契約しているプロバイダを使ってWindows 95のInternetExplorerでのPPP接続をしてみた。そんなに悩むことなくつながった。これで筒井康隆の越天楽(http://www.jali.or.jp/tti/)が読める。
 COCO姉ちゃんの会社のAT互換機Acerが初期不良だとかで、逼迫している仕事ができなくなったため、1.6GByteのIDEディスクを買ってきて私のAT互換機PC-DIRECTに突っ込んだ。
 んで、ディスクが広がり、お姉ちゃんの仕事も一段落付いたので、Windows 95のシステムを広がったディスクの方に再インストールすることにした。一部困ったこともあったが再インストールはなんとかなった。
 問題はPPPである。ダイアルアップで接続できなくなってしまった。きちんとTCP/IP関連の設定を全部見直さないといけない。まいったなぁ。
 ウチの会社を含む複数の会社が共同で設置したサーバで勝手に始めたホームページの実験も、このPPP接続が解決するまでは手が付けられない(http://www.akinai.or.jp/riso/ostra/)。

 借りてたPS版「Dの食卓」をやっとやった。やり始めて気付かされたのは、「MYST」タイプのアドベンチャーゲームが大嫌いだということだ。うざったいユーザインターフェースと脈絡のないパズルの組み合わせという意味でだ。グラフィックは凄いけど、結局はゲーム性を求めてしまうからやっててどんどん腹が立つ。いや、別に「MYST」や「Dの食卓」が悪いゲームだと言っているのではない。私との相性が悪いだけだ。
 SS版の「ダークシード」なんかに比べればきちんと終われるし、部分的には楽しめるという意味では良質のゲームなのかもしれない。売れたしね。

1996.09.17

退職願

 私、この度一身上の都合により退職いたしたくお願い申し上げます。

平成8年10月14日
米木 武

注:
 転職しました。職種は変わりません、やはりプログラマです。3年におよぶSONYへの出向が終了したのをきっかけに職場を変えました。
 転職先は中村Showさんがいるところだと言えばわかる人にはわかるでしょう。

 昨日、1996年10月19日にCOCO姉ちゃんとの入籍披露大宴会を行った。宴会の出席者でこの文書を読む人はごく少数であろうとは思うが、出席ありがとう。OSTRACISM CO.の2年半ぶりのステージでもあったのだが、やはり反応のあったのは(歌を知っている)大学と新潟のグループのみだった。中村が「なんであいつら手拍子すらしないんだ」と怒っていたが、普通の反応はあんなもんだ。そもそも新郎の付き合いの中に軽音楽サークルがあるなんて思いもよらなかったわけだから。

1996.10.20

 COCO姉ちゃんの会社の営業さんが販売店まわりをしているときに某所の某ゾーンで「どうですかぁ?」と言われた店頭品の100MHzペンティアムマシンが11月2日我が家にやってきた。5万円である。結婚のお祝いに昔の同僚から貰った16ポートの10 Base-T Hubに接続するため同日\3500でNE2000互換Etherボードを買ってきた。ケーブルは\760である。
 100MHzペンティアムマシンはマイクロン製(なかなか良いメーカです)で、まだ日本法人のなかった頃のものだが、そんなことはどうでもいい。16MByteメモリだったので余ってた4MByteを2枚加えて24MByteにした。これだけあればLinuxを動かすのに問題は全くない。
 Etherボード、サウンドブラスタ、ビデオカード、ATAPI CD-ROMすべてきちんと認識した。Linuxを動かすならPlug & Playに対応していない頃の製品が良い。BIOSでもPlug & Playは切っておいた。ちょっとX Windowで問題があるが、古いS3のビデオチップではしかたがないようだ。
 んで、sambaとnetatalkを入れた。sambaはMicrosoft Network(LanManager)互換のdaemonで、netatalkはAppleTalk互換のdaemonのこと。これでマイクロンマシンはマックとWindowsの両方から見えるサーバになった。もちろんLinuxからはNFSで見える。これで68Kマック、PPCマック、Windows95、Linuxで本格的なLAN環境ができ上がった。完全に孤立しているのはEtherNetの使えないClassic IIとPlusのみだ(めったに使わないしなぁ)。プリンタの共有もできていない(セントロとシリアル両方端子があるので実用上の問題は少ない)。
 あ、DEC HiNote UltraもまだLANからは孤立している。こいつはメモリ入れてEtherカード買ってやらねばなぁ。

1996.11.07

 GripGropの最大の問題点に、ヒットしたアイテムのリスト表示の大きさがある。普通にListManagerを使うと文字列の合計が32KByteに制限されてしまうのだ。これは案外小さなサイズで、たとえば1行80文字だとすると400件程度であふれてしまい、全部リスト表示できなくなってしまう。実際多くのアイテムがヒットする検索では実用上に問題があることになる。
 そこで、LDEFを書くことにした。ListManagerに渡すデータを文字列にするのでなく、文字列のポインタにするのだ。これで32KByte / 4 = 8192と約8000件までは問題なく表示できる。これでだいぶ制限は緩和される。8000件以上必要ならポインタでなく整数をおくようにして、データアクセスの方法をrefConあたりを使って工夫することになるが、実際8000件あればもう良いだろうと思われる。
 藤本さんの書いた「THINK C プログラミング講座」を引っ張り出してきてLDEFの書き方を調べた。なんとも簡単なものだとわかった。Inside MacintoshではIVに説明があるが、2ページ足らずであった。こんな程度なのね。
 リストアイテムを描画しなさいというメッセージがLDEFに来るのだが、描画すべきRectは引数で与えられる上に、portがカレントになっていてvisRgnまできちんと設定されている。LDEFの役割はただただ描画するだけだ。
 データ長0のときは信頼できるデータがはいっていないということに気づくまで多少悩んだが、ともかく文字列ポインタLDEFが出来上がった。
 そんなわけでGripGropは8000件まで対応可能となった。デフォルトのヒープサイズではそもそも8000件も表示できないと思うので、たくさんヒットするような検索をする人はアプリケーションに与えるメモリサイズを適宜増やしましょう。

1996.11.11

 COCO姉ちゃんのマシンを使ってGripGropのPPC化が済んだ。必須AppleEventの部分をUPPに直しただけできちんと動作した。クラスライブラリはSaneatsuでPPC対応してあったので、GripGropでは非常にすんなりいった。
 ただ、PPCネイティブになってもSystem 7.5.3ではほとんどスピードの違いは出ない。結局68Kエミュレーションの速度向上が優秀だということだろう。また、GripGropの処理は大部分ファイルI/Oなのでエミュレーションだろうがネイティブだろうが負荷には差がないともいえる。
 System 7.1.2あたりで試すと違いが出るんだろうかなぁ。
 PPC版のGripGropは、「PPCネイティブで環境を揃えたい!」というあまり意味のない欲求を満たすだけの存在なのかもしれないね。

 GripGropをPPC化する前にSaneatsu LiteのPPC化を行った。これは68Kエミュレーションに比べるといくらか体感速度も向上している。PPCならばスクリプト対応で重くなった分よりはスピードが向上すると思われる。
 PPC化で最も手間取ったのはUniversal Proc Pointerだ。今まではCallback関数を単純に指定していたが、UPPを作成してそれを渡さなくてはいけない。最初勘違いしており、キャストしておけば勝手に解釈されると思っていた、が、それは間違い。きちんとUPPを作らなくてはいけない。また、そのCallbackを使う間UPPをDisposeしてはいけない。このDisposeに関しても勘違いしていた。おかげで例外1111が起きまくった。
 結局UPPを扱うクラスを用意した。少なくともDisposeは自動化したかったからだ。
 スクリプト化とPPC化を終えて、ともかくここしばらくの目的は達成されたことになる。GripGropを整えたらいよいよリリースだ。

1996.11.12

 Performer 6400シリーズは久しぶりに筐体の気に入った純正マックだ。マック互換機ではUMAXの筐体も気に入っている。UMAXマシンがほしいなと思っているが値段がとてつもなく安けりゃPerformerでもかまわない。ゴミモニタが付属しちゃうなら選択肢にはならないが。
 しかしPerformer 6400シリーズのスペックを調べると、いまだビデオメモリが1MByteのままだ。なんでこういうことするかねぇ。17インチモニタで16bitカラーってのがあたりまえの時代じゃないのかね。イーサネットもないしなぁ。
 ワールドPCエキスポでUMAXのお兄ちゃんが言っていた「秋にでるAppleのPerformerのマザーボードを使った20万円台のマシン」ってのはPerformer 6400シリーズを元にしたものであろう。UMAXなら差別化のためビデオメモリを2MByte積んでくれるかもしれないが、オンボードで拡張できないビデオだと不可能だともいえる。どうなるかな。
 いまだ店頭でUMAXマシンを見たことがない。探せばあるのだろうか。
 奇数の年はマシンを買うことになってる(^^;)のだが、PowerMacやめてBeBoxにしようかなぁ。あ、でも今年はひょんなことから安くAT互換機を買ったんだった。ついに10年目にして例外が発生したか。

1985 TOSHIBA MSX
1987 SONY HB-F900 MSX2
1989 APPLE Macintosh Plus
1991 APPLE Macintosh IIcx
1993 APPLE Macintosh Classic II
1995 PC-DIRECT 550Si P5-100MHz
1996 MICRON Millennia P5-100MHz

1996.11.13

 CW10でGripGropをメイクしたらCW9に比べ実行モジュールがかなり大きくなってしまった(PPC版)。何が変わったんだろう。いまさらCW9を入れ直して調べる気にはならない。なんか変だなぁ。シンボルは抜いてあるよなぁ。

1996.11.14

 さあて、次はGripGropのスクリプト対応とHUNDOSHI-EDITのPPC化だぁ。

1996.11.18

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