+---------------------------------------------------------------+ | DOSLFN - A Real-mode driver for Long File Names missed in DOS | | With full Unicode and DBCS support! | +---------------------------------------------------------------+ アプローチ 御多分に漏れず、1996年以来、私もこの手のプログラムが欲しかったのですが、 心の中では、そのようなツールは誰にとっても便利なので、そのうち誰かが書く だろうと思っていました。それで私はのんびり待っていたところ、思ったとおり、 1998年に書かれた LFNDOS.EXE などの、それほど古くないいくつかのツールを昨 年になって見つけました。 このプログラムは Win9x の COMMAND.COM で動作するように書かれており、私の 好きなファイル・マネージャー、Volkov Commander では動きません。（長い名前 のディレクトリに入ることができません）また、そのＴＳＲは *とても遅い* 上 に、なんとメモリを 64KB 以上消費します！ このプログラムは小文字のファイルおよびディレクトリを作成することができず （なぜ？）、ニョロニョロ（チルダ、レジストリキー NameNumericTail=0 に応じ て切替可能）を除去する方法がなく、そして決定的なことには、それはウムラウ トを正しくサポートしません。 私の挑戦： もちろん、そのようなプログラムはアセンブリ言語で書かれるべきでしょう。 Turbo Assembler という素敵なもののおかげで、私はローカルな構造化コンポー ネントが利用可能な、あまり一般的でない IDEAL モードを使用しましたが、これ には他の利点もありました。（例えば速度） 上述のような欠点が残らないように、このプログラムは作られました。また、私 はＣＤ−ＲＯＭ（ジョリエット形式）上の長い名前をサポートしようとしていま すから、生ＤＯＳの下でバックアップをリストアするのにとても役立つことでし ょう。このための適切なツールは ODI の LFN ツールですが、しかしそれはドラ イバ形式ではありません。 少なくとも私にとって重要なのは Volkov Commander（私が思うに最良の Norton Commander のクローン）で使えると便利だ、ということです。それは長いファイ ル名をサポートし、オリジナルよりはるかに小さくて速く、さらにいくつかの利 点もあります。 （残念ながらいくつかの欠点もあります。ディレクトリソートのためのホットキ ーが見当たらないとか、あるいはコンピュータ間接続など） プログラミングの間に、せいぜい私が当初思いついた全ての機能を持っただけの 安全なドライバを書くことであってもそれほど簡単ではない、と私は述べざるを えなくなりました。 それまで私がそのようなものを見たことがなかったのは、不思議ではなかったの です・・・それほどプログラムするのが難しいのです。 初めの目標は、必要メモリを最小限に抑えることでした。できれば 4KB 前後に。 現在、私はこのゴールからはるか遠くにいますが、だけど、12KB 未満になったの で、私はとりあえず満足しています。64K と比較すれば合格点でしょう。 別のハードルは、Windows9x の長いファイル名の意味を理解することでした。 "cd .." は何をするかよく知られていますが、9x では新しく、"cd ..." は２段 階、"cd ...." では３段階上位のディレクトリに移動することになった、などな ど。（私はディレクトリ・エントリの "." と ".." が直接ＤＯＳによって使用さ れないという事実を熟知していました。）あるいは長いファイル名のパターンマ ッチングのされ方：いくつかはＵＮＩＸでも知られた方法（例えば *1 が「1」で 終わるファイルすべてと一致する）ですが、いくつかは Win32 特有であり、例え ば "*." は拡張子のないすべてのファイルと一致します。 また、拡張子はファイル名において《最後》のピリオドより後の部分であり、そ れより前のピリオド（複数あっても）ではない、と定義されています。あるいは、 ファイル名先頭に空白もしくはピリオドのあるファイルを作ることはできますが、 ファイル名末尾の空白もしくはピリオドは削除されます。"*." という指定方法で はピリオドで終わっているファイルを見つける方法がないので、これは必要なこ とです。したがって、空白およびピリオドだけのファイル名は許可されません。 現実には問題になりませんが、ディレクトリ・エントリ "." と ".." という例外 はあるにはありますが。 COMMAND.COM は Get Extended Error Information というＤＯＳファンクション を使用するので、私は COMMAND.COM を正しく動かすために、そのエラーコードを セットするための不便で補足的な機能を使わなければなりませんでした。 スイッチの説明： ~ （チルダの扱い）：既定値では、Win9x は任意の長いファイル名のエイリアス 　に "~1" のような指示子を追加しようとし、もしそれでは重複するような場合 　には "~2" などとします。したがって、生ＤＯＳの中のこれらの長いファイル 　名はエイリアスを特定することができません。この振る舞いは、試験段階で使 　われたソフトウェアの誤った振る舞いに基づいて構築されたように見えます。 　（私が推測するに、それはある古いマイクロソフトのソフトウェアでしょう） 　普通のＤＯＳと Win のユーザについては、これは非実用的です。生ＤＯＳは、 　8.3 の形式に長い名前を自動的に切り詰めることで、長い名前に「対応」でき 　るのです。名前がスペースあるいは複数のピリオドを含んでいなければ、同じ 　長い名前のファイルを特定することができ、これは、そのファイルに LFN があ 　ろうが、なかろうが、関係ありません。{Win9x あるいは DOSLFN}を実行しよう 　がしまいが、これとは関係なく、ユーザは、あるプログラムの設定との互換性 　を維持することができます。 　次の設定を行うことにより、Win9xの中のチルダ使用を抑止する事ができます： REGEDIT4 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\FileSystem] "NameNumericTail"=hex:00 　その後、Windows を再開しなければなりません。（終了メニューで再開を選択 　する時には、シフトキーを押し続けることを忘れないように・・・マシンの再 　起動は必要ではないからです） 　 　さらに、キーワード「NameNumericTail」で WWW を参照してもよいでしょう。 t （トンネル効果）：これは、Win9x のファイル・システムに組み込まれた機能 　で、従来型（8.3のみ対応）のテキストエディタや類似のツールでファイルを修 　正する場合に、長いファイル名が残存するように努めます。それらのツールは 　以下のようにファイルを置き換えます： 　* ファイル .bak を削除します（もしあれば） 　* オリジナルのファイル .txt を .bak にリネームします 　* 新しいファイル .txt を作成します 　このシーケンスで、長いファイル名は永久に失われるでしょう。 　しかし「トンネル効果」を有効にしておけば、Win9x と DOSLFN は delete - 　rename - create（DRC）のシーケンスを監視し、もし が同じ場合には 　「automagically」（自動魔法的に）、長いファイル名のエントリを削除するの 　に先立って新しく作った名前を付与します。 　上記の DRC シーケンスも、DR、DC、RR あるいは RC に切り詰められるかもし 　れませんし、またディレクトリでも同様に動作します。 　MSDN CD の中でドキュメント化されているように、Win9x 内部の「トンネル情 　報」は１５秒間だけ記憶されることになっていますが、しかしながら、私は忘 　却機能の部分を見つけることができていません。さらに、Win9x でのトンネル 　動作は「両方向」で働き、LFN を扱えるプログラムが同じ処理を行う場合、そ 　れは元のエイリアスを付与しなおしてくれます。したがって「Program Files」 　を「Programs」にリネームしてからもう一度もとにリネームしなおしてみても 　「PROGRA~1」のチルダを取り除くことはできません。 　（期待する効果を得るためには、２回のリネームの間で Windows を再起動して 　みましょう） 　更にマルチタスクＯＳとして要求されることですが、Win9x が持っている「ト 　ンネル情報」は１つだけではありませんので、２つ以上のプロセス（Win16 や 　ＤＯＳプログラム）が同時に DRC シーケンスを行ったり、１つのプロセスが時 　間を開けてから実行するのを許容します。 　単純にするために、DOSLFN では１つの「トンネル情報」をサポートするだけに 　しました。 /*２つの削除されたオプション** c （チェックサム・リンク）：このスイッチはＯＮにするべきです。ＯＦＦでは 　DOSLFN がちょっとだけ傷ついたディスク（例えばディスクエディタなどによる 　もの）を読むことができるかもしれません。しかし、それは仕様外の動作です。 　DOSLFN は、不完全なリンクを修理しようとすらしません。（その後に、長い名 　前に対して完全に異なる短い名前を付与することは可能かもしれません。しか 　し、SCANDISK はそれを正しくないと見破ります） a マイクロソフトがプログラマを嫌っているため、古典的なＡＰＩである「open」 　（AH=3Dh）や「creat」（AH=3Ch）のようなものへの、長い名前のサポートを追 　加してくれていません。（もちろん、プログラムが最大１２文字のファイル名 　を予期するので、FindFirst/FindNext のサポートは不可能です。GetCurDir の 　ようなものも同様で、プログラムは最大６４文字だと思っています） 　DOSLFN の将来のバージョンでは、これらをサポートするつもりです。（だれか 　が、要らない、と言わなければ） **２つの追加されたオプション*/ c （ＣＤ−ＲＯＭ対応）：ＣＤ−ＲＯＭへの対応を許容することで DOSLFN は、 　ＣＤ−ＲＯＭの初期化とアクセスのためのコードの分、より多くのメモリを使 　います。.JLT ファイル１つと、（最低限）ＣＤ−ＲＯＭを２セクタ分バッファ 　リングするためにも、メモリは使われます。 　MSCDEX が常駐済かどうかで、このオプションの既定値は異なります。MSCDEX 　の前に DOSLFN を常駐し、かつ、ＣＤ−ＲＯＭの上の長いファイル名も扱いた 　いのならば、c+ オプションを指定しなければなりません。 i （InDOS フラグの扱い）：LFN を使用するＴＳＲプログラムが正常に動作する 　には、それらのプログラムは DOSLFN が稼働中かどうかを知らねばなりません。 　悪くすると、もし DOSLFN が未使用の LFN を削除する場合、もしくはトンネル 　効果が作用して LFN が付加される場合（-tスイッチ参照）、短いファイル名を 　使って作業をすると、データが破損することにもなりかねません。 InDOS フラグの扱いに関するこのオプションを指定すると、DOSLFN が古いタイ プの Int21 をコールしている間、InDOS フラグの値を２にします。私は InDOS フラグをゼロでないように維持しつつＤＯＳをコールするもっと安全な解決策 を知りません。 　何か問題があれば、このオプションを Off にしてみましょう。このオプション 　の既定値は On です。 z DOSLFN は Unicode を各言語のコードページへ変換しますが、これはロケール 　依存です。ＤＯＳ（あるいは NLSFUNC）は内部に変換テーブルを持っていませ 　んから、この変換テーブルは別の方法で DOSLFN にわたされる必要があります。 　１９の Unicode の変換テーブル、例えば437（リセット時に使われる標準的な 　ＩＢＭコード）、850（西ヨーロッパ）、852（東ヨーロッパ）、866（キリル文 　字）および２つのギリシャ文字などが現在 DOSLFN にバンドルされています。 　コードページは DOSLFN が常駐中に読み直し・切替をすることができます。 　ほとんどのヨーロッパのユーザはウムラウトをめったに使用しない（変なコー 　ド化をしているソフトウェア[*]が引き起こす問題は、世界中でよく知られてい 　るので、これが理由でしょう）から、変換テーブルの読み込みを忘れても大し 　たことはありません。それでも想定されていないアンダーラインのあるファイ 　ル名を目にしたなら、変換テーブルをロードするべきでしょう。 　（DOSLFN は単に、変換できない Unicode を "_" に変換するだけであり、同じ 　ファイル名が既に存在しているという通知はしません） 　ヒント：DOSLFN は、動作開始時に「正しい」Unicode のテーブルを自動的に読 　み込みますので、東欧諸国でさえこのスイッチは必要ではありません。 　更に、ＤＯＳの nlsfunc を使用してコードページを変更すれば、DOSLFN はテ 　ーブルを自動的にロードしてくれます。それでも、この場合、余計にヒープ領 　域を確保しておかなければならないかもしれません。 　（US mode で DOSLFN をロードするなら、日本語ＤＯＳでは /m18000 を指定す 　る必要があります） 　[*] 多くの場合、ウムラウトを亡き者にするのは、邪悪な Unix 系のソフトウ 　ェア（例えば "tar"）です。Unix は内部的には３２ビットではなく７ビットの 　ＯＳと言うべきであり、ごく最近になるまで、この制限は広く世界に蔓延して 　いました。（脳死状態のような UTF-7、MIME エンコーディング、・・・） m DOSLFN はデータの格納用に内部ヒープ領域を必要とします；ほとんどは Find 　ハンドル用です。このデータ・エリアのサイズの既定値は 1000Byte ですが、 　ＣＤ−ＲＯＭを使う時の既定値は 2000 Byte になります。小さな値を指定すれ 　ば、DOSLFN の常駐時のメモリ消費量を減らす事ができます。 　DOSLFN が常駐している時、このオプションを指定する事はできません；メモリ 　が既に使用されているかもしれないからです。 l DOSLFN はバイリンガルです。もし使われている場所がオーストリア、スイスあ 　るいはドイツだということを検知すると、それは言語設定の既定値をドイツ語 　とし、そうでなければ英語とします。既定の言語設定を無視してドイツ語にす 　るには "ld" を、英語にするには "le" を使用してください。 　例えばオーストリアで英語のヘルプメッセージを得るためには "doslfn -le -h" 　または "doslfn leh" と指定します。 　（ご覧の通り、DOSLFN はオプション指定の際の前置されたハイフンと空白を無 　視します。後ろの空白は、z コマンドだけで必要とされます） 　DOSLFN が常駐している間は、言語設定は変わりません。 TZ ＦＡＴのタイムスタンプを Win32 の時間の形式（１９０１年１月１日からの 　１００ナノ秒単位の経過時刻を示す６４ビット整数）に変換するために、この 　環境変数は後から使われます。それは "%c%c%c%g" のような scanf() テンプレ 　ートに一致しなければなりませんが、これは３文字からなる（未使用の）文字 　列、浮動小数点数（指数関数的な形式ではありません）およびその後ろのオプ 　ション文字列を意味しています。浮動小数点数は、ＧＭＴ（グリニッジ標準時） 　からの時差で表現します。夏時間（ＤＳＴ）の自動設定はできませんが、これ 　は各国の計算方法が不明なためです。もし自動設定するならば、DOSLFN は与え 　られた国の過去（および将来）の全ての夏時間規則を知っていなければならな 　いからです。それは、今日の日付ではなくファイルの日付に従って時刻を変換 　する必要があるからです（が、ほとんどのプログラムはこの部分にバグを持っ 　ているように見えます）。アメリカのＤＳＴ規則は応用できませんが、しかし 　多くのプログラムもそうです。 　したがって私は、ユーザが TZ をセットすることを提案します。例えば中欧の 　例： set TZ=MET-1 in winter set TZ=MET-2 in summer 　どんな夏時間情報も使用しません・・・でも、年に２回、AUTOEXEC.BAT をユー 　ザ自身で変更しなければなりません。 　TZ は CDFS を Win32 の時間の形式に変換する時には必要とされませんが、こ 　れは、その日付の部分にＣＤが作成された国の時差についての情報（１５分刻 　みの値を格納したバイト値）を含んでいるからです。しかしながら、世界の時 　間と同期をとるために、CDFS の時間を（ほとんどすべての時計関数の返り値で 　ある）ＦＡＴの時間に変換し、TZ と CDFS の両方の時差情報は正しく計算され 　てＦＡＴ時間（＝常にローカル時間）にまとめらます・・・さらにそれは、内 　部で Win32 時間形式にするためのよい中間形式です。 動作： コマンドラインの末尾の文字で、動作を指示します。なぜなら、コマンドライン の解析はそこで終わるからです。 デフォルトの動作は、DOSLFN を読み込むか、または DOSLFN が既に読み込まれて 稼働中なら、アクティブにしてから短いメッセージを表示することです。 ＴＳＲが DOSLFN の常駐後に Int21 か 2F をフックしている場合、DOSLFN を常 駐解除することはできないかもしれません。その場合、DOSLFN は自分自身を休止 状態にしますが、別途（再読み込みまたは再稼働のような）指示があるまで常駐 し続けます。常駐解除するときは、その（あるいはそれらの）ＴＳＲを先に常駐 解除しなければなりません。それが不可能なら（ほとんどの場合は不可能だ：マ イクロソフトのバカやろ〜）、「システムのリブート」が必要です。 いくつかの実装上の注意点： 私にとっての最大の難関は、ＣＤ上の長い名前を安全にサポートすることでした。 私は MSCDEX を利用して構築したいので、ジョリエット形式とＩＳＯ形式の間の 橋渡しをしなければならないのですが、最終的に私が気づいたことというのは、 安全な橋渡し方法はないということです！（WinOnCD はその手のリンク・テーブ ルを必要としないのでありがたいのですが、でも標準的な方法ではありません。） 更に、Win9x および NT は新しい短いファイル名を「発明」してくれるし、ジョ リエット形式のＣＤのＩＳＯ形式の部分を全く使用しない上に、これらの２つの システムは異なる規則を有しています。ということで、ＣＤ−ＲＯＭドライブに 長いファイル名を持ったＣＤを入れて、古いＤＯＳプログラムからそれを見ると、 生ＤＯＳ用、Windows9x用、および WindowsNT用の、それぞれで異なった短い名前 が最大３個まで、付けられていることがわかるはずです。 ODI の LFN ツールは、MSCDEX を（セクタを直接読むときを除いて）要求しない し、逆にあっても問題はないように、ドライバーの動作としては長い名前に対す る正しい短い名前を伝えるだけなんですが、これは MSCDEX が短い名前を扱うべ きものだからです。 最近になって採用した方法は、ディスク（例えばハードディスク）上のリンク・ テーブルと各ＣＤのリストを構築するプログラムを使用します。このリストを作 ることは時間のかかることで、多分、よいプログラムであればそんなに時間を消 費しないでしょうが、しかし全てのディレクトリを読むことはある程度時間がか かることだし、また DOSLFN にとってはやっぱりよろしくない動作です。 DOSLFN がＣＤをチェックし適切なテーブルを読み込むのか、あるいは、ユーザが Unicode の変換テーブルを読み込まなければなりません。 別の問題は、ディスク書き込み時のセクタバッファの同一性についてです： 私はデータをキャッシュに入れたいのですが、ShortName API は勝手にディスク を書き換えるかもしれません；その場合には、少なくとも書き込みのあったドラ イブの分だけでも、キャッシュをすべて破棄しなければなりません。これは、す べてのＤＯＳディレクトリに対する書き込み時だけでなく、昔ながらのＦＣＢに よるものも対象です。 これは DOSLFN のパフォーマンスを下げます。 できるだけ多くのＤＯＳ（ＭＳ製以外も含め）で利用可能にしたいので、私は非 公開なＤＯＳの内部構造を使用したくないのです。 チェックされた環境： * MS Windows NT 4 DOS-Box, FAT12 and FAT16 drives 　（でも、やはりすばらしいオープン・ソースのフリーウェアである NTLFN を使 　うべきです） * MS-DOS 6.2 * MS-DOS 7.10, FAT32 * DR-DOS 7, ＭＯドライブ使用 動作しない機能： * 正しい WindowsNT 形式の時間のフォーマット（だけど、双方向の変換ルーチン 　は組み込み済みです） 　私が見たことのあるすべてのプログラムはこのＮＴ形式の時間を直接には使用 　しませんが、このＮＴ形式をＤＯＳ形式に変換するために DOSLFN を呼びます。 　（例えばＤＯＳ７の COMMAND.COM の DIR コマンド） 　NTFSDOS が DOSLFN の後に読み込まれるとエラーとなります。 * JOIN されたドライブ（でも、SUBST されたドライブでは動作します） * ASSIGN されたドライブ（未テスト、でも SUBST に似ているからそのうちやっ 　ときます） * VCACHE.386 が Int25/26 および Int21/AH=32 によるディスク直接アクセスを 　妨害するので、３２ビットファイルアクセスが可能な Windows3.11 は、DOSLFN 　がハードディスクへ FallBack モードでアクセスすることを強制します。 　「３２ビットファイルアクセス」を停止させてください。 　（「３２ビットディスクアクセス」は ON のままでも構いません） もっと難しい機能： * 非ＦＡＴドライブ上のワイルドカードによる拡張された削除機能 * 短いファイル名が同一となる時の REName -> 短いファイル名の新規作成 多分永遠に手付かずとなる機能： * SUBST 関連の機能、AL=AAh（「subst 問い合わせ」は利用可能です） * サーバーからのファイル生成、AL=A9h * ハンドル情報検索、AL=A6h * ドライブのリセット、AL=0Dh ＤＢＣＳ（中国語、日本語、朝鮮語、=CJK）ユーザのためのヒント： 西欧のユーザと同じく、単に DOSLFN をロードするだけです・・・ただ、DOSLFN は、巨大な DBCS<->Unicode の変換表を保持するために、より多くのメモリを使 う事になります。 その背景： Win9x/Me の緊急ディスクから起動する場合、ＤＯＳはコードページが 932、936、 949、あるいは 950 だと言ってくるのですが、でも、ディスプレイ・フォントは まだＢＩＯＳで指定されているコードページ 437 のままです。 更に、ＤＯＳ内部のＤＢＣＳベクタはまだ使える状態になっていません。 したがって、DOSLFN の使用・未使用にかかわらず、漢字を含んでいるファイル名 を表示する場合、意味不明な文字列を見る羽目になります。 PDOS95.BAT の動作開始後、私が思うに、ディスプレイは 40x24 の全角（四角形 という意味）漢字表示モードに切り替えられます。（もし CP932：日本語のシフ トＪＩＳを使用すれば、半角カタカナも表示されます）２５行目は、単にローマ 字／ピンイン入力および漢字選択のための行としてインプット・メソッド・エデ ィタ（ＩＭＥ）で使われるだけです。（異なる意味を備えた多くの文字が１つの 読みに対して存在するという事実により、選択という動作は特に日本語で必要） 更に、ＤＯＳ内部のＤＢＣＳベクタが使用可能になって、そして DOSLFN は LFN の中の全ての Unicode のＤＢＣＳへの変換および書き込み時の逆変換ができるよ うになります。 実際に行うのが大陸中国のユーザ（および日本語を理解できる私）なので、将来 の試験は CP932 と CP936 に限定されます。（CP950 は現在のバージョンはまだ 動作報告があります） 注目に値するのは、PDOS95.BAT を置き換えることのできる多くのよいツールがあ るということで、私の持っている「TechWay SCS V3.2」のプログラムおよびドラ イバはそれが可能だし（wengier に感謝）、それにドイツ語ＤＯＳ６でも動作し ます。それらの利点のうちの一つは、全角文字で使われる記号の自動検知と、検 知したそれらの文字を漢字として解釈しないことです。（PDOS95.BAT と同様の動 作）それを使うことにより、私は好きなファイル・マネージャ（vc.com）、エデ ィタ（turbo.exe）およびデバッガ（td.exe）をほとんどトラブルなしで動作させ ることができました。 付属プログラム「MK_TABLE」、「MKLINK」および「LOWDMA」： MK_TABLE は、ASCII 形式の Unicode テーブル（www.unicode.org でダウンロー ド可能）を DOSLFN によって使用されるバイナリの Volkov Commander 形式に変 換します。 MKLINK（名前は今後変わるかもしれません）は、見つけた各ジョリエット形式の ＣＤの「ジョリエット・ディレクトリ・リンク・テーブル」を作成します。 デフォルトでは、それは全てのＣＤドライブをスキャンし、やや複雑な再帰処理 を使用して、このテーブルを作成します。MKLINK は、処理した各ＣＤ毎に、ＣＤ のボリュームラベルから引き出されたファイル名を選び、.JLT ファイルに追加し ます。 従って、使用者は持っているＣＤのコレクションをスキャンして、全てのＣＤの テーブルを作成しておく事ができます。 これらのテーブルを DOSLFN が使うことで、WinOnCD によって作成されたのでは ないメディアに記録されている長いファイル名へのアクセス速度が向上します。 MKLINK はいくつかのコマンドライン・パラメーターを受け付けます。以下のオプ ションがあります： /b * 全ＣＤの対話的なバッチ処理 /f * リンク・テーブル・ファイルが既に存在しても強制的にＣＤ読み込み * CeQuadrat WinOnCD のテーブルを無視して強制的にＣＤを読み込み /v * 複数行毎の読み込み過程を表示（テーブルとして、こちらがお勧め） /v- * 読み込み過程非表示 /c * ＩＳＯおよびジョリエットツリーの順序の比較 /h * ヘルプの表示 ドライブの選択はドライブ名を１文字入力することで行います。 MKLINK には DOSLFN の作業ディレクトリに結果の .JLT ファイルを出力させるべ きであり、DOSLFN と同じディレクトリに MKLINK を置いてある場合、これがデフ ォルトです。 一つのセッションの破壊の影響は全てのディレクトリ・セクタの不良につながる ので、マルチセッションのＣＤ−ＲＯＭに記録されている、そのＣＤ−ＲＯＭの .JLT ファイルを壊すことは考えてはいけません。 LOWDMA： LOWDMA.TXT を参照してください。 ---------------------------------------------------------------------------- 変更履歴： (+ 仕様追加 - バグ取り * 仕様変更) Version 0.30 (01/01) 最初のバージョン Version 0.31 (04/01) + Windows NT をちょっとはましに扱うようにした（今でも変だが） + リムーバブルなメディアのデータを保護するためのタイムアウトの解決 + ＤＯＳ７で書き込みアクセス前に自動的にボリュームをロックするようにした * PKZIP 2.50 をサポートしようとしたが − 最終的な解決に至らず * ISR を RETF 2 の代わりに IRET で終了させた。これでシングルステップデバ ッガでも動作可能になった Version 0.32 (09/01) - NUL、CON、LPT のような標準デバイスで動作するようにした * ソースコードに InDOS フラグの設定のためのオプションを入れた + 可変ヒープサイズのサポート；DOSLFN のメモリ消費量はユーザが指定可能 + PRINTF 類似機能内蔵（非常駐部のみ） * 「ステータス」機能での出力形式の変更 + 圧縮ファイルに４つの文字コード変換テーブルを同梱 - ちょっとだけ readme ファイルを修正 Version 0.32a (10/01) - いくつかの FAT32 ドライブのルートディレクトリでの誤動作 （このバグはしばしば報告されたが、私のところでは今まで発生していない） - DOSLFN が FAT32 なドライブから起動した時の妙な動作 （このバグは Version 0.32 で混入した） + 圧縮ファイルに全ての利用可能な文字コード変換テーブルを同梱 + MK_TABLE.C（0.32 の時に作られた）を強化して同梱 * バージョン番号の「a」は別のバージョン 0.33 が現在開発中であることを示す。 これはいくつかのバグを取り除いたリリースである。 Version 0.32b (10/01) - INT21/4E&4F での正しくない AX、claude.caillet@free.fr から報告された （動作が Ralf Brown list 03/99 に記載されていなかった） - DOSLFN.TXT でのいくつかの英語文書の誤り（時間帯およびテスト条件） Wu Yongwei から報告された - CP850UNI.TBL の不良がそのまま CP858UNI.TBL にコピーされていた（これはユ ーロの通貨記号を１つ含んでいるが、CP850 はユーロを含んでいない。 （ より） + MKLINK の追加、でも出力されたリンク・テーブル・ファイルはまだ使えない Version 0.32c (11/01) - いくつか場合に *. が働かない。（例えば "copy *. tmp" が失敗する） - キャラクタデバイスの FindFirst がエラーを返すがそれはおかしい （"copy con xx" での誤り）この２つは wengierwu@sohu.com から報告された * デフォルトのヒープサイズの縮小、ＣＤセクタはまだ内部にない * 内部リンク・テーブルのためのサイズを３２ビットに拡張 Version 0.32d (06/02) - LFN をサポートしないことにして SUBST されたドライブでの誤動作を除去 - アンダーラインを挿入する数値の末尾の右揃えが誤動作していた（caillet） * CeQuadrat リンクテーブルの有効性をチェックするように MKLINK を修正 - MKLINK はマルチセッションと EasyCdCreator のディスクを扱えるようにした Version 0.32e (06/02) * ソースの再整理、宣言部における英語の増加 + InDOS フラグの使用（ユーザであらかじめセット可能） - MSCDEX から返された VolumeStart の値は誤っていたので、IOCTL に基づいた ルーチンを組み込んだ * 「チェックサム・リンク」と「LoSA」スイッチ廃止、「LoSA」はVxDへ移動予定 - ＣＤ−ＲＯＭのルートディレクトリの LFN GetFAttr の誤り * デフォルト設定の変更（チルダ使用をＯＮにした） + DOSLFN が MKLINK の生成したファイルをロードできるようになった（つまり全 てのジョリエットＣＤ−ＲＯＭのサポート） + 最後に発生したエラーの状況報告機能 - MKLINK の小さなバグ潰し（LongInt の代わりに LowWord で InSTab を比較す るようにした） * （既知）ルートディレクトリのリンクが *.JLT に含められるよう、MKLINK は 再び変更された * MKLINK の内部的な変更、オブジェクトを使用して「ツリー順チェック」を付加 Version 0.32fα1 (09/02) - LFN_FindFirst/FindNext の返り値 CX が誤っていた * Creat(3C) の代わりに拡張 Open/Create(6C) の内部呼び出し - ブート可能ＣＤの認識するようにした（MKLINK はまだ） * トンネル効果の準備 Version 0.32fα2 (10/02) - 拡張 Open/Create（0.32fα1 で混入したバグ） - lfn_rmdir のために LFN_DirEnt を削除（バグはずっと入っていた） * 今後は再帰的な Int21 呼び出しはしない（.JLT アクセスを除いて） * lfn_unlink のために sfn_unlink へ再帰することはしない（速度向上） + ワイルドカードを使った削除（未テスト；FALLBACK モードも） Version 0.32fα3 (11/02) - パスの構成要素としてボリュームラベルを解釈していた Version 0.32fα4 (12/02) - ほとんど（できればすべて）の EDIT.COM バグの除去 - 正しくないセグメントへ書き込む汚いルーチン除去（Version 0.32e で混入） Version 0.32fα5 (12/02) + ワイルドカードを使った削除を実装。少なくとも FAT なドライブでは機能する Version 0.32f (12/02) - 最終 "f" バージョン - 既に存在するディレクトリ作成時に「file not found」を返していた[wengier] - リネームコマンドがまれに他の LFN を忘れるか破壊する（２つのバグ） Version 0.32g (12/02) - VC Alt+F7 のバグ（lfn_name 呼出時に末尾のバックスラッシュが除去された） - VC の再帰的削除と PKZIP の再帰的新規作成でのバグ（FastOpenCache バグ） * Version 0.33 の開発中止 Version 0.32h (12/02) - 空白を伴った SFN へのアクセス（なんと、この修正はコードサイズを縮めた） - MKLINK をちょっとだけ修正：詳細表示スイッチおよびテーブル配置 + CeQuadrat LT が最初のセッションでないなら、MKLINK はリンク・テーブルを 作成する + MKLINK が内蔵コードページ 437 を取得（詳細表示用） - ＣＤ−ＲＯＭのルートディレクトリが . と .. のエントリを表示していた - 末尾にバックスラッシュのついた「cd」コマンドが VC Alt+F7 で機能しなくな るバグを除去 Version 0.32i (12/02) - ＣＤ−ＲＯＭがカレントドライブの時に DOSLFN を起動するとクラッシュした - /p スイッチの正しくない扱いおよび不動作 - Unicode テーブルを自動読み込みする時に誤ったディレクトリを取得 Version 0.32j (12/02 - Xmas) + LFNXLAT.386 を書いた −− Windows および DOS 窓用プロテクトモードＡＰＩ + その VxD をロードする（Win3）か、自動的に無効にする（Win95 以降）ための Int2F インターフェース追加 + ＤＯＳと Windows のバージョンを検査しＤＯＳ４未満または Win9x のときは 常駐しない + Int2F 上での自動コードページ変更通知（未テスト） + 最後に発生したエラーの報告機能で５種類のメッセージ表示するようにした + 最大の .JLT ファイルに基づいた自動的なヒープサイズ計算機能 + /c スイッチ追加 + FAT-ONLY モード（要するにＣＤ−ＲＯＭ未使用時）のメモリ消費量を縮小 もし MSCDEX の前に DOSLFN をロードし、かつＣＤ−ＲＯＭにアクセスする事 を希望する時には、/c+ スイッチの指定が必要 - マルチセッションのＣＤ−ＲＯＭからの CeQuadrat LT の読み込み - ディレクトリ拡張時における少なくとも３つのバグ - ワイルドカード文字を含む長い名前のファイル名を作成することができていた + SUBST されたドライブの完全サポート - 長いＩＳＯのファイル名で DOSLFN がクラッシュ −− 現在は単に１２文字以 降切り捨てることで対処 - 大文字・小文字の変更だけのリネームが失敗していた * setjmp/longjmp または Catch/Throw に類似のエラー処理でソースを単純化 + トンネル効果（古いエディターなどのために長い名前を保持する） - ボリュームラベルと同じ名前のファイル／ディレクトリを作成することができ なかった - 末尾のバックスラッシュの扱いの非互換性で PKUNZIP の誤動作を招いた + /t スイッチ追加 − これで全てのスイッチが機能するようになった - ジョリエットＣＤ−ＲＯＭのルートディレクトリのファイル一覧表示のバグ （ファイルがディレクトリになる） + ＤＢＣＳサポートの準備 Version 0.32k (01/03) - "dir makefile" が makefile を表示しない （この小さなバグをとるために、DOSLFN の大量の書き直しが必要となった） * .TBL ファイルがない場合、DOSLFN のデフォルトは、今までの CP437 ではなく ISO-Latin1 となった。これはＤＢＣＳサポートのための内部処理変更による。 西欧のユーザは CP437UNI.TBL ファイルを削除してはならない！ - １バイト目が 0xE5 のファイルを扱うことができなかった （ＤＯＳの TRUENAME の「バグ」@0.32j） + ＤＢＣＳ用の .TBL ファイルのフォーマットを発表した、TBL.TXTを見よ + ３つの新しいコードページのテーブルを追加：日本語（シフトＪＩＳ）、簡体 字中国語（GBK のサブセットである GB2312）、繁体字中国語（BIG5） + 全面的なＤＢＣＳサポートの追加、でも私はテストが不可能 中国語または日本語のユーザは /m18000 を指定する等の方法でヒープを増やす ことが必須（このスイッチは今後のバージョンで自動化予定） - デバイスへのアクセス後、データ化けが生じる恐れがあった - DOSLFN の異なるバージョンが動作中だと変な文字列が表示される恐れがあった - /z スイッチが機能していなかった問題が 0.32j で混入 バージョン0.32l(01/03) - ＤＢＣＳサポートは（バグ多発で）全く動かなかったが、TechWay SCS と動作 が一致するようになった - ＣＤ−ＲＯＭ未使用時にＤＢＣＳをロードする場合のメッセージ誤表示 - 部分的なＤＢＣＳテーブルの上書き * より厳密な「重大な初期化コード」セクション + .TBL ファイル読み込み時のヒープサイズを自動で計算して拡張するようにした ＣＪＫユーザはスイッチ指定が不要になった Version 0.32m (01/03) - 0.32l 以来、ヘルプ表示の /? または -h でＤＯＳがクラッシュ（爆！） - 0.32fα2 以降、DEL コマンドで誤った返り値を返していた * 短い名前で大文字だけのファイルを作成する際の能率をわすかに改善 - CP950UNI.TBL は悪い（時代遅れな）フォーマットだった + 第４のＤＢＣＳな Unicode のテーブルとして CP949UNI（朝鮮語）が追加され たが、私にはフィードバックが必要だ！ Version 0.32n (01/03) + 第５の CP936UNI.GBK は簡体字を網羅した Unicode テーブルである - CHCP コマンド実行後の Unicode テーブルの自動読み込みの失敗 - コマンドライン上書きエラー（長いパスに入ることができなかった）、変数領 域を完全に再構成する事によって対処 + FallBack モードとしてＵＮＣ名を処理（完全にテストされていなかった） - SUBST されたドライブでの truename がエラー - FallBack モードにおけるファイル／ディレクトリ作成エラー + NERO が非ＩＳＯなＣＤ−ＲＯＭを作れるようになって以来、ＩＳＯ／ジョリエ ット形式のファイル名の末尾にある ";?" (?=1..9) の２文字を脱落させるより も検査するようにした * VCACHE.386 に問題が発見され、３２ビットファイルアクセスを使用しない以外 の対処法がなかった + 単純なヒープ管理機構でサイズおよびフリーエリアを把握 + FMLFN.DRV という Windows File Manager に長いファイル名を渡すとってもβ なツールを追加 + DOSLFN は SimTel（www.simtel.net）からダウンロード可能となった + MKLINK も Unicode とＤＢＣＳをこのバージョンよりサポート（その画面表示 時に利用） - MKLINK によって生成された .JLT ファイル中の多重リンクのバグ - ディレクトリのサイズが 2048 で割り切れない時に MKLINK がクラッシュする （ＩＳＯの標準ではない） Version 0.32o (05/03) - オプション /? が再びシステムをクラッシュさせていた + ロシア語文字列が利用可能、でもまだ未実装 以下の変更およびバグフィックスは jadoxa@yahoo.com.au に影響されたものです が、でも彼はもっとすごいことを実行していました： * ちょっとしたコードの最適化 - トンネル効果による SFN ファイル作成時の ReadOnly 属性の設定 * セクタ・アクセスは（非公開で）SmartDrive のキャッシュを通過するようにし たので、いくつかのファイルをＣドライブからコピーするときの効率が下記の ように改善した DOSLFN なし A: へのコピー 25 s A: からの削除 7 s DOSLFN 0.32n A: へのコピー 78 s A: からの削除 12 s DOSLFN 0.32o A: へのコピー 43 s A: からの削除 7 s * MKLINK はこのバージョンより 64KB 以上のディレクトリを扱うことができる （まれな状況なので未テスト） * MKLINK.PAS は、もっと多くのメモリを使うことのできるＤＰＭＩバージョンに コンパイルすることができる（テスト済） 既知のバグ： - 「最終アクセス」日を設定／更新しません - FCB を使ったファンクションを呼ぶ際に、ＬＦＮのディレクトリエントリを設 定／移動しません - ＣＤ−ＲＯＭでのワイルドカード検索は、ＩＳＯのエントリーを走査しません （0.32e 以来？） - RENAME のバグ（改名時は常に短い名前を変更する） - VCACHE.386 のバグで、Windows 3.11 では３２ビットファイルアクセスを無効 にしておかなければなりません。 - NTFSDOS が DOSLFN の後にロードされたときの FILETIME のバグ（DIRは間違っ た時間を表示する） - 複数の LFN DRIVER の LOAD の順番に関するバグ − NTFSDOS は DOSLFN の後 にロードされなければなりません。 - VERSION CHECK していません − 異なるバージョンの DOSLFN を使用する場合 は奇妙な挙動を示します - TRUENAME はデバイスを正確に処理しません。 email: henrik.haftmann@e-technik.tu-chemnitz.de Download: http://www.tu-chemnitz.de/~heha/hs_freeware/doslfn.zip or http://www.simtel.net/pub/dl/62342.shtml