虚構人形廃棄場

GetProcAddressはGetProcAddress自身のアドレスを正しく取得できないことがあるようです。どうもUACで高ILにしたデバッガー下だと違うアドレスが返っています。

どうしてCreateRemoteThreadがロジックボムになるのかと思ったら、なんという罠でしょうか。

環境はVista x86、Visual Studio 2008 SP1。

関係あるのかないのか、ntdll.dllのUndocumentedなLdrGetProcedureAddressだと正しく取得できるという情報があり、試してみるとその通りでした。

単独で実行させる限り大丈夫なら、UndocumentedなAPIに手を出すこともありませんが、常時正しく動いてほしいのが本音です。

C文字列ではなくANSI_STRING構造体でAPI名を渡すので、RtlInitAnsiString/RtlFreeAnsiStringも使う必要があります。モジュールハンドルはLdrLoadDLLではなくLoadLibraryのもので大丈夫のようです。

ダミーウィンドウを作らせるだけですから、GetModuleHandleでuser32.dllの存在を確認した上で、DllMainから作ってしまうのが楽ではあります。

しかし「のどか」にて、これは共用メモリの話ですが、Adobe Readerという全くのGUIアプリでエラーが発生したことを考えると、ロードされていてもDllMainからuser32.dllのAPIを呼ぶのは危険かもしれません。

Windows Vistaおよび7のHome系製品が延長サポート対象になったようです。

Windows Vistaサポートライフサイクル
Windows 7サポートライフサイクル

Vistaの残り2ヶ月足らずで突然の方針転換。粘っていた人は嬉しいでしょうが、既に更新した人は恨むでしょう。今やPCはただの道具であって、維持費はかけたくないのです。

そういえばXPのサポート切れをカウントダウンするガジェットなんてものが昨年4月にリリースされましたが、ガジェットというカジュアルな手段(しかもXP非対応)に訴えるなら、Vistaの方が先ではないかと思ったものです。

この延命はいつ頃から確定路線だったのか、と勘ぐってしまいます。

私の仕事PC(MacBook MB062J/B)はVista Ultimateなので救済されましたが、Visual Studio 2010には非力なので、できれば本体ごと新しくしてほしいなあ...。

AMFMラジオ録音さんのlame MP3で、再生ピッチが一定しないような感じがしたので(細かい音飛び？)、試しにaac Pipeに切り替えたのです。まあ、録音時のハードウェアの問題でしょうが。

ところがこれは生AACなので、iTunesやiPhoneで再生できないのですね。

そこでMP4Boxでm4aに変換したところ、QuickTime Playerで「不正なサンプル記述」というエラーが出てしまいました。Windows Media Playerは通りますがiPhoneではやはり再生できません。

iOSは中にQuickTimeと同じものが入っているので、QuickTime Playerはテスト環境として有用です。どうやらMPEG-2扱いされたのが問題だったようで、MPEG-4に強制することで回避できました。

mp4box -add <input.aac>:mpeg4 <output.m4a>

faacにオプション-wを追加して直接出力させたm4aは、QuickTime Playerでも再生できたので、録音時に使うならこちらでしょうか。

しかしいずれも音飛びは悪化してしまいました。そういえばHandBrakeの時にも音飛びしていました。faacは音質以前に音飛びが問題です。

DeltaEndに元々のVJE-Delta 4.0対応機能を組み込み直しているのですが、そういえばNT 4.0ってどんなだったっけ、と気になったので仮想PCに入れました。

Windows 95相当のUIで、実はPnP非対応、Windows Updateも無し。ブリーフケースや受信トレイが懐かしいですが、常用した時期は短いです。

無断でWindows 2000 β3にして仕事をするというアホなことをしていたためですが、幸運なことに不具合には遭遇しませんでした。

で、NT 4.0です。Service Pack 6aの配布がもう終了しているのですね。sp6full_i386.exeというファイル名で探してきたものを入れて何とか対応。これがないとVMWare Toolsが入りません。幸いInternet Explorer 6はまだ普通に手に入りました。

MacBook Proのファンが回り始めて何事かと思ったら、当時は省電力機能がなかったのを思い出しました。ですので割り当てたコア数が100%貼り付きっぱなしになります。今となっては引退させないと電気の無駄でしょう。

ImmDisableIMEってWin98/2000以降だったのね、とDeltaEndのコードfixはもうちょっと先の話です。

なかなか更新されないので、Workstationからもらうことにしました。

まずはVMware Workstation 8.0.2をダウンロードして解凍します。

VMware-workstation-full-8.0.2-591240.exe /e <解凍先フォルダ>

"tools-"で始まるファイルがVMWare Toolsです。例えばWindows 2000以降用ならtools-windows-8.8.2.exeを実行すれば、無事にVMWare Playerのフォルダの中が更新されます。

OpenProcessしてEnumProcessModulesしてDLLのハンドルを取得し、CreateRemoteThread経由でFreeLibraryに渡すという手がありました。

が、次にウィンドウが生成された時に、同じDLLがWH_CALLWNDPROCRETフックに指定されていると(つまりフックを使用するそのアプリがもう一度起動されていると)、アクセス違反で落ちました。

呼び出し履歴によるとCreateWindowから最終的にDispatchHookWで落ちており、名前からすると何事もなくフックを呼ぼうとしているのでしょう。DLLは開放できてもフックの状態は解除できなかったと推測されます。

となると何とかしてウィンドウプロシージャを呼ばせる、つまりCreateRemoteThreadからCreateWindowするしかありません。どんどんイケナイ道に踏み出している気がします。

LoadLibraryさせたDLLで、隠しダミーウィンドウを一瞬生成(WM_CREATEでDestroyWindow)すると開放できました。最初は論理試作としてDllMainでやったりしましたが、もちろん危険なのでエクスポート関数に実装しなければなりません。

コード注入だけで行なうのは無理そうです。CREATESTRUCTのlpCreateParams経由で受け取ったアドレスを、保存しておく場所がないためです。静的な変数が一切使えず、それがなくてはDefWindowProcすら呼べないのでは、ウィンドウプロシージャの実装は無理でしょう。

ウィンドウを生成するためにはRegisterClassする必要がありますが、クラス登録は相手プロセスの中ですから、同名クラスが既にあれば重複エラーとなります。時刻等を組み合わせてリトライする方向になるでしょうか。

台湾ASIX社からUSB 3.0対応GbEコントローラが発表されていました。1月3日のことです。
ASIX Releases the World's First Single-Chip USB 3.0 to Gigabit Ethernet Controller

現在サンプル、第一四半期の終わりに量産開始だそうなので、早ければ今年半ばぐらいに周辺機器として出回り始めるでしょうか。

PCI-Expressが1つしか使えず、しかも100BASEしかない廉価スリムPCで使い途があるでしょう。私の会社デスクトップPCがそれで、現在GbEで埋まっています。

GbEを維持しつつ高速な外付けHDDを接続するとしたら、USB 3.0経由しかないだろうと妄想していたところでした。

USB 2.0はともかく100BASEしかないスリムPCは今も販売されていたりします。ようやく救世主が現れました。

通知の設定でメールの「ロック中の画面に表示」をONにしたところ、i.softbank.jpが受信もできるようになりました。従来通りの緑ボタンの受信通知の直後に、実際に受信します。

またこれと同期したかは不明ですが、米Yahooメールもプッシュで受信できるようになりました。

こういうところが日本的には不親切ですが、何となく解決してしまうのは良いところでしょうか。マニュアルがないので、直接サポートとユーザーコミュニティにお任せ。

プッシュが利けばキャリアメールは不要です。SIMロック解除かSIMフリーかの決断まであと半年。

4.0.2が出たのですが、まだVMWare Toolsがありません。

Windows版の場合で下記の場所に4.0.1用があります。

http://softwareupdate.vmware.com/cds/vmw-desktop/player/4.0.1/528992/windows/packages/

Windows 2000以降用はtools-windows-8.8.1.exe.tarなので、これをダウンロードして解凍してインストールすると、一つ古いですがとりあえず入ります。

サポートフォーラムによると数日内に対応されるということでした。

DeltaEndでも使っているメッセージフック(WH_CALLWNDPROCRET、ウィンドウプロシージャ戻りフック)はDLLをプロセスに注入します。

開放されるタイミングは、UnhookWindowsHookExした後にウィンドウプロシージャが呼ばれた時だという話なのですが、開放されないプロセスがあるので調べてみました。

ehmsas.exeとjusched.exeの2つで、Spy++で見ると共にウィンドウがありません。前者はWindows Media Centerのモジュールで、ehtray.exeからCOMとして呼ばれています。後者はJavaのアップデート。

ログオン時タスクからでのみ発生し、起動後はタスクの手動起動でもDeltaEnd.exeの直接起動でも再現しません。

ログオン時タスクの起動はとても早いので、ひょっとして最初はウィンドウがあるんじゃなかろうか(少なくともjusched.exeはCreateWindowExAを使っている)、というわけで検証用のコンソールアプリを作ってみました。

WindowWithConsoleApp.zip
"w"入力でウィンドウを作り、"q"で終了します。ウィンドウを閉じるまでキー入力が利きません。

ProcessExplorerで監視してみると、最初は何をしても変化ありませんが、ウィンドウを作ると同時にDeltaEndDll.dllが入り、閉じてもそのままと見事に再現できました。

ウィンドウがなくなっても開放されるわけではなく、その場合はあくまでプロセス終了時の開放処理に任されているようです。ウィンドウ破棄後も動作するアプリは想定外なのでしょう。

DllMainでプロセス名を判別してFALSEを返し失敗させる、という方法は考えられます。しかし汎用的な方法はちょっと思いつきません。

他、Firefoxのplugin-container.exeでもたまに起きています。こちらもウィンドウがない場合ですが、このプロセスを除外するとIETabやFlash内に干渉できなくなるので、一度Firefoxを閉じて対応するしかななさそうです。