久しぶりの日記

2007年8月28日(火)

• 　1年空く前に更新！(苦笑)
  
  

• 　最近はワンチップマイコン関係の仕事が多い。それに合わせて(?)、趣味でもやはりマイコン関係の工作が多くなっている。
  
  　いま進行中なのはUSB接続PICプログラマの製作。回路はこんな感じ（「ヌーゲット」じゃないよ、「ターゲット」だよ）でほぼ決まりなんだが、ソフトのほうがあーでもないこーでもないと考えがまとまらず、なかなか進まない。同時進行でICD2（Microchip純正のPICプログラマ・インサーキットデバッガ）互換のプログラマ・デバッガの製作なんかも考えているもんだから、なおさら。
  
  　しかしワンチップマイコンは面白いな。8ビット「マイコン」登場当時と同じワクワク感がある。
  

2006年11月16日(木)

• 　今度は1年空いた・・・まぁいいか。
  
  

• 　PS3が発売になった。ゲーム機には全然興味がないが、コンピュータとしてはそこそこ興味がある。と言っても、買いたいと思うほどではないが。（そういう意味では、PSPもコンピュータとしては興味があるが、やはり買おうと思うほどではない。）
  
  　多くのニュースサイトで分解写真が掲載されているが、その中の1つ、PC Watchの『後藤弘茂のWeekly海外ニュース／完成度の高いPLAYSTATION 3ハードウェア』にあるマザーボード写真を見たところ、メインチップと思わしき中央2つの大きなチップと、そのすぐ近くにある「どう見ても電源部」のあいだに、メモリチップ程度の大きさだがそれにしては異様なピン配置を持つチップが見える。
  
  　ひょっとしてこれ、プロードライザじゃないの？と思いながら拡大写真を見ると、案の定、チップ上にNEC TOKINの文字が見える。型番は0E128のようだ。
  
  

• 　実際にプロードライザ使ってるの初めて見たよ。『たるさんのパソコンフィールド』でネタになりそう・・・というのを書くために、久しぶりに更新。
  

2005年10月3日(月)

• 　実に4ヶ月も間があいてしまった。その間いろんなことがあったが、すっかり忘れてしまったぞ(笑) まぁ、おいおい思い出すだろう。
  
  　なんで久しぶりに日記を書いているのかというと、メインで使っているノートが長考（=chkdsk）に入ってしまい他にやることがなくなってしまったため。仕方がないので暇つぶしにサブのデスクトップで日記でも書こうかと。
  

• 　そのノートは1999年から使っているThinkPad 570なのだが、いま入っている2代目のHDDにもとうとう不良セクタが発生してしまった。そういえばキーボードもフレームも2代目、液晶パネルなんか3代目だ。バッテリも3個目。
  
  　HDDを交換するくらい安いものだし、そろそろ手狭になってきたから（なんせ12GB(笑)）増やしてもいいとは思っているのだが、いまさらこのノートに投資するべきかどうかは迷うところ。
  
  　買い換えるとすればThinkPad TシリーズかLet's Note Yシリーズだろうなぁ。あぁ、でも踏ん切りがつかない。
  

• 　このあいだ見つけたWindows XPの不思議。
  
  　Windows 2000ではできないのだが、Windows XPではビデオチップのドライバを無効に設定することができる。そうしておいて再起動すると、今度はフォールバックビデオドライバ（汎用VGAドライバ）で画面が表示される。さらにこの汎用VGAドライバも無効にして再起動すると・・・画面に何も表示されないまま起動する(笑)
  
  　いったんこの状態になってしまうと、もうどうやっても画面が表示されない。セーフモードでもVGAモードでもダメ。回復コンソールは起動できるが、ドライバの有効・無効を変更することができないので役にはたたない。この状態を解消するにはレジストリをいじるしかない。
  
  　同じ状況下で、Windows 2000の場合は起動できなくなる。同じように画面が見えないので状況が定かではないが、おそらく起動途中でブルースクリーンになっているのだろう。しかしこちらはまだ救いがある。正常起動しないということは、起動時のオプションで「前回正常起動時のプロファイル」を選択して無事に起動させることができるからである。
  

2005年5月29日(日)

• 　SMM経由915用BIOS機能が返す値の中に不明のものがあったため、インテルの915用ドライバがその内容をどう使っているのか調べていったところ、グラフィックコアのクロック周波数と判明。これを変えればコア周波数も変わるのか！？ と勇んで調べてみたが、ベンチマークの結果が全く変わらなかったので、おそらくコア周波数は変わらなかったのであろう。
  

2005年5月28日(土)

• 　ECCメモリで起動すると3Dアクセラレーションが非常に不安定になる現象がどうしても消えないので、ECC機能を切る方法を探すことにした。
  
  　ECCメモリであってもSPDを書き換えると非ECCメモリとして認識し、その状態ならば3Dアクセラレーションも安定するので、BIOSのPOSTのどこかでSPDを読んでチップセットにECC機能の設定をしている場所があるはず。ということで、まずはBIOS解析から。雲を掴むような話だが、手がかりは2つ。1つ目はSPDアクセスに使用するSMBusコントローラの所在が明らかになっていること。もう1つはECCメモリ/非ECCメモリ混在時に「Mixing ECC/non-ECC not supported」のようなメッセージが画面に表示されること。
  
  　BIOSからSPDにアクセスしている場所を探すと3ヶ所が見つかった。POSTの中、BIOSセットアップの中、それにSMMサービスコードの中である。このうちSMMサービスコードの中ではSPDにあるECCかどうかのフラグを一切参照していない。BIOSセットアップの中ではECCかどうかのフラグを参照してはいるが、それは単に画面に表示する文字列の切替に使用しているだけ。必然的に、残ったPOSTの中のコードがECCメモリの認識に関わっていることになる。
  
  　POSTの当該コードを追っていくと、MCHに対してECC機能の設定をしているらしい箇所を発見した。なぜ「らしい」なのかというと、その「設定」がMCHの非公開レジスタに対して行われているものなので正解かどうかいまひとつ定かでないから。ではなぜその場所らしいと判断したのかというと、同じく行われている公開レジスタへの設定がECCで検出したエラーの通知に関するものだったからである。
  
  　しかし、ここで設定している内容の逆を行ってもECC機能をオフにすることはできなかった。逆の設定を行うと即座にハングアップしてしまうので、何らかの影響があることは確かなのだが、ハングアップさせずに設定を行う方法が分からない。これでは使い物にならない・・・
  

2005年5月27日(金)

• 　クロックジェネレータICS 954102AFのデータシートを探してみたところ、そのものずばりは見つからなかったが、954101のデータシートが出てきた。これによると、954101はSMBusインターフェースを持っていて、そのアドレスは0x69らしい。ん？ どっかで見たようなアドレス・・・5月13日の日記に書いていたアドレスじゃないか。
  
  　これでクロック可変実現か！？と思ったのだが、よくよくデータシートを読んでみるとSMBusの側から制御できるのはPCIのクロックだけで、CPUのクロックについては単に設定を読み取ることしかできないようであった。残念。
  

• 　ECC機能切替のためにBIOSを解析していて、SMBusコントローラの制御を行っている場所を見つけた。初期化ルーチンを見ていたら、コントローラのスレーブ機能の初期化時にスレーブアドレス0x44を設定している。ん？ これもどっかで見たような・・・やっぱり5月13日の日記に書いていたアドレスだ。
  
  　道理でそれらしいチップが見当たらないわけだ。自分自身に割り当てたアドレスだったとは。
  

2005年5月26日(木)

• 　SMM経由915用BIOS処理の内容を、SoftGMA Enablerに移植してみた。ECCメモリ使用時の処理が安定してくれないかと期待したのだが、何も変わらなかった。
  

2005年5月25日(水)

• 　Video BIOSの差し替えは簡単にできた。が、差し替え後に再初期化するにはリアルモード相当で実行する必要があり、それが難しい。というか、真面目にやるにはどうやったらいいか分からない。ので初期化せず(笑)
  
  　差し替えてみたところ、画面の回転やらアスペクト比の調整やら、表示される設定項目が増えた。多分Video BIOSの中にある設定データをドライバが読んで、その内容によって設定項目を出したり消したりしているのであろう。そういえば同じIntelの915用ドライバを入れていてもNECと富士通とショップPCとでは表示される設定項目が違っていたが、そういうことだったのか。OEM向けの機能だな。
  

• 　Intelの915用ドライバはSMM経由でBIOSを呼び出しているのだが、これに相当するBIOSの機能がSC420には存在しない。このBIOS機能の内容を知りたいとずっと思っていたのだが、今日その方法を思いついた。DELLマシンのBIOSイメージをBIOSアップデートプログラムから抜き出すことができるのだから、DELLの915マシンのBIOSアップデートプログラムを使えばいいじゃないか。
  
  　さっそくDimension 4700CのBIOSアップデートプログラムをダウンロードしてBIOSイメージを抜き出してみたところ、その内容はSC420のBIOSイメージの内容とうり2つ。型番上はSC420の兄弟機のPowerEdge 800が圧縮方法もデータレイアウトも全く違っていたのに対して、Dimension 4700CのコードはSC420のコードとほとんど1対1に対応していた。これなら必要な情報を探すのも楽そうだ。
  
  　SMM経由のBIOS処理部分は割とすぐに見つかった。コードレイアウトを見ると、SC420ではコードが終了しているあたりから始まっていて、この部分が最後のコードになっているので、BIOSコードのいちばん最後に追加してあるような感じ。
  

2005年5月24日(火)

• 　今日の発見。MCHによるBIOS ROM ShadowingはOS起動状態でもRead OnlyからRead/Writeに切替が可能だった。つまり、BIOS ROMエリアに勝手に書き込みをして書き換えが可能ということ。これならACPIのテーブルを変更したりVideo BIOSを差し替えたりするのも簡単にできそう。
  

2005年5月23日(月)

• 　64ビットDLL作成はPlatform SDKをダウンロードすれば可能なことが分かった。が、32ビットDLL作成をVisual Studio .NETで行っているので、2つの環境を混在させるのは面倒。Platform SDKのx64部分をVS .NETに統合する方法があればいいんだが。
  
  　対象外のCPU（Athlon等）で実行するとBSODで落ちるというレポートが複数あり。原因はMSRアクセス時に例外が発生しているため。存在しないMSRにアクセスしようとすると一般保護例外が発生するとは知らなかった。CPUエミュレーションを考えれば当然発生するべき局面だよなー。というわけで再度修正して公開。
  

• 　「神ドライバ」でぐぐるとSoftGMA Enabler関連ネタが上位を独占。健闘しとるなー(笑)
  
  　・・・でもSoftGMAの進展はまだないのであった orz

2005年5月22日(日)

• 　いつもいつもXP SP2でしか動作テストをしていないというのはあんまりなので、今回はWin2kとWin2k3でも動作テストをすることにした。とは言っても、もう1台あるにはあるSC420に環境を作るのが面倒(笑)なので、「動作環境を確認する機能」を追加して（てゆーか入れてなかったのかよｗ）非対応環境の場合はダミー動作を行うようにしておき、Virtual PC上に作ったテスト環境でテストすることにした。
  
  　・・・うーん、なんかVirtual PC上のWin2k3に「バーチャルマシン追加機能」をインストールしても動作してないんですけど。まぁ今回Win2k3のインストール自体少々しくじってるところがあるのと、追加機能なくてもファンコンのテストには支障ないので、原因追求はしないことにした。
  

• 　おっしゃ、動作に問題なし。公開。そしたら3時間ほどで「Athlon機で実行したらBSODが発生する」との報告が。心当たりが・・・あった(笑) 動作環境確認の結果I/Oポートアクセスの抑制は行うがMSRアクセスの抑制をしていなかった。そりゃ不正MSRアクセスで落ちるわな。
  
  　MSRへのアクセスも抑制するように修正して終わりかな。DOS版の要望もあったけど、DOSからMSRにアクセスできるとは限らないから対応するかどうかは迷うところ。
  

• 　さらに数時間してx64環境でも動作報告があった。懸案のT(control)取得部分はちゃんと動いたらしいが、パフォーマンスデータ収集DLLは動かなかったらしい。よく考えたらこれは当然。x86環境では64ビットアプリが64ビットDLLを要求するので、パフォーマンス系システムが64ビットアプリ化されていればパフォーマンスデータ収集DLLも64ビット化しなければならないのであった。
  
  　うーん、64ビットドライバはDDKで作成できるけど、64ビットDLL作るには何を使えばいいんだろう。Visual C++ 2005 Express Betaでも使わないといけないのだろうか。
  

2005年5月21日(土)

• 　パフォーマンスデータ収集DLLがおかしかったのは2つ原因があった。
  
  　DLLがうまくリンクされなかった理由はDLLからexportする関数名がおかしかったから。普通にextern "C" __declspec(dllexport)すると_Foo@4みたいな修飾が付くのだが、この修飾を全部含めてレジストリに書くか、さもなければ修飾を全部取ってexportする必要があった。
  
  　他のモニタオブジェクトまで表示されなくなってしまった理由は、データ収集コード内で更新すべきタイミングやデータの範囲を間違えていたから。多数あるデータ収集DLLはすべて同じ共通のメモリブロックを受け取るので、自分の受け持ち範囲を間違えると他のデータ収集DLLにまで影響を与えてしまうのであった。（いくら効率のためとはいえ、もうちょっと何とかならなかったのか、この設計。）
  
  　まぁ何にしても、これでデータ収集DLLを読み込ませるところまではできた。
  

• 　これで終わりにしてもよかったのだが、某チラシの裏掲示板でx64版が欲しいという要望が上がっていたので、ちょうどいい機会なので試してみることにした。そして、今度は最初から予想したとおり、ハマり(笑) マイクロソフトのx64対応版C/C++コンパイラはインラインアセンブラを使わせてくれないのであった。
  
  　以前どこかでちらっと読んではいたのだが、アプリケーションプログラムのレベルではインラインアセンブラは「あったらたまに便利」程度であってなくても困らない機能なので、そのときにはたいして意識していなかった。しかしドライバとなると話は別。特に今度のプログラムではMSRにアクセスするのでアセンブラレベルのコーディングができないと話にならないのだった。
  
  　しかし、同じくアセンブラレベルでCPUIDを実行する必要のあるcpuzやらwcpuidやらが既にx64対応を果たしていたので、対応する方法があるのは間違いないのであった。そう思ってぐぐってみると、どうやらml64というx64対応アセンブラがあるらしいことが分かった。ローカルを見てみるとDDKにもちゃんと入っていた。しかし今度は使い方が分からない(涙) とりあえずtest.asmみたいなものを作ってsourcesファイルに記述してbuildしてみるのだが、test.objの作り方が分からんみたいな文句を言う。
  
  　今度はDDKのx64環境makeファイル（amd64mk.inc）にあるasm関係の記述を見ながらまたいろいろ試してみたところ、どうやら(1) sourcesファイルを置くフォルダの直下にamd64フォルダを作成し、x64専用asmファイルはamd64フォルダ内に置く、(2) sourcesファイル内にAMD64_SOURCES=パラメータを作成し、x64専用ソースはそちらに記述するの2つでbuildできるらしいということが分かった。
  
  　しかし、せっかくbuildしてもx64環境がないのでテストランもできないのであったｗ
  

2005年5月20日(金)

• 　SCH5017のファンコンパラメータ仕様はほぼそのままSC420でも使用でき、ファンコンの改良はすぐにできた。温度センサの数値も表示できるようにした。しかしファンコンを実行するたびに単発で表示するのではいかにも芸がないし見劣りするので、グラフで継続的に見えるようにしよう。とはいえわざわざGUIを作るのもかったるいので、Win32のパフォーマンスモニタ機能を使ってパフォーマンスデータを収集する部分だけ作ることにした。これさえできれば、標準のパフォーマンスモニタでグラフ化することができる。
  
  　・・・ところがこれが（またもや）大ハマり。サンプルプログラムと同じにしているはずなのに、何度やってもDLLをリンクしてくれなかったり、他のモニタオブジェクトまで表示されなくなってしまう。くそー、なんでじゃ！
  

2005年5月19日(木)

• 　SC420に内蔵されているファンコン機能を司るチップは（おそらく）SMSCのLPC47M584。そのデータシートが公開されていないが類縁チップの型番（LPCシリーズ）およびデータシートからSuper I/Oチップであろうことは以前の日記で書いたとおり。しかしBIOS解析からファンコン用レジスタのアクセス方法だけは判明しているので、レジスタ内容の詳細を調べる手がかりとして、レジスタ全体をダンプするプログラムを作ってみた。
  
  　同じくBIOS解析からファンコン用レジスタへのアクセスがSMBus（あるいはI2C）アクセスと類似であることが分かっているので、ダンプしたデータをSMBus（あるいはI2C）チップからのデータとみなして読んでみると、オフセット0x3eにあるベンダコードが0x5c、すなわちSMSC自身と読める。むむー、ということはやっぱりこのデータ、SMBus互換データなのか。
  
  　LPCシリーズでファンコンとSMBusスレーブを内蔵しているタイプの場合、SMBusのベンダコードは0x55という異なる値になっている。ということは、内蔵されているSMBus互換機能はLPCシリーズとは違う部隊の手によるものと思われる。それでは、と、再度SMSCのサイトに戻り今度はLPCシリーズ以外でファンコン機能を持ったチップのデータシートを探してみることにした。
  
  　そうしていろいろダウンロードしてみたところ、SCH5017のSMBus経由ファンコン機能の内容がほぼドンピシャであることが判明。これで回転数取得だけでなく自動制御のパラメータも変えられるぞ。
  

2005年5月18日(水)

• 　きのう作ったファンコンだが、実は明らかなバグがある。それは、本来BIOSが返しているはずのリターンコードが全く読み取れないというもの。これが読み取れないとファン回転数が分からないんだよーー。と思いながらプログラムをトレースしたら・・・うげー、if (buf.Return = 0xffff)なんて書いてるじゃないか。正しくはもちろん、if (buf.Return == 0xffff)だ(^^;
  
  　ここを直したらすぐにリターンコードが取れるようになった。これでファン回転数も表示できるぞ。
  

• 　・・・と機能追加したものの、数字が取れたり取れなかったりする。ファンのモード設定もできたりできなかったり、それどころかハングアップしたりBSODになったりもする。リターンコードを観察してみると、どうもBIOS呼び出し（out 0xb2,al）を実行しても何も起きないことがあるようだ。
  
  　おかしいなー。DELL DIAGではそんなそぶりなしで確実に取れてるのに。何が違うんだろう。
  
  　というところで思い至ったのがHTの存在。観察結果から察するに、どうやらout 0xb2,alを実行すると必ず特定のロジカルプロセッサにSMIが送られ、そのプロセッサ上でレジスタが処理（破壊）されるようだ。たまたまoutを実行したプロセッサがSMI送信先プロセッサなら問題はないが、これが異なっているとoutを実行したプロセッサはoutを実行していないかのように実行を継続されてしまう。それだけでなく、outを実行していないにもかかわらずSMIを受け取ったプロセッサは、その時点でSMIによりレジスタが破壊され暴走してしまうことにもなる。
  
  　かなり強引な展開だが、これで動作不安定の説明がつくことも確か。プログラムにAffinity設定を追加して試してみると、何と（自分で推測しておいて何だが）、本当にそれが原因のようだった。あるロジカルプロセッサにスレッドを固定すると全く問題が発生せず、別のロジカルプロセッサに固定すると一度も正常に動作しない。謎は解けた！(笑)
  

• 　さっそく改訂版を公開ｗ
  

2005年5月17日(火)

• 　きのう見つけたファンクションをまとめてファンコントロールソフトを作成、公開した。温度による制御が一切ないのに、それでもけっこう受けている。255指定暴走モードが特にｗ
  

• 　きのう書いた逃避の件。今日（ってーかもう日付変わって昨日だが）でっちあげて送った。ほっ。
  

2005年5月16日(月)

• 　仕事が滞りまくっていて、どうしても今日中に提出しないといけないものがある。ので、逃避のためにファームウェア読み(^^;
  

• 　SC420のマザーボードに載っているファームウェア用Flash ROMは4Mbits品（512MB）だったので、SC420のBIOS ROMエリア（FFF80000-FFFFFFFF）から512MBを読み出してみた。そうすると、そのうち先頭の64KBを除いてはBIOSアップデートプログラムから取り出したデータと同じだった。この「BIOSアップデートプログラムから取り出したデータ」は4月28日の日記に書いたとおりLZSSで圧縮されているので、BIOS ROMには圧縮されたままの状態で書き込まれ、起動時に展開しているということになる。
  
  　Flashは512KBしかないのだから、その展開プログラムも同じデータ内にあるはず。探してみると確かにあった。それを読んだ結果、展開もできるようになった。うーん、あとほんの少しのところまで迫っていたのか。惜しかった。
  

• 　BIOSデータを展開して眺めていたら、どうもSMM用コードと思わしき部分を発見した。読み進めてみると確かにSMM用コードだった。ここさえ解析できればS3スタンバイも実現できるかも・・・という野望はさておき、ファン制御コードを読むことにした。
  
  　うーむ、DELL DIAGでも使っていないファンクションコードがいくつかあるな。いただき。
  

2005年5月15日(日)

• 　SPD書き換えツールの内容を整理しコマンドラインオプションを整備してSPDEditor Version 0.01として公開。しかしSMBusの制御にはまだ不安が残る。これまで発生している障害は再現性に乏しく、いったん発生すると電源断以外では解消しない。何が原因で発生しどう対処すればよいのか、全く掴めていない。まぁSPDの書き換えさえできれば何度電源を切っても構わないだろうから、ひとまずこの程度で良しとしておこう。
  

2005年5月14日(土)

• 　先日までHost Too BusyでアクセスできなかったJEDECのWebサイトがアクセスできるようになっていたので、ようやくSPDの仕様書をダウンロードできた。ところが、DDR2向け改訂文書に「DIMMベンダは〔SPDの〕先頭128バイトがソフト的に書き込み禁止に設定できるようにすべきである。（中略）〔SPDの〕ソフト的に設定する書込み禁止機能は『解除不可』だが、SPDの先頭128バイトの〔データの〕破壊を防止するため、起動のたびにBIOSで〔ソフト的な書込み禁止設定を〕行うべきである。」（「〔〕」カッコ内は注釈。原文：The DIMM vendor should ensure that the lower 128 bytes are software write protectable. （中略） The software write protect feature is "write once", but should be done by the BIOS at each power up, to prevent corruption of the lower 128 bytes of the SPD.）などと書いてあってちょっとびっくり。これが普及しているとすればDDR2 DIMMのSPD書き換えはできないことになる。
  
  　改めてこの点を確かめてみると、いま手元にある非ECC 512MB DDR2 DIMMは2枚とも書込み禁止設定が行われていたが、SC420に付属のECC 256MB DDR2 DIMMは書込み禁止設定になっていなかったので、現時点（BIOSリビジョンA01）のSC420のBIOSではDIMMへの書込み禁止設定の上書きは行っていないようだ。
  
  　実際のところ、BIOSで書込み禁止設定を上書きするのはちょっとやり過ぎのような気がする。どんな形にせよ、BIOSが交換可能なシステムパーツに対して復帰不可能な操作を行うのはマズいのではないだろうか。「SPDが書き換えられてしまったので返品が受け付けられなかった」などというクレームの元になりそう。
  
  　えー、斜め読みの人が勘違いすると困るので再記しますが、SC420のBIOS（リビジョンA01）ではDIMMのSPDへの書き込みは行っていないようです。念のため。
  

• 　さて、いちおう手元にあるECC版DIMMは書込み禁止設定されていないことが分かったので、再びSMBusアクセス・SPD読み書きプログラムの作成を続行。読み出しと書き込みはICH6のレジスタに書き込むフラグが違うだけなので作成は簡単。テストプログラムを仕上げて実行してみると、前出『DIMMのSPDを書き換えてECCを非ECCにするネタ』に書いてあるとおり、あっけなく非ECCメモリとして認識した。
  
  　このSPD書き換え版えせ非ECCメモリ256MBだけで起動して、さっそくdxdiagやらPCMark04やら3DMark05やらを起動してみると、落ちずにちゃんと動作するではないか。念のため元のECC DIMMのデータに戻して再起動しdxdiagすると、すぐに落ちた。本当にECCかどうかが影響してるんだなぁ。なんだか不思議な設計だ。
  
  　さて、このテストプログラムはDIMMのスロットや書き換える内容を決め打ちにしているので、そのまま公開するには不適切。内容をもう少し整理して使いやすくしないといけないのだが、問題はユーザにどんなふうに使わせるか。危険なツールであることに変わりはないので、よく分かっている人だけに理解できるような、ダイハードというかスパルタンというか、そんな感じに仕上げることにしよう。プログラムは当然コマンドライン専用で、コマンドラインオプションがread|write|compare [DIMMスロット番号] [ダンプファイル名]なんて感じかな。
  

2005年5月13日(金)

• 　気を取り直して、SPDだけでも読み書きできるようにしようとICH6経由のSMBusアクセスに挑戦。読み出しができるようになった。書き込みルーチンも作成したがテストは明日。
  
  　SMBusに接続されたデバイスを列挙しようとアドレス0x00から0x7fまでRead Quickをかけてみたら、アドレス0x69にアクセスしたところでSMBusが全く使えなくなってしまった。この状態ではSPDも読めないので多分ブートしないだろうなーと思いながら再起動してみると案の定、ブートしない。電源断でようやく復帰。ちょっと焦った。
  
  　ひとまず列挙のアドレス範囲を0x10から0x5fまでに制限することにして消極的に回避することにしたが、0x69のデバイスはいったい何物なんだろう。なんでSMBusが使えなくなったんだろう？ バスが使えなくなった理由はおそらくDataラインをアサートしたままになってしまっているせいなのだろうが、どうやって解除したものだか。強制的にClockラインをトグルすれば元に戻るのだろうか。
  
  　もう1つ、アドレス0x44にもデバイスがあった。BT869等のビデオアクセス系デバイスで同様のアドレスを使っているらしいことは分かったのだが、SC420にそんなものが載っているとは思えないし・・・実はあまり知られていない計測系デバイスでファンコントロールに使われている、なんてことになれば嬉しいのだが。そうもいかんのだろうな。
  

2005年5月12日(木)

• 　SMBus調査のため、SC420のマザーボードに実装されているチップを調べてみた。と言ってもSMBusインターフェースないしI2Cインターフェースが付いていそうなチップのみだが。ざっと見たところ、次のようなチップがあった。
  
  
  • SST 49LF004B （フラッシュメモリ）
  • ICS 954102AF （おそらくクロックジェネレータ）
  • SMSC LPC47M584-NC （おそらくSuper I/O）
  
  「おそらく」ばかりなのはデータシートが見つからないからだが、ICSの類似型番はクロックジェネレータばかり、SMSCの類似型番はSuper I/Oばかりなので、おそらくここまでは間違いない。
  
  　この中でSMSC LPC47M584に的を絞ってもう少し調べてみた。この型番はSMSCのWebサイトでも見つからないのだが、類似型番のLPC47M192やLPC47N350のデータシートに記載の内容と実機の動作を比較すると、ロジカルデバイスの選択操作や割り当てられたデバイスの順序等が明らかに類似していることが分かる。
  
  　とすれば、これら類似型番の製品に存在するSMBusインターフェース機能もそのまま使えるのではないか・・・と調べてみたのだが、こちらは残念ながら動作が確認できなかった。残念。
  

2005年5月11日(水)

• 　S3サスペンドは進展がなくてつまらないので、またSPD書き換えのためのSMBus調査に戻る。
  
  　DDKにあるSMBus関連記述ではsmbclass.sysとsmbhc.sysというファイルがあることになっているのだが、どう探しても見つからない。思い余ってinfを漁ったところ、どうやらACPIで*acpi0001というデバイスが列挙されないとインストールされないらしい。うーん、だめじゃん。さらにぐぐって調べていると「smbclass.sysとsmbhc.sysはALiのチップセット専用だよ」との発言が。そういえば同じinfの中でsmbali.sysなるファイルもあって、その説明には確かにALi 1535 SMBusコントローラ用ドライバと書いてある。
  
  　infファイルの記述から言えば、認識の順序は「ACPI BIOSがSMBusコントローラを認識して*acpi0001というデバイスを列挙→PnPマネージャが列挙された*acpi0001に対応するsmbhc.sysとsmbclass.sysを読み込み→smbclass.sysがSMBデバイスを列挙してAliコントローラを発見→PnPマネージャがALiコントローラに対応するsmbali.sysを読み込み」ということのようなのだが、いずれにしてもIntelチップセットの場合はダメか。
  
  　でもデバイスマネージャを見ると、確かに「Intel(R) 82801FB/FBM SMBus Controller」というデバイスがある。こっちのinfはどうなっとるんかいなと思って見てみると・・・なんと、ドライバファイルなしでデバイス名エントリのみ登録していた。どうりでそれらしいファイルが何も見つからないわけだ orz
  
  　しかしまぁ、考え方を帰れば、これで競合を気にすることなく自由にアクセスして大丈夫ということにもなったわけだ。
  

• 　SMBus関係を調べていたときに出てきたMicrosoftのmssmbios.sysの資料。XP SP2・2003 SP1以降に入っているそうな。ほとんどSMBusに関係はないが覚えておくと後で役に立ちそうなのでメモ。
  

• 　今日のじじぃトーク。雑誌編。
  
  　「初ラ」（初歩のラジオ：誠文堂新光社）が休刊したのはもう何年前だったか。これを10年近く読んでいた。読み始めをハッキリ覚えていないのだが、1977年9月号か1978年9月号からだったと思う。なぜ「ラ製」（ラジオの製作：電波新聞社）にしなかったのかは全く覚えていないが、若干「初ラ」のほうが対象年齢層が上に幅広く、その分興味を惹いたのかもしれない。「子科」（子供の科学：誠文堂新光社）では内容が簡単すぎてつまらなく、「トラ技」（トランジスタ技術：CQ出版社）や「インターフェース」（CQ出版社）では全く歯が立たなかったのは間違いない。無線にはたいして興味がなかったので、「CQ」（CQ出版社）や「無線と実験」（誠文堂新光社）は好みではなかった。（が、父親の受験のついでに勉強させられて1979年にはアマチュア無線の免許を取った。）
  
  　「初ラ」にはTK-80BSを使ったBASIC入門記事が載っていて、子供心にも「なんだかスゴイ」と思った覚えがある。思っただけで、BASIC言語はほとんど理解できなかったのだが。今にして思えば、初歩の英語の知識さえあれば子供でもすぐに理解できる程度の内容だったのだが、あいにくそんなものは持ち合わせていなかったので、いくらかでも理解できるようになるまでけっこう時間がかかった。（なぜ代入が「LET」なのか、なぜループが「FOR/NEXT」なのか、なぜジャンプが「GOTO」なのか等、構文の多くは英語さえ知っていれば簡単に理解できたはずのものである。）
  
  　すごいと思ったのは、その手続き的処理の様子である。当時、デジタルIC工作からごく簡単なロジックの知識はあり、それを大規模に組み合わせればマイコンを実現できるはずであることも知識としては知っていたが、単なる組み合わせ回路からどうやれば「手続き的な処理」が実現できるのかは全く想像できなかった。
  
  　1980年6月からは「I/O」（工学社）を、1981年7月からは「ASCII」（アスキー出版）を（それぞれ父親が買い始めたので）読み始めた。1983年6月からは「トラ技」を読み始めた。「トラ技」は「C-MOS版Z80ファミリ最新情報」という特集記事が読みたくて買ったのだが、かなり読み応えがあって面白かったのを覚えている。まだ「インターフェース」には手出しできなかったが、たまに資料として買いたいと思ったこともあった。そういえば、Inmos社のTransputerの記事が「ASCII」に載ったのはいつだったかな。あれもなかなか面白いと思ったが、商業的にはあまり成功しなかったみたい。
  
  　あとは・・・「Oh! HC」（ソフトバンク）を創刊号から終刊号まで全部買ったくらいか(笑)

2005年5月10日(火)

• 　Sxオブジェクトに入っているデータをチップセットのデータシートとつき合わせてみると、どう見ても値がおかしい。インターネット上で公開されている他のマシンのAMLIコードに入っているSxオブジェクトのデータを見ると、こちらはデータシートから予想される値のとおりになっている。それでは、ということで、S3オブジェクト追加＆データシートから予想される値に変更してサスペンドしてみた。
  
  　結果：復帰しない orz
  
  　うーん、SMBIOSの中でサスペンドを処理してしまっているのだろうか。
  

2005年5月9日(月)

• 　SC420にインストールしたWindows XPでpowercfg /aを実行すると「S1スタンバイが利用可能です／S3スタンバイは利用できません」と表示される。これを「S1・S3スタンバイが利用可能です」と表示されるようにするのが最初の目標である。
  
  　Windows XPのACPIオブジェクトをダンプしてみると、S0, S1, S4, S5の各定数は定義されているがS3は定義されていなかった。BIOSにあったACPIデータのうちS3定数がある部分はやはり読み込まれていなかったようである。それならば、ACPIテーブルを一部書き換えてS3定数を含むデータを強制的に読ませてやればS3スタンバイができるようになるのではないかと考え、試してみた。
  
  　ブートのどの段階でACPIテーブルを参照しているのか。ACPI対応PCかどうかでHALのファイルが異なるので、おそらくHALでACPIテーブルを参照しているのだろうと当たりをつけてみた。しかし、カーネルデバッガでHALの初期化時点から調べていくと、確かにACPIテーブルを参照してはいるが、HALの中ではSx定数を含むテーブル（SSDT）を読み込んでいる形跡がない。
  
  　次はACPI.SYSを調べてみた。ところが今度は、HALのときに使ったのと同じ方法ではACPIテーブルを参照している場所が見つからない。仕方がないので、それらしい関数（FindTableみたいなもの）にブレークポイントを起き、それぞれ実行を止めてはACPIオブジェクトをダンプしてみた。そうしてACPIオブジェクトを読み込んでいる関数を特定し処理内容を調べたところ、何とHALがBIOSから読み取ったACPIテーブルをレジストリに格納し、ACPI.SYSは最初のACPIテーブルをBIOSからではなくレジストリから読み込んでいた。道理で見つからないわけだ。
  
  　ACPIテーブルを読み取る場所が分かったので、次はSSDTを読み取る位置を探し、その場所にブレークポイントを設定。実行が中断したところで強制的に読み取るべきSSDTをS3定数を含むものに差し替えて実行を再開。すると、起動後にpowercfg /aを実行すると「S1・S3スタンバイが利用可能です」と表示されるようになった。実際に、スタンバイに入って戻ることもできた。成功！
  
  　・・・と思ったのだが、どうもおかしい。ファンは停止しないしチップセットも熱いまま。どうやらチップセットがS3スタンバイモードに入っていないような感じ。必要な設定が省略されてしまっているのだろうか。それともマザーボード自体にその機能がないのか。いや、S3スタンバイに入ってもチップセットは電力を消費し続けるのか？クランプメータでも買わないと区別が付かないな。困った。
  

2005年5月8日(日)

• 　今更だが、SC420はS3スタンバイができずS1スタンバイになってしまう。ところが、ACPI仕様を確認しているとき気付いたのだが、SC420のBIOSにあるACPIデータにはS3スタンバイのレイテンシ情報やS3スタンバイ時のパワーマネジメントレジスタ設定値等、S3スタンバイに関するデータがちらほらと見える。実はS3スタンバイが可能で、何かの設定を行うと使用可能になるのではないだろうか。最近気温が上がってきてファンもだんだん力強く(笑)回り始めてきたので、SPD書き換えは後回しにして、S3スタンバイを目指してちょっと調べてみることにした。
  
  　SC420が届いてからこんな調査ばかりしているが、普通のソフト開発より断然楽しいのには困ったものだ。他のことが手につかない。・・・そんなことを考えながら調査していたら、調査中ずっと昔のことばかり思い出していた。かなりじじぃ化しているようだ。完全にじじぃ化して忘れ去ってしまう前に、そのいくらかを書き記しておこう。
  

• 　私は平均的プログラマよりもハードウェアおよびハードウェアに近い部分の（いわゆる「低レベルな」）ソフトウェアを得意としている。もともとデジタルIC工作からデジタル世界に踏み込んだせいだろうか。
  
  　最初に扱ったPCはNECのPC-8001、CPUはZ80（のNEC製互換品であるμPD780、確か勝手セカンドソース）。当時のLSIは4Kbit DRAMやP-MOSの世代が終わり16Kbit DRAM (4116)・N-MOS世代に入ったところ。PCを構成するメジャーなLSIはほとんどが5V単電源化していたが、4116はまだ3電源（+5V/+12V/-5V）が必要だった。（ちなみに、同世代の4Kbit SRAMである2114は既に単電源だった。）
  
  　その頃のI/O誌にはメモリボードの製作記事が時々載っていたが、DRAMの使い方ほとんど理解できなかった。当時汎用ロジックICのゲートの知識程度はあったが、遅延に関する知識は皆無だったので、分からなくても無理はない（まだ小学生だったし）。これも、以前の日記に書いた「時間をおいて読み返したら理解できた」の類である。
  

• 　数年後、中学生の頃。PC構成部品の中でも単電源化が遅れていたDRAMが64Kbit DRAM (4164)の登場でようやく単電源化を達成。内部で複数の電源電圧が必要なことに変わりはなく、供給される単一電源からLSI内部で必要な電源電圧を生成していたのだが、まだMAX232のようなチャージポンプICが全然ポピュラーでない頃だったのでDC-DCコンバータは大きいものというイメージがあり、LSI内部で生成するというのが画期的な技術に思われた。
  
  　同じ頃、CMOS汎用ロジックICのラインナップが充実。TTLでは（いくらLSシリーズを使っても）消費電力がけっこう多く、また電源電圧を5V±10%に保つために電源回路が別途必要だが、CMOSでは電源電圧の制限が非常に緩やか（40xx系、45xx系で3V〜18V程度）で消費電力も非常に少ないので電池を電源とする電子工作はとても楽になった。しかし、いくらラインナップが充実したと言ってもTTLにはかなわず、ちょっと特殊な機能が欲しかったり高速性が必要になるとTTLを使わざるを得ない場面もあった。そういう時にはCMOSとTTLを混在させることになり、自然とロジックレベルや駆動能力の違いを意識することになった。
  
  　この頃のCMOSのプロセスルールは現在と比較すれば超巨大で、虫眼鏡だけでチップ内の配線を追うことができた。汎用ロジックICのデータブックにはたいてい等価回路図が載っていたので、チップの拡大写真があればチップの配線と回路図を直接比較することができ、CMOSの構造を知るのに役に立った。現在のCMOSの構造も、サイズが小さくなっただけでその頃からほとんど変わっていないが、今では電子顕微鏡でしか構造を見ることはできない。（とは言え、今でも売っている汎用ロジックICは当時と同じようなサイズなのかも。プロセスルールを小さくしても縮小できるトランジスタはたかだか数十個しかなく、チップ面積の大部分を占めるであろうパッドは縮小できないから。）
  
  　チップの配線といえば、最初にMAX232のチップの拡大写真を見たときにはちょっと面白かった。サイズの割にはけっこうな大電流を出力するチップなわけだが、写真を見ると明らかに他の部分と比較して巨大なトランジスタが数個あり、これがチャージポンプのドライバなのだろうなと簡単に想像ができた。
  

• 　さらに数年後、高校生の頃。いわゆる「パソコン通信」をしたくなった。当時使っていたPC-6001にはシリアルポートがなかったが、アスキー誌1983年4月号にPC-6001の全回路図が載っていたのでシリアルポートを増設することは難しくなかった。通信ソフトも存在しないので自作。電話代のほうが高くついた・・・
  
  　この頃にはもうゲート遅延の考慮もある程度できるようになっていて、そのうちPC-6001のCPUをZ280に置き換えて10倍速PC-6001を作ってやろうと回路図も引いていたのだった。実現しなかったけど。
  

2005年5月7日(土)

• 　1週間ほど日記が飛んだ。その間、仕事関連や私事で時間（というより気力）が確保できずGMA900イネーブラは手付かず。こんなに放置したのは、着手開始から初めてかも。
  

• 　2chのPowerEdge掲示板（SC420祭をやっていた場所）でDIMMのSPDを書き換えてECCを非ECCにするネタを読む。これは面白い。ECCメモリを非ECC化してGMA900イネーブラの動作が安定するのならば、やってみる価値がある。さっそく調べてみることにする。
  
  　まずはこの辺でシリアルEEPROMの仕様とI2Cバスの使い方をチェック。なるほど・・・今時はワイヤードORでもノイズ耐性は充分確保できるのだろうか。昔（汎用TTL IC全盛の頃(^^;）はあまり信頼できない回路構成の代表格だったんだけど。
  
  　次はもっとソフトウェアに近いほうをチェック。確かチップセットドライバをインストールするとチップセットのSMBusインターフェースに対応するドライバもインストールされるはず、と思ってデバイスマネージャを見ると、やっぱりありました。「Intel(R) 82801FB/FBM SMBus Controller」というのがインストールされている。こいつを呼び出せば簡単にインターフェースできそう。・・・と思ったらドツボだった。
  
  　DDKのSMBusに関する記述を読んでも、直接SMBusドライバを呼び出す手順が書いていない。それじゃドライバファイルのエクスポートを見て見当を付けようかとドライバファイルを探してみたが、デバイスマネージャのSMBus Controllerの「ドライバの詳細」を見ると「ドライバファイルが必要でないか、またはこのデバイス用のドライバファイルが読み込まれていません」などと表示される。改めてここのSMBus Device Driver External Architecture Specificationにある方法でインターフェースを取得しようとしてみたが、何も取得できない。
  
  　確かACPIにもSMBusの取り扱いがあったはずだと思い直しここでACPI仕様を確認。これがまたうんざりするほど長い文書で、しかもインデクスが付いていないときたもんだ。それでも我慢して読んでみたところによれば、どうもACPIは閉じた世界のようで、外部からACPIの機能を呼び出して使用するということはできないらしい。確かに、DDKのACPIに関する記述でも「ACPIが使用する機能を提供するドライバの書き方」しか書いていない。
  
  　結局、SMBusを使おうと思ったらチップセットに対して直接アクセスするしかないんだろうか。SPDの書き換えなんてけっこうシステム的にクリティカルだから他と競合するとイヤなんだがなぁ。
  

2005年4月29日(金)

• 　起動時にVGA画面への切替がうまく行かない件、タイミングによって稀に表示されることもあることが分かった。BSOD（Blue Screen Of Death：ブルーサンダー）はいつもちゃんと表示される（orz）ので、915ドライバが正常動作していればVGA画面に切り替わらないということはないはず。おそらく起動直後、VGAドライバと915ドライバの起動タイミングによって何か問題が発生しているのであろう。
  
  　なおこの問題、作業優先度は低いので解決に向けた調査は後回しになる。悪しからず。
  

• 　Video BIOSの続き。915用ドライバに付属している915用Video BIOSは本来ROM化が前提のものなのだが、DOS上でTSRとして動作するバージョンも含まれている。ということは、本来のBIOS ROMがあるべきアドレス以外の場所にVideo BIOSを置いても、割り込みベクタさえ適切に設定してあれば動作するということである。（昔のVESA BIOS TSRと同じ考え方だ。）
  
  　さらに考え方を進めて、Windows NT系OSであっても、最下位1MBの領域にメモリを確保してVideo BIOSを置き、VideoPortInt10で呼び出す先がそのVideo BIOSになるように何らかの細工をしてやれば、BIOS ROMのコードではなく後から置いたVideo BIOSが使えるのではないだろうか。そう考えて、その予備的なテストをいくつか行ってみた。
  
  　まず最下位1MBの領域へのメモリ確保。これはMmAllocateContiguousMemoryに物理アドレスの上限値として0xFFFFFを与えることで実現できた。次は割り込みベクタの設定がVideoPortInt10の呼び出しに反映されるかどうかだが、実際に割り込みベクタを変更する前にまずVideoPortInt10がどのような処理を行っているのか確認することにした。
  

• 　VideoPortInt10のコードを辿っていくと、最終的にはNtVdmControlという非公開APIの呼び出しに到達する。このAPIに関する資料は非常に少ないのだが、名前のとおりVirtual DOS Machineに関係するAPIで、V86モード環境の設定とV86モード環境下のプログラムコード実行を行う機能を持つらしいことが分かった。だとすると割り込みベクタの設定を行っても無効となる可能性が高い。また仮に割り込みベクタの設定が有効であったとしても、V86環境下では物理アドレスではなく仮想アドレスを使用するので、NtVdmControlによって呼び出されるV86環境下の仮想アドレスで下位1MBの範囲内にVideo BIOSを送り込む必要がある。のだが、その方法が全く見当もつかない。なにせ非公開APIなので。
  
  　いずれにしても、さらにテストを行う必要がありそうだ。
  

2005年4月28日(木)

• 　915ドライバの安定動作のためにはSMIやVideo BIOSとの通信に鍵がありそうな感じがいや増している。もっとドライバの解析を進めてからBIOSに取り掛かろうと思っていたのだが、もしもさくっとBIOS ROMの情報が取れるようであればそのほうが楽なので、ちょっとBIOSを調べてみた。とは言っても、いきなりBIOS ROMの読み出しに挑戦するのはあまりに無謀なので、まずはDELLが用意しているBIOSアップデートプログラムから調査開始。
  
  　先に調査結果から書くと、BIOS ROMイメージはgzip形式で圧縮され、その前後にヘッダ・フッタを付加してプログラムファイルの後端に連結されていた。
  
  　ざっとプログラム内に埋め込まれた文字列を見ていくと、始めのほうで「Pyld」「Bioz」といういかにもな感じの文字列が現れるのだが、これが圧縮されたBIOS ROMイメージのヘッダ文字列になっていた。また、そのもう少し先に「Cant gzdopen」という文字列も見える。この段階でgzip圧縮だとピンと来るべきだったのだが、最初に見た時には思い至らなかったのが残念。
  
  　さらに先に「deflate 1.2.1 Copyright 1995-2003 Jean-loup Gailly」「inflate 1.2.1 Copyright 1995-2003 Mark Adler」の文字列。deflateを調べるとRFC1951になっていることが分かった。内容を読むと、この圧縮形式はgzipで使用されていると書いてある。さらに読み進めると、このRFCのAuthorにJean-Loup GaillyとMark Adlerの名前が出てくるではないか。この段階でようやく、BIOSアップデートプログラムでは圧縮データの展開におそらくgzip互換の標準的なライブラリを使用しているのであろうことが分かった。
  
  　さらに先へと進むと、EXEプログラムのヘッダ情報に記載されたコード／データ範囲をさらに超えたところに大量のデータがある。普通のプログラムではヘッダ情報に記載されたコード／データ範囲を超えたところにデータを置くことはない（というよりも、コンパイラ・リンカがそういうEXEプログラムの作成を許さない）ので、これ以降のデータは何か普通でない方法で作成されたものであることが分かる。さらに、そのデータの先頭には「PyldBioz」というどこかで見たような文字列がある。この時点で、ここ以降の付加データがBIOS ROMデータであろうことがほぼ確実になった。
  
  　次に、おそらくBIOS ROMデータがgzipで圧縮されているであろうという予想から、gzip圧縮したファイルのヘッダ情報と並べてみたところ、明らかに付加データのオフセット0x30以降がgzip形式データ、オフセット0x0cからのDWORDがデータ長に見える。文字列の中にCRC32云々があったので、オフセット0x08からのDWORDはおそらく圧縮データのCRC32であろう。
  
  　データの最後を見ると、今度は明らかにデータの先頭ファイルオフセットをDWORDで指しているので、これがフッタであろうと当たりをつけ、付加データのオフセット0x30から最終4バイトを除くデータを切り出してgunzipしたところ、見事データを展開することができた。展開後のデータ長はヘッダのオフセット0x24からのDWORDと一致していた。ちなみにヘッダのオフセット0x20からのDWORDは圧縮データ長であった。
  

• 　そんなこんなでBIOSアップデートプログラムから圧縮されたBIOS ROMデータを取り出し展開することはできたのだが、そのデータを見ると、まだ何かしらの形式で圧縮されているように見える。一部の文字列が細切れになりながらもそのまま読むことができるので、これはLZ77（というかLZSS）の一変種による圧縮であろうことはほぼ確実である。それならば割と簡単に展開できるはず・・・と思ったが、甘かった。
  
  　まず幸いなことにBIOS ROMデータの先頭が文字列（を圧縮したもの）で始まっていたので、これを正常な文字列に展開できるような展開手順を推理してみたところ、およそこんな感じと考えられた。
  
  

  第1バイトがX0である場合、続く(X+1)バイトのデータをそのまま出力する。ただしX=Fの場合はさらに第2バイトZZを用い、続く(X+ZZ)バイトのデータを出力する。またX=Eの場合は第2バイトZZを用い、最後に出力したデータと同じデータを(ZZ+1)バイト出力する。 第1バイトが0Yである場合はさらに第2バイトZZを用い、出力済みデータを(ZZ+1)バイト遡った位置から(Y+1)バイト分と同じデータを出力する。

  　これでデータ先頭の文字列は正常に読めるものに展開できたので、これを基本線として、うまく展開できない部分を見つけるたびに手順を手直ししていった。しかし、どうしてもうまく展開できない部分がある。
  
  　問題点は2つあるようだ。1つは、どうやら辞書（上記手順でいうところの「出力済みデータ」）が特定のデータで初期化されているらしいこと。もう1つは、第1バイトがX0でも0YでもないようなXYである場合の処理を誤っているらしいこと。もし前者があるとすると、これは（圧縮されている）BIOS ROMデータそのもの以外に初期化データがあるということなので、その初期化データを取得するのはかなり難しそうだ。後者は、より詳しくデータを観察するしかない。
  
  　とりあえず1日の作業ではここまでが精一杯で、BIOS ROMデータを取り出すには至らなかった。
  

• 　ところで、Video BIOSはDOSから見える場所にあることが前提になっているので、Video BIOSだけを相手にするのであればBIOS ROMデータ全体を取り出す必要はない。こちらもざっと見てみると、SC420に搭載されているのは当然ながらE7221用。915用ドライバになぜか付属している915用Video BIOSと比較してみると、けっこう違っていた。また、この比較の時に気付いたのだが、Video BIOSのビルド番号が915用ドライバのプロパティ画面（Alt-Ctrl-F12で表示される画面）で表示されている。今までそんな通信をしている場所に気付かなかったが、やはりVideo BIOSの呼び出しは行っているようだ。いよいよ本格的に、Video BIOSの対応を考える必要がありそうだ。
  

2005年4月27日(水)

• 　カーネルデバッガにデバッグメッセージが表示される件は、どうやらPCMark等が非公開APIを使っているせいらしいと分かった。
  
  　Windows NT 4.0以降ではシステムが\Device\PhysicalMemoryというセクションオブジェクト（Win32の用語ではファイルマッピングオブジェクト）を作成するようになっている。このオブジェクトはオフセットを物理アドレスとするメモリ内容に対応するセクションになっていて、非公開APIであるNtOpenSection（Win32 APIのOpenFileMappingに相当）に渡すと物理アドレスを指定してメモリの内容を直接操作することができる。
  
  　このセクションオブジェクトは本来カーネルドライバのみが使用することを前提としており、DDKには「自身に割り当てられた物理メモリをマップする場合を除いて、このセクションオブジェクトをユーザモードのメモリ空間にマップするな」という意味のことが書かれている。
  
  　ところがPCMarkや3DMarkではBIOS情報を読み出すためにこのオブジェクトと非公開APIを使用しているらしい。これを行うとシステム側には「ドライバに割り当てていない物理メモリをマップしようとしている」ように見え、そのため警告メッセージを表示してしまっているようだ。（どうりで、MapViewOfFileを行うテストプログラムを作っても現象が再現しないわけだ・・・）
  

• 　ちなみに、ここによれば、Windows Server 2003 SP1以降はユーザモードからこのオブジェクトを使用することができなくなったようだ。カーネルドライバ用のZwOpenSectionで使えなくなるとドライバ互換性の問題が発生するので、おそらくユーザモード・カーネルモードの境界にあるNtOpenSectionの中に\Device\PhysicalMemoryが使用できないようにチェックを追加したのだろう。
  

• 　今日の覚え書き。というか半月近く前に発見したことなのだが、書き忘れていたネタ。
  
  　PCMark04のベンチマークで実行するテストの中にDivXによる圧縮があるが、アプリケーションがハードウェアDEPの対象になっているとこのDivX圧縮が動作せず、そのためこのテストの結果が得られず最終的なPCMarkスコアも表示されない。これを回避するには(1)DEPをOffにする、(2)DEPをOpt-Inに設定しPCMark04.exeを指定しない、(3)DEPをOpt-Outに設定しPCMark04.exeを指定する、のいずれかを行う必要がある。
  
  　GMA900イネーブラ開発開始当初、なかなかこれに気付かなかったためPCMarkスコアが表示されず、えらく悩んだ。
  

2005年4月26日(火)

• 　Windows NT系OSに移行してから初めて、今日Checked Buildを入れた。正確には、ドライバのデバッグ用にデバッグカーネル（Checked Build版のHALとカーネル）のみ入れてみた。それというのも、PCMarkや3DMarkを起動すると必ずデバッガが
  
  

  ******************************************************************************* * * A driver is mapping physical memory XXXXXXXX->YYYYYYYY * that it does not own. This can cause internal CPU corruption. * A checked build will stop in the kernel debugger * so this problem can be fully debugged. * *******************************************************************************

  などという恐ろしげな警告メッセージを表示するので。
  
  　boot.iniにはHALとカーネルを入れ替えるためのオプションが用意されているので、これを使えば一時的な入れ替えは簡単。/HAL=hal.chk /KERNEL=ntkrnlpa.chkとでも追加しておけばよい。それより問題はデバッグカーネルをどこから持ってくるか、である。
  

• 　どういうわけかChecked Buildは英語版しかなく日本語版がない。大昔、Windows 3.1の頃には日本語版もあったのだが。Windows NT系ではカーネルバイナリは各国語版すべて同じという建前なので、多分この英語版Checked Buildのカーネルをコピーしてくれば日本語版環境の中でもちゃんと動くに違いない。
  
  　・・・とは思ったが、確認しておかないとちょっと怖い。ので、まずは英語版Windows XP with SP2のRetail Build（要は、普通の版）のCD-ROMからHALとカーネルのファイルを抜き出し、現在使用している日本語版Windows XP SP2のHAL・カーネルと比較してみた。すると、HALは完全一致。しかしカーネルが一致しない。どうやらSP2リリースより新しいWindows Updateで更新されてしまったらしい。しょうがない、少し戻って英語版Windows XP with SP1aと日本語版Windows XP with SP1aで比較してみよう。
  
  　・・・やっぱりカーネルが一致しない。どういうことだろう。カーネルファイルもローカライズ対象になっているのか、それとも英語版リリース後のセキュリティアップデートを追加して日本語版をリリースしているのか。それにしてはリリース日の違いが4日しかないんだが。
  

• 　まぁいいや、動かなくてもその時はその時。と思い直して英語版Windows XP SP2のデバッグカーネルを入れることにした。とは言っても「英語版Windows XP」の「Checked Build」は「with SP2」版が存在せず、SPなし版しか用意されていない。欲しいファイルは3つだけ（halmacpi.dll, ntkrpamp.exe, ntkrnlmp.exe）なのに丸ごと全部インストールしてSP2当てるのも面倒で嫌だったので、英語版Windows XP Checked BuildのSP2インストーラからこの3ファイルを抽出することにした。
  
  　抽出と言っても、インストーラを起動しておいて一時フォルダに展開されたファイルをコピーするだけなのだが。ちなみに、SPのインストーラはC:\に一時フォルダを作成した。C:\が書き込み可能とは限らないはずなのだが、大丈夫なのだろうか？ 他人事ながらちょっと心配になってしまった。Windows Installerあたりだと%temp%に書き込むのだが。
  

• 　ところでコピーすべきファイルだが、インストール済みWindows XPからコピーする場合は%SystemRoot%\system32からhal.dll, ntoskrnl.exe, ntkrnlpa.exeの3ファイルをコピーすればよい。それぞれHAL、PAEを使わないカーネル、PAEを使うカーネルである。しかしCD-ROMやSPインストーラの一時ファイル等、インストール前イメージからコピーする場合は少々注意が必要だ。
  
  　インストール前イメージではHALは7ファイル、カーネルは2セット4ファイルあり、どのファイルをコピーすれば良いかはシステムによって異なる。インストール済みWindows XPの%SystemRoot%\repair\setup.logの最初のほう（25行目前後）に
  
  

  \WINDOWS\system32\hal.dll = "halmacpi.dll","2242b" \WINDOWS\system32\ntkrnlpa.exe = "ntkrpamp.exe","1d84bc" \WINDOWS\system32\ntoskrnl.exe = "ntkrnlmp.exe","1d15ee"

  
  のような記述があるので、その記述にあるファイルをコピーする。ちなみに上記の例では、halmacpi.dll（ACPIマルチプロセッサPC用HAL）、ntkrpamp.exe（マルチプロセッサPC用PAEカーネル）、ntkrnlmp.exe（マルチプロセッサ用非PAEカーネル）の各ファイルをコピーしている。
  
  　なお、インストール前イメージではhalmacpi.dl_のように拡張子の3文字目がアンダースコア（_）になっているが、これはファイルが圧縮されていることを示す。圧縮を解除するにはWindowsに付属のexpand.exeを使用する。expand -r halmacpi.dl_と実行すればhalmacpi.dllが生成される。
  

• 　boot.iniの書き換えにもちょっと注意が必要だ。通常はPCの構成とソフト的設定によって非PAEカーネルとPAEカーネルが自動的に切り替わるのだが、この2つはカーネルファイル自体が異なるので、boot.iniの/KERNEL=オプションで直接カーネルファイルを指定する場合は、起動すべきカーネルが非PAEカーネルなのかPAEカーネルなのかを意識しカーネルファイルを区別して指定する必要がある。
  
  　この区別を誤るとどうなるのか・・・は試していないが、あまり試したくもない。指針としては「メモリ実装量が4GB以上、あるいはハードウェアDEP機能を有効にする、あるいはその他の理由でPAEを使いたい場合」はPAEカーネル、そうでない場合は非PAEカーネルとなる。
  

• 　とまぁそんな注意を払いつつboot.iniを書き換えて再起動。何の問題もなく起動した。よかった。
  
  　さっそく懸案であったデバッガメッセージを調査してみた。デバッグカーネルを入れると、このメッセージが表示される段階で停止するので調査が非常に楽になる。さっそくスタックトレースを表示。ところが、どうもGMA900イネーブラやIntelビデオドライバとは関係のないところで止まっているように見える。呼び出し元もntdll!NtMapViewOfSection+0xcなどと出ているから明らかにアプリケーション側のMapViewOfFileだし。
  
  　アプリケーション側の問題でカーネルデバッグメッセージが表示されるなんてことがあるのだろうか。そう思いつつ、念のためGMA900イネーブラとIntelビデオドライバを停止して再起動。やっぱり同じメッセージが表示される。ドライバの出来とは全く関係なかったのか・・・嬉しいような悔しいような。そもそも元のメッセージが紛らわしすぎ。「A driver is mapping hogehoge」と出てくるからドライバに難があると考えてしまうのは当然だと思うのだが、このスタックトレースを見るとメッセージを出すこと自体、XPのバグなのではないかと思えてくる。
  
  

  ******************************************************************************* * * A driver is mapping physical memory 00122000->001EFFFF * that it does not own. This can cause internal CPU corruption. * ******************************************************************************* Break instruction exception - code 80000003 (first chance) nt!DbgBreakPoint: 80aba2f4 cc int 3 1: kd> kP ChildEBP RetAddr f6a9ebc0 80a7d9ed nt!DbgBreakPoint f6a9ec0c 80a806a1 nt!MiCheckCacheAttributes+0x21d f6a9ec40 80b95890 nt!MiMapViewOfPhysicalSection+0x31b f6a9ec98 80b96099 nt!MmMapViewOfSection+0x130 f6a9ed28 80ad5ae8 nt!NtMapViewOfSection+0x313 f6a9ed28 7c94eb94 nt!KiFastCallEntry+0x158 0012e914 7c94dc61 ntdll!KiFastSystemCallRet 0012e918 10044079 ntdll!NtMapViewOfSection+0xc WARNING: Stack unwind information not available. Following frames may be wrong. 0012ea2c 1003f501 SI3+0x44079 0012f600 1002bc69 SI3+0x3f501 0012f7c8 10005508 SI3+0x2bc69 0012f7f4 00408714 SI3+0x5508 0012ff08 7c172fb6 PCMark04+0x8714 0012ffc0 7c816d4f MFC71+0x32fb6 0012fff0 00000000 kernel32!BaseProcessStart+0x23

• 　検索性を上げるために、日記の中の横文字をなるべく元の英語表記してみようと思いたつ。見た目があまりに悪ければまた元に戻すつもり。・・・と書いておいてやり始めたら、めちゃめちゃ見た目が悪い(笑)「DriverのDebug用に」と書いた時点で、すぐ止めた。
  
  　全部英語表記は非常に見た目が悪いということが分かったが、かといって全部カタカナも見た目が悪いし読みづらい。どのくらいが丁度なのか難しいところ。いっそ全部英語で書く・・・というのも面倒だし、それもまた読みづらい。
  

2005年4月25日(月)

• 　またGMA900イネーブラネタ。ひとまず発生している障害をまとめてみる。
  
  
  • ブート時、VGAスクリーンへの切替が正常に行われない。（例えばブート時にchkdskを実行する設定にした場合、chkdsk実行中の画面が表示されない。）
  • 主にDirect3D使用アプリケーションで、フリーズ等の重大な障害が発生する。
  • 主にWindows 2000やWindows Server 2003等、Windows XP以外の環境で、イネーブラ自体が起動せず915ビデオドライバの組み込みができない。

• 　ブート時にVGAスクリーンを出すのは標準搭載のVGAドライバの役目のはずなのに、なぜ出ないのだろう。もしかしてint 10hがミニポートドライバにルーティングされるようになっているのか。すぐに分かりそうなものなのだが、ブート時に画面を切り替えるシーケンスがどこにも載っていないので、どのタイミングで調べたらいいのか分からないでいる。
  
  　D3Dアプリのフリーズは、メモリ256MBではほぼ確実、512MBではdxdiagで発生せず規模の大きいもの（ベンチマーク等）で発生、1GBではベンチマーク等でも発生しないので、メモリ確保（の初期化ルーチン）周りに問題があるものと思われる。フリーズ時点でデバッガが接続できればすぐ原因が分かりそうなものなのだが、フリーズするとデバッガにも反応しなくなるからなぁ・・・
  
  　イネーブラが起動しないのは、もう完全にイネーブラ自体のプログラミングが雑なせい。まだ全般的にテスト的実装になっているが、フリーズのような重大障害を解消してから奇麗な実装に整理しなおすつもり。
  

• 　ところで、テストのために何度もDIMMを着け外ししているが、以前DIMMスロットの接点寿命は着脱100回程度と読んだことがあるので、ちょっと気になる。確かに100回程度の寿命があれば普通は十分なんだが。
  

2005年4月24日(日)

• 　久しぶりにGMA900イネーブラ以外のネタ。
  

• 　Windows XP Professional x64 Editionの正式発売開始によって、にわかに64ビットコンピューティング環境の話題が盛り上がっている。しかし、アドレス空間に関してはどれもこれも「これで4GB超メモリ実装の意味が出てくる」的な勘違いばかり書かれている。コラムを書く人の中にシステムエンジニア出身者はいないのだろうか。
  
  　メモリ実装量を制限するのは物理アドレス空間の広さ、アプリケーションのアドレス空間を制限するのは仮想（論理）アドレス空間の広さである。PC Watchでおなじみの後藤弘茂氏も以前書いていたと思うが、物理アドレス空間が広がることと仮想アドレス空間が広がることに直接的な関係はない。実際、Windows 2000（もしかしたらWindows NT 4.0）以降のサーバ版では仮想アドレス空間を32ビットのまま変更することなく物理アドレス空間を32ビットから36ビットに広げている。「4GBを超えるメモリを使う」ことが目的ならば必ずしも仮想アドレス空間を広げなくても良いのである。
  
  　ではWindows x64 Editionで仮想アドレス空間が64ビット化されることにはどのような利点があるのか。それは仮想アドレスで使用できる（ほぼ「アプリケーションで使用できる」と言い換えてもよい）仮想メモリ領域が広がることである。と書くと「なんだやっぱり使えるメモリが増えるということなんじゃないか」と思う人がいるだろう。しかし、この2つは全く異なる。メモリの実装量が全く変わらなくても仮想アドレス空間の64ビット化によって仮想メモリ領域は大きく広がり、アプリケーションにとっては実際のメモリ実装量の増加よりもこの仮想メモリ領域の拡大こそが重要なのである。
  

• 　仮想メモリ領域が広がることによって、これまで置きたくても置けなかった巨大なデータを仮想メモリ領域上に一度に置くことができるようになる。これが仮想アドレス空間の64ビット化による大きな利点の1つである。しかし従来の32ビットシステムでも仮想メモリ領域の大きさは数GBある。これを超えるような巨大なデータがそんなにあるのだろうか。
  
  　現在ではギガバイト級のオーディオデータ・ビデオデータも珍しくない。また、単一のデータはそれほど大きくなくても、画像編集ソフト・音声編集ソフト・動画編集ソフト等の編集ソフトで数十・数百のデータを扱えば、編集対象データの総量が数GBを超えてしまうこともあるだろう。
  
  　このような場合、従来の32ビットアプリケーションでは、仮想メモリ領域に必要に応じて編集対象データの一部だけを置く等、仮想メモリ領域の大きさに注意する必要があった。このような工夫はOSあるいはハードウェアの制限を回避するために必要とされるものであって、プログラムが行うべき処理の本質（例えば編集処理）とは全く関係がない。そのような本質的でない「工夫」は仮想アドレス空間の64ビット化によって不要となるのである。
  

• 　2ヶ月ほど前に作成した多数決プログラムも、仮想アドレス空間が64ビット化していれば大きな恩恵が得られたはずのプログラムである。数百MBのファイルを100個程度扱うプログラムなのでデータの総量は数十GBになり、従来の仮想メモリ領域ではとても収まらないので仕方がなく一度に1ファイルあたり数MB（全部で数百MB）ずつデータを仮想メモリ領域に置いていたが、この処理はかなり面倒であった。仮想アドレス空間が64ビット化すれば前ファイルの全データを一度に仮想メモリ領域に置いても全く問題ないため、非常にプログラミングは楽になったはずである。
  

• 　そもそも仮想メモリの利点は、いつ必要なのかを考えることなく、いつでも、いくらでも事前に確保しておけることにある。「いつでも、いくらでも」確保できるようにするには、予想される確保量に対して充分な領域がなければならないのは明らかであろう。
  
  　Windows XP/2000の前身であるWindows NTが登場した当時は、Windows自体が32MBもあれば動作し、仮想メモリ領域も全部で数百MBあれば十分足りていた。最大数GBという上限は充分だったわけである。しかし現在はDVD1枚分、数GBのデータを処理するようなことも珍しいことではなく、既にそれだけでも32ビットシステムの仮想メモリ領域の上限を超えてしまっている。そのため、現在の動画処理系アプリケーションなどではデータの入出力にかなり面倒で本質的でない処理を行っているであろうと思われる。
  
  　仮想アドレス空間の64ビット化は「将来」に対するヘッドルーム確保などではなく、既に発生し始めている面倒を解消するために「今」必要とされているものなのである。
  

2005年4月23日(土)

• 　うーん、どんどん開発ペースが落ちてくるな。モチベーション急降下中。
  

• 　ビデオミニポートドライバのIOCTL呼び出しが多数あることが分かったので、どのIOCTL呼び出しで落ちているのか調べてみた。同じプログラムでメモリ1GB実装の場合（落ちない）と256MB実装の場合（落ちる）で比較してみると、IOCTL_VIDEO_SHARE_VIDEO_MEMORYを発行する前後で落ちていることが分かった。
  
  　念のためIOCTL_VIDEO_SHARE_VIDEO_MEMORY処理コードの先頭にブレークポイントを置いてみたところ、ここに到着する前に落ちている。IOCTL_VIDEO_SHARE_VIDEO_MEMORYの直前に発行しているIOCTLはメモリ割り当て要求だが、こちらはちゃんと終了している。ということは、この2つのリクエストの間で何か落ちるような処理をしているということか。
  

• 　ひとまずここまで当たりをつけておいて、今度は誰がIOCTL_VIDEO_SHARE_VIDEO_MEMORYを発行しているのか調べることにした。ところが、これがなかなか見つからない・・・
  

2005年4月22日(金)

• 　これまで「分かる限り915マシンと同じ環境を整えてドライバを動作させる」ことを目標に解析を行っていたが、今日からはちょっとこれまで方針を変えて「異常動作をしている場所を特定し、それに関連するデータを探す」ことを目標にしてみた。
  
  　まず、不具合が発生する適当なテストプログラムの用意。dxdiagや3DMarkでも不具合は発生するわけだが、ちょっと規模が大きすぎるしソースもないから不適。Direct3Dを使った小さなサンプルプログラムを適当に探してきて使用することにした。
  
  　しかし、不具合の根本原因はカーネルモード側で発生しているから、ユーザモードからのコールをカーネルモード側の実行コードまで追いかけないといけない。そもそもデバッガでそんなことができるのか？ それも含めて調査だな・・・面倒くさい・・・
  

2005年4月21日(木)

• 　きのうできたプログラムをPC屋店頭の915マシンで実行してデータのダンプを取り、それを解析してみたところ、やはりSMIを使ってBIOSからデータを取得していた。それだけでなく、SMI経由でBIOSにデータを渡しているところもある。BIOSから受け取るデータの中身が何かはだいたい分かったのだが、BIOSに渡しているデータの使い道が分からない・・・
  

• 　とりあえず、BIOSから受け取るデータを取得したダンプと同じにするようにイネーブラを書き換えて実行してみたが、dxdiagのDirect3Dテストで落ちるのは変わらなかった。くそー、あとどこが違うんだよー。
  

2005年4月20日(水)

• 　SMI関連情報を取得するプログラムは簡単にできると思っていたが、思わぬところで足踏み。情報取得自体は簡単にできた（というより、これまでのイネーブラでも行っていた）のだが、取得した情報を持ち帰るにはファイルに出力する必要があり、ドライバからファイルを作成しデータを出力するのに手間取ってしまった。
  
  　いままでのWin32の常識が通用しないのが辛いところ（って楽しんでるわけだが）。まるでDOSのTSRプログラムを作成しているような感覚だ。
  

2005年4月19日(火)

• 　やった！ とうとう確保メモリ量を変更することができるようになった。あとはベンチして256MBで試してデバッグ用コードをコメントアウトしてコードを整理してUIを作って公開だ。今度は0.10を名乗れるかな。・・・と思って256MBに戻したら、やっぱりハングした。それどころか、1GBのままでも確保メモリ量を32MBにするとベンチ途中でリセットしたりする。ダメダメじゃん。やっぱり915実機からライブデータを抜いてこないとダメなのかな。
  
  　とりあえず明日は915実機からSMI関連情報を取得するプログラム作って、PC屋店頭で試してみることにしよう。
  

2005年4月18日(月)

• 　近所のPC屋にいってSystem Management BIOSを実機で調べてみた。SMBIOSデータテーブルをダンプして確認したが、メモリ容量設定と思わしきデータはなし。残念。だがこれで調査対象候補が1つ減ったので良しとしよう。
  

• 　SMIの正体を知るためIA-32 Intel Architecture Software Developer's Manualを読み、E7221チップセットの仕様書や実際のレジスタ設定内容とつき合わせてみた。結局分かったことは、SMI実行時のプログラム内容にアクセスすることは（BIOS自体のコードを見る以外の方法では）できないということ。SMIをフックするというわけにはいかないのか・・・
  

2005年4月17日(日)

• 　診断メッセージを読んではWinDbgで対応場所をチェック。GMA900のホワイトペーパーに「SMIを使ってシステムBIOSと通信する」と書いてあったのだが、案の定、
  
  　　　　util.c::util_GetInternalGraphicsConfig
  　　　　*** Unable to call SMI from SoftBIOS: Previous SMI call failed (BIOS may not support SMI) ***
  
  　なんてメッセージが出ている。今度はSMIのお勉強か・・・ざっと調べてみたのだが、CPUのSystem Management InterruptやMCH等のSMBusインターフェース、ACPIのSMBus対応やSystem Management BIOS Specification等、どれがどういう関係にあるのかさっぱり分からない。まぁゆっくり読んでいくしかなかろう。orz
  

• 　某所で「作者のブログ、ハケーン」なんて書かれていた。それに対するレスポンスを見ていると、どうも見つけてた人は割といたようだ。まぁトリップも書いてるから、ぐぐればすぐに出てくるだろうけど。
  

2005年4月16日(土)

• 　きのうの覚え書きは、あっちこっちフックしまくっているのでマルチプロセッサ環境（HT含む）で不安定にならないようにスピンロックで保護が必要、という意味だったのだが、今日また思いつきでフックのタイミングを変更したら必要なくなってしまった。
  
  　これまでフックの設置・解除を動的に（極端なところではIRP Completion中にも！）行っていたので保護は必須だった（にも関わらずやっていなかった）のだが、よくよく考えてみるとAPIの呼び出し先アドレスの解決はテーブルベースなので、テーブルのエントリアドレスさえ書き換えてやれば実コードにパッチする必要はないので、ブートデバイスの初期化時に静的なフックのみ行えばOKだった。
  
  　これでフックにまつわる不安定性はなくなるはず。（でも新機能が何もないまま、これ以上リリースだけ増やすのはやめておこう・・・）
  

• 　順番的にはこちらのほうが先なのだが、純正915ドライバから診断用メッセージを表示することができるようになった。
  
  　もともと915ドライバには診断用メッセージが多数埋め込まれていて、要所要所でメッセージ通知関数を呼び出しているのだが、この通知関数に中身が全くない（void notify() { } みたいな関数になってる）ので通常はメッセージが外に出ることはない。
  
  　そこに（またしても）パッチを当ててDbgPrintにメッセージを渡すようにしたところ、出るわ出るわ、山のようなメッセージ。フィルタをかけてないせいもあるのだろうが、ブートするだけで8000行も出てくる。スタックトレースも表示するようにしたから、解析すればプログラムの構造がだいぶ分かりやすくなるはず。解析するプログラムを書けばね・・・orz
  

2005年4月15日(金)

• 　今日の覚え書き。HOOK_DATAはスピンロックで保護が必要。
  

2005年4月14日(木)

• 　さっそく昨日探し出した方法でPCIドライバのDriverEntryをフックし、その中で設定しているIRP_MJ_PNP処理ルーチン（PciDispatchIrp）を差し替え。うまくいった。しめしめ。次はPciDispatchIrpがIoCompleteRequestを実行する直前にIRPの中身を見て、必要に応じて書き換え。となるとまた今度はIoCompleteRequestのフックか・・・フック地獄だな。まぁいいや(^^;
  
  　これでID文字列の書き換えもうまくいった。次はIRP_MJ_PNP, IRP_MN_QUERY_INTERFACEのGetBusDataポインタでも差し替えるか・・・と思ってその中身を見たら、なんとPnpReadConfigであった。これってVideoPortGetBusDataが呼び出してる関数そのものじゃないか。ということは、GetBusDataポインタを差し替えればVideoPortGetBusDataのフックは必要なくなるはず。実際にやってみたらそのとおりだった。
  
  　これでPlug & PlayのデバイスIDは完全に差し替えることができた。が、HalGetBusDataするやつがいないとも限らないので、念のためHalGetBusDataのデータも差し替えてみた。これで、自作Dumpdata.exeが取得するデータもちゃんと変わる。
  

• 　そうそう、VideoPortGetBusDataをフックする必要がなくなったおかげでPsSetLoadImageNotifyRoutineを使う必要もなくなったのは嬉しい。このAPI、「システム全体で8個まで使用できる」なんていう、Windows NTベースにしては珍しい制限がついているので。
  
  　Win16の頃はこういう制限たくさんあったんだけどね。DC（Display Contextの略だっけ？ Device Contextの略だっけ？）がシステム全体で4個だかまでしか使用できなくて、開放し忘れてるとあっという間にハングアップしてしまうとか、デバッガがその貴重なDCのうち1つを占有してしまうとか（これはTurboDebugger for Windowsのことだ(笑)）。
  

• 　さて、今度はインストールのためのInfファイル作成。まったく次から次へと新しいことばかり挑戦させられるな。楽しいったらありゃしない(笑)・・・あれれ？ なんか、ドライバのインストールなのにMicrosoftの認証がどーとかこーとかの警告メッセージが出ないんですけど、いいんでしょうか？
  
  　あー、ようやくできたと思ったら、なんかうまくコピーされたりされなかったり、C:\Windows\system32\driversにコピーしなきゃいけないのにC:\Windows\system32にコピーされたり。Infの書き方むずー。
  

2005年4月13日(水)

• 　PCIドライバをフックする方法は未だに思いつかない。とりあえずテストのため、デバッガを使ってイネーブラのDriverEntry内で停止させ、同じくデバッガでPCIドライバのDriverEntryを変数に直接入力することにした(笑)
  
  　PCIドライバはデバイススタックのいちばん下にいて、そいつがPlug & Play IRPのIRP_MJ_PNP, IRP_MN_QUERY_IDに対応してID文字列を組み立て、IoCompleteRequestでIRPを完了している。もう少し詳細に書くと、まずデバイスマネージャはIRPを組み立ててからPciDispatchIrp（PCIドライバがDriverEntryで通知した関数）を呼び出す。PCIドライバはPciDispatchIrpの中でリクエストを判別、IRP_MJ_PNPの場合はIRP_MN_xxxによってさらに分岐し、IRP_MN_QUERY_IDの場合は最終的にPciQueryIdを呼び出してID文字列を作成。その後PciDispatchIrpに処理が戻り最後にIoCompleteRequestを実行して終了する。
  
  　この流れであれば作成しているID文字列はPciDispatchIrpから返ってきた時点でIRP内部を見れば分かるだろうと思いPciDispatchIrpをフックしてみたが、見えるものは意味の分からない値ばかり・・・
  

• 　実はこれ、Windows NT系ドライバ初心者であれば誰でも必ずやるであろう失敗の1つなのであった。IoCompleteRequestの実行完了後はIRPの内容が保証されていないので、IRPの内容を参照するためにはIoCompleteRequestの実行完了前に行う必要があるのであった。これに気付くのに何時間もかかってしまった。
  
  　気付いてしまえば、値を確認するだけならばどうということはない。IoCompleteRequestを実行している場所の前後にブレークポイントを置いて実行しIRPの内容（正確にはIRP内のIO_STATUS_BLOCKの内容）を確認したところ、PCIバス上のデバイスのベンダ識別文字列が次々と出てきたのであった。これで、PCIドライバがPlug & Play IRP（IRP_MJ_PNP）に対応してベンダID等を返しているのはほぼ間違いないことが分かった。
  

• 　さてそうしたら、次はどうやってその内容を改変するか。いちばん手堅く、またWindows NTシステム的に正しいのはPCIドライバの直上にフィルタドライバを入れることなのだが、どうもそのセットアップ方法がよく分からない。行儀悪く関数フックでいくとすればPCIドライバのDriverEntryを掴みこむ方法を探す必要がある。
  
  　PCIドライバのDriverEntryをフックするには、PCIドライバよりも先に初期化される必要がある。Bootデバイスの初期化は読み込み順なので、そのためにはPCIドライバよりも先に読み込まれている必要がある。そういう場合、PCIドライバに動的にリンクしてしまうと読み込み順序はどうなってしまうのだろうか・・・やってみれば分かるんだけど、どうも面倒でいかん(^^;やってみた。正確には、やってみようとしたが、できなかった。なぜか→PCIドライバにはExportが1つもなかった(爆)
  

• 　こーなったらしょうがない、カーネルのモジュール一覧を自前でトラバースだ（どんどん泥沼）。どうせ今でもビデオポートのドライバモジュールアドレスからExportをトラバースしてるんだから大して違いはない。
  
  　そんなAPIは公式にはないわけだが、カーネルデバッガでターゲットに接続すると「PsLoadedModuleList = 0x80124100」みたいな意味深なメッセージが出てくるので、多分この変数にモジュール一覧関係の構造体のポインタが入っているのであろう。どれどれ・・・って、これもExportされてないじゃないか。困ったときのぐぐだのみ。すると、ZwQuerySystemInformationなるAPIがあるらしい。今度はこれで調べてみると・・・おー、サンプルコードあった！ラッキー！
  

2005年4月12日(火)

• 　た、楽しい・・・楽しすぎる(笑)
  
  　Windowsのドライバ書きがこんなに楽しいとは。ちょっとした間違いでシステムクラッシュ。限りない再起動。Life&Deathなこの感覚はMS-DOS時代を思い出させる。
  

• 　きのうの続き。いちおう自前のドライバ書いてみたんだが、ブート時に読み込むドライバの場合、Plug and Playドライバと扱いが違うのかうまくフィルタドライバとしてインストールできなかった。またしてもやり方が間違っている可能性が高いが、それを追求する前に「本当にこのやり方で目的のことが実現できるのか」の調査を先にすることにした。
  
  　まずビデオポートドライバのフック。こいつは読み込み順序がずっと後のほうなので簡単にフックできた。この時点で、Intel純正915ドライバをパッチせずに動作させることができるようになった。
  
  　次にHALのフック。これも最初に必ず読み込まれていることが保証されているのでフックは簡単だった。
  
  　しかし、これでもまだPlug & Playに渡されるデバイスIDが変わらない。多分PCIドライバがPlug & Play IRPに対応してると思うのでPCIドライバをフックしたいのだが、なかなか方法が思いつかない・・・
  

2005年4月11日(月)

• 　ちょっとした成功。と、情けない発見。
  
  　きのう書いてた「仮想アドレスを物理アドレスにいったん変換して、その物理アドレスに別の仮想アドレスを割り当てようとしたが挙動不審」だが、どうしても納得いかなくてもう一度やってみたら、今度はうまく行った。成功！
  
  　前回なぜ失敗していたかというと、実は大事なことを忘れていたから。IoAllocateMdl()しておいてMmGetSystemAddressForMdlSafe()していたのだが、その間にMmBuildMdlForNonPagedPool()が必要なのだった。つまり、allocだけしてinitせずに使っていたということ。何年プログラマしてるんだよ、俺・・・orz
  
  　そしてもう1つ情けないというか何というか。物理アドレスから仮想アドレスを取得したら、元の（仮想アドレスから物理アドレスに変換した、その）仮想アドレスが取得できた。つまり「別の仮想アドレス」は割り当てられなかった(^^;
  

• 　とりあえずアプローチとしては間違ってないと気を取り直して、また別のAPIでalias作成を試みてみた。今度は大成功！これで標準ドライバファイルにパッチを当てないで済むぞ。・・・ちゃんと自前のドライバ書けばだけどね。（それが面倒）。
  

2005年4月10日(日)

• 　きのうの続き。
  

• 　ユーザモードのプログラムであればスタブを割り込ませて必要な情報を差し替えることも容易なのだが（実際その手のプログラムは何度も作っている）、カーネルモードではLoadLibrary()とかGetProcAddress()に相当するAPIがないのでスタブから動的に本来のプログラムにリンクするのが容易ではない。
  
  　それでも、強制的にダイナミックリンクしたりモジュール読み込みのコールバックを設定してモジュール位置を検出したりして、ダイナミックリンク先あるいはダイナミックリンク元にメモリ上でパッチしようとした。かなり面倒な思いをしてPEヘッダからダイナミックリンク構造体を辿ってパッチ先を探すコードを書いたのだが、いざやってみるとカーネルモードドライバ間でもちゃんとメモリ保護機能が働いていてパッチができない。ユーザモードにはある保護属性変更APIがカーネルモードにはないのでメモリ保護を解除することもできない。（すごく面倒なコードだったのに一瞬でダメ出しとは・・・辛い。特定のメモリアドレスのメモリ保護属性をデバッガで表示することできないのかな？ 誰か知ってたら教えてー！）
  
  　作戦を変えて、仮想アドレスを物理アドレスにいったん変換して、その物理アドレスに別の仮想アドレスを割り当てようとしたが挙動不審（エラーにはならないが、同じ物理メモリのエイリアスのはずなのに内容が全く違う）。同じくいったん物理アドレスに変換しておいて、UNIX系で言うところの/dev/memに相当するメモリマップ（\Device\PhysicalMemory）を使って当該物理アドレスを仮想アドレス上にマップしてみたが、マップ時にエラー発生。うーむ、どないせいっちゅうねん。（注：後者は使い方を間違っていた可能性もある(^^;）
  
  　直接Page Table Entry (PTE)を書き換えるという最終手段は残っているのだが、これはあまりやりたくない。なぜかというと、PTEには2種類の構造があってWindowsの起動モード（標準かPhysical Address Extension (PAE)モードか）によって切り替わってしまうので、モード検出と2通りのPTE書き換えコードを書かないといけなくなるから。PAEモードは従来、4GB超搭載マシンでサーバ版Windowsを使う場合しか有効にならなかったのだが、XP SP2と2K3 SP1からは新設されたDEP機能を有効にすると搭載メモリが4GB以下でも自動的にPAEモードになってしまうので対応は必須。
  

• 　・・・と、ここまで試すだけでもずいぶん時間を使ってしまった。とりあえず仮にでも動作するものをリリースして評価してもらうために、4/5に書いた3つの選択肢のうち(2)を採用するのは後回しにして、いちばん簡単な(1)で超プレリリース0.01版とすることにした。（ところで、4/5では「けっこうな量を書き換えるらしい」と書いたが、その後の調査で実は実質的には1バイト書き換えるだけで動作することが分かった。先に試した人は他にどこを書き換えていたんだろう？）
  
  　日が変わらないうちにと急いでパッチ版をまとめて、まずここでリリース報告。（これを書いている時点での最新スレッドはここ）。うーん、すごいレスポンスだ(^^; 「目指せ神」はひとまず達成かな。
  

• 　現時点までで、参考にしたものの覚え書き：
  
  
  • Intel E7221 chipset
  • Intel 915G Express chipset
  • IntelR Graphics Media Accelerator 900 Information
    各チップのデータシート（Specification）は当然、すべてダウンロードして隅から隅まで必読。
  • インターフェース1997年10月号（CQ出版）
    古くてもうバックナンバーも手に入らないかもしれないが、PCIのコンフィギュレーション関係はとても役に立った。同じCQ出版からはPCIバス&PCI-Xバスの徹底研究（TECH-Iシリーズ）も出ているが、こちらはハード寄りの話ばかりでソフト的な話がほとんどないので、今回の用途には不適。
  • OSR Online
    DDK以外でこんなにディープで役に立つドライバ開発情報は他にないのではないか、と思えるような情報が満載。必読。
  • Sysinternalsサイト
    ここのWindows NT系に関する情報はすべて必読。便利ツールも必携です。
  • Programming the Microsoft Windows Driver Model（Walter Oney著／Microsoft Press）
    いまからWindowsドライバ書こうという人は必携。日本語版も出てるが、どうせDDKは全部英語なんだから、英語で読んでおいたほうが後々楽。こちらもWindows XPに関する記述を増やした第2版が出てきます。
  • Inside Microsoft Windows 2000 Third Edition（David A. Solomon, Mark E. Russinovich著／Microsoft Press）
    Windowsドライバ系開発者は、これを読んでおかないとお話にならない。アプリケーションのみの開発をする人でも、読んでおいて損はない。既に第4版が出ていて、Windows XPに関する記述が増えているそうです。
  • Microsoft WHDCサイト
    ドライバ開発をするなら全体をざっと眺めておくべき。とても為になる情報が満載。とくにDriver Fundaentalsの下とDevelopment Tools and Testingの下にある次の3つは必見。
    • WHDC: Windows Driver Development Kit
      
    • WHDC: Debugging Tools for Windows
      
    • WHDC: Driver Fundamentals
      
    WHDCサイト自体は日本語版もあるようだが、見ていないので品質は不明。
  • Windows DDK
    これなしでドライバ開発できたら神決定ｗ
    最近のDDKはものすごい量のドキュメントとサンプルプログラムが付いている。昔のしか知らなかったのでちょっと驚いた。これから入手する場合は最新OSの最新DDKを入手すべし。現在の最新はWindows 2003 Server SP1 DDK。ただし、古いAPIだと使い方の記述がなく「互換性のため残してある」としか書いてない場合があるので、その場合は古いDDKも必要になることがある。今回はWindows NT 4.0 DDKも必要だった・・・

2005年4月9日(土)

• 　さっそく実行結果をレポートしてくれた人がいた。ありがたいことだ。
  
  　実行結果を比較してみると・・・ふむふむなるほど、そうなってるのか。うーん、Reservedなチップセット設定がちょこちょこと違ってるんだけど、Read Only設定で変更できないんだよなー。片っ端からパッチ当てないとダメなんだろうか。
  

• 　そんなことを考えながら、調査のためカーネルデバッガを使ったリモートデバッグの準備。ケーブル箱をひっくり返してヌルモデムケーブルを引っ張り出してきた。最初はメガソフトのMAXLINK用ケーブルを使ったのだが、何度やってもカーネルデバッガ接続待ち状態でデバッグ対象機がハングアップしてしまう。ハイパーターミナルではちゃんと双方向に通信できるからケーブルはOKで設定が悪いのだと思ってずいぶん時間を使ってしまったが、結局、ケーブルを変えたらすぐにリモートデバッグできるようになったのだった。くそー。
  

• 　リモートデバッグを開始してからしばらくして気付いたのだが、どうもこのドライバはチップセットのチェックが割とゆるいようだ。というより、同系統のいろいろなチップセットに1つのドライバで対応するために、少々の違いは自動的に吸収する仕組みになっているようで、簡単なチップセットチェックさえ通り抜ければほぼ問題なく動作した。でも、どうやって「チェックを通り抜け」させるかが問題なんだけどね・・・メンテナンス性を考えると、なるべくドライバパッチは避けたい。それではどうやって実現するか。
  
  　ドライバはカーネルモードで動作してるから「カーネルドライバでチップセットのIDをエミュレート」という手が使えない。下位ドライバからIDを取得しているのであればドライバスタックに割り込んでIDを変更する手が使えるんだが、ビデオドライバ（ミニポートドライバ）はビデオポートドライバからIDを取得する仕様になっていて、ミニポートドライバとポートドライバはドライバスタックの上下関係じゃなくて単なるダイナミックリンクなので割り込む余地が乏しい。うーん、困ったな。
  

2005年4月8日(金)

• 　チップセット設定データ取得プログラムの続き。ようやくDOS版を作る環境ができたので、Win32版からポーティング(笑) int86x関数とかREGS構造体とか、そういうたぐいのものがあったことは覚えてるんだけど使い方をすっかり忘れていた。どのヘッダファイルを#includeするんだったかとか。
  
  　作成自体はとても簡単で拍子抜けするくらい。これをWin32版プログラムのスタブに指定して、DOS/Win32両用EXEの出来上がり。でも情報収集対象の915G搭載機は持っていないので、公開して協力者待ち・・・
  

2005年4月7日(木)

• 　今日はなんか長いぞ。
  

• 　きのう書いてたチップセット設定データ取得プログラム、まずWin32版ができた。
  
  　このプログラムはPCIのコンフィギュレーションレジスタにアクセスする必要があるのだが、NT系OSではユーザモードプログラムから直接アクセスできないのでカーネルモードドライバを書く必要がある。NT3.xの頃にごく簡単なドライバを書いたことがあったけど、それ以来久しぶりに、カーネルモードドライバを書くことになった。最近のDDKはサンプルが豊富で助かる・・・
  
  　PCIの資料は、なぜか手元にあったCQ出版インターフェース1997年10月号なんていう古い雑誌。特集が「これで作れる! PCIボードのハード&ソフト（PCIバス/プラグ&プレイ/Windowsデバイスドライバの完全マスタ）」なんて内容で、まさに今回の作業にうってつけ(^^;
  

• 　さて、Win32版はWindows 2000/XP/2003上で実行してもらうことになるわけだが、この環境では既にGMA900用ビデオドライバが入ってることがほぼ確実なわけで、このドライバがチップセット設定を変更してしまっている可能性もある。知りたい情報は「GMA900用ビデオドライバが起動した後の状態」よりもむしろ「同ドライバが起動する前の状態」なので、今度はこれを取得するためにDOS版を作ることにした。が、しかし・・・
  
  　幸い手元にはVisual C++ 1.5（Win16版）があり、これに含まれているMicrosoft C/C++コンパイラバージョン8はDOSアプリケーションとWin16アプリケーションを生成できるので、これをインストールすることにした。しかし、こんな古いアプリケーションをWindows XPの上にインストールするのは避けたい。インストーラがちゃんと動作しないかもしれないし、それどころかテキストベースのシステムファイルを変な風に書き換えてしまうかもしれない。アンインストールもちゃんとできない可能性が高いし。なので、Virual PCで仮想マシン環境を作って、そこにVC++1.5をインストールすることにした。また、どうせ仮想マシン環境を作るんなら、ちゃんとインストールできるかどうか分からないWin32環境より絶対確実なWin16環境のほうがいいだろうと思い、昔懐かしいWindows 3.1環境を作ることにした。
  
  　MSDNからWindows 3.1をダウンロードしながら（まだちゃんと残ってる！）、そーいえばWindows 3.1はセルフブートできないからMS-DOSが必要じゃないか、と思い出し、続けてMSDNからMS-DOS 6.2/Vをダウンロード（こんなものまで残ってる！！）。さてまずはOSのインストールだ・・・と、ここからが長かった。
  

• 　まずはMS-DOSのFD作成。FDを作成するバッチファイルが用意されていて、それを実行して指示に従えば6枚のFDが作成されるようになっている。Virtual PC上に用意したWindows XP環境からこのバッチファイルを実行し、同じくVirtual PC上に用意した仮想FD×6枚分を作成。これは割とスムーズだった。
  
  　次に、将来Windows 3.1環境となる仮想HDにMS-DOSをインストールするべく1枚目の仮想FDでブート。ところが、いざインストールしようとすると、既にインストールされているMS-DOSのアップグレード用だから、MS-DOSがインストールされているパーティションにしかインストールできませんと文句を言う。それじゃあと、あらかじめWindows 98の起動ディスクでブート可能にしてみたが、それでもダメ。うーん困った、MS-DOSなんてもう持ってないよ・・・
  
  　というところで、ふと思い出した。確かMS-DOSもバージョン5以降だったか6以降だったかではF8でconfig.sysとautoexec.batのステップ実行ができたはず。それなら、インストーラが起動する前で止めてコマンド手打ちすればHDを「MS-DOS 6.2/V」でブート可能にできるはず。あとはインストーラが同一バージョンのMS-DOSでも「アップグレード」と認識してくれることを期待するのみ。
  
  　やってみると、めでたく、インストーラは同一バージョンでも「アップグレード」と認識してインストールさせてくれたのでした。はぁ・・・
  

• 　その次はWindows 3.1のインストール。こちらはインストール用ファイルにアクセスできさえすれば楽勝・・・と思っていたのに、またトラブル。orz
  
  　まずVirtual PCの「バーチャルマシン追加機能」をインストールした。この機能をインストールしておくと共有フォルダ（仮想マシン環境からホストOS上のファイルにアクセスできる機能）が使えるようになるので、インストールは必須と言ってもよい。これをインストールしたので、ダウンロードしてあるWindows 3.1インストール用ファイルには簡単にアクセスできた。
  
  　ところが、インストール用ファイルのsetup.exeを実行するとなぜか仮想マシンがハングアップする。setup.exeにはハードウェアのチェックや常駐ソフトのチェックを省略するオプションがあるので、考えられる限りのオプションを付けて試してみたが効果なし。またしても困ってしまったところで、またしてもふと思いついた。もしかして「バーチャルマシン追加機能」が悪さをしてないか？
  
  　さっそく、先のF8を使って「バーチャルマシン追加機能」の実行だけをスキップすることにした。「バーチャルマシン追加機能」なしでは共有フォルダが使えないので、またVirtual PC上のWindows XPを使って、もう1つ別の仮想HDDにWindows 3.1インストール用ファイルをコピー、その仮想HDを2台目のHDとして使用することにした。
  
  　準備ができてsetup.exeを実行すると、今度は何の障害もなくインストールできた。いやー速い速い。ほんの10秒かそこらでインストールが完了する。まぁよく考えてみればWindows 3.1のインストール用ファイルは全部で16MB「しか」（現在の感覚では）ないわけで、いまどき16MB程度のソフトのインストールが10秒くらいで済むのは当たり前ではあるが、昔FDを10枚以上もとっかえひっかえインストールした覚えがあるので、同じソフトでこうも違うとやっぱりちょっと新鮮な驚きがある。
  

• 　さて、ようやくその次はVC++1.5のインストール・・・の前に、画面の解像度が640x480x16色ではいかにも狭くて使いづらい（だいいちVC++のインストーラのダイアログも画面内に収まらない）ので、高解像度のビデオドライバをインストールすることにした。しかし、これもまた難航。
  
  　仮想マシンのビデオはS3 Trio 32/64 PCI互換ということになっている。確かこのビデオカードはPCIの割と初期のものだった気がするので、当時ならWindows 3.1用ドライバはまず確実にあったはず。でも今でも用意してるかどうか。だいいちS3ってもうどこだかに買収されたんじゃなかったっけ？ いちおうぐぐってみると、どうやらまだ会社はあるらしい(^^; VIAとの合弁になったのかな。それはともかくドライバ探し。
  
  　なんかあっちこっちたらい回しにされた挙句、最終的には775 Trio64V2/DX, 785 Trio64V2/GX用ドライバならあることが分かった。うーん、これってTrio32/64と同世代だけど若干新しいんだよね。ちゃんと動くのかな？
  
  　他にそれらしいのはないので仕方なくこれを試してみると・・・ううっ、Windows 3.1でのビデオドライバのインストール方法なんてすっかり忘れてる・・・懐かしい「アプリケーションエラー」と再会できました。orz
  
  　めげずに色々試してみると、どうやら(1)アプリケーションエラーが出ても再起動すれば動く、(2)256色・32K色・64K色・16M色の4モードあるうち16M色しか動かない（それ以外は「このビデオモードは利用できない」と文句を言って起動しなくなる）、ということが分かった。16M色モードってGDIオブジェクトが無駄にシステムリソースを圧迫するから使いたくないんだが、仕方がない・・・とりあえず800x600x16Mで動くようにできた。
  

• 　今度こそVC++のインストールだ！IDEは使わないしWin16開発もしない、C/C++コマンドラインコンパイラとライブラリだけのインストールだけど・・・今度は何もハプニングなし。本来こうあるべきだよね。インストール時のダイアログが若干画面からはみ出していたが、必要な情報は全部見えた。800x600でこれでは、640x480のままだったらどんな悲惨なことになっていたことか。
  

• 　コンパイル作業までWindows 3.1の中でやる気は全然ないので、今度はインストールを完了したC/C++コンパイラ等のファイルをホストOS側にコピー。ところが、こんな単純コピーでも落とし穴が。
  
  　いったんDOSに落ちてxcopyでコピーを開始したところ、途中でハングアップしてしまう。そういえば似たような現象が昔もあったような・・・どうやらSmart Drive（MS-DOS標準のディスクキャッシュマネージャ：今の若い人は知らないかもしれないが orz）がキャッシュしたデータをちゃんと吐き出せなくて落ちた模様。小さいファイルならコマンドプロンプトが出たところで吐き出すところだが、（DOSにしては）大きいファイルばかりのコピーだったので想定外だったのか。まぁ有り体に言えばバグなんだが、今更追求する気もなし。
  
  　これも何度試しても同じ現象が発生するので、DOSでxcopyするのは諦めてWindows 3.1のファイルマネージャでコピーしてみたところ、今度は成功。ふぅ。ここまでで3時間くらいかかっただろうか。
  

• 　さてさて、ようやくインストールを完了してホストOS側に引っ越しも済ませたMS C/C++コンパイラだが、cl.exeを実行してようやく思い出した。MS C/C++コンパイラはバージョン6まで16ビットDOSアプリケーションだったが、バージョン7でVCPI対応（実際はDPMIにも対応していたのか？）32ビットアプリケーションになり、バージョン8からはWin32コンソールアプリケーション（PhalapのTNT DOS-ExtenderでDOSでも動作可能）になったのだった。当時Windows NT 3.1で快適に動いていた覚えがあるが、もちろんWindows XPでも快適に動作する。これも一種のクロスコンパイル環境か？
  

2005年4月6日(水)

• 　GMA900イネーブラを作り始めたが、動作が中途半端。GMA900を初期化するのに何が必要なのか分からないのが痛い。誰か915系チップセットのマシン持ってる人で協力してくれるといいんだけど・・・
  
  　とりあえず、915系チップセット上でデータを取るプログラムを作って公開しよう。まだ出来てないけど。
  

2005年4月5日(火)

• 　ちょっと前にUSB 2.0の話を書いたが、実はうちにはUSB 2.0対応ポートもUSB 2.0機器も1つもなく、USB 2.0対応機器が欲しいと思っていた。
  
  　そんなときに某氏にそそのかされたのがDELL SC420の特価販売。これまた欲しいと思っていたHT対応CPUもキャンペーンのアップグレードで付いて、価格は\24,000弱。1日ほど悩んだあげく購入。それが3月22日のことだったのだが、今日ようやく到着。さっそく開封。
  
  　うーむ、確かにPCI Express x8スロットにx16サイズの（でも仕切りの多い変な）コネクタが付いてるぞ。基板の配線はx8じゃなくてx16だな。コネクタにはx8までしかピンがないから配線だけあっても意味ないが。しかしx16のパターンが引いてあるということは、E7221チップセットなのに915Gチップセット用の設計を流用したのかな。だとすると、PCI Express x8にもSMBusの配線がちゃんと通ってるのかも。それならADD2カードが使える可能性もあるな。
  
  　チップセットといえば、E7221チップセットのビデオ用ドライバを入れてちゃんと動作することを確認したあとで、念のため(?)915Gチップセットのビデオ（GMA900）用ドライバを入れて試してみた。あっさり敗退。まぁそうだよなぁ。いちおうINFファイルを書き換えたりドライバのPCIデバイスIDチェックにパッチを当てたりしてみたんだけど、うまくロードしてくれなかった。GMA900かどうかのチェックはそれなりにしてるみたい。
  
  　それなら、ドライバから見てGMA900に見えるように何かの手を打てばいいんだろうか。すぐにはできないが、ちょっと試してみることにしよう。（これができたら神？そのときは◆xcrOSgS2wYで報告するからね。）
  
  　・・・って、すっかりUSB 2.0から離れてるやん・・・
  

• 　気を取り直して、ドライバにGMA900と認識（誤認識）させる方法だが、いくつか考えられる。
  
  (1) GMA900ドライバにパッチを当てまくる
  (2) GMA900のイネーブラドライバを作成し、GMA900ドライバにはPCIデバイスIDチェックのみパッチを当てる
  (3) GMA900イネーブラドライバとPCIデバイスID偽装ドライバを作成し、GMA900ドライバはそのまま使う
  
  　(1)の方法は既に試している人がいるが、けっこうな量の書き換えを要するらしく、面倒なので除外。2番煎じになるし(笑) (2)の方法は割と簡単そう。ただし、イネーブラドライバをどのレベルで実装するかは、これまたいろいろ選択肢が考えられる。(3)の方法は、これが可能であればいちばん美しいのだが、ドライバレベルでPCIデバイスID偽装が可能なのか不明。
  
  　ひとまず(2)で試してみて、うまく行ってなお余力（というか気力）があれば(3)も試してみることにしよう。
  

2005年3月23日(水)

• 　最初に読んだときにはさっぱり理解できなかったのが、時間をおいて読み返したら理解できた・・・ということが、よくある。大昔、小学生の頃にZ80アセンブラの本を読んでさっぱり分からなかったのが、中学生になってから同じ本を読んだら理解できたことがあった。その中学生の頃にI/O誌のC言語の解説記事を読んで理解できなかったのが、高校生になってから読み返したらよく分かった覚えもある。今月も同じような思いをした。
  
  　USB 2.0のハブはTT（Transaction Translator：トランザクション・トランスレータ）という仕組みを内蔵することが必須になっていて、実装方法にはシングルTTとマルチTTの2通りがある。1年半ほど前、Tom's Hardware GuideでこのTTに関する記事を読んだ時には違うがピンと来なかったのだが、USB 2.0仕様書を読み返してようやく「あーTTってそういうものだったのか！」と理解できた。要するに、USBハブのTTはEthernetでいうところのスイッチングハブやデュアルスピードハブに入っているブリッジと同じような機能を持った仕組みで、シングルTTのUSBハブはデュアルスピードハブ、マルチTTのUSBハブはスイッチングハブに相当する。（参考：マルチ　トランザクション　トランスレータ、デュアルスピードハブ、スイッチングハブ）
  

• 　TTはUSB 1.1機器（〜12Mbps）とUSB 2.0のHigh Speed（480Mbps）の間でデータの仲介を行う。1つのTTはUSB 1.1ポート1つ分、12Mbpsまでのデータを仲介することができる。シングルTTハブはTTを1つだけ持ち、マルチTTハブはポートの数だけTTを持っているので、ハブにUSB 1.1の機器をたくさん接続する場合は、ハブがシングルTTかマルチTTかによって転送速度に大きな違いが出てくる。USB 1.1ポートに機器をたくさん接続していて転送速度が足りないからと言ってポートをUSB 2.0に変更しても、シングルTTハブを使用すると結局ハブ全体の合計でUSB 1.1の1ポート分の転送速度しか発揮できない。それに対してマルチTTハブを使用すると、各ポートがUSB 1.1の1ポート分の転送速度を発揮することができ、総転送速度はポートの数だけ増えることになる。
  
  　こういうことに関する記事が1年以上前からあるということは、これはそのくらい前から知られていたはずであるが、あまり聞く機会がない。USBハブのスペックでも、シングルTT・マルチTTの別が書いてあるものは見たことがない。理由はおそらく(1)USB 2.0ハブ用インターフェースチップのほとんどがシングルTTでマルチTTチップは高価、(2)マルチTTチップを使っても謳える利点が「旧式なUSB 1.1機器を使う場合に効果アリ」というだけで謳い文句として弱いので安価なシングルTTチップを使う機器メーカがほとんど、(3)そのため機器メーカはTTについて触れたくない（ユーザには知らないでいてほしい）、(4)多くのライターがUSB 2.0について不勉強でTTについて書かない、(5)そのためユーザがTTについて知る機会が少ない、ということなのではないだろうか。（他人の不勉強をどうこう言えた義理ではないが、まぁそれでもライターはユーザよりは勉強していて当然でしょう。）
  

2005年3月22日(火)

• 　去年の今頃「USB over IPソフトないかなー、作るの面倒かなー」などと考えていたのだが、1年経って再発してしまった。また思い出したようにWindows DDKドキュメントやらUSB 2.0仕様書やらを読み返している。それとProgramming the Microsoft Windows Driver Modelも(^^;
  
  　・・・って、調べてみたら似たようなプロジェクトが2004年10月から走ってるし。あーあ。去年のうちなら先行できたのに。
  

2005年3月21日(月)

• 　また1ヶ月開けちまったい・・・
  

• 　先月やっていた多数決プログラムは、あれから3日程度いろいろやってみたが、結局それ以上劇的に速くなることはなかった。
  
  　まずデータ読み込み時間。1つのファイルだけを完全シーケンシャル読み込みすればHDD読み出し速度と同等の読み込み時間になるのだが、100ファイルの同時読み込みとなるとどうしても各ファイルごと細切れに読まざるを得ない。「細切れ」を大きくすれば読み込みが速くなるが、先に読み込んだデータがページアウトしてしまっては意味がないので適当な大きさに留めなければならないのは前述（2/19）のとおり。Inside Microsoft Windows 2000でファイル読み込みの先読みアルゴリズムやページ再利用アルゴリズムも調べてみたが、現行速度から速くなる余地が見つからない。
  
  　100ファイルの中のある特定の1ファイルの読み込み時間を短縮するのはほぼ限界なので、読み込み対象の100ファイルを別々のドライブ上に分散し「異なるドライブ上にあるファイルは並列して同時に読み込む」ようにしてみた。
  
  　ところで、うちで使っているドライブは2つある。正確には2つのHDDで構成したRAID1（ミラー）ボリュームが1つと、これまた2つのHDDで構成したSPANボリュームが1つである。RAID1からの読み出し速度はcopyコマンドで50MB/sくらい、SPANからの読み出し速度はcopyコマンドで25MB/sくらいで、これはそれぞれ、ほぼ使用しているHDDの読み出し速度のスペックどおり。
  
  　テストで使用しているデータは1ファイルあたり500MBあるので、copyコマンドではRAID1上で10秒、SPAN上で20秒の読み出し時間を要する。多数決プログラムの読み出しルーチンではそれぞれ17秒、34秒というところ。各ボリュームに50ファイルずつ置いたとすると、copyコマンドで全ファイルを読み出すのに必要な時間は1,500秒（500秒＋1,000秒）、多数決プログラムで2,550秒（850秒＋1,700秒）になる。
  
  　ここで各ボリュームから並列して読み込んだとすると、多数決プログラムでの読み込み時間は1,700秒で済む計算になり、copyコマンドでの読み出し時間と同程度まで高速化できる。
  
  　プログラムの最適化からは離れるが、各ボリューム上に置くファイルの数を最適化すればもっと高速化できる。RAID1からの読み出しはSPANからの読み出しの2倍高速なので、RAID1上に全体の2/3、SPAN上に全体の1/3を置くのが最適となる。例えばRAID1上に67ファイル、SPAN上に33ファイルを置くと、多数決プログラムでのRAID1からの読み込み時間が1,139秒（17秒×67ファイル）、SPANからの読み込み時間が1,122秒（34秒×33ファイル）なので、トータルの読み込み時間は1,139秒となりcopyコマンドよりも高速になる。（もっとも、copyコマンドも並列して使えばさらに速くなるのだが。）
  

• 　次に多数決処理時間。と言っても、こちらは既にできることをやり尽くした感じで、もう何も思いつかない。だいたい、読み込み時間を半分にしてもまだ多数決処理のほうがずっと短い状態だから、これ以上多数決処理を縮めても効果はあまりないし。
  
  　やるとすれば、やっぱり読み込みと並行して処理を行い、処理時間を隠蔽するというところだろうか。
  

• 　ちなみに使用しているCPUはAthlon XP 1.47GHz、メモリはPC133のSDRAMなので、今時のクロック2GHz〜3GHzのCPU＋DDR200超のメモリなら、処理時間はさらに半分程度に短縮されるのではないかと思う。ますます、ファイル読み込みがボトルネックになるわけだ。
  

2005年2月20日(日)

• 　多数決プログラムの続き。
  
  　現在のプログラムでは、多数決処理の他に最多数サンプルの出現数やファイル内の最多数サンプル数を数えているが、こういうオマケ処理を省くと8秒が4秒になった。そうすると多数決処理を途中で枝刈りできて、その枝刈りを追加したらさらに2秒短縮して実行時間2秒になった。結果、オマケ処理を取るだけで実行速度は4倍になったことになる。
  
  　この時点で処理スループットは250MB/s程度。出力1バイトあたりのクロック数は1,000クロック強。
  
  　さて、いよいよアセンブラ化を考えてみるか・・・
  

2005年2月19日(土)

• 　多数決プログラムの続き。思いのほか最適化が進んで計時が難しくなってきたので、対象データを増やして再試行。最初のプログラムに5.0MB（5.0*2^20バイト）×100ファイル（合計500MB）の多数決を行わせてみたところ、所要時間は160秒。（うちデータ読み込み時間25秒、多数決処理時間135秒。）
  
  　「読み込み元ファイルが別ドライブにある場合は同時に読み込み」と「多数決処理の順序をキャッシュが効きやすいように変更」の最適化を加えたところ、現在のところ所要時間は24秒まで縮まった。（うちデータ読み込み時間16秒、多数決処理時間8秒。）
  
  　データ読み込み時間は縮めるべくかなり悪戦苦闘したが、おとといの「ちょっと工夫」からあまり縮めることができなかった。コマンドプロンプトのcopyコマンドと比較してまだ1.5倍くらい時間がかかっている（現在のプログラムの読み取り速度は約30MB/s、copyコマンドは50MB/sくらい）ので縮める余地はあると思うんだが、どうやったものか。読み込みバッファを4倍にすれば2割程度スピードアップできるのだが、現時点で1ファイルあたり1MB（100ファイルで100MB）もバッファを使っているので、4倍の400MBとなるとメモリを512MB以上搭載していないと使えないプログラムになってしまい、少々ためらわれる。
  
  　多数決処理のほうは16倍以上のスピードアップと、かなり劇的に高速化できた。が、こちらもスループットは60MB/s程度とメモリバンド幅の1GB/sにはるかに及ばないので、まだまだ高速化の余地はあるはず。今はC++だが、インラインアセンブラを使えば1GBは無理としても300MB/s程度には高速化できるのではないかと思っている。（とすると5倍程度の高速化なので、処理時間は2秒程度になるはず。）
  
  　データ読み込みはCPUをあまり使わないので、データ読み込みの裏で多数決処理をやらせるようにすれば多数決処理の時間を見かけ上ゼロにもできるが、そうするには読み込み用と処理用の2つのバッファが必要になりバッファ容量が倍になってしまうので、これは行わないことにした。バッファサイズを半分にすればよいのだが、そうすると読み込み時間が2〜3割増えてしまうので、処理時間をオーバーラップさせて削減しても相殺されてしまう。多数決処理速度はまだまだ向上の余地があるので、そちらの方向で行くことにする。
  
  　この最適化、まだもう少し続けるつもり。
  

2005年2月17日(木)

• 　手持ちのCDの1枚をキズだらけにしてしまい、普通に再生しても音飛びするようになってしまった。そのデータを何とか再生するべくプログラムを作ってみた。
  
  　再生の方法はこう。まずCD-Audioの内容のダンプをたくさん作成する（とりあえず100個くらい）。キズがついて読み取りができず音飛びするようなところは適当なデータに補完されるが、時々は読み取りができる程度のキズであれば時々は正しいデータになっているはずなので、たくさん作成したダンプの中でデータの多数決を取れば正しいデータが取り出せる可能性が高い。もちろん、読み取りのできる頻度が低く、なおかつ読み取りができない場合の補完データがいつも同じ値になっている場合、多数決の結果はこの補完データになってしまうのであるが。（C1, C2エラーステータスも取得できれば完全になるんだけど、汎用的ではないし。Plextorのドライブならできるのかな？）
  
  　CD-Audioのダンプから自動的に取得するプログラムを作成すれば放置するだけで済むようにもできるんだが、汎用ダンププログラムを作るのは何かと面倒そうなのでひとまず後回しにして、まずは多数決を取るプログラムから作成してみる。が、こっちも別の面倒があったりする。
  
  　1枚のCDから作成するダンプは、多い場合には800MBにもなったりするので、それを100個も作成すると全部で80GBにもなる。これを100個並列に読み込んで処理するとなると、読み込むだけでも工夫しないと効率が悪くなってしまう（例えば100個ファイルを開いてそれぞれfgetcなんてことをやると、非常に効率が悪い）。
  
  　多数決を取るコードも工夫しないと効率が悪い。100個分のファイルから読み込んだデータは普通にやるとそれぞれ別のページに格納されることがほぼ確実なので、ファイル100個分のデータは100ページに分散してしまう。その各ページの先頭から1サンプルずつ読み込んで処理となると、ページ変換テーブルへのアクセスはいったいどれだけになるのか。
  
  　まぁ最初は試しに、データの読み取りだけちょっと工夫したプログラムを作成してテストしてみた。2.5MB（2.5*2^20バイト）×98ファイルの多数決で78秒かかった。
  
  　これを改良していって、どのくらいまで速くなるか・・・
  

2005年2月12日(土)

• 　昨日に引き続き、ハマり「フィルターグラフ」編。
  
  　書くのも面倒になってきたので、結論だけ。フィルターグラフを走らせたり一時停止したり停止したりするたびにちょっとずつメモリリークしている原因がなかなか分からなかったのだが、ようやく判明。IMediaEventに溜まったイベントを処理していなかったせいで、イベントが溜まるたびにメモリを使っていたのでした。ちゃんとイベントを捨てるようにしたらメモリリーク（と思っていた現象）が解消。
  
  　さぁ次は何だ？
  

2005年2月11日(金)

• 　最近のハマり。MFCライブラリをスタティックリンクしたDLLを作成して、アプリケーションからこのDLLを使用する。そして、アプリ側でスレッドを作成して終了すると、そのたびにメモリリークが発生する。その原因を突き止めるのにえらく手間取った。
  
  　作成・終了するスレッドで一切DLLの呼び出しを行わなくても発生するので、おそらくMFCが提供するDllMainがdwReason == DLL_THREAD_ATTACHのときにメモリを確保してdwReason == DLL_THREAD_DETACHのときに開放するはずが、何らかの条件が重なると開放しないのだろうと当たりをつけた。ところが、リークしているメモリ領域を確保している場所を見ると、ここはdwReason == DLL_THREAD_DETACHの時に実行されているではないか。なんでスレッド終了時に確保してるんだ？
  
  　・・・結論から言うと、実はDLL側でCWinAppオブジェクトを作り忘れるとこの現象が発生するのだった。
  
  　このDLLは、最初はMFCを使わずに作り始めたのだが、後でCList等を使いたくなったので#include <afxtempl.h>等を足したものだった。ところが、CWinAppの作成は足し忘れていた。（足さなくてもメモリリーク以外は問題なく動いてたし(^^;）
  
  　さてメモリリークが発生するメカニズムだが、まずDLL内ではMFCが_AFX_THREAD_STATEとAFX_MODULE_THREAD_STATEという2種類のオブジェクトを参照している。このオブジェクトはスレッドローカル記憶域(TLS)を使ってスレッドごとに管理されており、各スレッドでの最初の参照時に自動的に作成されるようになっている。また基本的には、各スレッドの終了時に、そのスレッドに属するオブジェクトが破棄されるようになっている。
  
  　ところがこの破棄のルールには例外がある。それは「_AFX_THREAD_STATEオブジェクトやAFX_MODULE_THREAD_STATEオブジェクトがDLLの初期化時に作成されなかった場合、作成されなかったのと同じ種類で各スレッドに属するオブジェクトをスレッド終了時に破棄しない」というものである。（正確には、オブジェクト自体とオブジェクトの一覧の維持に使用するメモリが破棄されない。）
  
  　由緒正しくCWinAppオブジェクトを作成するようにしていれば、CWinAppオブジェクトの初期化時に_AFX_THREAD_STATEオブジェクトとAFX_MODULE_THREAD_STATEオブジェクトが作成されるので、スレッド終了時には_AFX_THREAD_STATEオブジェクトとAFX_MODULE_THREAD_STATEオブジェクトが正常に開放される。しかしCWinAppオブジェクトの作成を忘れているとDLLの初期化時にAFX_MODULE_THREAD_STATEオブジェクトが作成されないため、スレッド終了時に_AFX_THREAD_STATEオブジェクトとAFX_MODULE_THREAD_STATEオブジェクトが開放されない。
  
  　しかも、MFCによるスレッド終了時の処理では_AFX_THREAD_STATEオブジェクトとAFX_MODULE_THREAD_STATEオブジェクトの両方を参照しているため、スレッド処理中に_AFX_THREAD_STATEオブジェクトやAFX_MODULE_THREAD_STATEオブジェクトが作成されなかった場合、スレッド終了時に作成されてしまう。今回のプログラムではスレッド内で何も処理を行わない（DLLを呼び出さない）ためスレッド終了時に_AFX_THREAD_STATEオブジェクトやAFX_MODULE_THREAD_STATEオブジェクトが作成され、冒頭のような現象（スレッド終了時にメモリが確保され、そのまま開放されない）となったわけである。
  
  　どうせCWinAppオブジェクトは必須なのだから、ASSERTでもいいからCWinAppオブジェクトの不在を通知してくれればいいのに。そうなっていればこんな面倒な思いをしないで済んだのに・・・というような提案をMicrosoftに行うには、どこに行けばいいんでしょう。知っている人、教えてください。
  
  　はぁ、疲れた。
  
  ＃フィルターグラフもメモリリークしてるっぽい。しんど。
  

2005年1月21日(金)

• 　賀正。とか言ってみる。
  

• 　いきなりですがソースネクスト・ドットコム/大人力診療所をやってみた。結果はこんな感じ。
  
  

  上司力検定：横綱級 (20点)□□2005年1月21日受診 あなたほどの上司力があれば、どんなにやりづらい会社でも、どんなに面倒な 部下を持っても大丈夫。その実力を遺憾なく発揮して、出世街道をまい進して ください。ま、仕事力とかもあわせ持ってないと宝の持ち腐れですけど。 ベンチャー力検定：アニキ級 (16点)□□2005年1月21日受診 あなたは、ウマが合う部下からは「アニキ」と慕われる立場になれる程度の ベンチャー力は持っています。大それた野望を抱かなければ何とかなるで しょうが、サラリーマンと比べてどっちがいいと考えるかはあなた次第です。 宴会力検定：飲めや歌えや級 (23点)□□2005年1月21日受診 あなたほどの並はずれた宴会力があれば、どんな宴会でも楽しめるし、 たいていのピンチは乗り越えられるはずです。これからも宴会の場をリード し続けるのが、あなたが天から授かった使命と言っても過言ではありません。 モテ力検定：十人並み級 (12点)□□2005年1月21日受診 あなたは、そこそこのモテ力の持ち主。本人の努力や心がけに応じて、 出会いに恵まれたり、男女交際の醍醐味を味わえたりするでしょう。「自分は モテるタイプ」とカン違いすることだって、けっして不可能ではありません。 旦那力検定：夫婦茶碗級 (15点)□□2005年1月21日受診 あなたの旦那力は、邪魔にはならないけど役にも立たない程度の大人っぷり。 男性の場合も女性の場合も、それなりに山あり谷ありの結婚生活になるで しょうが、パートナーと力を合わせて乗り越える喜びは味わえそうです。 貯金力検定：雪だるま級 (20点)□□2005年1月21日受診 あなたは、まるで雪だるまのように、何をやっても増えていく貯金力の持ち主。 その調子で、どんどん貯め込みましょう。ただし、十分な「使いみち力」が ないと、かえって悲惨なことになりかねません。お気をつけください。 総合大人力判定 総合大人力：黒帯級 (106点) グッド・ジョブ！　あなたほどの強烈な大人力なら、たいていの試練は クリアできるはずです。しかし、くれぐれも油断は禁物。大人力の道に ゴールはありません。弱点分野を克服して師範級をめざしましょう。 ★あなたの武器になる大人力 　・上司力 ： あらゆるものをなぎ倒す無敵の上司力で、グイグイ部下を引っ張っていきましょう。 　・宴会力 ： 宴会を制するものは大人を制す。その旺盛なサービス精神を仕事でも役立てましょう。 　・貯金力 ： 「締まり屋さん」と陰口を叩かれたって何のその。最後に笑うのは、きっとあなたです。 ★もっと強化したい大人力 　・モテ力 ： トラブルなき人生が約束されています。でも、たまには異性と話すように心がけましょう。

2004年11月5日(金)

• 　3日の日記の追加：めしや氏も同じテストをやってみて、こんな結果だったそうだ。
  
  　ちなみに記憶の衰えの件。昔のことは割と覚えてるんだけど、最近のこと、とくに「ついさっきのこと」の覚えがずいぶん悪くなった感じがするのよねぇ。それってまんま、年寄りじゃん！
  
  　もしかしたら脳味噌が減ってきてるのかも。こんど脳ドックに入って調べてもらおう。
  

2004年11月3日(水)

• 　テスト・ザ・ネイション（全国一斉iQテスト）をやってみました。結果はこれ。（レーダーチャートに赤と青があるが、赤は間違いで青が正しい。）正答数60と年齢層（35〜54）から、iQは140と出ました。
  
  　分野別に結果を見ると、記憶だけダントツに悪い。最近、記憶力がずいぶん減退しているような気がするのは、気のせいではないのかもしれない・・・
  

2004年10月21日(木)

• 　ITmedia PCUPdateの記事（2004年10月19日 『あなたはどのくらい印象に残ってる？　PCのコマーシャル』 筆者:岩城俊介）
  
  

  というわけで、製品に関する特徴やキャッチコピーなど肝心な項目を覚えていたのは半々。意外に覚えていないんだなぁということを実感したのであった。読者の皆様はどうですか？

  
  　うーん、ざっと思い出した順に・・・
  
  

  思い出した順	覚えていた内容　のぶの場合
  1	ソニー：「♪ひーとびとーのHitBit」
  2	東芝：横山やすしのPASOPIA
  （以下略）

  
  　・・・なんじゃそりゃ＞わし
  

2004年10月20日(水)

• 　ITmedia PCUPdateの記事（2004年10月20日 『「ここはインテリアの見本市ですか？」本格的なリビングセットが目立つPCブース』 筆者:長浜和也）
  
  

  現在東芝はネガティブ方式燃料電池の開発も並行して進めている。「ノートPCの用途によってQOSMIOではアクティブ方式、dynabook SSではネガティブ方式と使い分ける」こともありえるそうだ。

  （本日現在のイメージ）
  　いやー長浜さん、久しぶりにやってくれました。「ネガティブ方式」って何ですか(笑)
  　だから、知らないことは無理して書かなければいいのに(^^;
  
  　ちなみに、東芝のプレスリリースにはこうあります。
  
  

  【参考】 （略） （２） 燃料電池の方式（アクティブ型／パッシブ型） 　燃料電池は、その構成から「アクティブ型」と「パッシブ型」に分類されます。 　アクティブ型は燃料となるメタノールや空気（酸素）をポンプやファンを使用して燃料電池に供給・循環させる方式で、構成が比較的複雑ですが大きな電力が得やすいという特長があります。これに対し、パッシブ型は燃料も空気も対流や濃度勾配等を利用して供給するため構成が単純で小型化に適していますが、得られる電力が小さく、希釈した燃料を用いるため燃料カートリッジが大きくなる課題がありました。 （後略）

2004年10月1日(金)

• 　Impress PC Watchの記事（2004年10月1日 『■多和田新也のニューアイテム診断室■　Shader Model 2.0完全対応の「3DMark05」』 筆者:多和田新也）
  
  

  Future Testは過去の3DMarkシリーズにも実装されてきたもので・・・

  （本日現在のイメージ）
  　細かいことで恐縮ですが、「Future Test」は「Feature Test」の誤り。この間違い、日本人にはよくあるのよねー。私も経験あります(笑)
  

2004年9月30日(木)

• 　少々古いが、琉球新報の記事（2004年9月22日 『安里川にジョーズ　５年前から上流にも出没　那覇市』）
  
  

  １８日夜、那覇市内の安里川でサメが捕獲された。場所は泊港から約７００メートル上流の地点、沖縄都市モノレール美栄橋駅近くで、体長約８０センチメートル、重さ約５キロで、人を襲うオオメジロザメの稚魚とみられる。サメを捕獲した那覇市壺屋の高嶺太一さん（２４）によると、これまで最低９匹のサメが泊港付近の安里川で生息しており、満潮時にはかなり上流まで上ってくるという。高嶺さんは「泊港で２メートルのサメを見たという人もいる。大きくなって危険な状態になる前に全部駆除したい」と話している。 　安里川はテレピアなどの淡水魚が生息しているが、５年ほど前からサメが現れるようになったという。オオメジロザメは成長すると体長３メートルまで大きくなり、雑食で人間を襲うこともある危険のあるサメ。特に濁った水域で襲われることが多いという。 （後略）

  （本日現在のイメージ）
  　同じ「雑食で人間を襲うこともある危険」のある海棲動物でも、シャチやイルカならば保護してもらえるのに、サメだと殺されてしまう。割り切れないものを感じる。
  

• 　次はITMediaの記事。まず2004年9月10日 『ITmedia PCUPdate：使い続けたPCはなぜ遅くなるのか。その解決法とは？』（筆者:星紀明）から。
  
  

  購入直後は確かに速くて快適だったマイPC。それが徐々に遅くなっていくように感じるのは、このスペックに慣れてしまったからなのか、単なる気のせいなのか。いや、気のせいなどではない。あなたのPCは着実にスローダウンし続けている。果たしてその理由とは？ （後略）

  （本日現在のイメージ）
  　導入はなかなか立派。でも読み進めると何か変だ。
  
  　この記事には、こうある。
  
  

  言うまでもなく、PCのハードウェアのスペックが自然とダウンすることなどない。原因は、Windowsの方にある。Windowsは、使い続けていくうちにだんだんと“ゴミ”がたまっていくからだ。それは、とうにアンインストールしたはずのアプリケーションの残滓だったり、何かの拍子で変更されてしまった不適切な設定情報だったりする。そういった“ゴミ”が蓄積されるにつれて、Windowsの動作を不安定にしたり、パフォーマンスの低下を招くのだ。

  （本日現在のイメージ）
  　なるほど、それはよく言われていることで、おそらくそうなのだろう。しかし・・・
  
  

  とりわけ影響が大きいのは、レジストリの肥大化だ。

  （本日現在のイメージ）
  　本当に？どうやってそれが判明したのか全く記述がないので、主張が正しいのかどうか判断のしようがない。もうこの時点で提灯の臭いがぷんぷんする。（主張の裏付けがない⇒誰かの主張の受け売り⇒元の「誰か」の製品・サービスの宣伝の可能性が高い。）
  
  

  では、なぜレジストリの肥大化がPCのパフォーマンスに悪影響を及ぼすのか。それは、Windowsの起動時はもとより、Windowsや各種アプリケーションの動作中も、ことあるごとにレジストリを参照しに行くからだ。大きなサイズのファイルを開くのに時間がかかるのと同じで、レジストリが大きくなればなるほど参照に時間がかかる。

  
  

  また、不必要な常駐プログラムやサービスも、PCの動作の足を引っ張る一因となる。 （中略） これらがメモリを余計に消費するために、PC全体のパフォーマンスを低下させてしまうわけだ。

  （本日現在のイメージ）
  　何とも頭の悪い理由付け。明らかに誤っている。この筆者ならば「ハードディスクの容量が大きくなればなるほどファイルアクセスが遅くなるから、なるべくハードディスクの容量は小さくしましょう」などと言いかねない。コンピュータの基礎知識が欠如していることは明らか。少し基礎を勉強したほうがよい。（長浜氏よりもずっとひどいぞ。ITMediaはそんなにカネがないのか？）
  
  　レジストリが大きくなっても参照にかかる時間はほとんど変わらないし、メモリを余計に消費してもそれがスラッシングを発生させるほどに酷くならない限り「メモリ消費（メモリ不足）による実行速度低下」は発生しない。こんなことは初歩中の初歩、常識中の常識である。
  
  　ただし、理由付けが誤っているのであって、指摘されている原因自体は間違っていない。レジストリの肥大化それ自体はパフォーマンスの低下をもたらすものではないが、レジストリエントリが増えるということはそれを参照するプログラムが増えているということであり、参照する回数が増えれば当然パフォーマンスは低下する。また不必要な常駐プログラムやサービスが増えるということはそれらがCPU時間を多少なりとも消費するということであり、これもやはりパフォーマンスの低下につながる。
  
  　察するにおそらく、この筆者はどこかに書いてあった「レジストリの肥大化・不必要な常駐プログラムやサービスがPCのパフォーマンスを低下させる」という文章を参照したのだろう。記事にする都合上理由を書く必要があり、しかし元の文章には理由が添えられていなかったため、何とか自分で理由らしきものを捻り出したのだろう。しかし、PCに関する基礎知識がなかったため、誤った理由を書いてしまったのだろう。
  
  　さて、この記事には続きがあり、ますます変なことが書いてある。
  

• 　2004年9月14日 『ITmedia PCUPdate：レジストリをカスタマイズして、PCの環境を復活させてみる』（筆者:星紀明）
  
  

  カーネルとは、OSの中核となるプログラムのこと。CPUの制御やメモリの管理など、PCの動作における根幹を担う部分だ。このカーネルの一部が仮想メモリ（ハードディスク）に置かれていると、PC全体のパフォーマンスを低下させる原因にもなる。PCに十分なメモリ（512Mバイト以上）が搭載されているなら、このカーネルを常にメモリ上に置くようにレジストリを変更すると、動作速度の向上が期待できる。

  （本日現在のイメージ）
  　非常識なアドバイス。確かに「カーネル」周辺の動作速度は向上する可能性がある。しかし、これによってカーネル周辺の動作速度が向上するならば、それは（このレジストリ変更を行わない場合は）カーネル周辺コードに対するスワップが発生していたということであり、言い換えればカーネルとアプリケーションが残り少ないメモリを取り合っているということを意味する。この状況でカーネル周辺コードのスワップを禁止すれば、その分だけアプリケーションが使用できるメモリが減少し、アプリケーションに由来するスワップが増加する。そうなれば、アプリケーションの実行速度はさらに低下する。
  
  　このアドバイスによって、見かけ上のレスポンス（マウスカーソルの動きや画面の表示等）は改善される可能性が充分ある。ユーザインターフェースのレスポンスが改善されれば、体感的には全体的にパフォーマンスが改善したように感じるものなので、その意味では意味がある（つまり「改善は気のせい」ということ）。しかし、本来問題にすべきパフォーマンスはアプリケーションの動作速度であり、これは改善されない。
  
  　スワップはカーネルが「必要」とみなす場合にのみ行われるもので、一般にユーザが手動でスワップのタイミングを調整するよりカーネルに任せて自動で行わせるほうが良い結果が出るものである。これも常識。特に、カーネル周辺コードにはめったに動作しないようなコードもあり、それも含めてスワップ禁止にするなど「調整」と呼ぶにも値しない非常識な行為と言わざるを得ない。
  
  

  アプリケーションの終了後もDLLファイルがメモリ上に残ることがあり、利用できるメモリ領域を圧迫してしまうことがある。アプリケーション終了時にメモリ上からDLLファイルが削除されるように設定しておけば、メモリの空き領域が増えるので、動作速度の向上につながる。

  （本日現在のイメージ）
  　またしても非常識なアドバイス。だいたい、解説の文章自体が誤解を招きかねないものだ。筆者自身が意味を理解していないのだろう。解説の文章では、ここで紹介されているレジストリ設定を行わないと「DLLファイルがメモリ上に『いつまでも』残る」かのように取れるが、実際は「DLLファイルがメモリ上に『一定時間』残る」のである。そして、標準設定がそのようになっている理由はとりもなおさずパフォーマンスを向上させるためであって、その設定をあえて変更するのであれば得失を検討してから行うのが筋である。しかし、その「得失」が一切解説されていない。筆者は得失どころかレジストリ設定の意味を理解していないのだから、解説されていないのも無理はない。そもそも、このレジストリ設定はWindows 2000以降では有効でないことがMicrosoftのWebサイトに掲示されている。
  

• 　さらに次の記事（2004年9月17日 『ITmedia PCUPdate：DiskX ToolsでPC環境を快適に保つ：レジストリのお掃除編』 筆者:星紀明）
  
  

  筆者のPCにおける結果は「51％」。かろうじて「普通」の範囲だが、やはりPCの中には不要なファイルやレジストリ情報が相当溜まっているようだ

  （本日現在のイメージ）
  

  予想通り、いやそれ以上にマイPCが汚れていることに愕然としたが、診断結果のアドバイスによれば、「ファイルクリーナー」の「オートクリーン」を実行すれば、クリーン度が11％改善されるという。「ファイルクリーナー」とは、不要なファイルを多角的に検出して削除するという機能だ。

  （本日現在のイメージ）
  　「クリーン度51%」で「予想...以上にマイPCが汚れていることに愕然とした」そうだが、どうにも不思議な人だ。51%は愕然とする数字なのか。因果関係が第三者には全く分からない。紀行文じゃあるまいし、もう少し客観性のある記事は書けないものか。
  
  

  「ファイルクリーナー」と「レジストリクリーナー」を実行した後、再びクリーン度をチェックしてみたところ、クリーン度が15％も改善されて「66％」まで向上した。

  （本日現在のイメージ）
  　「クリーン度が15％も改善」・・・また紀行文書体。15%改善とは具体的にどのような効果のある改善なのかさっぱり分からない。その改善にはどんな価値があるんでしょうか。全く分かりません。もう少し上手に宣伝しないとスポンサーからクレームが来るんじゃないの？
  

• 　最後の記事（2004年9月22日 『ITmedia PCUPdate：DiskX ToolsでPC環境を快適に保つ：システム周りのお掃除編』 筆者:星紀明）
  
  

  「DiskX Tools Ver.10」（以下、DiskX Tools）で不要ファイルや不要レジストリをクリーンアップしたところ、「パフォーマンスチェッカー」のスコアも同時に74ポイントほどアップしていた。やはり筆者のPCでも、不要ファイルの蓄積やレジストリの肥大化がパフォーマンスを悪化させる一因になっていたらしい。

  （本日現在のイメージ）
  　いつまでも繰り返される紀行文書体。具体性全くなし。
  
  

  とはいえ、体感的には「起動が少し速くなったかな？」という程度で、まだ購入直後のPCのパフォーマンスには及ばないという印象だ。

  （本日現在のイメージ）
  　体感できたのは素晴らしいことです。しかし記事を読んでいる人は記事から体感することができないので、具体的な数字を挙げるべきでしょう。もちろん、どこかの不思議ソフトが表示する〇〇度なんて数字は「具体的な数字」のうちに入りません。
  
  

  DiskX Toolsでクリーンアップとチューンアップを行った筆者のPCは、最終的なパフォーマンススコアが3172ポイントに達した。購入当時の快適さを取り戻したばかりか、それを上回る成果をあげたことに、筆者はすっかりこのソフトが気に入ってしまったほど。何よりも、自分でレジストリの操作やサービスの停止といったリスクを負うことなく、安全・確実・簡単にパフォーマンスを向上できる点が優れている。

  （本日現在のイメージ）
  　ほー、それは素晴らしい。で、元はどの程度のパフォーマンスだったのが、処理後はどの程度のパフォーマンスになったんですか？3172ポイントに達したのは良いことなんですか悪いことなんですか？まさか、最初に2466ポイントだったのが3172ポイントになったからパフォーマンスは向上している、と判断したのではないでしょうね？もちろんそうではないのでしょうが、ではどのような根拠で判断できたのか、読者にはさっぱり伝わってこない。
  
  

  自分のPC環境は自分で守りたいもの。アンチウィルスソフトは一般ユーザーの間でも標準的な存在になったが、これからはPCのメンテナンス用にクリーナーソフトも一家に1本備えておきたいものだ。

  （本日現在のイメージ）
  　この記事の結びがこれ。結局、筆者の主観的な記述に終始し、どれだけの改善があったのか具体的な根拠の提示は一切なし。読者には、このソフトが最初に2466ポイントと表示し最後には3172ポイントと表示したことと、筆者がこのソフトを誉めていること以外には何の情報も伝わっていない。
  
  　ここまでひどい、読者の役に立たない提灯記事は見たことがない。
  

2004年9月6日(月)

• 　PC周辺機器を作っているロジクールという会社がある。当然マウスも作っていて、ロジクールはハイエンドのマウスで結構有名である。
  
  　そのロジクールが新しい光学式マウスMX-1000を発表した。何でも、「MX-1000に搭載されたMXレーザーエンジンは、一秒間に最大5.8メガピクセル/秒のデータを処理する能力をもち、LED使用のオプティカルマウスに比べ20倍のセンサー感度を得ることができます。」だそうな。
  
  　この売り文句は充分納得できるものがある。というよりも、何でそんな簡単なことを今まで他のメーカーはやっていなかったのかという感じだ。だって、表面状態を読み取るセンサーだったらレーザーのコヒーレント光を使うほうがLEDを使うよりずっと高分解能に決まっているのだから。こんなの工学部の学生なら100人中120人くらい知ってるはず。
  
  　そう、センサーの光源にレーザーを使う利点は高分解能にある。例え赤色レーザーよりずっと波長の短い緑色LEDを使ったとしても、分解能では全く足元にも及ばない。だから、LEDのほうがレーザーよりも何倍も安いにもかかわらず、ミクロン単位の極小ピットを読み取る必要のあるCDやDVDの光源にはレーザーを使う。
  
  　と、物理の初歩を書いたところで、Web記事の紹介を・・・
  

• 　Impress PC Watchの記事（2004年9月2日 『■元麻布春男の週刊PCホットライン■　ロジクールのレーザーマウス「MX1000」を試す〜高解像度画面に向いたタイトな操作感』 筆者:元麻布春男）
  
  

  光源にレーザーを採用したことによる最大の利点はここにある。一般的な光学式マウスに使われている赤色LEDより波長の短いレーザー光は、赤色LEDの光では識別できなかったような、素材表面の違いを浮き彫りにする。たとえば、カラーインクジェットプリンタに使う写真印刷用の光沢紙の上では、これまでの光学式マウスはうまく動かない(手元にある人はぜひ試してみてほしい)。

  （本日現在のイメージ）
  　おーー、緑色レーザーとか、もっと新しい青色レーザーとか使ったんかな。緑だったらDVDプレーヤーで価格もこなれてきたけど、青だったらかなりの冒険だな・・・と思っていたのだが、読み進むと変なことが書いてある。
  
  

  さて、実際のMX1000だが、ちょっと意外なのはセンサーからはそれらしい光が見えないこと。「レーザー」というからには、ピカーとした光が見えそうなものだが、可視光線外の波長を使っているらしい。安全基準はLED光源を使ったオプティカルマウスと同じだ。

  （本日現在のイメージ）
  　？？？？
  
  　さっき「一般的な光学式マウスに使われている赤色LEDより波長の短いレーザー光」って書いてたのに、今度は一転して「可視光線外の波長」？まさか紫外線レーザーのわけはないから（そうだったらものすごい快挙だ！）、それなら赤外線レーザーだよね。でも赤外線レーザーだったら赤色より波長が長いんですけど。元麻布さんともあろう方が・・・
  

• 　次はITMediaの記事（2004年9月2日 『ITmedia PCUPdate：手のひらにレーザー光線を』 筆者:本田雅一）
  
  

  では、LEDの代わりに832〜852ナノメートルという短波長のレーザー光を用いた新センサーの「MX-Laserセンサー」は、従来の「MXエンジン」とどのように違うのだろうか？

  （本日現在のイメージ）
  　むむむ・・・またちょっと嫌な臭いがするぞ。「832〜852ナノメートルという短波長」って、その波長は明らかに赤外領域。それが短波長ということは、従来のLED式ではさらに長波長の赤外線LEDを使ってたのか。それだとだいぶ（従来製品は）解像度が不足しそうだけど。
  
  　さらに読み進んでみる。
  
  

  ならば何も変わらないのでは？　いや、MX-Laserセンサーがその威力を発揮するのは、滑らかな表面でマウスを利用するときだ。赤色のLED光よりもはるかに波長が短いレーザー光を用いることで、表面の凹凸をより鮮明に浮き上がらせる。

  （本日現在のイメージ）
  　ぐはっ（吐血）。「赤色のLED光よりもはるかに波長が短いレーザー光」が、なんで赤色より波長の長い赤外線なんだよ。
  
  　それにしても、物理の苦手な長浜氏ならともかく、本田氏までこんな間違いをするとは・・・
  
  　だいたい、ニュースリリースにも製品情報にも「従来より短波長」なんてどこにも書いてないんだよね。「高解像度」から反射的に「短波長」を連想したのかな。それとも、ロジクールが発表会でもやって、その席で発表内容が間違ってたのかな。こっちの記事にはニュースリリースに書いてない具体的な波長が書いてあるし、大御所の2人がそろって同じ間違いをしているところを見ると、どうもニュースリリースより詳しい発表があって、その内容が間違っていたというのが真相かとも思えるのだが。
  

2004年9月2日(木)

• 　Windows XP SP2のNX（DEP）機能のテストをしたいのだが、テスト可能な実機がない。誰か、Athlon64か新Pentium4/Xeon搭載マシン持ってる人おらんー？(笑)
  
  　ハードウェアDEP機能が有効のマシン持ってる人がいたら、次のプログラムがDEPで強制終了させられるかどうか教えてください。
  nxtest1.exe (448 bytes)
  nxtest2.exe (448 bytes)
  nxtest3.exe (448 bytes)
  nxtest4.exe (560 bytes)
  （nxtest1はウィルススキャナが警告を発することが分かったので、公開を停止しました。
  なおウィルスの混入はありませんので、既に実行してしまった人はご心配なく。）
  
  　ちなみに、強制終了させられない場合（あるいはDEP機能がない場合）、nxtest1〜nxtest3は何も表示せずすぐに終了、nxtest4は一瞬コマンドプロンプトのウィンドウを出した後ですぐに終了します。
  
  

2004年9月1日(水)

• 　昨日書いた「NTFSのファイルやフォルダのセキュリティ設定を変更する簡単な方法」だが、意外と簡単に変更できることが分かった。もっとも、簡単でも面倒。あーやだやだ(^^;
  

• 　でもって次はプロセスのhModuleを取得する方法だが、かなりしつこく調べたのだがToolHelp32を使うかPSAPIを使うしか方法はなさそうだ。うーむ、しょうがないな。
  

2004年8月31日(火)

• 　今日はアンチパターン − ソフトウェア危篤患者の救出（Brown, Malveau, McCormick, Mowbray共著・岩谷宏訳／ソフトバンク）を読み終えた。割と面白かった。デザインパターンに関する知識があったほうがより良いが、なくても充分楽しめる。
  

• 　現在悩んでいる事が2つ
  
  • NTFSのファイルやフォルダのセキュリティ設定を変更する簡単な方法はないものだろうか。ACL関係のAPIを使えばできることは分かっているんだが、APIリファレンスには一般論しか書いてなくて「これをやりたい場合はこうせよ」という例がほとんどないのが困り者。うーん、どこかに良いサンプル落ちてないかなー。
  • ToolHelp32を使わずにプロセスのhModuleを取得する、簡単な方法はないだろうか。toolhelp32は全プロセスを舐めるから遅くて使いたくないのよねー。

2004年8月26日(木)

• 　『超』をいくつも付けたいほどおバカなプログラミングのページを発見。ここ。いやー、イカす(笑)
  
  　ちょうど今日、仕事のプログラムでアセンブラが必要になったところだった。Win32でアセンブラを使いたがる人間が他にもちゃんといると分かって嬉しい。
  

2004年8月20日(金)

• 　今週は月曜からずっと10時−6時で通勤だったので、通勤時間を利用してようやく平行植物（レオ・レオーニ著・宮本淳訳／ちくま文庫）を読み終えた。感想は・・・全くワケが分からん(^^;
  
  　強いて言えば鼻行類の同類なのだが、絵本作家『レオ・レオーニ』の絵本作品とはずいぶん毛色が違うように感じる。
  

2004年8月7日(土)

• 　1ヶ月ほど前になるが、扇風機を購入した。3000円以上出すつもりがなかったので、最低価格帯のものから選択したのだが、ちょっと驚いた。
  
  　まず、標準的な左右の首振りに加えて、上下にも首を振る。初めて見た(笑)（食堂とかにある、首を丸くタイプではなくて、左右と上下が選択できる。）
  
  　そして、もっと驚いたのが、この左右・上下の首振りの有無をリモコンで選択できること。
  
  　首振りの有無を電気的に選択できるということは、首振り用に専用のモータを仕込んであるに違いないということ（しかも上下用と左右用に1個ずつ）。ちょっと高めの製品ならともかく、最低価格帯の製品でそんなコストアップになりそうなことを容認するとは・・・
  

• 　読みかけの本を読みきらないうちに、また別の本を読み始めてしまった・・・で、2冊読み終えた。
  
  
  • デスマーチよ！さようなら！（深沢隆司著／技術評論社）
    
    　具体例は独り善がりなものが多いが、提案している内容自体はうなづけるものがある。ソフト開発者で、同業者の様子をちょっと見てみたくて、若干の時間が取れる人（電車通勤の人とか）であれば、読んでみてもいいかも。
    
    
  • Windows 95内部解析（アンドリュー・シュルマン著・太田純監訳／ソフトバンク）
    
    　「なんで今頃（今更）こんなものを読んでるの？」と言われそうだが、たまたま本棚の上のほうを見たら目に入ったので・・・こんな本を未読のまま残していたとは不覚。かなり面白い。ただし、Undocumented DOSとかUndocumented WindowsとかWindows Internalsとかを愛読していた人でないと理解は難しいと思う。また、その筋では割と有名人の太田純氏を監訳に据えた割に、翻訳はデタラメの極致。いにしえのIBM文章のほうが10倍まし。太田さん、名前だけ貸して翻訳した文章読まなかったでしょ？
    
  
  　で、いまはまたInside Microsoft Windows 2000 Third Editionの続きを読んでいるのであった。しかし、もうすぐ4th Editionが出るらしい・・・(涙)
  

2004年6月9日(水)

• 　久しぶりにITmediaの星、長浜和也氏ネタだ。
  

• 　長浜和也氏はここのところ間違いを起こしそうにないものの記事ばかり書いていたが、COMPUTEX TAIPEI 2004取材絡みで（よせばいいのに）キワモノ記事を書いたらまたやってくれた。
  　ITMediaの記事（2004年6月8日 『TAIPEIではコンビニでもキワモノに遭遇した』 筆者:長浜和也）
  
  

  おでんで人気のメニューは殻ごと煮付けた「味付けゆで卵」とこの「猪血漿」 なかなかグロいネーミングだが、もち米に豚のレバーを絡めて煮たもので台湾の屋台ではよくあるポピュラーな食べ物。

  （本日現在のイメージ）
  　まず、この食べ物の名前は「猪血漿」じゃなくて「猪血糕」。それに、使っているのは豚のレバーじゃなくて豚の血。（なんでレバーで「血」なんだか。レバーだったら「肝」だろうに。）
  

2004年6月7日(月)

• 　数少ない（であろう）読者から「更新せんの？」と聞かれてしまった。そういえば、前回更新してからもう2ヶ月以上になるんだなぁ・・・ネタはいっぱいあったはずなんだが、すぐには思い出せないので、とりあえず最近読んだ本のタイトルでも書くことにしよう。
  

• 　以前読んで、最近また読み返した本：
  
  • 「ご冗談でしょう、ファインマンさん」I（ファインマン著・大貫昌子訳／岩波書店）
  • 「ご冗談でしょう、ファインマンさん」II（ファインマン著・大貫昌子訳／岩波書店）
  • 「困ります、ファインマンさん」（ファインマン著・大貫昌子訳／岩波書店）
  • シュテュンプケ氏の鼻行類（カール・Ｄ．Ｓ．ゲーステ著・今泉みね子訳／思索社）
  • コンピュータの業界のオキテ!!（藤原博文著／技術評論社）
  • 作品としてのプログラム（黒川利明著／岩波書店）
  • 日本語をさかのぼる（大野晋著／岩波新書）

• 　ここ半年に読んだ本：
  
  • 日本語の教室（大野晋著／岩波新書）
  • 日本語の起源（大野晋著／岩波新書）
  • 対談 日本語を考える（大野晋編／中公文庫）
  • 日本語はどこからきたのか（大野晋著／中公文庫）
  • 大野晋の日本語相談（大野晋著／朝日文芸文庫）
  • 日本語練習帳（大野晋著／岩波新書）
  • 日本語（新版）上（金田一春彦著／岩波新書）
  • 日本語（新版）下（金田一春彦著／岩波新書）
  • 日本語の文法を考える（大野晋著／岩波新書）
  • 日本語の起源（大野晋著／岩波新書）
  • 日本語の形成（大野晋著／岩波書店）
  • 口語訳古事記（三浦佑之訳・注釈／文芸春秋）
  • 鼻行類（ハラルト・シュテュンプケ著・日高敏隆・羽田節子訳／平凡社）
  • 数学21世紀の7大難問（中村亨著／講談社）
  • カラス なぜ遊ぶ（杉田昭栄著／集英社新書）
  • ことばの道草（岩波書店辞典編集部編／岩波新書）

• 　読みかけの本たち：
  
  • Inside Microsoft Windows 2000 Third Edition（David A. Solomon, Mark E. Russinovich著／Microsoft Press）
  • Programming the Microsoft Windows Driver Model（Walter Oney著／Microsoft Press）
    （いま調べたら第2版が出てた・・・ガーン）
  • 憂鬱なプログラマのためのオブジェクト指向開発講座（Tucker!著／翔泳社）
  • 7日間でマスターするレイアウト基礎講座（視覚デザイン研究所編／視覚デザイン研究所）
  • 平行植物（レオ・レオーニ著・宮本淳訳／ちくま文庫）

• 　立ち読み(笑)：
  
  • 廃用身（久坂部羊著／幻冬舎）

• 　この「廃用身」、後半の1/3ほどを立ち読みしたんだが、めちゃめちゃリアルでエグい。介護とか老人問題とかに真面目に関わりたい人にはお薦め。というか、このエグさが耐えられなければ関わるべきではない。
  

2004年3月26日(金)

• 　最近その数が急に増えてきたLED使用の信号機だが、点灯の際に違和感を感じたことはないだろうか。いや、あのギラつくような色のことではない（これは色の純度が高いせいである）。LED式の信号機が点灯時に一瞬強く光るように見える現象のことである。
  
  　最初は気のせいかと思っていたが、多くのLED式信号機でこの現象が見られるので何らかの理由があるのだろう。そう思って考えてみると、1つその原因に心当たりがある。
  
  　旧来の電球式信号機では当然、電球を使用している。電球は、電流による加熱で白熱したフィラメントを光源としている。加熱を利用する性質上、通電してもすぐには明るくならず、最大光量に到達するまで時間がかかる。
  
  　ところが、この「最大光量に到達するまで時間がかかる」という性質は、信号機のように瞬時に点滅してほしい用途では不都合である。そのため、電球式信号機では最大光量に到達するまでの時間を短くするような仕組みが内蔵されているのではないかと想像できる。
  
  　最大光量に到達するまでの時間を短くする方法として、点灯直後に流す電流量を一時的に増やし、光量の立ち上がりを急峻にするというものがある。旧来の電球式信号機では、この方法を取っているのではないかと思われるのである。
  
  　この仕組みが信号機自体に内蔵されているとすると、電球に流れる電流量は点灯直後に一時的に多くなる。そのような電球用の仕組みを持った信号機本体にLED式電球を使用すると、LED式電球でも同じように点灯直後に一時的に多い電流量となるはずである。
  
  　ところがLEDは通電後すぐに最大光量に到達し、電流量を増やせばその分だけ光量も増えるので、この仕組みをもつ信号機をそのまま使用すると、点灯直後に一瞬光量が増えることになる。
  
  　本当にこのような理由なのかどうかは分からないが、電球の性質と信号機の設置コストを考えると、そのような仕組みが旧来の信号機に内蔵されており、LED式になってもそのまま使用されていると考えても不自然ではない。
  

2004年3月25日(木)

• 　どうもVirtual PCの動きが鈍いと思ったら、なんと、使っているHDDの一部の転送モードがDMAではなくPIOになっていた。よくある現象なのでOSインストール時には必ずチェックするようにしていたのだが、今回は見逃してしまった。
  
  　というよりも、OS（Windows 2000）インストール後にちゃんとチェックして、PIOモードが指定されていたのでDMAモードに指定を変更しておいたのだが、それにもかかわらずPIOモードのままになっていたのだ。これまでHDDではモードを指定してそのように変更されなかった経験がなかったので、気付かなかったのだ。（CD/DVDドライブではDMAモードを指定してもPIOモードのままになるものが結構あるので、割と気にして見直すのだが。）
  
  　全く同じ2台のHDD（Maxtor DiamondMax 80, モデル番号98196H8）を同じIDEチャネルのマスターとスレーブに接続しているのだが、そのうちスレーブ側だけ、どうやってもPIOモードのまま変わってくれなかった。マスター側はちゃんと、DMAモードを指定すればDMAモードに、PIOモードを指定すればPIOモードになるのだが。全く訳がわからない。
  
  　このスレーブHDDをマスターに変更すると、今度はちゃんとDMAモードに変わった。それじゃもしかして・・・と思って、元々マスターだったHDDをスレーブに変更したら、こちらはスレーブでもちゃんとDMAモードになってくれた。
  
  　結局、元の2台のHDDのマスターとスレーブを入れ替えることで両方ともDMAモードになってくれたのだが、やっぱり訳がわからないままである。もしかして、元々スレーブに接続していたHDDは故障しているのだろうか・・・（最もあり得る原因は、HDD内のフラッシュROMに格納されたパラメータが何らかの原因で書き換わって、UDMAが無効になってしまったというものであろうが。）
  

2004年3月22日(月)

• 　昨日に引き続き、今日はWindows 2000, XPの無人インストールテスト。
  
  　Windows 2000, XPにも無人インストール用の応答ファイルを作成するプログラムがあるのだが、これ、各コンポーネントのインストールする・しないを選択する機能がない。それだけでなく、インストール先のパーティションの指定等、プログラムで設定できないパラメータが山ほどある。全部手作業で入れなきゃいけないのか・・・
  

• 　F&F 2004年3月21日の日記のネタ。（2004年3月中はここ、それ以降はここ）
  
  　血液型と性格の関係について、概ね生物学的知識のある人は「関係ない」、そうでない人は「関係ある」「関係ある、ような気がする」と考えるようだが、私は生物学科卒としては異端的に「関係ある可能性も否定できない」派である。
  
  　根拠は非常に簡単。まず、人間の血液型を決定する因子（A型・B型・O型）の遺伝子座は特定されている。これは広く知られた事実であり、この点について異論を差し挟む人はいない。
  
  　また、ここ20年ほどの遺伝学の研究結果から、遺伝子上の僅かな変異によって性格の違いが発現する例が多く知られている。これも事実。
  
  　そして、相同染色体の交差組み替えという現象がありますが、遺伝学の常識として、遺伝子座の近接した遺伝子ほど交差組み替えによって入れ替わる確率が低いことが知られている。事実。
  
  　この3点の事実を組み合わせると、こういうことが言える。
  
  

  (1) 血液型を決定する因子（A型・B型・O型）の遺伝子座に非常に近い位置に、性格の違いを生じさせる遺伝子があると仮定する。 (2) この遺伝子は血液型を決定する因子と非常に近い位置にあるので、組み替えによって血液型決定因子と離れるような入れ替えが発生する可能性は非常に低い。 (3) ゆえに、(1)で仮定するような遺伝子が存在する場合、血液型決定因子に対応して、高い確率で特定の性格が発現する。 (4) (3)で言う、血液型決定因子と、これに隣接する遺伝子座にある性格影響遺伝子による性格の発現の関連は、遺伝子座が近いほど高くなる。

  
  　言い換えると、血液型を決定する因子がある遺伝子座の近くに、性格に影響を与えるような遺伝子があるとするならば、遺伝子学的な見地から言えば、特定の血液型と性格に有為な関係が生じる可能性がある、ということである。
  
  　そのような遺伝子が存在しないと言い切るのは現時点では不可能なので、遺伝学的には「血液型と性格に関係がある可能性は否定できない」というのが正しく、「関係ない」と言い切るのは非科学的な誤りであろう。
  

2004年3月21日(日)

• 　Windows 98, 98SE, Meの無人インストールをテストしようとしたのだが、その前に大きな問題が・・・どうやってブートしたらいいんだ？
  
  　手元にはWindows 95, 98（アップグレード版）, 98SE, MeのCD-ROMが全部あるが、どれもBootable CD-ROMではないので、MS-DOS（かWindows 9xのMS-DOS部分）でブートする必要がある。幸い手元にはWindows 95起動ディスクもあるので、これで起動すれば万事OK・・・と思いきや、これにはなぜかCD-ROM用ドライバが入っていない！（どうやらFD版のWindows 95の起動ディスクだけ置いといたようだ。）
  
  　いまさらDOSのCD-ROM用ドライバを探すのも面倒なので、CD-ROMのコピーをDドライブに置き、FD起動後HDDからインストールすることにした。クリーンインストールしたかったのでCドライブはフォーマットしたてを用意。これで通常インストールはできるようになった。
  

• 　ところが、無人インストールを行おうとしたところまた1つ問題が発生。Windows 98はアップグレード版なので、インストールの途中で旧バージョンのWindowsの存在チェック（「アップグレード互換チェック」）を行う。その際、Windows 95のすべてのcabファイルとsetup.exeを同一ディレクトリに置き、そのディレクトリを指示してやればチェックは通るのだが、自動的にチェックを通すにはどこにディレクトリを作ればよいのかが分からない。
  
  　かなり試行錯誤を繰り返したのだが、どうやってもうまくいかないので諦めた・・・
  

• 　さて「アップグレード互換チェック」は諦めるとして、その他は自動化できた。が、これにも問題が全くなかったわけではない。
  
  　まず、無人インストールのための応答ファイルはリソースキットに入っているバッチユーティリティを使用するのだが、98SEとMeにはリソースキット自体が存在しない。しょうがないので、98用のバッチユーティリティを使用することにした。
  
  　そうしてできあがった応答ファイルを使用すると、98と98SEは（前述のチェックを除いては）何の問題もなくインストールを完了することができた。ところが、Meでは指定の一部が有効にならず、インストールしないよう指定したプログラムがインストールされていたり、起動しないよう指定したプログラムが起動したり。
  
  　まぁいちばんの目標であったインストールの自動化は達成できているので、大きな問題ではないのだが。
  

2004年3月20日(土)

• 　今日の覚書。
  

• 　ABIT KT7A-RAID（AthlonXPに多分対応していないくらい古いAthlonマザーボード）のBIOS設定でACPI S3(STR)がうまく動かないので調べていたら、Windows 2000でACPIを使うとPCIのIRQが全部同じ（共有）に設定されてパフォーマンスが低下するので、消費電力・サスペンド周りに重点を置くノートパソコン等でなければACPIを使用せずAPMを使用する設定にしたほうが良いという記述を発見した。
  
  　なるほどなるほど、そういうことなら確かにそうだなーと思って、そこに書いてあるようにACPI-PCから標準PCにHALを入れ替えたところ、確かにACPIは使わなくなったが、APMも使ってくれない。どうやってもダメ。
  
  　Windows 2000のAPMサポートに関する文書を見てみると、APM BIOSを認識しているかどうかはレジストリで分かるらしい。調べると、確かにAPM BIOSは認識されている。また別の文書ではAPM の状態を確認するapmstat.exeというツールがあるとか。さっそく調べてみると「ACPI BIOSが存在するのでAPMは使わない」とかのたまう。
  
  　再度BIOS設定を見てみると、確かにAPMを使用する設定にはなっているのだが、ACPIを使わない設定にもなっていない。というより、ACPIを無効にする設定自体が存在しない。
  
  　こりゃ困ったなーと思いつつ、何度となく繰り返しているWindows 2000のブートを再度行っていたら、ふと気付いた。HALをACPI-PCから標準PCに入れ替えたのに、まだacpi.sysを読み込んでるじゃないか。（注：普通のブート画面を見ていると分かりません。boot.iniのエントリに/sosを書き加えると分かります。開発者は常用するエントリに必ずこのスイッチを追加するべきです。私はいつも、OSインストール後すぐに追加しています。）
  
  　ブート時に読み込まれるということは、ドライバのスタートアップ設定が「ブート」（レジストリで言えばStart=0）になっているはず。調べてみると、確かにそうなっていました。さっそくこれを「要求」（レジストリで言えばStart=3、サービスのスタートアップ設定で言えば「手動」）に変更して再起動したところ、無事APMが有効になったのでした。
  
  　ちなみに、レジストリを使わずにドライバのスタートアップ設定を変更する場合は、デバイスマネージャを表示して「表示(V)→非表示のデバイスの表示(W)」をチェックし、「プラグアンドプレイではないドライバ」を開きます。
  

• 　・・・と書いてはみたものの、いまどきならWindows XPにすればよいだけの話なので、誰にも必要とされない知識であろう・・・
  

2004年3月10日(水)

• 　鳥インフルエンザ発生地域からの鶏・鶏肉・鶏卵の出荷が停止されているが、なぜだろう。「鶏肉・鶏卵から人に感染する心配がないから食べてくれ」と主張するのであれば、その「感染の心配のない」鶏肉や鶏卵は出荷・販売できるようにしたらよいのではないだろうか。
  
  　一方では神経質にすべて出荷を止めていながら他方では「大丈夫」と言われても、それでは納得できなくて当然だ。一般人は流通できないようなシロモノを「安全」とは呼ばない。「安全」なものとは普通に流通していて普通に購入できるものを言うのだ。
  

2004年3月9日(火)

• 　今日、MSDN Operating System Subscriptionのライセンス登録完了の連絡があった。予定納品日は3月18日だったのに、なんでこんなに早く・・・
  

2004年3月8日(月)

• 　Impress PC Watchの記事（2004年3月8日 『日本HP、コンシューマPC市場再参入の勝算』 筆者:大河原克行）
  
  　「惨々たる」（さんさんたる）という言葉が2回出てくるが、こんな言葉あるの？「惨憺たる」（さんたんたる）の間違いじゃない？(^^;
  

2004年3月7日(日)

• 　最近、C++のSTLだのBoostだののドキュメントを読み始めている。特にBoostのmplライブラリが面白い。
  　しかし、仕事でこんなの使ったら他者／他社でメンテナンスできなくなるだろうな(^^;
  

2004年3月3日(水)

• 　雛祭り。男兄弟だったから全く縁のない日。
  
  　雛祭りの歌の歌詞に「お内裏様とお雛様」とある。ずーっとこれで一対の人形だと思い込んでいたが、調べてみると「内裏様」とは「内裏雛」のことで、これだけで男女一対の雛人形のことを指す。「お雛様」はお姫様の意だから、そうすると、本来は「お内裏様」が両親で「お雛様」が娘？
  
  　まぁそんなことはともかく。
  

• 　Virtual PCを買おうかと思っていたが、どうせOSも何種類か必要で、まだ新しいのは買ってない。必要なものの値段を全部合計するとMSDN Operating System Subscriptionに入るのと同じくらいかかるから、MSDN Operating System Subscriptionに入ってしまうことにした。
  
  　今日注文したのだが、ライセンスが到着するまで2週間！さらにライセンス到着から品物が到着するまで1週間！何と3週間がかりの遠大な計画になってしまった。MSにしては珍しい、ゆったりとしたペースですなぁ。
  

2004年2月22日(日)

• 　今日はネコの日。
  

• 　いまやっている仕事で、Windowsの何種類かのOS、DirectXのいくつかのバージョンの組み合わせで動作テストをする必要に迫られた。が、DirectXはいったん新しいものをインストールすると以前のバージョンに戻せないので、動作テストのたびにOSを再インストールしなければならない。
  
  　それではたまらんのでVMwareかVirtual PCのお世話になろうと思ったのだが、動作テストの中でUSBカメラを使う必要があり、VMwareもVirtual PCもUSBカメラが使うIsochronous TransferというUSB転送モードをサポートしていない。
  
  　くそー、どないやねん！
  

• 　というわけで、ホストOSに接続したUSBカメラをゲストOSから使うべくUSB over ほげほげ（ほげほげは適当なインターフェース）を作ってみることにした。
  
  　・・・が、調査したところ1日で挫折(笑)
  

• 　ドライバインターフェースがWindows 2000とWindows XPでずいぶん変わってるんだよなー。両対応でないと困るし、それぞれ個別対応するのはイヤだし。
  　USB over ほげほげは諦めて、DirectShowカメラ over ほげほげに転向するか・・・
  

2004年2月17日(火)

• 　今日の覚書。
  
  　CreateDIBSectionやGetDIBitsに与える「BITMAPINFO構造体へのポインタ」パラメータに素直にBIRMAPINFOを与えるとWindows NT系でしか動かない。
  
  　Windows 95系では、BIRMAPINFOを与えるとAPIがfailする。Windows 95系で動かすにはBITMAPV4HEADERやBITMAPV5HEADERを与える必要がある。
  
  　・・・くそーはまっちまった。
  

2004年1月27日(火)

• 　ZDNet改めITMediaの記事（2004年1月27日 『Let'snoteが目指すのは「単純な最軽量」ではなく「バランスの取れた携帯性」』 筆者:長浜和也）
  
  　この人の記事の間違いは、もう指摘するのも飽きた。この人の記事は3回くらい校正しなきゃダメです＞編集部の人
  

2004年1月11日(日)

• 　またしても月記のペースである。
  

• 　sRGB→L*a*b*変換のプログラムをチューンアップするために、久しぶりにアセンブラを使ってみた。と言ってもC++ソースの中にインラインアセンブラだけど。
  
  　まず手始めにsRGB→L*のみ変換。元々の公式そのままdouble演算を使ったりして遅いバージョンで、1回の変換（320x240ピクセル）が約45ms。これに対してテーブル引き＋アセンブラ化で約5ms。9倍のスピードアップ。ループアンローリングでさらにもう2割ほどスピードアップ。
  
  　このプログラム、最初はちょっと長めだったんだが、どんどん最適化していくうちにループ内の命令数が15個まで減ってしまった。
  
  　面白いのは、全く同じ命令を使っていても順番を変えると速度がけっこう変わること。メモリアクセスのレイテンシによる影響がこんなに大きいとは＆out-of-orderダイナミック実行でこんなに速くなっていたとは。
  
  　それから、32ビット命令を16ビットや8ビットにすると、とたんに大きく遅くなる。いちばんビット数の大きい命令がいちばん速いというのがちょっと不思議。ちなみに使ってるCPUはPentium 2。この性質はPentium Proからしっかり引き継いでいるようだ。
  　Pentium 4ならここまで影響大きくないんだろうけど、今回のオプティマイズは遅いマシン向けだから、速いマシンのことは考える必要なし。
  
  　さて今度はsRGB→L*a*b*をやってみなくては。ちなみに元々の公式そのままdouble使用遅いぜバージョンは1回の変換が約140ms。sRGB→L*用のアセンブラプログラムはめちゃめちゃチューニングしてしまったから、L*a*b*用プログラムは5倍くらいの量と処理時間になりそうだなぁ。予想実行時間は25msというところか。四則演算とメモリアクセスのどっちが速いのか遅いのか、それによってプログラムの方向性が全く変わってくるんだが・・・（両方やってみればいいんだが、面倒くさい(^^;）
  

• 　今日の覚書。
  
  

  /OPT:{REF | NOREF} /OPT:{ICF[=iterations] | NOICF} /OPT:{WIN98 | NOWIN98}

  
  　なんかファイルイメージが小さくなるっぽい。でもVisual Studio 6.0では隣家オプションを直接入力しないとダメっぽい（隣家オプションって何だよ＞IME2000）。Visual Studio .NETなら設定項目があるようだ。
  

• 　覚書その2。
  
  　try-exceptステートメントのexcept expressionで、C++のプログラム表現レベルで例外発生の原因を取り除いても、EXCEPTION_CONTINUE_EXECUTIONを行うと再度例外が発生する可能性がある。
  　EXCEPTION_CONTINUE_EXECUTIONは「例外が発生した場所からコードの実行を再開する」とされているが、この「場所」とは「例外が発生した『行』」ではなく「例外が発生した『機械語の命令』」であり、プログラム表現レベルの「行」が機械語の複数命令に対応している場合、この機械語の複数命令のうち例外発生以前の部分は再実行されないためである。
  　例えば「*p = 123」という式の実行がアクセス例外を発生した場合、except expressionの中でpをアクセス例外を生じない値に変更してEXCEPTION_CONTINUE_EXECUTIONを行えば実行を再開できるように思われる。
  　しかし実際には「*p = 123」は「mov ecx, [p]; mov [ecx], 123」のように2つの機械語に展開され、例外は2つ目の機械語命令で発生している。EXCEPTION_CONTINUE_EXECUTIONで実行が再開されるのはこの2つ目の命令であり、except expressionの中でpの値を更新してもこの2つ目の命令で使われているメモリアドレス（ecxレジスタに格納されている）は更新されないため、実行を再開すると再度同じ例外が発生してしまう。
  

2003年12月16日(火)

• 　ZDNetの記事（2003年12月16日 『TD-CDMA【てぃーでぃー・しーでぃーえむえー】』 筆者:江戸川）
  
  

  TD-CDMAでは通信チャネルを符号多重し、時間軸でスロットに分割する。このときスロット毎に上りと下りを割り当てることができるので、ADSLのように非対称な通信速度を持つ構成に設定することができる。

  （本日現在のイメージ）
  　スロット毎の割り当てと非対称な通信速度に直接の関係はない。それよりも電波の送信出力のほうが支配的である。そもそも、今までの携帯電話はどれも上り・下りのスロット数が同じだけど通信速度はどれも非対称。PHSを使用したデータ通信の下り通信速度の考え方に引っ張られたものと思われるが、勉強不足。
  　てっきりまた長浜さんかと思ったら、今度は違った(笑)
  

• 　ZDNetの記事（2003年12月16日 『東芝、切手サイズのハードディスクを開発〜小型情報機器向けに）』 筆者:後藤祥子 ）
  
  

  サンプル出荷時のスペックはまだ確定していないが、試作機段階でのサイズは直径0.85ミリ。

  （本日現在のイメージ）
  　いくら何でも0.85mmじゃ天下の東芝様でも無理でしょう。正解はもちろん、0.85インチ。
  

2003年12月5日(金)

• 　久しぶりにZDNet長浜和也氏の記事から。
  　ZDNetの記事（2003年12月5日 『「物量」で攻めるインテルを「質」で迎え撃つAMD』 筆者:長浜和也）
  
  

  このたび米国のAMD本社から来日した生産技術のトップが、AMDが誇る自動調整製造（Automates Precision Manufacturing：APM）をはじめとする、「高い技術力で効率の高いAMDの生産体制」について説明を行った。

  （本日現在のイメージ）
  　「Automates Precision Manufacturing」じゃ明らかに語呂が合わない。「Automated Precision Manufacturing」じゃないのかと検索してみると、やっぱりそうだった。
  　この筆者は、資料が横文字になるとどうも記事の確度が落ちる。この手の記事を見ると「もしかして長浜さん？」と署名を先に見る癖がついてしまった。
  

2003年11月12日(水)

• 　ここのところ役所ばっかり行っている。今月行ったのは区役所・税務署・ハローワーク・法務局・警察署・・・延べ10回は行っただろうか。書類仕事は嫌いではないが、さすがに飽きてきた。
  

• 　このあいだ、10月7日の日記でこう書いた。
  

  　部屋の整理をしていたら、昔参加していた草の根BBSの案内が出てきた。千葉にあったBBSで「ジェットストリームクラブ」、通称JSCという。けっこう規模が大きかったのに、googleしても何も出てこないのが寂しい。

  　今日になって、なんとsysopさんからメールを頂いた。お元気でしたか！というか、sysopさんもJSCで検索されたんでしょうね。そして、そのメールを見ていてふと思った。「Jet Stream Club」で検索していなかったじゃないか。
  　さっそく「Jet Stream Club」でgoogle・・・してみたら、いっぱい出てくるじゃないの！ 懐かしい名前が出てくる〜！ 嬉しい！！
  

2003年11月10日(月)

• 　Impress PC Watchの記事（2003年11月10日 『Iomega、容量1.5GBのリムーバブルメディア「DCT」の仕様を明らかに』）
  
  

  （略） 　DCTは、Click!メディアと同サイズの小型リムーバブルメディア。

  （本日現在のイメージ）
  　Clik!やっちゅうに
  

• 　ZDNetの記事（2003年11月10日 『ZDNN：「メディア容量35Gバイト」のリムーバブルストレージ登場』 筆者:長浜和也）
  
  

  （略） 　利用方法はTypeIIPCカードのリーダにメディアカートリッジを挿入するタイプのもので、以前アイオメガから「Click！」の愛称で販売されていたPocketZipと見た目は非常に良く似ている。

  （本日現在のイメージ）
  　だからClik!やっちゅうに
  

2003年10月30日(木)

• 　Impress PC Watchの記事（2003年10月30日 『シャープ、過去最高の上期決算』）
  
  （本日現在のイメージ）
  　まだ10月30日なのに「11月29日 発表」・・・
  

2003年10月15日(水)

• 　Impress PC Watchの連載「■塩田紳二のPDAレポート■」（2003年10月15日 『ザウルス SL-C750はどう変わったのか』）
  
  （本日現在のイメージ）
  　表2で新旧製品（C750とC700）の内容が入れ替わっている。それだけ。
  

2003年10月13日(月)

• 　BIGLOBE「デジタル生活向上委員会」連載第6回の記事（『カウントダウン！PCリサイクル』）
  
  

  （略） 　法改正以前に販売されたパソコンなど、PCリサイクルマークが貼られていない製品に関しては、廃棄時に回収費用を支払わなければならない（詳細については次ページ参照）。家電リサイクル法のように、施行前に購入した製品が免除にならない点を気を付けるようにしたい。これを知らずに一般ゴミとしてパソコンを処分しようとすると罰せられることになるので注意。

  （本日現在のイメージ）
  　「家電リサイクル法のように、施行前に購入した製品が免除にならない点を気を付けるようにしたい。」と書いてあることから、この記事の筆者は「家電リサイクル法では、施行前に購入した製品は適用を免除される」と考えているらしい。これは全くの誤りである。
  　分からないなら分からないなりに下調べくらいすればいいのに、なぜそんな小さな手間を惜しむのだろうか。そして、それを指摘しようにも連絡先の記載が一切ない。典型的な「書き逃げ」である。
  

2003年10月12日(日)

• 　読売新聞の記事（2003年10月12日 『「ひまわり」後継機、米製造会社破産で打ち上げ延期？』）
  
  

  老朽化で引退した静止気象衛星「ひまわり」の後継機「運輸多目的衛星（新１号）」について、米国の製造会社が経営破たんし、製造続行を求めた日本政府の申し立ても現地の裁判所で却下されたことを、気象庁が１２日明らかにした。 　新１号機は同社のミスなどで既に２度打ち上げが延期され、同庁は当面の代替として米国の古い気象衛星を月１６００万円で借用中。来年初めに予定していた新１号機の打ち上げはまたも延期が濃厚で、日本の気象観測はさらに大きな不安に直面することになった。 （後略）

  （本日現在のイメージ）
  　そりゃ大変だ！と思ったのも束の間、よく考えてみたら・・・
  
  　衛星の耐用年数は確か5年程度。5年間、いま借りている衛星を借り続けたとすると費用は約10億円、これに対して新衛星を打ち上げると衛星本体の製造費だけで100億円以上。
  
  　借り続けて差額を他の用途に使うのと、どちらが本当に得なのだろうか。
  

2003年10月8日(水)

• 　溜まりに溜まったCD-ROMを一気に整理したら、不要なCD-ROMが山になった。こんなふうに。
  
  　いったい何枚あるんだろう。捨てる前にちょっと数えてみるか．．．（数えてみた。325枚あった。）
  

2003年10月7日(火)

• 　またしても1ヶ月の休み。日記というより「月記」だね。
  

• 　部屋の整理をしていたら、昔参加していた草の根BBSの案内が出てきた。千葉にあったBBSで「ジェットストリームクラブ」、通称JSCという。けっこう規模が大きかったのに、googleしても何も出てこないのが寂しい。
  
  　SYSOPの渡辺さん、MAKOさん、牛さん、むべちゃん・・・みんな、どうしてるのかなぁ。
  

• 　「インペリアル・コンソリデイティッド・ジャパン」という会社を知っているだろうか。元本保証・年利8.5%利率保証という美味しいファンドを販売していた会社なのだが、今年8月に破綻したらしい。（参考記事：産経新聞『１００億円以上償還不能　「年利８．５％」英社系投資ファンド』）
  
  　実は、2000年頃にこの会社の商品に興味を持って話を聞きに行ったことがある。出てきた代表者というのがいかにも怪しい雰囲気の人間だったので手出しを止めたのだが、止めておいて本当によかった。（その時もらった名刺がコレとコレ。）
  

2003年9月10日(水)

• 　読売新聞の記事（2003年9月10日 『鳥取県、情報公開で懲戒職員を全員公開…全国初』）
  
  

  鳥取県は１０日、情報公開請求があった場合、不祥事などで懲戒処分にした職員の氏名を例外なく公開することを決めた。 　業務に関する不祥事については、口頭注意や訓告など軽微な処分でも公表する。全国市民オンブズマン連絡会議（名古屋市）によると、懲戒処分を受けた職員名の原則公開は全国の自治体で初めて。 　刑事事件の被疑者などを除いて氏名は非公開だったが、今年８月、職務怠慢などで職員７人を処分した際、いずれも問題発覚から１年以上経過していたため、処分の迅速化とともに公表基準の見直しを検討していた。

  （本日現在のイメージ）
  　鳥取県、偉い！ 警察は鳥取県の爪（ってどこにあるんや？）の垢を煎じて飲むべし。
  

• 　読売新聞の記事（2003年9月10日 『ディーゼル排ガス規制、千葉が離脱』）
  
  

  東京、神奈川、埼玉、千葉の１都３県で来月１日から同時に始める予定だったディーゼル車の排ガス規制から、千葉県が事実上、離脱する見通しとなった。 　千葉県議会最大会派の自民党が９日、県ディーゼル車排ガス規制条例の罰則規定の適用を２００５年３月まで延期する方針を固めたためだ。（後略）

  （本日現在のイメージ）
  　さすが千葉県！ 要は、千葉県議は票と金ほしさに県民と周辺地域住民の健康を売り飛ばしたということ。自分の懐さえ暖まれば赤の他人の生命など歯牙にもかけないということか。まあ普通の政治屋はそんなもんでしょう。
  

2003年9月9日(火)

• 　旧KDD（現KDDI）のサービスといえば誰でも国際電話を思い浮かべるであろうが、実はDDIと合併する以前から「001市外電話」という国内電話サービスを提供していた。これには国内の電話サービスとしては珍しい6秒ごとの課金を行うという特徴があり、比較的低価格でもあったため、FAX送信のように1回の通話時間が短い場合おトクなサービスであった。
  
  　ところがKDDはこれに競合する「0077市外通話」を持っているDDIと合併しKDDIとなり、国内電話サービスは旧DDI「0077市外通話」のみを全面に出すことになったため、旧KDD「001市外電話」の情報は一切表に出てこないようになった。
  
  　それでもサービスの提供自体は続いているのだが、今日KDDIのカスタマサービスセンターに電話して料金表を請求しようとしたところ、6秒単位（課金単位）ごとの料金表は提供していないので口頭でしか料金は回答できないとか。何年か前に請求した時は送ってきたのに・・・しょーがないので、口頭で全距離区分・全時間帯区分の料金を聞き出した(笑)
  
  　その料金表は以下のとおり。
  
  「001市外電話」 6秒ごとの通話料金

  通話 区分	通話先までの 距離	隣接区域・ 20km以下	20km超〜 30km以下	30km超〜 60km以下	60km超〜 100km以下	100km超〜
  県 内 通 話	平日昼間	0.66	1.01		1.34
  	夜間・休日	0.66	0.91		1.01
  	深夜・早朝	0.50	0.68
  県 外 通 話	平日昼間	0.66	1.01	1.10	1.80	2.30
  	夜間・休日	0.66	1.01		1.20	1.80
  	深夜・早朝	0.50	0.90			1.00

  （注：単位は円。1通話ごとの最低課金金額は5円。）
  　これだけだとどの程度おトクなのか分かりづらいので、同じKDDIの「0077市外通話」と料金を比較してみると次のようになる。（「0077市外通話」は距離区分が1つ多いので、下表では追加してある。）
  
  例1：通話時間40秒の場合（FAX1枚送信に相当）

  通話 区分	通話先までの 距離	隣接区域・ 20km以下	20km超〜 30km以下	30km超〜 60km以下	60km超〜 100km以下	100km超〜 170km以下	170km超〜
  県 内 通 話	平日昼間	5 10	7.07 10		9.38 10
  	夜間・休日	5 10	6.37 10		7.07 10
  	深夜・早朝	5 10	5 10
  県 外 通 話	平日昼間	5 10	7.07 10	7.7 10	12.6 20	16.1 20
  	夜間・休日	5 10	7.07 10		8.4 10	12.6 20	12.6 20
  	深夜・早朝	5 10	6.3 10			7 10

  （注：単位は円。上段「001市外電話」料金、下段「0077市外通話」料金。）
  　通話時間40秒ではすべての距離区分・時間帯区分で「001市外電話」のほうが安いという結果になった。では通話時間30分（1,800秒）では？
  
  例2：通話時間1,800秒の場合

  通話 区分	通話先までの 距離	隣接区域・ 20km以下	20km超〜 30km以下	30km超〜 60km以下	60km超〜 100km以下	100km超〜 170km以下	170km超〜
  県 内 通 話	平日昼間	198 200	303 300		402 400
  	夜間・休日	198 200	273 240		303 300
  	深夜・早朝	150 150	204 200
  県 外 通 話	平日昼間	198 200	303 300	330 400	540 600	690 800
  	夜間・休日	198 200	303 300		360 400	540 600	540 700
  	深夜・早朝	150 150	270 240		270 300	300 400

  （注：単位は円。上段「001市外電話」料金、下段「0077市外通話」料金。）
  　料金差が微小なものを同額とみなすと、実質的に差があるのは上の着色部のみである。これを見ると、県内市外か県外で距離20km〜60kmの場所に通話相手がいない限り「0077市外通話」が安くなることはないことが分かる。
  
  　これだけの差があるのにKDDIが「001市外電話」を推さずに「0077市外通話」を全面に出す理由は不明だが、おそらくこの「実質的には0077市外通話のほうが高い」ということも理由の1つであろう。つまり、高いほうが利益になるからということである。
  
  　ところで、私は「001市外電話」を通話時間の短いFAX送信のみに利用し、通常の県外通話にはJENSのipPhoneサービスを使用している。これは全国一律3分17.1円なので、30分（1,800秒）では171円となり、ほとんどの距離区分・時間帯区分で他社サービスよりも安いからである。
  
  　普通の固定電話から掛けられる、これより安い通話サービスといえば平成電電のサービスや各社のIP電話サービスがあるが、どれも月額固定料金や初期費用がかかるからパス。月に500円かそこらしか使わないのに数千円の初期費用や数百円の月額料金を払うのは馬鹿げているので。
  

2003年9月7日(日)

• 　みなさんはオイシス(OISIS)をご存知だろうか。これは神戸市にある製パン・製菓メーカーなのだが、ここの菓子パンには他のメーカーにはない大きな特徴がある。それは、どれも他のメーカーのものと比較して妙に安いのである。
  
  　うちから歩いて5分以内にスーパーが2軒ある。いずれも安売りが主な売りで、最初の1軒が開店してきた3年前には、それよりもっと前からあった1軒のスーパーが潰れてしまった。その後、昨年になってその跡地にまた別のスーパーがより過激な安売りを売りにして開店。そして、この昨年開店したスーパーでは並んでいる菓子パンまでもが軒並み妙に安いのである。不思議に思いよく見てみると、それこそがこのOISISブランドのものだったのだ。
  
  　その後、3年前に開店したほうのスーパーでもOISISブランドを並べるようになったのだが、そっちの店でもやっぱり安い。これは絶対に安かろう悪かろうであろうから手を出さないようにと気をつけていたのだが・・・
  
  　今日、「3年前に開店したほうのスーパー」で見切り品として並んでいる菓子パンを何気なく買ってきて、食べ始めたところ、なんだか味がとてもイマイチ。ありていに言えば、マズい。これはひょっとして、と思い外装をよく見たところ、果たしてそれはOISISブランドであった。がーん。やっぱり安かろう悪かろうだったのか。もう二度と買わないぞ！
  

2003年9月5日(金)

• 　共同通信の記事（2003年9月5日 『マクドナルド再提訴も却下　ＮＹの肥満訴訟』）
  
  

  【ニューヨーク４日共同】ニューヨークの米連邦地裁は４日、糖尿病や心臓病などの症状がある肥満児らが、肥満の原因となる食事をさせたとしてハンバーガー店チェーンのマクドナルドに損害賠償を求めた２回目の訴えを却下した。 　地裁は今年１月、肥満は食べ過ぎた本人の責任として同じ原告らの訴えを退けたが、内容を修正して再提訴することは認めていた。 　原告側は新たな訴訟で、マクドナルドが自社のハンバーガーなどを健康な食品と消費者に誤解させているなどと訴えた。これに対し地裁判事は、マクドナルドの食品が原告の健康被害の原因であることや、誤解を招く宣伝の事実を原告側は立証できなかったとしている。 　原告側はさらに再提訴を認めるよう求めたが、判事は却下した。

  （本日現在のイメージ）
  　このニュースには2つの側面がある。1つは、米国人の中には、こんな下らないことを大真面目に訴える大馬鹿者がいるということ。もう1つは、米国はこんな下らない大馬鹿な訴えでも勝訴する可能性が皆無ではない大馬鹿な司法制度を持っているということ。
  　司法制度の大馬鹿度では日本も全く負けていないのだが。
  

• 　続けて共同通信の記事（2003年9月5日 『裁判官になるのは「変人」　伊首相発言、政治問題に』）
  
  

  【ローマ４日共同】イタリアのベルルスコーニ首相が英週刊誌スペクテーターとイタリアの地方新聞の両英国人記者とのインタビューで「裁判官は普通の人と違う変人」と発言。これにマスコミや野党が猛反発、政治問題に発展した。 　インタビューは先週、行われた。ＡＮＳＡ通信によると、マフィアとの関係を禁じる組織犯罪関与罪に問われたアンドレオッティ元首相についての質問に、首相が「彼は頭がいい人だからマフィアと関係ない」と述べた後で「裁判官になる人は精神的におかしいし、変人だ」と発言。また「こんな職業を選ぶ人は精神的に問題がある」とも言った。 　首相自身も、ミラノ地裁で贈賄罪に問われる被告人の立場にあり、司法と対立していることなども発言の背景にありそうだ。

  （本日現在のイメージ）
  　米国よりもイタリアのほうが日本の司法制度の状況に似てるようだ。日本の裁判官にも浮世離れした、精神的におかしいとしか思えないような物の考え方をする人が多い。
  

• 　またまた共同通信の記事（2003年9月5日 『９月１１日を「愛国の日」に　米大統領、追悼呼び掛け』）
  
  

  【ワシントン４日共同】米ホワイトハウスによると、ブッシュ大統領は４日、中枢同時テロから２年を迎える今月１１日を「愛国の日」とすることを決めた。 　マクレラン大統領報道官は４日、記者団に対し「大統領は９月１１日に国民が各家庭で半旗を掲げ、（乗っ取られた１機目の民間機が世界貿易センタービルに突っ込んだ）午前８時４６分に黙とうするよう呼び掛けている」と述べた。ホワイトハウスによると「愛国の日」は休日扱いとはせず、連邦政府や教育機関の業務は通常通りという。 　報道官によると、大統領は昨年の９月１１日はニューヨークの追悼式典で演説したが、今年はホワイトハウスでローラ夫人やスタッフらとともに簡素な追悼行事に参加。ニューヨークの式典にはチェイニー副大統領が代理出席する。

  （本日現在のイメージ）
  　米国はファシズムに向かって一直線に突き進んでいますな。いったいこれは米国人の多くが狂っているのか、それとも米国政府が狂っているのか。後者であることを祈りたいところ。（しかし政府が狂っているとしたら、それを選んだ人民も同様・同罪であろう。もちろん日本の状況も同様。）
  　ジョニー・デップは「米国はまるで愚かな子犬のようだ」と発言したそうだが、愚かな子犬ならまだ良かった。愚かな大型狂犬であるところが始末に負えないのだ。
  

• 　またまた、また共同通信の記事（2003年9月5日 『心から国民に深くおわび　札幌の集会で鈴木議員』）
  
  

  地元北海道入りしている衆院議員鈴木宗男被告（５５）＝受託収賄罪などで公判中＝は５日夜、札幌市内のホテルで歌手の松山千春さんら支援者が開いた集会に出席した。 　閉会後、鈴木議員は記者団に対し「国会議員でありながら裁判を受ける身となり、心から国民の皆さまにおわび申し上げる」と述べ、陳謝した。（後略）

  （本日現在のイメージ）
  　陳謝の理由が「国会議員でありながら裁判を受ける身となったこと」とは、あきれるほかはない。日本にはこういう、ふてぶてしい政治屋しかいないのか？
  　裁判を受ける身となったのは「不徳の致すところ」ではなく「罪悪を犯したから」であって、国民に対してするべきことは「陳謝」ではなく「謝罪」である。
  　松山千春もいったい何を考えているのやら。裏で何か動いているのか？
  

2003年9月2日(火)

• 　再開したとたん、1ヶ月の休み。いかにもありがち。もちろんこの日記のこと。
  

• 　最近、携帯メールの設定でメール指定受信設定を外した。そうしたら、携帯発の迷惑メールが来る来る。それを見て感じるのは、迷惑メールは実に窃盗行為であるということ。迷惑メールの発信者は、受信者が加入する携帯キャリアをして、受信者の財産を不当に奪っているのである。もちろん、携帯キャリアもその窃盗行為の主要な行為者であり、容易に行える対策を取らずいたずらに迷惑メールの発信者を利している以上、窃盗の共犯であることは免れない。ここで言う容易に行える対策とは、メールの本文に基づく遮断機能の提供である。
  
  　これはNTTドコモの場合になるが、NTTドコモは最近、メールの内容に基づく遮断機能の提供を可能にする規定を加入契約の内容に追加した。この規定追加によってNTTドコモはメールの題名に基づく遮断機能の提供を開始できるようになった。（メールの内容は通信上の秘密と見なされるので、追加規定なしではキャリアがその内容を閲覧することができない。）しかし、この追加された規定には実はもっと強力な使い方がある。
  
  　この追加規定自体は、遮断の判断材料をメールの題名に限定していない。つまり、規定のさらなる変更なしでメールの本文に基づく遮断機能も提供できるのである。これこそが先に言うところの「容易に行える対策」である。
  
  　現在流通している迷惑メールの大部分は出会い系サイト等のウェブサイトにメール受信者を誘導するものである。このようなウェブサイトに誘導するメールが激増した背景には、現在使用されている携帯電話のほとんどがウェブ対応となり、かつ受信した携帯メールの中にあるウェブサイトのアドレス(URL)から簡単にそのウェブサイトを開くことのできる機能を備えるようになったことがある。ということは、逆に言えば現在流通している迷惑メールの大部分はこの「メールの中にあるアドレスからウェブサイトを開く機能」に依存しているということであり、この機能を利用するために必要な特有の表現形式があれば、メールの本文を対象としてその表現形式を含むメールを遮断することができることになる。そのような表現形式はあるのだろうか。
  
  　それが、あるのである。この機能を利用するには、ウェブサイトのアドレスを必ず「http://」または「https://」という一連の文字で開始しなければならない。つまり、本文にこれらの文字を含むメールを遮断すれば迷惑メールの大部分は遮断できるのである。そして、既にNTTドコモを含むキャリア各社は題名に「未承諾広告※」という文字を含むメールを遮断する機能を提供しているのであるから、これと同じ機能を、今度は題名ではなくメールの本文に適用するだけのことが難しいわけはない。
  
  　ではそんな簡単なことを、なぜキャリア各社はすぐに行わないのか。その理由は2つ考えられる。まず、ウェブサイトのアドレスを含むメールをすべて遮断してしまうと、迷惑メールだけでなく契約者が本当に利用したいと考えるウェブサイトのアドレスを含むメールまで遮断されてしまうからである。これによって勝手サイトのアドレスやiショットメールのやりとりもできなくなってしまう。しかしこれは、現在提供されているメール指定受信・ドメイン指定受信設定のように、遮断の対象外とするウェブサイトを登録できるようにすればよいだけのことである。
  
  　しかしいちばんの理由は次のものであろう。すなわち、キャリア各社はメールが流通すればするほど儲かる上、迷惑メールによって契約者が出会い系サイト等を利用すればますます儲かので、なるべくメールを遮断したくないのである。どんなに簡単であってもメールの遮断にはシステム開発のコストがかかり、その上メールを遮断することによって儲けも減る、それだからキャリア各社は迷惑メール対策に及び腰なのである。
  
  　ところで、このような対策が行われると現在流通している迷惑メールの大部分を遮断できることは前述のとおりであるが、その「大部分」とはどの程度なのであろうか。メール指定受信設定を外したのは約3ヶ月前のことであるが、それから送りつけられてきた迷惑メールは549通にのぼる。そのうち本文に「http://」を含むものは542通であった。本文に「http://」を含むメールを遮断するだけで、549通の迷惑メールが僅か7通に減るのである。これは、従来1日平均6通の迷惑メールを受け取っていたものが2週間に1通程度に激減することを意味する。
  

2003年8月7日(木)

• 　今日の昼も暑かった。が、昼過ぎから雲が出始めて、夕方にはけっこう厚い雲に覆われた。おかげで気温もちょっと下がって・・・それでも30℃・・・ぐわー。
  

• 　ふと思い出した昔のこと。
  　小学生の頃、1人で山形から東京まで遊びに出かけたことがあった。その時に乗ったのが、今はなきエル特急つばさ。（「エル特急」ってまだあるんかな？）
  　座席は通路側だったのだが、窓側に座っていた人と、通路を挟んで反対側の2席に座っていた人たち、計3人は連れ立っていたらしく、しばらくは私の頭越しに話をしていた。
  　そのうち、窓側の人が話し掛けてきて・・・
  
  『窓際の席にしない？』
  　別に窓際の席になりたくもなかったので断わると、またしばらく話をしてから、今度は
  
  『席を換わってもらえない？』
  　最初からそう普通に頼めば良いものを。今にして思えば、「子供だからきっと窓の外が見られる席なら喜んで交代するだろう」と小賢しいことを考えて、頼もうとしなかったんでしょうな。
  

2003年8月6日(水)

• 　ZDNetの記事（2003年8月5日 『2008年、ディスプレイの中で動く「自分の心臓」とご対面』 筆者:長浜和也）のヘンなとこ。
  
  

  心臓の形状も物性データも筋繊維配列そろってしまうそうだ

  （本日現在のイメージ）
  　「筋繊維配列そろってしまう」とは何だろう？ 何か助詞が欠けているようだ。
  
  　そういえば、ZDNetの記事はいつも写真のキャプションの最後に句点（「。」）を付けない。同じ写真のキャプションでも、途中なら句点を付けるのに。どうも奇妙な編集ルールだ。
  

• 　読売新聞の記事（2003年8月6日 『神奈川県警茅ヶ崎署が少年事件など２００件放置』）
  
  

  神奈川県警茅ヶ崎署の警察官らが、被害届を受けた軽微な少年事件など約２００件について、適正な処理をしないまま放置していたことが５日、県警の内部調査で明らかになった。 　県警は６日にも県公安委員会に報告し、担当者や上司ら数人の処分を発表する。 （略） 　ただ、書類を意図的に隠したり、捨てたりした形跡がないことから、県警は刑事事件としての立件を見送り、内部処分を行う方針。 　少年事件の放置では、今年６月、埼玉県警の４署が、容疑者がほぼ特定されていた約７０件について必要な捜査を行っていなかったことが発覚。当時の担当者５人が訓戒や注意の内部処分を受けている。

  （本日現在のイメージ）
  　また神奈川県警か・・・
  　民間なら数度の業務放置で戒告、数十回ともなれば責任者はクビになるのが当然だが、前例から言って、今回も戒告からせいぜい減給100分の10程度で済ませるのだろう。担当者とその上司をどのように処分するのかが注目される。今度こそは公務員の身びいきとならなければよいのだが。
  
  　毎日新聞の記事（2003年8月6日 『＜神奈川県警＞放置事件は２４９件　担当者処分へ』）
  
  

  （略） 元警部補は「処理する事件が多すぎて放置した」と話しているという。

  （本日現在のイメージ）
  　ということは、明らかに過失ではなく故意による職務怠慢。するべき仕事をわざと仕事をしなかった、そんな人間を警察はどの程度に罰するだろうか。ちゃんとクビにできればようやく民間並みになったと誉めよう。おそらく「減給減給100分の5を3ヶ月」程度でお茶を濁すのであろうが。
  
  　時事通信の記事（2003年8月6日 『少年事件など２５０件放置＝当時の上司ら３人処分』）
  
  

  （略） 県警は同日、当時の上司３人を本部長訓戒とする処分を行った。

  （本日現在のイメージ）
  　あぁ、やっぱりその程度。さすがは警察。期待を裏切らない見事な腐敗っぷりだ。身内の不正はできるだけ助けるのがモットーなのでしょうな。民間なら、表沙汰になった以上は上司を減給ないし降格、担当を懲戒免職にした上でイメージダウン分の損害賠償請求というところだ。もっとも、神奈川県警ではダウンするほどのイメージは残っていないだろうが。
  

• 　信濃毎日新聞の記事（2003年8月6日 『住基ネット 県と国側 討論会　安全性論議など平行線』）
  
  

  二十五日に本格稼働する住民基本台帳ネットワーク（住基ネット）の安全性をめぐり、県本人確認情報保護審議会委員と総務省側が五日、討論会を東京都内で開いた。県側は住基ネットの安全性を確認するため、システムへの公開侵入実験の実施を求めたが、総務省側は安全対策上、否定的な姿勢を示した。安全対策向上に向け、意見交換を重ねる必要性は認めた。 (略) 　田中知事は討論会後、総務省側が公開実験に否定的な姿勢を示したことに対し、「自治事務を指導監督してきた国の責任として無謬（むびゅう）性を確認すべきだが、明快な答えがない。テストすると不具合があるのか」と述べた。

  （本日現在のイメージ）
  　田中・長野県知事は毎度いいこと言うね。
  

2003年8月5日(火)

• 　以前カプリチョーザで食事をした時の意見・苦情を送ったのだが、今日、お礼としてお食事券が送られてきた。ラッキー。
  

• 　ゴーヤチャンプルを作った。食べたら塩味が足りなかったので、ソルトミルでゴリゴリと塩を振りかけたら・・・うひゃーー！
  　暑かったので真横に扇風機を置いていたのだが、その風にあおられて塩がみんな横に飛んでいってしまった。そこらじゅう塩だらけ。
  

• 　20分ほどで食べ終わってしまった。バカでかいゴーヤをまるまる1本使ったのに。苦しい。
  

• 　稲光が見えたので、デジカメで撮ってやろうとベランダに出てムービーモードで撮りまくってみた。
  　撮っている最中に別の稲光があったのに、再生してみたら撮れていなかった。
  　うーむ、ファストシャッターになっているとは思えないんだが・・・なぜだろう。
  

2003年8月4日(月)

• 　明らかに自分が阪神ファン化している。近畿に来て2年くらいでだんだん阪神ファンになっているのは自覚していたが、これほどとは・・・
  

• 　今日は激烈に暑かった。今シーズン初めて、夜までエアコンつけていた。
  

2003年8月3日(日)

• 　このあいだ、法事でのこと。
  　法事で行くお寺さんには藤棚があるのだが、小さい頃、私はそれをずっと「ぶどう棚」だと思っていた。
  　・・・という話をイトコにしたら、
  
  ぶどう棚って何？？？
  という顔をされてしまった。
  　ぶどう棚、知らない？ ぶどう狩りは？ ぶどう棚より藤棚のほうがポピュラー？
  

• 　いまだにWindows 2000を使っているが、時々、デスクトップが異常なことになる。「デスクトップが」というよりも、GDIが異常になっている雰囲気。アイコンやボタン・スクロールバー等の見た目が異常になるので。（こんな感じ）
  　いったんこうなると再起動するまで正常に戻らない。めちゃ面倒だ。
  　Xpならこういうことは起きないんだろうか。（いや、同じことが起きるに違いない。）
  

• 　表紙にも置いたが、「ゲーム脳」関連リンクを置いてみる。
  
  

  「斎藤環氏に聞く ゲーム脳の恐怖」 『「斎藤環氏に聞く ゲーム脳の恐怖」のGoogleランクを上げよう』運動

  
  

• 　近所で花火大会があった。ちょうど家の窓から見えるのだが、「おーー大玉！」と思ような大輪の花火でも、デジカメで撮るとショボくなってしまうのが悲しい。こんなふうに。
  

2003年8月2日(土)

• 　ここ数ヶ月、日記的ネタがたくさん出てきた。そろそろ日記を再開しようかと思った。が、日記を更新するのは面倒。手作業でやっていたら、また前と同じように途中で面倒になって止めてしまうのは目に見えている。ので、日記用のCGIでも作ろうかと思った。が、それもやっぱり面倒なので放置していた。
  　しかし、そろそろネタを貯めつづけるのも限界に近づいてきたので、また手作業日記を再開することにした。いつまで続くことやら・・・
  

• 　今日見つけた「変な主張」
  
  

  御覧の通り、記紀神話には旧約聖書の影響が見て取れる。なぜ、日本神話に聖書の故事が混入しているのだろうか？ 　それは日本人の一部に、イスラエル起源の民族がいるからに他ならない。

  神話の謎から抜粋（本日現在のイメージ）
  　「お話し」が伝来していることがどうして民族が到達していることの根拠になるのか。その「混入した故事」が真正イスラエル起源だったとしても、単に「イスラエル起源の物語が口伝えに伝来した」と考えるほうがよっぽど単純で無理がない。
  

• 　次はZDNet長浜和也氏の間違い記事特集。
  

• 　このあいだ見つけた、ZDNetの記事（2003年7月11日 『Rambusはメモリの仇をPCI Expressで討つ』 筆者:長浜和也）の誤り。（2003年7月14日指摘済み、現在まで未訂正。）
  
  

  きょうのTechnical Trackでは、もう一歩踏み込んだ実際の開発で必要になる、PCI Express PHYの仕様や、PCI Expressのパラレルインタフェース用PIPEの実装方法の解説が行われた。

  （本日現在のイメージ）
  　あたかも一般に「PIPE」と呼ばれるものが存在し、それを「PCI Expressのパラレルインタフェース用」に改訂あるいは適用したものであるかのような印象を与える記述だが、実際には全くそのようなものではない。ここで言うPIPEとはPHY Interface for PCI Expressの略であり、全くPCI Express専用のものである。
  　「PCI Expressのパラレルインタフェース用『ではない』PIPE」というものが存在しない以上、「PCI Expressのパラレルインタフェース用」という前置きは意味をなさない。
  　筆者はPIPEが何を意味しているのか理解しないまま原稿を書いたものと思われる。
  
  

  PCI Expressは、サーバ用高速パラレルバスのPCI-Xや、PCの外部機器接続バスとして最も普及しているPCIと、ソフトウェアレベルで互換性を持たせることになっている。そのため、シリアル接続のPCI Expressにパラレルインタフェースへの変換回路も実装する必要があるのだ。

  （本日現在のイメージ）
  　この記事で取り上げられているパラレルインターフェースは前述の「PCI Express PHYのパラレルインターフェース（PIPE）」のみだが、これはPCI-XやPCIとの互換性のために存在するものではない。また、PCI ExpressではPIPE以外の「パラレルインタフェースへの変換回路」なるものの実装は必須ではない。
  　PCI-XやPCIをそのまま使用する場合、すなわちPCI Express - PCI(-X)ブリッジを構成する場合には当然に「パラレルインタフェースへの変換回路」が必要となるが、PCI Express - PCI(-X)ブリッジの実装は、これも必須ではない。
  　この部分は「シリアルインターフェースのPCI ExpressがパラレルインターフェースのPCI(-X)と互換→それならパラレル変換が必要だろう」という推測のみで書かれた文章と思われる。
  
  

  PCI ExpressはInfiniBandをベースに、PCで必要になるプラグ＆プレイ機能やパワーマネジメント機能を拡張している

  （本日現在のイメージ）
  　あたかもPCI Expressが「InfiniBandを拡張して派生したもの」であるかのような印象を与える記述だが、実際には、PCI ExpressはInfiniBandから派生したものではない。
  　InfiniBandは旧称をNGIO（Next Generation I/O）というI/O技術、PCI Expressは旧称を3GIO（3rd Generation Input/Output）というI/O技術で、いずれもその開発にはIntelが関与しているが、I/O技術としては全く別系統のものである。
  　「どちらも確かIntelが関ってたような」程度の認識で書かれたものだろうか。
  
  

  Elastic BufferからFramerを経てPMA Rxに信号が送られている

  （本日現在のイメージ）
  　記事中4枚目の写真で分かるとおり、Framerに送られる信号はElastic Bufferからのものではなく、Lane-Polarity（LP）からのもので、明らかな誤り。
  
  

  データ幅が8ビット、もしくは16ビットでないのはPCS内部で8b/10bエンコードされて10ビット幅でMAC層に送られるためだ。

  （本日現在のイメージ）
  　これも同じく記事中4枚目の写真で分かるとおり、PCSとMAC Layer（MAC層）の間のインターフェースは8b/10bエンコードデコードの8b側であり、明らかな誤り。
  
  

  Elastic Bufferのビット増減は、データフレームに設けられたSkip Sequence用のビットに対して行われる。一番上は正規のビット配列で真ん中が1ビット追加された状態、下が1ビット間引きされた状態のデータ配列になる

  （本日現在のイメージ）
  　あたかもElastic BufferでSkip Sequenceを1ビットずつ増減するかのような印象を与える記述だが、実際にはElastic Bufferは8b/10bエンコードされた10ビットのコード（10bコード）を処理の単位としていて、10bコードを追加したり削除したりしており、これも明らかな誤り。
  　記事中6枚目の写真にあるData PacketやSkip Sequenceのデータのそれぞれ（D[n]やCやSと表記されたもの）は、1ビットを表しているのではなく、すべて10bコードを表している。
  　これに関連して、記事中には「接続されたシステム間でクロックのズレが発生している場合に、Elastic Bufferの内部で送受信するフレームにビットを追加、もしくは削除してデータの一貫性を保つようにする。」、あるいは「相手側（画面ではSystem1）のクロックが速い場合、Elastic Bufferでは余計に送られてくるビットを間引きしてデータの同期を図ろうとする。逆に相手側のクロックが遅い場合は、Elastic Bufferで足りないビットを追加する」とあるが、これらもElastic Bufferで1ビットずつ増減するという誤解に基づく不正確な記述である。
  
  

  もちろんエンドユーザーにとって、いまあるPCIベースのリソースがそのまま使えるメリットの大きさついては、改めて言うまでもないだろう。

  （本日現在のイメージ）
  　「いまあるPCIベースのリソース」をPCI Express移行後も「そのまま」使用するにはPCI Express - PCIブリッジの実装が必要になるが、記事中にはそれについての記述が全くない。ブリッジを実装すればそのまま使用できるという説明なしに、いきなり「改めて言うまでもないだろう」とはどういうことなのか、全く理解に苦しむ。
  

• 　もう少し前に見つけた、ZDNetの記事（2003年6月13日 『Let'snote LIGHT W2の跳ね上げドライブがもたらすメリットとは』 筆者:長浜和也）の誤り。（2003年6月16日指摘済み、現在まで未訂正。）
  
  

  通常2.5インチHDDは駆動電圧5.5Vであるが、Let'snoteシリーズは、特注の3.3V駆動のHDDを採用している。

  （本日現在のイメージ）
  　定格が5.5VのPC用部品は存在せず、明らかな誤り。正しくは5V（ないし5.0V）。
  

• 　もっと前に見つけた、ZDNetの記事（2003年6月12日 『インテルが30ナノメートルプロセスのトライ・ゲート・トランジスタの開発に成功』 筆者:長浜和也）の誤り。（2003年6月12日指摘済み、現在まで未訂正。）
  
  

  22mVの動作電圧で1GHzを発揮するDSP Multiplier

  （本日現在のイメージ）
  　記事中にあるプレゼンテーション資料の写真の中にはそのような記述がない。22mWという記述ならある。22mWを22mVと読み間違えているのではないか。
  　そもそもシリコンベースで動作電圧が22mVなどということは全く非常識であり、またそのような知識がなかったとしても、同じプレゼンテーション資料の中に「0.8V, 3mWで500MHz動作」とあることから類推できてしかるべきである。
  

• 　さらに前に見つけた、ZDNetの記事（2003年4月11日 『DDR400は出荷準備完了なれど当初の歩留まりは40％の見込み』 筆者:長浜和也）の誤り。（2003年4月12日・4月14日指摘済み、現在まで未訂正。）
  
  

  さらにパッケージにFBGAを採用したことで、同クロックのTSOPモジュールと比べ発熱量が7〜8割減少した

  （本日現在のイメージ）
  　記事中にあるプレゼンテーション資料の写真の中にはそのような記述がない。パッケージングの変更で発熱量が変わることはあり得ないので、明らかな誤りである。
  　これについて指摘したところ筆者から「この件は、エルピーダメモリのスピーカーが口頭で説明したものです。」という回答があった。（注：エルピーダメモリはプレゼンテーションを行った会社。）しかし、これについてエルピーダメモリに直接問い合わせを行ったところ、プレゼンテーションを行った当人から「(1) 消費電力低減の理由はあくまで電源電圧低下によるもの。(2) 消費電力は『従来と比較して8割減少した』のではなく『従来の8割となった』、すなわち『従来より2割減少した』。」という内容であるとの回答が得られた。
  　つまり、記事は二重の意味で誤っていることになる。すなわち、発熱量の減少の原因はパッケージングの変更によるものではなく、また発熱量は「7〜8割減少した」のではなく「7〜8割に減少した」のである。
  
  

  DDR2で採用されるOn Die Termination（ODT）を実装していない回路（左）と実装した回路（右）の違い。ODT採用回路ではトランジスタや抵抗がいらなくなるので、その分コストと消費電力が抑えられる

  （本日現在のイメージ）
  　記事中にあるプレゼンテーション資料の写真では、左がDDR2に実装される回路、右がその等価回路と説明されており、記事では回路の説明が誤っている。またODT採用によりディスクリート回路がいらなくなり、その分コストが抑えられる可能性はあるが、消費電力はODT採用のみでは削減されないので、この部分の説明も誤っている。
  

• 　こうして見てみると、どうやら長浜和也氏は理工系の理解が若干乏しい方のようだ。それならそれで、不明点があったら分かるまで調査して正しいことを書いてくれればよいのだが、それも苦手なように思われる。もしかしたら思い込みの激しい方なのかもしれない。
  

更新日: 2005年05月30日