kekyoの丼

そういえば、実際のところこれがC++のどんなシンボルに相当するのかを実演しなかったのを思い出しました。これが、デマングリングした結果です（メニューから「Undecorate C++ symbol」を選択すると表示されます。見比べてみると面白いと思います）。

このような、C言語で言うところの関数名だけでは表現できない、C++のオーバーロードやクラスメンバ関数、const関数などを、シンボル名だけで識別可能にするために、マングリング操作が行われます。そしてこのマングリング操作が、処理系依存（かつバージョン依存）なのです。

したがって、例えばVC++ 6.0で普通に作ったDLLとVBで作ったDLLを直接静的にリンクすることは出来ません。他の処理系についても同様です。COMは、これらの処理系依存シンボルを使わず、COMのランタイムが提供する情報だけでクラスのファクトリを特定し、メンバ関数の位置はvtableと呼ばれる関数ポインタのテーブルの並びの整合性を担保することで、この問題を回避します。

# vtableの話はディスカッションでやらなかったですね。vtableはC++のvtableそのままで、仮想関数へのポインタのテーブルです。

どうやってクラスを特定するのかは、レジストリのHKEY_CLASSES_ROOT配下の情報を使います。ATLでプロジェクトを新規に生成すると、プロジェクト内に*.rgsのようなファイルが配置されます。これはコンポーネントレジストラスクリプトと呼び、要するにregsvr32された時にレジストリのどこにどんな値を書き込むのかを表し、このスクリプトでCOMのクラス（coclass）が特定できるようにします。

# 特定には、COMコンポーネントの実装が、どこのパスにあるDLL内にあり、どのクラス（CLSID –> GUID）なのかという情報を含みます。

もう一つの問題がメソッドの呼び出し規約で、これはWikipediaにあるように複数の規約があり、VC++では各関数単位でこれを指定して実装できるのですが、COMでは例外なく「stdcall」を使います。

生存期間

生存期間とは、COMのクラスのインスタンスが、いつまで生き続けるのかと言う問題です。.NETのインスタンスは、誰からも参照されなくなり、GCが回収する（場合によってはファイナライザーが呼び出され）と死んだ事になるのですが、C言語のようなアンマネージな世界では、「malloc」や「new」によってインスタンスが（ヒープに）生成され、「free」や「delete」によってメモリから取り除かれます。

// 確保する
auto p = static_cast<int*>(malloc(123 * sizeof(int)));

// 使う...

// 解放する
free(p);

このような簡単な例であれば、確保して解放するというサイクルから、解放のタイミングの時点で正しく解放されることが分かります。しかし：

static const int* pUseLate = nullptr;

static void ComputeStep1(const int* pTarget)
{
	// 後で使いたいので保存
	pUseLate = pTarget;
}

static void ComputeStep2()
{
	// （pUseLateを使って何かやる）
}

// 確保する
auto p = static_cast<int*>(malloc(123 * sizeof(int)));

// 使う...

// 処理その1
ComputeStep1(p);

// 処理が終わったので解放する
free(p);

// 処理その2
ComputeStep2();

このような処理があった場合、ComputeStep2の内部実装では、既にpが解放されていることを知る由はありません。このサンプルコードは非常に短く、メインの処理とComputeStepの実装が並べて書いてあるので「こんなのダメに決まってるじゃん！」と分かりますが、ComputeStepの実装は「別のだれか」がやるとしたらどうでしょうか？ あるいは、既にComputeStepは別の誰かが実装済みであり、これからメインの処理を書く場合、ComputeStep2の実行前にpを解放してはならない事はどうやって分かるのでしょうか？

このような、インスタンスの生存期間の問題を解決する方法として、COMではクラス実装側に参照カウンタを持ち、このカウンタ値を監視することで不要になったかどうかを判定します。

生存期間のカウンタは、IUnknownインターフェイスのAddRefによってカウントアップされ、Releaseによってカウントダウンされます。カウンタの初期値は1で、AddRefのたびにインクリメントされ、Releaseが呼び出されるとデクリメントされます。カウンタが0になると、自己消滅するように実装します。

使用する側は、ポインタをコピーするときにはAddRef、使い終わったらReleaseするという規約を守る事により、生存期間が正しく管理されるようになります。

インターフェイス型の認識

インターフェイス型の認識の問題もあります。C++上でインターフェイスを示すポインタをキャストして、目的のインターフェイスへのポインタを取得しようとしたとします。

// CoCreateInstanceなどで取得したインターフェイスポインタ
IUnknown* pUnknown = ...;

// 目的のインターフェイスポインタを得るためにキャスト
ICalc* pCalc = static_cast<ICalc*>(pUnknown);

このキャストが正しく解釈されるかどうかは、処理系に依存します。IUnknownをICalcにするにはダウンキャストが必要ですが、C++の世界ではコンパイラがその判断を行えるものの、COMの世界ではインターフェイスの情報しか存在しないため、正しくキャストできる保証がありません。そのため、キャストと言う処理自体も、IUnknown.QueryInterfaceメソッド呼び出しで解決します。

// CoCreateInstanceなどで取得したインターフェイスポインタ
IUnknown* pUnknown = ...;

// 目的のインターフェイスポインタを得るためにキャスト
ICalc* pCalc = nullptr;
pUnknown->QueryInterface(IID_ICalc, reinterpret_cast<void**>(&pCalc));

第一引数はインターフェイスID（GUID）で、これが必要なのはCOMの世界は.NETとは異なりリフレクションが存在しないので、インターフェイス型を一意に識別するIDが必要だからです。勿論、この場合のIID_ICalcは、ICalcインターフェイスのIDである前提です。

QueryInterfaceメソッド内でキャストを実装することにより、処理系の範囲内で正しくキャストが行えます。返されるポインタはキャスト後のポインタであるため、呼び出し元は処理系に依存することなくキャスト出来たことになります。

このようなメソッドを提供することで、処理系に（C++固有の）型を認識させる必要をなくし、互換性を維持します。

COMの概念への展開

結局、IUnknownの実装を通じて、どうやって処理系に依存しないでバイナリ互換性を維持するのかという事が、COMの中心にある概念であることを確認しました。COMのIUnknownとその実装はこんな感じだ！というのを、C#ライブコーディングで疑似実装して、参照カウンタの動きや、QueryInterfaceによるキャストの挙動を示して、内容の共有をしました。

# 以下のコードは、クラスファクトリも含めて穴埋めしたコードです。

// （あくまで概念コードです。これは正式なCOMのコードではありません）
public interface IUnknown
{
	T QueryInterface<T>() where T : IUnknown;
	int AddRef();
	int Release();
}

public interface ICalc : IUnknown
{
	int Add(int a, int b);
}

// クラスは直接公開されない
internal sealed class CalcImpl : IUnknown, ICalc
{
	private int count_ = 1;

	public int AddRef()
	{
		return Interlocked.Increment(ref count_);
	}

	public int Release()
	{
		var current = Interlocked.Decrement(ref count_);
		if (count == 0)
		{
			// インスタンスの破棄処理
			// Disposeに近いが、メモリストレージも削除される。
			// 破棄処理を隠蔽することで、処理系依存を排除。
		}
	}

	public T QueryInterface<T>() where T : IUnknown
	{
		// CやC++にはリフレクションは無いので、本当はインターフェイスID（GUID）で判定する。
		// キャスト処理を隠蔽することで、処理系依存を排除。
		if (typeof(T) == typeof(ICalc))
		{
			Interlocked.Increment(ref count_);
			return (T)(object)this;
		}
		if (typeof(T) == typeof(IUnknown))
		{
			Interlocked.Increment(ref count_);
			return (T)(object)this;
		}

		throw new NotImplementedException();
	}

	public int Add(int a, int b)
	{
		return a + b;
	}
}

public interface IClassFactory
{
	T CreateInstance<T>(Guid clsid) where T : IUnknown;
}

// クラスファクトリクラスも公開されない
internal sealed class CalcClassFactory : IClassFactory
{
	public T CreateInstance<T>(Guid clsid) where T : IUnknown
	{
		if (clsid == CLSID_Calc)
		{
			// newの実装を隠蔽することで、処理系依存を排除。
			return new CalcImpl();
		}

		throw new NotImplementedException();
	}
}

// CalcImplを外部から特定するためのGuid
public static readonly Guid CLSID_Calc = new Guid("BD4D1DDD-9C28-4432-A8DD-9CFA77E6433F");

// DLL外からはこのエントリポイントだけが見える
public static IClassFactory DllGetClassObject()
{
	return new CalcClassFactory();
}

もう既にかなりアレですが、まだまだ続きます。

COMとWinRT

WinRT（ストアアプリ・UWPのフレームワークとして使われるライブラリ）は、基礎がCOMで出来ていることは分かっていましたが、それ以上の理解は私の中になく、あんまり調べる意欲もなかったので、知りたかった部分です。

全てのCOMクラスはIUnknownインターフェイスを実装しますが、WinRTのクラスは、IInspectableインターフェイスも実装します。COMの世界ではITypeInfoインターフェイスをタイプライブラリ情報を公開するのに使いますが、これのWinRT版のような位置づけです。WinRTでは型情報は.NETのメタデータをそのまま使用します（winmd）。この情報との対応付けにIInspectableインターフェイスを使います。したがって、ITypeInfoのように、情報の細部までトラバース可能なメソッドセットは持っていません。

なお、COMにおいてITypeInfoインターフェイスの実装は任意ですが、WinRTのIInspectableの実装は必須です。

WinRTにおいてのもう一つの事情は、スレッドアパートメントの扱いです。WinRTでは、メインスレッドに相当するスレッドがASTAに属し、それ以外のスレッドはMTAに属するそうです。各アパートメント間の関係は、通常のCOMと同一とのこと。なるほど。

# 余談ですが、MSDNライブラリのリンク壊れてたりするよねー、直してほしいよねーみたいな話が… TechNetもぶっ壊れてるなー |дﾟ) ﾁﾗｯ

こんな話をすると、当然「アパートメントとは何か」みたいなところを避けては通れないけど、とりあえずは次の課題へ。

COMの実践的な実装方法

ようするに、どうやってCOMを書けば良いのかわからない（.NETとかVB6以外で）。

ATLでやる

ということで、一からIUnknownをCで実装するというハードは方法は時間もないのでパスし、ATL（Active Template Library）での実装方法をライブデモしました。ライブデモは私がやったのですが、ATLでバリバリ書いていたのはVisual Studio 2005の時だったので、2005を使ってデモ（こんなこともあろうかと、2005はインスコしてあるのだよ）。ATLは途中から、C#のような属性ベースの指定で楽に書けるようになったはずなのですが、結局私的には移行しなかったので分からず…

新しいプロジェクトの追加で、「ATLプロジェクト」を追加し、「プロジェクト-追加-クラス」で、「ATLシンプルオブジェクト」を選択すると、COMをATLで実装するクラスのひな型が追加されるウィザードが表示されます。短い名前の所にクラス名を入れると、各ファイル名とか良しなに決定されます。問題は次のウィザード。

ここのスレッドモデルとアグリゲーションの選択も、結構ディープだよね、ああそれとフリースレッドマーシャラーとかも。でもこの説明をするには、やっぱりアパートメントを避けては通れないしデモが中断してしまうので、ちょっと横に置いておく事に。

これでひな型が生成されたら、あとは「クラスビュー」のCOMインターフェイスのツリーから「追加-メソッド」とか「追加-プロパティ」とかやると、メンバを追加するウィザードが表示されて、メンバ定義を簡単に追加できます。もし、手動で定義するとなると、IDLファイル・ヘッダファイル・ソースファイルを同時に修正しなければならないため、かなり面倒です。そして、追加はウィザードで簡単にできますが、修正するとなると同じように全部直さなければならないので、結構苦痛…

で、実装出来たらビルドしますが、Visual Studioが管理者権限で起動していないと、最後にエラーが出ます。これはregsvr32でDLLを登録しようとしたときに、コンポーネントレジストラスクリプトがレジストリを変更するためで、素直に再起動。

TestPropという文字列（BSTR）のプロパティを追加し：

// メンバには以下のようなフィールドを定義
private: _bstr_t temp;

STDMETHODIMP CTest::get_TestProp(BSTR* pVal)
{
	// TODO: ここに実装コードを追加してください。

	*pVal = temp.copy();
	return S_OK;
}

STDMETHODIMP CTest::put_TestProp(BSTR newVal)
{
	// TODO: ここに実装コードを追加してください。

	temp = newVal;
	return S_OK;
}

テストするコードはC#で書きました。
COM側のビルドとregsvr32が完了していれば、C#の参照設定でCOMコンポーネントが参照出来ます。

using ATLSampleLib;

class Program
{
	static void Main(string[] args)
	{
		var testClass = new TestClass();
		testClass.TestProp = "ABCX";
		Console.WriteLine(testClass.TestProp);
	}
}

これで無事、コンソールに”ABCX”が表示されました。

WinRTでは文字列をHSTRING型で扱いますが、これはリテラル文字列をいちいちメモリ確保してコピーして…というコストを削減するためだそうです。なるほど、それだとCLRの世界での文字列と同じように扱われる訳で、イメージは湧きやすい。BSTRを使うと、内部ではSysAllocString APIなどでメモリを確保したり解放したりするので、コストは高いです。

いつ解放されるのか

上記テストコードで、AddRefもReleaseも呼び出していないのは？という疑問に対し、CLRの世界にはRCW（ランタイム呼び出し可能ラッパー）があって、これがAddRefとかReleaseを呼び出しているのだ、しかし、この例では使用後にすぐプロセスが終了してしまうので、果たして呼び出されるのか？という疑問があり、じゃあ、Marshal.FinalReleaseComObjectを呼び出せばどうだ、いや、それを呼び出すと挙動がおかしい、などの説があって、試しました。

using ATLSampleLib;

class Program
{
	static void Main(string[] args)
	{
		var testClass = new TestClass();
		testClass.TestProp = "ABCX";
		Console.WriteLine(testClass.TestProp);

		Marshal.FinalReleaseComObject(testClass);
	}
}

ATL側では、インスタンスの寿命が尽きる時（参照カウンタが0になったとき）、FinalReleaseメソッドが呼び出されます。ここにブレークを張ってテストしたのですが、やってこない…

FinalReleaseComObjectの代わりにGCを手動実行したらどうだろうと言う事でテスト：

using ATLSampleLib;

class Program
{
	static void Main(string[] args)
	{
		var testClass = new TestClass();
		testClass.TestProp = "ABCX";
		Console.WriteLine(testClass.TestProp);

		GC.Collect(2, GCCollectionMode.Forced, true);
		GC.Collect(2, GCCollectionMode.Forced, true);
		GC.Collect(2, GCCollectionMode.Forced, true);
	}
}

すると来ましたFinalRelease。うーむ、FinalReleaseComObjectとは何なのか？ これだとインターフェイスポインタを直接弄った方が安心感があるよなぁと思わなくもない（真相は分からず）。

もう一つ気が付いたことが。FinalReleaseでブレークを張ったところ、スタックトレースがこのように。

これワーカースレッドから呼ばれてるよね、何でだ？と思ったらMainメソッドに、STAThread属性を付けていなかった。

で、STAThreadを追加したところ、無事にメインスレッドから呼び出された（このCOMコンポーネントがワーカースレッドから呼び出されること自体に問題はないんですが、一瞬えっと思ったので気が付いた次第）。

# しかし、このスタックトレースも大概だなぁ。当然こうなる事は予測できるんだけど…

// 呼び出し元の例：
IHogeService* pHogeService = ...;

// 例えば、戻り値がインターフェイスポインタの場合
IResultData* pResultData = nullptr;
pHogeService->GetResult(&pResultData);

// （pResultDataは何を指しているか？）