DLL ShareMem D2007 -> XE7?

[Mavarik]

Hallo Zusammen!

Wie mache ich am besten ein DLL mit XE7 die ich von einem D2007 Programm aus aufrufen kann..

Das Beispiel SimpleSharemem funktioniert nicht..

Oder doch mit PChars arbeiten?

Mavarik

[Union]

Aufrufen kannst Du doch immer, oder?

[himitsu]

PChar schonmal garnicht. :zwinker:
Entweder PAnsiChar oder PWideChar.

Denn der LongString (AnsiString) ist nicht kompatibel, da man in 2009 die Typ intern um zwei neue Felder erweitert hat (CharSize und CodePage),
also ein schreibender Zugriff geht überhaupt nicht und maximal kann ein älteres Delphi den neueren Stringtypen auslesen, aber nicht andersrum.


Bezüglich SharedMem brauchst du natürlich auf beiden Seiten eine kompatible Version. (so könnte man z.B. jeweils ein aktuelles FastMM in beide Programmteile integrieren)

Alternativ zu PAnsiChar/PWideChar ginge natürlich noch der WideString, wofür schon ein eigenes SharedMem gibt. (OleAut32.dll)

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1278353)

Alternativ zu PAnsiChar/PWideChar ginge natürlich noch der WideString, wofür schon ein eigenes SharedMem gibt. (OleAut32.dll)

LOL... OK Das wusste ich noch nicht... Das ist alles? :stupid:

Es funktioniert Prima... Wofür den der Sharemem Quark?

Grüsse Mavarik :coder:

[himitsu]

WideString ist ein bissl langsamer.

• hat keine Referenzzählung
• man sollte bei Parameterübergaben niemals das CONST vergessen
• zwischen den "normalen" Delphistrings und Dem muß es erst umkopiert werden
• ...

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1278404)

WideString ist ein bissl langsamer.

Bissl ist gut...

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1278404)

• man sollte bei Parameterübergaben niemals das CONST vergessen

Wieso CONST und nicht VAR?

[himitsu]

Bei VAR wird die Referenz unverändert reingegeben, da ist es egal.

Bei

Delphi-Quellcode:

prodecure Test(S: WideString);

wird aber eine 100%-Kopie des Strings erstellt, bei Aufruf der Prozedur.
Bei LongStrings (AnsiString/RawByteString/UTF8String und UnicodeString) wird einfach nur die Referenzzählung schnell hochgezählt, was praktisch nicht auffällt.

Bei

Delphi-Quellcode:

prodecure Test(const S: WideString);

passiert das nicht, da direkt mit der schreibgeschützten Referenz gearbeitet wird.

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1278465)

Bei VAR wird die Referenz unverändert reingegeben, da ist es egal.

Bei

Delphi-Quellcode:

prodecure Test(S: WideString);

wird aber eine 100%-Kopie des Strings erstellt, bei Aufruf der Prozedur.
Bei LongStrings (AnsiString/RawByteString/UTF8String und UnicodeString) wird einfach nur die Referenzzählung schnell hochgezählt, was praktisch nicht auffällt.

Bei

Delphi-Quellcode:

prodecure Test(const S: WideString);

passiert das nicht, da direkt mit der schreibgeschützten Referenz gearbeitet wird.

Ahh dann ist gut. Dachte schon VAR würde nicht gehen... :stupid:
Was ist z.B. mit TObject... ? Das abgeleitete Object könnte ja in D2000 und XE7 unterschiedlich sein.

Mavarik

[himitsu]

Objekte grundsätzlich niemals über Modulgrenien (EXE/DLL) hinweg verwenden,
außer bei BPL, oder wo man selber die RTTI shared.

Zitat:

Das abgeleitete Object könnte ja in D2000 und XE7 unterschiedlich sein.

Ja, und es kann auch innerhalb der selben Version sich unterscheiden, abgesehn von den Änderungen durch Updates/Bugfixes.

TObject der DLL ist ein anderes als das TObject der EXE,
genauso bei allen anderen Klassen.

Wenn auf einer Seite ein Feld nicht benutzt wird, dann kann der Compiler das weglassen, womit dann alle nachfolgenden Adressen nicht mehr stimmen.
Der Offset nachfolgender Variablen verschiebt sich (aber nur in der einen RTTI) und auch die Position in der VMT verschiebt sich, bei virtuellen Methoden
und somit greift die andere Seite (EXE/DLL) mit ihrer eigenen RTTI auf was Falsches zu.