Outlook 2007とPreview HandlerとWOW64

Outlook 2007では、Windows Vistaのエクスプローラと同じPreview Handlerが利用できる。ただし、実のところ実装はいろいろと違うらしく、困った事態がいくつかある。

エクスプローラ上でのPreview Handlerは原則、低い整合性で別プロセスとして起動される

昔から、シェル拡張がエクスプローラをクラッシュさせるという現象が多く散見されたせいか、Windows Vistaでは、シェル拡張系(その他、さまざまなCOMインプロセスサーバーも)は、かなりが別プロセス(COM Surrogate)経由でインスタンス化されるようになった。このおかげで、理論上は、エクスプローラの不安定性は改善されるはずだったけど、実際にはそうはなっていないのは気になるところ。
また、これもシェル拡張に限られる話ではないのだが、デフォルトで低い整合性が指定される。これは、シェル拡張の気が狂って、いろいろなファイルを破壊したりできないようにするため。今では、ほとんどシェル拡張において、ファイルは、IStreamベースで渡される(もちろん、従来のファイル名によるアクセス方式も選択できるが、推奨されていない)ので、ファイルシステムにはアクセスする必要はなく、この低い整合性は非常に理にかなっている。なので、たとえば、サムネイルを作成するシェル拡張は、サムネイルを作っている対象の画像ファイルのファイル名すら取得できないし、そもそもそのファイルを自力で開くことはできない。これはセキュリティという意味で望ましいだけでなく、Outlookの添付ファイルなど、実はファイルではないものも透過的に処理できる可能性があるという点で非常に優れているが、一方で、画像へのリンクを張ったHTMLなどのように、外部のファイルに依存しないとレンダリングできないようなコンテンツには不向きである。そういう場合に限り、さっきも書いたように、整合性を上げて、かつ、ファイル名によるファイルアクセスを選択すればいいので、逃げ道は用意されているといえる。
ちなみに、Adobe Readerなどの場合は、フォントやいろいろなリソースにアクセスしないとPDFをレンダリングできないので、整合性は高めに設定して、IStream経由でファイルを読み込むのが筋なんだろう。たぶん。

Outlook 2007では、中間の整合性で別プロセスとして起動される

エクスプローラとは異なり、こちらでは中間の整合性(つまり普通の状態)として起動される。おいおい。上記で書いたことを覆すようなことをやってやがる。このあたり、プレビューハンドラを設計したやつは、Outlook開発チームにちゃんと説明できなかったんだろうなぁと思う。悲しい現実だ。

WOW64上のOutlook 2007

WOW64上でのOutlook 2007は、ちょっと変な挙動を示す。Preview Handlerをロードするに当たって、まず、自分のプロセス内でPreview Handlerを検証しているらしく、WOW64でロードできないPreview Handlerしかないと、Preview Handlerが存在しないという間違ったエラーを表示して、プレビュー表示しれくれない。
にもかかわらず、32-bitのPreview Handlerを登録しておいても、実際に実行されるのは、64-bitのPreview Handler。全く、挙動に一貫性がない。

結論として、Preview HandlerをWOW64経由でOutlookに使ってもらおうとすると、絶対に実行されることはないけど、32-bit版のバイナリも登録しておかないといけない。

余談

tasklistコマンドには、/Mという、特定のDLLをロードしているプロセス一覧を取得する機能がある。Process Explorerでも同様のことはできるが、コマンドプロンプトをすでに開いている場合には便利かも。

C:\Users\espresso3389>tasklist /M:fbpreview.dll

イメージ名                     PID モジュール
========================= ======== ============================================
prevhost.exe                  4164 fbpreview.dll