Asas
Hasta dos partes en la descripción de cadena de formato de un identificador de dirección de procedimiento. La primera parte es el campo handle_type<1> de la descripción de un procedimiento, que se usa para indicar identificadores implícitos. Esta parte siempre está presente. La segunda parte es una descripción de parámetro de cualquier identificador explícito en el procedimiento. Ambos se explican en las secciones siguientes, junto con una explicación de la compatibilidad adicional del compilador MIDL de la estructura descriptor de código auxiliar para controlar problemas de enlace.
Identificadores implícitos
Si un procedimiento usa un identificador implícito para el enlace, el campo handle_type<1> de la descripción del procedimiento contiene uno de los tres valores no cero válidos. La compatibilidad del compilador MIDL con identificadores implícitos se encuentra en el campo IMPLICIT_HANDLE_INFO de la estructura del descriptor de código auxiliar:
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;
Si el procedimiento usa un identificador automático, el miembro pAutoHandle contiene la dirección de la variable de identificador definido del código auxiliar definido.auto.
Si el procedimiento usa un identificador primitivo implícito, el miembro pPrimitiveHandle contiene la dirección de la variable de identificador definida-primitiva de código auxiliar.
Por último, si el procedimiento usa un identificador genérico implícito, el miembro pGenericBindingInfo contiene la dirección del puntero a la estructura de GENERIC_BINDING_INFO correspondiente. La estructura de datos MIDL_STUB_DESC contiene un puntero a una colección de estructuras de GENERIC_BINDING_PAIR . La entrada en la posición cero de esta colección está reservada para las rutinas de enlace y unbind correspondientes al identificador de enlace genérico al que hace referencia pGenericBindingInfo en IMPLICIT_HANDLE_INFO. El tipo de identificador de enlace implícito se indica en la cadena de formato.
Identificadores explícitos
Hay tres tipos de identificadores explícitos posibles: context, generic y primitive. En el caso de un identificador explícito (o un identificador de contexto [out], que se controla de la misma manera), la información del identificador de enlace aparece como uno de los parámetros del procedimiento. Las tres descripciones posibles son las siguientes.
Primitivo
FC_BIND_PRIMITIVE, flag<1>, offset<2>.
La marca<1> indica si un puntero pasa el identificador.
El desplazamiento<2> proporciona el desplazamiento desde el principio de la pila hasta el identificador primitivo.
Nota:
Una descripción de identificador primitivo en la cadena de formato de tipo se reduce a una sola FC_IGNORE.
Genérico
FC_BIND_GENERIC, flag_and_size<1>, offset<2>, binding_routine_pair_index<1>, FC_PAD
El flag_and _size<1> tiene el nibble de la marca superior y el nibble de tamaño inferior. La marca indica si un puntero pasa el identificador. El campo size proporciona el tamaño del tipo de identificador genérico definido por el usuario. Este tamaño se limita a 1, 2 o 4 bytes en sistemas de 32 bits y 1, 2, 4 o 8 bytes en sistemas de 64 bits.
El campo offset<2> proporciona el desplazamiento desde el principio de la pila del puntero a los datos del tamaño especificado.
El campo binding_routine_pair_index<1> proporciona el índice en el campo aGenericBindingRoutinePairs del descriptor de código auxiliar para los punteros de función rutinaria de enlace y desenlace para el identificador genérico.
Nota:
Una descripción de identificador genérica en el formato de tipo es la descripción del tipo de datos relacionado únicamente.
Context
FC_BIND_CONTEXT flags<1> offset<2> context_rundown_routine_index<1> param_num<1>
Las marcas<1> indican cómo se pasa el identificador y qué tipo es. Las marcas válidas se muestran en la tabla siguiente.
| Hex | Marca |
|---|---|
| 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 |
Las cuatro primeras marcas siempre han estado presentes, las cuatro últimas se agregaron en Windows 2000.
El campo offset<2> proporciona el desplazamiento desde el principio de la pila hasta el identificador de contexto.
El context_rundown_routine_index<1> proporciona un índice en el campo apfnNdrRundownRoutines del descriptor de código auxiliar a la rutina de detención utilizada para este identificador de contexto. El compilador siempre genera un índice. En el caso de las rutinas que no tienen una rutina de detención, se trata de un índice a una posición de tabla que contiene null.
En el caso de los códigos auxiliares integrados en –Oi2, el param_num<1> proporciona el recuento ordinal, empezando por cero, especificando qué identificador de contexto se encuentra en el procedimiento especificado.
Para las versiones anteriores del intérprete, el param_num<1> proporciona el número de parámetro del identificador de contexto, empezando por cero, en su procedimiento.
Nota:
Una descripción del identificador de contexto en la cadena de formato de tipo no tendrá el desplazamiento<2> en la descripción.
Nuevo encabezado –Oif
Como se mencionó anteriormente, el encabezado –Oif se expande en el encabezado –Oi . Para mayor comodidad, aquí se muestran todos los campos:
(El encabezado anterior)
handle_type<1>
Oi_flags<1>
[rpc_flags<4>]
proc_num<2>
stack_size<2>
[explicit_handle_description<>]
(Extensiones –Oif )
constant_client_buffer_size<2>
constant_server_buffer_size<2>
INTERPRETER_OPT_FLAGS<1>
number_of_params<1>
El constant_client_buffer_size<2> proporciona el tamaño del búfer de serialización que el compilador podría haber calculado previamente. Esto puede ser solo un tamaño parcial, ya que la marca ClientMustSize desencadena el ajuste de tamaño.
El constant_server_buffer_size<2> proporciona el tamaño del búfer de serialización como precomputado por el compilador. Esto puede ser solo un tamaño parcial, ya que la marca ServerMustSize desencadena el ajuste de tamaño.
El INTERPRETER_OPT_FLAGS se define en Ndrtypes.h:
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;
- El bit ServerMustSize se establece si el servidor debe realizar un paso de ajuste de tamaño del búfer.
- El bit ClientMustSize se establece si el cliente necesita realizar un paso de ajuste de tamaño del búfer.
- El bit HasReturn se establece si el procedimiento tiene un valor devuelto.
- El bit HasPipes se establece si el paquete de canalización debe usarse para admitir un argumento de canalización.
- El bit HasAsyncUuid se establece si el procedimiento es un procedimiento DCOM asincrónico.
- El bit HasExtensions indica que se usan extensiones de Windows 2000 y posteriores.
- El bit HasAsyncHandle indica un procedimiento RPC asincrónico.
El bit HasAsyncHandle se ha usado inicialmente para una implementación DCOM diferente de compatibilidad asincrónica y, por tanto, no se pudo usar para la compatibilidad asincrónica de estilo actual en DCOM. El bit HasAsyncUuid indica actualmente esto.
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de