今日の必ずトクする一言-- TODAY'S REMARK --
今日の必ずトクする一言以前から本ページでは、
●トラフィックを絞り出す乾いたモデムのナゾ
●山本式スーパーステルスノイズインシュレーターのナゾ
●アナログモデムの限界性能をさぐる(K56flex編)
●PPP接続をロハで高速化する方法のナゾその２
●PPP接続をロハで高速化する方法のナゾ
でアナログモデムからトラフィックを絞り出すトピックを紹介してきた。今回は同じ手法でADSL環境を最適化する事を考える。
現在の回線にはいろいろな種類のパケットが混載されている。そして回線の主流はEthernetのような搬送波検出多重アクセス/衝突検知(CSMA/CD)というしかけである。機器は回線が使用中かどうかを検出してパケットを送り出す。回線が使用中ならランダムな時間待ってパケットを送出する。もし出会い頭にパケットが衝突したら、衝突事故を全ての機器に知らせ、その後ランダムな時間待って再度パケットを再送する。
パケットのデータ(MSS)にはヘッダー（40bytes）が付くので、なるべく多くのデータを送るにはパケットサイズ(MTU=MSS+40)は大きい方が良い。しかし低速の回線ではパケット送出の時間が長くなり、その途中でパケット衝突やノイズで失われることがある。そこで、有線モデムではMTUが576bytes、Ethernetでは1500bytesが使われる。
使用中の回線の至適パケット長はWindows付属のpingで確かめることができる。例えば４つのDOS窓で同時に
ping XXX.XXX.XXX.XXX -t -l 576 ping XXX.XXX.XXX.XXX -t -l 1000 ping XXX.XXX.XXX.XXX -t -l 1454 ping XXX.XXX.XXX.XXX -t -l 1500
を実行して反応を確かめる。xxx.xxx.xxx.xxxは使用頻度の高いサーバーのIPもしくはドメイン（例えばwww.xxx.co.jp）を指定するが、1500以上のサイズを指定するとサーバーをダウンさせることがある。WebmatserのADSL環境では図のような反応だったので1500を選択した。
さらに数字を追い込むにはまず後述のレジストリーを導入してMTUを1500にセットする。次に
ping xxx.xxx.xxx.xxx -l 1472 -t -f
ここで1472は1500-28(pingのヘッダー）で、実際のパケットサイズがちょうど1500になる。これでfragmented（パケットが分割されたこと）と表示されなかったら、MTU=1500がそのまま届いていることになる。もしfragmentedと表示されたら、そうならないまでpingの値を減らし、それに28を加えた数字をMTUとして採用することになる。グローバルIPを貰っている場合はMTU=1500が適当だろう。
回線には速度やノイズ、混み具合の他に遅延という大事なパラメータがある。例えば人工衛星の回線は高速で低ノイズだが遅延が大きい。従ってパケットを送って、相手からの届いたよ(ACK)を待っていると能率が悪い。
そこで受け側は複数の１個ないし２個パケットを受ける度にACKを返す。複数のパケットからのデータを収容するバッファーのサイズがRWINで、MSSの整数倍が使われる。RWINは低速で遅延の少ない回線では小さく、高速で遅延の大きな回線では大きくなる。また遅延が不定の場合は小さくする必要がある。機器によっては回線の状態によってパケット長やRWINを変更するものもある。
そこで使用中のADSL環境でのRWINと転送速度の関係を調べてみよう。Win9XのRWINを変更するには、
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP] "DefaultRcvWindow"="17520" "Tcp1323Opts"="0" [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000] "MaxMTU"="1500"のようにレジストリーに導入する。Win9Xの標準は1460(=1500-40)の６倍のRWIN=8762になっている。例えばRWIN=17520を導入するとMSSの12倍になる。またMaxMTU=1500の値は各\NetTrans\Ethernet\000Xにも導入する必要がある。ただしPPPoEの場合はMTUは1492以下に設定し、ネットワークによっては1454以下にする必要がある。その場合のRWINはMTU-40を整数倍したものになる。Win95ではこの操作の前にwinsock2を導入しておく必要がある。
レジストリーの変更は面倒なので、1500x6倍(win9X標準）、1500x12倍、1500x18倍、1500x24倍、1454x6倍、1454x12倍、1454x18倍、1454x24倍の設定ファイルををダウンロードし、クリックして導入後に再起動する。
さてRWINをMTU=1500の６倍、12倍、18倍、24倍に設定し、ADSL実験室の各プロバイダーの測候所との間で1MbytesのJPEGファイル転送速度を測ったのがグラフである。トラフィックがまばらなほぼ同時刻に計測したものだが、ネットワークトポロジーも関係するので、あくまでも傾向を見るための参考値である。
データのように、遅いプロバイダーでは12倍以下に、並のプロバイダーは12倍付近に、そして速度に余裕のあるプロバイダーは18倍以上にピークがある。
この結果からWebmasterはRWINをMSSの18倍にしているが、それが至適値とは限らないようだ。確かに相手が高速のサーバーの場合は大きくした方が早いが、テレホーダイの時間帯にはRWINは12倍の方が通りが良い。これは混雑のために遅延が発生し、RWINが大きいとACKが通りにくくなるからだろう。ACKが帰ってこないとパケット喪失＋待ちぼうけのペナルティーだけでなくtcp/IPのslow start機構や輻輳制御によりRWINが減らされ、さらなるペナルティーが加わる。RWINが過大だと損である。
このようにADSL実験室による帯域とネットの反応は必ずしも比例しない場合がある。最大転送速度が得られなくてもMTUが小さい方が反応が良い場合もあるので、パソコンのベンチマークと同じように、ピーク性能よりは常用での最適値を探るべきだろう。
ところで、米国におけるADSLやケーブルモデムの至適化は今回のネタ元であるspeedguide.netに詳しいが、そこのRWINパラメーターは日本より一桁以上大きい。
どうやら極東のIT開発途上島国の通信バックボーンはRWINにして１桁相当分以上遅れてしまったようである。その責任の多くは”みかか”にあると考える人が多いようであるが、あなたはどう思われるだろうか。
このページでADSLを最初に取り上げたのは４年も昔だ。それは、
というものであった。Webmasterは中長期的にはADSLが主流になると読んでいたので自宅の回線は敢えてISDNにしなかった。Webmasterは数カ所でISDNを設置してきたが、どれもスピードはモデムと大差なく、唯一のメリットは接続が速いことだけだった。２回線のアナログ電話機が使える事も携帯電話があればさしたるメリットにはならない。
ADSLの普及にありとあらゆる妨害をしてきた”みかか”も方針変更でフレッツADSLをプッシュ中ということになっているが、依然として腰が引けている。先進的ユーザーの中にはアナログからISDN、再度アナログへの再々度変換で不愉快な思いをしたケースも多いと聞く。簡単なADSLのセットアップを見てしまうと、ISDNの複雑な設定はいったい何だったんだろうと思う。
ADSLのシステムは非常に単純なものだ。契約者は電話線にスプリッターを入れ、電話局でも主配電盤と交換機の間にスプリッターを入れる。スプリッターは電話用の音声周波数(4KHz以下)とそれ以上を分けるフィルターである。そして電話局内に設置したADSL集合モデム(DSLAM)からネットに繋がっている。つまり契約者から電話局への電線を借りてモデム同志が繋がるだけで、交換システムとは全く独立している。
従ってISDNと違いモデムの故障や停電は電話に影響しない。スプリッターも単なるフィルターなので雷の直撃でも受けない限り故障しない。つまりインフラが弱く規制産業がはびこるIT発展途上国（日本を含む）向きのシステムである。またモデムもグローバルに調達できるので、DDファミリー日本局地規格による弊害も軽い。
Webmaterはそのポリシーを評価して、Ｔ京めたりっくと並んでADSLに注力している老舗のこちらと契約した。速度は1.5Mbpsだが静的なグローバルIPを一個貰えるのがミソである。他にモデム/ISDN接続の口座や100MBytesのHPスペース、２個のメイルアドレスがオマケである。ここ福岡ではフレッツADSLは３ヶ月待ちらしいが、こちらは１ヶ月弱の待ちであった。
セットアップは非常に簡単だ。まずスプリッター（電話帯域とADSL帯域を分けるフィルター）をなるべく電話線の上流に介在させるだけである。スプリッターからの電話線をADSLモデム（WESTELL 316R516）につなぎ、電源をONすると数秒のネゴ後にコネクトランプが点灯する。
あとはモデムとパソコンを10BASE-Tでつなぐ。パソコンには指定のグローバルIP、ネットマスク、ゲイトウェイIP、DNSのIPを設定する。グローバルIPのためフレッツADSLのように認証のための余計なPPPoEソフトは要しない。契約者は電話局から直接電線（首輪）で繋がっているから認証は不要なのである。もちろん固定したIPにはそれなりのセキュリティーも必要になる。
２カ所から同時にftpをかけて下りのスピードを測ってみると、coara、DTI、OCN、So-net、Biglobe、Plara、ATT、asahi-net、kcomなどのADSL速度測候所に対して70から120kBytes/secであった。特にMTUなどのパラメーターをいじっていないが、規格の1.5Mbpsからすればまずまずである。
実際には以前登場した有線/無線LAN付ルーターを使っている。WAN側にグローバルIPを割り振り、LAN側のDHCPサーバーがクライアントにローカルIPを割り振りIPマスカレードが働らいているので、簡単なファイヤウォールになる。クライアント同志のファイル/プリンター共有はNetBEUIの方が無難だろう。ADSL＋無線LANはかなり極楽で、時代遅れノートパソコンが高速モバイル端末に一変する。
現状では100kBytes/secプラスがADSLの実力だが、モデムは8Mbpsまで対応しているので、中期的には10BASE-Tや無線LAN(11Mbps半二重)に近い速度が期待できる。しかしWWWサーバーにとって100kBytes/sec以上を持続するのは苦しい。ここ数年はADSLよりはネットやサーバーの帯域の方が実用上のボトルネックになるだろう。光ファイバー(FTTH)は導入コストを含めてADSLより安くなるまではあわてて乗り換える必要は無いように思う。
”みかか”は今後もADSLには三味線を弾きながらFTTHをプッシュするだろう。いや、ADSLユーザーのいない所から問答無用で電線をファイバーに置き換える可能性があるので、政府は予めその変換時期は公開するように求めているが、守られるだろうか。少なくとも、ADSLの簡単なセットアップと速度を知ってしまった個人ユーザーが急いでFTTHに走る理由は全く無い。一旦ADSLが普及した地区をFTTHに変換するには、”みかか”がユーザー設備更新のコストを負担しなければ、契約者は納得しない。
前にも書いたように、ADSLは一般的なコンセンサスを越えてしぶとく生き残る予感がする。場所によっては10年は続くのではないだろうか。しばらくは”みかか”の強制ファイバー工事によるFTTH囲い込み、押し込み販売に注意する必要がある。雑誌で”やっぱりFTTHだね”というパブ記事が増えだしたら、ご用心である。
お知らせ
新規リソース獲得により、近々サーバー構成の変更をいたします。追ってお知らせいたします。
June 17
●ホームページUNAGI指数(PAT PEND)のナゾ
以前こちらでウナギの寝床式ホームページの是非を論じてからも、本ページは懲りずにウナギの寝床を踏襲している。その理由として、以下のようなことをWebmaterは主張してきた。
１．現代のGUIでは窓を開く時のオーバーヘッドが大きくレスポンスが悪い。単純な窓でも非常に多くのインスタンスを引く必要がある。だからこそ、それぞれの窓でGUIの作法に則った窓操作が可能なのである。しかし、小さな窓では、窓の中の表示や処理より窓を開く事自体のオーバーヘッドの方が大きいこともあろう。
さらに、日本語版のGUIでは漢字フォントやIMEコード、辞書キャッシュのオーバーヘッドが加わる。このためCPU周辺のコード/データのローカリティーが低く、CPUのキャッシュの有効性が低下してレスポンスが悪くなる。一方、一旦開いた窓の上下スクロールは2Dアクセラレーターが理想的に働くから非常に高速だ。このため、多くの窓を開く方式よりウナギの寝床の方がレスポンスが良い。
２．ウナギの寝床式ホームページはサイトの構造がつかみやすい。またメニューにコンテンツの記載を集中することにより、下手にフレームやテーブルを切るよりはブラウザーやネットでの検索効率が良く、また更新しても検索情報が陳腐化しない。
以前からディレクトリーを階層化する事が推奨されているが、Webmasterは必ずしもそれに賛成では無い。もちろん、単一ディレクトリーに多数のファイルを置くと検索性が悪くなる。また、うっかり古いファイルを新しいファイルでオーバーライトしてしまう可能性がある。これはファイル名自体に日付（例えばhiga9802.html)を含める事により解決する。またファイルシステムの原理からして、深い階層化はディスククラッシュに弱い。
３．ウナギの寝床式は更新が簡単である。更新はトップページに記載を追加するだけで、メニュー構造に手を着ける必要が無い。コンテンツは１ヶ月をメドに別ファイルに切り出すが、メニューはそのまま維持する。この作業を常に一定の方法とタイミングで行うことにより、読む方もページがどう変化していくかを予測することができるし、リンク切れも発生しにくい。
とまあ、いろいろ書いたが、詰まるところは手抜きだろう。ランキングを見ても、多くの人気ページが参入しては短時間で消えていく。持続は力なりと言うが、結局サイトが消えてしまうと情報の集積が失われてしまう。ページが長生きするには、更新のスタイルが一定していて、またその労力が過大で無く、かつ過去の集積を失わない工夫が必要だ。
その目で、おそらくネットで最も多く参照される新聞社のページを見てみよう。代表は旭日新聞だろう。イデオロギーに賛成しかねる点が多々あるが、更新が速く力が入っているのは衆目の一致するところである。
それは、まるで日産スカイラインのように、ページ構造の複雑化による失敗とウナギの寝床化への回帰を繰り返していて、今はウナギの寝床フェイズ後期にある。この新聞社の創世記のページの面影は今日の朝刊に残っているが、完全なウナギの寝床式である。個人的には題字をもっと小さくし、トップにメニューが集中していればよいと思う。
今回本ページではウナギ指数(UNAGI INDEX)という新しい概念を提唱したい。これはページの記述部分のアスペクトを数値化したもので単位はUNAGIである。旭日新聞の場合約３UNAGIとなりウナギの寝床最盛期より悪い方に少し戻ったフェイズと考えられる。Webmaterはニュースページのウナギ指数至適値は3.5UNAGIから4UNAGIと考えている。その根拠は後述する。
次の日計新聞は長らく細分化したページにこだわってきたが、最近ついにウナギの寝床化したところである。ここは長らくテーブルや画像の多用できわめてレスポンスが悪く、またリソース喰いのためOSの負担が重かった。それが今はウナギの寝床化によって見通しが非常に良くなっているが、遠目で見ると構造の一貫性は今一つというところである。記述部分は４UNAGIを越えるようで、これは左右のメニューのコラムが過大だからだろう。
次の賣賣新聞だが、イデオロギーは旭日新聞と対照的ながら、ベストだった頃の旭日新聞（ちょっと前）を研究した形跡が見られる。遠目で見てもかなり構造が一貫しており、記載部分のウナギ指数は４前後と好ましい。題字が大きすぎないのも好感が持てる。
最後が毎朝新聞だが、廃れつつあるフレーム使用ということで大減点しなければならない。創世記のJamJamから良く解らないメニュー構造が長らく続いてきたページで、かなりまともになってきたがネット家電やモバイル機器の制約を考えるとフレーム使用は大減点である。しかもフレームに現れる自社広告は陳腐である。
さて快いウナギ指数はどうして3.5UNAGIないし４UNAGIなのだろうか。その例として、英文ではあるが、世界で最も美しい雑誌の一つとされているNational Geographic誌を見てみよう（写真）。もちろん、Webと印刷物、英文と和文という大きな違いがあるが、この位が読みやすいウナギ指数ではないかと思う。蛇足ながら、ここのホームページもたいへん美しい仕上がりである。
いずれにせよ、ギリシャ建築や彫像の黄金分割比と同じように、ホームページにも至適なウナギ指数があると考えられるのだが、いかがだろうか。個人的には和文では必ずしもA4版とのマッチングは良くなく、B5版の方が読みやすい印象がある。
イントルは、ニュースリリースのようにスロット１CPU（SECCカートリッジ）の供給を停止した。この中にはPen-IIIの700MHzから1GHzまでの全ての製品が含まれる。
本ページでは以前よりスロット１は21世紀を迎えられないだろう、と書いてきた。廃止の発表は2001年の５月、ラストオーダーは１１月であるが、2000年夏頃よりスロット１は市販品から消えていたので、おおむね予想は当たったと思う。
ところで600MHzまで生き延びたK6であるが、こちらを見る限り供給は続いている。バスクロック66MHzの大古マシンでも400MHz、75MHzマシンだと450MHz、83MHzマシンだと500MHz、100MHzマシンだと600MHzが期待できる。webmasterの環境ではK6-2+の600MHzドライブの性能はセレロン700MHzを凌ぐので、当分は事務用に困ることはなかろう。
”わかった。確かにソケット７が２１世紀に生き残ったことは認めよう。しかし肝心のPentium-MMX(P55C)は廃止されているではないか。そうしたら、イントル純正品に限ってはソケット７が先に死んだことになるのではないか？”
もっともな御意見である。イントル公式ページを見てみると、確かにMMX(R)テクノロジPentium(R)プロセッサ＊と、廃止の”＊”マークが付いている。
しかしよく見るとその数行下にEmbedded Pentium(R) プロセッサおよびプロセッサ・モジュールがあり、クリックしてみると、懐かしいソケット７(296pin)のP55C（100-233MHz、3.3V/2.8V)の姿を見ることができる。そして市販されなかったバス周波数ｘ４の低電圧版P55C-266MHz(電圧2.5V/1.5V)も供給されている。もちろん、430HXや430TXチップセットもしっかり現役だが、低電圧版CPUではレベルシフターが必要になる。
カタログを漁ると差し替え用の300MHzのP55C（名古屋パソコンパーツ）は確かに存在する。しかしその値段は、更新が難しいFAや組み込み機器しかペイしないだろう。今時4万円台でフル装備の安物デスクトップが買えるからである。
さてパソコンの将来はどうなるだろうか。ご存じのようにItaniumやXeonはサーバー用途に限られるだろう。問題はPentium-4だが、現状の423pinソケット版は今年暮れには古くなるしRDRAMを要するので、よほどパフォーマンスを要する用途以外には勧められない。健全な市場メカニズムが今までと同様に機能すれば、現状のソケット370はあと３年は使えるとWebmasterは予想している。ソケット５／ソケット７程の長寿は期待出来ないが、現状のソケット370の性能、価格、炭酸ガス排出のバランスは悪くない。
すでにパソコンはソフトウェアDVD再生が可能になった時点で次なる目標を失った。とすれば、市場の要求は性能では無くサイズや価格、そして少ない炭酸ガス排出である。チップセットとCPUの統合化がさらに進むだろう。
その形は、おそらく現状の安物USBハブ(金沢パソコンパーツの写真）が一番近いのではなかろうか。いくら無線インターフェースが発達しても最小限のコネクターは必要だ。しかし中身を見ても部品は見あたらないがどこにあるのだろう。探してみると、基盤の裏に隠花植物のように統合チップがCOB(チップオンボード）で貼り付いていることだろう。
そしてそのころ本ページが存続しているかどうかは解らないが、”昔のパソコンはCPUやディスプレーアダプター（死語）を差し替えたりして楽しかったがなぁ。”とPC古老が嘆くことだろう。それを聞いた若者は”ＣＰＵ？アダプター？差し替え？？？いったい何のこと？”と理解できない。
ムリもない。それは現状でUSBハブのCPUを交換する意義が全く無いのと同じだからである。最悪そういったビジョンを予想しておけば、ビジネスを失うことは無かろうと思うが、どうだろうか。
June 3
●風水式レジストリー圧縮法のナゾ(危険な香り編)
Windowsを使っていて気になるのはレジストリーの肥大である。Webmasterはバージョンアップが遅いことでは最右翼であり、無用なお試しソフトなどはメインのマシンに仕込まないようにしているが、それでもレジストリーには無駄な行が忍び込んでくる。
そもそもWin95からは管理情報はsystem.iniとwin.iniに代わってレジストリーに格納されることになっていた。”なっていた”、と書いたのは、肝心なM$がそれを守っておらず、ハードディスク中にインストール情報を書き散らかしているからである。
さらにWinを構成するコンポーネントに整合性が無いことも問題だろう。特にInternet ExplorerやDirect-XはOSを根幹から書き換えるにもかかわらず、アンインストール不可なのでレジストリーが肥大してしまう。さらにWindows Media PlayerやM$-OFFICEが事情を複雑にする。対するJuztシステムはM$と全く異なった小宇宙をレジストリーの中に作り込む。そしてレジストリーが肥大するとシステムのレスポンスが低下してしまう。
もちろん巷にレジストリーを圧縮するノウハウは満ちあふれている。代表的なサイトとしてはRegist"o"ryがある。ここのこだわりは大したものである。
しかし、ここのノウハウを適用してもレジストリーは肥大したままである。それは重複したキーにまったく手がつけられていないからである。そこでレジストリーをハンドアッセンブリするかのように、つましく、かつ抜本的に圧縮する事を考えてみよう。もちろん、本ページは地球にやさしいパソコン風水学の実践のために、ボトルネックをリソースゼロで解決することがモットーであるから、特別なソフトウェアは使わない。すべて一切の先入観をすてて解析し、果断に実践するのみである。
前提
前提としてRegist"o"ryに述べられていることは実施済みであり、かつまたレジストリー(system.dat user.dat)はバックアップされていることとする。当然Regclean、scanreg /fix、regcon.exeなどは処理済みであろう。また何があっても泣き言を言ったり、メール爆弾を送りつけるような人は止めた方が良い。
もしそうでなければひきかえそう。何も危険を冒す必要は無いのである。このページがありきたりのことを書くはずもないが、特に今回は最悪システムが破壊されることもある。そうすれば、楽しい家族や恋人との団らんの時間が確実に失われてしまう。それに世の中にはパソコンいぢり何かより、はるかに楽しいことがいっぱいある。
レジストリーを眺めてみる
さてsystem.datを眺めてみよう。いままでのレジストリー圧縮方法は幽霊キーを消し、依存関係をチェックし、内容を書き出して読み込むことによってセグメンテーションを詰めるだけである。しかしこのままでは
HKEY_CLASSES_ROOT
に重複したキーが残っている。特にOSをはじめ、IEやDirect-Xのようにアンインストール不可のコンポーネントを何世代に亘って追加した場合には、同じ名前のキーがいくつも並んでいる。あろうことか、新品のパソコンなのに、すでにキーが重なっていることすらある。もしこれが性格的に気にならないならここで引き返そう。何も危険を冒す必要は無い。
そこで図を見て欲しい。まずAのように、同じ名前のキー（最後に".1"がついているだけ）でCLSID(Class ID)が一つづつぶら下がっている場合である。この場合CLSIDの内容が同じならCtrl.FileFinder.1を消してみたらどうなるであろうか。何か不都合があっただろうか。もし不都合がある場合はここで引き返そう。
次がBのような場合である。この場合、Ctrl.FileFinderのCurVerの内容はCtrl.FileFinder.1を参照している。CLSIDの内容が同じならCtrl.FileFinderのCurVerキーを削除し、Ctrl.FileFinder.1全体を消してみたらどうなるであろうか。何か不都合があっただろうか。もし不都合がある場合はここで引き返そう。
問題がCの場合である。CurVerの内容はやはりCtrl.FileFinder.1を参照しているので、Ctrl.FileFinderのCurVerを消すとCtrl.FileFinderのCLSIDが無くなってしまう。従って正しくはCtrl.FileFinder.1のCLSIDと同じ物をCtrl.FileFinderに作り、さらにCurVerを消さないとCtrl.FileFinder.1全体を消せないことになる。あるいは単純に、Ctrl.FileFinderを消したまま知らんぷりはどうだろう。
さらにDは複雑だ。CLSID以外にいろいろなキーが追加されている。この場合は正しくはCtrl.FileFinder.1のInsertable、protocol、shellをCtrl.FileFinderに引っ越さないと、CurVerとCtrl.FileFinder.1全体は消せないことになる。しかしCtrl.FileFinderの方を消して知らんぷりはどうだろう。
A,B,C,Dをよくよく見ると、同じキー名のものはCLSIDが同じなら、数字が一番大きい（最新の）ものだけ残せば良いような雰囲気である。同名のキーが一つしか無い場合は、最新のキーが検索されるので、そもそもCurVerは必要無い。もしトラブルが起きたら、キー名の".数字"だけを消せばたりることである。そのポリシーで行くと変造は飛躍的に簡単になるし、専用のユーティリティーを作ることも考えられるだろう。
もちろん最後にDOSモードでscanreg /fixして空きを詰める必要がある。できればシステム情報(msinfo32.exe)のIE修復ツールとdirect-X診断ツール類を走らせて、整合性を確かめておくのが良いだろう。
HKEY_LOCAL_MACHINEのソフトウェアのキーはベンダー名がヘッダーに付くので消すのは比較的簡単である。一方、今までHKEY_CLASSES_ROOTに手を着けることはタブーとされてきた。しかしsystem.datの肥大化の原因の大部分はHKEY_LOCAL_MACHINEではなくHKEY_CLASSES_ROOTにある。
このように依存関係を整理するとレスポンスが改善することから、Windowsの終了、起動、そしてアプリ起動のもたつきにはレジストリーの複雑な依存状況が関係しているようである。問題はレジストリーのサイズだけではなく、内部構造なのである。もちろん労力が必要だし、失敗したらバックアップからレジストリーを書き戻すことになるが、それも身から出たサビと諦めよう。
さて、今まで風水変造によるフォント負荷およびリソース削減策に加え、sysalign.batによるシステムファイルの全面的MapCache対応を試してきた。今また風水式レジストリー圧縮法で、起動、終了時のレスポンスに三回アゴを落とすことになる。再起動という時間のかかる面倒な作業が、さほど苦にならなくなる。
Webmasterもsysalign.batの時は、これ以上win9Xには変造ネタは無かろうと思った。しかし、まだまだネタが残っていた。これで今後クリーンインストールの必要性も減るだろう。地球にやさしいパソコン風水学の奥義はさらに深く、またGUIのボトルネック対策の道には多岐亡羊の感がある。る
この作業は、内容が理解できない場合はハナからペイしない。しかも今までの変造の中では一番危険な方法である。しかしレジストリー肥満化の時計を逆に動かす方法は残念ながらこれしか無い。もちろんシステムの肥大化を問題と感じない場合は何も危険を冒す必要は全く無い。世の中にはパソコンいぢりより遙かに楽しいことがたくさんある。