Diferencias entre MIDL y MkTypLib

Nota

La herramienta Mktyplib.exe está obsoleta. En su lugar, use el compilador MIDL.

 

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 el /mktyplib203 opción del compilador MIDL 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. Puesto 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 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 bibliotecas 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 no reconocidos podrían aparecer en la interfaz de usuario. Este comportamiento también se aplica a definiciones de de unión y enumeración, con el compilador MIDL que genera TKIND_UNIONs y TKIND_ENUMs, respectivamente.

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

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

• Tipos de datos booleanos

  En MkTypLib, el tipo base de booleano y el tipo de datos MkTypLib equivalen a VT_BOOL, que se asigna a VARIANT_BOOL, y que se define como un corto. En MIDL, el tipo base de booleano es equivalente a VT_UI1, que se define como un char sin signo y el tipo de datos BOOL se define como un long. Esto conduce a dificultades si combina la sintaxis IDL y la sintaxis de ODL en el mismo archivo mientras intenta 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 un GUID predefinition o un GUID creado por instancias. MIDL normalmente coloca predefiniciones GUID en sus archivos de encabezado generados y instancias GUID solo en el archivo generado por el modificador de/iid.

No se pueden resolver las siguientes diferencias en el comportamiento mediante el modificador de/mktyplib203:

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

  MIDL distingue mayúsculas de minúsculas, ole Automation 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ública.

• Orden de búsqueda de importlib

  Si importa más de una biblioteca de tipos y, si 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 tipos 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 alternativa 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 lenguaje C void tipo de datos 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 se incluyan 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, /iidy Serialización de tipos de datos OLE.