Freigeben über


Griffe

So viele wie zwei Teile in der Formatzeichenfolgenbeschreibung eines Prozeduradressenhandles. 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 Descriptor-Struktur für bindungshandle Probleme.

Implizite Handles

Wenn eine Prozedur ein implizites Handle für die Bindung verwendet, enthält das handle_type<1> Feld der Beschreibung der Prozedur einen von drei gültigen Nichtzerowerten. DIE MIDL-Compilerunterstützung für implizite Handles befindet sich im IMPLICIT_HANDLE_INFO Feld 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 Member die Adresse der variablen stub-automatischen Handle.

Wenn die Prozedur ein implizites Grundtyphandle verwendet, enthält das pPrimitiveHandle Member die Adresse der variablen stub-primitiven Handle.

Wenn die Prozedur ein implizites generisches Handle verwendet, enthält die pGenericBindingInfo- Member die Adresse des Zeigers auf die entsprechende GENERIC_BINDING_INFO Struktur. Die Datenstruktur MIDL_STUB_DESC enthält einen Zeiger auf eine Sammlung von GENERIC_BINDING_PAIR Strukturen. Der Eintrag in der Nullposition dieser Auflistung ist für die Bindung reserviert und nicht gebundenen Routinen, die dem generischen Bindungshandle entsprechen, auf das durch pGenericBindingInfo- in IMPLICIT_HANDLE_INFOverwiesen wird. Der Typ des impliziten Bindungshandles wird in der Formatzeichenfolge angegeben.

Explizite Handles

Es gibt drei mögliche explizite Handletypen: Kontext, Generika und Grundtyp. Im Falle eines expliziten Handles (oder eines [aus] nur Kontexthandle, das auf die gleiche Weise behandelt wird), werden die Informationen zum Bindungshandle als 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 der Handle von einem Zeiger übergeben wird.

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

Anmerkung

Eine Beschreibung des primitiven Handles in der Typformatzeichenfolge wird auf ein einzelnes FC_IGNORE reduziert.

 

Generisch

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 nibel und die untere Größe nibble. Das Flag gibt an, ob das Handle von einem Zeiger übergeben wird. Das Feld "Größe" stellt die Größe des benutzerdefinierten, generischen Handletyps bereit. 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.

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

Das Feld binding_routine_pair_index<1> gibt den Index in das Feld "GenericBindingRoutinePairs" des Stub-Deskriptors an die Bindung und nicht gebundenen Routinefunktionszeiger für den generischen Handle an.

Anmerkung

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

 

Zusammenhang

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

Die Flags<1> angeben, wie der Handle übergeben wird und welcher Typ es ist. Gültige Flags werden in der folgenden Tabelle angezeigt.

Fluch Flagge
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.

Der Offset<2> Felds stellt den Offset vom Anfang des Stapels bis zum Kontextziehpunkt bereit.

Die context_rundown_routine_index<1> stellt einen Index in den apfnNdrRundownRoutines Feld des Stub-Deskriptors für die für dieses Kontexthandle verwendete Ausführungsroutine bereit. Der Compiler generiert immer einen Index. Bei Routinen, die keine Ausführungsroutine aufweisen, ist dies ein Index zu einer Tabellenposition, die NULL enthält.

Für Stubs, die in –Oi2integriert sind, stellt die param_num<1> die Ordnungszahl ab 0 bereit, wobei angegeben wird, welches Kontexthandle es in der angegebenen Prozedur ist.

Bei früheren Versionen des Interpreters stellt das param_num<1> die Parameternummer des Kontexthandles ab 0 in seiner Prozedur bereit.

Anmerkung

Eine Beschreibung des Kontexthandle in der Typformatzeichenfolge verfügt nicht über den Offset<2> in der Beschreibung.

 

Die neue Oif-Kopfzeile

Wie bereits erwähnt, wird die kopfzeile –Oif auf der kopfzeile –Oi erweitert. Zur Vereinfachung werden alle Felder hier angezeigt:

(Die alte Kopfzeile)

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>

Die constant_client_buffer_size<2> stellt die Größe des Marshallingpuffers bereit, 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.

Die constant_server_buffer_size<2> stellt die Größe des Marshallingpuffers bereit, wie vom Compiler vorkompiliert. 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;
  • Der ServerMustSize-Bit wird festgelegt, wenn der Server einen Puffergrößendurchlauf ausführen muss.
  • Der ClientMustSize-Bit wird festgelegt, wenn der Client einen Puffergrößendurchlauf 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 verwendet werden muss, um ein Pipe-Argument zu unterstützen.
  • Das HasAsyncUuid-Bit wird festgelegt, wenn es sich bei der Prozedur um eine asynchrone DCOM-Prozedur handelt.
  • Das HasExtensions-Bit gibt an, dass Windows 2000 und höhere Erweiterungen verwendet werden.
  • Das HasAsyncHandle-Bit gibt eine asynchrone RPC-Prozedur an.

Das HasAsyncHandle-Bit wurde zunächst für eine andere DCOM-Implementierung asynchroner Unterstützung verwendet und konnte daher nicht für die aktuelle asynchrone Stilunterstützung in DCOM verwendet werden. Das HasAsyncUuid-Bit gibt dies derzeit an.