Unterschiede zwischen MIDL und MkTypLib
Hinweis
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 treten auf, weil MIDL eher auf C-Syntax ausgerichtet ist als MkTypLib.
Im Allgemeinen möchten Sie die MIDL-Syntax in Ihren IDL-Dateien verwenden. Wenn Sie jedoch eine vorhandene ODL-Datei kompilieren oder die Kompatibilität mit MkTypLib anderweitig aufrechterhalten müssen, verwenden Sie die MIDL-Compileroption /mktyplib203, um das Verhalten von MIDL wie Mkktyplib.exe Version 2.03 zu erzwingen. (Dies ist die letzte Version des MkTypLib-Tools.) Insbesondere die Option /mktyplib203 löst diese Unterschiede:
typedef-Syntax für komplexe Datentypen
In MkTypLib generieren beide der folgenden Definitionen einen 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" (definieren "this _ struct" als Alias für "struct _ tag"). Da das Tag in der zweiten Definition fehlt, generiert MIDL einen TKIND _ RECORD für einen vermischen Namen, der für MIDL intern ist. Dies ist für den Benutzer und ein _ TKIND-ALIAS für "diese Struktur" nicht _ sinnvoll.
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 auch Struktur-, Union-und Enumerationsdefinitionen im C-Stil. Beispielsweise ist die folgende Definition in MIDL zulässig:
struct my_struct { ... }; typedef struct my_struct your_struct;Boolean-Datentypen
In MkTypLib entsprechen der boolesche Basistyp und der MkTypLib-Datentyp BOOL VT _ BOOL, das VARIANT BOOL zugeordnet _ ist und als kurzdefiniert ist. In MIDL entspricht der boolesche Basistyp der VT _ UI1, die als char ohne Vorzeichendefiniert ist, und der BOOL-Datentyp ist als longdefiniert. Dies führt zu Schwierigkeiten, wenn Sie IDL-Syntax und ODL-Syntax in derselben Datei kombinieren und dennoch versuchen, die Kompatibilität mit MkTypLib aufrechtzuerhalten. Da die Datentypen unterschiedliche Größen aufweisen, entspricht der Marshallingcode nicht dem, was in den Typinformationen beschrieben wird. 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-Prädefinition oder eine instanziierte GUID zu generieren. MIDL fügt GUID-Prädefinitionen normalerweise nur in den vom Schalter /iid generierten Headerdateien und GUID-Instanziierungen in die Datei ein.
Die folgenden Unterschiede im Verhalten können nicht mithilfe des Schalters /mktyplib203 behoben werden:
Groß- und Kleinschreibung
Bei MIDL wird die Groß-/Kleinschreibung beachtet, ole-Automatisierung nicht.
Gültigkeitsbereich von Symbolen in einer Enumerationsdeklaration
In MkTypLib ist der Gültigkeitsbereich von Symbolen in einer Enumeration lokal. In MIDL ist der Gültigkeitsbereich von Symbolen in einer Enumeration global, wie in C. Der folgende Code wird z. B. in MkTypLib kompiliert, generiert jedoch einen Fehler aufgrund eines doppelten Namens 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 jede Typedef innerhalb dieses Schnittstellenblocks als öffentlich. MIDL erfordert, dass Sie das public-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. Wenn Sie beispielsweise die folgende ODL-Syntax verwenden, verwendet Bibliothek C die MOO-Typdefinition aus Bibliothek A, wenn Sie mit MkTypLib kompilieren, und die MOO-Typdefinition 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 hierfür besteht darin, jeden solchen Verweis wie folgt mit dem richtigen Namen der Importbibliothek zu qualifizieren:
typedef struct tagBAA {A.MOO y;}BAAVOID-Datentyp nicht erkannt
MIDL erkennt den void-Datentyp der C-Sprache und nicht den VOID-Datentyp der OLE-Automatisierung. 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 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 Marshallen von OLE-Datentypen.