虚構人形廃棄場

自作のダイアログベースのプログラムが、英語版Windows XPでのみ動かない現象が発生したので調べてみました。

リソースをあれこれいじりましたが、コモンコントロールの初期化を忘れていたのが原因でした。


このおまじないは「コモンコントロールを使う場合は必要」と方々で注意されているのですが、日本語版Windowsでは2000以来ずっと、なくても動いていたので記憶に残らなかったのです。

しかしこうして現実に、英語版にて問題が発生したのでした。建前は偉大です。英語版Vista(Ultimateの言語切り替えではなく英語版)でも試してみましたが、こちらは大丈夫でした。


現象の詳細としては、CreateDialogが失敗、GetLastErrorが6を返します。ERROR_INVALID_HANDLEです。

WM_CREATEは来るのですが、その後WM_SETFONTの直後にWM_DESTROYが来てしまう、という流れでした。WM_INITDIALOGの前に終了します。

日本語版Windowsはどうして問題ないのか謎ですが、お約束は忘れると怖いという話でした。

3GBと4GBなんて違わないだろう、と64ビットWindowsの出始めの頃には思っていましたさ。当時はXPメインの時代、画像や動画を扱わなければ2GBで余裕でしたから。

しかしOSとアプリがメモリを食い尽くした後の余力ですから、そうした状況がひとたび発生すれば、スワップ(残量0)と1GBの比であって、倍率は計算不能のゼロ除算となります。

私とMacBookをそこに追い詰めたのはVisual Studio 2010でした。というわけでVS2010の使用頻度が上がったため、OSとHDDを強化しました。

Vista x86から7 x64へ。せっかく延命されたばかりでしたが、OS上のプログラムも多い立場なので、遅すぎたぐらいです。もう8がリリース間際、経費節減といっても自粛しすぎはダメですね。

250GB/5400rpmから750GBハイブリッド/7200rpmへ。出たばかりのSeagateのハイブリッドです。Mac側は120GBから160GBの微増としました。

使い物にならないレベルだったVS2010が、かなりまともになりました。次期版(2012?)ではもう一歩の高速化を期待したいところです。

電源投入からログオン画面までもかなり速くなったのですが、ログオン後が嘘みたいな速さです。ひょっとしたら64ビット版ウイルスバスターが速い、なんてこともあるかもしれません。

しかし、そうなるとまたタイミング問題が出るわけです。ログオン時タスクからのShell_NotifyIconで、FALSEなのにERROR_SUCCESS、何の関係があるのか不明なERROR_NO_TOKEN、この2パターンが新たに出現しました。

前者はともかく後者は何なのか。GetLastErrorの戻り値は判別せず、回数を制限してリトライするのが無難に思えてきました。

環境依存であるタイムアウトや回数制限を避けるとすれば、通知領域へのアイコン登録は後回しにして、登録できるまでウィンドウを表示してしまう(消すと終了できないため)ことになります。

真っ白ウィンドウでは格好が悪いので、いっその事スプラッシュウィンドウを登録できるまで常時表示するようにするのが、UIとしての妥協点でしょうか。

Windows 7でslnを「プログラムから開く」でVisual C++ 2005 Expressに噛ませたところ、以後VC++2005からしか開かなくなってしまいました。

何度「プログラムから開く」でVisual Studio 2008を指定しても、ダブルクリックするとVC++2005に行ってしまうのです。コントロールパネルの「関連付けを設定する」でも効果無し。

そういえばUACを求められなかったことを思い出し、HKEY_CURRENT_USERを探したところ、関連付け情報がありました。

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts

ここの.slnを削除したところ、無事に元に戻りました。恐らくVistaも同様の操作でしょう。

メールアドレスがgmailからHotmailに変わりました。無線APの_nomap騒動がちょっと癇に触りまして。

それでCERTUMのオープンソース開発者向けAuthenticode証明書を、少し繰り上げて発行してもらいました。

どうもシステムが改良されたようで、相変わらず最初のフォームはポーランド語なのですが、アンケート的なその最初さえ入力してしまえば、後は何とかなるようになりました。

名前、メールアドレス、電話番号、種別。その次がよくわからないのですが、業種でしょうか。そこから下はアンケートで、他に興味があるもの、どこでCERTUMを知りましたか、個人情報の使用に合意しますチェック、です。

最初の連絡メールもポーランド語ですが、そこには受付番号と入力の注意点(CNにOpen Source Developerが追加される、OにOpen Source Developerと入れること)があるぐらいで、本番の入力フォームは英語でできます。

次のメールにパスポートのスキャン画像を返信すれば万事完了です。

知りませんでしたが、考えてみれば当然です。OSがWPA2に対応しても、ドライバが非対応なら、接続はできないのでした。

先代サーバーであるFMV-610MG2を母用にセットアップしています。メモリが768MBなのでXPですが、SP3だからWPA2対応だとばかり思っていました。

無線LANカードはエレコムLD-WL54G/CB。アクセスポイントをWPA2と認識しているのに、一向に接続できません。どうもWPA2のAESはWPA時代のAESと少し違うのだとか。

ドライバを更新しようにもWPA2登場以前のものが最新です。そこで使えそうなドライバを捜してみました。Vendor IDが168Ch、Device IDが13hなので、チップはAtheros AR5213です。

チップ型番から検索すると非公式ドライバの配布サイトがあり、これを使うことで無事にWPA2でも使えるようになりました。

私が小さい頃、まだ蛍光管の電卓が現役でした。シャープのもので、メモリーの使い方が今と違うものでした。演算結果の総和を表示する"T"というキーがあったのみだと記憶しています。

さて、Windows 7で電卓が改良されたことが好評らしいのですが、私にはどうも合いませんでした。

16進も小数も頻度が変わらないものですから、関数とプログラマを分けられては面倒くさいのです。しかも切り替えがAlt+1などキー2つですし。

自宅ではあまり使わないので、会社MacBookがVistaの間は気にしなかったのですが、あっちも7になったので、何とかしてみました。

Vistaのcalc.exeは持ってくるのに注意が必要で、ja-JPフォルダ作り、その中にcalc.exe.muiを置かなければなりません。XPのcalc.exeは単体で動きました。

余談ですが、そういえばWindows 3.1の電卓にはバグがありましたっけ。パソコン通信で配布されたアップデートも懐かしい思い出です。

今期から日曜の起床時間が遅くなりました。スマプリに一話目で脱落したので。

相変わらず日曜美術館は見ているのですが、今日は佐藤忠良氏でした。

芸術の知識なんか元々ありませんから、この番組の大半は知らない芸術家を見ているわけですが、今日はさにあらず。福音館「おおきなかぶ」のイラストも手がけていたのでした。

小さい頃に読んでもらった記憶があります。あの絵が彫刻家の手によるものだったとは。他にも何冊もあるようですね。

記念館が宮城美術館に、今回の企画展が滋賀の佐川美術館、旭川の道立美術館、そして宮城。新幹線を使えば仙台はたかだか1時間半ですが、どうしたものか。

DeltaEndの改良も一段落というところで、後はNT4.0での動作確認をするのみです。

そういえば95/NT4.0にはシェル統合というものがありました。これをしないとShell32.dllが古いまま。しかしそのためにはIE4が必要で、さすがにネット上にはどこにも残っていないのです。

ところが収集癖が幸いし、手元に色々残っていることがわかりました。

まず、月刊I/O 1999年10月号付属のCD-ROM。Windows 98 SP1のために残しておいたものですが、これにIE4.01SP2が入っていました。この手の付録に付けるものは得てしてフルパッケージなので、これもNT4.0用が含まれています。

それと別に、2001年10月に配布されたMicrosoft Security Tool KitのCD-ROM。Nimdaが猛威をふるっていた頃のものですね。NT4.0 SP6aも入っていました。

他、FDメディアをMOに保存して一括インストールしていたことがあったのですが、それがPDになり、さらに5年前にCD-Rにコピーしたものもありました。
AmiPro R3.0Jとか、DOS6.2やWin3.1の98版・AT(/V)版、DFJ2/WIN 1.5、Win32s 1.25など。

素晴らしい。

その後Windows 7 x64環境で確認したところ、x86バイナリ・x64バイナリ共に再現せず。OSの違いなのか何なのか、と謎が深まってしまいました。

Visual Studioのデバッガにモジュールの一覧表示があったのに気付き、Vista x86で表示させたところ、shimeng.dllのアドレス範囲となっていました。Windows互換性テクノロジの中の人だそうな。

色々試した結果、slnファイルをUAC昇格して開くための自作ツールが原因だと判明しました。といっても、requireAdministratorなmanifestを持たせ、ShellExecuteExするだけの小さな小さなものなのですが。Vista環境でのみ、Send Toに入れて使っていたのです。

ファイル名に"launch"を含んでいると、問答無用で互換性テクノロジの餌食となるようです。互換性レイヤーを示す環境変数__COMPAT_LAYER=ElevateCreateProcessとありましたが、GetProcAddressに介入するのはWRPDllRegisterとかいうものだけではないのでしょうか。

インストーラー検出のinstall,setup,update,etc.とは異なり(他にpatchも)、今のところファイル名にlaunchを含むx86バイナリのみですが、Vista/7共にOSはx86/x64両方で再現しています。

asInvokerの中ILでも互換性レイヤーが入り込み、GetProcAddressをshimeng.dllに取られます。requestedPrivilegesがあってもダメということは、Vista以降用として作っても回避できない、ということです。

こんなテストコードを作りました。実行ファイル名を変えるとアドレスが変わることがあるのがわかります。
GetProcAddress.zip

昇格ランチャーのファイル名変更で回避できたのですが、真正面から行く場合、GetModuleInformationでkernel32.dllの範囲を取得し、その中にあるかどうかを確認して、外れていればLdrGetProcedureAddressする、という方法になるでしょうか。