String aus D5 DLL in Delphi 10.2 einslesen

[jziersch]

ich meinte dies:

function ExportString: PAnsiChar stcall; external 'xxx\Project_d5.dll';

und mal sehen was Du mit dem Pointer machen kannst.

Auf diese Weise wird ShareMem etc. nicht benötigt.

[EWeiss]

Zitat von jziersch:

ich meinte dies:

function ExportString: PAnsiChar stcall; external 'xxx\Project_d5.dll';

und mal sehen was Du mit dem Pointer machen kannst.

Auf diese Weise wird ShareMem etc. nicht benötigt.

Sieht seltsam aus.. stcall nicht stdcall ?

gruss

[Codehunter]

Soweit ich mich erinnere ging das mit den String-Rückgaben bei D5 ausschließlich in Verbindung mit Sharemem und/oder FastMM4. Daher würde ich orakeln, dass der Speichermanager von Tokio krachen geht. Evtl. hilft es, die DLL dynamisch (spät) zu laden und nach Gebrauch auch gleich wieder freizugeben.

[hoika]

Hall,
laß unter D10 einfach mal das stdcall weg.

[Rolf Frei]

Du deklarierst die Funktion mit einem Rückgabewert als AnsiString. In deiner Anwendung nutzt du aber einen ShortString. Nutze den selben StringtTyp in der Anwendung, also AnsiString. ShortString und AnsiString sind intern komplett anderes aufgebaut und ich kann mir gut vorstellen, dass es deswegen zu einer AV kommt.

[hoika]

Hallo,

Zitat:

ShortString und AnsiString sind intern komplett anderes aufgebaut

Ausprobieren.
Sobald das falsche (denke ich) stdcall weg ist, 50:50 Chance ...

Zitat:

StringLists aus D5

Das kannst du glaube ich vergessen.
https://stackoverflow.com/questions/...elphi-versions
Notlösung wäre, den StringList.CommaString zu übergeben, also genau einen String.

[Rolf Frei]

Wieso nicht einfach:

In der DLL: ExportString := StringList.Text
in der Anwendung: StringList.Text := ExportString

Damit lässt sich eine Stringlist mit der bestehenden Funktion ohne Probleme transferieren.

Stcall wird doch sicher einen Compilerfehler bringen. Ich vermute das ist hier einfach ein Schreibfehler des OP im Forum.

[dummzeuch]

Wenn der Export aus der DLL nicht als StdCall deklariert wurde, sollte der Import es auch nicht sein.

Laut Swiss Delphi Center (bzw. Peter Below, der den Artikel dort geschrieben hat) war die Default-Calling-Convention in Delphi 5 nicht StdCall sondern Register.

Normalerweise sollte man die aber in der DLL explizit angeben...

Ansonsten: Mit Delphi 2007 wurde der Standard-Memory-Manager auf FastMM geändert. Früher wurde für ShareMem eine DLL (BORLNDMM.dll?) benötigt, die dann sowohl das Programm als auch die DLL zur Speicherverwaltung benutzt haben. Seit FastMM ist das nicht mehr notwendig.

Ich frage mich gerade, ob das alte ShareMem noch kompatibel zum neuen ist.

Vielleicht muss man ein Flag setzen?
EnableBackwardCompileMMSharing