|
|
|
|
コメント(19)
COM。Component Object Model の略。
C++ の純粋仮想クラスと同様のバイナリインターフェースを持つプログラミングインターフェースとその実装通信規約の総称。
もともとは、OLE1(DDE上で実装されていた)の仕様上の限界の突破と、Office の外部制御を、統一された規格のもとでなんとかするために計画されたもの。
COMと呼ばれる部分は、上述の通り、アクセスのための規約と通信のために規約しか盛り込まれていない。
それ以外の具体的なインターフェースの規約は、すべてCOMとは切り離されて考慮されるべきものである。
なお、インターフェースのうち、COMの規約に含まれるものは、IUnknown と、IClassFactoryの２つだけである。
＃間違えやすいが、IClassFactory2 は、COMの規約ではない
なお、すべてのインターフェースは、IUnknown から派生しなければならないのもCOMの規約として盛り込まれている。
こんな感じでどうでしょ？ｗ
ちなみに、アプリケーションとしてのエクスプローラは、自身の動作を支えるために様々なインターフェースを用意し、それをそれぞれの用途ごとに実装されたものをプラグインとして(OS自身が標準提供するものも含め)、利用しているにすぎません。
そのため、アプリケーションとしてのエクスプローラと互換のアプリケーションを作成することも可能です。
ただし、シェルとしてのエクスプローラはその限りではないため、こちらはそう簡単には実装できないと思われます。
＃どのみち、今はシェルをおきかえられないので、無理ですけどｗｗｗ
C++ の純粋仮想クラスと同様のバイナリインターフェースを持つプログラミングインターフェースとその実装通信規約の総称。
もともとは、OLE1(DDE上で実装されていた)の仕様上の限界の突破と、Office の外部制御を、統一された規格のもとでなんとかするために計画されたもの。
COMと呼ばれる部分は、上述の通り、アクセスのための規約と通信のために規約しか盛り込まれていない。
それ以外の具体的なインターフェースの規約は、すべてCOMとは切り離されて考慮されるべきものである。
なお、インターフェースのうち、COMの規約に含まれるものは、IUnknown と、IClassFactoryの２つだけである。
＃間違えやすいが、IClassFactory2 は、COMの規約ではない
なお、すべてのインターフェースは、IUnknown から派生しなければならないのもCOMの規約として盛り込まれている。
こんな感じでどうでしょ？ｗ
ちなみに、アプリケーションとしてのエクスプローラは、自身の動作を支えるために様々なインターフェースを用意し、それをそれぞれの用途ごとに実装されたものをプラグインとして(OS自身が標準提供するものも含め)、利用しているにすぎません。
そのため、アプリケーションとしてのエクスプローラと互換のアプリケーションを作成することも可能です。
ただし、シェルとしてのエクスプローラはその限りではないため、こちらはそう簡単には実装できないと思われます。
＃どのみち、今はシェルをおきかえられないので、無理ですけどｗｗｗ
とっちゃんさん、ありがとうございます。
そいや、OLEなんてのもありましたね。
OLE→COM→COM+
でしょうか？
>なお、インターフェースのうち、COMの規約に含まれるものは、IUnknown と、IClassFactoryの２つだけである。
約束事は意外と少ないんですね。でも、どんな恩恵があるのか、よくわからないっす;_;
普通のDLLとどう違うねん〜みたいな^^;
COM入門の本でも買おうかな。
わんくまの掲示板で質問したんですが、
IRichEditOleCallback::QueryInsertObject
という話がでてきまして、これ、なんやかんやしようと思ったら、やっぱりCOMの知識がいるんですよね？
C#でちょっと突っ込んだことしようとしたら、まだまだCOMは避けては通れないみたいです。
そいや、OLEなんてのもありましたね。
OLE→COM→COM+
でしょうか？
>なお、インターフェースのうち、COMの規約に含まれるものは、IUnknown と、IClassFactoryの２つだけである。
約束事は意外と少ないんですね。でも、どんな恩恵があるのか、よくわからないっす;_;
普通のDLLとどう違うねん〜みたいな^^;
COM入門の本でも買おうかな。
わんくまの掲示板で質問したんですが、
IRichEditOleCallback::QueryInsertObject
という話がでてきまして、これ、なんやかんやしようと思ったら、やっぱりCOMの知識がいるんですよね？
C#でちょっと突っ込んだことしようとしたら、まだまだCOMは避けては通れないみたいです。
＞OLE→COM→COM+
いえ、OLE と COM は同じようでいて違うものです。
.NET でいえば、BCL がCOM、OLEは.NET Framework という感じです。＜また難解な！
通信規約という意味では、COMの前進に当たるものは、DDE かなぁ？
これに、RPC とかLPCとか織り交ぜてコネコネしたものがCOMという感じでも捉え方としては間違ってねーと思います。
＞でも、どんな恩恵があるのか
規定しているものが少ないので、自由度が上がります。
平たくいってしまえば、IUnknown から派生していて、インターフェースを実装しているオブジェクトを引っ張りだす仕組みを合わせておけば、COMとして成り立つといえます。
なので、エクスプローラのように、自由自在にインターフェースを取り決めることができます。
最大の恩恵は、同じインターフェースなので、実装がどうあれまったく同じ扱いにできるということですね。
なので、プラグインやアドオンなんかの実装でもよく利用されていますし、オブジェクトという単位を設けられるので、OO的な利用方法が行いやすいというのもあります。
＞普通のDLLと
こちらは...んー。特に違いはないですｗ
あるとすれば、きまった形のエクスポートがあってきまった形でシステムに登録されているということくらいかなぁ？ｗ
所詮、DLLはDLLですのでｗｗｗ
＃.NET のDLLとは似て非なるものですけどｗ
＞わんくまの掲示板で質問したんですが、
かなり厳しいっすよｗ
まぁ、リファレンス自体はそんなじゃないですが、.NET のリッチエディットコントロールが、Nativeのそれのラッパーなのだとすれば、アクセスは、Windowメッセージ＋COMインターフェースです。
で、このうち、IRichEditOleCallback はCOMインターフェース部分の段取りなので、今まで見えなかったところまで触らないと...ｗ
ちなみに、.NET もその最下層部分では、COM を利用しています。
実際、Native EXEがホストする部分のAPIはCOMのインターフェースですし。
なので、まだまだ現役とも言えますねｗ
いえ、OLE と COM は同じようでいて違うものです。
.NET でいえば、BCL がCOM、OLEは.NET Framework という感じです。＜また難解な！
通信規約という意味では、COMの前進に当たるものは、DDE かなぁ？
これに、RPC とかLPCとか織り交ぜてコネコネしたものがCOMという感じでも捉え方としては間違ってねーと思います。
＞でも、どんな恩恵があるのか
規定しているものが少ないので、自由度が上がります。
平たくいってしまえば、IUnknown から派生していて、インターフェースを実装しているオブジェクトを引っ張りだす仕組みを合わせておけば、COMとして成り立つといえます。
なので、エクスプローラのように、自由自在にインターフェースを取り決めることができます。
最大の恩恵は、同じインターフェースなので、実装がどうあれまったく同じ扱いにできるということですね。
なので、プラグインやアドオンなんかの実装でもよく利用されていますし、オブジェクトという単位を設けられるので、OO的な利用方法が行いやすいというのもあります。
＞普通のDLLと
こちらは...んー。特に違いはないですｗ
あるとすれば、きまった形のエクスポートがあってきまった形でシステムに登録されているということくらいかなぁ？ｗ
所詮、DLLはDLLですのでｗｗｗ
＃.NET のDLLとは似て非なるものですけどｗ
＞わんくまの掲示板で質問したんですが、
かなり厳しいっすよｗ
まぁ、リファレンス自体はそんなじゃないですが、.NET のリッチエディットコントロールが、Nativeのそれのラッパーなのだとすれば、アクセスは、Windowメッセージ＋COMインターフェースです。
で、このうち、IRichEditOleCallback はCOMインターフェース部分の段取りなので、今まで見えなかったところまで触らないと...ｗ
ちなみに、.NET もその最下層部分では、COM を利用しています。
実際、Native EXEがホストする部分のAPIはCOMのインターフェースですし。
なので、まだまだ現役とも言えますねｗ
OLE には OLE1 と OLE2 があります。
OLE1 はすでに過去の遺物であり、現在、OLE と言えば OLE2 を指します。
OLE は Object Linking and Embedding の略で、要するに埋め込みドキュメント（Word の中に Excel の表を埋め込めたり）です…よね？
とっちゃんも言われているとおり、OLE1 は COM とは関係なく、DDE という技術によって実現されていました。
それを COM の上に再実装したのが OLE2 ですが、2 は発展しすぎて、すでに「Object Linking and Embedding」だけにとどまらないものになってしまっています。
現在の OLE は、何かの略というよりも「OLEという言葉」だと思ったほうがいいかもしれません。
OLE1 はすでに過去の遺物であり、現在、OLE と言えば OLE2 を指します。
OLE は Object Linking and Embedding の略で、要するに埋め込みドキュメント（Word の中に Excel の表を埋め込めたり）です…よね？
とっちゃんも言われているとおり、OLE1 は COM とは関係なく、DDE という技術によって実現されていました。
それを COM の上に再実装したのが OLE2 ですが、2 は発展しすぎて、すでに「Object Linking and Embedding」だけにとどまらないものになってしまっています。
現在の OLE は、何かの略というよりも「OLEという言葉」だと思ったほうがいいかもしれません。
COM+ はまた別の技術ですね。
これはいろいろな技術の複合体です。
昔、MTS（Microsoft Transaction Server）がありました。
COM オブジェクトをトランザクショナルにするためのものらしいです。
これは NT4 の頃は単体製品として売られていましたが、Windows2000 から OS の一部になりました。
この時、MTS が COM に緊密に統合され、COM+ の一部となりました。
また、C++ でネイティブな COM コンポーネントを作ってみると、結構、定型的な部分が面倒臭いものです（ATL でも回避できるでしょうけど）。
そうした定型的な部分を、「COM+ カタログ」というデータベースに登録しておけば、定型的なコードを書かなくてもいいようにした、というのも COM+ の機能の一つです。
これはいろいろな技術の複合体です。
昔、MTS（Microsoft Transaction Server）がありました。
COM オブジェクトをトランザクショナルにするためのものらしいです。
これは NT4 の頃は単体製品として売られていましたが、Windows2000 から OS の一部になりました。
この時、MTS が COM に緊密に統合され、COM+ の一部となりました。
また、C++ でネイティブな COM コンポーネントを作ってみると、結構、定型的な部分が面倒臭いものです（ATL でも回避できるでしょうけど）。
そうした定型的な部分を、「COM+ カタログ」というデータベースに登録しておけば、定型的なコードを書かなくてもいいようにした、というのも COM+ の機能の一つです。
NT4 から、DCOM（Distributed COM）が登場しました。
分散 COM、要するにネットワーク透過的な COM のことであり、サーバが同じプロセスの中にあろうが海の向こうにあろうが、クライアントはそれを意識しない、というのが可能になりました（それ以前は同じプロセスの中にしか有りませんでした）。
この時、同時に COM にマルチスレッドが持ち込まれました。
サーバとクライアントの境界は「アパートメント」という形で一般化され、マーシャリングだの何だのと面倒くさいことが増えましたｗ
今では殊更に DCOM と呼ばなくても、もはやアパートメント越えを意識しない COM は書けない状況ですから、DCOM は COM の一部に吸収されたと思ってよいでしょう。
分散 COM、要するにネットワーク透過的な COM のことであり、サーバが同じプロセスの中にあろうが海の向こうにあろうが、クライアントはそれを意識しない、というのが可能になりました（それ以前は同じプロセスの中にしか有りませんでした）。
この時、同時に COM にマルチスレッドが持ち込まれました。
サーバとクライアントの境界は「アパートメント」という形で一般化され、マーシャリングだの何だのと面倒くさいことが増えましたｗ
今では殊更に DCOM と呼ばなくても、もはやアパートメント越えを意識しない COM は書けない状況ですから、DCOM は COM の一部に吸収されたと思ってよいでしょう。
ついでに ActiveX も説明しておきましょう。
ActiveX とは、技術的にいえば、IDispatch というインターフェイスを実装した COM のことです。
COM の応用技術の一種ですが、COM とは一線を画する異質なものでもあります。
IDispatch は ActiveX 技術の中では IUnknown に相当する、もっとも基本的なインターフェイスです。ActiveX クライアントは IUnknown の代わりに IDispatch を使います。
よく「Visual Basic のためにデザインされた」と言われますが、真偽のほどはわかりません。
今でもブラウザのアドインという形で生き残っています。
ActiveX とは、技術的にいえば、IDispatch というインターフェイスを実装した COM のことです。
COM の応用技術の一種ですが、COM とは一線を画する異質なものでもあります。
IDispatch は ActiveX 技術の中では IUnknown に相当する、もっとも基本的なインターフェイスです。ActiveX クライアントは IUnknown の代わりに IDispatch を使います。
よく「Visual Basic のためにデザインされた」と言われますが、真偽のほどはわかりません。
今でもブラウザのアドインという形で生き残っています。
ActiveX についての補足。
ActiveX というのは、ActiveX Contorol(OCXの再定義バージョン)と、ActiveX Document(OLEインプレースサーバーの再定義バージョン)の二つの総称をさします。
いずれも、IEに対しての追加機能ではありますが、それぞれの用途も仕組みもすべて異なるものです(類似部分も多々あり)。
で、１０でいってるのは、ActiveX Control(以下ActiveX) のほうになります。
ActiveX は前身となるOCX(確かOle Control eXtensionの略であってると思う)を、IE用に強化したものです。
OCX は、OLEインプレースサーバー＋Automation(こちらもOLEの仕組みの一部)の組み合わせになります。
Automationは、IDispatch 及びその周辺を規格化したもので、もともとは、Excel/Word の外部操作用のインターフェースといえます。
＃出自はこっちのほうが早い。
で、肝心のOCXはなにかというと、VBX を 32bit 化する際に規格化されたものです。
これが理由で「Visual Basic のためにデザインされた」と言われることもありますが、VBX -> OCX の際に大幅に汎用的にした結果、VBのためにだけではなくなりました。
ActiveX というのは、ActiveX Contorol(OCXの再定義バージョン)と、ActiveX Document(OLEインプレースサーバーの再定義バージョン)の二つの総称をさします。
いずれも、IEに対しての追加機能ではありますが、それぞれの用途も仕組みもすべて異なるものです(類似部分も多々あり)。
で、１０でいってるのは、ActiveX Control(以下ActiveX) のほうになります。
ActiveX は前身となるOCX(確かOle Control eXtensionの略であってると思う)を、IE用に強化したものです。
OCX は、OLEインプレースサーバー＋Automation(こちらもOLEの仕組みの一部)の組み合わせになります。
Automationは、IDispatch 及びその周辺を規格化したもので、もともとは、Excel/Word の外部操作用のインターフェースといえます。
＃出自はこっちのほうが早い。
で、肝心のOCXはなにかというと、VBX を 32bit 化する際に規格化されたものです。
これが理由で「Visual Basic のためにデザインされた」と言われることもありますが、VBX -> OCX の際に大幅に汎用的にした結果、VBのためにだけではなくなりました。
あら。。。ずいぶんと懐かしいコミュにコメントがついてるｗ
.NET Framework(C#やVBなどの実行基盤ですね)には、RCW(Runtime Callable Wrapper:ランタイム呼び出し可能ラッパー)というものがあり、これが、COMオブジェクトをラッピングして、.NET Framework 側には、間接的に見せる形になっています。
RCWのCOMラッパーは、IUnknown 以外のインターフェースしか再定義しないので(取り込みのタイミングでメタデータを構築している)、.NET 側には、IUnknown は見えません。
もっとも、QueryInterface は、キャスト演算子としてオーバーライドされているので、形が変わっているだけですし
Release は、Marshal.ReleaseComObject として、用意されています。
.NET サイドにはCOMオブジェクトそのものが見えるわけではないので、構造的には見えてしまうほうが困るんですけどね。
ちなみに... C++/CLI でCOMを扱う場合は、RCWを通さず、直接COMオブジェクトを利用するほうが安全かつ効率よく利用することができます。
もちろん、生のポインタを使うのではなく、_com_ptr_t のようにスマートポインタを利用するという前提ですが。
.NET Framework(C#やVBなどの実行基盤ですね)には、RCW(Runtime Callable Wrapper:ランタイム呼び出し可能ラッパー)というものがあり、これが、COMオブジェクトをラッピングして、.NET Framework 側には、間接的に見せる形になっています。
RCWのCOMラッパーは、IUnknown 以外のインターフェースしか再定義しないので(取り込みのタイミングでメタデータを構築している)、.NET 側には、IUnknown は見えません。
もっとも、QueryInterface は、キャスト演算子としてオーバーライドされているので、形が変わっているだけですし
Release は、Marshal.ReleaseComObject として、用意されています。
.NET サイドにはCOMオブジェクトそのものが見えるわけではないので、構造的には見えてしまうほうが困るんですけどね。
ちなみに... C++/CLI でCOMを扱う場合は、RCWを通さず、直接COMオブジェクトを利用するほうが安全かつ効率よく利用することができます。
もちろん、生のポインタを使うのではなく、_com_ptr_t のようにスマートポインタを利用するという前提ですが。
- mixiユーザー
- ログインしてコメントしよう！
|
|
|
|
COM -Component Object Model- 更新情報
-
最新のトピック
-
最新のイベント
-
まだ何もありません
-
-
最新のアンケート
-
まだ何もありません
-
