32bitプロセスと64bitプロセス間で通信する手段は、いろいろあるらしい。
Interprocess Communication Between 32-bit and 64-bit Applications
そのうちのひとつに、32bitのCOMサーバー1つで、32bit/64bit両プロセスからのアクセスに対応できるというものがあるらしい。しかも、既存のDLLをCOMでラップしてやることにより、対応することもできるという。ていうか英語しかなく、日本語の資料がないんだな、だから日本に知られづらい。それか、なんかセミナーとか行けば知る機会があるのかも。
Microsoft 64-bit Computing overview
Process Interoperability
Designing 64-bit-Compatible Interfaces
Windowsの32bit/64bit過渡期において、COMのこのテクニックはとても重要になってくるだろう。たぶん。なんかRPC(Remote Procedure Call)のメカニズムを使うらしい。だからRPCのサービスを止めちゃダメ。
まとめ
・64bit Windowsにおいて
- 32bit processは32bit DLLをロードできるが、64bit DLLをロードできない。
- 64bit processは64bit DLLをロードできるが、32bit DLLをロードできない。
- 32bit processと64bit process間でRPCがサポートされている。(同じマシン内や,別マシン間)
- 32bit COM server processは32bit/64bit client processと通信できる。
- 64bit COM server processは32bit/64bit client processと通信できる。
従って、既存のCOMでない32bit DLLをCOM server processでラップし、64bit processからも利用可能にすることができる。
・可能なリンク
- 32bitDLL <-(DynamicLink)-> 32bit proceess
- 64bitDLL <-(DynamicLink)-> 64bit proceess
- 32bitDLL <-(Link)-> 32bit COM server process <-(RPC)-> 32bit/64bit process
- 64bitDLL <-(Link)-> 64bit COM server process <-(RPC)-> 32bit/64bit process
・つまり32bit/64bit COM server processであれば32bit/64bit環境すべてに対応できる。
- Windows x86上で32bitアプリ(つまりWIN32)から使う
- Windows x64上で32bitアプリ(つまりWOW64)から使う
- Windows x64上で64bitアプリ(つまりWIN64)から使う
- 別のマシンから使う
デメリットは、独立プロセスになることでメモリ消費が増えるとか、RPCによるパフォーマンス低下とか。パフォーマンスを問題にするならネイティブで32bit版と64bit版の両方を作ってそれぞれインストールしてもらう事になる。たとえばJRE(Java Runtime Environment)なんかはそうなっている。その辺は、パフォーマンス、インストールしやすさ、サポートしやすさ、等の要素のトレードオフになると思う。
なんかOS側でサポートすればいいのにな、32bit DLL資産のCOMによるラップで64bitプリケーションから利用するメカニズム。既存のDLLのヘッダファイルから、そのラッパーのCOMを自動生成するジェネレータが作れそうな気がする。visual studioのプラグインとして作るとか。無理かな？
COM serverのEXEのほうは、クライアントとは別の独立したプロセスになり、proxy/stub経由で通信する(RPC)。COMをDLLで作ると、クライアントプロセスの中にロードされて動く。でもDLLでも、代理プロセス(SurrogateProcess)を使えばRPCにできるらしい。
COMの知識は、まだ浅いです。
