DLL Verständnis frage...

[jaenicke]

Zitat von Der schöne Günther:

Ich habe nur wenig Erfahrung mit DLLs, aber solange es nicht super zeitkritisch oder gigantische Datenmengen sind, weshalb macht man das nicht einfach so, wie man es z.B. aus der Windows-API auch kennt?

Warum sollte man den Aufwand betreiben, wenn man es nicht muss? WideStrings sind etwas langsamer, aber deutlich einfacher zu nutzen.

Die Lösung aus dem ersten Post passt schon so. Ich würde den WideString nur als Rückgabewert nehmen. Wofür soll das ein var Parameter sein? Es sei denn der Rückgabewert soll z.B. den Erfolg signalisieren.

[TurboMagic]

Naja, es stellt sich halt die Frage wer den Speicher wie reserviert.
Wenn die DLL das als Rückgabewert macht, dann hat die DLL einen Pointer anzulegen der groß
genug ist das die Daten rein passen.

Nur: wann wird das freigegeben?

Wenn man es als Var Parameter macht, dann müsste denke ich der Aufrufer den Speicher reservieren,
wozu er aber wissen müsste wieviel benötigt wird.

Grüße
TurboMagic

[DelTurbo]

Zitat von jaenicke:

Die Lösung aus dem ersten Post passt schon so. Ich würde den WideString nur als Rückgabewert nehmen. Wofür soll das ein var Parameter sein? Es sei denn der Rückgabewert soll z.B. den Erfolg signalisieren.

Danke, ja das ist eigentlich eine Function die ein True/False zurückgibt. Ich habe das ob nur so einfach wie möglich gemacht, das es nicht so viel wird.

Danke @all, ich habe es auch so am Laufen. Von Win7-11.

Frohe Ostern euch allen, auch an alle hier im Forum....

[Mavarik]

Ich nutze mittleiweile of XEx DLL's von D2007 aus.
Dein Beispiel ist correct.

WideStrings werden "von Windows" verwaltet, daher machen die kein Problem.

Strings und AnsiString gehen nicht, weil die in unterschiedlichen Speichern verwaltet werden.

Native type wie byte, integer und gehen natürlich auch. Das gleiche gilt für interfaces.

Für Streams musst Du einen IStream verwenden.

Mavarik

[himitsu]

Nicht nur unterschiedlich verwaltet, was sich via ShareMem lösen liese.

Im Jahre 2009 wurde auch die Struktur der LongStrings geändert.
* früher gab es vor den Chars nur Felder/Variablen für Length und Referenzzähler
* jetzt gibt es zusätzlich noch Felder für die CodePage und die CharSize.

Neue Delphis auf alten Strings, würden also auf beim Kopieren des Strings auf nichtexistierende Felder zugreifen
und die Speicherverwaltung würde jeweils mit einem falschen Offset den internen Anfang des Strings falsch bestimmen.

Hier mal ein böses Beispiel, was für einen Aufwand man bekommt, wenn man dennoch Delphi-Strings zwischen DLLs/EXE übergeben möchte.
https://www.delphipraxis.net/213736-...-fuer-neu.html



ShareMem verbindet nur den SpeicherManager, aber dennoch haben DLL und EXE weiterhin jeweils eigene Funktionen für die Verwaltung des Strings.

Delphi 2 bis 2007 sind bezüglich dem AnsiString somit noch kompatibel, was die Verwaltungsfunktionen der Strings angeht (ShareMem vorausgesetzt)
oder eben alles ab 2009 bis "jetzt", wo AnsiString sowie UnicodeString kompatibel wären.

Ja, sogar AnsiString und UnicodeString/String sind per se untereinander kompatibel, ABER seitdem das StringChecking wieder deaktiviert wurde, stimmt das nur bedingt.

[Mavarik]

Zitat von himitsu:

Nicht nur unterschiedlich verwaltet, was sich via ShareMem lösen liese.

ShareMem mit D2007 und einer D11.3 DLL?

Seit wann soll das funktionieren?

Mavarik

[himitsu]

Es gibt nicht nur dieses eine SharedMemory.