DE69615637T2

DE69615637T2 - Verfahren zur objektorientierten Programmierung mit dynamischer Schnittstelle

Info

Publication number: DE69615637T2
Application number: DE69615637T
Authority: DE
Inventors: David A. Jordan
Original assignee: Intergraph Corp
Current assignee: Intergraph Corp
Priority date: 1995-11-03
Filing date: 1996-10-30
Publication date: 2002-07-11
Anticipated expiration: 2016-10-31
Also published as: EP0777177A1; EP0777177B1; DE69615637D1; US6016392A; US6237044B1

Description

Die vorliegende Erfindung bezieht sich auf die Zuweisung von Speicher in einem Computer auf Anwendungsebene. Insbesondere bezieht sich die Erfindung auf die Zuweisung von Speicher, um Objekte zu repräsentieren, die in einer objektorientierten Programmierumgebung unterstützt werden.
Das allgemeine Objektmodel (COM-Modell) ist eine sprach- und speicherstellenunabhängige Software-Spezifikation. Ein allgemeiner Überblick des COMs und des eng verbundenen Modells des Verknüpfens und Einbettens von Objekten (OLE) sind im folgenden dargestellt. COM und OLE sind in Inside OLE von Kraig Brockschmidt, veröffentlicht von Microsoft Press (1995, 2. Auflage) und in den hierin aufgelisteten Literaturhinweisen vollständig beschrieben. Die Veröffentlichung von Brockschmidt ist jedoch nicht Stand der Technik.
Da die C++-Sprache die objektorientierte Programmiersprache ist, die sich gegenwärtig der größten Akzeptanz unter den objektorientierten Programmierern erfreut, ist diese Erfindung in C++ beschrieben. Selbstverständlich kann jede Sprache, die den COM-Standard unterstützen kann, diese Erfindung und ihre Vorteile verwirklichen.
Das COM ist ein binärer Standard, dessen primäre Eigenschaft Objekte und die Schnittstellen sind, die speziellen Objekten zugeordnet sind. Eine Schnittstelle für ein Objekt ist eine Menge von Funktionen, um das Objekt zu manipulieren. Ein einzelnes Objekt besitzt typischerweise mehrere Schnittstellen. C++ kann sehr zweckmäßig COM-Objekte und -Schnittstellen (COM-Klassen) mit C++ -Klassen repräsentieren.
Das Definieren einer COM-Klasse erfolgt in zwei Schritten: der erste ist das Definieren der Instanzdaten der Objektklasse. Der zwei Schritt ist das Definieren einer Klasse für jede Schnittstelle der Objektklasse.
Die Schnittstellenimplementierungen sind C++-Klassen, die aus einer abstrakten Schnittstellendefinition abgeleitet sind.
Fig. 1 A veranschaulicht schematisch den Aufbau eines einzelnen Beispiel- COM-Objekts 1A00 entsprechend der herkömmlichen COM-Implementierung. Das Objekt 1A00 enthält einige Infrastruktur, wie z. B. einen Zeiger 1A10 auf die Schnittstelle der Unknown-Steuerung und einen Referenzzähler 1A20. Das Objekt 1A00 enthält außerdem die Anwendungsdaten 1A30. Ferner gibt es einen Zeiger 1A40 für jede Schnittstelle, die das Objekt 1A00 unterstützt, einschließlich der erforderlichen IUnknown-Schnittstelle. (Jeder Zeiger 1A40 zeigt direkt auf die vtable, die die Schnittstelle implementiert.) Für jede Schnittstelle, die das Objekt 1A00 unterstützt, weist die herkömmliche Implementierung ein entsprechendes Objekt 1A50 für die Schnittstelle zu. Diese herkömmliche und zweckmäßige Implementierung der COM-Schnittstellen nutzt die Fähigkeit von C++ für virtuelle Funktionen aus.
Die herkömmliche Implementierung besitzt jedoch eine Anzahl von Mängeln. Die Objekte, wie z. B. das Beispielobjekt 1A00 werden beim Hochfahren der Anwendung zugewiesen und initialisiert und verbleiben im Speicher der Anordnung, ungeachtet der Tatsache, daß die Anwendung das Objekt niemals verwenden wird und ungeachtet der Tatsache, daß zu irgendeinem gegebenen Zeitpunkt die Anwendung die meisten Objekte nicht verwenden wird. Deshalb erleidet die herkömmliche Implementierung die Speicherkosten von einem Zeiger 1A10 auf eine Steuerschnittstelle, des Referenzzählers 1A20, der Zeiger 1A40 und von einem Objekt 1A50 für jede Schnittstelle, die für ein Objekt unterstützt wird.
Demzufolge ist es eine Aufgabe dieser Erfindung, die Speicherkosten des Implementierens der COM-Objekte zu verringern.
Es ist eine weitere Aufgabe der Erfindung, die Programmierungsschnittstelle zum COM zu vereinfachen und eine umfangreiche Menge der wiederholten Infrastruktur des herkömmlichen COMs zu beseitigen.
Es ist eine noch weitere Aufgabe der Erfindung, die einzelnen Entwickler der Notwendigkeit zu entlasten, komplizierte Schemata zu entwerfen, um den Speicherverbrauch zu verringern.
Die Erfindung ist in den Ansprüchen definiert.
Der Erfindung ist eine Vorrichtung und ein Verfahren zum Zuweisen, Binden und Verwenden getrennter Blöcke des Speichers, um die Anwendungsdaten und die Infrastruktur des objektorientierten Programmierungsmodells eines Datenobjekts zu repräsentieren. Die Erfindung enthält das Bezugnehmen auf ein Objekt, das Zuweisen eines Objekt-Wrappers und dann das Binden das Objekt-Wrappers an das Objekt.
Die Erfindung ist im COM-Programmierungsmodell besonders nützlich. Dort enthält ein Objekt-Wrapper vorzugsweise die Adresse des Objekts, die Adresse einer Beschreibung der Klasse des Objekts, die Adresse der Unknown- Steuerung des Objekts und den Referenzzählstand für das Objekt.
In einer bevorzugten Ausführungsform hält dieses erste System die Beschreibungen jeder Objektklasse aufrecht, die im System verfügbar ist. Das Binden umfaßt das Auswählen der Beschreibung, die die Objektklasse des Objekts beschreibt, auf das Bezug genommen wird, aus diesen mehreren Beschreibungen, und dann das Verbinden des Objekt-Wrappers und der ausgewählten Beschreibung.
In den bevorzugten Ausführungsformen implementiert der Objekt-Wrapper lediglich eine Schnittstelle, die IUnknown-Schnittstelle, wobei er als der IUnknown- Wrapper bezeichnet wird.
Wenn das Objekt nach einer Schnittstelle abgefragt wird (die von der IUnknown-Schnittstelle verschieden ist), wird die Beschreibung der Objektklasse nach der Funktionstabelle der gewünschten Schnittstelle durchsucht. Falls die Schnittstelle vorhanden ist, wird ein zweiter Objekt-Wrapper, ein Schnittstellen- Wrapper, zugewiesen und initialisiert. Die Adresse des Schnittstellen-Wrappers wird als das Ergebnis der Abfrage zurückgeleitet.
Der Schnittstellen-Wrapper wird verwendet, um den Aufruf einer Funktion aus der Funktionstabelle der gewünschten Schnittstelle zu emulieren. Der durch den Kompilierer für die tatsächlich aufgerufene Funktion des Schnittstellen-Wrappers erzeugte Aufrufrahmen wird modifiziert, um einen Zeiger auf den Schnittstellen-Wrapper durch einen Zeiger auf das Objekt zu ersetzen. Die Funktion, deren Aufruf emuliert wird, wird dann ausgeführt.
Durch die Beseitigung der herkömmlichen vtable-Zeiger, der Referenzzähler, der Zeiger auf die Unknown-Steuerung und des anderen Zusatzaufwands von den Datenobjekten und statt dessen durch das vorübergehende Zuweisen dieser Strukturen zu Wrappern, während sich ein Objekt im Gebrauch befindet, verringert die Erfindung die Speicherkosten der Modellierungs-Datenobjekte als COM-Objekte.
Die Erfindung definiert außerdem Klassen durch das explizite Erklären ihrer Instanzdaten und durch das Bereitstellen einer Menge unabhängiger Schnittstellen. Demzufolge vereinfacht die Erfindung die Programmierungsschnittstelle zum COM und beseitigt viel der Infrastruktur des herkömmlichen COMs.
Fig. 1A ist eine schematische Veranschaulichung des Speicherverbrauchs eines COM-Objekts beim Hochfahren der Anwendung gemäß dem Stand der Technik;
Fig. 1B ist eine schematische Veranschaulichung des Speicherverbrauchs eines COM-Objekts beim Hochfahren der Anwendung gemäß der vorliegenden Erfindung;
Fig. 2A ist eine schematische Veranschaulichung eines Objekt-Wrappers;
Fig. 2B ist eine schematische Veranschaulichung eines Schnittstellen- Wrappers;
Fig. 3 veranschaulicht die Beziehung einer Typabbildung zu einem Datenobjekt;
Fig. 4 veranschaulicht die Inhalte einer Schnittstellenliste;
Fig. 5 ist ein Schema eines nicht modifizierten Stapels entsprechend der. Konvention für den Standard-Aufrufkompilierer; und
Fig. 6 ist ein Schema eines modifizierten Stapels entsprechend der Konvention für den Standard-Aufrufkompilierer.
Das System der dynamischen Schnittstellen der Erfindung wird durch eine Menge von Datenstrukturen unterstützt, die Informationen als Daten erfassen, die normalerweise als Code in COM-Implementierungen erfaßt werden. Es gibt im System der dynamischen Schnittstellen zwei statische Haupt-Datenstrukturen: eine Typabbildung mit Informationen darüber, welche Klassen unterstützt werden, und eine Schnittstellenliste mit Informationen darüber, welche Schnittstellen in jeder Klasse unterstützt werden. Es gibt zwei Typen von Objekt-Wrappern, der dynamischen Haupt-Datenstruktur: IUnknown-Wrapper und Schnittstellen-Wrapper. Eine Beschreibung der statischen Datenstrukturen folgt unmittelbar. Eine Beschreibung der dynamischen Datenstrukturen folgt weiter unten.
Eine Typabbildung ist die Wurzel der statischen Datenstrukturen der dynamischen Schnittstellen, wobei sie im wesentlichen eine Tabelle aller Klassen ist, die im System der dynamischen Schnittstellen enthalten ist. Dieses Objekt ist global.
In Fig. 3 ist die Typabbildung als ein Feld 310 implementiert, das durch die im folgenden erörterten ganzzahligen Identifizierer indexiert ist. Jeder Eintrag in der Typabbildung 310 ist ein Typabbildungs-Datensatz 312, der eine spezielle Klasse vollständig beschreibt. Ein Typabbildungs-Datensatz 312 für eine Klasse enthält die folgenden Informationen:
- einen Zeiger 316 auf eine Schnittstellenliste 314, die die Schnittstellen spezifiziert, die die Klasse unterstützt;
- die CLSID der Klasse; und
- den (nicht gezeigten) ganzzahligen Identifizierer der Klasse.
Das System verwendet die CLSID, um die primäre DLL der Klasse zu laden (durch CoGetClassObject).
(In einer alternativen Ausführungsform, in der die Klassen-Identifizierer größer als die ganzen Zwei-Byte-Zahlen sind, die hier unterstellt werden, ist die Typabbildung 310 vorzugsweise eine Hash-Tabelle.)
In Fig. 4 spezifiziert eine Schnittstellenliste 314 die Schnittstellen, die eine Klasse unterstützt. In einer bevorzugten Ausführungsform ist eine Schnittstellenliste 314 ein Feld 410 aus Zeigern 412 auf die Strukturen 414 für die Schnittstellendefinition. Eine Schnittstellendefinition 414 definiert die Implementierung einer Schnittstelle, wobei sie ein Tupel ist, das eine Schnittstellen-ID (IID) mit der vtable 416 paarweise anordnet, die die Schnittstellen implementiert.
Die Organisation einer vtable 416 ist Teil der OLE-Spezifikation. Demzufolge ist eine vtable 416 ein Feld aus Zeigern auf die Funktionen, die die Schnittstelle implementieren.
Die Erzeugung dieser statischen Datenstrukturen ergibt sich aus der Verwendung der verschiedenen im folgenden beschriebenen Makros. Die Erzeugung der meisten Datenstrukturen erfolgt zum Zeitpunkt der Kompilierung, das System bindet aber einige Komponenten während der Laufzeit zusammen. Die Verarbeitung der Laufzeit wird durch die Erbauer und Zerstörer der mit den Makros vereinbarten globalen Variablen eingeleitet. Das Laden einer DLL in den Speicher und das Entladen einer DLL aus dem Speicher feuert diese Funktionen.
Jede vtable 416 ist eine statische Elementvariable der Schnittstellenimplementierungsklasse ihrer Schnittstelle. Jede Schnittstellenimplementierungsklasse veranlaßt den Makro DECLARE_DYN_MAP, der die vtable 416 vereinbart. Die Makros BEGIN_DYN_MAP und END_DYN_MAP beginnen bzw. beenden die Initialisierung einer vtable 416. Zwischen den BEGIN_DYN_MAP- und END_DYN_MAP-Makros spezifiziert der DYN_MAP_ENTRY-Makro einen Eintrag in diesem Feld 416. Die vtables 416 sind deshalb vollständig zum Zeitpunkt der Kompilierung spezifiziert.
Die Schablone für die Verwendung der Makros ist wie folgt:
wobei < Schnittstellenimplementierungsklasse> der Name der Klasse ist, die die Schnittstelle implementiert, wobei es einen < Elementfunktion> -Eintrag für jede Elementfunktion in der Schnittstelle gibt.
Ähnlich initialisiert der BEGIN_DYN_CLASS-Makro eine Schnittstellenliste 314, während eine Folge von DYN_INTERFACE_ENTRY-Makros das Feld 410 aus Zeigern 412 und die Schnittstellendefinitionen 418 spezifiziert, die die Liste aufbauen. Ein END_DYN_CLASS-Makro beendet die Initialisierungsliste. Folglich ist eine Schnittstellenliste 314 zum Zeitpunkt der Kompilierung ebenfalls vollständig spezifiziert.
Die Schablone für die Verwendung dieser Makros ist wie folgt:
Die Objekte der Schnittstellenliste besitzen einen Erbauer, der die Adresse des Schnittstellendefinitions-Feldes 410 und den ganzzahligen Typ der Klasse akzeptiert. Dieser Erbauer zählt die Anzahl der Einträge im Schnittstellendefinitions-Feld 410 und speichert diesen Zählwert in seinen instanzdaten. Das System aktualisiert den Typabbildungs- Datensatz 312, der durch diese ganzzahlige Zahl gekennzeichnet ist, mit diesen Informationen, wobei es ansonsten den Typabbildungs-Datensatz 312 initialisiert.
In einer bevorzugten Ausführungsform ist die Typabbildung 310 eine globale Variable, die ein im voraus zugewiesenes Feld mit fester Größe enthält. In einer anderen Ausführungsform ist die Typabbildung 310 ein neu zuweisbares Feld aus Zeigern, wobei die BEGIN_DYN_CLASS-Makros die Typabbildungs- Datensatzstrukturen 312 definieren und initialisieren.
Das Laufzeitsystem ist im folgenden beschrieben.
Wenn eine Anwendung auf ein Objekt der dynamischen Schnittstellen zugreift, weist das System dem Objekt verschiedene Wrapper zu, die das COM- Verhalten bereitstellen. Es gibt zwei Typen von Objekt-Wrappern: IUnknown- Wrapper und Schnittstellen-Wrapper. Die Erfindung erhält einen Cache dieser Objekt-Wrapper aufrecht, wobei es einen in ein paar Anweisungen zuweisen kann.
Die Fig. 2A und 2B veranschaulichen einen IUnknown-Wrapper 2A10 bzw. die Schnittstellen-Wrapper 2B10.
In einer bevorzugten Ausführungsform enthält ein IUnknown-Wrapper 2A10 außer einen Zeiger auf eine vtable, die die allgegenwärtigen IUnknown- Funktionen enthält, die folgenden Instanzdaten:
- die Adresse 2A20 des Objekts 2A60, das gewrappt wird;
- die Adresse 2A30 des Typabbildungs-Datensatzes 312, der die Klasse des Objekts 2A60 beschreibt;
- die Adresse 2A40 der Unknown-Steuerung 2A70 des Objekts 2A60; und
- den Referenzzähler 2A50 des IUnknown-Wrappers 2A10.
Ein IUnknown-Wrapper 2A10 wird zugewiesen, wenn zuerst auf das Objekt 2A60 Bezug genommen wird. Wenn das System den IUnknown-Wrapper 2A10 dem Objekt 2A60 zuweist, durchläuft der IUnknown-Wrapper 2A10 einen Bindeprozeß, in dem diese Instanzdaten initialisiert werden.
Das Binden ist nicht teuer. Die umfangreichste beteiligte Arbeit ist das Finden des geeigneten Typabbildungs-Datensatzes 312. Dies erfolgt, indem die Typabbildung 310 mit der ganzzahligen ID des Objekts 2A60 für den Typabbildungs-Datensatz 312 indexiert wird.
Es gibt zu irgendeinem gegebenen Zeitpunkt immer nur einen IUnknown- Wrapper 2A10 für ein Objekt 2A60. Der IUnknown-Wrapper 2A10 bleibt an das Objekt 2A60 gebunden, bis der Referenzzähler 2A50 für das Objekt 2A60 auf null geht. Der IUnknown-Wrapper 2A10 ist die IUnknown-Implementierung für die Klasse. Der IUnknown-Wrapper 2A10 ist aus IUnknown abgeleitet, wobei seine Adresse zurückgeleitet wird, wenn die Anwendung IUnknown::Querylnterface aufruft.
Der IUnknown Wrapper 2A10 kann keine andere Schnittstelle als IUnknown implementieren. Wenn ein Client eine Schnittstelle durch Querylnterface angefordert, durchläuft das System die Schnittstellenliste 314 und lokalisiert die vtable, die die angeforderte Schnittstelle implementiert. Der IUnknown-Wrapper 2A10 weist dann einen Schnittstellen-Wrapper 2B10 zu und initialisiert ihn mit dieser vtable 416. Querylnterface leitet die Adresse des Schnittstellen-Wrappers 2B10 als die Schnittstellenimplementierung zurück.
(Jede obenbeschriebene Zeile
äquivalent, der in der herkömmlichen Querylnterface gefunden wird.)
In einer bevorzugten Ausführungsform enthält jeder Schnittstellen-Wrapper 2B10 außer einen Zeiger auf eine vtable, die die im folgenden beschriebenen IUnknown-Funktionen und die Elementfunktionen des Schnittstellen-Wrappers enthält,:
- die Adresse 2B20 des entsprechenden IUnknown-Wrappers 2A10;
- die Adresse 2B30 der vtable 416, die die Schnittstelle implementiert; und
- den Referenzzähler 2B40 des Schnittstellen-Wrappers 2B10.
Die Hauptfunktion des Schnittstellen-Wrappers 2B10 besteht darin, sich als eine Implementierung dessen zu verkleiden, was auch immer für eine Schnittstelle der durch das System zugewiesenen Adresse 2830 entspricht. Weil die aufrufende Software nichts über die Schnittstellen-Wrapper weiß, ruft diese Software Elementfunktionen in dem Datenobjekt auf, wobei sie denkt, daß sie Elementfunktionen der COM-Schnittstelle aufruft (wobei sie aber tatsächlich die im folgenden beschriebenen Elementfunktionen der Schnittstellen-Wrapper) aufruft.
Wenn eine Anwendung eine COM-Elementfunktion aufruft, baut der Kompilierer etwas, das als Aufrufrahmen bezeichnet wird, der die tatsächlichen Parameter der Funktion, einen Zeiger auf das Objekt, auf das zu wirken ist, und die Adresse, zu der zurückzukehren ist, enthält. Typischerweise unterstützt der Kompilierer eine Anzahl von Aufrufkonventionen. Die COM-Spezifikation erklärt jedoch, daß alle Schnittstellenaufrufe eine Konvention verwenden müssen, die als ein "Standardaufruf" ("_stdcall") bezeichnet wird. (Das ist das, was das herkömmliche STDMETHOD-Makro tut.) In dieser Konvention werden alle Parameter zum Stapel geleitet, wobei der this-Zeiger des Objekts in einem impliziten ersten Argument erfaßt wird. Das Programm verzweigt dann zur aufgerufenen Funktion, die den this-Zeiger und die Parameter aus dem Stapel extrahiert.
Wenn die Software eine Elementfunktion eines Schnittstellen-Wrappers 2B10 aufruft, gibt der Kompilierer der gerufenen Funktion einen gültigen Aufrufrahmen, der für die Schnittstellenelementfunktion formatiert ist, die der Schnittstellen-Wrapper 2B10 emuliert. Fig. 5 ist ein Schema eines derartigen Aufrufrahmens entsprechend der Standard-Aufrufkonvention.
Es stellen sich jedoch drei Probleme selbst dar: Erstens enthält der Aufrufrahmen den this-Zeiger 610 des Schnittstellen-Wrappers 2B10 anstatt den des Datenobjekts. Zweitens werden die Elementfunktionen des Schnittstellen-Wrappers 2B10 anstatt die erforderliche Funktion der Schnittstellenimplementierungsklasse ausgeführt. Drittens sind die Elementfunktionen der Schnittstellen-Wrappers in der Assemblersprache geschrieben, wobei Probleme der Übertragbarkeit verursacht werden.
Was den Zeiger auf den Schnittstellen-Wrapper in einem Aufrufrahmen anbelangt, extrahiert die Elementfunktion des Schnittstellen-Wrappers, die ausgeführt wird, die Adresse 2A20 des Datenobjekts aus ihren Instanzdaten (durch ihren Zeiger 2B20 auf den IUnknown-Wrapper 2A10) und schreibt diesen Wert in der geeigneten Position in den Stapel. Fig. 6 ist eine Skizze eines modifizierten Stapels entsprechend der Standard-Aufrufkonvention.
Was die Ausführung der richtigen Funktion anbelangt, extrahiert die Elementfunktion des Schnittstellen-Wrappers, die ausgeführt wird, die Adresse der Funktion, die ausgeführt werden sollte, aus ihren Instanzdaten (über den vtable- Zeiger 2B30) und verzweigt zu dieser Adresse. Die erforderliche Elementfunktion beginnt dann die Ausführung.
Ein ernsteres Problem ist die Tatsache, daß die Elementfunktionen des Schnittstellen-Wrappers in der Assemblersprache geschrieben sind. In einer bevorzugten Ausführungsform ist hier jedoch nur die Übertragbarkeit lediglich einer Funktion strittig. Die tatsächlichen Elementfunktionen des Schnittstellen-Wrappers sind mit einem Makro implementiert, der die Nummer der Funktion aufzeichnet und zu einer Zentralfunktion verzweigt. Vorausgesetzt, es ist möglich, die Position des ersten Funktionsparameters im Stapel zu finden, ist diese Zentralfunktion sehr einfach und leicht übertragbar. Dieser erste Parameter ist leicht zu finden, falls der.
Kompilierer diese Parameter von rechts nach links in den Stapel einspeichert, er ist aber nicht so leicht lokalisierbar, falls der Kompilierer die Parameter von links nach rechts einspeichert. Konventionell erscheint der binäre COM zur Konvention von rechts nach links verpflichtet, obgleich keine explizite Feststellung diesbezüglich bekannt ist.
Sind die Parameter von links nach rechts, muß das System einer Anzeige der Anzahl der Bytes im Aufrufrahmen jeder Elementfunktion jeder Schnittstelle aufrechterhalten. Diese Anzeigen würden über den Schnittstellen-Wrapper zugänglich sein müssen. Wie ein Fachmann erkennen wird, kann dies mit ein paar weiteren Makros zum Aufbau von Tabellen erreicht werden.
(Die Klasse eines Schnittstellen-Wrappers vereinbart eine vtable mit einer bestimmten festen Größe (vorzugsweise 30). Das System kann keine Schnittstellen mit mehr Elementfunktionen als diese bearbeiten. In einer bevorzugten Ausführungsform wird ein Prüfpunkt in der Fehlersuchbetriebsart auftreten, falls ein Versuch unternommen wird, eine vtable zu registrieren, die diese Grenze übersch reitet.)

Die Obiekt- und Schnittstellenklassen-Definition einer bevorzugten Ausführungsform

Gemäß der vorliegenden Erfindung definiert ein Entwickler die COM-Klassen in im wesentlichen der gleichen Weise wie vorher: Definieren einer Klasse für die Instanzdaten und Definieren einer Klasse für jede der Schnittstellen der Klasse. Die Interna einer Klasse und die Mechanismen des Verbindens der Klassen miteinander sind jedoch ganz verschieden, wie durch einen Vergleich von Fig. 1A mit den Fig. 1B, 2A und 2B gezeigt wird und wie hierin beschrieben ist.
Nun die grundlegende Definition einer COM-Objektklasse ist seine Daten- C++-Klasse. Bei dynamischen Schnittstellen definiert der Entwickler eine normale C++-Klasse. Wenn das Objekt erzeugt wird, muß der Mechanismus, der den eindeutigen Identifizierer für die Objektklasse aufzeichnet, initialisiert werden. Der eindeutige Identifizierertyp kann z. B. mittels einer Überlastung des new-Operators als Teil des Datenobjekts gespeichert werden, wie durch die Typen 318 in Fig. 3 veranschaulicht ist. Dieser Mechanismus kann auf ein Makro reduziert werden, das hierin als DECLARE_NEW_OVERLOAD bezeichnet ist, das den eindeutigen Identifizierer als sein Argument nimmt.
Vorzugsweise ist dieser eindeutige Identifizierer eine kurze vorzeichenlose ganze Zahl (Zwei-Byte-Zahl). Die COM-Objekts sind jedoch bereits durch eine CLSID gekennzeichnet, wobei die CLSID einer Klasse das Argument für den Makro sein kann. Es gibt einen Kompromiß zwischen der Annehmlichkeit beim Programmieren und der Ausführungsgeschwindigkeit, der Hauptvorteil einer kurzen ganzen Zahl ist die Leistung. In jedem Fall wird die Typabbildung in Übereinstimmung mit der Auswahl der CLSID oder der kurzen ganzen Zahl indexiert.
Eine Beispiel-Datenklasse ist wie folgt:
Die Klasse wird nicht von irgendeiner anderen Klasse abgeleitet und enthält keine virtuellen Funktionen. Während virtuelle Funktionen nicht verboten sind, sind sie im allgemeinen nicht notwendig, weil das COM als die "Objekt-Polymorphismus"-Maschine funktioniert.
Außerdem besitzt die Klasse keine COM-Unterstützungselementdaten, wie z. B. einen Referenzzähler (z. B. m_cRef in Fig. 1A) oder einen Zeiger auf eine Steuerschnittstelle (z. B. m_pUnkOuter in Fig. 1A). Diese Daten sind hier nicht notwendig, da das System sie behandelt, wie oben beschrieben ist.
In bezug auf die Schnittstellendefinitionen implementiert eine Klassendefinition der dynamischen Schnittstellen jede COM-Schnittstellenimplementierung für eine spezielle Datenklasse unabhängig von den anderen Schnittstellen in dieser Klasse. Die Klasse der dynamischen Schnittstellen wird öffentlich aus der Datenklasse abgeleitet, auf der die Schnittstelle definiert ist, wobei sie ein DECLARE_DYN_MAP-Makro und die Vereinbarungen der Schnittstellenelementfunktionen enthält.
Das folgende ist eine generische IGraphic-Schnittstelle in dem oben definierten Punktobjekt:
Die Implementierungsklasse würde sein class PointIGraphic : public Point
Die Implementierungsklasse stellt auffallend nicht die Standard-IUnknown- Funktionen Querylnterface, AddRef und Release bereit.
Die vtable-Definition der obenbeschriebenen PointIGraphic-Klasse würde sein:
Diese Einträge erscheinen in der gleichen Reihenfolge, in der sie in der Schnittstellendefinition erscheinen.
Schließlich wird die allgemeine Unterstützung für einen COM-InProc-Server beschrieben. Die allgemeine DLL-Infrastruktur für dynamische Schnittstellen- DLLs ist mit derjenigen für herkömmliche COM-DLLs völlig gleich. DIIGetClassObjecfwird verwendet, um die Klassenobjekte zu erhalten. DIICanUnloadNow bestimmt, ob die DLL aus dem Speicher entladen werden kann.
Die dynamischen Schnittstellen-DLLs spezifizieren die Schnittstellen, die die Klasse unterstützt. Sie tun dies, indem sie die BEGIN_DYN_CLASS-, DYN_INTERFACE_ENTRY- und END_DYN_CLASS-Makros im Datei-Gültigkeitsbereich anordnen. Wenn z. B. die oben definierte Punktklasse zwei Schnittstellen unterstützt, IGraphic und ISymbology, dann würde dieser Registrierungsabschnitt lauten
Weil die dynamischen Schnittstellenobjekte weniger Speicher als herkömmliche COM-Objekte erfordern, verbessert die Verwendung dynamischer Schnittstellenobjekte die allgemeine Systemleistung, insbesondere weil die Seitenfehler verringert werden. Trotzdem erleidet das Wrapping-System einigen Zusatzaufwand: Das Erhalten der ersten Schnittstelle in einem Objekt erfordert die Zuweisung von zwei Wrappern, wobei jede anschließende Schnittstelle einen Wrapper erfordert. Die Querylnterface-Funktion selbst sollte nicht signifikant langsamer als die der herkömmliche COM sein. Sobald ein Schnittstellenzeiger erhalten worden ist, wird das Aufrufen einer Elementfunktion eine kleine Anzahl zusätzlicher Maschinenanweisungen benötigen (z. B. 10 auf einem 80 · 86-Prozessor), was typischerweise im Vergleich zur Verarbeitung der Funktion vernachlässigbar ist.
Die dynamischen Schnittstellenobjekte unterstützen vollständig die veröffentlichte COM-Semantik. Sie sind mit Klassenobjekten konstruiert, sie werden durch Schnittstellen manipuliert, sie unterstützen die IUnknown-Identität und sie können Objekte zusammenfassen und durch andere zusammengefaßt werden.
Selbstverständlich gibt es den Programmtext für eine derartige Software, wie sie hierin offenbart ist, in seiner statischen Form auf einer magnetischen, optischen oder anderen Platte, in einem ROM, einem RAM oder einem anderen Datenspeichermedium. Das Datenspeichermedium kann in ein Computer-System integriert sein oder in ein Computer-System einfügbar sein.

Claims

1. Verfahren zum Zuweisen eines Speichers in einem Computersystem, um Datenobjekte zu repräsentieren, wobei das Verfahren umfaßt:

Bezugnehmen auf ein Objekt;

Zuweisen eines Objekt-Wrappers, der eine objektorientierte Programmiermodell-Infrastruktur enthält; und Binden des Objekt-Wrappers an das Objekt.

2. Verfahren nach Anspruch 1, bei dem der Schritt des Bindens das Initialisieren des Objekt-Wrappers umfaßt.

3. Verfahren nach Anspruch 1 oder 2, bei dem vor dem Ausführen des Schrittes der Bezugnahme der folgende Schrift ausgeführt wird:

Erzeugen mehrerer Zuordnungen zwischen Klassen-Identifizierern und Klassen-Beschreibungen; und

der Schritt des Bindens umfaßt:

Auswählen der Zuordnung des Klassen-Identifizierers des Objekts und einer Klassen-Beschreibung aus den mehreren Zuordnungen; und

Zuordnen des Objekt-Wrappers zu der Zuordnung.

4. Verfahren nach einem der Ansprüche 1 bis 3, bei dem der Objekt- Wrapper nur eine Schnittstelle implementiert.

5. Verfahren nach Anspruch 4, bei dem die eine Schnittstelle die IUnknown-Schnittstelle ist.

6. Verfahren nach Anspruch 4, bei dem nur die IUnknown-Schnittstelle zu irgendeinem Zeitpunkt an das Objekt gebunden ist.

7. Verfahren nach Anspruch 3, bei dem eine Klassen-Beschreibung umfaßt:

eine Tabelle von Funktionen, die eine Schnittstelle implementieren; und das Verfahren ferner umfaßt:

Abfragen des Objekts nach einer zweiten Schnittstelle;

Durchsuchen der Klassen-Beschreibung der ausgewählten Zuordnung nach einer Tabelle von Funktionen, die die zweite Schnittstelle implementieren;

Zuweisen und Initialisieren eines zweiten Objekt-Wrappers, wenn die Tabelle von Funktionen gefunden wird.

8. Verfahren nach Anspruch 7, bei dem der zweite Objekt-Wrapper einen Schnittstellen-Wrapper umfaßt.

9. Verfahren nach Anspruch 7 oder 8, bei dem der Schritt des Zuweisens und Initialisierens umfaßt:

Zuordnen der Tabelle von Funktionen zu dem Schnittstellen-Wrapper; und

Zuordnen des Schnittstellen-Wrappers zu dem Objekt.

10. Verfahren nach Anspruch 8 oder 9, das ferner den folgenden Schritt umfaßt:

Zurückleiten der Adresse des Schnittstellen-Wrappers als Folge der Abfrage, falls die Tabelle von Funktionen gefunden wird.

11. Verfahren nach Anspruch 10, das ferner den folgenden Schritt umfaßt:

Emulieren des Aufrufs einer Funktion aus der Tabelle von Funktionen.

12. Verfahren nach Anspruch 11, bei dem der Schritt des Emulierens umfaßt:

Ersetzen eines Zeigers auf den Schnittstellen-Wrapper in einem Aufrufrahmen, der für eine Funktion erzeugt wird, die tatsächlich aufgerufen wird, durch einen Zeiger auf das Objekt; und

Ausführen des Programmtexts der Funktion, deren Aufruf emuliert worden ist.

13. Verfahren nach einem der Ansprüche 1 bis 12, bei dem die objektorientierte Programmiermodell-Infrastruktur umfaßt:

eine erste Speicherstelle für die Adresse des Objekts;

eine zweite Speicherstelle für die Adresse der Zuordnung, die die Klasse des Objekts beschreibt;

eine dritte Speicherstelle für die Adresse für die Unknown-Steuerung des Objekts; und

eine vierte Speicherstelle für einen Referenzzählstand des Objekts.

14. Verfahren nach einem der Ansprüche 7 bis 12, bei dem der zweite Objekt-Wrapper umfaßt:

eine erste Speicherstelle für die Adresse des Objekt-Wrappers;

eine zweite Speicherstelle für die Adresse der Tabelle von Funktionen, die die Schnittstelle implementieren; und

einen Referenzzählstand für den zweiten Objekt-Wrapper.