プログラミング：COM

COM列挙子 in C#

シャノン — Wed, 12 Mar 2008 00:22:00 GMT

COMインターフェイスからもらったIEnumXXXをIEnumeratorにするには、どーしたらいいんだろうか？

タイプライブラリに保持されない属性

シャノン — Sat, 22 Dec 2007 00:17:00 GMT

の一覧って、MSDNかどこかにあるんでしょうか？

# Atata!! 師匠のサイトの掲示板に書こうと思ったら、referer error!!!! って言われて書けなかったorz
# ここを見てくださっていることを願って。

COMとスレッドセーフ

シャノン — Fri, 21 Dec 2007 14:35:00 GMT

MTAとかは当たり前にスレッドセーフなので置いといて。

DllGetClassObjectとDllCanUnloadNowとか、クラスファクトリもスレッドセーフにしなきゃならないですよね？

MIDLが吐き出すファイル

シャノン — Mon, 17 Dec 2007 15:38:00 GMT

たまにはCOMしましょうかね…（遠い目）。

IDLファイル書きました。こんなの。

import "oaidl.idl";
import "ocidl.idl";
[
 object,
 uuid( 9874C279-FE45-43a1-9ED6-ED667E5BA089 )
]
interface IHoge : IUnknown
{
 HRESULT Hoge();
}

こいつをMIDLでコンパイると、（元のファイル名がHoge.idlだとして）以下の４つのファイルができます。

Hoge_h.h
Hoge_i.c
Hoge_p.c
dlldata.c

Hoge_h.hは、このインターフェイスの定義をC++風に書き直したものです。
こいつを、このインターフェイスを使うクライアントに提供します。
この中には、IID_IHogeの宣言も含まれています。

Hoge_i.cは、GUIDの定義ファイルです。
今回の例の場合、この中にIID_IHogeの定義が含まれます。

Hoge_p.cとdlldata.cは、このインターフェイスのプロキシとスタブを生成するためのソースファイルです。
ここでは割愛。

さて、これでコンポーネント側はできたとして（実装は小人さんが手伝ってくれました）、次はこれを利用するアプリ側を作りましょう。

ここで問題です。
アプリ側ではCoCreateInstanceを使うために、CLSID_HogeとIID_IHogeの定義が必要です。
しかし、CLSID_Hogeなんてものはどこにも定義してありません。
それから、ユーザに渡したHoge_h.hには、IID_IHogeの宣言しか入っていません。
さぁどうしましょう？

MicrosoftがWindows SDKで提供しているインターフェイスは、そのCLSIDやIIDの定義がスタティックライブラリに入っているものがあります。
しかし、COMは本来、インポートライブラリ不要のアーキテクチャです。
ヘッダファイルにでも入れて提供してあげれば済むことなので、このためにHoge.libなんて作りたくありません。

IIDの定義は、Hoge_i.cに入っています。
このファイルをユーザーに提供すればいいんでしょうか？
できれば、ユーザーに渡すのはヘッダファイルだけにしたいところです。
それとも、実体の定義を伴うヘッダファイルなんて邪道でしょうかね？

CLSIDはどこで定義しましょう？
IDLファイル中でも、こんな風にすればできます。

import "oaidl.idl";
import "ocidl.idl";
[
 object,
 uuid( 9874C279-FE45-43a1-9ED6-ED667E5BA089 )
]
interface IHoge : IUnknown
{
 HRESULT Hoge();
}
[ uuid( 56BFECD7-0642-4594-9CA8-6C1B77DE0C95 ) ]
coclass Hoge
{
 [ default ] interface IHoge;
}

これは、IHogeを実装するクラスHogeの定義です。
こう定義してやると、Hoge_h.hにCLSID_Hogeの宣言が、Hoge_i.cに定義が、それぞれ生成されます。

しかし、同時に、Hoge_h.hにHogeクラスの先行宣言が加わります。
このHogeクラスとは何者でしょうか？

これはCOMクラスですから、そんなクラスを宣言されたところで、new Hoge; でインスタンスを生成することはできません。
先行宣言によって可能になるのは、その型のポインタ型を定義することくらいですが、メソッドの宣言が含まれないため、そのポインタを利用してメソッドを呼び出すことができません。
第一、C++でCOMを扱うときに利用するのはインターフェイスポインタであって、CLSID以外でクラスの存在を意識することはないのです。クラスポインタなんて必要ありません。
まったく役立たずです。

IDLファイルにcoclassだけでなくタイプライブラリの定義も加えてやれば、VBや.NETからの呼び出しが可能になり、そこではnew Hoge;でのインスタンス生成が可能になります。
しかし、そのためにHoge_h.hでHogeクラスが宣言されている必要はゼロです。VBや.NETは、C++のヘッダファイルを必要としないのですから。

というわけで、

ユーザにHoge_i.cは提供したくない
IDLでcoclassは定義したくない

ということになりました。

IDLでcoclassを定義しない以上、CLSIDの定義をMIDLに頼ることはできません。
ならば、自分でヘッダファイルでも作って、そこに書いてやるしかないでしょう。
せっかくファイルを作るのならば、IIDの定義もそっちでやってしまいましょう。
特定のマクロが定義されているときは定義に、そうでないときは宣言になるようにスイッチしてあげればいいでしょう。
事実、Windows SDKに含まれるDEFINE_GUIDはそうなっていますし、guidgen.exeはほとんどコピペで使えるDEFINE_GUID形式の表記を生成してくれますから、これを使えばいいでしょう。

ふーむ…これで最適解になりましたかね？
MIDLが若干気に食わないものの、こうするのが定石、なのかな？

同値関係

シャノン — Tue, 11 Dec 2007 10:38:00 GMT

あるインスタンスnがある。このインスタンスの真の型（動的な型）は問わないものとする。

反射律：nの静的な型がAであるならば、nをAにキャストできる。
対称律：nの静的な型がAであり、これをBにキャストできるならば、再度Aにキャストできる。
推移律：nの静的な型がAであり、これをBにキャストしてからCにキャストできるならば、直接AからCにキャストできる。

この特徴は、特にCOMのQueryInterfaceにおいて顕著である。
余談だが、COMのキャスト規則も書いておく。

反射律：nの静的な型がIFooであるならば、n->QueryInterface( IID_IFoo, &m ); は成功する。
対称律：nの静的な型がIFooであり、n->QueryInterface( IID_IBar, &m ); が成功するならば、m->QueryInterface( IID_IFoo, &o ); は成功する。
推移律：nの静的な型がIFooであり、n->QueryInterface( IID_IBar, &m ) が成功し、かつ m->QueryInterface( IID_IPoo, &o ); が成功するならば、n->QueryInterface( IID_IPoo, &o ); は成功する。
nの型に関わらず、n->QueryInterface( IID_IUnknown, &m ); は常に成功する。
かつ、m の値は何度実行しても必ず同じになる（IUnknown 以外へのキャストの場合は同じになるとは限らない）。
n->QueryInterface( IID_IFoo, &m ); が一度成功したならば、何度実行しても必ず成功する。
逆に、一度失敗したならば、何度実行しても必ず失敗する。

メモリー図勉強しなおし宣言

シャノン — Fri, 16 Nov 2007 09:43:00 GMT

…COM Interopでハマったorz

私はこれでVB6を捨てました

シャノン — Thu, 28 Jun 2007 11:03:00 GMT

SHGetFileInfoとDestroyIcon

なんか涙ぐましいことしてるなぁ….NETのListViewにSendMessage か…。

いや、ちょっと昔を思い出して。

VB6でね。エクスプローラもどきをつくろうとしたんですよ。
デスクトップをルートとする仮想フォルダツリーもちゃんと表示したりして。

SHGetFileInfoで、システムイメージリストのハンドルを取得するわけですよ。
でも、VBのListViewに設定できるのは、あくまで「ImageListコントロール」だったんですね。
しかも、その中身はIPictureDispじゃないといけないと来たもんだから、システムイメージリストの中身をOleCreatePictureIndirectで変換して、それを１個ずつImageListに追加してたんですね。
既にあるものをわざわざ複製するなんて馬鹿らしいと思いながら。

Windows SDKなら、SendMessageで一発なのにと。変換なんかしなくても、既にあるものがそのまま使えるのにと。
VB6を捨ててC+Platform SDKの世界に飛び込んだきっかけはそれでした。

.NETになっても、ImageList.Handleプロパティはあるくせに、ImageList.FromHandleメソッドは無いんだね…

以下は完全に余談。

シャノンというハンドルは、恐れ多くも情報理論の開祖、Claude Elwood Shannon大先生にあやかってつけたものです。
当時、データ圧縮にハマってまして、その端緒を開いたのがシャノンのエントロピー符号であったことに始まります。
ちなみにあの頃は、「全てのアーカイバを集める」ということもやろうとしてました。後に、ほとんどのアーカイバは似たり寄ったりのアルゴリズムでできていること、アルゴリズムをちょこっと変えれば違うアーカイバができることを知って、止めてしまいましたけど。

で、最初はLhasaのようなダイアログベースアーカイバを作ろうとしたんですが、次第に、書庫ファイルをフォルダとして扱えるようなエクスプローラライクなものへと構想が変わっていって、上記のような事態になったという次第。

その後、エクスプローラライクなものを自作するより、エクスプローラそのものを利用した方がいいだろうということに気付き、シェル拡張を志し、その基礎たるCOMに手を染めるという流れで、脈々と今に続いていたりするのでした。

# その割に、具体的な成果物はまだ何一つないんだけどナー('～`；)

スレッド＠COM

シャノン — Tue, 26 Jun 2007 20:28:00 GMT

COMの泥沼へようこそ…ﾋﾋﾋ。

どーにもわかんねぇことがあるんで訊いちゃおう。

わかんねぇこと　その１
STAスレッドからMTAオブジェクトのメソッドを呼んだら？: MTAオブジェクトのメソッドが実行されるスレッドは、CoInitializeEx( NULL, COINIT_MULTITHREADED ) したスレッドとは限らず、COMが管理するスレッドプールのスレッドで呼ばれる？; 呼び出し元のSTAスレッドで呼ばれることはないと思うけど…。
わかんねぇこと　その２
MTAスレッドからSTAオブジェクトを作って呼んだら？: STAスレッドが勝手に作られて、そのスレッドコンテキストで実行される？; MTAスレッドからSTAオブジェクトを作った数だけ、STAスレッドができちゃったりする？

アパートメントのメモ書き

シャノン — Fri, 25 May 2007 15:06:00 GMT

＃アパートじゃなくてホテル住まいとかしてみたいですネ
＃でもCOMの記事書くための缶詰ってのは勘弁orz

以下はメモ書きです。
＃とっちゃんに負けるなー！おー！（ｲｲﾉｶｿﾝﾅｺﾄｲｯﾁｬｯﾃ
COM+のコンテキストのことはわかりませんorz

アパートメントの種類
- STA
- MTA
- TNA
- デフォルト
オブジェクトのスレッディングモデルの種類
- Apartment
- Free
- Both
- Neutral
- なし
アパートメントとスレッディングモデルの組み合わせ
STAの注意事項
FTMとGIT
CoMarshalInterThreadInterfaceInStream（長ぇよバカヤロー！

…こんなところでいいかしら？

やっべー

シャノン — Fri, 25 May 2007 14:00:00 GMT

最近、わんくま内でCOMの話題がチラホラと…

まずい！このままでは、「COMと言えばシャノン様」の構図ができる前に泡と消えてしまう！！

週末で家のPCのOS再インストールしたら気合い入れて取り掛かるか…
＃この機にVistaに入れ替えよう