Beleg (.pdf - 1.63 MB) - Technische Universität Dresden

TECHNISCHE UNIVERSITÄT DRESDEN
FAKULTÄT INFORMATIK
INSTITUT FÜR SOFTWARE- UND MULTIMEDIATECHNIK
PROFESSUR FÜR COMPUTERGRAPHIK UND VISUALISIERUNG
PROF. DR. STEFAN GUMHOLD
Großer Beleg
API für Plugin und Treiber basierte
Softwareentwicklung
Michael Voß
(Mat.-Nr.: 2821139)
Betreuer: Prof. Dr. rer. nat. Stefan Gumhold
Dresden, 27. April 2007

Aufgabenstellung
Entwicklung von plattformunabhängigen Konzepten für die Realisierung von Plugins und Treiber in
computergraphischen Anwendungen.

1
Inhaltsverzeichnis
1 Einführung 3
2 Grundlagen 5
2.1 Hostanwendung, Plugins und Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Programmiersprache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 „Native“ Sprachen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 .NET Framework und Mono . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.3 Interoperabilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Statische Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 Dynamische Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3 Windows und dynamische Bibliotheken . . . . . . . . . . . . . . . . . . . . . . 11
2.3.4 Linux und dynamische Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Beispiele für Pluginsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.1 Adobe Photoshop Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.2 Qt Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Die Plugin API für C++ 15
3.1 Typenreflektion mit dynamic_cast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Schnittstellendefinitionen in PluginDefs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1 Plugin_interface_class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2 Iplugin_base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.3 Irenderable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.4 Id3d9_plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.5 IPluginEventCallback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.6 Ikeyboard_event_handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.7 Imouse_event_handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Die Verwaltungsklasse plugin_loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2
3.3.1 Laden neuer Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.2 Pluginliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.3 Zugriff auf Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Plugin Bibliotheken schreiben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.1 plugin_factory_list_class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.2 Pluginfabriken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4 Die Plugin API für .NET 26
4.1 Typenreflektion im .NET Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Schnittstellen in PluginDefs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.1 Die Standardschnittstelle iplugin_base . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.2 Iplugin_event_callback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 PluginLoader.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5 Beispielanwendungen 31
5.1 DirectX Beispiel für C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.1 Die Hostanwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1.2 Die Dll MeshDll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1.3 Die DLL InteractiveRoom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2 OpenGL Beispiel für C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.1 OpenGLHost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2.2 Die Pluginbibliothek OGLDLL . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3 Beispiel für .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3.1 Hostanwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3.2 Das Assembly PluginDLL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6 Zusammenfassung 37
Literaturverzeichnis 38
Abbildungsverzeichnis 40
A Quelltexte 41
B Verzeichnisse auf der CD zum Beleg 46

1. EINFÜHRUNG 3
1 Einführung
Arbeitet man an einem kommerziellen Software-Projekt, muss man sich irgendwann entscheiden, welche
Funktionen implementiert werden sollen. Diese Entscheidung wird im Normalfall mit Hilfe des
Verhältnisses zwischen Nutzen und Kosten getroffen. Spezielle Wünsche werden selten berücksichtigt,
weil sie für den durchschnittlichen Kunden kaum eine Verbesserung bringen. Oft ändern sich aber die
Anforderungen an die Software im Verlauf des Nutzungszeitraums und je nach Anwender. Aus diesem
Grund ist es vorteilhaft, wenn der Software ohne erneutes Kompilieren Funktionen hinzugefügt werden
können. Weiterhin gibt es einige Anwendungsbereiche, wo es von Vorteil ist, wenn viele kleine Projekte
in einer gemeinsamen Oberfläche zusammengefasst werden können. Dabei sollte die grafischen
Benutzerschnittstellen nicht für jedes Projekt einzeln gestaltet werden, sondern einheitlich und zentral.
Manchmal ist es nötig, dass eine Anwendung je nach Bedarf ihre grafischen Ausgaben mit Hilfe von
DirectX, OpenGL oder den Betriebssystemfunktionen realisiert. Hier wäre es schön, wenn die Anwendung
nicht für alle Systeme komplett neu geschrieben werden müsste und wenn die Wahl des System
so dynamisch wie möglich ist. Dies alles kann durch Pluginsysteme realisiert werden. Solche Systeme
sind in der Lage Programmteile, welche Plugins genannt werden, einer Anwendung dynamisch hinzuzufügen.
Das Wort Plugin kommt vom englischen „to plug in“ und bedeutet soviel wie „einstöpseln“
oder „anschließen“. Das Erweitern von Anwendungen durch Plugins wird im Rahmen vorher definierter
Grenzen, den Schnittstellen, durchgeführt. Schnittstellen sind eine Art Regelung der Kommunikation
zwischen Anwendung und hinzugefügten Programmteil. So wird es möglich, Erweiterungen für Applikationen
zu schreiben, von denen die Schnittstellen bekannt sind, auch wenn der Quellcode unbekannt
bleibt.
Viele moderne Anwendungen für Desktoprechner unterstützen die Erweiterung mittels Plugins. So können
spezielle Inhalte wie Animationen, PDF Dateien und Videos über den Internetbrowser Firefox [15]
betrachtet werden. Für das 3d Modellierungs- und Animationsprogramm 3d Studio MAX [4] sind z. B.
physikalische Systeme, Stoffsimulationen und verschiedene Partikeleffekte als Erweiterungen im Internet
zu finden. Ein weiteres Beispiel ist Adobe Photoshop [1]. Für diese Bildbearbeitungssoftware gibt es
zahlreiche Plugins. Sie werden Filter genannt und verändern das aktuell ausgewählte Bild in spezifischer
Weise.
In diesem Beleg geht es darum, eine Programmierschnittstelle (API) zu entwickeln, mit deren Hilfe ei-

1. EINFÜHRUNG 4
ne pluginbasierte Anwendung schnell und einfach geschrieben werden kann. Diese API soll sowohl in
einem Windows Betriebssystem, als auch unter Linux kompilierbar sein. Die API soll zudem flexibel
und erweiterbar sein. Weiterhin soll Untersucht werden ob eine einheitliche API für C++ - und .NET
Anwendungen möglich ist. Der Anwendungsfall an dem sich bei der Entwicklung der Plugin API orientiert
wurde, ist eine grafische Applikation die als Benutzerschnittstelle fungiert und Plugins, die bis auf
die Interaktion mit dem Benutzer, komplett selbständige Programme darstellen. Die API wurde in den
Namensraum cgv::utils::plugins geschrieben und hält sich an die vorgegebene Namenskonvention.

2. GRUNDLAGEN 5
2 Grundlagen
2.1 Hostanwendung, Plugins und Schnittstellen
Jedes Pluginsystem besteht im wesentlichen aus zwei Komponenten. Zum Einen aus der Hostanwendung,
welche als solche vom Anwender gestartet wird und den Rahmen der Funktionalität bestimmt.
Zum Anderen aus den Plugins, welche von der Hostanwendung geladen werden und dieser neue Funktionen
hinzufügen können. Plugins werden typischer Weise in dynamische Bibliotheken verpackt. Zur
Kommunikation zwischen Hostanwendung und Plugin werden Schnittstellen definiert. Diese Schnittstellen
müssen für beide Seiten gleich sein und vor dem Kompilieren der Hostanwendung angegeben
werden. Aus diesem Grund dürfen einmal definierte Schnittstellen in der hier vorgestellten API nicht
mehr geändert werden, da sonst neue Plugins nicht mehr mit alten Anwendungen kompatibel wären
bzw. alte Plugins mit neuen Anwendungen. Sie können aber zur Erweiterung der API als Basisklassen
genutzt werden, wenn sie für eine neue Schnittstelle notwendig sind.
2.2 Programmiersprache
Im Bereich der Programmiersprachen ist mit Einführung von .NET [13], und dessen Portierung auf Linux:
Mono [14], eine Einteilung in „managed“ und „native“ oder auch „unmanaged“ entstanden. Bei dieser
Unterteilung werden alle Sprachen und Programme die das .NET Framework nutzen als „managed“
bezeichnet. Alle übrig bleibenden Sprachen werden „native“ oder „unmanaged“ genannt. Die im Rahmen
dieses Beleges erstellte API ist dieser Aufteilung folgend auch zweigeteilt.
2.2.1 „Native“ Sprachen
Der „native“ Teil der Plugin API besteht aus drei statischen Bibliotheken und einigen C++ Headern
und ist für den Gebrauch mit C++ gedacht. Die Bibliotheken enthalten Schnittstellen für Plugins, eine
Verwaltungsklasse zur Nutzung von Plugins in Anwendungen und eine Verwaltungsklasse für alle in
einer Pluginbibliothek enthaltenen Plugins.

2. GRUNDLAGEN 6
2.2.2 .NET Framework und Mono
Abbildung 2.1: CTS Typenhierarchie ([7])
Das .NET Framework wurde von Microsoft als Konkurrenz zu Java entwickelt und sollte den Anforderungen
von verteilten Anwendungen genügen. Es besteht im wesentlichen aus einer virtuellen Maschine,
welche Common Language Runtime (CLR) genannt wird und dem Framework selbst. Die Implementierung
orientiert sich an der CLI (Common Language Infrastructure), einem Standard, der Systeme
spezifiziert, die sprach- und plattformneutrale Anwendungsentwicklung und -ausführung ermöglichen.
Wie bei Java wird beim Kompilieren zunächst eine Art Zwischencode (CIL für Common Intermediate
Language) erzeugt. Ein in CIL kompiliertes Programm bzw. Programmteil wird als Assembly bezeichnet.
Assemblies können sowohl selbständig ausführbare Dateien (in Windows EXE-Dateien) als auch
Bibliotheken sein. Sie enthalten neben dem Code in CIL zusätzlich Metadaten, welche das Assembly und
darin enthaltene Definitionen näher beschreiben. Zum Ausführen eines Assemblies durch die virtuelle
Maschine, im Falle von .NET der CLR, wird der Zwischencode in „nativen“ Maschinencode umgewandelt.
Diese Art der Kompilierung in Maschinencode direkt vor dem Ausführen wird just-in-time (JIT)
Kompilierung genannt. Da dies negativ auf die Startzeit eines Assemblies wirkt, kann für „zeitkritische“

2. GRUNDLAGEN 7
Anwendungen, also Anwendungen die schnell gestartet werden sollen, bereits vor der Ausführung durch
die CLR, „nativer“ Maschinencode erzeugt werden. Dieses Verfahren nennt sich NGen (Native Image
Generation) und wird typischer Weise bei der Installation der Anwendung ausgeführt. Es wird also wie
beim JIT kompilieren ein auf das System angepasster und optimierter „nativer“ Maschinencode erzeugt,
der nicht für die Weitergabe und Ausführung auf anderen Systemen gedacht ist. Assemblies werden in
CIL dem Binärformat der CLR weitergegeben. Ein weiterer Bestandteil der CLI ist ein wohldefiniertes
Typensystem. Das Common Type System (CTS) stellt ein einheitliches System von Datentypen bereit.
Abbildung 2.1 zeigt die Typenhierarchie des CTS.[7]
Im Gegensatz zu Java, ist das .NET Framework an keine Programmiersprache gebunden. Neben C#, welches
extra für die effiziente Nutzung des Frameworks entworfen wurde, gibt es eine Vielzahl von .NET
fähigen Programmiersprachen. Einige wie C++ mit Managed Extensions (C++/CLI) oder Delphi.NET
können sowohl „managed“ .NET Code als auch „unmanaged“ Code kompilieren. Da bei jedem .NET
Kompiler ein Zwischencode (CIL) erzeugt wird, ist die Wahl der Sprache keine Einschränkung bezüglich
der Kompatibilität. So können .NET Sprachen alle Komponenten und Bibliotheken nutzen die von
einer beliebigen anderen .NET Sprache erzeugt wurden.
Das .NET Framework ist zur Zeit nur für die Windows Betriebssysteme ab Windows 98 erhältlich. Um
auch unter Linux Assemblies erzeugen zu können, muss man auf Open-Source Projekte wie Mono zurückgreifen.
Das Mono-Projekt[14] orientiert sich ebenfalls an der CLI und beinhaltet eine eigene virtuelle
Maschine, eine zum .NET Framework kompatible Sammlung von Klassenbibliotheken sowie einen
Kompiler für die Sprache C#. Mono gibt es neben Linux auch für Mac OS X, Sun Solaris, BSD und
Windows. Dadurch ist es möglich, Anwendungen für das .NET Framework auch unter anderen Betriebssystemen
als Windows auszuführen.
Der „managed“ Teil der Plugin API besteht aus zwei Assemblies. Diese Klassenbibliotheken stellen eine
Verwaltungsklasse und Schnittstellen für Plugins bereit.
2.2.3 Interoperabilität
Bei der Entwicklung vom .NET Framework wurde auch auf die Zusammenarbeit mit „unmanaged“ Code
geachtet. Allerdings bezieht sich diese Zusammenarbeit vor allem auf COM Projekte. COM steht für
„component object model“ und bezeichnet eine Technologie, welche eine von der Programmiersprache
unabhängige Möglichkeit der Objektbeschreibung und Objekterzeugung bietet (für weitere Informationen
siehe [16]). Diese von Microsoft entwickelte Technologie findet aber nur in Windows Betriebssystemen
Verwendung. Für eine plattformunabhängige API ist COM also ungeeignet.
Im .NET Framework existiert neben der Unterstützung von COM noch eine weitere Variante der Inter-

2. GRUNDLAGEN 8
operabilität. Diese nennt sich Platform Invoke Service oder auch PInvoke Service. PInvoke unterstützt
Aufrufe von exportierten globalen Methoden und nicht statischen Memberfunktionen einer „unmanaged“
DLL. Dies geschieht über das DllImport Attribut. Die dabei notwendige Konvertierung der „nativen“
Typen in „managed“ Typen und umgekehrt wird Marshaling genannt (siehe [18]). Leider gibt es keine
Möglichkeit, eine Instanz einer Klasse (Objekte) zu konvertieren. Es müssten also Wrapperklassen
geschrieben werden, welche für jede Methode des zu konvertierenden Objektes, eigene Funktionszeiger
besitzt. Diese Herangehensweise ist aber für eine flexible Plugin API, wie die hier vorgestellte, sehr
hinderlich. Es müsste jeweils in C++ und .NET die Schnittstelle und eine zugehörige Wrapperklasse
definiert werden. Dies bedeutet gegenüber der Aufteilung der API in einen .NET und einen C++ Teil,
zwei zusätzliche Klassen. Es wurde aus diesem Grund von einer einheitlichen API abgesehen und die angesprochene
Teilung vollzogen. Ist eine Zusammenarbeit von .NET Hostanwendung und „unmanaged“
Plugin (oder auch umgekehrt) unbedingt nötig, dann kann auf die Managed Extensions von C++ zurückgegriffen
werden. Die Hostanwendung besteht dann aus einem „managed“ und einem „unmanaged“ Teil
und es ist dem Entwickler der Hostanwendung überlassen, sich um die Kommunikation zwischen .NET
und C++ zu kümmern. Dies bedeutet im Normalfall deutlich weniger Aufwand, weil die Hostanwendung
die Art der genutzten Plugins kennt. Sie muss unter diesem Gesichtspunkt also weniger flexibel sein.
2.3 Bibliotheken
Eine Bibliothek bezeichnet in der Programmierung eine kompilierte Sammlung von Funktionen, Variablen
und Konstanten, welche von Programmen genutzt werden können. Häufig verwendete Programmteile
werden auf allen gängigen Betriebssystemen in solche Bibliotheken ausgelagert. Sie müssen dann
bei der Programmierung einer Anwendung nicht erneut geschrieben werden, sondern es werden die benötigten
Teile aus der Bibliothek in das Programm eingebunden. Dieses Einbinden wird Linken genannt
und es geschieht nach dem kompilieren des Programms. Es wird zwischen drei Arten des Linkens unterschieden.
Dem statischen Linken, dem festen Linken und dem dynamischen Linken.
2.3.1 Statische Bibliotheken
Bei dem statischen Linken hängt ein sogenannter Linker der kompilierten Anwendung die benötigten
Programmteile der Bibliotheken an. Weiterhin werden die entsprechende Verweise und Funktionsadressen
angepasst, so dass die Anwendung danach den kompletten Programmcode enthält und beim Ausführen
die statisch eingebundene Bibliothek nicht mehr benötigt. Bibliotheken die für das statische Linken
vorgesehen sind werden statische Bibliotheken genannt. Das statische Linken führt zu einer immensen

2. GRUNDLAGEN 9
Abbildung 2.2: Statisches Binden einer statischen Bibliothek
Redundanz, da die Bibliotheksfunktionen in allen Programmen „physisch“ vorkommen, die sie verwenden.
Dies hat nicht nur Nachteile für den benötigten Speicherplatz, sondern auch für die Wartbarkeit des
Codes der Bibliotheken. Enthält beispielsweise eine Funktion einer statischen Bibliothek einen Fehler,
dann ist der Fehler auch in allen Programmen enthalten, die diese Funktion statisch eingebunden haben.
Für eine Behebung des Fehlers reicht es nicht die statische Bibliothek zu ändern, es müssen auch alle
Programme neu kompiliert (und gelinkt) werden, die diese Funktion verwendenden. Der größte Vorteil
vom statischen Linken ist, dass die Bibliothek zum Ausführen der Programme nicht mehr benötigt
wird. Außerdem können der Kompiler und der Linker, beim erzeugen der fertigen Anwendung, den
Programmierer auf nicht vorhandene Funktionen und auf Fehler bezüglich der Kompatibilität zwischen
Anwendung und Bibliothek hinweisen.
2.3.2 Dynamische Bibliotheken
Für eine Funktionsbibliothek eines Betriebssystem sind die Nachteile des statischen Linkens sehr gravierend,
da sie Funktionen enthält, die von vielen Programmen benötigt werden. Da eine solche Funktionsbibliothek
dem Betriebssystem angehört, ist sie sehr wahrscheinlich auch beim der Ausführung des
Programms vorhanden. Dies ermöglicht einen späteren Zeitpunkt des Bindens der Bibliothek an das
Programm. Bibliotheken die beim Ausführen (zur Laufzeit) eines sie nutzenden Programms gebunden
werden, nennt man dynamische Bibliotheken. Diese Bibliotheken werden nur dann in den physischen

2. GRUNDLAGEN 10
Speicher (Arbeitsspeicher) geladen, wenn sie dort noch nicht vorhanden sind. Sie befinden sich also
höchstens einmal im Hauptspeicher und verbleiben dort, bis alle sie verwendenden Prozesse beendet
sind. Beim Binden an ein Programm wird die Bibliothek in dessen virtuellen Adressraum eingeblendet.
Alle nicht statischen Datenbereiche der Bibliothek werden den entsprechenden Bereichen der Anwendung
angegliedert. Sie sind für jeden Prozess der die Bibliothek nutzt, jeweils einmal im Adressraum
des Prozesses zu finden. Deshalb können zwei Prozesse, welche gemeinsam eine Bibliothek nutzen, verschiedene
Ausprägungen der gleichen, in der Bibliothek definierten, globalen Variable besitzen. Eine
Kommunikation der Prozesse mit Hilfe dieser Variablen ist somit nicht möglich. Als Stackspeicher, wird
von der Bibliothek der Stack des aufrufenden Prozesses genutzt. Der statische Teil einer dynamischen
Bibliothek wird von allen Prozessen gemeinsam verwendet. Dafür wird dieser Bereich im Hauptspeicher
von der Speicherverwaltung (memory management unit) vor einem Beschreiben geschützt. Der Maschinencode
einer Bibliothek ist dadurch vor dem Überschreiben gesichert, kommt aber trotzdem maximal
einmal im Hauptspeicher vor. Da die Bibliothek in den virtuellen Adressraum des aufrufenden Prozesses
eingeblendet wird, sind beim Ausführen die Bibliotheksfunktionen genauso effektiv, wie von vornherein
in die Anwendung eingebaute Funktionen. Sie besitzen aber automatisch auch die gleichen Rechte wie
die Anwendung bzw. der Prozess selbst. Dynamische Bibliotheken können entweder fest oder dynamisch
in eine Anwendung eingebunden werden.
Beim festen Linken werden für die benötigten Funktionen (oder Daten) der Bibliothek Scheinobjekte
(sogenannte stubs) erzeugt, damit für den Linker alle Referenzen erfüllt sind. Es sind also wie beim
statischen Linken, alle Funktionsdefinitionen auch im Programm zu finden. Die Implementation ist hingegen
nur in der Bibliothek enthalten. Beim Starten der Applikation wird die Bibliothek, wie zuvor
beschrieben geladen und in den virtuellen Adressraum eingeblendet. Da das Linken beim Start des Programms
erfolgt, also vor Ausführung des Programmcodes, kann die Anwendung auf mögliche Fehler
beim Einbinden der Bibliotheken nicht reagieren. Fehlende Bibliotheken beispielsweise, haben immer
einen Programmabbruch zur Folge. Wie beim statischen Linken, werden beim festen Linken, fehlende
Funktionen und Probleme bei der Kompatibilität zwischen Anwendung und Bibliothek entdeckt und dem
Programmierer beim Erstellen der Anwendung mitgeteilt.
Die zweite Art der Bindung einer dynamischen Bibliothek ist das dynamische Binden. Dabei sind nach
dem Kompilieren der Anwendung weder die Funktionsdefinitionen noch deren Implementation im Programm
festgeschrieben. Das Laden der Bibliothek und das Einblenden in den virtuellen Adressraum geschieht
analog zum festen Linken, allerdings wird beim dynamischen Linken der Zeitpunkt des Bindens
vom Programmierer festgelegt. Dafür stellt das Betriebssystem Funktionen zum Laden und Entladen von
Bibliotheken und zum Ermitteln der Einsprungadressen von Bibliotheksfunktionen oder Bibliotheksdaten
bereit. Da das dynamische Linken vollkommen unabhängig vom Kompiler und vom Linker abläuft,

2. GRUNDLAGEN 11
muss der Programmierer allein dafür sorgen, dass die implizit angenommene Funktionsdefinition mit
der Bibliotheksfunktion übereinstimmt. Dadurch wird es aber auch möglich auf Fehler beim Binden zu
reagieren. Es könnte z. B. auf eine alternative Bibliothek zurückgegriffen werden, wenn die eigentliche
Bibliothek nicht vorhanden ist. Dies ist beim festen Linken nicht möglich.
Abbildung 2.3: Festes Binden einer dynamischen Bibliothek
2.3.3 Windows und dynamische Bibliotheken
In Windows Betriebssystemen werden dynamische Bibliotheken DLL (dynamic link library) genannt.
Sie besitzen alle die Funktion DllMain, welche als Einsprungpunkt beim Laden und Entladen der DLL
dient. Ihr wird als zweiter Parameter der Grund für den Aufruf übergeben. Wird DllMain vom Programmierer
der DLL nicht implementiert, so wird eine Standard DllMain-Funktion erzeugt (für weitere
Informationen siehe [12]). Die von Windows für das dynamische Binden bereitgestellten Funktionen
sind LoadLibrary, FreeLibrary und GetProcAddress. Zum Laden wird LoadLibrary verwendet, welche
bei Erfolg einen Verweis vom Typ HINSTANCE auf die geladene DLL zurückgibt. Dieser Verweis wird
von GetProcAddress verwendet um einen Zeiger auf in der Bibliothek enthaltene Funktionen oder Daten
zu bekommen. Diese können dann mit dem Zeiger ausgeführt bzw. ausgelesen und verändert werden.

2. GRUNDLAGEN 12
FreeLibrary blendet die DLL aus dem virtuellen Adressraum aus und veranlasst zudem das Löschen aus
dem physischen Arbeitsspeicher, wenn sie von keinem anderen Prozess genutzt wird.
2.3.4 Linux und dynamische Bibliotheken
Dynamische Bibliotheken werden in Linux shared objects genannt. Sie besitzen die Einsprungpunkte
_init und _fini für das Laden bzw. Entladen der DLL. Werden diese vom Programmierer nicht implementiert,
werden Standardversionen dieser Funktionen genutzt. Das Laden einer dynamischen Bibliothek
erfolgt über die Betriebssystemfunktion dlopen. Auch hier wird ein Zeiger zurückgegeben der dann
von dlsym genutzt werden kann, um einen Zeiger auf eine Funktion oder ein Objekt der Bibliothek zu
erhalten. Durch dlclose wird die Bibliothek wieder aus dem virtuellen Adressraum entfernt und ggf. aus
dem Hauptspeicher gelöscht.
2.4 Beispiele für Pluginsysteme
In vielen kommerziellen, als auch freien Applikationen werden Pluginsysteme genutzt. Sie erweitern
die bestehende Funktionalität, verändern das Aussehen oder führen komplett neue Funktionen in die
Hostanwendung ein. Im Folgenden sollen einige Pluginsysteme vorgestellt und so Beispielhaft deren
Nutzung in heutigen Anwendungen aufgezeigt werden.
2.4.1 Adobe Photoshop Plugins
Im Bereich der Bildbearbeitung ist das Pluginsystem von Photoshop am verbreitetsten. Es wird nicht nur
von Photoshop selbst, sondern auch von anderen Anwendungen (z. B. Paintshop Pro) zur Erweiterung
genutzt. Auch innerhalb der Produktfamilie von Adobe können häufig die gleichen Plugins untereinander
verwendet werden.
Das Pluginsystem wurde von Adobe mit der Version 2.5 der Bildbearbeitungssoftware Photoshop [1]
eingeführt. Für Pluginentwickler wird ein SDK (Software Development Kit) bereitgestellt, womit sich
Plugins in C (später auch teilweise in C++) schreiben lassen. Diese Sammlung von Programmen und
Dokumentationen war bis 2002 frei zugänglich und kostenlos. Seit 2002 ist die Nutzung des SDK kostenpflichtig.
Von der Firma Centaurix wurde mittlerweile das Photoshop SDK für Delphi portiert [5].
Neben der Programmierung von Plugins mittels C/C++ bzw. Delphi, gibt es die Möglichkeit Plugins mit
verschiedenen Hilfsprogrammen zu erstellen. Diese Programme nehmen dem Entwickler viele Aufgaben
ab und verbergen den eigentlichen C/C++ Quellcode des Plugins. Sie werden zumeist für die Entwicklung
freier Plugins genutzt. Einige Beispiele für diese Programme sind „Filter Factory“, „Filter Formula“

2. GRUNDLAGEN 13
und „Filter Meister“.
Für die Erweiterung von Photoshop sind verschiedene Arten von Plugins verfügbar:
Image Filter Dies ist wohl die häufigste Art von Plugin. Sie können Bilder in verschiedenster Weise
verändern. Ein Beispiel für ein solches Plugin ist der Filter „Wolken“, welcher das ausgewählte
Bild, unter Zuhilfenahme der Vordergrund- und Hintergrundfarbe, mit einem Wolkenmuster füllt.
Import Mit einem solchen Plugin können neue Quellen bestimmt werden, aus denen sich Bilder zur
Bearbeitung mit Photoshop importieren lassen.
Export Neben dem Speichern von Bildern auf Festplatten, können durch ein Export Plugin auch andere
Ziele (z. B. Drucker) definiert werden.
Format Die von Photoshop unterstützen Grafikformate können mit dieser Art Plugin erweitert werden.
Color Picker Hiermit lässt sich ein eigener Farbwahldialog designen und in Photoshop nutzen.
Selection Um Photoshop eigene Auswahl-, Pfad- oder Ebenenfunktionen hinzuzufügen, kann ein Pluginentwickler
diesen Plugintyp nutzen.
Automation So ziemlich alle Menuaktionen und Tooloperationen lassen sich mit diesem Plugintyp
automatisieren. Es können unter Anderem auch weitere Plugins gestartet werden.
Extension und Parser Die Schnittstellen dieser Plugintypen sind nicht öffentlich. Solche Plugins
werden nur von Adobe erstellt.
Alle erstellten Plugins werden in entsprechende Verzeichnisse von Photoshop kopiert, wo sie beim Start
der Anwendung gesucht werden. Photoshop prüft dabei für jedes Plugin ob es eine sogenannte „plugin
property list“ (PiPL) als Ressource enthält. Eine solche Liste stellt alle benötigten Informationen über
das Plugin bereit. Diese Informationen werden von Photoshop auch zum Darstellen der Plugins im Menu
genutzt. So kann z. B. für Filter der Untermenüpunkt festgelegt werden, unter welchem der Filter in
Photoshop zu finden ist.
Die Schnittstelle von Plugin und Hostanwendung ist sehr einfach gehalten. Von der Hostanwendung
wird die Funktion main des Plugins zur Kommunikation genutzt. Die Art der Interaktion wird über ein
Integerparameter bestimmt. Alle gemeinsam genutzten Daten werden über Zeiger auf die Datenbereiche
mitgeteilt, welche als Parameter der Funktion main übergeben werden.
2.4.2 Qt Plugins
Trolltechs API Qt unterstützt ebenfalls die Nutzung von Plugins. Qt stellt dabei eine Sammlung von Klassen,
Funktionen und Makros bereit, die der Erstellung von Plugins und Hostanwendungen dienen. Eine
Qt nutzende Anwendungen kann die Klasse QPluginLoader verwenden, um so durch Plugins erweitert

2. GRUNDLAGEN 14
werden zu können. Für ein Pluginsystem mit Qt müssen als Erstes die Schnittstellen definiert werden.
Sie werden mit Hilfe von einem Makro Qt bekannt gemacht und können den Plugins als Basisklassen
dienen. So erstellte Plugins können von einem QPluginLoader Objekt geladen und mit qobject_cast auf
Schnittstellen getestet werden.
Neben diesem Pluginsystems für Anwendungen, enthält die Qt Klassenbibliothek schon fertige Basisplugins,
um Qt selbst zu erweitern. Für eigene Erweiterungen von Qt kann von diesen Plugins geerbt,
eigene Funktionen hinzugefügt und dann mittels einem dafür vorgesehenen Makro das neue Plugin
bei Qt registriert werden. Je nach gewähltem Basisplugin muss die neu geschriebene Erweiterung in
ein spezielles Verzeichnis kopiert werden, damit Qt es nutzen kann. Sollen Applikationen weitergegeben
werden, die eine so erweiterte Qt API nutzen, dann müssen die Plugins entweder statisch an das
Programm gelinkt werden, oder mit der Applikation mitgeliefert und in entsprechende Verzeichnisse gesteckt
werden. In Tabelle 2.1 werden alle vordefinierten Basisplugins und deren Standardverzeichnisse
aufgelistet.
Plugin
QAccessibleBridgePlugin
QAccessiblePlugin
QDecorationPlugin
QIconEnginePlugin
QImageIOPlugin
QInputContextPlugin
QKbdDriverPlugin
QMouseDriverPlugin
QPictureFormatPlugin
QScreenDriverPlugin
QScriptExtensionPlugin
QSqlDriverPlugin
QStylePlugin
QTextCodecPlugin
Verzeichnis
accessiblebridge
accessible
decorations
iconengines
imageformats
inputmethods
kbddrivers
mousedrivers
pictureformats
gfxdrivers
script
sqldrivers
styles
codecs
Tabelle 2.1: Qt Plugins

3. DIE PLUGIN API FÜR C++ 15
3 Die Plugin API für C++
Wie bereits zuvor erwähnt, gibt es sowohl für C++ also auch für .NET eine API. Im Folgenden werden
die einzelnen Teile der API für die Programmiersprache C++ näher beleuchtet und deren Verwendung
erklärt. Die Grundidee der C++ Plugin API besteht darin, dass eine Reihe von Schnittstellen definiert
werden und jedes Plugin von den Schnittstellen erbt, die nach Außen sichtbar sein sollen, d. h. deren
Funktionen das Plugin unterstützt und von der Hostanwendung genutzt werden können. Damit das
Ansprechen verschiedener Plugins möglich wird, wurde eine Schnittstelle definiert, von der alle Plugins
erben. Diese Schnittstelle ist iplugin_base. In der C++ Plugin API werden neben den Schnittstellen
auch Klassen eingeführt, die zum Laden und Schreiben von Plugins nötig sind. Außerdem werden einige
Typen deklariert, welche die Arbeit mit Plugins erleichtern sollen. Da es in C++ keine spezielle
Schnittstellendeklaration gibt, werden hier einfache Klassen verwendet. Diese können aber wie Schnittstellen
(interfaces) behandelt werden, weil C++ Mehrfachvererbung unterstützt, d. h. eine C++ Klasse
aus mehreren Basisklassen bestehen.
3.1 Typenreflektion mit dynamic_cast
Abbildung 3.1: Speicherlayout eines Plugins

3. DIE PLUGIN API FÜR C++ 16
Für alle Plugins, die mit Hilfe der hier vorgestellten C++ API erstellt wurden, gibt es eine gemeinsame
Basisklasse. Dies ist die Schnittstelle iplugin_base. Da neben dieser Basisklasse ein Plugin von beliebigen
anderen Klassen erben kann, wird ein Zeiger auf iplugin_base (piplugin_base) zum Ansprechen der
Plugins genutzt. In Abbildung 3.1 ist beispielhaft das Speicherlayout eines C++ Plugins zu sehen. Um
neben iplugin_base auch die anderen Schnittstellen (Basisklassen) ansprechen zu können, müssen zur
Laufzeit der Typ und die Basisklassen für das Plugin bekannt sein. Allgemeiner Formuliert muss man
zur Laufzeit für jedes Objekt die zugrunde liegende Klasse bzw. deren Eigenschaften ermitteln können.
Dieses Konzept wird Typenreflektion oder auch RTTI (runtime type information - „Typinformation zur
Laufzeit“) genannt. Die Sprache C++ unterstützt Typenreflektion nur für polymorphe Objekte, d. h. sie
müssen eine Instanz einer virtuellen Klasse sein und so zumindest eine virtuelle Methode besitzen. Der
Grund für diese Voraussetzung ist, dass der C++ Kompiler jeder virtuellen Klasse einen Zeiger auf die
sogenannte virtual function pointer table (vtbl) anfügt. Eine solche Funktionstabelle wird zur Laufzeit
für jede virtuelle Klasse geführt. Der Operator dynamic_cast nutzt diese Tabelle für die Typenreflektion
und bietet so eine generische Methode, um zur Laufzeit mögliche Basisklassen eines Typs zu ermitteln.
Dynamic_cast kann außerdem mit einem Verweis (Zeiger oder Referenz) auf eine Teilklasse eines polymorphen
Objekts, auf das Vorhandensein weiterer Teilklassen (Basisklassen) dieses Objektes testen. Er
könnte also z. B. mit einem Zeiger auf die Schnittstelle iplugin_base eines Plugins testen, ob dieses Plugin
auch die Schnittstelle irenderable implementiert. Um das zu realisieren versucht dynamic_cast den
Verweis eine Teilklasse in einen Verweis auf die andere Teilklasse des gleichen polymorphen Objekts zu
wandeln. Für die Typumwandlung wird der dynamische Typ eines Verweises geprüft, und die Wandlung
nur dann ausgeführt, wenn sie erlaubt ist. Dem Beispiel von weiter oben folgend würde dynamic_cast also
erst den Typ des Plugins ermitteln, zu welchem die Teilklasse gehört, auf welche piplugin_base zeigt
und dann testen ob dieser Plugintyp in die Schnittstelle irenderable umgewandelt werden kann. Ist der
Verweis ein Zeiger wird bei einer unerlaubten Wandlung von Typen ein Nullzeiger zurückgegeben. Wird
eine Referenz als Verweis genutzt, wirft dynamic_cast im Fehlerfall eine Ausnahme vom Typ bad_cast.
[3] Quelltext A.1 zeigt die Verwendung von dynamic_cast.
3.2 Schnittstellendefinitionen in PluginDefs
Damit die Hostanwendung und die Plugins kommunizieren können, müssen die Schnittstellen zwischen
Beiden definiert werden. Diese Definition muss an zentraler Stelle erfolgen und sowohl vom Plugin als
auch von der Hostanwendung unabhängig sein. In der C++ Plugin API sind alle Schnittstellendefinitionen
in der statische Bibliothek PluginDefs enthalten. Alle dort definierten Schnittstellen können bei der
Entwicklung von Plugins verwendet werden. Da C++ wie bereits erwähnt keine spezielle Deklaration für

3. DIE PLUGIN API FÜR C++ 17
Schnittstellen vorsieht, sind alle Schnittstellen virtuelle Klassen ,die von plugin_interface_class erben.
Außer der Standardschnittstelle iplugin_base sind alle Schnittstellen nicht abstrakt, obwohl dies dem
Charakter einer Schnittstelle am ehesten entsprechen würde. Es brächte aber einige Nachteile mit sich,
wenn sie alle abstrakt wären, denn es ist in C++ nicht möglich eine Liste von Typen zu erzeugen. Eine
solche Liste wird aber z. B. beim Laden eines Plugins benötigt, um die Schnittstellen anzugeben, die
ein zu ladendes Plugin implementieren soll (siehe dafür Kapitel 3.3.1). Durch den Verzicht auf abstrakte
Schnittstellenklassen können nun Instanzen der einzelnen Schnittstellen in eine Liste gesteckt werden.
Eine solche Liste die Schnittstellen aufnehmen kann ist in der C++ Plugin API bereits definiert und heißt
plugin_interface_list.
3.2.1 Plugin_interface_class
Die abstrakte Klasse plugin_interface_class ist die Basisklasse aller Plugin-Schnittstellen der API. Über
sie können alle Schnittstellen angesprochen werden und wie bereits erwähnt in einer Liste zusammengefasst
werden. Wie im Quelltext A.2 zu sehen wird in der Klasse die abstrakte Boolesche Funktion
is_implemented_by definiert, welche von allen erbenden Schnittstellen implementiert werden muss. Die
Funktion bestimmt für ein übergebenes Plugin, ob dieses die aktuelle Schnittstelle unterstützt. Um zu
testen, ob ein Plugin eine Schnittstelle unterstützt, muss als Erstes eine Instanz der Schnittstelle erstellt
werden und dann der Methode is_implemented_by dieser Schnittstelle, das Plugin als Parameter
übergeben werden. Im Normalfall wird in der Funktion zum Testen eine Umwandlung mittels dynamic_cast
von dem übergebenen Plugin zur Schnittstelle durchgeführt. Scheitert diese Umwandlung, wird
von is_implemented_by „false“ zurückgegeben. Im Erfolgsfall liefert die Funktion ein „true“ zurück. In
der Verwaltungsklasse plugin_loader wird is_implemented_by z. B. zum selektiven Laden der Plugins
genutzt, die bestimmte Schnittstellen beinhalten.
3.2.2 Iplugin_base
Für den ersten Zugriff auf ein Plugin wird die Standardschnittstelle iplugin_base genutzt. Sie ist eine
Schnittstelle, die von allen Plugins implementiert werden muss. In ihr ist die abstrakte Funktion
get_plugin_name angegeben. Sie ermöglicht es dem Plugin einen Namen zu geben. Daneben wird die
ebenfalls abstrakte Funktion create_new_instance definiert, welche einen Zeiger vom Typ piplugin_base
auf eine neue Instanz eines Plugins zurückliefert. Genau wie die Methode get_plugin_name muss auch
create_new_instance vom Entwickler eines Plugins implementiert werden. Zumeist wird dies in der Pluginfabrik
passieren (siehe dafür Kapitel 3.4.2). Neben der Klasse iplugin_base wird mit piplugin_base
ein Zeiger auf eine Instanz dieser Klasse definiert. Weiterhin kann iplugin_pointer_list dazu genutzt

3. DIE PLUGIN API FÜR C++ 18
werden um Plugins in einer Liste zu speichern. Der Quelltext A.3 zeigt den Header der iplugin_base
Schnittstelle.
3.2.3 Irenderable
Für alle Plugins die auf irgendeine Weise, Inhalte in der Hostanwendung grafisch ausgeben wollen, ist die
Schnittstelle irenderable gedacht. Plugins, die von irenderable erben, können über die Funktion render
angesprochen werden. Diese Funktion wird vom Plugin implementiert und sollte eine grafische Ausgabe
bewirken. Sie kann dann immer aufgerufen werden ,wenn die Hostanwendung neu gezeichnet werden
muss.
Die Schnittstelle irenderable beinhaltet keine Einschränkung bezüglich der Art der grafischen Ausgabe.
Die render Methode könnte jede beliebige Systembibliothek zum Zeichen verwenden. Für Hostanwendungen
die verschiedene Systembibliotheken zur Ausgabe von Daten nutzen kann, ist es deshalb ratsam
in einem Plugin mit grafischer Ausgabe, neben irenderable noch eine weitere Schnittstelle zu implementieren,
welche die Art der Ausgabe genauer spezifiziert. Dadurch kann beim Laden eines Plugins
festgelegt werden, was für Systembibliotheken zur Darstellung von Inhalten von der Hostanwendung
unterstützt werden. Ein Plugin könnte z. B. zusätzlich die Schnittstelle id3d9_plugin implementieren.
Beim Laden dieses Plugins würde das Pluginsystem dann feststellen können, dass die grafische Ausgabe
mit Direct3D 9 durchgeführt wird.
3.2.4 Id3d9_plugin
Die Schnittstelle id3d9_plugin ist für Plugins gedacht, die mit Direct3D 9 auf einen Bereich der Hostanwendung
zeichnen möchten. Die Hostanwendung ist also für die Initialisierung von Direct3D 9 zuständig,
d. h. unter anderem für das Erstellen eines IDirect3DDevice9 Objektes, welches die Zeichenfläche
für Direct3D 9 darstellt. Ein solches Objekt wird in Direct3D 9 von allen Funktionen benötigt, die etwas
darstellen wollen. Deswegen muss es auch einem Plugin zur Verfügung stehen, welches grafische
Objekte mittels Direct3D 9 ausgeben möchte. Für dieses Problem enthält id3d9_plugin die Funktion init_d3d9.
Sie besitzt als Parameter einen Standardzeiger vom Typ void. Der Zeiger ist nicht näher typisiert,
weil es sonst feste Abhängigkeiten zwischen der Plugin API und den DirectX Bibliotheken gäbe. Es ist
vorgesehen, dass dieser Zeiger auf ein IDirect3DDevice9 Objekt zeigt, welches in der Hostanwendung
erstellt wurde. Dieser Zeiger kann vom Plugin gespeichert werden und ihm so Zugriff auf das benötigte
IDirect3DDevice9 Objekt bieten. Mit init_d3d9 kann das Plugin außerdem alle für seine grafischen
Ausgaben notwendige Objekte erstellen. Um diese Objekte wieder freizugeben, kann release_d3d9 verwendet
werden.

3. DIE PLUGIN API FÜR C++ 19
Eine Hostanwendung die Plugins unterstützt, welche die id3d9_plugin Schnittstelle implementieren,
muss sich darum kümmern, dass die Funktionen init_d3d9 und release_d3d9 an den notwendigen Stellen
aufgerufen werden.
3.2.5 IPluginEventCallback
Bei einigen Anwendungen des Pluginsystems kann es notwendig sein, dass die Hostanwendung auf
bestimmte Ereignisse in einem Plugin reagiert. Beispielsweise könnte ein Plugin der Hostanwendung
signalisieren, dass Teile von einer Datenmenge fertig bearbeitet wurden und bereit sind von der Hostanwendung
ausgegeben zu werden. Für solcher Art Plugins ist die Schnittstelle iplugin_event_callback gedacht,
deren Aufbau im Quelltext A.4 zu sehen ist. Sie führt die zwei bereits implementierten Methoden
set_event_callback und do_event ein, welche einem Plugin die Möglichkeit bieten, zur Ereignisbehandlung
eine Funktion der Hostanwendung zu nutzen. Eine solche Funktion in der Hostanwendung wird
in der Programmierung „callback“ Funktion genannt, weil sie im Plugin „zurückgerufen“ werden kann.
Sie muss dem von cplugin_event_callback festgelegten Typ entsprechen, d. h. sie besitzt keinen Rückgabewert
und hat als einzigen Parameter den Aufzählungstyp enum_plugin_event. Durch die Methode
set_event_callback wird sie für die Behandlung von Ereignissen im Plugin festgelegt. Dies wird erreicht,
indem set_event_callback den private Funktionszeiger cfpdo_event auf die als Parameter übergebene
„callback“ Funktion setzt. Tritt im Plugin ein Ereignis ein, dass gemeldet werden soll, muss die private
Schnittstellenmethode do_event vom Plugin aufgerufen werden. Diese stößt wiederum die Hostfunktion
an, auf die von cfpdo_event gezeigt wird. Dadurch wird das Ereignis nach Außen bekannt zu geben, und
kann in der „callback“ Funktion behandelt werden. Die Art des Ereignisses wird aus einer Aufzählung
vom Typ enum_plugin_event bestimmt und als Parameter der „callback“ Funktion mitgeteilt.
3.2.6 Ikeyboard_event_handler
In den meisten Bereichen, in denen Plugins benutzt werden, kümmert sich die Hostanwendung um die
Interaktion mit dem Benutzer. Tastatureingaben und andere Ereignisse werden in dafür vorgesehenen
Funktionen behandelt. Mit Hilfe der Schnittstelle ikeyboard_event_handler können die Tastaturereignisse
an ein Plugin weitergegeben werden, wodurch dieses dann auf das übergebene Ereignis reagieren
kann. In der Schnittstelle werden drei Arten von Tastaturereignissen unterschieden. Wird eine Taste herunter
gedrückt kann dies mit der Methode on_key_down dem Plugin mitgeteilt werden. Durch on_key_up
erfährt das Plugin, dass eine Taste wieder losgelassen wurde. Wurde eine Taste gedrückt und wieder losgelassen,
wird dies durch on_key_press dem Plugin übergeben. Allen drei Methoden wird die gedrückte
Taste als Parameter übergeben. Dafür wird der Aufzählungstyp xp_key_code verwendet.

3. DIE PLUGIN API FÜR C++ 20
3.2.7 Imouse_event_handler
Wenn Plugins auf Mausereignisse reagieren sollen, kann imouse_event_handler implementiert werden.
Genau wie bei der Schnittstelle ikeyboard_event_handler, werden hier die von der Hostanwendung
aufgefangenen Ereignisse, an das Plugin weitergegeben. Die Methode on_mouse_button_down meldet
dem Plugin, dass ein Mausknopf herunter gedrückt wurde. Dagegen kann ein losgelassener Knopf
mit on_mouse_button_up bekannt gemacht werden. Durch on_mouse_move werden Mausbewegungen
mitgeteilt. Um einen Mausklick weiterzugeben wird on_mouse_click genutzt und für Doppelklicks ist
on_mouse_dbclick zuständig. Als Parameter wird ein Wert vom Aufzählungstyp xp_mouse_button und
die Mauskoordinaten als int erwartet.
3.3 Die Verwaltungsklasse plugin_loader
In einer Hostanwendung gibt es in Bezug auf Plugins drei wichtige Aufgaben. Die Plugins müssen dynamisch
geladen werden können, der Zugriff auf die geladenen Plugins muss schnell und einfach vonstatten
gehen und nicht mehr benötigte Plugins müssen auch wieder entfernbar sein. Um dem Entwickler
einer Hostanwendung diese Dinge abzunehmen, enthält die C++ Plugin API die Verwaltungsklasse plugin_loader,
welche für jede der einzelnen Aufgaben passende Methoden bereitstellt. Die Hostanwendung
muss nun nur noch ein Objekt aus der Klasse erzeugen und kann dann mit dessen Hilfe Plugins nutzen.
Der Quelltext A.5 zeigt den Header der Verwaltungsklasse plugin_loader.
Da das Laden und Entladen von Plugins das dynamische Binden bzw. entfernen von Bibliotheken beinhaltet,
ist plugin_loader auf die in Kapitel 2.3.3 und 2.3.4 beschriebenen Systemfunktionen angewiesen.
Damit die Plattformunabhängigkeit der Klasse gewährleistet bleibt, werden statt den systemspezifischen
Funktionen, die in den Dateien „CrossPlattform.h“ und „CrossPlattform.cpp“, für Linux und
Windows implementierten, plattformunabhängigen Funktionen xp_load_library, xp_get_proc_address
und xp_free_library genutzt.
Zum Laden dynamischer Bibliotheken wird xp_load_library verwendet. Diese gibt ein xp_dll_handle
zurück, welches zur Identifizierung der geladenen Bibliothek dient. Ein solches xp_dll_handle wird
z. B. von der Methode xp_get_proc_address benötigt. Diese Methode wird dazu genutzt, um in der
zum übergebenen xp_dll_handle passenden dynamischen Bibliothek, die Einsprungadresse der Funktion
get_plugin_factory_list zu finden. Auf den Nutzen dieser Funktion und weitere Einzelheiten zum Laden
von Plugins wird in Kapitel 3.3.1 genauer eingegangen. Sind alle Plugins einer Bibliothek nicht mehr
in Gebrauch, kann die Bibliothek mit xp_free_library entladen werden. Welche Bibliothek freigegeben
werden soll, wird durch den Parameter vom Typ xp_dll_handle bestimmt.

3. DIE PLUGIN API FÜR C++ 21
3.3.1 Laden neuer Plugins
Wie bereits erwähnt, wird dem Entwickler durch die Klasse plugin_loader u. a. das Laden von Plugins
vereinfacht. Dafür ist die überladene Methode load zuständig. Wie der Quelltext A.5 zeigt ist dazu immer
der Name der Pluginbibliothek inklusive dem Pfad erforderlich. Optional kann außerdem eine Liste
von Schnittstellen übergeben werden. In der Methode wird zuerst die angegebene dynamische Bibliothek
durch die plattformunabhängige Funktion xp_load_library geladen. Das zurückgegebene xp_dll_handle
wird in einer Struktur vom Typ plugin_list_item gespeichert. Diese enthält neben dem xp_dll_handle
noch einen Zeiger auf ein geladenes Plugin. Der Zeiger ist wie üblich vom Typ piplugin_base. Nach
dem Laden der Bibliothek wird ein Funktionszeiger definiert, welchen xp_get_proc_address anschließend
auf die Einsprungadresse der „C“-Funktion get_plugin_factory_list setzt. Diese Funktion wird vom
Entwickler einer Pluginbibliothek implementiert, und gibt eine Referenz auf eine Liste sogenannter Pluginfabriken
zurück (siehe Kapitel 3.4). Nachdem xp_get_proc_address erfolgreich den Funktionszeiger
gesetzt hat, wird dieser zum Ausführen der zugewiesenen „C“-Funktion genutzt. Dadurch erhält man
die oben erwähnte Referenz und kann mit ihrer Hilfe die Plugins der Bibliothek erzeugen, welche die
geforderten Schnittstellen unterstützen. Wurde der Methode load keine Liste von notwendigen Schnittstellen
übergeben, werden alle Plugins aus der Bibliothek erzeugt. Zum Abschluss werden Zeiger auf
diese Plugins in der Struktur vom Typ plugin_list_item gespeichert, und dann zusammen mit dem zugehörigen
xp_dll_handle in die Liste m_plugin_list vom Typ plugin_list eingetragen, welche der Klasse
plugin_loader angehört. Soll ein Plugin vor dem Programmende aus dieser Liste entfernt werden, kann
man entweder die Methode delete_plugin der Klasse plugin_loader verwenden, oder direkt auf die Liste
zugreifen und deren Methode zum Löschen verwenden.
3.3.2 Pluginliste
Von der Klasse plugin_loader geladene Plugins werden in einer Liste vom Typ plugin_list gespeichert.
Diese Liste heißt m_plugin_list, ist öffentlich und kann so wenn nötig über das plugin_loader Objekt direkt
angesprochen werden. Im Normalfall wird sie aber nur von den Methoden der Klasse plugin_loader
genutzt. Auf den Zugriff und den Umgang mit Plugins wird im folgenden Kapitel 3.3.3 näher eingegangen.
Ein Element der Liste plugin_list ist durch plugin_list_item beschrieben. Es enthält einen Zeiger auf
eine Plugininstanz und einen Verweis (Handle) auf die dazugehörigen Bibliothek. Wie der Quelltext
A.6 zeigt, werden intern diese Listeneinträge in einem vector gespeichert. Das Hinzufügen von Einträgen
geschieht durch die Methode add_item. Ihr werden die neuen Einträge mittels einem als Parameter
übergebenen plugin_list_item mitgeteilt. Die Klasse plugin_loader nutzt sie beim Laden der Plugins aus

3. DIE PLUGIN API FÜR C++ 22
einer Bibliothek. Das Entfernen von bestehenden Elementen erfolgt durch delete_item. Dieser Methode
wird der Index des zu löschenden Listeneintrags, als Parameter überliefert. Beim Löschen von Einträgen,
kümmert sich die Klasse plugin_list auch darum, dass neben der Plugininstanz die zugehörige Bibliothek
aus dem Speicherbereich der Hostanwendung ausgeblendet (entladen) wird, wenn kein anderes Plugin
dieser Bibliothek in der Liste vorhanden ist. Durch Aufruf des Destruktors der Listenklasse, also beim
Freigeben des Objektes, werden automatisch alle Elemente der Liste mit Hilfe von delete_item gelöscht.
Um ein bestimmtes Plugin aus der Liste anzusprechen, nutzt plugin_loader die Methode get_plugin,
welche einen Zeiger vom Typ piplugin_base zurückgibt. Durch plugin_count wird die Anzahl der in der
Liste enthaltenen Plugins zurückgegeben.
3.3.3 Zugriff auf Plugins
Neben Methoden zum Laden und Entfernen von Plugins, bietet plugin_loader auch Möglichkeiten zum
Zugriff auf die geladenen Plugins. Die Pluginliste m_plugin_list ist zwar wie bereits erwähnt öffentlich
und somit auch direkt ansprechbar, allerdings gestaltet sich der Zugriff durch die vom plugin_loader
bereitgestellten Funktionen etwas einfacher. Diese Funktionen sind zum Einem get_plugin und zum Anderen
get_interface.
Genau wie bei der gleichnamigen Methode der Klasse plugin_list, wird auch hier get_plugin der Index
des gewünschten Plugins übergeben und ein Zeiger auf die iplugin_base Basisklasse des Plugins
zurückgeliefert. Dieser Zeiger kann dann mit Hilfe von dynamic_cast in andere Schnittstellen umgewandelt
werden. Eine andere Möglichkeit des Zugriffs bietet die inline Schablonenmethode get_interface.
Ihr wird als Schblonenparameter eine gewünschte Schnittstelle übergeben. Der als Funktionsparameter
angegebene Index, bestimmt das Plugin aus der Liste, für welches der Zugriff auf die angegebene
Schnittstelle gewährt werden soll. Wie im Quelltext A.5 zu sehen ist, führt get_interface dann eine
Typumwandlung mittels dynamic_cast durch, und liefert einen Zeiger zurück, der auf die geforderte
Schnittstelle zeigt. Enthält das Plugin keine solche Schnittstelle, wird ein Nullzeiger zurückgegeben.
Der Quelltext A.7 zeigt den Umgang mit beiden Methoden.
3.4 Plugin Bibliotheken schreiben
Das Schreiben von Plugins, die durch Klassen der hier vorgestellten API genutzt werden sollen, gestaltet
sich kaum unterschiedlich zum Schreiben normaler Anwendungen. Da Plugins im Speicherbereich des
aufrufenden Prozesses ausgeführt werden, besitzen sie die gleichen Rechte und Einschränkungen wie zu
dem Prozess gehörende Funktionen. Ein wichtiger Unterschied besteht allerdings darin, dass ein Plugin

3. DIE PLUGIN API FÜR C++ 23
selten alleine in der Hostanwendung agiert. Das bedeutet, dass je nachdem wie stark die Plugins in eine
Anwendung eingreifen, sich auch indirekt der Einfluss der Plugins untereinander erhöht. Nutzt beispielsweise
ein Plugin die Funktionen von OpenGL zur grafischen Ausgabe, so bleiben die dafür benötigten
Änderungen an OpenGL (z. B. Lichteinstellungen, Farben o. Ä.) innherhalb der gesammten Hostanwendung
erhalten. Ein weiteres, OpenGL nutzendes Plugin, könnte also dadurch beeinflusst werden und so
seine Daten nicht wie gewünscht ausgeben. Ein Plugin sollte deshalb nur soviel wie unbedingt nötig an
„Eigenschaften“ der Hostanwendung ändern und soweit wie möglich die unerwünschten, aber für die
Funktion des Plugins notwendigen, Änderungen nach der Ausführung des Plugins wieder rückgängig
machen.
Damit Plugins von einer Instanz der Klasse plugin_loader geladen werden können, müssen sie vom
Pluginentwickler in eine dynamische Bibliotheken geschrieben werden. Eine solche Bibliothek kann im
Prinzip eine beliebige Zahl an Plugins enthalten. Für das Laden ist es nötig das alle enthaltenen Plugins
an zentraler Stelle registriert sind. Dazu dient eine Verwaltungsklasse vom Typ plugin_factory_list_class,
auf welche im folgenden Kapitel 3.4.1 genauer eingegangen wird. Damit eine Hostanwendung Zugriff
auf diese Liste bekommt, muss eine Pluginbibliothek die Funktion get_plugin_factory_list exportieren.
Diese Funktion wird als „C“-Funktion deklariert, damit der Compiler kein „name mangeling“ durchführt.
Das „name mangeling“ ist eine Bezeichnung für die Umbenennung von Funktionen durch den
C++ Kompiler. Der neue Name wird unter Einbeziehung des Funktionsnamen und der Funktionsparameter
gebildet. Der Grund für die Umbenennung durch den Kompiler liegt darin, dass C++ Funktionen
überladen werden können, d. h. dass es möglich ist, sie mit jeweils unterschiedlichen Parametern mehrfach
zu implementieren. Dadurch ist aus dem Funktionsnamen allein nicht eindeutig zu schließen welche
Implementation dieser Funktion gemeint ist. Da aber Symbole, also Funktionen und andere globale
Objekte in einer kompilierten Datei, über den Namen angesprochen werden, muss der C++ Kompiler
die Funktionsnamen wie oben beschrieben erweitern. Leider gibt es keinen Standard für diese Umbenennung.
Der Symbolname einer C++ Funktion kann also je nach Kompiler variieren. Da Plugins mit
unterschiedlichen C++ Kompilern geschrieben worden sein können, der Name der Funktion aber vorher
bekannt und überall gleich sein soll, wird get_plugin_factory_list also als „C“-Funktion deklariert.
In C gibt es keine Möglichkeit zum überladen von Funktionen und es findet darum auch kein „name
mangeling“ statt.
3.4.1 plugin_factory_list_class
Wie zuvor erwähnt, exportiert jede Pluginbibliothek eine Funktion get_plugin_factory_list. Sie gibt eine
Referenz auf eine Instanz der Klasse plugin_factory_list_class zurück. Diese stellt wiederum eine

3. DIE PLUGIN API FÜR C++ 24
Liste dar, welche für jedes Plugin der Bibliothek eine sogenannte „Pluginfabrik“ (siehe Kapitel 3.4.2)
enthält. Sie führt die Funktion create_plugin ein, welche ein ausgewähltes Plugin mit Hilfe der zugehörigen
„Fabrik“ erstellt. Welches Plugin zu erstellen ist, wird über einen als Parameter übergebenen
Index festgelegt. Neben dieser Funktion kann create_all_plugins genutzt werden, um mehrere Plugins
der Bibliothek zu erstellen. Ihr werden zwei Listobjekte als Parameter übergeben. Die erste Liste ist
bei der Übergabe leer und wird von der Funktion mit Zeigern auf die erstellten Plugins gefüllt. Diese
Zeiger sind vom Typ piplugin_base, zeigen also auf die Standardschnittstelle iplugin_base des erstellten
Plugins. Die zweite Liste, die von create_all_plugins verlangt wird, enthält Instanzen aller Schnittstellen,
welche das zu erzeugende Plugin implementieren soll. Sie dient also als Filter, um nicht alle Plugins
einer Bibliothek in eine Hostanwendung aufnehmen zu müssen. Wird eine leere Liste übergeben, werden
dementsprechend alle Plugins der Bibliothek geladen. Sowohl create_all_plugins als auch create_plugin
werden im Normalfall nicht direkt vom Entwickler aufgerufen. Die Klasse plugin_loader nutzt sie zum
Laden der Plugins (siehe auch Kapitel 3.3.1).
Eine typische Pluginbibliothek enthält genau eine globale Instanz der Klasse plugin_factory_list_class,
von welcher mit der oben beschriebenen Funktion, eine Referenz an die Hostanwendung übergeben wird.
Dieser Instanz müssen alle Plugins der Bibliothek bekannt gemacht werden. Dafür ist die Schablonenfunktion
register_factory vorgesehen. Ihr wird mittels Schablonenparameter eine „Pluginfabrikklasse“
übergeben. Aus dieser erzeugt die Funktion eine Instanz, die sie dann in der Liste m_class_factory_list
speichert. Im Quelltext A.8 ist die Listenklasse und die Implementation der Schablonenfunktion register_factory
zu sehen.
3.4.2 Pluginfabriken
Will man eine Pluginbibliothek schreiben, die mit den hier vorgestellten Klassen kompatibel ist, muss für
jedes Plugin, welches der Bibliothek hinzugefügt wird, auch eine „Pluginfabrik“ vorhanden sein. Eine
solche Klassenfabrik (engl. class factory) ist in der Lage, Instanzen des ihr zugeordneten Plugins zu erzeugen.
Sie erben von den gleichen Schnittstellen wie das Plugin, was sie erzeugen wollen, implementieren
aber die Schnittstellenmethoden nicht neu. Eine Ausnahme bildet die abstrakte Standardschnittstelle
iplugin_base. Sie „zwingt“ den Pluginentwickler dazu, die Beiden für die Fabrik wesentlichen Methoden
zu implementieren. Die Eine ist get_plugin_name und liefert den Namen des zu erstellenden Plugins
zurück. Die Andere ist create_new_instance. Sie ist für das eigentliche erstellen des Plugins zuständig.
In Pluginbibliotheken werden „Pluginfabriken“ in eine Liste eingetragen um einer Hostanwendung, welche
die jeweilige Bibliothek aufruft, mitteilen zu können, welche Plugins in der Bibliothek enthalten
sind (siehe Kapitel 3.4.1). Hierzu werden nicht die Plugins selbst gelistet, weil die „Fabriken„ sowohl

3. DIE PLUGIN API FÜR C++ 25
weniger Speicherplatz benötigen, als auch meist schneller zu erzeugen sind als die zugehörigen Plugins.
Trotzdem besitzen sie die zum Laden von Plugins nötigen Informationen über unterstütze Schnittstellen
sowie den zur Identifikation der Plugins nützlichen Pluginnamen.
Die Plugin API verlangt von „Pluginfabriken“, dass sie die gleichen Schnittstellen besitzen wie das von
ihnen erzeugte Plugin selbst. Dies kann dadurch erreicht werden, dass das Plugin allein von der „Fabrik“
erbt. Es müsste dann auch die beiden Funktionen der Standardschnittstelle iplugin_base nicht erneut implementieren,
da dies bereits in der Basisklasse, der „Pluginfabrik“, geschehen ist. Der Pluginentwickler
ist aber nicht dazu gezwungen so vorzugehen. Er könnte einem Plugin auch weitere Basisklassen zuweisen.
Es ist aber zu beachten, dass eine Hostanwendung immer nur die Schnittstellen der „Pluginfabrik“
abfragen kann, nicht die des Plugins.

4. DIE PLUGIN API FÜR .NET 26
4 Die Plugin API für .NET
Will man Pluginsysteme in .NET verwenden, kann die C++ API nicht genutzt werden. Aus diesem Grund
wurden die Klassen der C++ API für eine .NET Version umgeschrieben. Dafür wurde die Programmiersprache
C# verwendet. Die entstandene API kann aber auch von allen anderen „managed“ Sprachen
benutzt werden. Für eine Zusammenarbeit von C++ und .NET Komponenten, muss der Entwickler eine
„gemischte“ Anwendung schreiben, d. h. eine Anwendung mit einen „native“ Teil und einem „managed“
Teil und auch allein die Kommunikation der beiden Teile bewältigen (siehe auch Kapitel 2.2.3).
Die Klassennamen und Funktionen wurden weitgehend übernommen und auch der sonstige Aufbau des
.NET Teils der Plugin API gleicht dem der C++ Plugin API sehr. Sie enthält ebenfalls eine Reihe von
Schnittstellen, die von Plugins implementiert werden können. Daneben enthält sie die Verwaltungsklasse
plugin_loader die wie in C++ für das Laden und Löschen der Plugins, sowie für den Zugriff auf die geladenen
Plugins zuständig ist. Weil es in .NET möglich ist, aus einem Assembly alle vorhandenen Typen
auszulesen, sind für das Erstellen von Pluginbibliotheken (Assemblies) keine „Pluginfabriken“ notwendig.
Dadurch gestaltet sich der Aufbau der Bibliotheken etwas einfacher als in C++. Die Plugins können
ohne zusätzlichen Aufwand direkt in ein Assembly geschrieben werden. Diese Art von Assembly wird
in C# Klassenbibliothek genannt.
4.1 Typenreflektion im .NET Framework
Im .NET Framework wird die Typenreflektion durch das Assembly System.Reflection bewerkstelligt.
Dieses besteht, wie Abbildung 4.1 zeigt, aus verschiedenen APIs. Für die Typenreflektion sind primär
die Info APIs von Bedeutung. Die Info APIs erlauben den Zugriff auf das Typensystem von .NET. Mit
ihrer Hilfe können dynamisch Objekte erstellt, Methoden aufgerufen und Objekteigenschaften verändert
werden, ohne das der Typ beim Kompilieren bekannt ist. Außerdem können jegliche Informationen
über ein Assembly (die sogenannten Metadaten) ausgelesen werden. Diese Metadaten stehen neben dem
Zwischencode in jedem Assembly und enthalten Tabellen zu verwendeten Klassen, Felder usw. Enthält
das Assembly z. B. fünf Klassen, so hat die Klassentabelle in den Metadaten fünf Zeilen. Die Tabellen
können auf weitere Tabellen verweisen und so beispielsweise alle Methoden einer Klasse zeigen.

4. DIE PLUGIN API FÜR .NET 27
Die Info APIs stellen verschiedene Klassen für den Zugriff auf die Metadaten bereit. Die Klassen Assembly
und Module bieten Zugriff auf wiederverwendbare Codesammlungen und ausführbare Assemblies.
Type gibt Informationen über einzelne Typen der CLR preis. Zusätzlich sind die Klassen ConstructorInfo,
MethodInfo, FieldInfo, PropertyInfo, EventInfo und ParameterInfo vorhanden, welche weitere Informationen
über das Typensystem liefern. In den meisten Fällen werden die Info APIs zum Auslesen der
Metadaten von Assemblies und Typen benötigt.
Für Informationen über ein Assembly wird die Assembly Klasse genutzt. Eine Instanz dieser Klasse kann
sowohl aus Informationen bereits geladener Assemblies erstellt werden, als auch beliebige Assemblies
von einem Datenträger oder aus einem Datenstrom laden und deren Metadaten zurückliefern. Für die Plugin
API ist vor allem das Laden von Assemblies von einem Datenträger interessant. Dafür können die
statische Memberfunktionen Load, LoadFrom und LoadFile der Assembly Klasse genutzt werden. Load
benötigt einen aussagekräftigen Namen des zu ladenden Assembly, d. h. das Assembly muss der Anwendung
bekannt sein. Um Assemblies von der Festplatte oder sogar aus einem Netzwerk zu Laden, muss
auf LoadFrom oder LoadFile zurückgegriffen werden. Diese beiden Funktionen unterscheiden sich nur
wenig. Beiden wird ein string übergeben, der den Namen des Assembly und optional den Pfad enthält.
Das so spezifizierte Assembly wird dann geladen und das Assembly Objekt mit den Metadaten gefüllt.
Der Hauptunterschied ist, dass LoadFrom verschiedene Verzeichnisse nach bereits geladenen Assemblies
durchsucht, welche mit dem zu ladenden Assembly übereinstimmen. Wird ein Assembly gefunden,
nutzt LoadFrom dieses, anstatt erneut ein Assembly zu laden. Trotzdem kann es bei beiden Funktionen
vorkommen, dass das gleiche Assembly mehrfach geladen wird, auch wenn dies mit LoadFrom seltener
passiert. Aus diesem Grund wird in der Plugin API auch LoadFrom genutzt. Für die Verwendung von
Assemblies in der Plugin API ist es wichtig zu wissen welche Klassen (Plugins) enthalten sind. Mit der
Methode GetTypes kann dies erreicht werden. Sie liefert ein Array von Type Objekten zurück, welche den
im Assembly enthaltenen Typen entsprechen. Jedes dieser Type Objekte kann auf das Vorhandensein von
Schnittstellen getestet werden. Dies wird auch beim Laden von Plugins durch die Plugin API genutzt.
Hier wird für jedes Type Objekt im Array mit der Funktion GetInterfaces eine Liste der implementierten
Schnittstellen angefordert und mit der Liste der erwünschten Schnittstellen verglichen. Um von bestimmten
Typen des Assembly Instanzen zu bilden, kann die Funktion CreateInstance des Assembly Objekts
genommen werden. Sie erfordert in der einfachsten Überladung nur einen ausagekräftigen Namen des
Typs. Üblicherweise wird die Eigenschaft FullName des Type Objekts zur Namensübergabe verwendet.
Auf diese Art können Plugins in Assemblies verpackt und von der Plugin API geladen werden.

4. DIE PLUGIN API FÜR .NET 28
Abbildung 4.1: Überblick der System.Reflection APIs ([7])
4.2 Schnittstellen in PluginDefs
Das Assembly PluginDefs enthält alle Schnittstellendefinitionen der Plugin API für .NET. Sie dienen,
genau wie in der C++ API, der Kommunikation zwischen Hostanwendung und Plugin. Im Unterschied zu
C++, unterstützt C# das Konzept von Schnittstellen. In C# ist dafür das Schlüsselwort interface vorgesehen.
Schnittstellen werden im Grunde genau wie abstrakte Klassen in C++ deklariert. Zusätzlich dürfen
sie aber auch keine Membervariablen enthalten. Eine C# Schnittstelle besteht also allein aus Deklarationen
von Methoden, Eigenschaften, „Indexers“, die es erlauben auf Elemente der implementierenden
Klasse mittels Index zuzugreifen (z. B. klassen_element[1];) und Ereignissen. Da es in .NET möglich
ist Typen in Listen zusammenzufassen und als Parameter zu übergeben, müssen die Schnittstellen auch
nicht mehr instanzierbar sein. Darüberhinaus erben, aufgrund des wohldefinierten Typensystems von

4. DIE PLUGIN API FÜR .NET 29
.NET, alle Schnittstellen von System.Object und nicht mehr von plugin_interface_class, wodurch auch
die für .NET überflüssige Methode is_implemented_by weg fällt. Quelltext A.9 zeigt beispielhaft an
iplugin_base, wie in C# Schnittstellen deklariert werden. Diesen von der Programmiersprache bedingten
Unterschieden folgend wurden die Schnittstellen aus dem C++ Teil der API angepasst, so dass alle
Schnittstellen der C++ API, auch im .NET Teil zu finden sind. Es soll im Folgenden nur auf einige der
Schnittstellen eingegangen werden, weil sich die meisten nur wenig von ihrer C++ Variante unterscheiden.
4.2.1 Die Standardschnittstelle iplugin_base
Die Schnittstelle iplugin_base spielt in der Plugin API für C++ eine besondere Rolle. Sie wird von
allen Plugins genutzt und dient so als Basis für jeglichen Umgang mit einem Plugin. In .NET ist dies
nicht mehr der Fall. Durch das wohldefinierten Typensystem von .NET bedingt, erben alle Plugins von
System.Object. Für eine Liste von Plugins, ist iplugin_base deshalb nicht mehr notwendig. Außerdem
verliert die Methode create_new_instance in .NET an Bedeutung, da hier die Plugins direkt aus den
Pluginklassen erstellt werden. Somit enthält iplugin_base nur noch eine Methode um den Namen des
Plugins zu ermitteln. Da die Schnittstelle in .NET sehr verkleinert wurde und an Wichtigkeit verloren
hat, muss sie auch nicht mehr von einem Plugin implementiert werden. Sie wurde aber trotzdem in die
Plugin API für .NET übernommen, weil es in vielen Fällen nützlich ist, einem Plugin einen Namen
zuweisen zu können, um es dadurch leichter zu identifizieren.
4.2.2 Iplugin_event_callback
Die Bezeichnung dieser Schnittstelle ist eigentlich nicht ganz korrekt. In .NET werden Rückruffunktionen
als „delegates“ bezeichnet. Da sie aber in ihrer Wirkungsweise den aus C++ bekannten „callback“
Funktionen gleichen und damit die .NET und die C++ Version der Plugin API möglichst einheitlich gestaltet
sind, wurde der Name der C++ Schnittstelle übernommen. Da die Schnittstellen der .NET Plugin
API keine Implementationen besitzen, enthält iplugin_event_callback lediglich eine Deklaration der Eigenschaft
set_event_callback. Diese Eigenschaft kann nur beschrieben aber nicht gelesen werden, d. h.
sie bestitzt nur eine set Methode. Sie ist vom Typ plugin_event_delegate und soll in ihrer Implementation
im Plugin, ein privaten „delegate“ (Funktionszeiger) auf eine von der Hostanwendung bestimmte Funktion
setzten. Das Plugin kann dann den Verweis auf die Funktion nutzen, um diese auszuführen. Eine
so zugeordnete Funktion muss einen Parameter vom Aufzählungstyp enum_plugin_event haben. Dieser
Typ beschreibt die Art des Ereignisses, welches das Plugin melden möchte.

4. DIE PLUGIN API FÜR .NET 30
4.3 PluginLoader.NET
Wie in C++, steht dem Entwickler einer Hostanwendung auch unter .NET die Verwaltungsklasse plugin_loader
zu Verfügung. Sie ist im Assembly „PluginLoader“ definiert und enthält die gleichen Funktionen
wie die Version der C++ Plugin API. Neue Plugin Assemblies können mit der überladenen Methode
load geladen werden, wobei diese den Dateinamen des Assembly und optional eine Liste von Schnittstellen
benötigt. Wird eine Liste übergeben, werden nur solche Plugins geladen, die alle Schnittstellen
der Liste implementieren. Ist die Liste leer oder wird sie nicht übergeben, lädt die Verwaltungsklasse alle
in der Bibliothek enthaltenen Plugins. Geladen wird ein Plugin durch die vom .NET Framework bereitgestellten
Klasse System.Reflection.Assembly. Die Verwaltungsklasse plugin_loader nutzt eine Instanz
dieser Klasse, um mit Hilfe deren Memberfunktion LoadFrom das Assembly zu laden, welches durch
den der Methode übergebenen Dateinamen spezifiziert wird. Eine weitere für das Laden von Plugins
wichtige Funktion ist GetTypes. Sie ist ebenfalls Bestandteil der Assemblyklasse und liefert alle in einem
Assembly enthaltenen Typen zurück. Ein plugin_loader Objekt nutzt die so erhaltenen Typen, um
mit Hilfe Funktion CreateInstance des Assemblyobjektes, Instanzen von ihnen zu erstellen. Abbildung
A.10 zeigt die load Funktion der plugin_loader Klasse.
Der Zugriff auf die Plugins erfolgt analog zu C++, mit den Methoden get_plugin und get_interface.
Auch in .NET ist es möglich, einmal geladene Plugins, vor dem Programmende durch die Methode delete_plugin
wieder zu entfernen. Im Unterschied zu C++, wird hier aber das Assembly nicht entladen,
wenn kein in ihr enthaltenes Plugin mehr genutzt wird. Ein einmal dynamisch hinzugefügtes Assembly
bleibt also bis zum Programmende der Hostanwendung geladen. Die Klasse plugin_loader nutzt eine
Liste von Objekten zum speichern von Plugininstanzen. Diese ist wie in C++ vom Typ plugin_list, führt
aber bisher keine eigenen Methoden ein.

5. BEISPIELANWENDUNGEN 31
5 Beispielanwendungen
Neben der eigentlichen Plugin API, wurden im Rahmen dieses Belegs einige Beispielanwendungen erstellt.
Diese sollen Einblicke in die Nutzung der API bringen und werden im Folgenden etwas genauer
erklärt.
5.1 DirectX Beispiel für C++
Dieses Beispiel besteht aus einer Hostanwendung (SampleHost.exe) und zwei DLLs ( MeshDll.dll und
InteractiveRoom.dll). Es nutzt die in der Direct X SDK (Software Development Kit) enthaltenen DXUT
Hilfsklassen [11].
Abbildung 5.1: Screenshot aus der DirectX Beispielanwendung

5. BEISPIELANWENDUNGEN 32
5.1.1 Die Hostanwendung
Die Hostanwendung wird in der für DXUT typischen Weise initialisiert. Als Erstes werden den Ereignissen
DeviceCreated, DeviceReset, DeviceLost, DeviceDestroyed, FrameRender und FrameMove
Funktionen zur Behandlung des Ereignisses zugewiesen. Außerdem wird die Funktion zur Nachrichtenbehandlung
der Anwendung festgelegt. Das Hauptfenster, die notwendigen DirectX Objekte werden
durch DXUTInit, DXUTCreateWindow und DXUTCreateDevice erstellt. Danach wird die Hauptschleife
in der Funktion DXUTMainLoop betreten. Neben dem plugin_loader Objekt werden eine Kamera (CModelViewerCamera)
und ein Objekt für die grafische Benutzeroberfläche (SampleHostGUIClass) global
definiert. Im Konstruktor der SampleHostGUIClass wird die Benutzeroberfläche erstellt. Zur Interaktion
hält sie Knöpfe zum Laden und Entladen der Plugins bereit. In einer Liste werden alle geladenen Plugins
angezeigt. Dafür wird der in der Schnittstelle iplugin_base definierte Name des Plugins genutzt. Um von
der Hostanwendung geladen werden zu können, müssen die Plugins die Schnittstellen irenderable und
id3d9_plugin implementieren. Ist ein Plugin in der Liste ausgewählt, dann wird dessen Memberfunktion
render von der Hostanwendung aufgerufen. Im Falle eines Plugins dass ikeyboard_event_handler
implementiert, werden zusätzlich die Tastendrücke der „Hoch“-Taste und „Runter“-Taste an das Plugin
übergeben. Dies wird vom „interaktives Auto“ Plugin in der Bibliothek InteractiveRoom.dll genutzt. Die
Hostanwendung verwendet ein CModelViewerCamera Objekt, um eine vom Benutzer gesteuerte Kamera
zu erzeugen. Der Nutzer der Anwendung kann so mit Hilfe der Maus die Position der Kamera verändern.
Mit gedrückter Maustaste wird bei jeder Mausbewegung die Kamera Rotiert. Über das Mausrad kann ein
Zoom ausgelöst werden.
5.1.2 Die Dll MeshDll
Die Pluginbibliothek MeshDll enthält drei Plugins. Alle drei Plugins implementieren die Schnittstellen
iplugin_base, irenderable und id3d9_plugin. Für jedes ist eine Fabrikklasse vohanden, von der das Plugin
erbt. Da die Schnittstelle iplugin_base abstrakt ist, wird sie bereits in der Fabrik implementiert. Die Plugins
nutzen den von der Hostanwendung erzeugten LPDIRECT3DDEVICE9 Zeiger um in der Funktion
render Objekte grafisch auszugeben. Das Plugin TubeMeshPlugin zeichnet mit Hilfe eines Vertexbuffers
eine Röhre. Das Plugin TeapotMeshPlugin lädt ein Teekannen-Objekt aus einer Datei und stellt es rotierend
da. Beim Plugin TigerMeshPlugin wird ebenfalls ein Objekt aus einer Datei geladen und rotierend
dargestellt. Der so gerenderte Tiger wird aber zusätzlich noch mit einer Textur versehen.
Die DLL enthält weiterhin das zum Laden der Plugins notwendige plugin_factory_list_class Objekt.
Diesem werden in DllMain Mittels register_factory die Plugins bekannt gemacht.

5. BEISPIELANWENDUNGEN 33
5.1.3 Die DLL InteractiveRoom
In der DLL InteractiveRoom ist ein Plugin enthalten. Dieses soll die Funktion der Schnittstelle ikeyboard_event_handler
verdeutlichen. Es zeichnet ein Auto auf das gegebene IDIRECT3DDEVICE9 Objekt,
welches sich je nach Tastendruck vorwärts oder rückwärts im Kreis bewegt. Genau wie bei der
Pluginbibliothek MeshDll, ist auch hier für jedes Plugin eine Fabrik vorhanden, mit welcher das Plugin
erzeugt werden kann. Das Plugin IACarPlugin nutzt sowohl ikeyboard_event_handler, als auch die für
die Hostanwendung nötigen irenderable und id3d9_plugin . Die Schnittstelle iplugin_base wird, wie bei
jedem Plugin, natürlich auch implementiert.
5.2 OpenGL Beispiel für C++
Dieses Beispiel besteht aus einer Hostanwendung (OGLHost.exe) und einer DLL ( OGLDll.dll). Zum
erstellen wurde die Grafikbibliothek OpenGL und die Zusatzbibliothek GLUT verwendet.
Abbildung 5.2: Screenshot aus der OpenGL Beispielanwendung

5. BEISPIELANWENDUNGEN 34
5.2.1 OpenGLHost
Die Hostanwendung OpenGLHost nutzt die Zusatzbibliothek GLUT für das Erstellen des Hauptfensters
und zum behandeln einiger Ereignisse. Dafür werden mit glutInit und glutInitDisplayMode die
für OpenGL notwendigen Objekte erzeugt und Einstellungen gesetzt. Die Funktionen glutInitWindow-
Position und glutInitWindowSize setzten die Eigenschaften des Hauptfensters, welches dann mit glut-
CreateWindow erzeugt wird. Damit Ereignisse, die von einem mit GLUT erstellten Fenster aufgefangen
werden, die Hostanwendung erreichen, muss sie Funktionen festlegen, die sich um die Behandlung der
Ereignisse kümmern. Diese Funktionen werden bei GLUT mittels je nach Art des Ereignisses verschiedenen
Methoden registriert. Soll die Hostanwendung z. B. auf eine Größenänderung des Hauptfensters
reagieren, wird ein dafür bestimmte Funktion an glutReshapeFunc übergeben. Sie muss als Parameter
zwei int Werte besitzen, die von GLUT beim Eintreten des Ereignisses und vor dem Aufruf der gewählten
Funktion auf die neue Höhe und Breite des Fenster gesetzt werden. Die Beispielanwendung benutzt
solche „Ereignishandler“, d. h. Funktionen die in GLUT registriert und dann beim Auftreten des Ereignisses
aufgerufen werden, für Tastatureingaben, Veränderungen der Fenstergröße und Sichtbarkeit und
für die Darstellung des Fensters, wenn es z. B. zuvor verdeckt war. Daneben wird noch eine Funktion
definiert, welche immer dann aufgerufen werden soll, wenn die Anwendung nicht „beschäftigt“ ist, sie
also keine Nachrichten bearbeiten muss. Diese Funktion wird durch glutIdleFunc festgelegt und kann
u. a. für die Animation von Fensterinhalten genutzt werden, da sie von GLUT so häufig wie möglich
aufgerufen wird und so flüssiges Darstellen von Bildabfolgen ermöglicht. Nachdem alle Einstellungen
gesetzt wurden, wird die Hauptschleife des Programms durch glutMainLoop betreten.
Im Gegensatz zum DirectX Beispiel wird in OpenGLHost die Pluginbibliothek automatisch geladen.
Dies geschieht aber dennoch dynamisch durch ein globales plugin_loader Objekt. Der Nutzer kann in
der laufenden Anwendung zwischen Vollbild und Fenstermodus wechseln. Durch „+“ und „-“ kann er
aus den geladenen Plugins das Nächste bzw. Vorherige auswählen, und darstellen lassen. Neben diesen
Tastaturereignissen gibt die Hostanwendung auch einen Tastendruck auf die Cursortasten an das gerade
ausgewählte Plugin weiter.
5.2.2 Die Pluginbibliothek OGLDLL
Die Pluginbibliothek für OpenGL enthält zwei Plugins. Beide sind aus Beispielanwendungen gewonnen
worden, welche der Demonstration der Möglichkeiten von OpenGL dienen und von der Website
„Codesampler.com“ [6] stammen. Von den eigenständigen Programme mit den Titeln „Dot3 Per-Pixel
Bump Mapping“ und „Point Sprites“ wurden dafür die Funktionen zur Erstellung des Hauptfensters
und zur Behandlung von Nachrichten entfernt. Die Variablen und Funktionsnamen wurden angepasst,

5. BEISPIELANWENDUNGEN 35
und es wurden die von den Pluginschnittstellen vorgegebenen Funktionen hinzugefügt. Die unterstützten
Schnittstellen sind irenderable und ikeyboard_event_handler. Eine für die genutzte Grafikbibliothek
spezifische Schnittstelle ist, im Gegensatz zu DirectX, bei OpenGL nicht notwendig, da hier für die
Ausgabe von grafischen Inhalten nur Funktionen verwendet werden. Es muss so kein globales OpenGL
Objekt an die Plugins übergeben werden. Es ist dabei aber zu beachten, dass die Initialisierung der für die
Darstellung der Szene notwendigen Einstellungen von OpenGL (z. B. Licht) bereits im Konstruktor des
jeweiligen Plugins erfolgt. Die Hostanwendung muss dementsprechend schon beim Laden des Plugins
für OpenGL eingerichtet sein.
Bei beiden Plugins ist es möglich, die Szene zu rotieren. Dies geschieht im Plugin und nicht wie beim
Beispiel für DirectX durch eine Kamera in der Hostanwendung. Damit der Benutzer die Rotation steuern
kann, werden den Plugins über die Schnittstelle ikeyboard_event_handler jeder Tastendruck auf eine der
Cursortasten mitgeteilt. Das Plugin ändert dann je nach Tastendruck die Darstellung der Szene. Durch
irenderable wird die Funktion render eingeführt, welche die Szene des jeweiligen Plugins auf das Fenster
der Hostanwendung zeichnet.
5.3 Beispiel für .NET
Da die Plugin API neben C++ auch für .NET Anwendungen gedacht ist, soll dieses Beispiel den Umgang
mit der API in .NET zeigen. Es beinhaltet eine Hostanwendung (HostAnwendung.exe) und eine DLL (
PluginDLL.dll). Das Beispiel wurde in C# erstellt und ist nur für die Nutzung unter Windows gedacht.
5.3.1 Hostanwendung
Die zu diesem Beispiel gehörende .NET Hostanwendung ist eine einfache C# „Windows-Anwendung“.
Das von Visual Studio automatisch generierte Formular wurden nach den Bedürfnissen angepasst und ein
privater Member vom Typ plugin_loader hinzugefügt. Im Konstruktor des Formulars wird das Assembly
„PluginDLL.dll“ dynamisch geladen, und diejenigen Plugins erstellt, welche sowohl irenderable als
auch die Schnittstellen iplugin_event_callback und imouse_event_handler implementieren. Nach dem
Laden werden die Funktionen zum Weiterleiten von Mausklicken (einfacher und doppelter Mausklick)
und Mausbewegungen an ein Panel gebunden, so dass es alle diese Mausereignisse an die entsprechende
Methode der Plugins weiterleitet. Den Plugins werden wiederum eine eigene Funktion über die Eigenschaft
set_event_callback zugeteilt, welche vom Plugin aufgerufen werden soll, wenn ein Pluginereignis
auftritt.
Der Nutzer der Hostanwendung kann mit der Maus auf jeden Punkt des Panel klicken und muss versu-

5. BEISPIELANWENDUNGEN 36
chen einen vom Plugin festgelegten Bereich zu treffen. Gelingt ihm dies, wird vom Plugin ein Erfolg
gemeldet und die Hostanwendung gibt die Erfolgsmeldung über eine „Messagebox“ an den Nutzer weiter.
Mit dem Knopf „Show Results“ werden alle geladenen Plugins aufgefordert zu Zeichen, d. h. es wird
die Methode render der Schnittstelle irenderable aufgerufen.
5.3.2 Das Assembly PluginDLL
Die Pluginbibliothek PluginDLL ist eine C# Klassenbibliothek. Sie enthält ein Plugin mit dem Namen
mouse_click_tracker_plugin, welches neben den unterstützen Pluginschnittstellen auch von der Klasse
Form erbt. Das Plugin ist also ein Formular, welches außer einem Panel keine weiteren Steuerelemente
enthält. Das Plugin implementiert die Schnittstellen iplugin_base, irenderable, imouse_event_handler
und iplugin_event_callback. Beim Erstellen legt es einen rechteckigen Bereich fest, und prüft bei jedem
Mausklick und jeder Mausbewegung mit gedrückter Maustaste, welche über die Schnittstelle imouse_event_handler
von der Hostanwendung an das Plugin weitergeleitet und vom Plugin in einer Liste
gespeichert wurden, ob die Koordinaten des Mauszeigers in diesem Bereich liegen. Ist dies der Fall, sendet
es der Hostanwendung einen Erfolg (PE_SUCCESS) über die privaten Methode priv_event. Dieser
Methode wird durch die Eigenschaft set_event_callback eine Funktion der Hostanwendung zugeordnet.
Die Funktion render des Plugins, zeigt das Formular dem Benutzer an. Bei der Darstellung des Formulars
werden die bei Mausereignissen gespeicherten Koordinaten durch einen Punkt repräsentiert. Auch
der festgelegte Zielbereich wird mit dargestellt.
Das Plugin zeigt neben der Verwendung der Plugin API unter .NET auch wie eine einfache Kommunikation
zwischen Hostanwendung und Plugin ablaufen kann.

6. ZUSAMMENFASSUNG 37
6 Zusammenfassung
Das Ziel dieses Belegs war die Entwicklung einer plattformunabhängigen Plugin API. Sie sollte das
Schreiben und Laden von Plugins sowohl unter Windows als auch unter Linux vereinfachen. Dies wird
durch die hier vorgestellten Klassen ermöglicht. Es wurde darauf geachtet, diese API sehr flexibel und
erweiterbar zu gestalten. In der API sind die wichtigsten Schnittstellendefinitionen enthalten, es können
aber jederzeit Schnittstellen beliebiger Art hinzugefügt werden. Da die Plugins in dynamische Bibliotheken
geschrieben werden, ist eine Ausführung im Prozess der Hostanwendung gewährleistet und es entfällt
jegliche Interprozesskommunikation, also eine Kommunikation zwischen zwei unterschiedlichen
Prozessen. Um Plugins schnell und einfach in einer Anwendung nutzen zu können muss lediglich die
plugin_loader Klasse eingebunden werden. Dadurch wird das dynamische Laden von Plugins ermöglicht.
Dabei gibt es seitens der API so gut wie keine Einschränkung bezüglich der Art der Plugins. Es
sind Plugins die vorhandene Objekte (Meshs) ändern genauso denkbar, wie komplette Applikationen,
die lediglich die Interaktion mit dem Benutzer der Hostanwendung überlassen.

Literaturverzeichnis 38
Literaturverzeichnis
[1] Adobe Photoshop.
http://www.adobe.com/de/products/photoshop/
[2] ALLEN JONES, Rakesh R.: Die C++ Programmiersprache. Apress, 2006
[3] AUPPERLE, Martin: Die Kunst der Programmierung mit C++. Bd. 2. Vieweg, 2002
[4] AUTODESK. 3d Studio MAX.
http://www.autodesk.de/3dsmax
[5] Centaurix Interactive Designs.
http://www.centaurix.com/pssdk.html
[6] CodeSampler.com.
http://www.codesampler.com/oglsrc.htm
[7] DUFFY, Joe: Professional .NET Framework 2.0. Wiley Publishing, Inc., 2006
[8] JACK DRAFAHL, Sue D.: Plug-Ins for Adobe Photoshop: A Guide for Photographers. Amherst
Media, Inc., 2004
[9] JASMIN BLANCHETTE, Mark S.: C++ GUI Programming with Qt 4. Prentice Hall, 2006
[10] LLOPIS, Noel: C++ for Game Programmers. Charles River Media, 2003
[11] MICROSOFT. DXUT Programming Guide.
http://msdn2.microsoft.com/en-us/library/bb173316.aspx
[12] MICROSOFT. MSDN.
http://msdn.microsoft.com
[13] MICROSOFT. .NET Framework.
http://www.microsoft.com/germany/msdn/netframework
[14] Mono.
http://www.mono-project.com
[15] MOZILLA-EUROPE. Firefox.
http://www.mozilla-europe.org/de/products/firefox

Literaturverzeichnis 39
[16] Microsoft Component Object Model.
http://www.microsoft.com/com/default.mspx
[17] MULLIN, Eileen: Inside the Adobe Photoshop 6 Studio. Thomson Course Technology, 2000
[18] SIVA CHALLA, Artur L.: Essential Guide to Managed Extensions for C++. apress, 2002
[19] SMITH, Colin: How to Do Everything with Photoshop CS. McGraw-Hill Professional, 2003
[20] STROUSTRUP, Bjarne: Die C++ Programmiersprache. Bd. 4. Addison Wesley, 2000
[21] WACHTLER, Klaus. Dynamische Bibliotheken unter Windows und Linux.
http://www.wachtler.de/dynamischeBibliotheken/

Abbildungsverzeichnis 40
Abbildungsverzeichnis
2.1 CTS Typenhierarchie ([7]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Statisches Binden einer statischen Bibliothek . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Festes Binden einer dynamischen Bibliothek . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1 Speicherlayout eines Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1 Überblick der System.Reflection APIs ([7]) . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1 Screenshot aus der DirectX Beispielanwendung . . . . . . . . . . . . . . . . . . . . . . 31
5.2 Screenshot aus der OpenGL Beispielanwendung . . . . . . . . . . . . . . . . . . . . . . 33
A.1 Verwendung dynamic_cast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
A.2 Header für plugin_interface_class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
A.3 Header für iplugin_base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
A.4 Header für IPluginEventCallback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
A.5 Header für Verwaltungsklasse plugin_loader . . . . . . . . . . . . . . . . . . . . . . . . 43
A.6 Header für PluginList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.7 Beispiele für Zugriff auf Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.8 Header für plugin_factory_list_class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.9 Beispiel einer Schnittstelle in .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.10 load Funktion der plugin_loader Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . 45

ANHANG A. QUELLTEXTE 41
A Quelltexte
class CBase1 { ... }; //virtuelle Klasse CBase1
class CBase2 { ... }; //virtuelle Klasse CBase2
class CDerived: public CBase1, public CBase2 { ... }; //virtuelle Klasse CDerived
//pCBase1 zeigt auf Teilklasse CBase1 in CDerived Objekt
CBase1* pCBase1 = new CDerived();
CDerived* pCDerived = new CDerived();
//Umwandlung mit dynamic\_cast in Basisklasse CBase1
CBase1* pCBase11 = dynamic\_cast(pCDerived);
//Wenn pCBase11 == NULL dann schlug die Umwandlung fehl,
//sonst zeigt pCBase11 auf Teilklasse CBase1 in CDerived Objekt
//Umwandlung mit dynamic\_cast in andere Teilklasse CBase2
CBase2* pCBase2 = dynamic\_cast(pCBase1);
//Wenn pCBase2 == NULL dann schlug die Umwandlung fehl,
//sonst zeigt pCBase2 auf Teilklasse CBase2 in CDerived Objekt
Abbildung A.1: Verwendung dynamic_cast
class plugin_interface_class
{
public:
virtual ~plugin_interface_class();
};
virtual bool is_implemented_by(piplugin_base pplugin_class ) = 0;
Abbildung A.2: Header für plugin_interface_class

ANHANG A. QUELLTEXTE 42
class iplugin_base: public plugin_interface_class
{
public:
virtual ~iplugin_base();
virtual std::string get_plugin_name() = 0;
virtual piplugin_base create_new_instance() = 0;
};
virtual bool is_implemented_by(piplugin_base pplugin_class );
Abbildung A.3: Header für iplugin_base
class iplugin_event_callback: public plugin_interface_class
{
public:
virtual ~iplugin_event_callback();
void set_event_callback(cplugin_event_callback);
virtual bool is_implemented_by(piplugin_base pplugin_class );
private:
cplugin_event_callback cfpdo_event;
void do_event(enum_plugin_event);
};
Abbildung A.4: Header für IPluginEventCallback

ANHANG A. QUELLTEXTE 43
class plugin_loader
{
public:
plugin_list m_plugin_list;
plugin_loader(void);
~plugin_loader(void);
void load(xp_dll_filename plugin_filename);
void load(xp_dll_filename plugin_filename,
const plugin_interface_list& a_interface_list);
int get_plugin_count();
piplugin_base get_plugin(unsigned int index);
template interface_typ* get_interface(unsigned int index)
{
return dynamic_cast(get_plugin(index));
}
};
void delete_plugin(int plugin_index)
{
m_plugin_list.delete_item( plugin_index);
};
Abbildung A.5: Header für Verwaltungsklasse plugin_loader

ANHANG A. QUELLTEXTE 44
struct plugin_list_item
{
xp_dll_handle dll_handle;
piplugin_base pplugin;
};
class plugin_list
{
private:
std::vector m_plugin_list_items;
public:
plugin_list();
~plugin_list();
void add_item(plugin_list_item a_plugin_list_item);
void delete_item(int index);
};
unsigned int plugin_count();
piplugin_base get_plugin(unsigned int index);
Abbildung A.6: Header für PluginList
//Zugriff "uber GetPlugin
piplugin_base pInterface = plugin_loader_Intstanz.get_plugin(1);
irenderable* pRenderInterface1 = dynamic\_cast(pInterface);
if (pRenderInterface1 != NULL)
{
//benutze Interface
}
//Zugriff "uber GetInterface
irenderable* pRenderInterface2 = plugin_loader_Intstanz.get_interface(1);
if (pRenderInterface2 != NULL)
{
//benutze Interface
}
Abbildung A.7: Beispiele für Zugriff auf Plugins

ANHANG A. QUELLTEXTE 45
class plugin_factory_list_class
{
public:
iplugin_pointer_list m_class_factory_list;
plugin_factory_list_class() {}
virtual ~plugin_factory_list_class();
piplugin_base create_plugin(unsigned int iindex);
void create_all_plugins(iplugin_pointer_list& a_created_plugin_list,
const plugin_interface_list& needed_interfaces);
};
template void register_factory()
{
m_class_factory_list.push_back(new class_factory);
}
Abbildung A.8: Header für plugin_factory_list_class
public interface iplugin_base
{
string get_plugin_name { get; }
}
Abbildung A.9: Beispiel einer Schnittstelle in .NET
public void load(string a_filename, Type[] a_needed_interfaces_list)
{
Assembly a = Assembly.LoadFrom(a_filename);
Type[] enum_types = a.GetTypes();
foreach (Type current_type in enum_types)
{
Type[] implemented_interfaces = current_type.GetInterfaces();
}
if (m_test_for_needed_interfaces(implemented_interfaces, a_needed_interfaces_list))
m_loaded_plugins.Add(a.CreateInstance(current_type.FullName));
}
Abbildung A.10: load Funktion der plugin_loader Klasse

ANHANG B. VERZEICHNISSE AUF DER CD ZUM BELEG 46
B Verzeichnisse auf der CD zum Beleg