Diferencias entre MIDL y MkTypLib

Nota

La herramienta Mktyplib.exe está obsoleta. Use el compilador MIDL en su lugar.

 

Hay algunas áreas clave en las que el compilador MIDL difiere de MkTypLib. La mayoría de estas diferencias surgen porque MIDL está orientado más hacia la sintaxis C que MkTypLib.

En general, querrá usar la sintaxis MIDL en los archivos IDL. Sin embargo, si necesita compilar un archivo ODL existente o mantener la compatibilidad con MkTypLib, use la opción del compilador MIDL /mktyplib203 para forzar que MIDL se comporte como Mkktyplib.exe, versión 2.03. (Esta es la última versión de la herramienta MkTypLib). En concreto, la opción /mktyplib203 resuelve estas diferencias:

• Sintaxis typedef para tipos de datos complejos

  En MkTypLib, ambas definiciones siguientes generan un TKIND_RECORD para "this_struct" en la biblioteca de tipos. La etiqueta "struct_tag" es opcional y, si se usa, no se mostrará en la biblioteca de tipos.

  typedef struct struct_tag { ... } this_struct;
  typedef struct { ... } that_struct;
  

  Si falta una etiqueta opcional, MIDL la generará, agregando eficazmente una etiqueta a la definición proporcionada por el usuario. Dado que la primera definición tiene una etiqueta, MIDL generará un TKIND_RECORD para "this_struct" y un TKIND_ALIAS para "this_struct" (definiendo "this_struct" como alias para "struct_tag"). Dado que falta la etiqueta en la segunda definición, MIDL generará un TKIND_RECORD para un nombre de mangled, interno a MIDL, que no es significativo para el usuario y un TKIND_ALIAS para "that_struct".

  Esto tiene posibles implicaciones para los exploradores de biblioteca de tipos que simplemente muestran el nombre de un registro en su interfaz de usuario. Si espera que un TKIND_RECORD tenga un nombre real, los nombres irreconocibles podrían aparecer en la interfaz de usuario. Este comportamiento también se aplica a las definiciones de unión y enumeración , con el compilador MIDL que genera TKIND_UNIONs y TKIND_ENUMs, respectivamente.

  MIDL también permite definiciones deenumeración, unión y estructura de estilo C. Por ejemplo, la definición siguiente es legal en MIDL:

  struct my_struct { ... };
  typedef struct my_struct your_struct;
  

• tipos de datos booleanos

  En MkTypLib, el tipo base booleano y el tipo de datos MkTypLib BOOL equivalen a VT_BOOL, que se asigna a VARIANT_BOOL, y que se define como un short. En MIDL, el tipo base booleano es equivalente a VT_UI1, que se define como un carácter sin signo, y el tipo de datos BOOL se define como un long. Esto da lugar a dificultades si mezcla la sintaxis IDL y la sintaxis de ODL en el mismo archivo mientras sigue intentando mantener la compatibilidad con MkTypLib. Dado que los tipos de datos son diferentes tamaños, el código de cálculo de referencias no coincidirá con lo que se describe en la información de tipo. Si desea un VT_BOOL en la biblioteca de tipos, debe usar el tipo de datos VARIANT_BOOL.

• Definiciones guid en archivos de encabezado

  En MkTypLib, los GUID se definen en el archivo de encabezado con una macro que se puede compilar condicionalmente para generar una predefinición GUID o un GUID creado por instancias. MIDL normalmente coloca las predefiniciones GUID en sus archivos de encabezado generados y las instancias guid solo en el archivo generado por el modificador /iid .

Las siguientes diferencias de comportamiento no se pueden resolver mediante el modificador /mktyplib203 :

• Distinción entre mayúsculas y minúsculas

  MIDL distingue mayúsculas de minúsculas, la automatización OLE no.

• Ámbito de símbolos en una declaración de enumeración

  En MkTypLib, el ámbito de los símbolos de una enumeración es local. En MIDL, el ámbito de los símbolos de una enumeración es global, como se encuentra en C. Por ejemplo, el código siguiente se compilará en MkTypLib, pero generará un error de nombre duplicado en MIDL:

  typedef struct { ... } a;
  enum {a=1, b=2, c=3};
  

• Ámbito del atributo público

  Si aplica el atributo público a un bloque de interfaz, MkTypLib trata cada definición de tipo dentro de ese bloque de interfaz como público. MIDL requiere que aplique explícitamente el atributo público a esas definiciones de tipo que desee públicas.

• Orden de búsqueda de Importlib

  Si importa más de una biblioteca de tipos y estas bibliotecas contienen referencias duplicadas, MkTypLib lo resuelve mediante la primera referencia que encuentra. MIDL usará la última referencia que encuentra. Por ejemplo, dada la siguiente sintaxis de ODL, la biblioteca C usará la definición de tipo MOO de la biblioteca A si compila con MkTypLib y la definición de tipo MOO de la biblioteca B si compila con MIDL:

  [...]library A
  {
      typedef struct tagMOO
      {...}MOO
  }
  
  [...]library B
  {
      typedef struct tagMOO
      {...} MOO
  }
  
  [...]library C
  {
      importlib (A.TLB)
      importlib (B.TLB)
      typedef struct tagBAA
      {MOO y;}BAA
  }
  

  La solución adecuada para esto es calificar cada una de estas referencias con el nombre de biblioteca de importación correcto, de la siguiente manera:

  typedef struct tagBAA
      {A.MOO y;}BAA
  

• Tipo de datos VOID no reconocido

  MIDL reconoce el tipo de datos void del lenguaje C y no reconoce el tipo de datos OLE Automation VOID. Si tiene un archivo ODL que usa VOID, coloque esta definición en la parte superior del archivo:

#define VOID void '''

• Notación exponencial

  MIDL requiere que los valores expresados en notación exponencial estén incluidos entre comillas. Por ejemplo, "-2.5E+3"

• Valores y constantes de LCID

  Normalmente MIDL no tiene en cuenta el LCID al analizar archivos. Para forzar este comportamiento para un valor, o si necesita usar la notación específica de la configuración regional al definir una constante, incluya el valor o la constante entre comillas.

Para obtener más información, vea /mktyplib203, /iid y Serialización de tipos de datos OLE.