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.

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1278524)

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.

Also für alles was nicht (Byte,Word,Integer,Pointer,Widestring) ist einen "schönen" Wrapper bauen...

z.b. alles in einen Buffer "knallen" und den Pointer auf den Buffer übergeben...

Mavarik

[himitsu]

Oder ein IInterface um das Objekt drumrum (also auch ein Wrapper :angel:), da dort das Interface feste Indize besitzt (wenn man überall die selbe Definition verwendet) und es dann in jedem Modul eine passende Übersetzung für Interface<->Klasse gibt.

Und natürich nur statische Typen verwenden, also kein PChar, Char usw., sondern PAnsiChar, PWideChar usw.
Für Integer/NativeInt/Pointer würde es zwar auch gelten, aber da man eh keine 32-Bit-DLL in eine 64-Bit-EXE rein bekommt, und andersrum ebenfalls nicht, stört es hier nicht.

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1278543)

Oder ein IInterface um das Objekt drumrum (also auch ein Wrapper :angel:), da dort das Interface feste Indize besitzt (wenn man überall die selbe Definition verwendet) und es dann in jedem Modul eine passende Übersetzung für Interface<->Klasse gibt.

emm dazu nochmal auf deutsch bitte.

Natürlich nutze ich ein Interface.

Delphi-Quellcode:

    IFooDll = Interface
      ['{23763801-630D-4389-B214-398804635CA1}']
      Procedure Test(Var S : WideString);
      Function ShowPanel(ParentWnd:hwnd;R:TRect):hWnd;stdcall;
    End;

Und übergebe das Interface an die DLL

Delphi-Quellcode:

Procedure SetInterface(Var DLL:IFooDll);
begin
  DLL := TFoo.Create;
end;

Exports
  SetInterface;

Welchen Vorteil - den ich noch nicht gesehen habe - habe ich dadurch auch noch?

Mavarik