反則技

[↑一覧] [新着] [ホームページ]

DynaBook(*1)を入手してからそろそろ半年になる。80286を使った新製品が出る という噂もあるようだが、私のDynaBookにはモデムカードも装備し、データのダ ウンロードのような負荷の大きな(?)作業にも使うようになった。現状の利用目的 に対しては、かなり使えるという感触である。

DynaBookに関しては、市販ソフトは買わないという主義で今まで使ってきた。(*2) ただし、正確にはDynaBook本体と同時に英語DOSを買っているので、これだけは別 格である。基本的に使っているソフトは、MicroEMACS、ULTmini、lessの3種類だ。 (*3)

ここで、そろそろMicroEMACSの限界が障害になってきた。サイズの非常に大き なファイル(*4)が扱えないことである。今まで、DynaBookの通常の用途は文章作 成だった。64KBを超えるサイズのドキュメントを作成するのは結構大変なはずで ある。しかし、電子会議をダウンロードすると、簡単に数百KBのサイズのテキス トファイルができてしまう。これを編集できないのが、問題になってきたという 意味である。

これを回避する最も安易な方法は何か考えた。ここで別の事情にも触れておき たい。今まで、大きなサイズのファイルはPC286U上でMIFESというエディタを使っ て編集していた。ところが、最近になって、他のマシンの上で同様の作業を行い たいという状況が発生した。そのマシンでMIFESを使えばよい、というのは安易す ぎる。MIFESの利用条件は、指定した機械上でのみ使用するというものだから、登 録したPC286U上でしか使うことができない。許可を求めれば、登録機種の変更は 可能かもしれないが、常識的に考えて、同時に使うことは無理だと思われる。

(同時に使えないと困る)＋(MIFESをコピーして使うのは不正利用である)という 条件から、ただちに結論が導かれる。大きなファイルを扱えるエディタをもう一 つ用意しなければならない。たとえばMIFESをもう一つ買えばよろしい。

ところが、MIFESは高くて買えないのである。そこで、最近評判のVzというエデ ィタを買うことにした。これは限りなく反則に近い行為である。が、ある程度の 条件を満たせば、私の場合、価格は機能に勝る条件なのだ。もう一つエディタを 買おうと決心した場合、これ以外に選択の余地はなかろう。それに、Vz Editorは MIFESに比べて値段はとても安いが機能は特に劣らないと思われる。

    *

で、早速Vzを使ってみた。PC286U上で使う限り、MIFESと比べて遜色ない所も多 い反面、細かい点で使い勝手がMIFESに劣る部分がある(*6)。速度などの面は、Vz の圧勝である。普通のユーザーならば、使い勝手に改善の余地があると文句も言 いたくなるかもしれないが、ソースリスト付きのプログラムに対してプログラム が改善の余地があると言うのは難しい。自分で改善すればよいからである。

ところが、DynaBookで使っていると、これが非常に使いづらい。使い方を誤っ ているのかもしれないが、atok7で文字入力をする時に、何か処理が追いついてい ないのである。具体的に述べると、仮名漢字変換を行いながら入力をして、確定 する時に、確定直後に入力した文字の次の入力が、atokを素通りしてしまうこと があるのだ。これで、文章の入力が大幅にスピードダウンしてしまうのである。

具体的にどのような結果になるのか? 都合よいことに、この段落の最初の文章 がそのまま例になってくれた。この文を入力したら「具体的にどのような症状に ルなのか?」(*7)となったのだ。「症状に」で一旦スペースを押して変換 を行う。確定するためには次の入力を行うか、Enterを押せばよい。ここでは、次 の入力、「なるのか」を入力したのである。すると、「な」が入力されたまでは よいが、次の「る」がatokには渡されずに、直接エディタに出てきてしまうので ある。

この症状が発生した場合、カタカナを次の文字と入れ換えて読めば文意は解釈 できる。そこで、どの程度の割合で再現するか例示するために、ここからの文章 を作成中にこの現象が発生したら、あえて修正スぜにそのまま放置してみ よう。多少お見苦しい点はご容赦いただきたい。

「修正スぜに」というのは、「修正」で一旦確定させ、「せす゛に」と続 けた。せの次の「す」だけがatokを通過するので、FEPには「せ゛に」という文字 が渡されることに注意。

わざとこうやって作文してみると、漢文を読むときの返り点が何となくン れそうされるようで面白い。:-)

    *

B+は、通信ソフトがB+対応になっている場合、最も威力を発揮する。すなわち、 通信フそとがB Plusの転送開始のコードをケうとったら、その時 点で自動的にプロトコルに従って転送を開始し、終了すればテキストモードに復 帰させるのである。すると、ユーザーは従来のようにファイル転送開始の時にコ マンドとしてXMODEMの起動を指定するような手間がいらない。

さて、よくFlying-XMODEMとB+はどちらが速いかと質問されるのである。物理的 な転送クそどは同じと仮定すると、XMODEMの場合には128バイトを送るご とにヘッダー3バイトとチェッサム1バイト、B+の場合には1024バイト送るごとに ヘッダーやCRCの情報(*8)。ただし、XMODEMの場合には、データの最後は128バイ トに揃えるために平均して64バイトは無駄なデータで埋めなければならない。B+ の場合、データにquoteが必要な文字が含まれていると、quoteのために１文字に つき余計な１文字が必要ナとる。私の判断では、双方ともあまり量的な差 はないのではないかと思う。

考えてみれば、Flying-XMODEMの測定値も、かなり理論的限界に近い値なのだか ら、それ以上速くするのは無茶である。ただ、B+の場合には、将来、圧縮処理を プロトコル自体が行うようなフラグを持っている。その場合には、B+はさらにパ ワフルになるかもしれない。しかし、現状ではフリーソフトのようなデータは、 既に圧縮された状態で登録されているから、それ以上圧縮することは不可能な場 合が多いようだ。そのような場合には、圧縮がかえってCPUの負荷を重くするだけ 不利になるかもしれない(*9)。私としては、それより先にセンターホストとモデ ム間の速度を速くして、MNP class5を有効利用できるようにして欲しいと思って いるのだが。

補足

(*2) SS001が20万フラットという価格設定なので、20万フラットでどこまででき るか試してみようという目的だった。最近は10万出せばブックPCが買えてしまう のだが。

(*3) MicroEMACSはVz Editorになり、ULTminiは魔王という通信ソフトに置き換え た。lessは健在である。

(*4) このころの感覚で「非常に大きな」というのは、フロッピーのサイズの制限 を受ける。最近なら、2〜3MB程度を超えないと「非常に大きな」という感じはし ない。

(*5) 一名が使えば複数のマシンでもよい。あるいは複数の人が使う場合は、一台 のマシンで使えばよい。

(*6) 最も不便だと思ったのは、ページ移動のキーが、検索文字列を指定した途端 に、次の検索キーに変化してしまうことである。検索中に次のページを見たいと いうことは、しばしばあるのだ。その度にイライラする。

(*7) ルは、実際は1バイトカナのコードが出ている。

(*8) 最近は2KBのパケットが使えるようになった。ただし、NIFTY-Serveは、1996 年8月の時点で、まだサポートしていない。

(*9) ハードウェアが進歩したため、そんなことどうでもいい時代になってしまっ たかもしれない。

    COMPUTING AT CHAOS RUINS -102-
    1990-01-27, NIFTY-Serve FPROG mes(5)-077
    FPROG SYSOP / SDI00344   フィンローダ
    (C) Phinloda 1990, 1996