DLL XE4 in Delphi 6 ohne sharemem

[stalkingwolf]

Morgen zusammen.

ich versuche gerade eine Delphi XE4 DLL in Delphi 6 aufzurufen.
Ich habe dies auch schon einmal gemacht, aber ich bekomme es gerade nicht hin einen String zu übergeben und ich habe ehrlich gesagt keinen Plan warum es nicht geht. sharemem in beiden drin. Variablen Typ shortstring und auf der Seite der XE4 DLL kommt nur Datenmüll an.

Meine Frage daher nun wie gehe ich das ganze an wenn ich es ohne sharemem machen wollte.

Wie müssten beide Seiten aussehen damit ich Strings übergeben kann.

Edit : ok das Problem hat sich erledigt. stdcall hat gefehlt.
Aber die Frage bleibt bestehen um das sharemem wegzubekommen.

[dummzeuch]

Zitat:

Zitat von stalkingwolf (Beitrag 1461371)

ich versuche gerade eine Delphi XE4 DLL in Delphi 6 aufzurufen.
Ich habe dies auch schon einmal gemacht, aber ich bekomme es gerade nicht hin einen String zu übergeben und ich habe ehrlich gesagt keinen Plan warum es nicht geht. sharemem in beiden drin. Variablen Typ shortstring und auf der Seite der XE4 DLL kommt nur Datenmüll an.

Meine Frage daher nun wie gehe ich das ganze an wenn ich es ohne sharemem machen wollte.

Wie müssten beide Seiten aussehen damit ich Strings übergeben kann.

Wenn Du Strings ohne ShareMem übergeben willst (bzw. wenn das auch über verschiedene Delphi-Versionen hinweg funktionieren soll, denn die Implementation von ShareMem hat sich geändert, genaus wie der Default-String-Typ), bleiben Dir zwei Optionen:

1. PAnsiChar
2. WideString

PAnsiChar schaltet die automatische Speicherverwaltung für den String ab, es wird einfach ein Pointer auf das erste Zeichen übergeben. Jede Seite ist selbst dafür zuständig, das sauber zu implementieren (ist aber relativ einfach, eine Zuweisung auf Einen String reicht bzw. ein Typecast eines AnsiString auf PAnsiChar reicht).

Bei WideString wird der Speicher von Windows verwaltet. Das ist langsamer, aber das fällt in der Regel kaum ins Gewicht.

Und wie Du ja schon bemerkt hast: Wichtig ist, dass die Deklaration der Funktion auf beiden Seiten gleich ist, incl. der Calling-Convention.

[stalkingwolf]

Ok danke. Werde ich einmal angehen.

[stalkingwolf]

[QUOTE=dummzeuch;1461374]

Zitat:

Zitat von stalkingwolf (Beitrag 1461371)

Bei WideString wird der Speicher von Windows verwaltet. Das ist langsamer, aber das fällt in der Regel kaum ins Gewicht.

Bei WideString bekomme ich eine Zugriffsverletzung, sobald ich die DLL Funktion aufrufe.

Ich hab auch schmerzlich feststellen müssen, das scheinbar die Länge von Records begrenzt ist ... wir hatten hier so ein Monster von 150 shortstrings. Der kam nicht ganz auf der anderen Seite an :lol:

[Blup]

[QUOTE=stalkingwolf;1461583]

Zitat:

Zitat von dummzeuch (Beitrag 1461374)

Zitat:

Zitat von stalkingwolf (Beitrag 1461371)

Bei WideString wird der Speicher von Windows verwaltet. Das ist langsamer, aber das fällt in der Regel kaum ins Gewicht.

Bei WideString bekomme ich eine Zugriffsverletzung, sobald ich die DLL Funktion aufrufe.

Selbstverständlich müssen dann beide Seiten die Funktionen bzw. Parameter und Rückgabewerte mit WideString delarieren und verwenden (DLL und Anwendung).

Zitat:

Zitat von stalkingwolf (Beitrag 1461583)

Ich hab auch schmerzlich feststellen müssen, das scheinbar die Länge von Records begrenzt ist ... wir hatten hier so ein Monster von 150 shortstrings. Der kam nicht ganz auf der anderen Seite an :lol:

Wer macht den so was? Wenn es sich um konstante Strings handelt, kann man diese als Resoutce in der DLL anlegen.
Die Anwendung soll gezielt den String aus der DLL laden, der gerade benötigt wird.
Allternativ eine CallBack-Funktion als Parameter übergeben, die dem gerade benötigten String bei Bedarf bereitstellt.

[himitsu]

Zitat:

Zitat von stalkingwolf (Beitrag 1461583)

Ich hab auch schmerzlich feststellen müssen, das scheinbar die Länge von Records begrenzt ist ... wir hatten hier so ein Monster von 150 shortstrings. Der kam nicht ganz auf der anderen Seite an :lol:

Eventuell war es was mit der Speicherausrichtung in den records.
* entweder selbst festlegen, wie die sein soll, oder immer PACKED verwenden
http://docwiki.embarcadero.com/RADSt...ields_(Delphi)

Ich bin mir aber ganz sicher dass es nicht am Record selbst lag, denn eine Grenze gibt es nicht.
Record als CONST-Parameter (oder VAR) wird nur als Referenz übergeben, also garnichts kopiert.

Ohne CONST/VAR/OUT wird der Value übergeben, also eine Kopie auf den Stack gegeben.
Auch als lokale Variable liegt der Record auf dem Stack.
Und wenn nicht genug Speicher auf dem Stack ist, dann knallt es, aber es wird garantiert nichts abgeschnitten.


Übergeben wird jedenfalls definitiv immer alles, aber wenn auf beiden Seiten mit einer unterschiedlichen Speicherausrichtung oder unterschiedlichen Speichergrößen (Char, PChar, Integer/NativeInt, ...) gearbeitet wird, dann stimmen die Offsets im Record natürlich nicht.

[stalkingwolf]

[QUOTE=Blup;1461590]

Zitat:

Zitat von stalkingwolf (Beitrag 1461583)

Zitat:

Zitat von dummzeuch (Beitrag 1461374)

Zitat:

Zitat von stalkingwolf (Beitrag 1461371)

Bei WideString wird der Speicher von Windows verwaltet. Das ist langsamer, aber das fällt in der Regel kaum ins Gewicht.

Bei WideString bekomme ich eine Zugriffsverletzung, sobald ich die DLL Funktion aufrufe.

Selbstverständlich müssen dann beide Seiten die Funktionen bzw. Parameter und Rückgabewerte mit WideString delarieren und verwenden (DLL und Anwendung).

Das ist klar. Kracht dennoch.

Zitat:

Zitat von Blup (Beitrag 1461590)

Zitat:

Zitat von stalkingwolf (Beitrag 1461583)

Ich hab auch schmerzlich feststellen müssen, das scheinbar die Länge von Records begrenzt ist ... wir hatten hier so ein Monster von 150 shortstrings. Der kam nicht ganz auf der anderen Seite an :lol:

Wer macht den so was? Wenn es sich um konstante Strings handelt, kann man diese als Resoutce in der DLL anlegen.
Die Anwendung soll gezielt den String aus der DLL laden, der gerade benötigt wird.
Allternativ eine CallBack-Funktion als Parameter übergeben, die dem gerade benötigten String bei Bedarf bereitstellt.

Der Grund ist das dieser riesige Record damals wegen unser BPL erstellt wurde. Es werden alle nötigen Daten hineingepackt und dann der Record an die BPL übergeben, da diese nicht auf Datenbank zugreifen kann. und so wurde das Ding immer größer und größer und war dann irgendwann dieses Monster.
Klar man hat es sich zu einfach gemacht.

Zitat:

Zitat von himitsu (Beitrag 1461619)

Ich bin mir aber ganz sicher dass es nicht am Record selbst lag, denn eine Grenze gibt es nicht.
Record als CONST-Parameter (oder VAR) wird nur als Referenz übergeben, also garnichts kopiert.

Doch es kam nur ca 1/3 an. Nichts verschoben oder ähnliches. Wie gesagt für unsere BPL funktioniert das.
Ich habe den Record zerlegt mit exakt den gleichen Typen und dann kommt auf der anderen Seite alles an, wenn ich jeden Rekord einzeln übergebe.


Mittlerweile funktioniert alles so wie ich es will.