フォルダ画面の背景を右クリックしたときのコンテキストメニューを出してみようとしたのだが、どうもうまくいかない。一応メニューは出るのだが、メニューの一番下に余計なセパレータが表示されたり、「元に戻す」や「コマンドウィンドウをここで開く」などが動作しなかったりなど、少しおかしい。少し調べたもののよく分からなかったので、そのままの状態で SpringM に組み込んでしまった。
iPod nano (8GB) をもらった。色がオレンジというのがびみょー。iTunes 8.0 が必要なようだが、7.5 しかインストールしていない。
SpringM の機能拡張をするために、springm.dll の呼び出し口を新たに一つ追加しようとしたのだが、インポートテーブルに空きがない。テーブルをずらして空きを作ることもできなくはないのだが、少し面倒だ。それに、この方法では今後の拡張性がない。
今後の拡張性と実装の手間を考えて、独自の方法で動的リンクを行うことにした。springm.exe には、関数ポインタの配列へのポインタをグローバル変数として用意しておき、springm.dll がロードされたときに、そのポインタを DLL 内部に用意した配列を指すように直接書き換えてしまうようにした。DLL から EXE 内部のメモリ空間をアドレス直値指定で書き換えるなんて、もはややりたい放題。エラーチェックが弱いのが難点か。
評価目的に限定するならば「TechNet Plusサブスクリプション」で各種 MS 製品を（MSDN と比較すると）格安で入手できるようだ。「MSDN サブスクリプションの比較 - やや温め納豆」経由で知った。
なお、その記事には MSDN で入手した OS が使えるのは契約期間中のみであるように書かれているが、実際には「Visual Studio with MSDN Subscription - よくある質問」の No.6 にあるように、MSDN の契約期間が終了してもそのまま使用できる。
CoFreeUnusedLibraries() という API を知った。COM 関係の DLL で使っていないものがあれば、これを呼ぶことで解放されるようだ。
コンテキストメニュー関連情報と関連 API のメモ。
複数ファイルのプロパティを表示する方法を調べてみた。SHMultiFileProperties() という API があるようだ。元々は隠し API だったようだ。
SHMultiFileProperties() を使わずにやるには、おそらくコンテキストメニューから呼び出すことになるのだろう。コンテキストメニューを扱う方法を調べてみた。
WDK のデフォルトの Makefile を見ていたところ、セクションがマージされる設定になっていることに気付いた。/merge:.rdata=.text オプションが指定され、.rdata セクションが .text セクションにマージされるようになっている。.rdata は、read-only data ということで書き込み属性が必要ないので、.text とマージしてしまっても問題ないということか。
undll.exe ではサイズを小さくするため、.rdata だけでなく、書き込み可能な .data セクションもマージしてしまったが、そのままでは実行できなくなってしまう環境がある。そこで、書き込み属性を付加するために、/section:.text,erw オプションを指定している。もっとも、安易に .data をマージしてしまうと、逆にファイルサイズが大きくなる場合がある。
WDK で .rdata を .text にマージしているのはどういう理由だろうか。
cl.exe のバージョンを調べてみた。
| 環境 | バージョン |
|---|---|
| WDK 6000.16386 | 14.00.50727.215 |
| WDK 6001.18001 | 14.00.50727.278 |
| WDK 6001.18002 | 14.00.50727.278 |
| Windows SDK 6000.16384 | 14.00.50727.762 |
| Visual Studio 2005 SP1 | 14.00.50727.762 |
| Windows SDK 6001.18000 | 15.00.21022.08 |
| Visual Studio 2008 SP1 | 15.00.30729.01 |
玄箱のファンがうるさい。ばらしてみたところ、かなり埃がついていた。綺麗にしたが相変わらずうるさいので交換することにした。
どのファンにするか迷ったが、結局以前と同じ製品を購入。交換したところ、なぜかかなりうるさい。確認すると、kurofand.pl が動作していなかった。動作させたところ、そこそこ静かになったが、本当はもっと静かになって欲しいところ。
ワイヤレスマウスの RaFeel に不満があったため、新たにワイヤレスマウスを購入することにした。以前購入した V450 はなかなか良かったので、今回は後継の V450 Nano を購入した。外見は V450 とほとんど変わらない。使い勝手は全く変わらない。V450 のようにチャタリングが発生しなければよいのだが。
ijexp32 を WDK でコンパイルしたときにサイズが大きくなる要因を引き続き調査。スタックのチェック（バッファオーバーラン等）が強化されている点が異なっているようだ。WDK でコンパイルすると /GS オプションがデフォルトでオンになっている。/GS をオフにしてコンパイルしてみたところ、サイズが 75KB まで小さくなった。それでも、VC6 でコンパイルしたときに比べて 7KB 大きいが、要因は不明。
せっかく WDK 6001.18001 をインストールしたばかりだというのに、既に WDK 6001.18002 が出ていたようだ。早速ダウンロードしインストールしてみた。コンパイラのバージョンは 6001.18001 と全く同じだった。
Windows XP ビジュアル スタイルの使用によると、DLL などでビジュアルスタイルを使用する場合は、SIDEBYSIDE_COMMONCONTROLS を define してコンパイルすればよいとある。しかし、最近の Windows SDK を見てもこれに関するコードが無い。CodeProject: The Complete Idiot's Guide to Writing Shell Extensions - Part II によると、SIDEBYSIDE_COMMONCONTROLS ではなく、ISOLATION_AWARE_ENABLED になったようだ。
参考サイトをいくつか掲載。
VC6 に WinXP 対応の Platform SDK をインストールせずにビジュアルスタイルを使用するようにしてみようかとも思ったが、大変そう。msvcrt.dll を使用しつつ、ビジュアルスタイルを使用するには WDK でコンパイルするのが楽か？
ijexp32 をビジュアルスタイルに対応させようと思い、WDK でコンパイルしてみた。ijexp32.dll のサイズが、VC6 に比べてかなり大きくなってしまった。x86 Unicode ビルドの場合、VC6 では 68KB だったものが、WDK では 90KB になった。ちなみに、x64 ビルドでビジュアルスタイル対応のため ISOLATION_AWARE_ENABLED を有効にした場合は、126KB だったものが 129KB に増加した。これから類推すると、x86 Unicode ビルドでの増加のうち、約 19KB はコンパイラの変更による増加と考えられる。
コンパイラの変更で何が増えているのか少し調べてみた。まず気がついたのは、WDK でプログラムをコンパイルすると、デバッグ情報 (*.pdb) へのポインタがファイルの中に書き込まれる点。ただ、この情報は数十バイト程度でサイズ的には大したことはない。他の要因については調査中。
しばらく前にダウンロードした WDK 6001.18001 をインストールしてみた。以前の WDK 6000.16386 と比較するとメディアの容量はずいぶん小さいのだが、インストール後のサイズはおよそ 1.6GB となり大差ない。
MFC を使ったプログラムを Win2K 向け環境でビルドしようとすると、mfc42_downlevel.obj が見つからないとのエラーが出るのは全く変わっていなかった。
WDK の lib ディレクトリを確認すると、WinXP 以降の MFC のライブラリファイルは lib\mfc 以下にあるが、Win2k 用の MFC のライブラリファイルは lib\w2k 以下にある。Win2k の場合は、lib\mfc\i386\mfc*.lib を使うのではなく、lib\w2k\i386\mfc*.lib を使うようにすれば、mfc42_downlevel.obj が無くとも問題ないのではないだろうか。早速試したところ、Win2k でも動作するバイナリができあがった。
少し前の DDK を確認したところ、Win2k の MFC ライブラリファイルは、WinXP 以降とは別になっている点は今と同じだった。しかし、Win2k 向け環境でも実際に参照されるライブラリは WinXP 以降のものと同じ設定になっていた。何のために Win2k 向けだけ別ファイルになっているのか不明だ。
先月の spam メールの集計結果。着信拒否にならなかった spam が少なくとも 773通。そのうち、@nifty の迷惑メールフォルダーでも Spam Mail Killer でも spam として認識できなかったものは 3通(0.4%)。誤削除が 1通。