※このＨＰで指す”２チャンネラー”とは、【２ch掲示板】の訪問者の全てを指してはいません。

■【田中式処置の理念】■　　---技術的な説明---　　　　　　【2001年８月２５日.更新】

★★★　始.め.に　★★★

●処置の前後で　Ｗindowsの操作性が変化する事は無いハズです。

　　---------------------------------------------------

●まず、【Ｗindows98の不安定・フリーズ・青画面】という言葉について確認しておきましょう。

　一般的な解釈をして下さっても結構なんですが、
　ＰＣ専門雑誌の対談記事で、Microsoft日本法人の副社長が話していた言葉を思い出して下されば結構です。
　『Ｗindows98ユーザーの８割〜９割の方が　動かしている内にフリーズしたり青画面になってしまう』---　という趣旨の話をしていました。
　 上記の説明も含めて、
　皆さんがＷin98を運用するうえで日常的に遭遇している【青画面・フリーズ】を、【Ｗindows98の不安定・フリーズ・青画面】と定義します。

★★★　目　次　★★★

大筋としては次の順番で説明します　（予定）。
　

１．【田中式処置】で　emm386.exe.と.Config.sysを操作する理由

２．msdos.sys.における.DoubleBufferの設定値と【田中式処置】の関わり

３．事前に【シングルユーザ環境】にしておかないと失敗する理由。
　　および、
　　[HK_LM\,,,\Run] キー.と　[HK_LM\,,,\RunServices] キーの 「LoadPowerProfile」.との関わり。
　「スタートメニュー」で「＊＊＊のログオフ」が出現しない状態で実行する理由。

４．次の３つのデバイスを削除してしまうと失敗する理由。
　
　　【プラグ アンド プレイ ソフトウェア デバイス エミュレータ】
　　【アドバンスト パワー マネジメント サポート】
　　【プロセッサ サポート】

５．　　【”ネットワーク関連ユーティリティを.一時的に.アンインストール】してから実行する事の意味。
　　　※↑これらも、守らないと失敗します。

６．【Catrootフォルダ】の　SYSMAST.cbd、SYSMAST.cbk、CATMAST.cbd、CATMAST.cbk、HASHMAST.cbd、HASHMAST.cbk
　　を操作する理由
　　また、c:\windows\INFフォルダの　*.PNFファイルを なぜ　削除するか？---その理由
　
　　　※４.との兼ね合いで、【削除してはならない.*.PNFファイル】もあり、　また、別の理由で【削除してはならない.*.PNFファイル】もあります。

７．HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ASD\Prob　の操作

　◆因みに、【２ch掲示板】で　『実行した』とか、『田中式の手順は〜〜である』とかの手順評論記事を読みますと、
　　上記の項目に関して、ただの１つも、そして　ただの１人も正しく指摘していません。
　　　　（逆の内容で指摘した人間は沢山いますが・・・）
　
　　ここを読んだ後で、彼らは　グチャグチャと能書きを垂れるハズです。
　　入学試験で.【零点】だった人間が、　解答が新聞に発表された後で　参考書と新聞を片手に.能書きを垂れるのと同じです。　（笑）
　　　　（馬っ鹿じゃなかろか。
　　　　　ヨソの掲示板に出向いて”私の悪口”を書いた方が　効果的だと思うけどナ〜・・・。）

■第１節■　【Emm386.exe.の一時無効化】に関して

【田中式処置】では、　デバイス検出を始める再起動時に　Emm386.exe.を無効にします。

　【２ch掲示板】で書かれているように、Ｗindowsにとって　Emm386.exeは重要度が低い事は確かです。
　Ｗin起動時の”コンベンショナル空きメモリ”を大きく稼ぐ程度の効能です。
　ただし、それは　Ｗin98がプロテクトモードで通常動作している時の話です。

　【田中式】のデバイス検出でも　GUI起動してしまえばプロテクトモードですが、
　デバイス検出が開始される時は通常とは少し状況が違うのです。
　　　　※詳細に触れると脇道にそれるので略。
　　　　※以後、初級レベルの話になるので　多少.飛ばして説明。

先に　『コンベンショナルメモリを大きく稼ぐ』--と書きましたが、　具体的には　Emm386.exeによってＵＭＢを確保する動作です。
　この時、拡張カードのメモリ領域に対して　Emm386.exeがアクションを起こします。
　
　この事との関わりで　【総デバイス再検出】の時に.Emm386.exe.が存在するとマズイのです。
　　　（この段階では　Ｗin98は.未だ.プロテクトモードに移行していません。）

　------------------------------------------------------------

『Ｗin98インストーラと.Emm386.exe.だって・・？』---と首をかしげる方もいるでしょう。
　　（通常、フロッピー起動でインストールする時は.Emm386.exe.は組み込まれませんから。）

　　フォーマットしたＣドライブに、
　　【Ｗin98　command_prompt_only】で起動するのに必要なファイルのみをコピーして、
　　Msdos.sysファイルを２項目ほど弄りますと、【Ｗindows無しのＤos】が起動します。
　　この状態でＷinインストールを行なうと.実に上手く行きます。
　
　　Ｗinインストーラは　この時の.Config.sys.等のユーザー設定を活かしてくれます。
　　　　※拡張カードエリアに対する【Emm386.exe.のミス】を回避できるので、
　　　　　クセのあるマザーボードでも問題が起きにくい。
　
　　この時のＷinインストーラの挙動は、Winアップデートインストールの場合も.ほぼ同じです。
　　で、具体的には
　　Ｗin98インストーラは、【デバイス検出】の直前に　Emm386.exe.を【一時的に無効化】しています。
　　　　（【デバイス検出】の直前で　Ｄosで停止させてみると分かります）

◆Ｗindowsにとって　Emm386.exeは重要度が低い。
　
◆【総デバイス再検出】の時に.Emm386.exe.が存在するとマズイ。
　
◆Ｗin98インストーラは、【デバイス検出】の直前に　Emm386.exe.を【一時的に無効化】している。
　
上記３点を根拠として、
【田中式処置】で　デバイス検出を始める再起動時に　Emm386.exe.を無効にするのです。
　そして、
　この事によって.”コンベンショナル空きメモリ＝500KB程度”で　心細いので、一時的に　Buffersの値を小さくして補います。
　　　※私がBuffersの値を調節している事について、
　　　　　２ch掲示板で　【DOSプロンプト　チューニング】であるとして評論した人間もいましたが、アホらしくて説明する気にもなれない。

【参考】　：　Ｗin95インストール時に必要な”コンベンショナル空きメモリ”は　490KBです。
　
【参考】　：　拡張カードを差していないマシンでは　
　　　　　　　【Emm386.exe.の一時無効化】を行なう必要は無いかも知れません。
　
【参考】　：　Ｋ'ｓ氏が【解説版】で何台ものＰＣに処置を施している時に
　　　　　　　うっかり　【Emm386.exe.の一時無効化】を忘れてしまい、『ＥＭＭ３８６のメモリーエラー』が原因で
　　　　　　　途中でハングして止まってしまった事があります。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　⇒　掲示板での報告　（Ｋ'ｓ氏）

　------------------------------------------------------------

◆ここまで説明しても　Emm386.exeに関する【２ch掲示板】での説明を信用する方は、
　　どうぞ　勝手にして下さい。
　　この方は、書いてある”内容”ではなく　”論調”に惑わされる人です。　（この先を読んでも.無駄です）
　
◆【２ch掲示板】で　Emm386.exeと絡めて　私を批判した人間は、　自分が初心者である事を露呈しています。
　承知の上で書いたとすれば、私を中傷する目的で　初心者を騙している事になります。

■第２節■　【Msdos.sys.の　DoubleBuffer値】に関して

デバイスマネージャで、【リソース】タブを参照して下さい。
　
　【田中式処置】を実行した時に、.コンフィグレーションマネージャが　ここの設定を.放棄する場合があるのです。
　どういう場合に.放棄してしまうのでしょう・・・。
　
　　ほとんどのＳＣＳＩカードは.DoubleBufferring.の値を.１.に設定する必要はありませんが、
　　それでも、
　　【SCSIカード　あるいは　IDE拡張カード】を差したマシンで、
　　【Msdos.sys.の　DoubleBuffer値】を　０　に設定した状態で　【田中式処置】を実行すると、そうなる時があります。
　　この事について、
　　私が仕方なく出した結論は　【Ｗindows98のクセ】です。

　　　※以前からＨＰで書いていましたが、
　　　　　Ｗin95初期版では　Scsi.inf.を書き換えてから　”カード検出”や.”Ｗinインストール”をしますと
　　　　　　【無用なDoubleBuffer設定】もされませんし、【設定_放棄】も発生しません。
　　　　ところが　Ｗin98では、
　　　　　マイナーなSCSIカードだけでなく、AdaptecのSCSIカードですら　【設定_放棄】が発生する事があるのです。
　　　　　　　（Scsi.inf.を書き換えても.”言う事”を聞いてくれません）
　　　　Microsoft社がＷin95初期版を発売した時、SCSIカード絡みでの【インストールトラブル】が多かった--と聞きます。
　　　　それで、【SCSIカード・IDE拡張カード】を差したマシンでは　無条件に　DoubleBuffer=1.を設定する仕様に変更されたのではないか・・・と、想像しています。
　　　　　で、【田中式処置】では　通常のＷinインストールとは異なり、人為的な操作を含んでいますから、
　　　　　【DoubleBufferring不要なSCSIカード】であっても　DoubleBuffer=0.に設定してあると
　　　　　コンフィグレーションマネージャが【リソース設定】を放棄してしまう---こう解釈しています。
　　　　　これに関しては、【クセ】ですから　理論ではどうにもなりません。
　　　という訳で、
　　　【田中式処置】では　Ｗin98のクセ（希望）に合わせて　一時的に　DoubleBuffer=1.を設定してやりましょう---という事です。
　　　　　　（それで問題が起きないのですから）

◆私の”DoubleBuffer操作”について、【２ch掲示板】で　色々書かれています。
　
　【SCSIカード.と.DoubleBuffer設定】に関する.基本的な知識.を並べ立てて、私を【低能】呼ばわり.しています。
　確かに、あそこに書かれた.基本的な知識.は間違いではありません。（その通りです）
　しかし、その事と　【デバイス検出時のＷin98のクセ】は　別の話です。
　
　彼らは、　『DoubleBuffer設定とデバイス検出は.関係無い。こんな無関係な設定を操作する田中は.低級だ』---
　という感じで　私を批判しています。
　　　※彼らは　私を批判するに当たって.【反証データ】を示しているでしょうか？　理屈をこねているだけです。
　　　　　マトモな検証もせずに、【反証データ】も示さずに、
　　　　　基礎知識.と　書物をかじった知識.で　専門用語を並べて評論しているだけです。

◆もし　彼らの主張するように
　『DoubleBuffer設定とデバイス検出は.関係無い。こんな無関係な設定を操作する田中・・・低級』であるならば、
　この主張に同意する方々に　答えて欲しい事があります。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　↓
◆Ｗin98インストーラは、【デバイス検出】の直前の再起動時に　DoubleBuffer=２　を設定してきます。
　　（【DoubleBufferring不要なSCSIカード】装着マシン）
　で、
　検出・設定が完了すると、黙って元に戻して　インストーラは.”知らん振り”しているのです。

　　　※マシンの状況によって.多少は.”振る舞い”が異なるかも知れませんが、
　　　　Ｗinインストール途中で【一時停止】させて調べると分かります。

　もし、彼らの言うように、完全に　『DoubleBuffer設定とデバイス検出は.関係無い。・・・』のであれば、
　なぜ、Ｗinインストーラは　こんな事をするんでしょうか？
　　　　　　　　　　　　　　　　　　　（必要無いジャン・・・）
　
　関係あるからこそ　設定されるんでしょ？　------　皆さん、どう思いますか？
　
　これは、理屈ではありません。　厳然たる事実です。
　
　いくら彼らが.理屈を並べても、　仮に　Microsoftのビルゲイツ氏が理屈を並べたとしても、ひっくり返す事は出来ません。
　事実は事実なのです。

つまり、
実験によって得られた”現象報告”に対して　【科学的に謙虚な姿勢】になれるか.なれないか---です。
　
　　　※２チャンネラーは　”最初の第一歩”で.躓いているのです。
　
　　私は、これを積み重ねるスタイルで　他の様々な要素で　未知の実験を.数十回と.繰り返したのです。
　　１項目だけ変化させて　他は全て同じ条件で実験をして、安定度を比較する・・・これの繰り返しです。
　　この時、
　　【別の条件での実験】をする目的で　”元に戻す”場合に、
　　【２ch掲示板】で報告されているような.”レジストリ復旧”と言う.安易な方法では　検証になりません。
　　必ず　その都度　全体を書き戻して復旧させるべきです。
　　これを検証して、誰も気が付かなかった事に気が付き、効果が大きくなるように手法と手順を工夫したのです。

　
　　　※因みに、皆さん・・・秋葉原で書籍をあさっても無駄です。
　　　　　DoubleBufferの値については、１と０について説明されているだけです。
　　　　　マトモな検証もしないで、本を少々かじった程度の知識で、ヒトを批判すると　自分の【低級ぶり】が露呈されるだけです。

◆DoubleBufferについて、最後に、誤解の無いように念を押しておきます。
　
　　Ｗinインストールの時は　インストーラが全て自動でコントロールしてくれます。
　　Ｗinインストールの場合と　【田中式処置】の場合とでは、コンフィグレーションマネージャの.”挙動”.が違うのです。
　　もちろん、ハードウェアウィザードの場合とも様相が異なります。
　　乱暴な言い方をすれば、
　　”挙動”.が違うから　結果が違ってくるのです。

■第３節■　なぜ　事前に【シングルユーザ環境】にしておくのか？

　　[HK_LM\,,,\Run] キー.と　[HK_LM\,,,\RunServices] キーの 「LoadPowerProfile」との関わり。

　結論を先に述べてしまいます。
　次の設定変更を行なってから【田中式処置】を行ない、処置が完了してから.元に戻します。

１．「シングルユーザ使用」の環境にする（その他)。
２．「スタートメニュー」で「＊＊＊のログオフ」が出現しない事を確認する。
３．「ＡＰＭ（電源のプロパティ）」 を 「完全に常にＯＮ(推奨) か、デフォルト」に設定する。

■第４節■　次の３つのデバイスを削除してしまうと失敗する理由。

　　【プラグ アンド プレイ ソフトウェア デバイス エミュレータ】
　　【アドバンスト パワー マネジメント サポート】
　　【プロセッサ サポート】

これについては、次の.５．の【Catrootフォルダ】の項目とも.深く関連しており、　きっちり説明しますと、難解な説明となってしまいます。
また、私自身も　実験を繰り返した結果として【結論】を出していても、
上手く説明できない部分も含んでいます。　従って、サラっと説明するだけです。
まず、上記の３つのデバイスは.【ハードウェア】ではありません。
　　※【アドバンスト パワー マネジメント サポート】は、新しいタイプのＰＣ・マザーボードでは.大体は表示されません。
　　　　”代わりの物”を残そうとは考えない事！。
また、【Power Management Controller】は　ハードウェアであり、”削除＋再検出”の対象デバイスです。

============================================================

【田中式処置】の根本理念として、次の要点が挙げられます。
　　※ちょっと長いですが、
　　　わざと　【田中式】の初期の頃の”発想の原点”に立ち返った説明にしてあります。　この方が　初・中級者の方が興味深く読めると思いました。

１．Ｗinインストール時に汲み上げられなかった情報があるとすれば、
　【ハードウェア情報】を最大限に吸い上げさせれば安定するのではないか？

２．Ｗinインストール時に構築された情報が、
　　【ハードウェアの性能をフルに発揮させるためのスタイル】での構築ではなく、
　　【インストール作業を滞り無く進行させる--という都合】による構築となっている気がする。

３．上位デバイス・下位デバイスという事を考えた時に、
　　Ｗinインストーラの構築では、
　　必ずしも　【土台に近い部分】を優先させるスタイルになっていない部分がある。
　　少なくとも、ＵＳＢコントローラ等は.最後の方で組み込まれるべき物であろう。

４．２、３を考慮して、Ｗinインストーラに干渉させないで、
　　コンフィグレーションマネージャに主役になってもらう形で　何とかして再構築をさせよう。
　　そうすれば、
　　【上位デバイス・下位デバイス】という意味で　それに相応しい位置付けで再構築してくれるのでは・・・。

　　Ｗindows95初期版は.Ｗin98よりも安定しているので、両方のＯＳで同じ事をやって比較してみよう。

５．色々と試したが、ただ単に再構築させようとしても　Ｗinインストーラが構築した時と同じ形態になってしまう。
　　という事は、
　　何かのファイル群が【情報源】.あるいは.【挙動選択の情報源】となっていて、
　　これを.Ｗindowsが参照しているので　何度やっても同じ形態になってしまうのではないか？
　　Ｗinインストール時のハードウェア情報を完全にクリアするだけでなく、
　　この【情報源】も.完全に忘れさせてやる必要がある。

６．色々試しても書籍を探しても判らん。
　　じゃあ、Ｗindowsを壊したり直したりしながら　自分で見つけよう。
　　【デバイス検出・設定】を色々なパターンで行なって、その都度　ファイルの変化を細かく調べよう。

７．ＰｎＰの挙動は判ってきた。　しかし、安定化どころか.もっと不安定になってしまう。
　　理屈どおりに行かないような挙動もする。
　　【Ｗindowsの都合】とか【Ｗindowsのクセ】も考慮してやる必要がありそうだ。

８．削除してはいけないデバイスもあるのではないか？　原点に立ち返って考える必要がある。
　　パターンや手順を工夫する必要もあるだろう。

============================================================

さて、【デバイス認識の再構築】をさせる訳ですが、
再構築をするために　あるタイミングで【デバイス認識の削除】をします。
　　※この時、全てを.”レジストリ直接操作”で行なうとマズイ部分もあって、これは.【Ｗindowsの都合】というヤツで、
　　　Ｗindowsが発展途上のＯＳである事にも関係しています。
　　　【簡易版】をダウンロードして実行する方も、
　　　デバイスマネージャの部分では.多少は考えて処理する必要があるので、判断に迷う人もいるでしょう。


【デバイス認識の削除】をする意味で　セーフモードのデバイスマネージャで削除する作業があるのですが、
【結果を得る】ためには、
【ハードウェア】ではないデバイスを.削除してしまっては具合が悪いのです。
　　※とはいえ
　　　　余分に残してしまうと、今度は.再構築しても.『変化無し』・・・となりがちです。

何か難しいナ〜・・と感じる方は、こんな風に厳密に考えなくても、次のように考えて下さい。

例えば、
　【プラグ アンド プレイ ソフトウェア デバイス エミュレータ】は　”仮想デバイス”です。
　【アドバンスト パワー マネジメント サポート　（ＡＰＭ）】も.そうです。
　【プロセッサ サポート】も　ハードウェアではありません。
　ＡＰＭを例として考えると.中級者の方でも解りやすいでしょう。

”仮想デバイス”とは、
ＯＳの機能として.”仮想的に”デバイスとして組み込まれていて、擬似的にハードウェアの”フリ”をするのです。
　要するに、
　これは　乱暴に言えば、Ｗindowsの一部として動作するソフトウェアなんです。
　で、これを削除してしまったんでは、
　”ハードウェアに密接に関連している”他のソフトウェア部分を.どうするんだ？・・・
　中途半端な再構築をしては　整合性という意味でマズイのでは？・・・
　という問題が生じてしまいます。

　　　新型のマザーボードの場合は　パワーマネンジメント機能が強化されているので、
　　　Ｗindowsが.【仮想デバイス】としてのＡＰＭを組み込む必要が無く、ＡＣＰＩが組み込まれます。
　　　ここでの話題としては、これ以上の説明は不要でしょう。

　【プラグ アンド プレイ ソフトウェア デバイス エミュレータ】に関しては、後から手動で組み込んでやる事もできます。
　しかし、何種類かの方法を試しましたが　結果が伴いません。


◆【プラグ アンド プレイ ソフトウェア デバイス エミュレータ】を削除してはマズイ理由は、もう一つあります。

　このデバイスを削除して　後から組み込むと、　Ｗindowsにおける位置付けが変化してしまい、 “元の位置付け”で組み込むことが不可能です。

　ハードウェアではありませんから、元の位置付けで組み込む必要があります。
　このデバイスは、元々　HKEY_LOCAL_MACHINE\Enum\Root\SwEnum　に配置されています。
　【Enum\Root】に配置されているデバイスは、ＰＮＰ機能が不完全なデバイスです。
　そして、【プラグ アンド 〜〜　エミュレータ】は　擬似的にエミュレーションするための仮想デバイスです。
　ところが、
　　これを削除し、　後で 手動で組み込むと　正しい形では 再生成されず、 Windows98の【パワーマネジメント】の挙動が変調となります。

　　手動で 【再検出・認識】させると　 レジストリ内での配置が 正しい位置付けにならず、
　　“元の位置付け”で組み込むことが不可能。

　　ＩＮＦファイルを改造し、手動で 【再検出・認識】させた場合は、
　　【Enum\Root\System\0000】に配置され、【非ＰnＰデバイス列挙】配下の システムデバイスの“第１デバイス”と認識されます。

　　　　　【Enum\Root\System\0000】・・・ （Enumeration／Root（非ＰnＰデバイス）／System（システムデバイス）

　　本当は、
　　【非ＰnＰデバイス列挙】配下の　【ソフトウェアデバイス列挙 の“第１デバイス”】と認識されるのが正しい。

　　　　　【Enum\Root\SwEnum\0000】・・・ Enumeration／Root（非ＰnＰデバイス）／SoftWareEnumeration（ソフトウェアデバイス列挙）。

　非ハードウェアデバイスであるから、元の配置で組み込む必要がある。
　非ハードウェアデバイスであり　Windows98自身の機能であるから、 【削除〜再検出】させる必要も無い。

----------------------------------------------------------------------------------------------------

◆他にも　【削除⇒再組み込み】すべきデバイスが幾つかあります。例えば　ＣＰＵもそうです。
　　　※これらについては、デバイスマネージャでは表示されない物もあります。
　　　　　　起動Ｄosで処理するしか方法が無いデバイスもあります。
　　　　　　無料の簡易版でも、【自動処理】される部分と.されない部分があります。
　　　　　　【自動処理】の部分をもっと増やす事も出来るのですが、
　　　　　　実験の結果.明らかになった事は　【Ｗin98の都合】と【ＰＮＰの都合】というヤツで　結果が思わしくありませんでした。

----------------------------------------------------------------------------------------------------
◆【削除するデバイス】、【削除しないデバイス】の区別に関して、今.ここで覚える必要はありません。
　　　（手順書に明確に指示してあります。）
　　手順書には.”技術的な解析・解説”は書いてありませんし、
　　皆さんが興味をお持ちであろう・・・との配慮で　解説しているのです。
　　なお
　　参考までに、デバイスマネージャを開いて　【Advanced Configuration and Power Interface (ACPI) BIOS】　は
　　どうするんだい？・・・
　　と、感じる方も多いでしょう。
　　これは.名前がＡdvancedで始まるので　【アドバンスト パワー マネジメント サポート】と混同する人もいます。
　　しかし、これは.【削除＋再検出】の対象デバイスです。
　　　（手順書の中程を御覧ください。）
　　考え方として、【仮想デバイス】は　Ｗin98が.【”ハードウェアのフリ”をするデバイス】として組み込みますから、
　　マザーボードが別種であるからといって　名前が変る事はありません。

　　　　【参考】：”Advanced〜〜BIOS”を”パワーマネジ〜サポート”と勘違いする人が.いらっしゃる事に
　　　　　　　　　　当初　私は配慮が足りませんでした。
　　　　　　　　　　初版の【簡単実行版】では.この事を指示していない事が原因で、残してしまって処置の効果が充分に出なかった方もいました。

■第５節■
　ネットワーク関連ユーティリティを.一時的にアンインストールしてから実行する.理由。

　　これに関しては、　説明が面倒でもあり、基本だけ説明して、続きは　第２ＨＰに廻します。

　前の.第４節.で、【仮想デバイス】は、削除すると具合が悪い〜〜と説明しました。
　で、
　【ダイヤルアップ アダプタ】も　仮想デバイスです。　このデバイスに関しては　一筋縄では行かない要素が多いのです。
　
　単純に考えても、これが組み込まれている場合は　ＴＡ等のハードウェアが組み込まれている場合が多く、
　ハードウェアならば【削除⇒再構築】しようと考えても、ＴＡとペアとして動作する【ダイヤルアップ アダプタ】は.どうするんだ・・・？
　という感じで、【迷宮入り】になってしまいます。

■第６節■　【Catrootフォルダ】の　SYSMAST.cbd、SYSMAST.cbk、CATMAST.cbd、CATMAST.cbk、HASHMAST.cbd、HASHMAST.cbk
　　　　　　　　　　を操作する理由
　　　　　　　　　　（c:\windows\INFフォルダの　*.PNFファイルについても。）
　　　　　　　簡易版を実行するに当たって、CatRootフォルダを考慮に入れる必要はありません。

　さて、いよいよ佳境を迎えました。　第４節の説明を思い出して下さい。　↓

　　　　色々と試したが、ただ単に再構築させようとしても　Ｗinインストーラが構築した時と同じ形態になってしまう。
　　　　という事は、
　　　　何かのファイル群が【情報源】.あるいは.【挙動選択の情報源】となっていて、
　　　　これを.Ｗindowsが参照しているので　何度やっても同じ形態になってしまうのではないか？

◆色々と実験してみて判った事が、　実は　上記の　ＣＢＤ、ＣＢＫ　のファイルがそうだったのです。
　基本的に、これらのファイルを事前に削除しておくことによって、ＰnＰの挙動が変ります。
　この事に気付かずに　そのままにした状態で　他の部分を弄って再構築させても、
　Ｗinインストール時の【ハードウェア認識】と同じ形で.再構築されるだけです。　レジストリ状況も大して変化せず、　安定度も向上しません。
　もちろん　結果を得るためには他の部分も操作しておく事も必要です。

　ＣＢＤ、ＣＢＫファイルが.下記の１〜４の内、どれに最も影響度が深いか・・・
　実は.私も完全には把握できていません。
　ただ、パターンを微妙に変えながら　何回も実験を繰り返してみますと、【関連が深い】事が判明します。

　　ハッキリ言える事は、Ｗindows98が参照したり、状況によって自動的に作り直している事です。
　　【解説版】から　ＣＢＤ、ＣＢＫファイルに関する部分を.抜粋して御紹介します。　⇒　【解説版】からの　ＣＢＤ・ＣＢＫ抜粋テキスト
　　　　　※【解説版】に書いてある説明以外にも　【ＣＢＤ・ＣＢＫに関するＷin98の注目すべき挙動】がありますが、
　　　　　　　ハッキリしないので.【解説版】にも記述していません。

　　実験を自分でやってみたい方は、
　　腕時計とＰＣの時刻を”秒単位”で正確に合わせておいて、時刻（秒単位）とＷin98の挙動を克明にメモする事が必要です。
　　そして、たくさんの”条件”と”結果”の違いを並べて.【比較分析】すると判ります。
　　私も.この実験をず〜っと続けて研究すれば.もっと正確に把握できたでしょう。
　でも、プログラミングした何かのモジュールによって.Win98のＰnＰを操作する事が目的ではありません。
　　これでは　【なぜ　再検出・再構築させるか】---という意味で、本末転倒になってしまいます。

　”Ｗinインストーラは　高度なテクニックによって.【トラブル無し】でハードウェアレジストリを構築している”・・・
　これを止めさせて　即ち、Ｗinインストーラに介在させないで
　最初から最後まで　コンフィグレーションマネージャを主役としてハードウェアレジストリを構築しよう---
　これが　重要なテーマです。
　従って、
　ＣＢＤ、ＣＢＫファイルが　ハードウェア情報を忘れさせる事に深く影響している・・・事、
　そして　【ＰnＰの挙動】を変えさせる事ができれば、それで充分です。
　次に必要なのは【手順と手法】を工夫する事です。

------------------------------------------------------------------------------------------

◆さて、ここで【オサライ】を含めて　テーマを整理しましょう。
　
　　１．Ｗinインストーラに介入させないで.【デバイス検出】をさせて　ハードウェアレジストリを再構築させる。
　　　　　　（Ｗinインストールの時と同じスタイルでの再構築では駄目）

　　２．Ｗin95ライクなデバイス検出をさせる。

　　３．今までのハードウェア情報を完全に忘れさせてから【デバイス検出】をさせる。

　　４．デバイス検出の際に　【ＰnＰの挙動】を変えさせる事が出来るか？

　　５．ハードウェアデバイスと仮想デバイスを見極める。

　　６．【*.pnfファイル】は.”PnPの検出記録ファイル”です。

　　　　●ハードウェアの*.pnfファイルは　デバイス検出させる前に削除しておく必要があります。
　　　　　この判断を間違えると上手く行きません。

　　　　●【*.pnfファイル】とペアとなる【*.infファイル】の中身を調べて、
　　　　　【自動構築されるＩＮＦファイル】と【自動構築されないＩＮＦファイル】を見極める。
　　　　　　◆ハードウェア用のＩＮＦファイルとペアになるＰＮＦファイルだけが削除対象です。
　　　　　　◆ハードウェアのＩＮＦファイルであっても、
　　　　　　　【ハードと拡張ユーティリティを同時に組み込む】形式のＩＮＦファイルの場合は
　　　　　　　”Ｗindowsのデバイス検出”の動作では自動処理されません。
　　　　　　◆Layout.PNF、Layout1.PNF、Layout2.PNF は 削除対象です。
　　　　　　　Layout.inf、Layout1.inf、Layout2.inf 等は　直接には「ハードウェア情報」を含んでいませんが、
　　　　　　　殆どの「ハードウェア用のＩＮＦファイル」から参照されています。
　　　【クリーンインストール＋最小構成のハードウェア】のマシンで処置を行なうのが確実である・・・
　　　　と、以前からＨＰで述べていた根拠は.ここにあります。

　　　７．前の６.に関係しますが、
　　　　　”これから運用するＷin98で【中核的な役割】を担わせる拡張カード”.の.INFファイルは、
　　　　　C:\C_WIN\INF\OTHERに存在する形では駄目です。
　　　　　自動組込みされません。
　
　　　　　【組込み順】と【PCIスロットの差し位置】は　安定度に影響します。（実験の結果からも明らか。）
　　　　　　別な言い方をしますと、
　　　　　　”フロッピーからインストール”とか、”ＣＤ-Ｒomからインストール”で組み込んだ場合、
　　　　　　組込み順が【後回し】になってしまうので、あまり良い結果が得られません。
　　　　　　例えば　SCSIカードを例に挙げれば、
　　　　　　【起動ＨＤＤを接続したＳＣＳＩカード】が　マイナーなＳＣＳＩカードであったり、
　　　　　　自動認識しない新型のＳＣＳＩカードであったり、誤認識するＳＣＳＩカードであったり・・・の場合は、
　　　　　　”８.３ネーム”のままでＩＮＦフォルダにコピーして　ドライバを所定の場所にコピーしておきます。
　　　　　　　　（ドライバのコピー先フォルダは.多くの場合　Iosubsysかsystemです。）
　　　　　　所定のコピー先はINFファイルに書いてあります。
　　　　　　サブデバイスばかり接続するSCSIカードならば【後回しの組込み】でもＯＫですが、
　　　　　　もう１枚.【中核的な役割】を担わせるＳＣＳＩカードを接続しているならば
　　　　　　サブのＳＣＳＩカードも正しく自動認識できる形にしておく必要があります。
　　　　　　　　（この辺の理屈は以前のＨＰに書いていましたネ）
　　　　　従って、Ultra１６０タイプのＳＣＳＩカードを使う方は上記の事前準備が必要です。

　　　●因みに、
　　　　２ch掲示板で指摘された【INFフォルダの*.binファイル】は.大して重要ではありません。
　　　　　（drvidx.binとdrvdata.bin）
　　　　１つは”indexファイル”で、１つは”検出されたデバイス種の一覧データベース”です。
　　　　こんな物はいつでも更新されます。
　　　　例えば、これを削除してハードウェアウィザードを動作させれば作成されます。
　　　　　　（ついでに掃除しておいた方が良いでしょうけど・・。）
　　　　これだけを指摘して『”デバイス再構築させてみた”・・・』と、私を中傷した２チャンネラーがいました。

　　　●先ほど、【組込み順】と【PCIスロットの差し位置】は　安定度に影響する---と
　　　　書きましたが、
　　　　Ｗin98の建前では『そんなハズ無い』という事になっているようです。
　　　　これは、私も正確に説明できません。
　　　　これに関して、２ch掲示板で.【ＩＲＱ】との兼ね合いを説明している人間がいました。
　　　　確かに書かれていた内容自体は正しいのですが、それはまた別の話で、焦点が【ピンボケ】です。
　　　　彼の説明は【マザーボード初級者】向けの説明です。
　　　　結局、彼も【田中式処置の実体】を全く把握しないで.『どうせ大した事やっていないに決まってる』と
　　　　決めてかかっていたので、【初級者】向けの解説をして.【田中式】を論破したつもりになってしまうのです。

■第７節■　HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ASD\Prob　の操作
　　　　　　　　　　および、HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class　の操作

　　　　　　　　　　上記のキーは　２つとも　それほど重要ではありません。
　　　　　　　　　　【無料版】も含めて、
　　　　　　　　　　簡易版では　【クリーンインストールしたＷin98で.サウンドカード無しの環境】であれば、↑これは自動処理されます。

　【２ch掲示板】で　唯一　正しく指摘しているのが、　HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class　です。
　　　　　　（このキーは、いうなれば.【レジストリの入門】部分です。　笑）
　ただし、
　このレジストリkeyの部分は　放っておいても.何とか結果が出てしまう事もあります。
　　（処理した方が良いですが・・・）
　元々、このキーの部分は、Ｗindowsが”呑気に”構えている部分です。
　さらに、　Ｗin95でもＷin98でも　この部分をいくら再構築しても　整然とした形にしても　安定度には寄与しません。
　このキー部分は　Win95でも何十回も実験しています。
　では、このキー部分は.”安定度に全く関係が無い”かと言えば、必ずしもそうでもありません。
　時として.【不思議な挙動】を認められる部分でもあり、【Windowsが組み込む”幽霊デバイス”】に絡んでいる部分でもあります。
　で、これに関してはMicrosoftも解らない--という部分を含んでいます。

--------------------------------------------------

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class　の配下と、
HKEY_LOCAL_MACHINE\Enum　の配下
に関して、　【田中式処置】を行なう前と後を比較しますと　不思議な事が判ります。

【田中式処置を行なう前のＷin98】のレジストリは.非常に整然とした形になっています。

ところが、【田中式処置を行なった後のＷin98】のレジストリは　必ずしも整然としてはいません。
　”幽霊デバイス”も組み込まれています。
　そして、Ｗin95のレジストリにおけるこの部分に　似ています。

　◆ＰＮＰの処理の流れを考えれば、　ＰＮＰ結果として　多少の”幽霊デバイス”は組み込まれても当然です。
　　Ｗinインストーラに任せた時の”ハードウェアレジストリ構造”は　あまりにも整然としていて、不自然です。
　　　（この部分の続きは　第２ＨＰで。）

◆レジストリの【デバイス認識ツリー】が.整然としている事が”良い”か否か・・・。
　　これは説明が非常に面倒です。
　　　第１ＨＰでは　”お茶を濁した説明”の仕方で勘弁して下さい。
　２つの内、１つだけ少し触れます。
　
　　状況が違うので、あまり良い【例】ではないのですが、【サウンドカード無しのＰＣ】で、
　　サウンドカードを接続して再起動した場合を考えて頂ければ　イメージとしては解り易いと思います。
　　この時、Ｗindowsは、【ＩＲＱ割り当て】とか【デバイスツリー】を再配置します。
　　【デバイス認識の構築】は　１発で済ませられるほど単純ではありません。
　　　　（Ｗin95インストール時のDetlog.txtを見ると良く判ります。何度も再配置しています。）
　　Ｗin98でも、
　　【ＵＳＢデバイス】とか.【リアルモード用のＩＤＥコントローラ】の”位置付け”という事を考えれば、デバイス認識の構築が.１発で完了するのはオカシイのです。
　　例えば、幾つかの【幽霊デバイス】が組み込まれる方が.むしろ自然です。
　　何らかの形で.インストーラが介在して、【ＰＮＰ処理が.無難に効率良く完了】するように仕向けているハズです。
　　結果として、
　　Ｗin98インストール処理では　【コンフィグレーションマネージャ】の能力を１００％発揮させてない・・・
　　という事になっているのです。

　　●Ｗindows98が組み込む【幽霊デバイス】は、少なくとも.４種類あります。
　
　　【無料ダウンロード版】の中でも、この内の１つについて.少し説明してあります。
　　補足_MOドライブの「設定チェック」と「ＣＰＵ負荷低減」.txt
　　　　　↑これ、読んで下さい。
　　　　　　　　　　　　　　　　（【無料ダウンロード版】の中にも入っています。　【田中式処置】の手順とは無関係です。）
　
　　ＭＯドライブとＨＤＤを.１つのＳＣＳＩカードに接続している方は、
　　【幽霊デバイス】を.Ｗin98が.どう認識して　その存在意義が何であるか・・・これを体感できます。
　　専門書にも書いてないですが、
　　実に簡単な処理で体感できます。　レジストリの【前後の変化】を見比べると　『あ〜、なるほど』と納得できます。
　　具体的な手順を省略して一言で言えば、
　　デバイスマネージャで　特定の手順の後、
　　【更新ボタン】を押すと　【”無意味なドライブ名”の幽霊デバイス】を.Ｗin98が自動的に組み込みます。
　　で、
　　この【幽霊デバイス】を生成させてやった時の方が、（乱暴に言えば）Ｗin98自体のパフォーマンスが高いのです。
　
　　　　※遅いマシンでないと体感の程度は少ないかも・・・。
　　　　　　（念のため、私の検証は.【田中式処置】の後で行なっています。）
　　　　※速いマシンで体感の程度が小さく、【CPUが速いから関係無いヤ】--と思われるかも知れませんが、
　　　　　　ＣＰＵが速くても　周囲のデバイスも.ＣＰＵパワーの要求程度が上がっていますし、
　　　　　　別の意味で.無視できません。
　
　　ＨＤＤとＭＯドライブの.【同期転送、非同期転送】という事を考えると、
　　この【幽霊デバイス】は.Ｗindows98にとって、『Ｗindowsの都合』によって.必要な物である・・・
　　という事を納得できます。
　　私はWin95OSRは持っていませんが、この変化を.Ｗin95初期バージョンでも体感しています。
　
　　この事からも判るように、【レジストリツリー】が整然としている事は　必ずしも最良であるとは言えません。
　
　　　※ＨＤＤとＭＯドライブの.【同期転送、非同期転送】という事を理解できない方は　納得できません。
　　　　　（すみません。勉強なさって下さい。）

　　●もう一つ.オマケに・・・。
　　　【幽霊デバイス】とは関係ありませんが、面白い実験結果を紹介します。
　　　　【AHA-2940】（無印）というSCSIカードがあります。　世代遅れですが、ベストセラーですから使っていた方も多いでしょう。
　　　　このSCSIカード、Win98の自動認識では."Adaptec AHA-2940U/AHA-2940UW PCI SCSI Controller".として認識されるのは皆さんが御存知の通りです。
　　　　　（Windowsはコントロールチップで認識しますから。）
　　　　で、ずいぶん前　アダプテック社に尋ねた事があります。
　　　　【これで良いのか？。　何か問題ないのか？】---と。　回答は、【そのままで問題ありません】でした。
　　　　確かに、その通りで何の問題も起きないようです。
　　　　で、私は実験してみる事にしました。
　　　　Ｗin98が【AHA-2940】を正常に認識できる【認識名】は何種類かありますが、
　　　　この内　「最もふさわしいだろう」--と.私が感じていた."Adaptec AHA-294X/AIC-78XX PCI SCSI Controller"という認識名
　　　　で.認識させた場合と比較してみる事にしました。
　　　　認識の変更は.デバイスマネージャで普通に”手作業”で行ないました。　（この時の実験記録は保存してあります。）
　　　　勿論マルチタスクで.【負荷】の高い作業をさせます。
　　　　そして、”鬼門”と言っては大袈裟ですが、
　　　　Win98が.【デバイスカテゴリ】を持たなくて、かつ.”ＣＰＵ占有率の高いデバイス”として　ＭＯ書き込みも同時に行ないます。
　　　　で、
　　　　ＨＤＤとＭＯドライブに、大量のコピー作業を.一気に実行させるのです。（自動で）
　　　　途中でＭＯが一杯になったら削除して再びコピーさせます。　このテストを、２種類の認識名の場合で、それぞれの所要時間を調べます。
　　　　　（勿論　Ｗin98はクリーンインストールで、２つの環境は全く同じにします）
　　　　で、結果は.どうなったか・・・・。
　　　　"Adaptec AHA-294X/AIC-78XX PCI SCSI Controller".で認識させた時の方が、５％〜７％程度　早く処理が終わるんです。

　　　　　　※上記の実験は　【田中式処置】とは直接には関係ありません。
　　　　　　　　このSCSIカードを使っている方は実験してみてはイカガでしょう。

--------------------------------------------------

Ｗindowsが組み込む”幽霊デバイス”について論じますと　キリがありませんし、
トータルで理路整然とした解答を出す事は至難の技ですし、【田中式処置】の本論から外れていきます。

”幽霊デバイス”と.【Ｗin98のパフォーマンス】、【Ｗin98の安定度】とに関連があるのは確かで、
　【処置後に幽霊デバイス】を削除しないで下さい。---と、補足説明をしています。

　”幽霊デバイス”らしき物としては、　【リアルモード用の認識デバイス】もあり、　ＰＮＰ処理の”残骸”として残った【認識デバイス】もあります。
　まだ他にもあります。
　この具体的な例として、製品版の”オマケ解説”で説明している、【ＣＰＵ占有率とＷinパフォーマンス】のお話があります。
　これに関しては、
　具体的に【これを〜〜の手順で操作してみて下さい。Ｗinのパフォーマンスが違うハズです】--と書いています。
　この”オマケ解説”は　パフォーマンスに焦点を当てているのではなく、
　Ｗindowsが”幽霊デバイス”を組み込んでいる時の方が.Ｗinパフォーマンスに優れる実例として　”【眼で確認】する形で体感”して頂く・・・
　という意味で書いています。
　　（”オマケ解説”は.色々あるので、これも含めて第２ＨＰで幾つか御紹介します。）

-----------------------------------------------------------------------------

●HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ASD\Prob
　 も含めて、　他の項目についても　第２ＨＰで解説する予定だったのですが、
　 『田中氏に関われば　２ｃｈ掲示板に関わることになるのでは？』--- と心配する人やら　　【田中式処置】を頭から疑う人ばかりで、
　 これ以上　解説する気になれません。　　ここまでで解説は終了です。
　 頭から疑っている人間に　何を説明しても無駄です。
　 このページは　“誹謗・中傷”で精神状態がマトモではない頃に作成した物で、解説として整理されていません。
　 内容的にも　補足した方が良い部分もありますが、もう馬鹿々々しくて　出来ません。

疑うのは本人の勝手です。　疑う人は、最初から　こんなページを読む必要はありません。