DLL mit Strings von D10 nach Delphi 6

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

[Kas Ob.]

Hi,

Is this acceptable to be solved by a hack ?

As i think it is doable but with little hacking around, see the the string structure is different, but we can utilize the fact of how Delphi handle constant (literal) strings, if the reference count is -1 ($FFFFFFFF) then it will always copy it, so in theory which i see doable, you have to overwrite and adjust your returned string to have the same structure as Delphi 6.
so the steps should be like:

1) in Delphi 10 and when the result is ready to returned, a copy of the pointer is stored in a garbage collecting list, this is crucial because we need to fix it later and release the memory preventing leak and corruption in the DLL.
2) rewrite the structure to be compatible with Delphi 6, means overwrite the 16bit "codePage" and "elemSize" as one cardinal 32bit, with value $FFFFFFFF (-1), and put the length in refCount.
3) now Delphi 6 should copy all the returned strings to its own allocated strings, as it will see them as constants.
4) we need an entry point to clean the garbage, it could be the first line in every call to DLL in Delphi 10, to restore the string refcount and assign it to an empty string ''.

This is working in my head and before writing code to demonstrate it and waste time, i would know if this is acceptable, also i don't have now an access to Delphi 6 or 7 to test it with a debugger.

On side note : i saw somewhere that himitsu has a unique love/hate for garbage collectors in Delphi, and i would love to hear your opinions.

[Kas Ob.]

Thinking more

We don't need a string, just a copy of the string in the memory adjusted to look like a string and let the DLL clear its string nicely and orderly meaning return the pointer with 8 bytes increase, as long the return fake string have refcount = -1 the application will copy its content as string from constant with the right length, this will simplify the Garbage collector from restoring the string then force to clear, or to have to save original refcount and restore it.