Unterschiede zwischen MIDL und MkTypLib

Anmerkung

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

 

Es gibt einige wichtige Bereiche, in denen sich der MIDL-Compiler von MkTypLib unterscheidet. Die meisten dieser Unterschiede ergeben sich, da MIDL eher auf C-Syntax ausgerichtet ist als MkTypLib.

Im Allgemeinen sollten Sie die MIDL-Syntax in Ihren IDL-Dateien verwenden. Wenn Sie jedoch eine vorhandene ODL-Datei kompilieren oder die Kompatibilität mit MkTypLib beibehalten müssen, verwenden Sie die /mktyplib203 MIDL-Compileroption, um das Verhalten von MIDL wie Mkktyplib.exe, Version 2.03, zu erzwingen. (Dies ist die letzte Version des MkTypLib-Tools.) Insbesondere löst die option /mktyplib203 die folgenden Unterschiede auf:

• typedef-Syntax für komplexe Datentypen

  In MkTypLib generieren beide der 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 eine TKIND_RECORD für "this_struct" und eine TKIND_ALIAS für "this_struct" (definieren von "this_struct" als Alias für "struct_tag"). Da das Tag in der zweiten Definition fehlt, generiert MIDL eine TKIND_RECORD für einen gehandelten Namen, intern in MIDL, der für den Benutzer nicht aussagekräftig ist, und eine TKIND_ALIAS für "that_struct".

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

  MIDL ermöglicht außerdem Struktur, Unionund Enumerationen Definitionen. Die folgende Definition ist beispielsweise in MIDL zulässig:

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

• Boolesche Datentypen

  In MkTypLib entsprechen der boolesche boolesche Basistyp und der MkTypLib-Datentyp BOOL VT_BOOL, die VARIANT_BOOL zugeordnet ist und als kurzedefiniert ist. In MIDL entspricht der boolesche Basistyp VT_UI1, der als nicht signierter Zeichendefiniert ist und der BOOL-Datentyp als langendefiniert ist. Dies führt zu Schwierigkeiten, 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 Marshallingcode nicht mit den in den Typinformationen beschriebenen Typen überein. Wenn Sie eine VT_BOOL in Ihrer Typbibliothek verwenden möchten, sollten Sie den VARIANT_BOOL Datentyp 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 fügt GUID-Vordefinitionen normalerweise in die generierten Headerdateien und GUID-Instanziierungen nur in der Datei ein, die von der Option /iid generiert wird.

Die folgenden Verhaltensunterschiede können nicht mithilfe des Schalters /mktyplib203 behoben werden:

• Groß-/Kleinschreibung

  BEI MIDL wird die Groß-/Kleinschreibung beachtet, OLE-Automatisierung ist 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. Beispielsweise wird der folgende Code in MkTypLib kompiliert, generiert jedoch einen Doppelten Namensfehler in MIDL:

  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 jeden Typedef innerhalb dieses Schnittstellenblocks als öffentlich. MIDL erfordert, dass Sie das öffentliche-Attribut explizit auf diese Typtypen 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. In Anbetracht der folgenden ODL-Syntax verwendet Bibliothek C beispielsweise die MOO-Typedef aus Bibliothek A, wenn Sie mit MkTypLib kompilieren, und die MOO-Typdef 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 entsprechende Problemumgehung besteht darin, jeden solchen Verweis mit dem richtigen Namen der Importbibliothek wie folgt zu qualifizieren:

  typedef struct tagBAA
      {A.MOO y;}BAA
  

• VOID-Datentyp nicht erkannt

  MIDL erkennt die C-Sprache void Datentyp und erkennt 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 '''

• Exponentielle Notation

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

• LCID-Werte und -Konstanten

  Normalerweise berücksichtigt MIDL die LCID beim Analysieren von Dateien nicht. 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, /iidund Marshaling OLE-Datentypen.