RTPatch®
RTPatch for Windows FAQ

RTPatch への一般的な御質問に対する回答です。

注意: ここで説明するコマンドや問題は、すべてオンライン ヘルプに含まれています。特定のコマンドや問題についての詳細は、オンライン ヘルプを参照してください。


RTPatch for Windowsの FAQ:

  1. Patch Apply はどのようにしてパッチを当てるファイルを検索するのでしょうか?
  2. パッチ適用のオプションにはどのようなものがありますか。
  3. パッチを適用するためには、どんなファイルを配布する必要がありますか?
  4. パッチを作成して、自分のシステムで適用テストをしています。"Files in new system are already up-to-date" (新規システムのファイルはすでに更新されています) というメッセージが表示されますが、実際にはアップデートされていません。
  5. システム内のファイルがアップデート ディレクトリのサブディレクトリに追加されるはずなのに、アップデート ディレクトリに追加されてしまいます。
  6. patchbld.exe コマンド ファイルのサンプルはありますか?
  7. ユーザがさまざまなバージョンを使っていて、誰がどのバージョンを使っているのか分かりません。1 つのパッチですべてのユーザをアップデートできるでしょうか?
  8. パッチ ファイルのサイズを小さくするにはどうしたらよいでしょうか?
  9. 開いているファイルまたはロックされているファイルにパッチを当てることはできますか?
  10. 同じファイルの複数のコピーをアップデートするにはどうしたらよいでしょうか?
  11. レジストリや初期化 (ini) ファイルをアップデートするにはどうしたらよいでしょうか?
  12. パッチ適用処理中に外部プログラムを実行するにはどうしたらよいでしょうか?
  13. 作成した履歴 (History) パッチの設定が個別に作成したパッチ ファイルの設定と同じでないのはなぜでしょうか?
  14. 作成した EZPatch ファイルの設定が、バインドから解放されたパッチ ファイルの設定と同じでないのはなぜでしょうか?
  15. RTPatch が違うファイルにパッチを適用てしまう可能性はありますか? また、対象のファイルを壊してしまう可能性はありますか?
  16. HowPatch Build はどのようにファイルを比較するのでしょうか?
  17. EZPatch のブラウザ ダイアログで、異なるファイル セットを表示するにはどうしたらよいでしょうか。また、ユーザが [Files of type] ダイアログを変更できるようにするにはどうしたらよいでしょうか。
  18. エンド ユーザのインストール用にインストール内容を CD-ROM に落としたところ、長いファイル名を持つ ADD (追加) パッチが 8.3 形式になるように切り捨てられました。何が起こったのでしょうか?
  19. RTPatchのパッチ適用（APPLY）時に出力されるメッセージを日本語化する方法は無いでしょうか？


Q1:    Patch Apply はどのようにしてパッチを当てるファイルを検索するのでしょうか?
A1:    パッチを当てるファイルの検索方法には、いくつかオプションがあります。オプションによっては、コマンド ラインまたはブラウザのダイアログを使用して、アップデートするディレクトリをユーザが指定する必要があります。ファイルや ini キー、レジストリ キーをユーザのシステムで検索してパッチを当てる、ユーザによる入力が必要ないオプションもあります。

コマンド ラインから patch.exe または patchdos.exe を実行する場合は、アップデートするディレクトリをコマンド ラインで指定する必要があります。この場合、Patch Apply は、パッチを当てるファイルを次の場所で検索します。
  1. ユーザが指定したアップデート ディレクトリ、指定がない場合はカレント ディレクトリ
  2. アップデート ディレクトリのサブディレクトリ
  3. PATH 環境変数でリストされているディレクトリ
2 の場所にあるファイルと 3 の場所にあるファイルの検索は、patchbld コマンドまたはパッチ オプションを使って切り替えることができます。NOSUBDIRSEARCH を使うとサブディレクトリでの検索がオフになり、NOPATHSEARCH を使うと PATH 環境変数にあるディレクトリでの検索がオフになります。後者のコマンドは、自分の開発用マシンでパッチの適用をテストする場合に特に便利です。この場合、アップデート対象プログラムが最新の形式で PATH に存在するため、対象のディレクトリにあるファイルは更新されません。パッチにある更新済みのファイルが検出され、ファイルはすでに更新されているので作業の必要がないとみなされます。NOPATHSEARCH はこの動作を防止します。

NOSUBDIRSEARCH は、アップデート ディレクトリのルートと、パッチ作成時の NEWDIR に関連したパスと同じアップデート ディレクトリに関連したパスだけを検索するように指定します (NEWDIR の指定に /f を使用した場合)。たとえば、次のようなディレクトリ ツリーがあると仮定します。
  • VER1\
  • 　file.1
  • 　SUB1\
  • 　　file.2
  • 　SUB2\
  • 　　file.3
  • VER2\
  • 　file.1
  • 　SUB1\
  • 　　file.2
  • 　SUB2\
  • 　　file.3
使用するコマンド ファイルは次のとおりです。
  • OLDDIR VER1 /s
  • NEWDIR VER2 /f
  • FILE *.*
  • NOSUBDIRSEARCH
次のディレクトリ ツリーにパッチを適用します。
  • APPLY\
  • 　file.1
  • 　SUB1\
  • 　　file.2
  • 　SUB2\
  • 　　file.3
NOSUBDIRSEARCH コマンドを使用したにもかかわらず、file.2 と file.3 もアップデートされます。これは、これらファイルが NEWDIR にあったときと同じ関連パス内にあり、かつ /f が使用されているためです。

アップデート対象のファイルが複数のディレクトリにある場合、パッチは、追加ディレクトリを示す SYSTEMTAG ファイルを検索します。1 つのパッチ ファイルに SYSTEMTAG ファイルをいくつでも関連付けることができます。パッチは、カレント ドライブ、すべてのローカル ドライブ、システム上のすべてのローカル ネットワーク ドライブまたはすべてのマッピングされたネットワーク ドライブを検索し、SYSTEMTAG ファイルの有無を調べます。SYSTEMTAG 検索を使うと、システムが複数のディレクトリに散在している場合や複数のドライブにまたがっている場合でも、パッチを適用することができます。さらに、この検索は自動的に行われるため、ユーザはアップデート ディレクトリを指定する必要がありません。SYSTEMTAG 検索は、EZPatch 自己適用型パッチ ファイルや 16 ビットまたは 32 ビットの apply DLL など、あらゆるパッチ適用メソッドと連動して機能します。

SYSTEMTAG を理解するには、異なるシステムの一部となるようにファイルを指定するファイル作成時のプロセスについて、よく理解しておく必要があります。作成時にはファイルをグループ化しますが、これはエンド ユーザのシステムに存在するファイル グループに基づいて行います。

systemtag というファイルは、アップデート対象のファイルと必ず同じディレクトリにあり、そこにしか存在しません。systemtag ファイルを使用して、アップデート対象ファイルの 1 つを指定したり、アップデートしないファイルを示したりできます。あるディレクトリをアップデート ディレクトリとして指定し、追加のディレクトリは systemtag を使って検索することもできます。また、単に 1 つのディレクトリを systemtag で検索することもできます。最後の 2 つの方法では、アップデート ディレクトリをユーザが指定する必要はありません。

たとえば、program.exe というファイルをアップデートすると仮定します。この場合、patchbld コマンド ファイルには次の内容が含まれます。
  • BEGINSYSTEM
  • 　FILE PROGRAM.EXE
  • 　SYSTEMTAG PROGRAM.EXE
  • 　NOCONFIRM
  • ENDSYSTEM
SYSTEMTAG は必ずしもパッチを当てるファイルと同じである必要はありませんが、必ずシステムで固有のファイルにします。カレント ドライブで SYSTEMTAG が検索され、SYSTEMTAG が見つかると、そのディレクトリにある program.exe にパッチが当てられます。EZPatchSearchAll コマンドを使用している場合、または RTPatchApply 関数に "-d**" を渡す場合は、すべてのローカル ドライブおよびすべてのネットワーク ドライブで SYSTEMTAG が検索されます。

パッチ適用プロセスで、レジストリまたは ini ファイルにあるキー値を使用してパッチを当てるファイルを検索することもできます。アップデート ディレクトリまたは特定のシステム ディレクトリは、エンド ユーザのマシンにあるレジストリまたは ini ファイルから取得されます。パッチを当てるファイルの検索にこれらの方法を使用すると、エンド ユーザはアップデート ディレクトリを指定しなくて済みます。エンド ユーザの技術的な知識が高くなく、ソフトウェアがインストールされているディレクトリが分からないような場合に、この方法が有効です。

patchbld ROOTKEY コマンドおよび SYSTEMKEY コマンドを使用すると、ソフトウェアがインストールされているディレクトリを、レジストリまたは ini ファイルから取得することができます。ROOTKEY は、レジストリまたは ini ファイルから、メインのアップデート ディレクトリを取得します。SYSTEMKEY は、SYSTEMTAG と似た方法で、追加のアップデート ディレクトリ (またはメインのアップデート ディレクトリ) を取得します。

作成スクリプトで ROOTKEY を指定すると、Patch Apply は対象マシンのレジストリで指定のキーを検索し、そこに格納されている値をアップデート ディレクトリとして使用します。また、ini ファイルにあるキーからアップデート ディレクトリを取得するように ROOTKEY を指定することもできます。ROOTKEY には特定の構文があり、『User's Manual』に記載されています。

SYSTEMKEY は、指定のレジストリまたは ini ファイルにある特定のシステムに関連付けられたファイルを検索します。SYSTEMKEY の使用方法は、SYSTEMTAG とよく似ています。SYSTEMTAG と同様に、SYSTEMKEY を理解するには、異なるシステムの一部となるようにファイルを指定するファイル作成時のプロセスについて、よく理解しておく必要があります。作成時にはファイルをグループ化しますが、これはエンド ユーザのシステムに存在するファイル グループに基づいて行います。

SYSTEMKEY コマンドは、いくつでも使用できます。SYSTEMKEY コマンドを使用すると、1 つのアップデート ディレクトリの検索 (使用方法は ROOTKEY とほぼ同じ) や、複数のアップデート ディレクトリの検索を行うことができます。また、パッチを適用するユーザによって 1 つのディレクトリが指定されている場合は、このコマンドを使って複数の追加アップデート ディレクトリを検索することもできます。

ROOTKEY コマンドと SYSTEMKEY コマンドは、それぞれ ROOTBASE コマンドと SYSTEMKEYBASE コマンドを使って変更できます。これら 2 つのコマンドは数値パラメータを取ります。数値は、アップデート ディレクトリで使用される ROOTKEY または SYSTEMKEY の上のディレクトリ レベルを表します。たとえば、指定された ROOTKEY 内のディレクトリが「c:\program files\mysoftware\bin」であり、アップデートするディレクトリが「mysoftware」であるとします。「ROOTBASE 1」というコマンドを使用すると、ROOTKEY によって指定したディレクトリの1 つ上のディレクトリ レベル (この場合は「mysoftware」) を表すことができます。「ROOTBASE 2」というコマンドを使用すると、「programfiles」がアップデート ディレクトリとなります。 SYSTEMKEY は、SYSTEMKEYBASE コマンドと同じような方法で変更できます。ROOTBASE と SYSTEMKEYBASE の使用例については、「PATCHBLD コマンド ファイル」の例 (後述) を参照してください。

以上のいずれかの方法で正しい名前の付いたファイルが検出されたら、これが正しいファイルであることを検証する必要があります。ファイルのサイズとチェックサムを比較することで、ファイルが検証されます。チェックサムは、数学的公式を使ってファイル内のバイトを組み合わせて算出されます。1 つのファイルについて、名前、サイズ、チェックサムのすべてが一致したら、正しいファイルが検出されたとしてほぼ間違いありません。

ファイル名で検出したファイルがその他の基準を満たさないと、パッチは、残りのディレクトリで正しいファイルの検索を続行します。

FAQのTOPへ
Q2:    パッチ適用のオプションにはどのようなものがありますか。
A2:   
  1. パッチ ファイルとともに DOS コマンド ライン プログラムの patchdos.exe を送ります。
  2. Win32 コンソール プログラムの patch.exe、patch.exe が依存する patchw32.dll、およびパッチ ファイルを送ります。
  3. patchw.dll または patchw32.dll に対して独自の 16 ビットまたは 32 ビットの Windows インターフェースをそれぞれプログラムします。そのプログラム、対応する DLL、およびパッチ ファイルを送る必要があります。 C、Visual Basic、および Delphi で記述された Patch Applyプログラムの例は、製品に備わっています。
  4. 独自の 16 ビットまたは 32 ビットの Windows インターフェースをプログラムし、それをパッチ ファイルおよび対応する DLL に組み込みます。ユーザには 1 つの実行ファイルを送るだけで済みます。
  5. カスタマイズした DOS インターフェースに、パッチ ファイルをバインドします。ユーザには 1 つの実行ファイルを送るだけで済みます。
  6. カスタマイズした Win32 コンソール インターフェースに、パッチ ファイルをバインドします。patchw32.dll は、そのファイルに含めることも、別に送ることもできます。DLL を含める場合は、実行ファイルを 1 つだけユーザに送ることになります。
  7. カスタマイズした Win16 または Win32 グラフィカル インターフェースに、パッチ ファイルをバインドします。適切な適用 DLL は、そのファイルに含めることも、別に送ることもできます。DLL を含める場合は、実行ファイルを 1 つだけユーザに送ることになります。
  8. InstallShield インストール プログラムからパッチを適用する、特別な InstallShield 適用 DLL を使用します。
オプション 5、6、および 7 は、まとめて「EZPatch」と呼ばれています。これらはすべて、パッチ ファイルの「バインディング」プロセスに関連しています。バインディングは、pbind.exe というユーティリティを使って行われます。単純なスクリプトを作成して、ユーザへのメッセージ、パッチを実行するプラットフォーム、DLL を含むかどうかなど、さまざまなパラメータを定義してください。続いて pbind.exe を実行し、パッチファイルを Apply プログラムにバインドします。その結果、自己内蔵式のパッチ ファイル、または外部の適用 DLL に依存する実行形式のパッチ ファイルが作成されます。EZPatch の詳細については、このヘルプ ドキュメントの EZPatch に関する項、または製品とともにインストールされるファイル「ezpatch.txt」を参照してください。

最も一般的に使用されているパッチ適用オプションは、EZPatch のオプションと、DLL に対してカスタム インターフェースを記述する方法です。

FAQのTOPへ
Q3:    パッチを適用するためには、どんなファイルを配布する必要がありますか?
A3:    今後のアップデートでリリースする必要のある RTPatch ファイルは、採用しているパッチ適用方法によって異なります。パッチング用に独自のフロント エンドを使用する場合は、初回のリリースでフロント エンドと patchw.dll または patchw32.dll (フロント エンドが Win16 かWin32 かによって異なる) を配布し、それ以降エンド ユーザのシステムに置いておく必要があります。EZPatch を使用する場合は、初回のリリースで patchw.dll または patchw32.dll を配布するか、またはパッチ ファイルの一部として毎回送付します (後者の場合はオーバーヘッドが大きくなります)。patchdos.exe (コマンド ライン版) を使用する場合は、このファイルを初回のリリースで送るだけです。パッチングのフロント エンドとして InstallShield を使用する場合は、エンド ユーザのシステムに patchw.dll と isrtp16.dll または isrtp32.dll が必要です。これらのファイルは InstallShield のインストールとともに毎回配布することもできますが、各 EZPatch に DLL を含める場合と同様に、オーバーヘッドが大きくなります。一番よいのは、初回に適切なファイルをインストールしてしまい、2 回目以降はパッチ ファイルだけを送ればよい方法を選ぶことです。

FAQのTOPへ
Q4:    パッチを作成して、自分のシステムで適用テストをしています。"Files in new system are already up-to-date" (新規システムのファイルはすでに更新されています) というメッセージが表示されますが、実際にはアップデートされていません。
A4:    PATCH は、 3 つの場所でアップデート対象のファイルを検索します。検索されるのは、コマンド ラインで指定されたアップデート ディレクトリ (アップデート ディレクトリのパラメータがない場合はカレント ディレクトリ)、アップデート ディレクトリのサブディレクトリ、PATH 環境変数にリストされているディレクトリの 3 つです。このいずれか 1 箇所でファイルの新しいバージョンが見つかると、そのファイルにはパッチが適用されません。通常この問題は、PATH にファイルが存在する場合に発生します。PATCH コマンド ラインで /NOP スイッチを使用すると、PATH での検索を無効にできます。アップデート ディレクトリのサブディレクトリでの検索を無効にするには /NOS スイッチを使用します。エンド ユーザのシステムには新しいバージョンがないため、この問題はパッチをテストするときにだけ発生します。

FAQのTOPへ
Q5:    システム内のファイルがアップデート ディレクトリのサブディレクトリに追加されるはずなのに、アップデート ディレクトリに追加されてしまいます。
A5:    バージョン 2.11 以降をお使いの場合は、OLDDIR の指定に /s スイッチを使用し、NEWDIR の指定には /f スイッチを使用してください。バージョン 2.11 よりも新しいバージョンをお使いの場合は、コマンド ファイルのファイル ブロック内で ADDTODIR コマンドまたはADDWITHFILE コマンドを使用して、ファイルが各サブディレクトリに追加されるようにする必要があります。

FAQのTOPへ
Q6:    patchbld.exe コマンド ファイルのサンプルはありますか?
A6:    patchbld コマンド ファイルの注釈付き例をここでご紹介します。コマンド ファイル使用方法の概要が分かるように、広範囲にわたるコマンドや状況を含めてあります。コマンド ファイルはテキスト ファイルで、任意の名前を付けられます。使用方法は次のとおりです。
  • PATCHBLD @
コマンド ファイル内の「#」の後ろにある行は、コメントです。

#サンプル コマンド ファイルはここから始まります。
OLDDIR C:\PROGRAM\VERSION1 /S #古いファイルとして
#version1 を検索し、サブディレクトリ (/S) も
#検索します。

NEWDIR C:\PROGRAM\VERSION2 /F #新しいファイルとして
#version2 を検索し、サブディレクトリも検索します。
#さらに、ファイル (newdir にはあるが
#olddir にはないもの)
#を元のサブディレクトリに追加します (/F)。

FILE *.EXE, *.DLL #.EXE または .DLL 拡張子を持つ
#ファイルだけにパッチを当てます。

OUTPUT VER1-VER2 #パッチ ファイルの名前を PATCH.RTP
#というデフォルト名から変更します。

CHECKTIMEDATE #タイプスタンプ以外に変更箇所がない
#ファイルを、異なるファイルであるとみなします
#(パッチが作成されます)。

ALLOWDUPLICATES #olddir/newdir の別々のディレクトリに
#同じ名前のファイルがある場合にクリーン ハンドリング
#を許可します。

BEGINSYSTEM #アップデート ディレクトリではなくエンド
#ユーザのマシンにある別のディレクトリに置かれる
#サブセットがここから始まります。アップデート
#ディレクトリは通常どおりコマンド ラインで指定され、
#その他のファイルは同じディレクトリで次のように指定
#するタグ ファイルの有無で検索されます。

#別の方法として、他のファイルをレジストリ キーに
#基づいて検索することもできます。この場合は
#SYSTEMKEY を使用します。
  • SYSTEMTAG PROGRAM.DLL #PATCH がエンド ユーザの
  • #マシン上で検索する、アップデート ディレクトリ
  • #以外の場所にあるアップデート対象ファイル。

  • SYSTEMNAME "Programs" #PATCH が systemtag を
  • #見つけたときの確認ダイアログで使われる文字列
  • #("Directory for Programs Directory is
  • #C:\Programs. Confirm? (Y/N)" など)。NOCONFIRM
  • #コマンドを使うと確認ダイアログをオフにできます。

  • FILE PRINTER.DLL, SYSTEM.DLL #メインのソフトウェア
  • #ディレクトリ以外の場所にインストールされている
  • #ファイル。たとえば、Windows Word をインストールする
  • #場合、メインのソフトウェアは C:\WINEDIT に格納され、
  • #.DLL のいくつかは C:\WINDOWS\SYSTEM にインストール
  • #されます。この両方のディレクトリをアップデートしよう
  • #としても、PATCH はコマンド ラインでアップデート
  • #ディレクトリ (この場合は C:\WINEDIT) を 1 つしか
  • #とることができません。PATCH は、SYSTEMTAG ファイルを
  • #含むディレクトリでそれ以外のファイル (ここで名前を
  • #指定されているファイル) を検索します。
ENDSYSTEM #メイン以外のディレクトリのファイル サブセットは
#ここで終わりです。

UNDO #パッチ プロセスがエラーによって失敗したり中断されたり
#した場合、パッチが適用されたまま残らないように指定します。

IGNOREMISSING #パッチ対象ファイルがない場合、またはパッチ
#対象ファイルのバージョンが正しくないためパッチを当てること
#ができない場合に、PATCH が続行するようにします。
#IGNOREMISSING がないと、以上のような状況になったとき
#PATCH はエラー コードを発行して停止します。

BEGINFILE #ここから開始するファイル ブロックに挙げられた
#ファイルは、RTPatch によって特定の方法で扱われます。
  • FILE SERIAL.EXE #特別な処理を指定するファイルを
  • #列挙します。

  • RETAINBYTES D2800H 0030H B2E00H #パッチを当てる
  • #古いバージョンのファイルの特定の範囲を新しい
  • #ファイルでそのまま保持するように、PATCH に指定
  • #します。一般的に、シリアル番号を保持するのに使用
  • #されます。ファイルの特定の範囲が異なる場合の
  • #パッチ適用に特に便利です。この例では、
  • #古いファイルの D2800 で始まる 30 バイト文字列と
  • #新しいファイルの B2E00 で始まる文字列を残すように指示しています。
ENDFILE #このファイル ブロックはここで終わりです。

BEGINSYSTEM #2 番目のシステム ブロック (いくつでも
#指定できます)
  • FILE SUPPORT.DLL, SUPPORT.EXE

  • SYSTEMKEY hklm(software\pocketsoft\program,
  • supportdir) #指定されたレジストリ キーの値は、
  • #このシステム ブロックで指定されたファイルのある
  • #ディレクトリとして使用されます。これは、
  • #SYSTEMTAG を使った追加ディレクトリの検索に
  • #代わる方法です。
ENDSYSTEM

BEGINFILE #2 番目のファイル ブロック (いくつでも
#指定できます)。
  • FILE MAIN.EXE

  • NOIGNOREMISSING #指定されたファイルがない場合
  • #またはバージョンが違う場合にエラーを発行します。
ENDFILE

ROOTKEY hklm(software\pocketsoft\program, maindir)
#指定されたレジストリ キーの値を、このパッチ ファイル
#のメインのアップデート ディレクトリとして使用します。
#このためユーザは、パッチを適用するときにアップデート
#ディレクトリを指定する必要がありません。この方法は、
#ソフトウェアのインストールされている場所をユーザが
#知らない場合に便利です。
NODOCFILE #パッチが作成されたときにドキュメント
#ファイル (.rtd) を作成しません。
#サンプル コマンド ファイルはここで終わりです。

FAQのTOPへ
Q7:    ユーザがさまざまなバージョンを使っていて、誰がどのバージョンを使っているのか分かりません。1 つのパッチですべてのユーザをアップデートできるでしょうか?
A7:    History (履歴) パッチを使用すると、さまざまな古いバージョンを最新のバージョンにアップデートできます。履歴パッチを作成するには、あるバージョンから次のバージョンへ、といった連続したパッチを作成して、それらをすべて 1 つの履歴パッチにインポートします。Patch Apply はシステム内の各ファイルのバージョンを判別できるようになり、この連続したパッチを各ファイルに順番に適用して現在のバージョンにアップデートします。

たとえば、あるソフトウェア製品のバージョンが 3 つあり、ユーザ全員をそれ以降の最新バージョンにアップデートしたいとします。まず、バージョン 1 からバージョン 2 へのパッチ、バージョン 2 からバージョン 3 へのパッチ、およびバージョン 3 からバージョン 4 へのパッチを作成します。これらのパッチを作成するには、patchbld コマンド ファイルを 3 つ (各パッチに対して 1 つ) 記述します。コマンド ファイルは、「@」記号が付いたコマンド ライン上にある patchbld に渡します。

ここでは、ソフトウェアのバージョン 1 は \VERSION1 というディレクトリ、バージョン 2 は \VERSION2 というディレクトリにあるという具合になっており、これらディレクトリの下にはサブディレクトリがあると仮定します。

1 つめのコマンド ファイル (v1tov2.txt) は次のとおりです。
  • OLDDIR VERSION1/s
  • NEWDIR VERSION2/f
  • FILE *.*
  • OUTPUT V1-V2
2 つめのコマンド ファイル (v2tov3.txt) は次のとおりです。
  • OLDDIR VERSION2/s
  • NEWDIR VERSION3/f
  • FILE *.*
  • OUTPUT V2-V3
3 つめのコマンド ファイル (v3tov4.txt) は次のとおりです。
  • OLDDIR VERSION2/s
  • NEWDIR VERSION3/f
  • FILE *.*
  • OUTPUT V3-V4
次に、プロンプトから PATCHBLD.EXE を 3 回別々に実行します。
  • PATCHBLD @v1tov2.txt
  • PATCHBLD @v2tov3.txt
  • PATCHBLD @v3tov4.txt
これで、3 つのパッチ ファイルが作成されました (V1-V2.RTP、V2-V3.RTP、V3-V4.RTP)。

次に PATCHBLD.EXE をもう一度実行し、履歴パッチを作成するように指定します。これは、別のコマンド ファイルを使って行います。

履歴パッチ コマンド ファイル (v1tov4.txt) は次のとおりです。
  • IMPORT V1-V2
  • IMPORT V2-V3
  • IMPORT V3-V4
  • HISTORY
  • OUTPUT V1-V4
patchbld を実行します。
  • PATCHBLD @v1tov4.txt
履歴パッチ ファイル「V1-V4.RTP」が作成されます。このファイルを使って、バージョン 1、2、3 を持つユーザをバージョン 4 にアップデートできます。

FAQのTOPへ
Q8:    パッチ ファイルのサイズを小さくするにはどうしたらよいでしょうか?
A8:    RTPatch は 2 種類のパッチ作成アルゴリズムを使用しています。デフォルトのアルゴリズムは、ほとんどのファイルに対して使用されます。実行可能アルゴリズムは、実行可能ファイル用に最適化されています。どちらのアルゴリズムを使うかは、ファイルの拡張子によって決定されます。.EXE、.COM、.DLL、およびその他いくつかの拡張子の場合は自動的に実行可能アルゴリズムが使用され、その他のファイルの場合はデフォルト アルゴリズムが使用されます。

patchbld コマンド ファイルでコマンド「TYPE E」を使用すると、あらゆるファイルに対して実行可能アルゴリズムを指定することができます。このコマンドは、すべてのファイルに対してグローバルに指定することも、個別のファイルに対して指定することもできます。こうすることで、デフォルト アルゴリズムより実行可能アルゴリズムを使用したほうがよい結果を得られるファイルについて、実行可能アルゴリズムを使用できるようになります。バイナリ データ ファイルの多くは、実行可能アルゴリズムを使用した方が、よりよいパフォーマンスを得られます。

パッチ ファイルのサイズを小さくするトリックは、すべてのコマンド ファイル (履歴コマンド ファイルを除く) でコマンド「TYPE E」を使用することにあります。こうすると、すべてのファイルについて実行可能アルゴリズムが実装されます。実行可能ファイルに限らず、ほとんどのファイルで TYPE E の方がパフォーマンスのよいことが判明しています。また、グローバルに使用すると、パッチ ファイルのサイズが小さくなるケースが多く見られます。

FAQのTOPへ
Q9:    開いているファイルまたはロックされているファイルにパッチを当てることはできますか?
A9:    できます。この方法の技術的な詳細は、次のとおりです。ファイルにパッチを当てるとき、まず対象のファイル名を tempfile に変更してから、この tempfile にパッチが当てられます。パッチが正常に適用されると tempfile は元の名前に戻され、そのため元のファイルは上書きされます。この時点でプロセスが失敗することがよくあります。開いているファイルを上書きすることはできないからです。RTPatch の今までのバージョンではエラー「ept0038」(ファイルの削除エラー) が発生していました。

現在のバージョンでは、次に再起動してからファイルの名前を変更するようにしています。対象のファイルは、再起動したあとは開きません。パッチは、tempfile を元の名前に変更するようにシステムに指示するレコードを記述します。これは読み込みの前に行われます。

EZPatch の「reboot」コマンドを使用していない場合は、ユーザは再起動するように要求されません。「warn」を使用すると再起動を促すプロンプトが表示され、「reboot」を使用すると再起動が実行されます。また、DLL を使用した場合や適切なコールバックを使用した場合も、再起動が要求されます。

FAQのTOPへ
Q10:    同じファイルの複数のコピーをアップデートするにはどうしたらよいでしょうか?
A10:    1 つのファイルを 2 回アップデートするには、次の 3 つを実行する必要があります。
  1. 対象のファイルに対してパッチを 2 つ作成します。つまり、1 つのファイルのコピーが olddir に 2 つ、newdirに 2 つ必要です。
  2. ALLOWDUPLICATES コマンドを使用します。
  3. 対象ファイルのもう 1 つのコピーがアップデート ディレクトリ以外にある場合は、ファイルの検索方法を指定する必要があります。別のファイル (SYSTEMTAG ファイル) の有無に基づいた検索、またはレジストリ キーに基づいた検索 (SYSTEMKEY コマンドを使用) を行うことができます。どちらの場合も、BEGNISYSTEM コマンドと ENDSYSTEM コマンドで区切られたシステム ブロック内で、ファイルのコピーを指定してください。
たとえば、PPP.EXE の 1 つが C:\WINDOWS にあり、もう 1 つがメインのアップデート ディレクトリにあるとします。PPP.EXE ファイルの一方がルートの olddir および newdir にあり、C:\WINDOWS にある方のファイルがサブディレクトリにあると仮定すると、コマンド ファイルは、次のようになります。
  • OLDDIR ver1 /s
  • NEWDIR ver2 /f
  • FILE PPP.EXE
  • 　BEGINSYSTEM
  • 　FILE SUB\PPP.EXE
  • 　SYSTEMTAG
  • NOCONFIRM
  • ENDSYSTEM
パッチを適用するとき、SYSTEMTAG コマンドを使って指定されたファイルがドライブ内で検索されます。ファイルが見つかると、そのディレクトリにある PPP.EXE がアップデートされます。パッチを指定するときに指定された、アップデート ディレクトリにあるもう一方の PPP.EXEも、アップデートされます。

これとは反対に、SYSTEMKEY コマンドを使用して、Windows ディレクトリの場所が格納されているレジストリ キーを指定することもできます。

FAQのTOPへ
Q11:    レジストリや初期化 (ini) ファイルをアップデートするにはどうしたらよいでしょうか?
A11:    レジストリや ini ファイルを変更するには、レジストリ スクリプトを記述して、レジストリや ini ファイル内にあるキーに対してどのようなアクションを取るか指示します。このスクリプトは、パッチ作成時に REGSCRIPT コマンドを使ってパッチ ファイルに組み込まれます。スクリプト内の指示は適用時に実行されます。スクリプティング言語は柔軟性を持っており、レジストリや ini ファイルでさまざまな変更を行うことができます。レジストリや ini の変更についての簡単な説明と例は、次のとおりです。

レジストリや ini ファイルに対する変更は、主に既存のキーの変更、新しいキーの追加、およびキーの削除です。キーを変更または追加する場合は、regscript で、キーを希望する値に設定して行います。キーを削除する場合は、regscript で、そのキーを DELETE に指定します。

たとえば、次のようなレジストリ スクリプトがあると仮定します。
  • hklm(software\pocketsoft\regtest, path1) = STR:d:\testtodo\regtest.gen\apply
  • hklm(software\pocketsoft\regtest, path2) = DELETE


各コマンドの冒頭の 4 文字は、指定されたキーのある場所と関連したレジストリのセクション、または作成する必要のあるレジストリのセクションを示しています。 たとえば、「hklm」は「HKEY_LOCAL_MACHINE」を示し、「hkcu」は「HKEY_CURRENT_USER」を示します。カッコ内にある最初のパラメータは、指定されたレジストリ セクションに関連したキーを示しています。2 番目のパラメータは、キーに関連した値の名前を示しています。このパラメータが二重引用符であって間に何も入っていない場合は、キーのデフォルト値で変更が行われます。「=」記号の右側の値は、指定されたキーおよび値で行われる変更を示しています。「STR」は文字列の値を表し、コロンの後に文字列が続きます。「DELETE」は、指定された値の削除を表します。または、中に何も入っていない引用符が指定されている (デフォルト値が仮定されている) 場合は、キーの削除を表します。そのキーの最後のレベルだけが削除される (上記の例では「software\pocketsoft\regtest」ではなく「regtest」) ことに注意してください。STR と DELETE は、一般的なレジストリの修正を網羅しています。

上記のスクリプトでは、「path1」という値が文字列「d:\testtodo\regtest.gen\apply」に設定され、「path2」という値がキー「regtest」から削除されます。 HKEY_LOCAL_MACHINE に関連したキー"software\pocketsoft\regtest"が存在しない場合は、このキーが作成されます。「path1」が存在しない場合は作成されます。存在するが指定されたのとは異なる値を持っている場合は、指定された値に設定されます。

すべてのレジストリ キーは、デフォルト値を持っています。デフォルト値を変更する場合は、3 番目のパラメータとして、中に何も入っていない二重引用符を hklm に対して指定します (上記の例では path1 または path2)。例は次のとおりです。
  • hklm(software\pocketsoft\regtest,””) = STR;d:\testtodo\tegtest.gen\apply
これで、キー「regtest」のデフォルト値が「d:\testtodo\regtest.gen\apply」に設定されます。
  • hklm(software\pocketsoft\regtest,””) = DELETE
これで、キー「regtest」 (「software\pocketsoft\regtest」ではない) が削除されます。

ini ファイルでも同様に変更を行うことができます。たとえば、次のようなレジストリ スクリプトがあると仮定します。
  • ini(regtest.ini, RTPatch, path1) = STR:d:\testtodo\regtest.gen\apply
  • ini(regtest.ini, RTPatch, path2) = DELETE
カッコ内にある最初のパラメータは ini ファイルの名前を示し、2 番目のパラメータは、ini ファイルのセクションを示しています。3 番目のパラメータは、ini ファイル内のキーを示しています。「=」記号の右側の値は、指定されたキーで行われる変更を示しています。「STR」は文字列の値を表し、「DELETE」は削除するキーを示します。STR と DELETE は、一般的な ini ファイルの修正を網羅しています。

上記の例では、ini ファイル「regtest.ini」の RTPatch セクションにあるキー「path1」が文字列「d:\testtodo\regtest.gen\apply」に設定され、キー「path2」が削除されます。path1 が存在しない場合は作成されます。また、RTPatch セクションが存在しない場合は作成されます。

ini ファイルのあるセクション全体を削除したい場合は、中に何もない二重引用符をカッコ内の 3 番目のパラメータとして使用します。例は、次のとおりです。
  • ini(regtest.ini, RTPatch, ””) = DELETE
これで、RTPatch セクションが regtest.ini から削除されます。

ini ファイルの検索は Windows ディレクトリで行われます。別のディレクトリにある ini ファイルを検索できるのは、ini ファイルがカレント ディレクトリにあったとしても、regscript で ini ファイルへの完全なパスが指定されている場合だけです。regscript で Windows ディレクトリに存在しない ini ファイルを参照する ini コマンドを使用すると、指定されたキーおよび値を持つこれらの ini ファイルが作成されます。つまり、上記の例でいうと、Windows ディレクトリに regtest.ini が存在しない場合は、指定された値に設定された RTPatch セクションと path1を持つ ini ファイルが作成されます。マクロを使用すると、Windows ディレクトリにある別の ini ファイルにある ini ファイルへのパスを検索することができます。

FAQのTOPへ
Q12:    パッチ適用処理中に外部プログラムを実行するにはどうしたらよいでしょうか?
A12:    4 つのコマンド (DOBEFORE、DOAFTER、DOBEFOREALL、および DOAFTERALL) を使用すると、パッチ適用処理中のさまざまな時点で、外部プログラムまたはコマンド ラインを実行できます。これらのコマンドは、それぞれパラメータとしてコマンド ライン (スペースを含む場合は引用符で囲む) をとります。このコマンド ラインは、プログラム、パラメータを持つプログラム、DOS コマンド、バッチ ファイルなどです。

DOBEFORE は、特定のファイル コマンドにパッチが当てられる直前にコマンド ラインを実行します。 DOBEFORE コマンドは、ファイル ブロック内の特定のファイルに関連づけられている必要があります。たとえば「main.exe」にパッチを当てる直前に「serial.exe」というプログラムを実行したい場合は、次のコマンドを実行します。
  • BEGINFILE
  • 　FILE MAIN.EXE
  • 　DOBEFORE "serial.exe"
  • ENDFILE
"$"は、ファイル ブロックで指定されたファイルにも適用されます。上記の例の場合、DOBEFORE のパラメータとして"$"を使用すると、実行されるプログラムは main.exe となります。1 つのファイルにつき 1 つの DOBEFORE しか使用できませんが、パッチにあるファイルの数だけ DOBEFORE を使用することができます。

DOAFTER は、特定のファイルにパッチが当てられた直後にコマンド ラインを実行します。DOAFTER コマンドは、ファイル ブロック内の特定のファイルに関連づけられている必要があります。たとえば「main.exe」にパッチを当てた直後に「serial.exe」というプログラムを実行したい場合は、次のコマンドを実行します。
  • BEGINFILE
  • 　FILE MAIN.EXE
  • 　DOBEFORE "serial.exe"
  • ENDFILE
"$"は、ファイル ブロックで指定されたファイルにも適用されます。上記の例の場合、DOAFTER のパラメータとして「$」を使用すると、実行されるプログラムはパッチを当てられた main.exe となります。1 つのファイルにつき 1 つの DOAFTER しか使用できませんが、パッチにあるファイルの数だけ DOAFTER を使用することができます。

パッチング開始前にプログラムを実行するには、DOBEFOREALL コマンドを使用します。DOBEFOREALL は、DOBEFORE およびDOAFTER と同じ種類のパラメータをとります。DOBEFORE や DOAFTER と異なる点は、ファイル ブロック内で指定されない点です。DOBEFOREALL は、1 つのファイルにつき 1 つしか使用できません。

パッチングがすべて終了した後にプログラムを実行するには、DOAFTERALL コマンドを使用します。DOAFTERALL は、DOBEFORE および DOAFTER と同じ種類のパラメータをとります。DOBEFORE や DOAFTER と異なる点は、ファイル ブロック内で指定されない点です。DOAFTERALL は、1 つのファイルにつき 1 つしか使用できません。

このようなコマンドを使って実行するプログラムのある場所がしばしば問題になります。このようなプログラムは、カレント ディレクトリ、パス上のディレクトリ、またはアップデート ディレクトリで見つかります。さらに、パッチングが開始されたときに解凍され、上記のいずれかのコマンドを使って実行し、パッチが完了すると削除されるようなプログラムをパッチに組み込むこともできます。このようなプログラムを組み込むには、TEMPFILE コマンドを使用します。コマンドの例は次のとおりです。
  • TEMPFILE display.exe
  • DOAFTERALL "display.exe read,me"
上記のコマンドでは、display.exe がユーザのシステム上に解凍されます。すべてのパッチングが終了すると、read.me ファイル (アップデート ディレクトリにある) が表示されます。ユーザが display.exe を終了すると、パッチング処理が終了し、display.exe は削除されます。

注意: RTPatch は、パッチング処理を続行するのに、外部プログラムが終了するまで待機しません。このようなプログラムの実行は、RTPatch にとって完全に外部のプロセスです。

FAQのTOPへ
Q13:    作成したHistory (履歴) パッチの設定が個別に作成したパッチ ファイルの設定と同じでないのはなぜでしょうか?
A13:    History (履歴) パッチを作成するとき、Patch Apply の動作設定は履歴パッチ コマンド ファイルでの設定値にリセットされます。例外は、個別のパッチ コマンド ファイルのファイル ブロックにある特定のファイルに対して行われた設定です。あるコマンドが履歴パッチ コマンド ファイルに表示されないと、そのコマンドのデフォルト設定が想定され、個別のパッチ ファイルのデフォルト設定に加えられた変更が無効になります。これを示す例は次のとおりです。

例 1
  • OLDDIR VER1
  • NEWDIR VER2
  • FILE *.*
  • OUTPUT VER1-VER2
  • NOSUBDIRSEARCH

  • OLDDIR VER2
  • NEWDIR VER3
  • FILE *.*
  • OUTPUT VER2-VER3
  • NOSUBDIRSEARCH

  • IMPORT VER1-VER2
  • IMPORT VER2-VER3
  • HISTORY
  • SUBDIRSEARCH
この例の場合、履歴パッチ ファイルではサブディレクトリの検索が有効になります。コンポーネント パッチ ファイルで SUBDIRSEARCH コマンドが NOSUBDIRSEARCH コマンドに優先しているためです。

代わりに次の履歴パッチ コマンド ファイルがあるとします。
  • IMPORT VER1-VER2
  • IMPORT VER2-VER3
  • HISTORY
この場合も、履歴パッチではサブディレクトリの検索が有効になります。SUBDIRSEARCH がデフォルト設定であるためです。サブディレクトリの検索を無効にする唯一の方法は、履歴パッチ ファイルで NOSUBDIRSEARCH コマンドを使用することです。

例 2
  • OLDDIR VER1
  • NEWDIR VER2
  • FILE *.*
  • OUTPUT VER1-VER2
  • BEGINFILE
  • 　FILE PROGRAM.DLL, MAIN.EXE
  • 　NOIGNOREMISSING
  • ENDFILE

  • OLDDIR VER2
  • NEWDIR VER3
  • FILE *.*
  • OUTPUT VER2-VER3
  • BEGINFILE
  • 　FILE PROGRAM.DLL, MAIN.EXE
  • 　NOIGNOREMISSING
  • ENDFILE

  • IMPORT VER1-VER2
  • IMPORT VER2-VER3
  • HISTORY
  • IGNOREMISSING
この結果生成される履歴パッチは、PROGRAM.DLL と MAIN.EXE 以外すべてのファイルに対して IGNOREMISSING が有効になります。履歴パッチ コマンド ファイルで、ファイル ブロックでの設定が無効にならないように保護されているためです。

FAQのTOPへ
Q14:    作成した EZPatch ファイルの設定が、バインドから解放されたパッチ ファイルの設定と同じでないのはなぜでしょうか?
A14:    Patch Apply の動作設定は、パッチ ファイルをバインドするときデフォルトにリセットされます。pbind スクリプトで設定を指定できるようにするためのコマンドは、いくつかあります。

最も便利なコマンドは OptionFromFile です。このコマンドは、パラメータとしてオプションの文字から成る文字列をとります。オプションの文字が存在すると、対応する設定が、作成したパッチ ファイルでの設定どおりに使用されます。たとえば OptionFromFile 文字列に「c」がある場合は、パッチ ファイルでの confirm 設定 (confirm または noconfirm) が使用されます。「s」がある場合は、パッチ ファイルでのsubdirsearch 設定 (subdirsearch または nosubdirsearch) が使用されます。OptionFromFile 文字列はまた、ファイル ブロック内にある個別のファイルに対する設定の保存も許可します。

ほとんどのユーザが望むように、バインドされたパッチ ファイルのすべてのオプションをパッチ ファイルで指定されているとおりに使用したい場合は、pbind スクリプトに次のコマンドを置いてください。
  • OptionFromFile = cismetpub
これは、各 Patch Apply 動作設定の 1 文字を表しています。

パッチを再作成することなく pbind コマンド スクリプトで Patch Apply 動作設定を設定したい場合は、OptionSet コマンドを使用します。このコマンドを使用すると、パッチ ファイルのオプションすべてを無効にできます。OptionSet は OptionFromFile も無効にします。OptionSet は、カンマで区切られたオプション文字列をとります。この文字列は Patch Apply コマンド ラインでの設定と同じように指定する必要があります。たとえば、次のコマンドの場合を例に取ります。
  • OptionSet = noi, s, nop
この場合、noignoremissing、subdirsearch、および nopathsearch が有効になります。

特定の設定をテストするためにパッチ ファイルを再作成すると時間がかかってしまうときは、OptionSet を使用すると好都合な場合が多々あります。通常、パッチ ファイルを作成するよりバインドする方が処理に時間がかかりません。

ezpatch.txt で説明されている OptionDefault コマンドは分かりにくく、またほとんど使用されていません。特に、このコマンドで行うことのできる作業は OptionFromFile や OptionSet を使用した方が簡単に行えることが大きな理由となっています。

履歴パッチをバインドする場合は、履歴パッチ作成時またはパッチ ファイルのバインド時に設定が再設定されるので注意してください。最もよい方法は、履歴パッチ コマンド ファイルで使用する設定をすべて確認し、上記の説明に従って bind スクリプトで OptionFromFile を使用する方法です。

FAQのTOPへ
Q15: RTPatch が違うファイルにパッチを適用てしまう可能性はありますか? また、対象のファイルを壊してしまう可能性はありますか?
A15: patchbld がパッチを作成するとき、古いファイルと新しいファイルのチェックサムが計算され、両方の値はパッチ ファイルに格納されます。Patch Apply は、パッチを当てる必要のあるファイルと同じ名前のファイルを見つけると、そのファイルのチェックサムを計算して古いファイルのチェックサムと比較します。チェックサムが一致すると、パッチが適用されます。チェックサムが一致しないと、パッチは同じ名前のファイルの検索を続行します。チェックサムが一致するファイルが見つからないと、パッチはエラーを発行してパッチングを停止(IGNOREMISSING がオフになっている場合) するか、警告を発して次のファイルのパッチングを続行 (IGNOREMISSING がオンになっている場合) します。

正しいチェックサムを持つファイルが見つかると、Patch Apply は、対象ファイルのコピーを作成します。続いてこのコピーに対してパッチを適用し、その後にチェックサムを計算します。計算されたチェックサムは、新しいファイル用のパッチ ファイルに格納されていたものと比較されます。チェックサムが一致すると、このコピーは元の名前に変更され、これによって元のファイルが上書きされます。チェックサムが一致しない場合は、エラーが発行されます。

Patch Apply は、ファイルごとにコピー/パッチ/名前の変更を順番に行います。また、オプションで、パッチ対象のすべてのファイルの名前を変更し、パッチを適用し、一度にすべてのファイル名を変更することもできます。この方法には、エラーが発生したときに既にパッチを適用されたパッチが元に戻るという利点があります。つまり、ファイルが足りないなどの原因でパッチがある時点で失敗すると、システムのすべてのファイルは古いバージョンのままになります。この動作は UNDO コマンドを使って有効にします。

RTPatch のチェックサム アルゴリズムを使用した場合、同じチェックサムを持つ 2 つのファイルが違うファイルである可能性は非常に小さくなります。このアルゴリズムによって、違うファイルに誤ってパッチを適用したり、パッチ適用後にファイルが壊れたりすることがないように保証されています。

FAQのTOPへ
Q16: Patch Build はどのようにファイルを比較するのでしょうか?
A16: 基本的なパッチには、modify (変更) パッチ、add (追加) パッチ、および delete (削除) パッチの 3 種類があります。ここではパッチの各種類と、作成するパッチの種類を patchbld が決定する方法について説明します。

  1. 変更パッチは、エンドユーザのマシンにあるファイルの変更を行います。OLDDIR にファイルが存在し、NEWDIR にある同じ名前のファイルと明らかに一致している場合は、デフォルトで変更パッチが作成されます。OLDDIR と NEWDIR の両方にファイルが存在し、それぞれのディレクトリにあるファイルの一致がはっきり確認できない場合は、OLDDIR にあるファイルに対して削除パッチ、NEWDIR にあるファイルに対して追加パッチが作成されます。たとえば、次のような場合です。
    • OLDDIR\
    • 　file.1
    • NEWDIR\
    • 　SUB1\
    • 　　file.1
    • 　SUB2\
    • 　　file.1
    上記の場合では、OLDDIR\file.1 に対して削除パッチが1つ作成され、追加パッチが2つ (SUB1\file.1 用に1つ、SUB2\file.1 用に1つ) 作成されます。
  1. 追加パッチは、エンド ユーザのマシンにある build マシン上の NEWDIR に対応するパスに、ファイルを追加します。NEWDIR にファイルが存在し、OLDDIR にある対応するどのファイルとの一致もはっきり確認できない場合は、デフォルトで追加パッチが作成されます。エンドユーザのマシンにサブディレクトリが存在しない場合は、サブディレクトリが作成されます。
  1. 削除パッチは、build マシン上の OLDDIR にあるファイルのチェックサムと一致するエンド ユーザ マシン上のファイルを削除します。OLDDIR にファイルが存在し、NEWDIR にある対応するファイルとの一致がはっきり確認できない場合は、デフォルトで削除パッチが作成されます。アップデート ディレクトリ ツリーのどこかでこのファイルが見つかると、ファイルは削除されます。

FAQのTOPへ
Q17: EZPatch のブラウザ ダイアログで、異なるファイル セットを表示するにはどうしたらよいでしょうか。また、ユーザが [Files of type] ダイアログを変更できるようにするにはどうしたらよいでしょうか。
A17: 次のコマンドを検討してください。
  • defaultfile = program
  • filefilters = Executable Files&*.exe&DLL Files&*.dll&Text Files&*.txt&
これらのコマンドによって、ブラウザ ダイアログに表示されるデフォルト ファイルは program.exe となり、ウィンドウには「.EXE」というファイルのみが表示されます。[Files of type] には [Executable Files] が表示されます。また、ここにはプルダウン メニューがあり、そこから[Files of type] として [DLL Files] や [Text Files] を選択できます。これらのファイル タイプを選択すると、対応する拡張子を持つファイルだけがウィンドウに表示されます。

FAQのTOPへ
Q18: エンド ユーザのインストール用にインストール内容を CD-ROM に落としたところ、長いファイル名を持つ ADD (追加) パッチが 8.3 形式になるように切り捨てられました。何が起こったのでしょうか?
A18: ファイル名の切り捨てが行われたのは、パッチが適用されるハード ドライブに関する情報に RTPatch がアクセスしなければならないためです。具体的には、そのドライブが長いファイル名をサポートしているか調べる必要があるのです。ただし、パッチ ファイルが適用される時点での現在の作業ディレクトリが CD-ROM ドライブである場合、その CD-ROM ドライブが読み取り専用ステータスであるため、RTPatch は、長いファイル名がサポートされていないとみなします。そのため、長いファイル名が 8.3 形式になるように切り捨てられます。

この問題を避けるには、RTPatch 適用プロセスの直前にある setup.rul ファイルに change directory コマンドを挿入します。changedirectory コマンドによって、現在の作業ディレクトリは、最終的にパッチが適用されるハード ドライブに変更されます。変更先ディレクトリのその他候補としては、インストール apply ディレクトリ (インストールの初期段階で作成される) または SUPPORTDIR が挙げられます。こうすることで、RTPatch は、長いファイル名をそのまま保つために必要な情報にアクセスできます。

また、この切り捨て現象は ADD (追加) パッチのみで発生し、MODIFY (変更) パッチでは発生しないことに注意してください。エンド ユーザのマシンにある、長いファイル名を持つ既存のファイルについては、8.3 形式に変更されません。

FAQのTOPへ
Q19: RTPatchのパッチ適用（APPLY）時に出力されるメッセージを日本語化する方法は無いでしょうか？
A19: RTPatch Pro 7 Windows から簡単に日本語化を行うことが可能になりました。詳細...

FAQのTOPへ
© Copyright 2006. MONET Co., Ltd. All Rights Reserved. RTPatch and Pocket Soft
are registered trademarks of Pocket Soft, Inc. dfc-gorilla is a trademark of Pocket Soft, Inc.
All other trademarks are the property of their respective owners.