Vista 64bit で AviUtl を使い、音声に MP3 を指定してエンコードしようとしたら、MP3 が使えなかった。l3codecp.acm が登録されていないようだ。「MP3の56kbps制限をなくす」を参考に、以下のレジストリを入力してから OS を再起動したところ、MP3 で音声をエンコードできるようになった。64bit と 32bit の両方で登録を行う必要がある点がポイントである。
REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32] "msacm.l3acm"="l3codecp.acm" [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32] "msacm.l3acm"="l3codecp.acm"
Core i7 920 で Super PI を動かしてみた。104万桁で 14秒だった。Super PI Mod だと 14.739s だった。Core Duo 2GHz のちょうど 2倍の速さだ。
64bit Windows で 32bit アプリを動かすと、%WinDir%\System32 へのアクセスは、%WinDir%\SysWOW64 にリダイレクトされてしまう。これをオフにする API を調べたところ、関連するものが 3つほどあるようだ。
これらの API を使う以外に、32bit アプリから %WinDir%\System32 にアクセスする方法はないのかと調べたところ、%WinDir%\Sysnative にアクセスすることで、%WinDir%\System32 にアクセスできるようだ。実際に試してみたところ、読み込みはできたが、書き込みはできないようだ。
動画を再生しながら、メインディスプレイからセカンドディスプレイにウィンドウを移動。BSoD が発生してしまった。
Core i7 マシンから HDMI 接続で E2200HD に画面を表示したところ、画面が小さく表示される問題が起きた。Catalyst Control Center を開いて、設定を確認したところ、スケーリングオプションの設定で、アンダースキャン側 5% 程度に設定されていたので、0% に修正したところ、正常な大きさで表示されるようになった。
DivX 6.8.5 を Vista x64 にインストールし、ライセンス登録しようとしたらエラーが出た。ライセンス登録のショートカットのリンク先を C:\Windows\System32\rundll32.exe 〜 から C:\Windows\SysWOW64\rundll32.exe 〜 に変更したところ、問題なく登録できた。
AviUtl で、H.264 にエンコードする際、出力先としてネットワークドライブを（UNC 形式で）指定していると、映像と音声の mux ができずに失敗するという問題が発生している。mux には、MP4Box の安定版を用いていたのだが、最新の開発版である MP4Box-0.4.5-dev_20081101 に入れ替えてみたところ、ネットワークドライブでも問題なくなった。
AviUtl を使ってエンコード速度を確認してみた。Core Duo 2GHz では、HD サイズの MPEG2 から HD サイズの H.264 にエンコードするのに、5〜6時間掛かっていたが、Core i7 920 では、1時間15分〜1時間半程度。およそ 4倍の速度が出ていることになる。この状態でも CPU は半分程度しか使われていなかったのでもう１本同時にエンコードしてみたところ、少し時間が延びて 1時間40分程度になったが、合わせて 7倍程度の速度が出ていることになる。
エンコード時のシステム全体の消費電力を調べたところ、1本エンコード時 140W 程度、2本同時エンコード時 180W 程度であった。
Gigabyte and MSI join the Core i7 motherboard crowd - The Tech Report - Page 7 を見たところ、EX58-UD5 の消費電力が他のものに比べてかなり大きい。少し割高になっても MSI のマザーボードの方が良かっただろうか。
ijexp32 を Vista x64 に正式対応させるに当たり、x64 関連情報を調査中。
カードリーダー付き FDD を取り付けようとしたら、M/B に付属の FDD ケーブルが微妙に短くて届かない。前のデスクトップから取ってきて付けた。
ijexp32 を Vista 64bit で使ってみた。まずは、WDK でコンパイルした 64bit 版をインストールしたところ、特に問題なくエクスプローラ上で実行ファイルの情報を確認できるようになった。SpringM などの 32bit アプリでは動作していなかったので、通常の 32bit 版もインストールしたところ、32bit アプリと 64bit アプリの両方で実行ファイルの情報を確認できるようになった。
コントロールパネルのアンインストール画面を開くと、64bit 版と 32bit 版が同じ名前で登録されていた。これではどっちがどっちだか分からないので、修正が必要だ。
一昨日購入した PC ケースと電源が到着した。早速組み立て。結構時間が掛かってしまったが無事にできあがった。（なお、FDD はまだ取り付けていない。）
気になる消費電力は、アイドル時 98W程度、高負荷時は未測定。グラフィックボードの性能を抑えたためか、比較的少なく済んでいる。
Core i7 マシン用に OS を購入。Vista Home Premium (64bit) をカードリーダー付き FDD とセットで購入。
ジャンクの DVI-HDMI 変換ケーブル (1m) を \480 にて購入。長さが足りないので、DVI ケーブル (1.8m) と DVI 延長コネクタを購入(\1,500 + \700)。普通の HDMI ケーブルを購入するよりは安く済んだか？
後で調べたら、普通の HDMI ケーブルを買った方が安かった様子。
メインマシンの Core Duo デスクトップの消費電力も測定してみた。アイドル時 90W 程度、高負荷時 100W 強。DVD-Rが全力で回ると +20W。
新 CPU の Core i7 は、一部で消費電力が大きいとの話も出ているが、グラフィックカードを適当に抑えておけば、システム全体ではそれほど大きくなさそうな気がする。最小構成なら 120W ぐらいで何とかなるのではないだろうか。
Core i7 マシンを組むことにした。
| 部品 | 詳細 |
|---|---|
| ケース | Antec SONATA PLUS 550 (静音ケース + 550W 静音電源) |
| CPU | Intel Core i7 920 (2.66GHz) |
| M/B | GIGABYTE GA-EX58-UD5 |
| メモリ | CFD T3U1333Q2G (DDR3-1333 2GB x 3) |
| HDD | Western Digital WD10EADS (1GB 5400rpm) |
| グラフィックカード | HIS H465P512P (RADEON HD4650、512MB、ファンレス) |
ケースは配送してもらうことにし、明後日到着予定。
PC の消費電力を把握しておこうと思い、ワットチェッカーを購入。
リプレースを考えている Tualatin Celeron デスクトップの消費電力を測定したところ、アイドル時は 90W 程度。ノート PC は、アイドル時 10W 程度。
アドバタイズショートカットか、通常のショートカットかの判別を簡単に行いたい。MsiGetShortcutTarget() を使うのが一般的なのだろうが、わざわざ新たに DLL を読み込みたくなかったので、.lnk を自前で読み込んで解析する方法を使うことにした。.lnk のフォーマットは、Wotsit.org から入手できるが、アドバタイズショートカットについては記載がない。解析したところ、フラグの 0x1000 が怪しい。これが立っていると IShellLink::GetPath() ではリンク先を取得できない。0x4000 も MSI と関係がありそうだが、詳細は不明。
以上の解析結果を基に、SpringM を改造中。
以前書いたように、MSI が作成するショートカットは普通のショートカットとは異なっている。このショートカットをアドバタイズショートカットと呼ぶらしい。
アドバタイズショートカットに対し、IShellLink::GetPath() を使って、リンク先の WIN32_FIND_DATA 情報を取得すると、dwFileAttributes によく分からない値が返ってくる。
例: 1回目: IShellLink::Resolve() を呼ばずに IShellLink::GetPath() を呼び出し。 0x00155510 2回目: IShellLink::Resolve() を呼んだあと IShellLink::GetPath() を呼び出し。 0x00154728 3回目: IShellLink::Resolve() を呼ばずに IShellLink::GetPath() を呼び出し。 0x001546e8
さらに、ディレクトリを変えたり別のアプリから呼んだりするとまた別の値が返ってきたりしているようだ。例えば、0x0018XXXX や 0x0012XXXX という値も返ってきている。0x00000008 や 0x00020000 以上のフラグは、上記 WIN32_FIND_DATA の説明にはない。0x00000008 はボリュームラベルを示すフラグだが、通常 Win32 では使われていないはず。0x00100000 がアドバタイズショートカットを示すフラグのように思われるが・・・。
後で、別マシンで試したら実行するたびに別の値が返ってきた。0x00100000 はアドバタイズショートカットのフラグではなさそう。
AviUtl の言語プラグイン (*.aul) のサイズを小さくできないか試してみた。サンプルのソースコードは、リソースファイルと TRUE を返すだけの DllMain() からなっているが、リソースファイルさえあれば十分な気がする。そこで link コマンドで /noentry オプションを指定してみたところ、アーキテクチャが不明との警告が出たが、一応プラグインファイルができあがった。AviUtl に読み込ませてみたところ、問題なく動作した。サイズは 1KB ほど小さくなった。
GanttProject 2.0.8 が出ているのに気付き、試してみた。相変わらず、PDF にエクスポートすると日本語が文字化けする。2.0.7 と同じ方法で、無事に文字化けが解消された。
SpringM 機能強化パッチを更新するために久しぶりに MASM を使っていたが、奇妙な現象に遭遇。jmp 命令部分で以下のエラーが発生した。
springm.2.asm(3112) : error A2075: jump destination too far : by 11 byte(s)
MASM で jmp を使うと、ジャンプ先との距離に応じて short jmp と near jmp を自動的に選択してくれるはずだったと思うのだが。アセンブルリストを確認すると、確かに short jmp ではジャンプできない距離だったが、jmp short LABEL という形式で書いていたわけではなく、jmp LABEL と書いていたので、near jmp が使われない理由が分からない。コードをいじってジャンプ先の距離を離したらどうなるか試してみたところ、距離 90h 以上だと問題なくアセンブルできた。もしかして MASM の距離判定部分がバグってる？
MASM のいくつかのバージョンで試してみたが、6.15 から 9.00 まで全て同じ挙動だった。このままでは困るので、とりあえず次のようなマクロを作って対処した。
; jmp near
jmpn macro dest
db 0e9h
dd offset dest - ($+4)
endm
jmp LABEL の代わりに jmpn LABEL と書けば、必ず near jump を使うようになる。
WDK でビルドする際に、DLLBASE をターゲットに応じて変更できなかったのは、sources ファイルの書き方が悪かったのが原因だった。例えば次のように書いておけば、64bit 版と 32bit 版でベースアドレスを別の値に設定できる。
!if $(AMD64) || $(IA64) DLLBASE=0x60012340000 !else DLLBASE=0x12340000 !endif
現状の ijexp32 のインストールには Admin 権限が必要だが、Admin 権限が無くてもインストールできるようにしてみようと少し試してみた。レジストリの書き込み先を HKLM や HKCR から HKCU\Software\Classes などに変更し、ファイルのインストール先を %APPDATA% などに変更したところ、Admin 権限のない WinXP でもインストールできるようになった。UAC オンの Vista でも試してみたところ、Admin 権限は必要ないはずなのに昇格ダイアログが出てしまった。アンインストールも試したところ、アンインストールが完了しなかったというエラーメッセージが出てしまった。一応ファイルやレジストリは消えていたようだが。
関連情報をいくつか。
以前入手した WDK (WDK 6000.16386) は、入手できなくなって久しいが、現在は Microsoft Connect に登録（無料）すれば、WDK 6001.18001 がダウンロードできる。（追加ドキュメントは登録不要の模様）
しばらく前に、Microsoft Connect に登録して、WDK 6001.18001 をダウンロードしてみた。まだインストールはしていない。WDK 6000.16386 は、2.4GB もあったのに対し、今回の WDK 6001.18001 は 600MB 程度であった。何がこんなに違うのかが非常に気になる。一般アプリの開発にも使えるかが特に気になるところ。
ijexp32 の 64bit 版のビルド環境として、WDK 6000.16386 を用いているが、WDK を使って Win2k 用バイナリをビルドできるか試してみたところ、mfc42_downlevel.obj が見つからないとのエラーが出てビルドできなかった。WinXP 用バイナリならば問題なくビルドできた。mfc42_downlevel.obj でググっても２件しか見つからず、有益な情報はなかった。WDK 6001.18001 だとどうなるか気になるが、まだ試していない。
build コマンドを使って DLL をビルドする場合、DLL のベースアドレスを設定するには sources ファイルに DLLBASE=0x12340000 などと書いておけばよい。しかし、 32bit と 64bit で別のベースアドレスを設定する方法が分からない。build コマンドを実行する際に、
> build -nmake DLLBASE=0x60012340000
などとすれば、ベースアドレスを個別に設定可能だが美しくない。良い方法はないものか。
ijexp32 の名前修飾解析部分で、const ポインタや volatile ポインタなどの解析が間違っていることが判明したため、修正した。ポインタのポインタや関数ポインタなどの対応にかなり苦労した。一応正しく解析できるようになったようだが、ソースがかなり汚くなってしまった。正しく解析できない構文もまだ１つ残っているが、簡単には対応できそうにないので放置する予定。
そろそろ、ijexp32 の改良は終わりにして、別のプログラムの改良を考えるか。
ijexp32 や名前修飾の関連情報収集中。
先月の spam メールの集計結果。着信拒否にならなかった spam が少なくとも 1139通。そのうち、@nifty の迷惑メールフォルダーでも Spam Mail Killer でも spam として認識できなかったものは 1通(0.09%)。