DLL einbinden Delphi7 vs Rad Studio 10.2

[KodeZwerg]

Zitat von mkinzler:

Nur wenn man Delphi-Strings verwendet.

Dann habe ich das falsch in Erinnerung, Text im allgemeinen dachte ich ist betroffen, ich nutz meist eh stdcall anstelle CDECL.

@EWeiss: Das war kein Angriff meinerseits, ich wollte damit nur sagen das es bei Übermittlung ohne den Manager zu fehlern kommen kann. Da es sich anscheinend nur um Konvention "String" handelt ist meine Aussage eh belangslos geworden.

Ps: Jetzt ist es mir wieder eingefallen bzw ich sehe es, ja das war so Delphi 6/7 rum als ich enorme Probleme hatte da Text immer fehlte/abgeschnitten war, stimmt total @mkinzler, String war damals auch der Übeltäter, ich habe erst jetzt das Projekt gefunden.

[EWeiss]

Zitat:

@EWeiss: Das war kein Angriff meinerseits, ich wollte damit nur sagen das es bei Übermittlung ohne den Manager zu fehlern kommen kann. Da es sich anscheinend nur um Konvention "String" handelt ist meine Aussage eh belangslos geworden.

Habe ich auch nicht so aufgefasst ..

gruss

[himitsu]

Zitat von KodeZwerg:

Ich las gerade das Du DLL mit einer CDECL Anweisung öffnest, da sollte dann immer der Memory Manager von Delphi an erster Stelle mitkompiliert werden, sonst kann es bei Daten-Übertragung (.exe <-> .dll) zu fehlern kommen.

Wieso?
Die Aufrufkonvention hat absolut garnichts mit den Speichermanagern zu tun.

Die besagen ob Parameter auf dem Stack landen und/oder in den Registern und in welcher Reihenfolge
und wer den Stack am Ende aufräumt (der Aufrufer oder der Aufgerufene).

[KodeZwerg]

Zitat von himitsu:

Die Aufrufkonvention hat absolut garnichts mit den Speichermanagern zu tun.

Dann bastel Dir mal eine .dll mit Funktionen die Input/Output : String haben.
Nutze keinen Speichermanager.
Irgendwann wirst Du feststellen das die Strings fehlerhaft sind.
Bindest Du dann den Speichermanager in .dll und .exe ein, sind alle Strings auf magische Weise repariert. (<- objektive Aussage)
Vielleicht handhabt Delphi das jetzt mittlerweise anders (?), aber zu Delphi 6/7 war es ein arges Problem für mich gewesen!

[Luckie]

Und wo kommt bei dir jetzt die Aufrufkonvention ins Spiel?

Genau das wurde doch gesagt. Den Speichermanager brauchst du nur bei Delphi Strings. Unabhöngig von den Aurufkonventionen. Was die Aufrufkonventionen bewirken, wurde auch erklärt.

[KodeZwerg]

.dll

Delphi-Quellcode:

function abs(Input1, Input2, Input3: String): string; cdecl;
begin
  result := input1+#13#10+input2+#13#10+input3;
end

exports
 abs name 'abc',

.exe

Delphi-Quellcode:

function xyz(Input1, Input2, Input3: String): string; cdecl; external '123.dll' name 'abc';
Memo1.Lines.Add(xyz('Das ist ein Dll Test','der vielleicht in die Hose geht','wenn man keinen Speichermanager einbindet'));

meinst Du das?


edit: ok, erledigt.

[himitsu]

Und dann kommt noch etwas dazu.

Mit Delphi 2009 wurden die LongStrings erweitert. (nicht nur, dass der UnicodeString dazu kam)

Also, selbst mit SharedMemmory gibt es dann Probleme, wenn man AnsiString zwischen DLL und EXE austauscht, aber Einer mit Delphi 2007 oder älter und der Andere mit Delphi 2009 oder neuer kompiliert wurde.

Reine Lesezugriffe auf der Anderen Seite würden aber noch funktionieren, aber den String verändern und ein Lesezugriff auf einen String, aber mit concatinieren zweier/mehrerer String kann knallen.
Seit D2009 hat der AnsiString zwei Word (einen Integer) mehr in seiner Verwaltungsstruktur (CodePage und CharSize) ... vorher gab es nur Length und RefCount.