情報非表示の回避

プログラムが意図的に、または誤って RPC マーシャリング エンジンから情報を非表示にすることがあります。 いくつかの例を次に示します。

• データ構造を未分化バイト ブロックとして送信する
• メソッドの副作用を使用してネットワーク経由で追加のデータをチャネル化することでパフォーマンスを活用する
• ハンドルを DWORD または ULONG として渡すことで偽装を試みる

これらの手法は、アプリケーションを 64 ビット Windows に移植する前でも、互換性の問題が発生することがほぼ保証されています。

標準のリモート プロシージャ 呼び出しでサーバー コンテキストを DWORD として送信する代わりに、コンテキスト ハンドルを使用して、クライアントの代わりに保持されているサーバー コンテキストに不透明なハンドルを提供します。 コンテキストは、サーバーがクライアントのコンテキスト ハンドルを作成するときに、RPC ランタイムによって定義された GUID によって識別されます。 ワイヤ上ではポインターは使用されず、操作は 32 ビットまたは 64 ビットの境界を越えて完全に透過的です。 コンテキスト ハンドルの使用の詳細については、「コンテキスト ハンドル」を参照してください。

COM は独自のコンテキスト管理を提供するため、DCOM インターフェイスではコンテキスト ハンドルを使用できません。 コンテキスト ハンドルを作成する代わりに、COM オブジェクトへのインターフェイス ポインターを渡すことができます。 その後、インターフェイス ポインターを介してメソッドを直接呼び出すか、他の呼び出し内にポインターを配置できます。 サーバー オブジェクトを解放するために、クライアントはインターフェイス ポインターを介してインターフェイスの Release メソッドを呼び出します。

ここでも、移植するコードの元のデザインを変更できない場合があります。 ワイヤ全体にポインターを DWORD として送信しないようにする方法がない場合は、 DWORD 値とポインターの間に何らかの形式のサーバー側マッピングを実装する必要があります。 これを行う方法の 1 つは、クライアント側アプリケーションのポインターを、 ULONG_PTR や DWORD_PTRなどのポインター精度型に変更することです。 次に、MIDL [call_as] 属性を使用して、ポインターを DWORD 値としてワイヤに配置します。 クライアント側ラッパーは、引数を渡すだけで済みます。 サーバー側ラッパーは、両方の型間のマッピングを処理します。 同様の方法で、[transmit_as] 属性または [represent_as] 属性を使用して、データをワイヤ表現の下位互換性のある形式に変換できます。

下位線の互換性が問題ではない場合、またはハンドルがリモート呼び出しに使用されておらず、32 ビットから 64 ビットのプロセス間のリモート呼び出しが発生しないことを確認している場合は、引数を ULONG64 として再定義できます。 必要に応じて、ユーザーに DWORD を渡すために 32 ビット アプリケーションを変更できます。 または、32 ビット Windows の DWORD と 64 ビット Windows の ULONG64 を使用して、プラットフォームごとに個別の IDL ファイルから個別のスタブを作成することもできます。