DLL mit Strings von D10 nach Delphi 6

[kmma]

Ich habe eine DLL in Delphi 10 die eien String zurückgeben soll. Das ganze soll (muss) in einer D6 Anwendung geladen wewrden.
sharemem ist als erstes in den uses eingebunden, der String ist als ansistring definiert.

Der String wird zwar in D6 richtig angezeigt, beim Beenden der Funktion kommt es aber zu einem Speicherzugriffsfehler.
Was ist da noch zu beachten?

In Delphi 10:
function ExportString: ansistring; export;
begin
result := 'Hallo'
end;

In D6:

procedure TForm1.Button1Click(Sender: TObject);
type TStringFunction = function: ansistring;
var StringFunction: TStringFunction;
h: hmodule;
p: pointer;
begin
h := LoadLibrary(pchar('s:\D\Delphi\Test.dll'));
if h <> 0 then
begin

p := GetProcAddress(h, 'ExportString');
form1.tag := integer(p);
@StringFunction := p;
form1.caption := StringFunction; // Klappt noch

end;
end; // hier kracht es

[dummzeuch]

Ich bin mir ziemlich sicher, dass Sharemem von Delphi 10 und Sharemem von Delphi 6 nicht kompatibel sind. Deshalb müsstest Du auf PAnsiChar oder WideString umstellen.

[Bernhard Geyer]

Zitat von kmma:

Ich habe eine DLL in Delphi 10 die eien String zurückgeben soll. Das ganze soll (muss) in einer D6 Anwendung geladen wewrden.
sharemem ist als erstes in den uses eingebunden, der String ist als ansistring definiert.

Der String wird zwar in D6 richtig angezeigt, beim Beenden der Funktion kommt es aber zu einem Speicherzugriffsfehler.
Was ist da noch zu beachten?

3 Möglichkeiten:
a, Entweder baust du eine C-Kompatible Schnittstelle. Also kein AnsiString sondern P(Ansi)Char und Co
b, Exe und DLL sind mit der gleichen Delphi-Version erstellt
c, Du nutzt WideString, so das hier die Speicherverwaltung von Windows genutzt wird und kein Probleme mit
2 Speichermanagern in D6 und D100 auftauchen
Das gibt es auch unter D6, da sonst kein COM genutzt werden könnte.

Ich würde die auch empfehlen komplett von D6 weg zu kommen.
Die Produktivität von D10(.4 bei uns) ist sehr viel höher als mit D6.
Ich würde keinen Job mehr mit D6 anfangen wollen (außer die erste Aufgabe wäre Update auf aktuelles Delphi)

[himitsu]

Strings wurden im Jahre 2009 intern umgebaut. Aktuelle "LongStrings" haben zwei Felder mehr. (der Offset zwischen String-Zeiger und Speicher-Block hat sich verschoben)
Außerdem mußt du mit der Speicherverwaltung aufpassen -> Shared Memory.

Hier ein paar Threads, unter Anderem auch diesbezüglich,
wo ich zuletzt auch damit gekämpft hatte, zwischen Delphi 7 und 11.3.
https://www.delphipraxis.net/213732-...n-gesucht.html
https://www.delphipraxis.net/213691-...-methoden.html
https://www.delphipraxis.net/213736-...-fuer-neu.html

Fazit: Nimm WideString, ShortString, PChar PAnsiChar/PWideChar oder andere CharArrays.
Ebenso ginge OleVariant .... nicht Variant, da Letzteres ebenfalls die LongStrings enthält, wobei vor 2009 das Delphi den UnicodeString nicht kennt.

WideString kapselt den BSTR (OLE-String), also dessen WinAPI der OleAut32.dll, aka SysAllocString usw.

[TurboMagic]

Außer der Empfehlung auch von meiner Seite von D6 weg zu kommen noch der hinweis,
dass man sicherheitshalber auch eine Calling Convention bei der Deklaration der Funktion
in der DLL und im aufrufenden Programm angeben sollte. z. B. StdCall.
Nich dass da mal wer unbedacht dran schraubt...

[himitsu]

Oder explizit "register" als Calling-Convention hinschreiben.

Nein, "pascal" ist nicht das, was Delphi standardmäßig benutzt, auch wenn es danach klingen mag.
https://docwiki.embarcadero.com/RADS...l_und_safecall



Und unter Win64 ist es eh egal, da es dort nur noch eine Convention gibt
und sämtliche Compiler alle Angaben einer Convention ignorieren.

[kmma]

Danke erstmal für die Antworten. Das Problem ist, dass ich an der D6 Seite nichts machen kann, die Anwendung ist da und soll so bleiben (außerhalb meines Einflußbereiches).
Natürlich könnte ich die DLL in D6 erstellen, aber zum einen will ich ja hin zu D10, außerdem gibt es da ein paar sehr nette Funktionen in D10, die ich für diese Aufgabe gut gebrauchen kann.

Ich habe jetzt ein wenig experimentiert und eine "Lösung" gefunden, die zumindest in der kleinen Testumgebeung funktioniert. Jetzt würde ich gerne wissen, ob das Zufall ist und bei anderen Konstllation auch zu Abstürzen führt oder ob das zwar prinzipiell sehr unsauber programmiert ist, aber der Zweck heiligt die Mittel.

Also wie gesagt an der D6 Seite kann/will/darf ich nicht ändern.
Da gibt es einfach die Funktion (vereinfacht)

Code:

  
type TStringFunction = function: string;

Ich habe jetzt die D10 Funktion so umgebaut dass ich quasi einen Widestring als Container für einen Ansistring missbrauche. Je nach Länge des zu übergebenden Strings wird eben am Ende ein #0 mit übermttelt, aber das wäre in der D6 Anwendug kein Problem.

Code:

function ExportString: widestring; Export;
  var Ansi: ansistring;
begin
  ansi := 'Hallo';
  setlength(result, (length(ansi) div 2) + (length(ansi) mod 2));
  fillchar(result[1], 2 * length(result), 0);
  move(ansi[1], result[1], length(ansi));
//  result := 'hallo';
end;

Jedenfalls kommt in der D6 Anwendung ein "Hallo" +#0 an. Die Frage ist jetzt eben, ob ich da nur zufälligerweise keine Speicherverletzung erlebe oder ob das prinzipiell so gehen kann.