Windows XP SP2（32ビット）とWindows 7 64ビットの両方に対応するシェル拡張（コンテキストメニューハンドラ）を開発したいと考えています。Windows 7で32ビットシェル拡張を使用する64ビット
64ビットWindowsで32ビットシェル拡張を実行することはできますか？または、Windows 7 64ビットで使用するためにシェル拡張を64ビットに移植/再構築する必要がありますか？
64ビットオペレーティングシステムで32ビットシェル拡張を使用する際に、不都合な点や既知の問題はありますか？
32ビットアプリケーションは64ビットWindowsでうまく動作しますが、私の理解が正しい場合はシェル拡張がin-procのCOMサーバーがエクスプローラプロセスに読み込まれるため、これは64ビットWindowsで64ビットプロセスでなければなりませんか...または64ビットOSで動作する32ビットシェル拡張のために提供される "32ビットエミュレーション"の形式ですか？
シェル拡張は単なるDLLであり、32ビットアプリケーションは32ビットDLLのみをロードでき、64ビットアプリケーションは64ビットDLLのみをロードできるというルールがあります。これを回避する方法はありません。
32ビットシェル拡張は、シェル拡張をロードする32ビットサードパーティアプリケーションが動作するため、64ビットシステムでも有効です。たとえば、TortoiseSVNは32ビット版と64ビット版の両方に同梱されているため、64ビット版のWindowsでは、サードパーティのファイルマネージャなどの32ビットアプリケーションからTortoiseSVNコンテキストメニューにアクセスできます。
しかし、エクスプローラ自体は64ビットWindows上で64ビットネイティブであるため、エクスプローラで動作させたい場合は、64ビットバージョンの拡張が必要です。
シェル拡張はCOMコンポーネントです。アウトオブプロセスサーバーとしてインストールする場合、Windows（DCOM）はすべて32 < - > 64ビットマーシャリングを処理する必要があります。
MIDLコンパイラは、処理中にロードされる64ビットスタブを作成します。
それは実際にはそのようには動作しません... –
それは間違っています。コンテンツメニューハンドラはインプロセス拡張であり、アウトオブプロセスとして実装することはできません。 https://msdn.microsoft.com/en-us/library/windows/desktop/dd758089(v=vs.85).aspx。分散COM（DCOM）は適用されません – MickyD
@あなたのリンクはあなたの主張をサポートしていません。別の参照がありますか？ –
64ビットWindowsではxplorer²のような32ビットエクスプローラを使用できます。彼らは、コンテンツの検索、データのプレビュー、コンテキストメニューの表示などに使用できる32ビットのDLL拡張を処理できます。組み込みのエクスプローラは64ビットで、32ビットの拡張機能は無視されます。
オプションはありません。 x64ターゲットに加えてWin32ターゲットを使用する別の構成をプロジェクトに追加するだけです。あなたのコードがきれいであれば、あなたのDLLのx86版とx64版の両方を生成するのに問題はありません。 –
@HansPassant：正当な答えのように聞こえます。 –
@HansPassant：32ビットと64ビットのシェル拡張に_別のGUIDがあるべきかどうかも疑問です。 –