今日の必ずトクする一言-- TODAY'S REMARK --
今日の必ずトクする一言
Version March 2000
March 29Version March 2000
特にフォントをいぢる方法はWin-NTでも有効とのレスポンスをいただき、それならと仕事場のNT群の変造に着手したら、とうの昔に変造されていて”風水NT仕様”と名付けて登録されていた。最近Webmasterの記憶力も相当あやしくなっている。
窓を開く時には雑多なコード/データ負荷が急激に発生するためキャッシュ効率が低下する。このため普段なら僅かなフォントの負荷であっても窓操作のレスポンスを大きく低下させる。本ページはかねてよりウナギの寝床式ページを提唱しているが、それはWin95の窓操作のレスポンスが悪いことも一因となっている。パソコンの生産性は決して単純なベンチマークで評価できるものでは無い。
本ページをご覧の方々の要求は過酷だ。MTUを小さくしてネットワークでの通りを良くする設定はWin98では標準的に取り入れられている。これ以上”ちょいちょい”と風水的に変造してモデムをさらに高速化できる方法は無いか、というのである。そんなウマい話がまだ残っているのだろうか。過去モデムに関しては、
●山本式スーパーステルスノイズインシュレーターのナゾ(モデムのノイズ根絶編)
●アナログモデムの限界性能をさぐる(K56flex編)
●PPP接続をロハで高速化する方法のナゾその２(山本式ブロックモード設定編)
●PPP接続をロハで高速化する方法のナゾ (tcp/ipとEthernetの本質に迫る編)
で取り上げており、データ的には56kモデムとINS64では速度差が殆どない。しかし最近はネットのバンド幅も拡充されていることから、試しにパケットサイズ(MTU)を576バイトより大きくしてみた。しかし予想に反して転送能力は全く改善しなかった。それどころかテレホーダイなどの忙しい時間帯ではレスポンスは悪化してしまった。
最近は56kモデムの普及に伴って多くのプロバイダーの集合モデムは56k/INS兼用のデジタルモデムとなっている。この場合どうがんばってもモデム一個あたりの積分値が64kをなかなか越えない。モデムとパソコン間のシリアル速度を230kに上げてみても状況は改善しない。どうもデジタルモデム一個あたりのバンド幅が制限されているように思える。つまりデータを受信するバンド幅には限界がある。そこで発想を風水学的に転換することとした。つまりこちらから返事するパケットのサイズを吟味して通りを良くする事を考える。
さてリクツであるが、論より証拠、Win95でDOS窓を４つ開いて欲しい。そしてそれぞれの窓で下記を実行する。xxx.xxx.xxx.xxxは契約しているプロバイダーのホームページのIPアドレスもしくはURLからｈｔｔｐ：／／を除いたものである。
ping xxx.xxx.xxx.xxx -t -l 500 ping xxx.xxx.xxx.xxx -t -l 512 ping xxx.xxx.xxx.xxx -t -l 576 ping xxx.xxx.xxx.xxx -t -l 1500これでネットワークの反応時間とtime outの頻度を調べるわけだ。まずあきらかにパケットサイズ1500では反応が悪い。パケットサイズ500、512、576の間の差は小さいが、Webmasterの契約しているプロバイダーでは512がなぜか一番反応時間が短くtime out頻度も低かった。つまり古いネットワークで標準なパケットサイズであった576が必ずしもベストでは無い。またパケットサイズが小さいからといって、必ずしも良くない。これはナゼだろう。以下はWebmasterの推理なので、それが本当かどうかは全く保証しない。
従来からtcp/ipのパケットサイズについては諸説がある。パケットサイズ576が悪くないことは今やM$も公認しているのだが、モデムでPPP接続する場合に限ってはパケットサイズ576は必ずしもベストでは無いのでは無いか？もちろん至適パケットサイズはプロバイダーやモデム設定によって異なるので、あなたの契約しているプロバイダーがそうとは限らない。しかし常に問題意識を持つことから風水学的な解析は始まるのである。
モデムでのPPP接続には大きなムダがある。つまりパケット通信としてのプロトコールが二重なのだ。まずtcp/IPのtcpの部分はパケットの通信によってデータの透明性とエラー訂正が保証されている。一方、モデムはtcp/ipのパケットからブロックを生成し同様にエラーを訂正する。
ブロックのサイズは回線品質が悪化すると小さくなる。ブロックは最大ブロックサイズ（MNPコマンドAT\Anで定義される）、回線品質、データ冗長度と圧縮度、そしてMNPコマンド(AT\Ln、ストリームを優先するか、ブロック生成を優先するか)によってサイズが規定されるので、ブロック作成のストラテジーは極めて高度で複雑なものとなる。
生成されるブロックの最大サイズは64,128,192,256バイトであり56kモデムでは256バイトの設定が一般的のようだ。もちろん実際のブロックサイズはtcp/ipパケットのサイズと回線状況、データの状況によって絶えず変化する。
しかしモデムはtcp/IPパケットのヘッダーとデータとの区別を知らないのでtcp/IPのパケットとモデムのブロックの間でフラグメンテーションが発生する。今回Webmasterのプロバイダーで見られた至適パケットサイズはおそらくこのフラグメンテーションが現れたものであろう。
実際パソコンからプロバイダーに返すtcp/IPパケットとモデムが生成するブロックのサイズは常に変動する。しかし最大ブロックサイズは必ず有効でこれが64の倍数である限り、どのパケットサイズも平等では無いことになる。というわけで今回パケットサイズ512を意識してMAXMTUを512、MSSを472(512-40)、RWINを1888(472x4)と設定してみた。ソフトウェアはppp-boostを使用した。
実際の転送データを示そう。上からパケットサイズ572、512、512である。上２段は土曜の午前中のネットがすいているとき、また最下段はテレホーダイの混雑が一番激しい土曜日の夜11時過ぎにredmeJの上位１５サイトを同時にブラウザーで開いた際のデータである。混み合った時間帯でもまずまずのレスポンスが得られている。前述の通り56kモデムではバンド幅に天井があるようなので、この改善は返事のパケットの通りが良くなって回線のデューティーレシオが改善したのであろう。
この風水学的な細工があなたの環境で目に見えてうまく働くかどうかは保証しないが悪くなることは無いだろう。なおwin98ではこのツールは無効のようだ。現在細工を考え中である。また１台のパソコンにモデムとNIC(LANカード)がささっている場合はRWINを倍（3776)に設定する必要がある。
2999999 tamura様 3000000 ishimoto様、kubonishi様 3000001 izumisawa様、yoshikawa様 3000002 toda様 3000003 Masui様、hara様で、アクセスをログで確認することができた。１名ご辞退された方を除いて住所が解り次第粗品（Webmasterが過去にデザインしたダサいテレカ）の発送を始めている。再度深くお礼する次第である。
さて今回もアクセスが錯綜したおかげでカウンターについていろいろ面白い事が解った。それは、
1.ネットには有形無形のキャッシュが存在する。
特に日本と米国の接点には間違いなく無形のキャッシュが存在する。これは通信コストの高い海外との接点ではムリからぬ事だ。このカウンターは同じビジターがリロウドかけても繰り上がらず、間に他のビジターが割り込んで初めて繰り上がるシカケだ。ところが今まで番号が飛んだり後戻りすることをWebmaster自身が目撃しているし、今回のお手紙にも同じ現象が書かれてあった。これはサーバーまで複数のルートがあり、またルート上にキャッシュがあると仮定すれば説明がつく。
2.カウンターのサーバーが鯖を読んでいる
このカウンターは米国の最大手のwww.digit.comの初期にロハ登録したもので、ランダムな字体を送る設定にしてある。当初のヨミはこの設定で同じ番号と字体を異なるビジターが引くことは無かろう、という事だった。しかし過去のカウンター競争でも、またWebmaster自身がメンテの時に同番ながら違う字体の数字を目撃している。今回もログで確認したので間違い無いと思う。
単にネットのルートに無形のキャッシュが存在するだけでは、同番で異なる字体は説明しがたい。これはwww.digit.comのサーバーが多重化されているか、あるいはそれらが投機的に番号を発行していると考えると説明がつく。おそらく世界最大級のカウンターサーバーでは負荷を分散するために何らかのトリックが行われているのだろう。まあサーバーが鯖を読むのは当然という意見もある。
本ページでは、今後もオリジナルな手法で地球に優しいＢ級テクノロジーを追求していきたい。ただ最近多忙がハンパで無いので、更新が不定期になる事をおゆるし頂きたい。。
March 15
●驚異のレスポンス”山本式Win98風水変造”のナゾ（300万visitor記念企画）
Win95ではOSと分離可能なIE4だが、Win98ではSHELLと不可分のためリソースを強制的に消費している。追加されたシステムツールガラ類のリソース消費とあいまって安定性やレスポンスを大きく損なっている。
このため巷ではWin98の\windowsにあるExplorer.exe、\windows\systemにあるShell32.dllとComDlg32.DLLをWin95OSR2のそれとスワップするWin98Lite変造が試されている。しかしM$が仕込んだ巧妙なトラップによりupdateに深刻な不具合が発生するので万人には勧めがたい。
そこでWebmasterは知恵を絞り、win98でありながらWin95OSR2に遜色無い、あるいはそれを超える空きリソースの確保と軽快なレスポンスを実現しupdateに一切の不具合を生じない”山本式win98風水変造”を完成した。
もちろん純正ツールのみを使いレジストリーはいぢらない。リソース削減効果は図の通りである。変造と言うよりは設定だが、その効果は地球にもレジストリーにもやさしい風水学的変造と称するに値する。なお引用には注意をお願いしたい。
窓操作のレスポンスは体感で倍以上に感じる。ほんとか？そんなウマい話があるのか、あるとしたら今までM$や雑誌は何をしていたのか？このプロジェクトは準備中だったのだが掲示板やメイルで抑圧されたM$帝国臣民からの悲痛な叫びが多く届いたため、いち早く公開することとした。
”われわれにスピードを！光を！力を！”
”何をもったいつけとるワレ、はよう公開せんかい！"
実にありがたいレスポンスである。
しかし単に方法を述べるだけではM$帝国へのリベンジに必要なスキルアップにつながらない。今回の試みはこのページで連綿と語り継がれてきたパソコン能力のボトルネック解析に基づくもので、その根底に流れるB級テクノロジーの真髄（リクツ）をぜひ理解してい頂きたいのである。基本的に、
1.現代のCPUとHDDの能力はwin95登場以来10倍以上改善している。しかしメモリーアクセスは3倍程度にしか改善していない。一方Win95のコード類は肥大しており、実際のメモリー負荷は増大している。また最近では上部構造がプチNT化しており、頭でっかちになっている。
2.Win95ではメモリーモデルの異なる16bitコードと32bitコードがキメラのように混在しており、サイズの大きなDLL類が非同期にロード/アンロードされるためコードのローカリティーが低い。またマルチメディアやネットワークのデータはサイズが大きくローカリティーも低い。MIDIやMP3を聞きながら画像満載のネットコンテンツを楽しむという、ありがちな負荷ではCPUのキャッシュ効率は劇的に低下する。
3.日本語版win95は漢字フォントとその展開、日本語辞書とその変換など優先度の高いコード/データが常駐するため、米国版win95よりCPU/メモリー負荷が高くCPUキャッシュ効率をさらに低下させている。米国製ベンチを基本にシステムを評価する雑誌評論はこの問題点を完全にシカトしており、きわめてオマヌと言わざるをえない。
4.Win95ではUSER.EXE（ユーザーインタフェース）とGDI.EXE（お絵かき）の一部に16bitコードが残っており、その作業域としてのリソースにはメモリーモデルの制約がある。この制約はいくらメモリーを積んでも改善しない。具体的には多数絵が載った窓がパカパカ展開すると、リソースは劇的に減少しシステムは不安定となる。
5.再度Win95のアーキテクチャーを見てほしい。レジストリーはwindowsコアとならんでVMM（仮想マシンマネージャー、メモリーやプロセス処理）、IFS（ネットワークファイルシステム）、ConfigManager（Plug and Play or pray)の上に乗っている。これらの立ち上げ初期には特殊データベース形式のレジストリはVMM、IFSから参照できず、Win3.1やWFWと同様にwin.iniとsystem.iniが参照される。従ってwin.iniやsystem.iniの空白のエントリー等はリソースを消費する。
以上の理解の元に32bitコードではフォントを中心にCPU/メモリー負荷を低下し、16bitコードではリソースを節約することを主眼に効果の高い方法から順に紹介する。当然だが不要なアプリは削除するのは基本である。方法だが、
1.フォントとお絵かき細工(万人向け）
まず、画面のプロパティー、（設定、全般）、詳細、フォントサイズで 大きいフォント を選ぶ(()はWin95の場合)。次に 画面のプロパティー、デザイン、指定する部分で、アイコン、アクティブタイトルバー、パレットタイトル、ヒント、メッセージボックス、メニュー、選択項目、アクティブタイトルバーと非アクティブタイトルバーのフォントをすべてSystem(日本語)（サイズ13、プロポーショナル）にする。これは1024x768ので老眼の熟年ユーザー仕様である。
なお中年ユーザー仕様（おすすめ）では、アイコン、パレットタイトル、ヒント を固定フォントのTerminal（サイズ11、等幅）にすると画面を広く使える。等幅フォントのため、老眼に厳しいURLやファイル名の”:"や"."などが読みやすくなるし、プログラマーもこの方が助かるだろう。Webmasterの場合殆どのパソコンを中年ユーザー仕様にしているが、文句が出たことは無い。
まだまだ細かい字が読める若者には若年ユーザー仕様として、また17インチ，21インチモニターを使用している場合は大型モニター仕様として、画面のプロパティー、設定、全般、詳細、フォントサイズの小さいフォントで、Systemフォント(サイズ14，プロポーショナル)を試して見て欲しい。Win98SEでTerminalフォントのサイズがうまく保存されない場合にもこの方法が使える。
Terminalフォントが見あたらないときは、コンパネ、アプリの追加/削除、windowsファイルの追加、通信でHyperterminalを追加すればインストールされる。Terminalフォントのサイズ欄が空白でも11（半角）と書き込めば有効になる。Win98SEではTerminalフォントのサイズがうまく保存されない場合には、win3.1の\windows\systemからterminalファイルをインストールするとサイズが保存されるようになる。
-------------------------------------------------------------------------
重要な追加
windows98以降では、OSのバグのため、terminalフォントの設定が保存されない場合があります。その場合、標準のシステムファイルからterminalファイルを再インストールすることで解決できます。必要なシステムファイルはお使いのハードディスク上にありますから簡単です。具体的な方法については、
●山本式風水変造version 2001(Win-Meフォローアップ編)
を参照ください。
-------------------------------------------------------------------------
モニターがボロで細いフォントが見づらい場合はB(Bold)属性が役に立つ。設定したら早速”風水98”と言う名前で設定を保存しよう。これでデザインの設定は自由自在となる。
さらにアクティブタイトルバーと非アクティブタイトルバーの”色”と”色2”を同じ色にしてグラデーションを廃する。もちろん色はwindowsの256色パレット基本色から選ぶ。これらの設定でお絵かきの負荷を減らそう。
TrueTypeフォントは展開に計算が必要だ。毎回計算するとレスポンスが遅くなるので、計算結果を\windows\TTFCACHEに保存しておく。窓操作時にシステム負荷が増えるのでTTFCACHEの読み書きも遅くなる。異なるフォントを混在使用するとヒット率も低下する。フォント負荷により頻繁にタスクスイッチが発生しレスポンスが低下する。不安定なマシンで最初にTTFCACHEが破壊され文字化けすることから、その負荷がいかに高いか解るだろう。
この点systemフォントは固定サイズなので展開の負荷が無く、立ち上げ時にメモリーに既にロードされているので新たにリソースを消費しない。Terminalフォントの負荷も最小である。この変造により窓を開ける際のフォントやグラフィックの計算とリソース消費が減り、CPUのキャッシュ効率が改善し、すべての窓操作のレスポンスがパカパカ、サクサクと飛躍的に改善する。もちろんフォントが変わるのは窓の枠だけで、アプリのフォントは今まで通りだ。起動時間もかなり短縮し、終了も瞬時になる。
2.常駐アプリを減らす(エクスパート向け！初心者にはお勧めしません！）
”スタート”、”ファイル名を指定して実行”から"msconfig"を実行。”全般”で”起動オプションを選択する”でWin.INIファイルを処理するの(v)をはずす。あるいはwin.iniを単純に削除！！！(もちろんバックアップの上）してしまおう。そんな大胆なことをして大丈夫？大丈夫、システムが最低限のwin.iniを自動的に作ってくれる。
何か古いアプリや印刷で問題があったら”win.iniを処理”に(v)して項目の(v)を選ぼう。Win95以降の標準的なプリンター追加（プリンター追加アイコンで行うヤツ）で無いインストール方法では [windows]、 [Device]、 [PrinterPort]あたりが必要となる場合があるとかである。msconfigを見れば解るとおりconfig.sys、autoexec.bat、win.iniやsystem.iniの設定は空白行に至るまで保持されリソースを喰っている。syseditでの明らかに不要な空白エントリーや空白行は削除しよう（もちろんバックアップの上）。
さらに”スタートアップ”でシステムトレイに常駐する項目の(v)をとる。特にリソースを喰う3Dサウンドやビデオカード設定ははずそう。ビデオの基本的な設定は画面のプロパティーで可能なはずだ。トレイに常駐するアプリは常時リソースを消費するので特に厳選すべきである。
アプリがトレイに住み着くには幾つかの方法がある。トレイを掃除するにはまずメニューの”スタートアップ”を調べるが、ここに見あたらない場合はwin98に標準のmsinfo32の”ソフトウェアの環境”、”スタートアップ”を見よう。これで常駐モノがどこで住み着いたかわかる。ここでのレジストリーとは具体的には
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Currentversion
にある”Run”、”RunOnce”、”RunService”、”RunServiceOnce"を反映している。この付近はウイルスの住みかなので、msconfigやmsinfo32であやしいエントリーを見つけたらウイルスも疑う必要がある。実際Webmasterはワクチンソフトが検知しなかったウイルス(BackDoor)をここで見つけた事がある。他にwin.iniの”run=”や”load=”もチェックしておく。
3.セコいアイコン細工（あまりにもセコい）
Win98にTweak-UIという物がある。もしプレインストールされていなければWin98のCD-ROMの \tools\reskit\powertoy にある。Win95用はM$にある。通常は
Mouseで Menu Speed を Fast
Generalで Window animation と Smooth scrolling を off
Exploreで StartupのAnimated...を off
でリソース節約して高速化できる事は良く知られている。しかしあと２〜３%リソースの空きを稼ぎ出そう。それは、
ExplorerのShortcut overlay を none
である。リソース節約だけでなく若干高速化するようだ。おおむねアイコン細工は必ず何らかのリソースを喰っていると考えて良い。これで窓がもうひとつ開くだろう。ああセコい。そこまでするか。しかし最後に開いた窓でシステムがクラッシュする事が無いとは限らないし。
これでリソースはシステムやユーザーが85%、GDIが95%程度確保できると思う。また文字表示は飛躍的に速くなる。フォント展開のオーバーヘッドがいかに大きいかが理解できるだろう。同時にリソース消費が減ってシステムの安定度が増すことは言うまでもない。
そんなにウマい話はホントか？昔から信じるヒトは救われるとも言う。もちろんwin98lite変造によりさらなる高速化も可能だがトラブルも増えるので、殆どのユーザーには今回の安全な風水仕様変造で十分ではなかろうか。
今回の変造その１のフォント細工はwin-NTやwin2kでも有効だ。486DX-2などの遅いマシンでは効果も著しい。フォントを固定フォントにするとTTFCACHEを一旦消すことができる。その太り具合を見ると、TTFCACHEを太らせているのはアプリよりもOS自体であることが解る。
変造の効果を実感すると、今までのレジストリー細工が全て色褪せて見える。もちろんWebmasterはこれによりアプリにも質素なコンテンツを強いるつもりは全く無い。OSはつましくかつ確固としたもので、アプリに最大限のリソースを配分すべきという考えであって、くれぐれも誤解無きよう。そうそう、Webmasterの趣味ではないがTTFCACHE読み書きの負荷が減るので過剰クロック耐性も向上する。
March 8
●Windows9Xは２１世紀の夢をみるか？
Win-NTクライアントを見て思うのは、日常の仕事にこれほど巨大なOSが必要なのか、と言うことである。そこいらの初期Win95マシンやマック教マシンでも日常の仕事にもマルチメディアを楽しむのにもさして問題無い。今後Win2kとWin9Xの位置づけはどうなるのだろうか。さらに肥大化は進むのだろうか。
Win98では確かに最新ハードがサポートされているが、OSは肥大化する一方でシステムの安定性は逆に低下しているのでは無いか。単にコードがバギーであるとかパンツのゴムのように弛いとかだけでなく、OSがアプリに提供すべきリソースをOS自体が食いつぶしているのでは無いだろうか。
図を見て欲しい。これはWebmasterの手元のWin95a、Win95OSR2.1、Win98マシンの起動時のリソースの残りを示したものだ。どのマシンもリソース節約をはかっているいることがトレイのアイコン数でわかる。Win95aはCD-Rを焼くマシンでリソースの空きはほぼ100%に近い。これは幻でなく現実である。ところがwin95の進化に従ってどんどんリソースが減っている。起動時だけでに何もしなくてもOSがリソースを喰っているのだ。
リソースの逼迫はユーザーから見るとどのような形で現れるのだろうか。Win95aのマシンではNetscapeでコンテンツ満載の窓を30個以上開ける所が、Win95OSR2では25個程度、そしてWin98では20個程度に減る。同時にリソースの逼迫は多くのシステムサービスを不安定とする。これは例えメモリーを1GB積もうとも解決しない。乗用車で言えば、モデルチェンジする度に客席とトランクが狭くなっていくようなものだ。
32bitOSであるハズのWin9Xでどうしてそれが起こるか。図はWin9XのCD-ROMについてくる図(win95rk.hlp)である。拡張DOSのシェルに過ぎなかったWin3.1はその後ネットワークを中心に強化されてWindows for workgroupe(WFW)に進化したが、これは日本に導入されなかった。その後WFWの土台を32bit化して安定化をはかり、ネットワークを強化したものがWin95である。
ところがDOSやWin3.1、WFWとの互換性を確保し必要メモリー量を減らす為にユーザーインターフェース(USER)とグラフィック(GDI)には16bitのコードが残っている。その内訳は図の通りで、多くのお絵かきに関係するBezierなどは16bitのままだ。そして16bitコードにはセグメントによるリソースの制約がある。本来Win98に求められたのは16bit部分を減らすことであったが、残念ながらそうならなかった。
実際にはWin98はマルチメディア小道具や最新ドライバー類とユーティリティー類で肥大しただけでなく、上部構造はプチNT化している。つまりひ弱な木造吹き抜け屋台OSの二階に鉄筋コンクリ造のプチNTが乗っているようなものだ。
M$にしてみれば、これ以上Win9Xにいろいろ物を載せると壊れてしまう。だから純粋32bitシステムであるWin2Kに誘導したい。しかしWin2KはWin9X以上にネットワークガラが満載して肥大化しており、これまたセキュリティーも穴だらけになることは火を見るよりも明らかだ。本来Win9Xのユーザーを吸収するためには32bit化を勧めたWin9Xもしくは、ダイエットしたWin-NTが必要なのである。しかし実際はそうなっていない。
ソフト屋の商売もつらい。最新ハードやマルチメディアに対応するだけでなく、絶えず何らかの最新ガラを積んでいかないと商売が成り立たない。しかしこのままガラ満載を続ければそれは地球環境にやさしくないだけでなく、いつかは土台が破綻してしまう。Win98が21世紀の夢を見るためには、32bit化とリソースのダイエットが必要である。と言うより、それ以外にWin9Xが生きる道は無い。
ヒトはみんなダイエットするために高いカネを払う。今後はダイエットしたOSに高いカネを払う時代になる。もうひとつは逆の発想としてWin9XをDr.DOSのようにフリーにしてしまうという手もあるかもしれない。
と言うわけで、本ページでは今後Win98の高速化とダイエットを追求していくこととする。それは他のページで報告されている98lite変造類やレジストリー細工とは根本的に異なるオリジナルな方法であり、かつ拍子抜けするほどシンプルなアプローチで驚く効果を狙うことは言うまでもない。そんなことができるのか？
なお風水学的ユーザー解析によると、トレイにならんだアイコンの数はスキルと反比例すると言われている。アイコンが10個以上並んでいるようだとWin9Xのリソースに関する理解が不足しておりB級ユーザー以下と判断される可能性があるので注意が必要だ。
アニメーションを再現するには、マウスの右クリックで画像を見る(view image)を選び、リロードかけてみよう。上から２番目の”Download Error”とエラーのダイアログが重なって来るヤツと３、４番目の指さしポインター（吹き出しつき）は本物とまぎらわしい。６番目はキャラがサブリミナリー効果を狙っているのだろうか。７番目はwindowsのポインター風がミソか。８番目はグラフが動く所が泣かせる。９番目はいくらなんでもダイアログボックス乱発しすぎだろう。
エラーのダイアログなどはビギナーの心臓を凍らせるのに十分だ。Webmasterの場合はマウスポインターを見失って一瞬老眼が進んだのかと思った。