Standardunits in dll einbinden

[himitsu]

Auch bei FastMM muß man erstmal die eingebaute SharedMemory-Funktion aktivieren,
ansonsten nutzen die DLL und die EXE immernoch jeder einen eigenen Speichermanager und schon iser der Hinweis auf den String wieder aktuell.

PS: Du kannst auch einfach WideString nutzen, denn dieser ist ein Sonderfall, da er nicht über den DelphiSpeichermanager/FastMM behandelt wird.

[xml99]

Hallo,

Danke für die Antworten.

@mkinzler: dann gibt es keine access violation beim Beenden des Hauptprogramms.

@himitsu: Danke für den Hinweis mit den Strings. Das ist aber nicht die Ursache. Z.B. Sysutils in der uses Anweisung der dll vorhanden -> access violation, nicht vorhanden alles ok. Ich meine DN gelesen zu haben, dass der FastMM4 jetzt der MM von Delphi ist (ab Delphi 2007) und keine dll oder unit mehr benötigt wird.

Grüße
Ralf

[himitsu]

Ja, im Delphi ist nun eine abgespeckte/angepaßte Version von FastMM4 enthalten (vermutlich ein FastMM 4.7x oder 4.6x), aber dieser ist nicht standardmäßig auf SharedMemory eingestellt.

Bei dem Modul (EXE/DLL), von welchem der MM geshared werden soll, da muß dieser über die Funktion ShareMemoryManager zum Sharing freigegeben werden.
(bei einer statisch geladenen DLL also in der DLL , ansonsten in der EXE ... also da, was zuerst geladen wird)

Dort, wo der MM genutzt werden soll, da muß dieser über die Funktion AttemptToUseSharedMemoryManager importiert werden (vor jeglicher Nutzung des eigenen MMs, also möglichst in einer Unit als Erstes der DPR)

Man kann aber auch einfach die Unit SimpleShareMem in beide/alle Module (EXE und DLL), jeweils als erste Unit in der DPR aufnehmen, dann kümmert sich diese Unit um das Sharen.

Näheres dazu ist dort zu lesen.

[xml99]

Hallo himitsu,

Ok, habe verstanden. Also ist SimpleShareMem (das abgespeckte FastMM4??) nötig um gemeinsamen Speicher, ohne zusätzliche dll zu verwalten. Der Beitrag aus Hallvard's Blog suggerierte mir, dass das Einbinden einer zusätzlichen unit seit Delphi 2007 nicht mehr nötig wäre.

Werde es später ausprobieren. Noch eine kleine Nachfrage: wenn ich statt SimpleShareMem FastMM4 einbinde habe ich ja auch einen MM, der keine dll zusätzlich benötigt. Gibt es hier Erfahrungswerte für die verschienen conditionals für die exe und die dll? Hast Du vielleicht sogar Beispiele, wie man die FastMM4-include ändern sollte um gute Ergebnisse für Debug/Release zu erzielen?

Danke und Grüße
Ralf

[himitsu]

Die DLL war eigentlich nie nötig, aber diese stellt als seperate globale DLL eine sichere Methode dar, um problemlos zu sharen, da sie immer als "erstes" (vor der EXE und der anderen DLL) geladen wird.

Problem:
versuche mal den Speicher zwischen 2 dynamisch geladenen DLLs (nicht mit der EXE, sondern nun zwischen den DLLs) zu sharen.

- erste DLL laden
- diese läd ihren MM
- zweite DLL laden
- diese nutzt nun den MM der Ersten
- erste DLL entladen
- diese nimmt ihren MM mit
- in zweiter DLL kracht es nun, da der MM weg ist
Das Problem hat man auch mit FastMM (ohne extra DLL für die MM-Verwaltung)


Die Unit SimpleShareMem enthält auch nur die Funktionsaufrufe für ShareMemoryManager und AttemptToUseSharedMemoryManager
und vereinfacht so deren Aufruf, da man sich selber nicht soeine Unit basteln muß, denn ein externer/anderer MM kann nur geladen werden, wenn der Eigene noch nicht gestartet/benutzt wurde.

Klar kannst du einen neueren/größeren FastMM nutzen, aber auch diesen mußt du, irgendwo in der Options.inc (oder wie die nochmal heißt) dieses aktivieren.