Ich empfehle dieses Beispiel eines hacks nicht in Produktivcode zu benutzen.
Das was man mit dieser DEMO zeigen möchte ist einfach nicht auf diese Weise machbar. Die einzigsten Lösungen sind
1.)
COM Interfaces benutzen
2.) Packages benutzen
punkt.
Zb. dieser Source hier
Delphi-Quellcode:
pInfo:=AObject.ClassInfo;
//if we can not get any valid information exit
if (pInfo = nil) or (pInfo^.Kind <> tkClass) then
exit;
//get information about the type of the class
pType := GetTypeData(pInfo);
Falls AObject aus dem Modul A stammt und der Code im Modul B ausgeführt wird ist dieser Code einfach UNZULÄSSIG !
Mit AObject.ClassInfo wird eine Klassenmethode im Modul B aufgerufen die im Modul A steht. Sie gibt einen Zeiger zurück auf das Codesegment des Modules A. Soweit noch ok.
Nun greift man aber mit pInfo^.Kind schon aus dem Modul A in das Codesegment des Modules B zu. Dieser Zugriff ist zwar unter heutigen Windows Betriebssystemen in dem eigenen Prozess auf selber geladene Module noch fast zulässig aber im Grund eigentlich verboten ! Wäre zb. die Klasse in einer
DLL wie Kernel32.dll implementiert ist es sicher das mit solchen Zugriffen eine
AV auftreten wird.
Denn es ist durchaus möglich das Codesegment eines Modules vor dem Lesen durch andere Module zu schützen.
Es geht aber noch weiter mit GetTypData(pInfo); wird nun ein Code in Modul A versuchen eine Datenstruktur im Modul B auszuwerten. Dies wird aber nur funktionieren wenn Modul A und Modul B mit identischen Sourcen compiliert wurden.
Wäre zb. Modul A mit Delphi 3 kompiliert und Modul B mit Delphi 5 so ergäbe sich eine andere
RTTI/Klassenstruktur in den Codesegementen. Die Funktion GetTypData() aus Modul B würde also im Codesegement des Modules A deren Klassenstrukturen und RTTIs absolut falsch auswerten. Also auch hier wieder AVs.
Es sind also gravierende Einschränkungen zu beachten die aber das Konzept der DLLs und ihrer Schnittstellenlogik zuwider laufen. Kurz gesagt: diese Methode eines Plugin Systems macht die Vorteile von DLLs wieder zunichte.
Denn bei einer
DLL als Schnittstelle ist es ja der Vorteil das man diese eine saubere Schnittstelle hat bei der man die
DLL zb. in BCB version 3 schreibt und diese in belieben Anwendungen die zb. in BASIC oder Delphi 5 gechrieben wurden, aufrufen kann.
Gruß Hagen
PS: heist also, das Irgendwas funktioniert und machbar ist heist noch lange nicht das es auch zulässig und sauber ist. Aus Sicht eines Protected Mode Betriebssystemes und dem Sharing von
DLL's und deren Codesegemente Prozessübergreifend sind solche Tricks wie oben eben unzulässig.
Wir als Programierer müssen aber immer von reproduzierbaren und sauberen Konzepten ausgehen, damit unsere Produkte auch funktionieren. Man kann sich also über die vielen Unzulänglichkeiten eines MS Windows aufregen, aber mit solchen Konstrukten wie oben ist das dann kein Wunder.