DLL mit Strings von D10 nach Delphi 6

[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.

[jaenicke]

Wenn da mit Strings über DLL-Grenzen hinaus agiert wird, kannst du das sauber nicht mit neuen Delphiversionen kombinieren.

Die einzig saubere Lösung:
Entwirf eine saubere neue DLL-Schnittstelle auf dem neuen Stand, sei es mit WideString oder P(Wide/Ansi)Char. Dann schreibe in Delphi 6 eine Wrapper-DLL, die nach außen die alte Funktionalität mit Sharemem bietet.

Auf diese Weise hast du dann für die Zukunft eine moderne DLL ohne Tricksereien, die trotzdem sauber in das alte System integriert werden kann.

[himitsu]

Siehe mein gezeigtes Projekt.
Von D7 zu 2009+ und umgekehrt.
Der originale D7-Code konnte nicht geändert werden.
Drum wurde eine D7-DLL erstellt (es gab noch Keine, nur die DCUs ... aber darum konnte ich drüben auch bissl was einfügen, um diesen Teil nicht auf Seite des 2009+ machen zu müssen ... aber im Grunde egal, wer von Beiden es macht)

Das alte Delphi kann LongStrings AnsiStrings/UTF8String/usw., des neuen Delphi lesen.
Es kann für sich selber auch Kopien erstellen, via Referenzzählung oder komplett.
Es darf aber niemals einen fremden String, des neuen Delphi, verändern oder freigeben.

Das neue Delphi kann/darf dagegen KEINEN AnsiStrings des alten Delphis lesen/bearbeiten/freigeben ... absolut nichts, da die neuen Felder nicht existieren und der Zugriff darauf fehlschlagen muß.

Darum hatte ich mir auch die Funktion zum Bearbeiten ins andere Delphi rübergezogen, denn es nutzt dadurch die Funktionen und den Speichermanager der anderen Seite.

Außnahme, was Beide können: Egal ob als AnsiString oder PAnsiChar übergeben wurde, es kann immer als über einen Cast nach PAnsiChar gelesen werden.
(auch Ändern einzelner Chars, über den PAnsiChar, also nur, wenn dabei nichts in der Speicherverwaltung angestoßen wird)