Datenübergabe Exe-DLL und unterschiedliche Delphi-Versionen

[Lemmy]

Hi,

habe das Problem, dass ich einen Teil einer Anwendung (Delphi 7) in einer neueren Delphi-Version umsetzen muss (XE2), weil dort Fehler korrigiert wurden. Eine Änderung der VCL von Delphi 7 ist mir zu heikel wegen den div. Abhängigkeiten von Drittkomponenten. Eine komplette Umstellung auf XE2 ist geplant, wird aber nicht zeitnah durgeführt werden können.

Erst dachte ich ich schieb die Daten (es handelt sich im Grunde um mehrere KLassenmodelle) bzw. die jeweilige Hauptklasse als Zeiger in die DLL und caste dort wieder auf die Klasse, verarbeite und gut ist. Problem sind jetzt aber die div. Strings in den Klassen: Klar kann ich ShareMem einbinden, doch welche BORLNDMM.DLL liefere ich dann aus? Die von Delphi 7 oder die von XE2? Zumindest in den Foren in denen das Thema angesprochen wurde, wird generell davon abgeraten so was zu machen und auf die BORLNDMM.DLL zu verzichten.

Jetzt habe ich noch folgende Optionen:
Für die Datenübergabe baue ich spezielle DatenkLassen, die anstelle der Strings mit ShortStrings bzw. PCHars arbeiten oder ich serialisiere die gefüllten Klassen und sende an die DLL einen entsprechenden Datenstrom und Rückwärts dann ebenso. Beides ist ein entsprechender AUfwand, wobei ich gerade zu der PChar-Lösung tendiere.

Gibt es über die beiden Möglichkeiten auch noch andere denkbare Lösungswege? Die DLL soll lediglich für Delphi bereit stehen und fliegt nach dem Umstieg auf XE2 oder neuer aus dem Gesamtsystem wieder raus...

Grüße

[jaenicke]

Zitat:

Zitat von Lemmy (Beitrag 1164543)

Erst dachte ich ich schieb die Daten (es handelt sich im Grunde um mehrere KLassenmodelle) bzw. die jeweilige Hauptklasse als Zeiger in die DLL und caste dort wieder auf die Klasse, verarbeite und gut ist. Problem sind jetzt aber die div. Strings in den Klassen

Auweia...
Dir ist noch gar nicht wirklich klar was deine Probleme dabei eigentlich sind. ;-)

Die Strukturen haben sich von TObject an geändert. Deshalb kannst du Objekte aus verschiedenen Delphiversionen nicht einfach casten, selbst wenn sie direkt von TObject abgeleitet sind. (Davon abgesehen, dass man das sowieso niemals nicht machen sollte. ;-))

Erstelle für den Zweck Interfaces für die Klassen. Die können bei Strings auf den Typ WideString zurückgreifen. Dann kannst du diese Interfaces 1:1 einfach übergeben. Die Referenzzählung solltest du dabei deaktivieren, da du ja auch mit den Objekten arbeitest, damit nicht das auch noch Probleme macht. So wäre das als relativ schnelle Lösung möglich.

[Lemmy]

Zitat:

Zitat von jaenicke (Beitrag 1164545)

Auweia...
Dir ist noch gar nicht wirklich klar was deine Probleme dabei eigentlich sind. ;-)

Stimmt - deshalb frage ich ja auch hier nach :-) Aber du hast völlig recht, das mit TObject kann auch nicht wirklich funktionieren.

Die IDee mit den Interfaces ist gut..... Muss gleich mal mein Testprojekt anschauen...

Grüße

[himitsu]

Die kann/sollte man sowieso nicht über Modulgrenzen (EXE<>DLL) hinweg casten, da es auch innerhalb der selben Compiler-Version unterschiede zwischen den klassen geben kann.

Immerhin hat jedes Modul (EXE/DLL) seine eigene RTTI.


PS: Der Delphi-Compiler/Linker läßt Dinge weg, die er nicht als verwendet ansieht.
Wurden nun in der DLL andere Dinge weggelassen, als in der EXE oder einer anderen DLL, dann sind die RTTIs/Klassen dennoch nicht kompatibel.

[Lemmy]

Hi,

Zitat:

Zitat von himitsu (Beitrag 1164549)

PS: Der Delphi-Compiler/Linker läßt Dinge weg, die er nicht als verwendet ansieht.
Wurden nun in der DLL andere Dinge weggelassen, als in der EXE oder einer anderen DLL, dann sind die RTTIs/Klassen dennoch nicht kompatibel.

das ist jetzt wirklich interessant... Das war mir in der Dimension noch nciht bewusst, dass der Compiler/Linker Zeugs wegoptimiert ist klar, dass sich dadurch aber die Schnittstellen der KLassen ändert, ist mir jetzt echt neu...

Testprogramm geändert und sieht schon mal verdammt gut aus.

[himitsu]

Das Schlimmste was passieren kann, ist die VMT oder neue/alte Felder.

Diese ist ja nur ein Array, wo nacheinander virtuellen Methoden verlinkt sind.
Fällt auf einer Seite eine Methode weg, dann liegen die nachfolgenden Methoden einen Index höher.
Wird nun über den Index der falschen/anderen RTTI zugegriffen, dann wird ein falscher Index erwischt und somit auch eine falsche Methodenadresse.
Da soll z.B. Methode A aufgerufen werden, aber ausgeführt wird dann Methode B.

Genauso könnte falsche Felder/Speicherzellen erwischt werden ... es soll in Feld X was reingeschrieben werden, aber da X drüben nicht verwendet wurde oder noch nicht existierte, bzw. nicht mehr existiert oder weider Vorne etwas Anders ist, wird stattdessen in Feld Y rumgeschrieben.

...