保護モードと IME
Windows アプリケーションに，統一的な "Protected Mode" (保護モード)の仕様や基準といったものはありません．保護モードと呼ばれている各技術の実装は製品ごとに異なります．A という製品の「保護モード」を有効にした状態で IME が動く(ように見える)からといって，B という製品の「保護モード」を有効にしても同じ IME が動く(ように見える)とは限りません．
例えば，Google Chrome は，ウィンドウ処理を行うブラウザプロセスと，HTML のレンダリングを行うレンダラプロセスを分けており，Chrome の保護モードが適応されるのはレンダラプロセスの方です．IME はウィンドウ処理が行われるブラウザプロセスに読み込まれるため，IME にとっての Chrome は，(プラグイン周りをいったん忘れることにすると) メモ帳などと同じただのデスクトップアプリケーションです．
UAC が有効な環境での Microsoft Internet Explorer は，整合性レベルが Low に設定されたプロセスでウィンドウ処理と HTML のレンダリングを実行します．IME はウィンドウ処理を行うプロセス内に読み込まれるので，IME は整合性レベル Low のプロセスで動作する必要があります．なお，Internet Explorer は，整合性レベルを Low にする以外ほとんどプロセスの設定を変更しないため*1，メモ帳を PsExec の -l オプションで起動して IME のテストをするだけでも十分有用です．
Adobe Reader や Firefox 版 Adobe Flash Player の「保護モード」はというと，Chrome の Sandbox 関連の技術を利用していることが Adobe から公表されています*2．Chrome とは異なるのは，ウィンドウ処理を行うプロセス自体を Sandbox 内で実行するということです．このケースでは，IME は Sandbox 化されたプロセス内で動作することになります．
| アプリケーション | IME の動作環境 |
|---|---|
| Google Chrome | メモ帳等と変わらず |
| Microsoft Internet Explorer | 整合性レベル Low |
| Adobe Reader X | Sandboxed process |
なお，ブラウザプラグイン特有の IME 関連の問題についてに関しては (基本的に) 今回は扱いません．
*1:他には，HKCU のマッピング が行われたり
*2:たとえば http://blogs.adobe.com/asset/tag/sandbox 内にもいくつか言及が見られます
整合性レベルに基づく保護モード
整合性レベル導入による互換性上の影響は，大まかに次の 2 つに分けることができます．
1. アクセス権不足によるリソースアクセスの失敗
2. ユーザーインターフェイス特権の分離 (UIPI) による，プロセス間通信の失敗
前者について，整合性レベルは OS 標準の ACL の上に実装されており，その実装についても詳細なドキュメントが存在します．
後者については，主にウィンドウシステムとウィンドウ間の通信に関する仕様変更で，こちらも詳細にドキュメント化されています．
互換性上の問題に直面したとき，開発者は，整合性レベル Low のプロセス用に専用の設定ファイルを用意したり，カーネルオブジェクトの ACL を変更して整合性レベル Low のプロセスからもオープンできるようにしたり，UIPI の例外を登録したりといった回避策をとることができます．
Chromium Sandbox を用いた保護モード
Chromium Sandbox は，乱暴に言えば
- 対象プロセスの権限や動作をとにかく制限する
- それだと目的の動作もできなくなることがあるので，本当に必要な処理についてはより強い権限を持ったプロセスで代理処理する
という二段構成になっています．
2. の代理処理は，Sandbox 化されたプロセス内での API 呼び出しをフックして行います*1．悪意のあるコードが API フックを回避し，本来のシステムコールに到達した場合，プロセス本来のアクセス権限によるチェックが行われます．このケースまで想定して，前者の「とにかく」のレベルが決まります．
1. の制限は強ければ強いほど良いため，Chromium Sandbox では，先ほど出てきた整合性レベルに加え，プロセスのアクセストークンからの権限削除，Job を利用した制約，デスクトップ分離などさまざまなテクニックが使われています．実際には，アプリケーション本来の目的を阻害するような制約は諦めざるをえないため，アプリケーションごとにどの制約を組み合わせるかを選択します．Adobe Reader のケースでは，一部の設定について PC 管理者がカスタマイズすることを許可しています．
Adobe Reader に関しては，次の文献などで詳細な解析が行われています．
http://media.blackhat.com/bh-us-11/Sabanal/BH_US_11_SabanalYason_Readerx_WP.pdf
Chromium Sandbox のような特殊な環境で IME が動作しているとき，正常に動作しているかどうかを判断するのは難しいものがあります．多くの場合，プロセスを起動するような操作しばしば失敗します．これは，辞書ツールや文字パレットが別プロセスとして実装されているケースでは明らかになるでしょうが，これらのツールが対象プロセス内に表示されるウィンドウとして実装されている場合には表面化しないかもしれません．IME の確定履歴がディスク上に書き込めないというケースもあります．Process Monitor でのログを見るだけで問題が明らかになることもありますが，いずれにせよ IME についての理解は必要です．
*1:AdHoc なルールを透過的に適応するという点では Windows の互換性スイッチに似ているとも言えます
Metro スタイルアプリケーションと IME
Metro では，AppContainer という特殊な環境でアプリケーションが実行されます．IME DLL は *1，対象の Metro スタイルアプリケーションプロセスに読み込まれ，AppContainer の管理下で動作することが求められます．
実際，Microsoft は Windows 8 Release Preview の公開に合わせ，Guidelines and checklist for IME development (Metro style apps) というガイドラインの提供を開始しました*2．同ドキュメントには，AppContainer 内で IME の機能を実装する上で，次のようなケースに注意せよとあります．
- 辞書ファイルの置き場所
- インターネットを利用したアップデート
- 学習機能
- プロセス間での(設定や学習)情報の共有
同ドキュメントには，IME の学習機能や，プロセス間での(設定や学習)情報の共有機能の実装方法として，その AppContainer で可能であればウェブサービスを経由してこれらの機能を実装するよう書かれています．Mac や Android のように IME プロセスを分離してくれていれば，IME 単体に別のアクセスコントロールを適用することも可能だったのでしょうが……
なお，Metro アプリケーションとデスクトップアプリケーションでは，利用可能なテクノロジに違いがあります．詳細については API reference for Metro style apps から辿ることができます．Metro 対応 IME では IMM32 ではなく TSF を使う必要があることはガイドラインで明記されていましたが，その他の API についてははっきりとは書かれていません．公開されると言われている Metro 対応 IME サンプルでも読まないとはっきりしない予感がします．
なお，こうして作られた IME DLL は，従来のデスクトップアプリケーションに読み込まれても動作する必要があります．まさに Run Anywhere，Universal Binary というわけです．
