Objekte (Klassen) mit DLLs zu Teilen ist so nicht möglich, da jeder seine eigene
RTTI hat.
Also die Klassen/Typen sind nicht direkt Kompatibel, selbst wenn sie gleich definiert sind.
Und dann hat standardmäßig auch noch jeder seine eigene Speicherverwaltung, welche ebenfalls nicht miteinander arbeitet,
http://www.delphipraxis.net/internal...t.php?t=166651
http://www.delphipraxis.net/internal...t.php?t=162452
http://www.delphipraxis.net/internal...t.php?t=161358
Wo das alles gehn würde, das wären BPLs.
Ansonsten: statt Klassen verwendet man hier Interfaces
allerdings bleibt hier immernoch ein kleines Problem mit deinem Speicher.
Aber da könntest du dir den Stream ebenfalls als Interface erstellen,
welchem dann beim Auslesen ein Speicherblock vom jeweiligen Modul (
DLL/EXE), bzw. von dessen Speicherverwaltung gegeben wird, wo er die Daten reinkopiert, welches bei vielen Streams allerdings eh oftmals schon so gemacht wird.
Man könnte (wenn es unbedingt nötig ist) den Stream so erstellen, daß er sich Speicher direkt von Windows (VirtualAlloc, MMF und Co.) besorgt und diesen Speicher kann man dann auch ganz leicht üerall in der ganzen Anwendung verwenden und komplett weiterreichen.
Und zu 2.
Ja, das mit den Callbackprozeduren kannst du hier auch ganz einfach lösen ... das geht genauso, wie sonst auch.
Entweder als normale Prozedur und hier dürfte sogar Methoden möglich sein, so wie du es von der
VCL (z.B. Button.OnClick) kennst.
Aber in Bezug darauf, daß man hier DLLs auch mit anderen Sprachenn (nicht immer nur Delphi) erstellen kann,
wäre es praktisch, wenn du Interfaces und als Callback einfach Prozeduren via StdCall verwendest.
Oder du gibst beim Start der
DLL, bzw. beim Erstellen (Createn) des PlugIns selber wiederum ein Callback-Interface an.
Dieses Callback-Interface kapselt dann einfach alle Befehle, welche das Plugin in der Hauptanwendung aufrufen kann.