Beleg: API für Plugin und Treiberbasierte Softwareentwicklung

Transkript

1 Fakultät Informatik Institut für Software- und Multimediatechnik, Professur Computergraphik Beleg: API für Plugin und Treiberbasierte Dresden, 23. Mai 2007

2 Übersicht Grundlagen zum Plugin-Konzept Dynamische Bibliotheken Die Native C++ Plugin API Schnittstellen Plugins laden Plugins schreiben Plugins verwenden Umsetzung auf die.net Umgebung Ausblick 2

3 Grundlagen zum Plugin-Konzept Schnittstellen: global definiert von Plugin und Anwendung unabhängig 3

4 Grundlagen zum Plugin-Konzept Hostanwendung: stellt Grundfunktionalität bereit lädt Plugins zur Laufzeit Beschränkung auf bestimmte Plugintypen (bei Kompilierung) 4

5 Grundlagen zum Plugin-Konzept Plugins: Funktionen zur Erweiterung der Hostanwendung Schnittstellen für Interaktion mit Hostanwendung in dynamische Bibliotheken verpackt 5

6 Dynamische Bibliotheken Bibliothek nur einmal im Speicher statische Daten eingeblendet Kopien veränderlicher Daten im Prozessspeicher (Heap/Stack) angelegt keinen Zugriff auf Code der Bibliothek kein IPC mit Variablen der Bibliothek 6

7 Dynamische Bibliotheken dynamisches Linken: Bibliothek durch Systemfunktionen an Programm gebunden Laden der Bibliothek Suchen nach Funktionsadressen Freigeben der Bibliothek 7

8 Dynamische Bibliotheken (Win32) DLL sind dynamische Bibliotheken in Win32 Betriebssytemen Win32 Funktionen: LoadLibrary() lädt eine DLL GetProcAddress() gibt Zeiger mit Funktionsadresse zurück FreeLibrary() entlädt DLL laden/entladen in DllMain() der Bibliothek signalisiert 8

9 Dynamische Bibliotheken (Linux) shared objects (*.so) sind dynamische Bibliotheken in Linux Linux Funktionen: dlopen() lädt ein shared object dlsym() gibt Zeiger mit Funktionsadresse zurück dlclose() entlädt ein shared object laden in _init() der Bibliothek signalisiert entladen in _fini() der Bibliothek signalisiert 9

10 Die Native C++ Plugin API drei Teile: 10

11 Die Native C++ Plugin API in C++ geschrieben (Standardbibliothek) Verwendung statischer Bibliotheken API nur zum Kompilieren nötig mit VS2005 und GNU C++ kompilierbar (Windows/Linux) plattformabhängige Teile in CrossPlattform.h und CrossPlattform.cpp 11

12 Die Native C++ Plugin API 12

13 Schnittstellen 13

14 Plugins laden plugin_loader in Hostanwendung einbinden verwaltet Plugins selbständig (inkl. Aufruf der Destruktoren) Systemfunktionen zum Laden/Entfernen von Bibliotheken im Objekt gekapselt zum Laden können notwendige Schnittstellen fesgelegt werden Zugriff auf Plugins über Index möglich 14

15 Plugins schreiben Plugins in dynamischen Bibliotheken globale Fabrikliste (plugin_factory_list_class) Liste im Einsprungpunkt der Bibliothek (DllMain/_init) mit Fabriken gefüllt zu jedem Plugin eine Fabrik Plugin erbt von Fabrik gleiche Schnittstellen Fabrik kann Plugin erstellen (create_new_instance() von iplugin_base) C -Funktion get_plugin_factory_list() 15

16 Plugins verwenden Plugins werden über deren Schnittstellen angesprochen standard: iplugin_base Konvertierung über dynamic_cast (Typreflektion mit vtbl) 16

17 Umsetzung auf die.net Umgebung Anwendungsfälle: Hostanwendung C++ C++.NET.NET Plugin C++.NET C++.NET mindestens zwei Lade-Klassen (.NET und C++ plugin_loader) Idee: um jeweilige Interop-Funktion erweitern mindestens zwei Schnittstellendefinition (.NET und C++).NET-.NET Anwendungsfall einfach und effizient lösbar (Reflection von Assemblies) 17

18 Umsetzung auf die.net Umgebung - Probleme C++ Hostanwendung und.net Plugins: Interoperabilität mit managed Code Hostanwendung in C++ mit Managed Extensions (C++/CLI) Probleme: eigene Kommunikationswege zwischen native und managed Code (Wrapperklassen usw.) eigene Version der Lade-Klasse (sonst immer C++/CLI notwendig) 18

19 Umsetzung auf die.net Umgebung - Probleme.NET Hostanwendung und C++ Plugins Interoperabilität mit native Code gute Zusammenarbeit mit COM (COM Interop Assembly) Platform Invoke für Code ohne COM (P/Invoke) Probleme: Marshaling von C++ Objekten nicht möglich (nur Datenstrukturen) Wrapperklassen innerhalb der Plugins (C++/CLI) 19

20 Umsetzung auf die.net Umgebung - Ergebnis zwei getrennte Plugin API-Versionen gleiche vordefinierte Schnittstellen jeweils eine plugin_loader Klasse Hostanwendungen kümmern sich um Interoperabilität (nicht die Lade-Klassen) Hostanwendung kennt Plugintypen (einfaches Marshaling / Wrappen) integrieren beider plugin_loader ermöglicht flexibles Laden von.net und C++ Plugins 20

21 Ausblick erweitern der Schnittstellen Sound Datenkanäle seq. Datenströme (z. B. für Video En-/Dekodierung) usw. eventuell Versionssystem für Plugins (bzw. deren Schnittstellen) integrieren Mechanismus zum Erkennen von Plugin-Bibliotheken (ohne Bibliothek zu laden) 21

22 Ausblick plugin_loader an Bedürfnisse anpassen komfortable Lade-Funktionen (verschiedene Ladebedingungen) angabe eines Plugin-Verzeichnisses (autom. Laden aller Plugins) usw. Verbesserung der Registrierung der Fabriken (automatisieren) 22