このページは福井県立大学の田中求之が2006年1月まで運用していた Mac のサーバ運用に関する会議室 「Web Scripter's Meeting」の記録です。情報が古くなっている可能性がありますのでご注意ください。

WSM WatcherをMac OS Xで

発言者:よしもと
( Date Friday, September 28, 2001 13:15:20 )


10.1も明日配布ということで、Mac OS Xへの移行も加速するんじゃないかと
思ったりする今日この頃ですが、WSM WatcherをMac OS Xネイティブな環境
で使えたら良いなぁと思ったりしています。

で、どうするのが良いかなんですが、

(1)RB 3.5.1でコンパイルして、使い物ならなくても使う(笑)
(2)適当なプラグインを探してきて、それも用いて3.5.1で
 作り直す。
(3)Cocoaでスクラッチから書き直す

くらいの候補があるんですが、どうなんでしょうねぇ...

田中求之 さんからのコメント
( Friday, September 28, 2001 13:25:30 )

WSM Watcher の仕様は無茶苦茶シンプルなんで、おそらく Cocoa で書き直すのが
早いと思います(私はまだ Cocoa に馴染んでないので無理だけど…)

REALbasic は、私は 2.x でアップグレードを止めているので(品質とコスト
を天秤にかけた結果の結論)、対応できません。XFCN の部分を全部書き直して
あと、NthField の高速化を図れば、たぶん、動かせるとは思いますが…


個人的には、「ターミナルで使える or Emacs で動かせる」プログラムを
書くって言うのが OS X っぽいかなと(笑)(あ、ターミナルってまだ
日本語無茶苦茶なんだったけ?)

Perl で書いちゃうっていうのも汎用性があっていいかも (^_^;;


とりあえず、仕様をまとめたものを、このあとポストしますんで、腕に覚えのあるかた、
あるいはネットワーク・プログラミングの練習としてやってみたい方、やって
みてください。

よしもと さんからのコメント
( Friday, September 28, 2001 16:14:58 )

やっぱりそうですよね。僕もやってみたいんだけど、なかなか時間が
取れなくてぇ。

> あ、ターミナルってまだ日本語無茶苦茶なんだったけ?

僕が試した限りは、10.1でも駄目ですね。まあ、この辺りは根深いものが
あるんで、なかなか一席一丁では行かないようですが...

> Perl で書いちゃうっていうのも汎用性があっていいかも (^_^;;

インターフェイスの部分がねぇ。Perl-Gtkとか使えれば良いんですが :-)

> とりあえず、仕様をまとめたものを、このあとポストしますんで、

はい、お手数かけます。

#誰かやってみない?テスター位はやらせていただきますかぁ :-)

田中求之 さんからのコメント
( Friday, September 28, 2001 16:56:49 )

この際、自分でも忘れないように(笑)、ちゃんとまとめておきたいと思い、
文書を書いてますんで、仕様の公開は今夜中には、ってとこです。

まぁ、Telnet を使って

http://mtlab.ecn.fpu.ac.jp/webcon.mtxt$last?raw
(これは始めて使用したときのアクセス)

あるいは

http://mtlab.ecn.fpu.ac.jp/webcon.mtxt$last?010928000000
(これは 2001年09月28日00時00分00秒以降にポスとされた発言のリクエスト)

へアクセスして、帰ってくるデータを眺めてもらえば、だいたいのことは
わかると思います(文字コードは SJIS です)

田中求之 さんからのコメント
( Friday, September 28, 2001 22:34:51 )

Inside WSM Watcher

田中求之(mact@antares.ecn.fpu.ac.jp)

2001年9月28日

●この文書について

この文書の目的は Web Scripter's Meeting のアクセス用のソフトウェアであ
る WSM Watcher の使用を解説することにある。

WSM Watcher
<http://mtlab.ecn.fpu.ac.jp/wsm_watcher/>
(最新版は v1.4 である。REAlbasic 1.x のプロジェクトも公開している)

WSM watcher は、Web Scripter's Meeting へのアクセスの便宜を図るために作
成されたアプリケーションである。アクセス専用のソフトウェアになっている
が、サーバとの交信は通常の HTTP を用いて行われるようになっており、独自
のプロトコルなどは用いていない。このため、以下に述べる仕様にしたがって
作成されるソフトウェアであれば、OS や環境に関係なく、WSM Watcher 同様の
アクセス環境を提供することが可能になる。実際、筆者は AppleScript で 
URL Access Scipting を利用したファイルメーカー Pro 版のクライアントを作
成したことがある。

FM_WSM_Watcher.sit
<http://mtlab.ecn.fpu.ac.jp/mySamples/FM_WSM_Watcher.sit>

誰であれ、この文書で述べられる仕様を利用して Web Scripter's Meeting へ
のアクセスツールを作成して構わない。また、作成したツールを公開・配付す
るにあたっても、一切の制限を設けないので、各自の自由にしてもらって構わ
ない。ただし、ここに説明する仕様を悪用して Web Scripter's Meeting の会
議室を荒らすツールを作成することも可能であるが、そのようなツールの使用
が認められた場合には、予告なく仕様の変更を行なったり、場合によっては、
アクセスのインターフェース自体の廃止を行なうこともありうる。筆者のサイ
トは、オープンであることを優先にし、その代わりにセキュリティなどの点に
おいてある種の脆弱性をはらんだものになっている。いうなれば、無担保の信
頼に基づいて運用されている。この原則を変えるつもりはないが、問題が生じ
た場合には、しかるべき処置をとるつもりである。この点は留意していただき
たい。

以下の順序で説明を行なう。

1:サーバ・クライアント間のインターフェース
2:サーバ側の実装
3:クライアントの実装例(WSM Watcher の基本的な仕組みの解説)


●サーバ・クライアント間のインターフェース

1:ホスト、ポート、プロトコル

サーバは mtlab.ecn.fpu.ac.jp (157.6.48.132) である。ホスト名、IP アドレ
スのどちらを用いてアクセスを行なってもよい。

使用するポートは 80 で、プロトコルは HTTP である。


2:リクエスト

WSM Watcher の処理は、Web Scripter's Meeting の処理を行なっている CGI 
が受け持つようになっている。このため、path_args を使って WSM Watcher の
アクセスであることを明示するする必要がある。キーワードは last である。
WSM watcher のアクセスの場合には、必ず、path_args は last になっている
必要がある。

また、WSM Watcher は、初回のアクセスの場合を除いて、クライアントが 
http_search_args を用いてメッセージの検索を行なう起点となる日時を指定す
るようになっている。日時の指定は12桁の数字からなる Timestamp を用いる。
これは YYMMDDHHMMSS のフォーマットで日時を表したものである。たとえば、
2001年9月28日21時59分25秒は 010928215925 と表される。WSM Watcher では、
日時のデータはすべてこの Timestamp 形式で処理するようになっている。なお、
時間はすべて日本標準時(JST)である。GMT への変換は必要ない。


WSM Watcher によって初めてアクセスを行なう際には、以下のように、
http_search_args に raw という文字列を渡す。これにより、サーバは、アク
セスがあった時点から過去2日間(48時間)に投稿されたメッセージをリプラ
イで返すようになっている。

http://mtlab.ecn.fpu.ac.jp/webcon.mtxt$last?raw

つまり、mtlab.ecn.fpu.ac.jp のマシンに TCP でポート 80 にコネクトしたら、
クライアントはサーバに対して以下のリクエストを発行することになる。

GET /webcon.mtxt$last?raw HTTP/1.0<CRLF>
Host: mtlab.ecn.fpu.ac.jp<CRLF>
<CRLF>

2度目以降のアクセスの場合は、前回のアクセスを行なった日時を 
http_search_args に渡す。これを受けてサーバは、http_saerch_args で指定
された日時以降に投稿されたメッセージをリプライするようになっている。
サーバ側ではクライアントに関する記録は一切行なわない。アクセス日時の記
録や管理は、すべてクライアント側の責任になる。

以下に記すのは2001年9月28日21時59分25秒以降に投稿されたメッセージを請求
する場合のリクエストである。

http://mtlab.ecn.fpu.ac.jp/webcon.mtxt$last?010928215925

つまり、mtlab.ecn.fpu.ac.jp のポート 80 にコネクトしたら

GET /webcon.mtxt$last?010928215925 HTTP/1.0<CRLF>
Host: mtlab.ecn.fpu.ac.jp<CRLF>
<CRLF>

というリクエストをサーバに送ることになる。

(続く)

田中求之 さんからのコメント
( Friday, September 28, 2001 23:48:22 )

3:リプライ

リクエストを受けたサーバは、クライアントに対して、以下のような形式のリ
プライを返す。

HTTP/1.0 200 OK
TimeStamp: 010928163707

<LIST>
<DATA>
メッセージ
</DATA>
<DATA>
メッセージ
</DATA>
....
</LIST>

ヘッダ部分(<LIST> の手前まで)の改行コードは CRLF である。

ヘッダのうち、timestamp ヘッダは、サーバがリクエストの処理を行なった日
時が Timestamp 形式で示されている。クライアントは、このヘッダの値を記憶
しておき、次回のアクセスの時点で、このヘッダの値をリクエストの 
http_search_args に用いるようにすれば、メッセージを取りこぼしなく受け取
れることになる(サーバの時計を基準にすることになるため、サーバとクライ
アントの時計が同期していなくても、処理上の誤差がほとんど生じないことに
なる)。

もしリクエストの http_easrch_args で日時が指定されており、指定された日
時以降に投稿されたメッセージが無かった場合には、サーバは以下のようなヘッ
ダを返す。

HTTP/1.0 304 Not Modified
TimeStamp: 010928163707

これを受け取ったクライアントは、timestamp の記録だけを行ない、メッセー
ジリストなどの更新は行なわないことになる。

なお、AppleScript の URL Access String を用いてアクセスを行なった場合、
ヘッダの値を得ることができない。このような場合には、クライアント側で時
間の管理を行なうと共に、帰ってきたリプライの content が空かどうかで、新
しいメッセージがあったかどうかの判定を行なうことになる。

リプライの content として、メッセージが送られてくる。メッセージは、
<LIST>と</LIST>によって挟まれたものになっており、各メッセージは
<DATA>と</DATA>のタグで挟まれている。

メッセージは、発言ごとに別れており、投稿された時系列で送られてくる(古
いものが先)。

各メッセージは、以下の形式になっている。各要素はタグによって分けられて
いる。

<DATA>
<DATE></DATE>
<URL></URL>
<ANCHOR></ANCHOR>
<TITLE></TITLE>
<NAME></NAME>
<MESSAGE></MESSAGE>
<SERIAL_NUMBER></SERIAL_NUMBER>
</DATA>

<DATE> は、メッセージが投稿された日時が文字列で収められている
<URL> は、メッセージが記録されているページの URL になっている
<ANCHOR> は、そのメッセージのページ内でのアンカータグの値
<TITLE> は、メッセージの収められているページ(話題)のタイトル
<NAME> は、メッセージの発言者
<MESSAGE> は、メッセージの本文
<SERIAL_NUMBER> は、WSM watcher での処理上の識別番号

その発言が新規の話題の投稿(話題の最初の投稿)であった場合には、
<ANCHOR> は空になっている。

また、参考ページおよび参考 URL は、<MESSAGE> の中に埋め込まれる。

漢字コード(文字コード)は SJIS が用いられる。また、タグを使って要素を
識別するようになっているため、本文などは、すべて HTML 表記になっている
(たとえば > は &gt; になっている)。


以下は、メッセージの実例である。

例1*新しい話題の投稿の場合

<DATA>
<DATE>09/28 13:15</DATE>
<URL>http://mtlab.ecn.fpu.ac.jp/webcon.mtxt$010928131520.html</URL>
<ANCHOR></ANCHOR>
<TITLE>WSM WatcherをMac OS Xで</TITLE>
<NAME>よしもと</NAME>
<MESSAGE>10.1も明日配布ということで、…
 (省略)
くらいの候補があるんですが、どうなんでしょうねぇ...</MESSAGE>
<SERIAL_NUMBER>010928131522</SERIAL_NUMBER>
</DATA>

例2*コメントの場合

<DATA>
<DATE>09/28 13:25</DATE>
<URL>http://mtlab.ecn.fpu.ac.jp/webcon.mtxt$010928131520.html</URL>
<ANCHOR>010928132529</ANCHOR>
<TITLE>WSM WatcherをMac OS Xで</TITLE>
<NAME>田中求之</NAME>
<MESSAGE>WSM Watcher の仕様は無茶苦茶シンプルなんで、…
 (省略)
みてください。</MESSAGE>
<SERIAL_NUMBER>010928132532</SERIAL_NUMBER>
</DATA>

例3*参考ページがある場合

<DATA>
<DATE>09/28 16:08</DATE>
<URL>http://mtlab.ecn.fpu.ac.jp/webcon.mtxt$010925133349.html</URL>
<ANCHOR>010928160827</ANCHOR>
<TITLE>EasyBBS DX 5 ベータ</TITLE>
<NAME>田中求之</NAME>
<MESSAGE>DX 5 GM1 です。
 (省略)
→  <a href="http://mtlab.ecn.fpu.ac.jp/mySamples/EasyBBS_DX_5_GM1.sit">EasyBBS_DX_5_GM1.sit (784K)</a>
</MESSAGE>
<SERIAL_NUMBER>010928160830</SERIAL_NUMBER>
</DATA>


例1は新規の話題の投稿なので <ANCHOR> は空になっている。それに対して、
例2はコメントなので、<ANCHOR> には 010928132529 という値が入っている。
つまり、例2のメッセージは、Web 上においては

http://mtlab.ecn.fpu.ac.jp/webcon.mtxt$010928131520.html#010928132529

という URL でアクセスできる発言であることを意味している。

また例3のように参考ページのリンクがあった場合には <MESSAGE> の最後の部
分に

<改行>
→  <a href="参考URL">参考ページ名</A><改行>
</MESSAGE>

という形式でリンクが追加されるようになっている。


なお、<ANCHOR> は、サーバが書き込みをページに追記した時点の日時が 
timestamp になったものであり、また、<SERIAL_NUMBER> は、サーバが WSM 
Watcher のデータを生成した時点の timestamp になっている。このため、
timestamp を文字列で比較を行なえば、古いものほど前になることが保証され
ている。これを利用すれば、メッセージやコメントの時系列を確認することが
できる。

また、サーバ側の処理がマルチスレッドでは行われないため、<ANCHOR> や 
<SERIAL_NUMBER> の値(あるいは話題が書き込まれるページのファイル名)は、
かならず一意になることが(事実上)保証されている。これを利用すれば、た
とえば各発言の <SERIAL_NUMBER> の値をチェックすることで、重複して取り込
んだメッセージがないかどうかを確認することが可能になっている。


リプライに関するポイントをまとめておくと以下のようになる。

●リプライはステータスヘッダ+Timestamp ヘッダをヘッダとする。メッセー
ジがあった場合はステータス 200 が、該当する新規のメッセージが無かった場
合には 304 が示される。クライアントは Timestamp ヘッダの値を記録してお
くことで、次回のアクセスの際に重複無くチェックを行なうことが可能になる。

●メッセージが存在した場合には <LIST> タグに挟まれたデータとして送られ
てくる。漢字コードは SJIS である。

●各メッセージは <DATA> タグで挟まれており、メッセージの各要素もタグに
よって識別できるようになっている。このため、メッセージは HTML にエン
コードされている。

●メッセージの <SERIAL_NUMBER> は一意の値になることが事実上保証されてお
り、また、この値は Timestamp であることから、昇順ソート(文字列で、ある
いは数値に変換した上でのソート)の際には古いメッセージのものほど上位に
来ることが保証されている。これを利用して、メッセージの時系列管理や重複
チェックが行なえる。

(続く けど、基本的なインターフェースはこれで解説は終わり)

重松修 さんからのコメント
( Saturday, September 29, 2001 02:20:41 )

今 Mac OS X で WSM Watcher を使っています。
後で、ソース一式アップしておきます。

気づいた問題点としては、
  * コントロールのサイズの調整が必要あり。
  * Preferences... の場所を OS X と Classic で切り替える必要あり。
  * アイコン (OS X) の作成が必要あり。
という程度ですので、とりあえず、使うことはできるかと思います。

よしもと さんからのコメント
( Saturday, September 29, 2001 12:41:25 )

重松さん、どもです。

おお、それはすばらしい。
RB 3.Xですか?是非使わせてくださいです。

それから、田中さん解説どうもです。これって、別にしてWSM Watcherの
ページ辺りに置くと良いなと思うんですが、どうですか?

#完成してからかな?

田中求之 さんからのコメント
( Saturday, September 29, 2001 13:43:39 )

お、さっそく対応版が出ましたね。

なお、この文書は、修正の上、ページとして公開します。とりあえずの速報
っていうか草稿ってことです。では、続き(そろそろページの容量に達するかな?):

4:コメントの投稿

クライアントからコメントを投稿する場合は、Web 上での書き込みと同じリク
エストを送る。WSM Watcher 用の登校用のインターフェースは設けられていな
い。

●メッセージの生成

コメントの場合は、ブラウザで以下の FORM に記入を行なって送信する場合と
同じ処理を行なう必要がある。

<FORM METHOD="POST" ACTION="/webconcmt.mtxt$000000000000.html">
発言者:<INPUT TYPE=TEXT NAME=name SIZE=40>
メッセージ:<TEXTAREA NAME=comment COLS=70 ROWS=10></TEXTAREA>
参考ページ名:<INPUT TYPE=TEXT NAME=Ref SIZE=40>
参考 URL :<INPUT TYPE=TEXT NAME=URL SIZE=50 VALUE="http://">
<INPUT TYPE=SUBMIT VALUE="Post">
</FORM>

METHOD は POST を用いる

ACTION は "/webconcmt.mtxt$" + ページのファイル名 になる。サーバから送
られてきたメッセージの <URL> 中に示されているファイル名($ の後ろ)を取
り出して用いることになる。

たとえば

<URL>http://mtlab.ecn.fpu.ac.jp/webcon.mtxt$010928131520.html</URL>

の場合、ファイル名が 010928131520.html になるので、ACTION は

/webconcmt.mtxt$010928131520.html

を指定することになる。

各フィールドに記入されたデータは URL 形式に変換して POST 用のメッセージ
へと仕立てる必要がある。

たとえば

発言者:[田中求之]
メッセージ:[これは WSM Watcher の解説]
参考ページ名[]
参考 URL :[]

という記入が行われた場合、最終的に以下のようなメッセージを作成する。

name=%93c%92%86%8B%81%94V&comment=%82%B1%82%EA%82%CD%20WSM%20Watcher%20%82%CC%89%F0%90%E0&Ref=&URL=

なお、使用する文字コード(漢字コード)は SJIS か JIS が望ましい(EUC に
も対応はしている)。UTF-8 などの Unicode 系の文字コードにはサーバが対応
していないので、この点は注意して欲しい。

●サーバへの送付

実際にサーバへメッセージを送付する際には、以下のような手順でリクエスト
を発行する(010928131520.html というページへ上記のコメントを書き込むと
して説明する)。

まず、mtlab.ecn.fpu.ac.jp のポート 80 へ TCP でコネクトする。

無事にコネクトできた場合には、以下のようなリクエストを送る。

POST /webconcmt.mtxt$010928131520.html HTTP/1.0
User-Agent: WSM Watcher
Host: mtlab.ecn.fpu.ac.jp
Content-type: application/x-www-form-urlencoded
Content-length: 99

name=%93c%92%86%8B%81%94V&comment=%82%B1%82%EA%82%CD%20WSM%20Watcher%20%82%CC%89%F0%90%E0&Ref=&URL=


改行コードは CRLF を用いる。ヘッダとメッセージの間には空行が入る。また、
メッセージの末尾にも空行を追加する(CRLF を2組付けておく)。

User-Agent ヘッダは必須ではないが、できる限り付けるようにして欲しい。も
ちろん、Agent の名前は自分のソフトウェアの名前にしてもらってかまわない
(そうするのが望ましい)。

Host ヘッダも、現状では必須ではない。ただし、今後、サーバ側の設定が変更
された場合にそなえて、このヘッダで mtlab を指定するようにしておくことが
望ましい。

Content-type ヘッダは必ず application/x-www-form-urlencoded を指定する。

Content-length ヘッダの値はメッセージ(書き込みのデータ)のバイト数であ
る。ヘッダは含まないし、末尾に追加する改行コード(CRLF が2組で 4 バイ
ト分)も含まない。


●サーバからのリプライ

無事にコメントが書き込まれた場合にはサーバからステータスコード 302 のリ
ダイレクトの指示が返ってくる。

HTTP/1.0 302 Found
Location: http://mtlab.ecn.fpu.ac.jp/webcon.mtxt$010928131520.htm#000000000000

(#以降の数値は書き込まれた日時次第で変わる)

なお、注意するべき点として、メッセージの発言者か本文が空だった場合にも、
サーバは同様の 302 のリプライを返すようになっている。クライアントは、
サーバへメッセージを送付する前に、発言者と本文が空でないことを確認する
処理を行なうのが望ましい。あるいは、エラーによる 302 の場合には、アン
カー(# 以降の数値)が付かない。それを利用して、事後的にチェックを行な
うことも可能ではあるが、余分なトラフィックを発生させることを避けるとい
う意味でも、投稿処理前にチェックを行なうべきである。


ページの容量が制限に達しており、コメントを追記できなかった場合には、ス
テータスコード 406 のエラーが返ってくる。

HTTP/1.0 406 Not Acceptable

<TITLE>Not Acceptable</TITLE><H1>Not Acceptable</H1>

(*ヘッダは1行で、空行の後に<TITLE>以下のメッセージが content として
ついてくる)

Web 上では、ページを表示する際に、容量を超えていたページには書き込み用
の FORM を付けないという処理を行なっているが、WSM Watcher では、クライ
アント側でページの総容量を確認することが難しいため、このような仕様となっ
ている。現在公開している WSM Watcher では、ステータス 406 が返った時点
で、他のエラー同様に、投稿メッセージは破棄されるが、この仕様は、決して
望ましいものではない。

田中求之 さんからのコメント
( Saturday, September 29, 2001 15:42:12 )

続きです。これでサーバ・クライアント間のインターフェースの解説は完了です。
ここまでの情報に基づいて WSM アクセスツールは作れるはずです。もちろん、
TCP での通信などの基本的なことは分っている必要がありますが。

5:新しい話題の投稿

新しい話題の投稿の場合も、Web 上での書き込みと同じ処理を行なうことにな
る。コメントの場合との違いを中心に説明する。

●データの生成

新規の話題の投稿の場合には、以下の FORM への記入と同じ処理を行なうこと
になる。

<FORM ACTION="/webconNewMsg.mtxt" METHOD="POST">
タイトル:<INPUT TYPE=TEXT SIZE=60 NAME=TITLE>
発言者:<INPUT TYPE=TEXT SIZE=60 NAME=NAME>
メッセージ:<TEXTAREA NAME=comment ROWS=15 COLS=70></TEXTAREA>
参考ページ名:<INPUT TYPE=TEXT size=60 name=ref>
参考ページ URL:<INPUT TYPE=TEXT SIZE=60 name=URL value="http://">
<INPUT TYPE=SUBMIT value=" 投稿する ">
</FORM>

METHOD は POST である

ACTION は "/webconNewMsg.mtxt" を指定する。コメントの場合と違ってページ
の指定などは不要である。

記入欄の先頭にはタイトルを記入するようになっている。新規の話題の場合に
は、タイトル、発言者、メッセージの3つのフィールドが必須(空は許されな
い)ものとなる。クライアント側でチェックを行なうことが望ましい。

各フィールドに記入された内容を URL 形式でエンコードし、投稿用のデータを
生成する。


●サーバへの送付

mtlab.ecn.fpu.ac.jp のポート 80 にコネクトしたら、以下のようなリクエス
トを送る。

POST /webconNewMsg.mtxt HTTP/1.0
User-Agent: WSM Watcher
Host: mtlab.ecn.fpu.ac.jp
Content-type: application/x-www-form-urlencoded
Content-length: 00

(投稿データ)


改行は CRLF を用いる。ヘッダと投稿データの間に空行が入る。また投稿デー
タの末尾に CRLF を2組付けておく(つまり最後に空行を追加することにな
る)。

Content-length は投稿データのバイト数を指示すること。ヘッダの容量は含ま
ない。


●サーバのリプライ

投稿が無事に処理された場合には、新たに作られたページへのリダイレクトを
指示する以下のようなヘッダが返される。

HTTP/1.0 302 Found
Location: http://mtlab.ecn.fpu.ac.jp/webcon.mtxt$001122334455.html

必須のフィールドへの記入が欠けていた場合には、以下のように、投稿用ペー
ジへのリダイレクトの指示が返る。

HTTP/1.0 302 Found
Location: http://mtlab.ecn.fpu.ac.jp/webConpost.html

ただし、クライアント側で、サーバへリクエストを送る前に入力のチェックを
行なっておくことが望ましい。

重松修 さんからのコメント
( Sunday, September 30, 2001 22:34:09 )

とりあえず、一式固めたものをアップしました。
バグがあったらゴメンなさい。変更点は、XFCN を plugin にしただけです。
今まで私が作っていたものは、サイズがでかいと酷評されていたし、
C++ の例外処理を使っていたのですが、Rb の plugin では、
まともな C++ 的なスタイルでの開発は出来ない、とわかりましたので、
新たに書き起こしました。そのため、バグがあるかも知れません。
それから、OS X 10.1 では、起動しないと思います。
どうも、REALbasic の問題のようです。あいにく私はアップデート CD を
入手し損ねましたので、確認できていません。

→  http://ganymede.ravi.ne.jp/~shige/WSM/WSMW1.4Car.sit