PCの最近のブログ記事

何となく気になっていたのですが、先月半ばのエントリーからカテゴリが反映されなくなっていることがわかりました。

その頃に何をしたかと調べてみたら、Firefoxを16.0.1に更新したことでした(そういえば16.0.0は公開中止になったのでしたね)。確かにIEだと平気です。

あれこれ検索していくと、やはりFirefox側の問題(相性と呼ぶべきかも)で、既にパッチが出ていました。10月15日でしょうか？
http://www.movabletype.jp/faq/firefox-16-patches.html

差し替えファイルは2つで、4.292にも上書き可能だったようですが、せっかくなのでオープンソース版4.38に更新しました。セキュリティ修正もありましたしね。

私のは個人用ですし書き込み頻度も高くはないので、1ヶ月以上しても13件だけですから、手作業でカテゴリを設定し直せますが、ある程度の規模のサイトであれば大騒ぎだったでしょう...。

アップロード画像のフォルダもだったようですが、まあそれはいいや(ぉ

年初の(1)で書いた、WH_CALLWNDPROCRETで入れたら抜けないプロセスの話ですが、メッセージ専用ウィンドウかもしれません。

というのは、何気なく作ってみたら全く同じ挙動になったのです。メッセージ専用ウィンドウを持つアプリをMsgWnd.exe、ウィンドウプロシージャにグローバルフックを注入するアプリをProcHook.exeとして、

• ProcHook.exeが先に立ち上がるとDLLが注入される
• MsgWnd.exe先だと注入されない
• MsgWnd.exeを終了させてもDLLは開放されない

話は単純で、ブロードキャストのメッセージが届かないために、ウィンドウプロシージャが呼ばれずフックが外れないため、DLLが開放されない、ということになります。

またWindowsによるDLL注入時にも解放時と同様、ウィンドウプロシージャが呼ばれる必要があると言えそうです。
とすれば、MsgWnd.exeが後からの場合はWM_CREATEその他、生成時のメッセージによってDLLが注入されると説明できます。

結局、メッセージ専用ウィンドウを列挙する方法がないため、(2)に書いた解決方法は変わらないだろうと思うのですが、フックDLLの開放ぐらいはOSで面倒を見てもらいたいものです。

(2012/12/18追記)
FindWindowExでHWND_MESSAGEを指定してループを回せば列挙できるのでした。WM_NULLを投げれば目的は達成できそうです。

AntiDeviceの2.51を公開しました。

• リストのソート
• リストをクリックで範囲選択も可に
• 検索直後にホイールでリストをスクロール可に

内部は大幅に変更されていますが、表面上はこんな感じです。

ホームページ側のWin32コーナーにて。

DeltaEndの0.60を公開しました。

細かい改良と修正ばかりですが、同期動作クラスが大幅に改良されています。安定性に影響する部分の修正もありますが、基本的にはプログラマー観点からの細工が主です。

またTS Demux for D-VHS 0.9を公開しました。

こちらは時差情報をログへの出力ではなくwavの頭で調整するように変更した他、細切れになっているTSファイルで1秒未満は削除するようにしました。完了後にサスペンドなんてのも。

いずれもホームページ側のWin32コーナーにて。

バラして組み直したら息を吹き返したThinkPad X61 Tabletですが(ネジが1本足りませんでしたが)、その後液晶パネルに気泡が発生しました。

ネットで調べると他にも発生した方がいるようで、X61 Tablet固有の不具合のようです。

サブ機なのでそのまま使っていたのですが、昨日、接着剤か何かが漏れ出てきました。

ちなみに写真は剥ぎ取ろうとした後の状態なので、少しデコボコしています。

Tablet PCという奴の研究目的で購入したところもあった機種ですが、高かったのに何という仕打ちでしょうか。

もし今後Tablet PCを購入するとしたらキーボード配列が変わる前のX220 Tabletですが、はてさて。

Windowsにおけるコンソールアプリの標準出力が実は、コードページ932(MS-DOS OEM)をデフォルトとしている、と最近気付いたお話です。

何となく知ってはいましたが、何を意味するのかわかっていませんでした。これが理由でwprintf等を使ってさえ、setlocaleしないと日本語が表示できなかったのです。

さてこれまた最近、リダイレクトに興味を持ちました。Microsoftが提供しているサンプルがあるのですが、これのUnicode入力をどうしたものかと調べてみたのです。

その中で上記CP932を理解したのですが、子プロセスになるコンソールアプリをUnicodeでコンパイルしようと何しようと、親プロセスのReadFileには常に8ビットで文字が取得されました。

唯一違ったのがcmd.exe /uによるUnicodeパイプ出力のコンソールで(ただし内部コマンド限定)、このことは子プロセス側で対応できる(すべき)だろうことを示唆していました。

ならば標準関数以外の方法でUnicode出力すればよいはず、ということで見つけたのがWriteConsoleでした。コンソール系APIは触ったことがなかったので未知の世界です。

WriteConsoleを使えば、setlocaleしなくても日本語を表示できたのですが、説明にある通りリダイレクトされたハンドルには出力できませんでした。代わりに、WriteFileで親プロセスにUnicode文字列を渡すことはできました。

# WriteFileをコンソールに使うと、8ビット幅のつもりで
# 文字列を出力されるお馴染みの問題が出ます

最終的に、GetStdHandle(STD_OUTPUT_HANDLE)で取得されるハンドルをGetFileTypeに渡し、FILE_TYPE_CHARの場合にWriteConsole、そうでなければWriteFileすることで解決しました。

...いびつなOSですね。

8月末～9月頭にかけて、USB 3.0 LANアダプタが流通を始めたようです。

一つがSIIG JU-NE0211-S1、もう一つがStarTech.com USB31000S。共にUSD50ほど。後者はチップが明記されており、やはりASIX AX88179でした。

しかしMacBookを強化したため、デスクトップPCがすっかり埃をかぶり、買う予定はなくなってしまいました。

個人的にはそんなことよりThunderboltだったりとか。

Windows XP以降に実装されているUndocumentedなMessageBoxTimeoutというAPIが密かに知られていたらしいのですが、私は最近知りました。
で、これがuser32.libにも含まれていました。

というわけで、

#ifdef IDTIMEOUT
#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */
int WINAPI MessageBoxTimeoutA(HWND hWnd,LPCSTR lpText,LPCSTR lpCaption,UINT uType,WORD wLanguageId,DWORD dwMilliseconds);
int WINAPI MessageBoxTimeoutW(HWND hWnd,LPCWSTR lpText,LPCWSTR lpCaption,UINT uType,WORD wLanguageId,DWORD dwMilliseconds);
#ifdef __cplusplus
}
#endif /* __cplusplus */
#ifdef UNICODE
#define MessageBoxTimeout  MessageBoxTimeoutW
#else
#define MessageBoxTimeout  MessageBoxTimeoutA
#endif // !UNICODE
#endif // IDTIMEOUT

IDTIMEOUTはXP以降でだけ定義されるので、そのまま流用。
これは名前の通りタイムアウト時の戻り値ですが、MB_OKの場合は常時IDOKが返るので注意。

wLanguageIdはMessageBoxExの説明を参照。通常は0。

MessageBox系APIは全て内部でこれを呼んでいる(dwMillisecondsに0xFFFFFFFF)と書いているサイトもありました。果たして49.7日で閉じるか否か。恐らくWaitForSingleObject同様に無期限扱いになるのでしょう。

今さらXPより前もないですが、ないOSではフックを仕掛けてWM_INITDIALOGの中でSetTimerして、ということになるのでしょう。別スレッドからPostQuitMessageする方法は、親ウィンドウを指定した場合に固まるようなので。

拙作のウィンドウクラスに細工をしたらハマったというお話です。

きっかけはプロパティリスト(SetProp等のあれ)が遅い、と小耳に挟んだことでした。大したウィンドウを作るわけでもありませんが、更新頻度が異様に高いアプリは作ることがあるので、別の方法を試してみようとしたのです。

プロパティリストにはthisポインタを入れておき、メンバ関数でメッセージを処理するというお馴染みの使い方ですが、代わりといってもWTLみたいな頭おかしい実装は技量が及ばないので、静的std::mapにしました。

# 旧BorlandのVCLもWTLと同じ方法だったようですね

これを使って、PnPメッセージを処理するためダミーウィンドウを別スレッド上に実装した、ハードウェアを操作するクラスを書きました。

動作の確認としてコンソールアプリでグローバルに定義し、mainを抜けると...手元ではウィンドウクラスのオブジェクトよりstd::mapオブジェクトが先に破棄され、ウィンドウプロシージャ内でアクセス違反が発生してしまいました。

グローバルのオブジェクトは生成・破棄の順が規格上は未定義で、例えば何かのクラスに従属させるような制御方法もないとのこと。ちなみにマイクロソフトの場合、コンパイル時の出現順に生成し、破棄はその反対順だそうな。

「グローバル」というより静的な(staticに限らず)オブジェクトの寿命をコンパイラが区別できないという話らしく、静的メンバにしても意味はありません。

手っ取り早い回避法は、

1. プロパティリストに戻す
2. 後始末関数で明示的にDestroyWindowできるようにする
3. グローバルで定義せず、他の関数からはポインタ経由とする

といったところでしょうか。

ちゃんとやれば自然と3.になりますが、2.が無難なところでしょうか。デストラクタからも後始末関数を呼んでおけば(始末済みチェックの上で)、3.では明示的に呼ばずに済みます。

8月7日に受信したBKDR_ANDROM.JNQだったワームをウイルスバスターに検出させ直したところ、BKDR_SHELL.XWUAになっていました。

私はお盆前は8月10日まで出勤していたので、定義ファイルリリース日の8月9日と辻褄が合いません。休み明けの20日に初めて検出できたのですから。

ログを見ると20日の検出時の記録までBKDR_SHELL.XWUAになっていました。インデックス番号か何かの情報がずれでもしたか、それともトレンドマイクロは記録の改竄までするのか。

試しにMicrosoft Security Essentialsを入れたところ、7日のワームも22日に受信したワーム(翌23日になってもウイルスバスターは無反応)も、共にWin32/Gamarue.Iと検出しました。

業務規則上ウイルスバスターは外せないので、両方が検出すると競合(ファイルの奪い合い)が起こってしまいます。とりあえずMSEのリアルタイム検出を無効にして入れておくことにしました。

で、MSEといえば定義ファイルの更新がかかりにくいので、タスクから更新コマンドを叩くのが定番です。私も作ってみました。「最上位の特権で実行する」が必要です。
MSEUpdate.zip

MSEのパスはレジストリから取り出しています。見つからなかったらイベントログにエラーを記録して終了。レジストリの場所にMpCmdRun.exeがない場合、64ビット版Windowsで32ビットプロセスから呼ばれた場合がそれですが、こちらはエラー表示のみとしています。