WM_ほにゃらら クロニクル

一般的にウィンドウ・メッセージの解説というとイベントドリブンだのマルチタスクだの典型的な切り口に終始するものが多い.が,以前IMEの動作について調べているときに,面白い視点の文章を見つけた.
http://home.catv.ne.jp/pp/ginoue/im/
文章はIMEに関するX11R6とWindowsの比較がテーマであるが,比較によってWindowsのウィンドウ・メッセージの特性が鮮やかに浮かび上がっている.

  • Windowsではメッセージが比較的安い資源と考えられているらしい.
  • WindowsではOSのバージョンが上がるごとに新メッセージが追加されることがある.アプリケーションがこの新メッセージが理解できない(DefWindowProcに渡される)場合は,以前のメッセージに変換されたものが送られて来るように(アプリケーションには)見える.このように後方互換性を実現しているらしい.
  • 実際IMEの候補文字列確定処理では,WM_IME_COMPOSITIONをDefWindowProcに渡すとWM_IME_CHARが送られ,WM_IME_CHARをDefWindowProcに渡すとWM_CHARが送られてくる.

文字列の獲得

一見して、どうしようもないですが、backward-compatibilityはメジャーOSの宿命として、許してあげましょう。ちなみに、このメッセージを時系列と逆に見ていくと、MS-Windowsの進化の歴史をかいま見ることができます。最初は、WM_CHARでASCII文字と同じように扱おうとしたようです。しかし、流石に1バイトづつ送られてきてはやっていられない(実際、WM_CHARでは、やっていられません。メッセージ処理側で(上位バイトか下位バイトかの)状態を持つ必要があります)ということで、WM_IME_CHARで1文字単位でやってくるようになります。それでもやはりつらいので、結局、(X同様)APIで文字列を取得するという手法に落ち着きました。

教科書的な本には表向きのメリットしか書かれていないことが多い.実際私も昔C++言語の本に「同じ事を何度も書かなくてよいので,ヘッダファイルはとても便利なのです」と書かれていたのを真に受けて便利便利と唱えていたものだ*1.というわけでウィンドウ・メッセージ機構にはまだまだ語られるべき性質*2がある気がするのだが,そこんとこいい感じに突っ込んでいる本に今のところ巡り会えてない.
しかしまあヘッダファイルに定義されたWM_ほにゃららを全部列挙して概観するだけで一冊本書けるぐらいネタがありそうな気がするのだが,誰かやってないだろうか?

*1:後にファイル数の増加とともにコンパイルコストが急速に増大していく理由を考える頃になって,実はヘッダファイルって効率悪くねぇ? という視点をもてるようになる

*2:この辺興味がある人は,例えばSTAというCOMのアパートメントモデルがどんなもので,現在STAは廃れ気味なんだけどそれは何故か? などを調べてみると面白いかも.C#のウィザードが出力したコードにデフォルトで付いているSTAThread属性も関係有り.