Unterschiede zwischen MIDL und MkTypLib

Hinweis

Das Mktyplib.exe-Tool ist veraltet. Verwenden Sie stattdessen den MIDL-Compiler.

 

Es gibt einige Schlüsselbereiche, in denen sich der MIDL-Compiler von MkTypLib unterscheidet. Die meisten dieser Unterschiede ergeben sich, weil MIDL mehr an C-Syntax als an MkTypLib ausgerichtet ist.

Im Allgemeinen sollten Sie die MIDL-Syntax in Ihren IDL-Dateien verwenden. Wenn Sie jedoch eine vorhandene ODL-Datei kompilieren oder anderweitig die Kompatibilität mit MkTypLib beibehalten müssen, verwenden Sie die MIDL-Compileroption /mktyplib203 , um zu erzwingen, dass sich MIDL wie Mkktyplib.exe, Version 2.03, verhält. (Dies ist das letzte Release des MkTypLib-Tools.) Insbesondere werden diese Unterschiede durch die Option /mktyplib203 behoben:

• typedef-Syntax für komplexe Datentypen

  In MkTypLib generieren die beiden folgenden Definitionen eine TKIND_RECORD für "this_struct" in der Typbibliothek. Das Tag "struct_tag" ist optional und wird bei Verwendung nicht in der Typbibliothek angezeigt.

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

  Wenn ein optionales Tag fehlt, generiert MIDL es und fügt der vom Benutzer bereitgestellten Definition effektiv ein Tag hinzu. Da die erste Definition über ein Tag verfügt, generiert MIDL einen TKIND_RECORD für "this_struct" und einen TKIND_ALIAS für "this_struct" (definiert "this_struct" als Alias für "struct_tag"). Da das Tag in der zweiten Definition fehlt, generiert MIDL einen TKIND_RECORD für einen in MIDL internen, für den Benutzer nicht aussagekräftigen Namen und einen TKIND_ALIAS für "that_struct".

  Dies hat potenzielle Auswirkungen auf Typbibliotheksbrowser, die einfach den Namen eines Datensatzes in ihrer Benutzeroberfläche anzeigen. Wenn Sie erwarten, dass ein TKIND_RECORD einen richtigen Namen hat, können nicht wiedererkennbare Namen auf der Benutzeroberfläche angezeigt werden. Dieses Verhalten gilt auch für Unions- und Enumerationsdefinitionen, wobei der MIDL-Compiler TKIND_UNIONs bzw. TKIND_ENUMs generiert.

  MIDL ermöglicht auch Struktur-, Union- und Enumerationsdefinitionen im C-Stil. Beispielsweise ist die folgende Definition in MIDL legal:

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

• Boolean-Datentypen

  In MkTypLib entsprechen der boolesche Basistyp und der MkTypLib-Datentyp BOOL VT_BOOL, der VARIANT_BOOL zugeordnet ist und als Kurz definiert ist. In MIDL entspricht der boolesche Basistyp VT_UI1, der als zeichenloses Zeichen definiert ist, und der BOOL-Datentyp ist als long definiert. Dies führt zu Problemen, wenn Sie IDL-Syntax und ODL-Syntax in derselben Datei kombinieren und gleichzeitig versuchen, die Kompatibilität mit MkTypLib aufrechtzuerhalten. Da die Datentypen unterschiedliche Größen aufweisen, stimmt der Marshallcode nicht mit dem in den Typinformationen beschriebenen Code überein. Wenn Sie eine VT_BOOL in Ihrer Typbibliothek wünschen, sollten Sie den datentyp VARIANT_BOOL verwenden.

• GUID-Definitionen in Headerdateien

  In MkTypLib werden GUIDs in der Headerdatei mit einem Makro definiert, das bedingt kompiliert werden kann, um entweder eine GUID-Vordefinition oder eine instanziierte GUID zu generieren. MIDL platziert GUID-Vordefinitionen normalerweise nur in den generierten Headerdateien und GUID-Instanziierungen in der Datei, die durch die / iid-Option generiert wird.

Die folgenden Verhaltensunterschiede können nicht mit dem Schalter /mktyplib203 behoben werden:

• Groß- und Kleinschreibung

  BEI MIDL wird die Groß-/Kleinschreibung beachtet, ole Automation nicht.

• Bereich von Symbolen in einer Enumerationsdeklaration

  In MkTypLib ist der Bereich der Symbole in einer Enumeration lokal. In MIDL ist der Bereich von Symbolen in einer Enumeration global, wie in C. Der folgende Code kompiliert z. B. in MkTypLib, generiert aber in MIDL einen Fehler mit doppeltem Namen:

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

• Bereich des öffentlichen Attributs

  Wenn Sie das öffentliche Attribut auf einen Schnittstellenblock anwenden, behandelt MkTypLib jede Typedef innerhalb dieses Schnittstellenblocks als öffentlich. MIDL erfordert, dass Sie das öffentliche Attribut explizit auf die Typdefinitionen anwenden, die öffentlich sein sollen.

• Importlib-Suchreihenfolge

  Wenn Sie mehrere Typbibliotheken importieren und diese Bibliotheken doppelte Verweise enthalten, löst MkTypLib dies mithilfe des ersten gefundenen Verweises auf. MIDL verwendet den letzten Gefundenen Verweis. Bei der folgenden ODL-Syntax verwendet die Bibliothek C beispielsweise die MOO-Typedef aus der Bibliothek A, wenn Sie mit MkTypLib kompilieren, und die MOO-Typedef aus Bibliothek B, wenn Sie mit MIDL kompilieren:

  [...]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
  }
  

  Die geeignete Problemumgehung hierfür besteht darin, jeden solchen Verweis mit dem richtigen Importbibliotheksnamen wie folgt zu qualifizieren:

  typedef struct tagBAA
      {A.MOO y;}BAA
  

• VOID-Datentyp nicht erkannt

  MIDL erkennt den Void-Datentyp in der C-Sprache und den OLE Automation VOID-Datentyp nicht. Wenn Sie über eine ODL-Datei verfügen, die VOID verwendet, platzieren Sie diese Definition am Anfang der Datei:

#define VOID void '''

• Exponentialschreibweise

  MIDL erfordert, dass werte, die in exponentieller Notation ausgedrückt werden, in Anführungszeichen enthalten sind. Beispiel: "-2.5E+3"

• LCID-Werte und Konstanten

  Normalerweise berücksichtigt MIDL beim Analysieren von Dateien nicht die LCID. Um dieses Verhalten für einen Wert zu erzwingen, oder wenn Sie beim Definieren einer Konstante gebietsschemaspezifische Notation verwenden müssen, schließen Sie den Wert oder die Konstante in Anführungszeichen ein.

Weitere Informationen finden Sie unter /mktyplib203, /iid und Marshallen von OLE-Datentypen.