Ziehpunkte

Bis zu zwei Teile in der Formatzeichenfolgenbeschreibung eines Prozeduradresshandles. Der erste Teil ist das handle_type<1-Feld> der Beschreibung einer Prozedur, das verwendet wird, um implizite Handles anzugeben. Dieser Teil ist immer vorhanden. Der zweite Teil ist eine Parameterbeschreibung eines expliziten Handles in der Prozedur. Beide werden in den folgenden Abschnitten erläutert, zusammen mit einer Erläuterung der zusätzlichen MIDL-Compilerunterstützung der Stub-Deskriptorstruktur für Bindungshandles.

Implizite Handles

Wenn eine Prozedur ein implizites Handle für die Bindung verwendet, enthält das feld handle_type<1> der Beschreibung der Prozedur einen von drei gültigen Werten ungleich null. Unterstützung des MIDL-Compilers für implizite Handles finden Sie im Feld IMPLICIT_HANDLE_INFO der Stub-Deskriptorstruktur:

typedef  (__RPC_FAR * GENERIC_BINDING_ROUTINE)();

typedef struct 
  {
  GENERIC_BINDING_ROUTINE  pfnBind;
  GENERIC_BINDING_ROUTINE  pfnUnbind;
  } GENERIC_BINDING_ROUTINE_PAIR;
  
typedef struct __GENERIC_BINDING_INFO 
  {
  void __RPC_FAR*          pObj;
  unsigned char            Size;
  GENERIC_BINDING_ROUTINE  pfnBind;
  GENERIC_BINDING_ROUTINE    pfnUnbind;
  } GENERIC_BINDING_INFO,  *PGENERIC_BINDING_INFO;

union 
  {
  handle_t*                pAutoHandle;
  handle_t*                pPrimitiveHandle;
  PGENERIC_BINDING_INFO    pGenericBindingInfo;
  } IMPLICIT_HANDLE_INFO;

Wenn die Prozedur ein automatisches Handle verwendet, enthält das pAutoHandle-Element die Adresse der variablen stub defined-auto handle.

Wenn die Prozedur ein implizites primitives Handle verwendet, enthält der pPrimitiveHandle-Member die Adresse der handle-Variablen vom Typ "stub defined-primitive".

Wenn die Prozedur schließlich ein implizites generisches Handle verwendet, enthält das pGenericBindingInfo-Element die Adresse des Zeigers auf die entsprechende GENERIC_BINDING_INFO-Struktur . Die Datenstruktur MIDL_STUB_DESC enthält einen Zeiger auf eine Auflistung von GENERIC_BINDING_PAIR Strukturen. Der Eintrag an der Nullposition dieser Auflistung ist für die Bindungs- und Nichtbindungsroutinen reserviert, die dem generischen Bindungshandle entsprechen, auf das von pGenericBindingInfo in IMPLICIT_HANDLE_INFO verwiesen wird. Der Typ des impliziten Bindungshandles wird in der Formatzeichenfolge angegeben.

Explizite Handles

Es gibt drei mögliche explizite Handletypen: kontext, generisch und primitiv. Bei einem expliziten Handle (oder einem reinen [out]-Kontexthandle, das auf die gleiche Weise behandelt wird), werden die Informationen zum Bindungshandle als einer der Parameter der Prozedur angezeigt. Die drei möglichen Beschreibungen sind wie folgt:

Primitiv

FC_BIND_PRIMITIVE, flag<1>, offset<2>.

Das Flag<1> gibt an, ob das Handle von einem Zeiger übergeben wird.

Der Offset<2> stellt den Offset vom Anfang des Stapels bis zum primitiven Handle bereit.

Hinweis

Eine primitive Handlebeschreibung in der Typformatzeichenfolge wird auf eine einzelne FC_IGNORE reduziert.

 

Allgemein

FC_BIND_GENERIC, flag_and_size<1>, offset<2>, binding_routine_pair_index<1>, FC_PAD

Die flag_and _size<1> hat die obere Flagge knabbernd und die untere Größe knabbernd. Das Flag gibt an, ob das Handle von einem Zeiger übergeben wird. Das Feld größe gibt die Größe des vom Benutzer definierten generischen Handletyps an. Diese Größe ist auf 1, 2 oder 4 Bytes auf 32-Bit-Systemen und 1, 2, 4 oder 8 Bytes auf 64-Bit-Systemen beschränkt.

Das Feld Offset<2> stellt den Offset vom Anfang des Stapels des Zeigers auf die Daten der angegebenen Größe bereit.

Das Feld binding_routine_pair_index<1> gibt den Index im Feld aGenericBindingRoutinePairs des Stub-Deskriptors an die Zeiger der Bindungs - und nicht gebundenen Routinefunktion für das generische Handle.

Hinweis

Eine generische Handlebeschreibung im Typformat ist nur die Beschreibung des zugehörigen Datentyps.

 

Kontext

FC_BIND_CONTEXT flags<1> offset<2> context_rundown_routine_index<1> param_num<1>

Die Flags<1> geben an, wie das Handle übergeben wird und welchen Typ es hat. Gültige Flags werden in der folgenden Tabelle angezeigt.

Hex Flag
80 HANDLE_PARAM_IS_VIA_PTR
40 HANDLE_PARAM_IS_IN
20 HANDLE_PARAM_IS_OUT
21 HANDLE_PARAM_IS_RETURN
08 NDR_STRICT_CONTEXT_HANDLE
04 NDR_CONTEXT_HANDLE_NO_SERIALIZE
02 NDR_CONTEXT_HANDLE_SERIALIZE
01 NDR_CONTEXT_HANDLE_CANNOT_BE_NULL

 

Die ersten vier Flags waren immer vorhanden, die letzten vier wurden in Windows 2000 hinzugefügt.

Das Feld offset<2> stellt den Offset vom Anfang des Stapels bis zum Kontexthandle bereit.

Der context_rundown_routine_index<1> stellt einen Index im Feld apfnNdrRundownRoutines des Stub-Deskriptors für die Rundownroutine bereit, die für dieses Kontexthandle verwendet wird. Der Compiler generiert immer einen Index. Für Routinen ohne Rundownroutine ist dies ein Index für eine Tabellenposition, die NULL enthält.

Für stubs, die in –Oi2 erstellt wurden, stellt die param_num<1> die Ordnungszahl bereit, beginnend bei Null, und gibt an, welches Kontexthandle es in der angegebenen Prozedur ist.

Bei früheren Versionen des Interpreters stellt der param_num<1> die Parameternummer des Kontexthandles bereit, beginnend bei Null, in seiner Prozedur.

Hinweis

Eine Beschreibung des Kontexthandles in der Typformatzeichenfolge enthält nicht den Offset<2> in der Beschreibung.

 

Der neue -Oif-Header

Wie bereits erwähnt, wird der -Oif-Header im -Oi-Header erweitert. Der Einfachheit halber werden hier alle Felder angezeigt:

(Der alte Header)

handle_type<1> 
Oi_flags<1>
[rpc_flags<4>]
proc_num<2>  
stack_size<2>
[explicit_handle_description<>]

(Die -Oif-Erweiterungen )

constant_client_buffer_size<2>
constant_server_buffer_size<2>
INTERPRETER_OPT_FLAGS<1>
number_of_params<1>

Der constant_client_buffer_size<2> gibt die Größe des Marshallingpuffers an, der vom Compiler vorab berechnet worden sein könnte. Dies kann nur eine Teilgröße sein, da das ClientMustSize-Flag die Größenanpassung auslöst.

Der constant_server_buffer_size<2> stellt die Größe des Marshallingpuffers bereit, wie vom Compiler vorberechnet. Dies kann nur eine Teilgröße sein, da das ServerMustSize-Flag die Größenanpassung auslöst.

Die INTERPRETER_OPT_FLAGS werden in Ndrtypes.h definiert:

typedef struct
  {
  unsigned char   ServerMustSize      : 1;    // 0x01
  unsigned char   ClientMustSize      : 1;    // 0x02
  unsigned char   HasReturn           : 1;    // 0x04
  unsigned char   HasPipes            : 1;    // 0x08
  unsigned char   Unused              : 1;
  unsigned char   HasAsyncUuid        : 1;    // 0x20
  unsigned char   HasExtensions       : 1;    // 0x40
  unsigned char   HasAsyncHandle      : 1;    // 0x80
  } INTERPRETER_OPT_FLAGS, *PINTERPRETER_OPT_FLAGS;
  • Das ServerMustSize-Bit wird festgelegt, wenn der Server einen Pufferanpassungsdurchlauf ausführen muss.
  • Das ClientMustSize-Bit wird festgelegt, wenn der Client einen Pufferanpassungsdurchlauf ausführen muss.
  • Das HasReturn-Bit wird festgelegt, wenn die Prozedur über einen Rückgabewert verfügt.
  • Das HasPipes-Bit wird festgelegt, wenn das Pipepaket zur Unterstützung eines Pipearguments verwendet werden muss.
  • Das HasAsyncUuid-Bit wird festgelegt, wenn die Prozedur eine asynchrone DCOM-Prozedur ist.
  • Das HasExtensions-Bit gibt an, dass Erweiterungen für Windows 2000 und höher verwendet werden.
  • Das HasAsyncHandle-Bit gibt eine asynchrone RPC-Prozedur an.

Das HasAsyncHandle-Bit wurde ursprünglich für eine andere DCOM-Implementierung der asynchronen Unterstützung verwendet und konnte daher nicht für die aktuelle asynchrone Formatunterstützung in DCOM verwendet werden. Das HasAsyncUuid-Bit gibt dies derzeit an.