クライアントからすれば別プロセスで作成されたオブジェクトということになります。それなのにメソッドの呼び出しが成立するのは何故でしょうか。クライアントはこのプロキシのメソッドを呼び出すことになります。RPCを通じてサーバーのスタブへ送信します。サーバーのオブジェクトのメソッドを実際に呼び出します。処理結果をクライアントのプロキシに返します。プロキシとスタブの実装はインターフェースによって異なります。CoCreateInstanceやCoRegisterClassObjectは次のレジストリキーを参照します。HKEY_CLASSES_ROOT\Interface\{IID}\ProxyStubClsid32IIDの部分には、使用するインターフェースのIIDが入ります。ProxyStubClsid32キーの既定のエントリには、プロキシとスタブを提供するオブジェクトのCLSIDが格納されています。このオブジェクトはインプロセスサーバーとして実装されており、一般にプロキシ/スタブDLLと呼ばれます。後はこれをロードすればクライアントの場合はプロキシ、サーバーの場合はスタブを用意できたことになります。次に、プロキシとスタブの関係を示します。クライアントとサーバーの両方のアドレス空間に、同じプロキシ/スタブDLLがロードされていると考えてください。クライアントのDLLはプロキシとして機能することになりますが、サーバーのDLLはスタブとして機能します。IUnknownやIStreamのような既存のインターフェースには、関連するプロキシ/スタブDLLが最初からシステムに存在しています。よって、既存のインターフェースを使用する場合は、プロキシやスタブについて特に意識する必要はありません。開発者がこれを用意することになります。これをコンパイルした際にはプロキシ/スタブ用のファイルが作成されることになっています。よって、これをDLLのプロジェクトに追加してコンパイルすれば、プロキシ/スタブDLLを作成することができます。次に、プロキシ/スタブDLLのファイル構成を示します。sample_h.h、sample_p.c、sample_i.c、dlldata.cが作成されることになります。sample_i.cはIIDの定義が含まれているため必要です。dlldata.cにはDLLのエクスポート関数であるDllGetClassObjectなどの実装が含まれているため、これも必要です。アプリケーションが独自にソースファイルを記述する必要はないのかというと、必ずしもそうとは限りません。既定では、アプリケーションはDllRegisterServerとDllUnregisterServerを実装し、DLLの登録と解除を行わなければならないようになっています。結果として独自のソースファイルは不要になります。「プリプロセッサの定義」という項目にREGISTER_PROXY_DLLを追加します。これでコンパイルすると、DllRegisterServerとDllUnregisterServerの実装はDLLに任せることができます。ちなみに、プロキシ/スタブはrpcrt4.libへのリンクを必要としているため、これも開発環境で設定しておきましょう。「追加の依存ファイル」にrpcrt4.libを追加するようにします。これにより、DLLのコンパイルが成功することになります。作成したプロキシ/スタブDLLは、通常のインプロセスサーバーと同様にregsvr32で登録することができます。HKEY_CLASSES_ROOT\CLSID以下にオブジェクトのCLSID(値はIIDと同一)のキーが作成されます。これはそのサーバーがプロキシ/スタブDLLであることを示す指標です。PSFactoryBufferという言葉は、プロキシ/スタブDLLのクラスオブジェクトがIPSFactoryBufferを実装していることに由来していると思われます。