DotConnect/SharpConnect

どっちにしろXPCOMべったりなC++コードを書かないといけなそうなことははっきりした。とすれば、.NET FrameworkXPCOMの相互運用レイヤを作ってやるのが妥当な手段だと考えられる。PyXPCOMとかBlackConnectみたいなやつ。やっぱりやってる人居ないのかな…(謎
MonoプロジェクトでもCOMやXPCOMとの相互運用性については考えてたみたいだけど、XPCOMとの相互運用性は実はかなり絶望的なものであるって言うことは昨日の日記でも書いたことからわかっている。つまり、利用するXPCOMライブラリのコンパイラとMonoをコンパイルしたコンパイラが違うだけで、XPCOMコンポーネントが利用できなくなるというわけ。xptcallのような相互運用性をもたらすコードをMozilla側に入れなければならないと言うことだと思う。
まぁ、とりあえず実現の方法を考えてみることは、少なくとも頭の体操という意味では価値があるということにして、少しずつ考えてみる。
まずは、XPCOMC++JavaScript(、JavaPython)など複数の言語をサポートしている仕組みについて、俺の理解を整理していきたい。俺の現時点での理解なので、間違っている可能性は十二分にある。
XPCOMでは、要するに、メモリ上にあるXPCOMコンポーネントやインタフェースといったものは各プラットフォームのC++コードに過ぎなくて、それにC++以外の言語からアクセスする方法を提供するためにxptcallという物を導入している。xptcallは、C/C++/アセンブリ言語を用いてMozillaを利用するアーキテクチャ・プラットフォーム毎に移植されており、これがコンパイラ毎のシグネチャの違いや仮想関数テーブルのレイアウトの違い、引数の渡し方の違いなどを吸収している。

あー、今日は33%程度の確率で大掃除(何)なので、学校行ってきます。残りは後ほど。
忘れないようにキーワードを残しておく。nsIComponentLoader。その実例としてのnsNativeComponentLoader、bcJavaComponentLoader、mozJSComponentLoader、pyloader。
http://lxr.mozilla.org/mozilla/source/xpcom/components/nsIComponentLoader.idl
http://lxr.mozilla.org/mozilla/source/xpcom/components/nsIComponentLoaderManager.idl
http://lxr.mozilla.org/mozilla/source/xpcom/components/nsNativeComponentLoader.cpp
http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/loader/mozJSComponentLoader.h
http://lxr.mozilla.org/mozilla/source/java/xpcom/java/loader/bcJavaComponentLoader.h
http://lxr.mozilla.org/mozilla/source/extensions/python/xpcom/src/PyGModule.cpp#147