Mehrfache instanzen einer DLL laden, wie geht das?

[QuickAndDirty]

Ok ich arbeite an einer DLL , diese DLL soll von mehreren
Anwendung verwendet gestartet werden.

Ich meine zu wissen DLL nur einmal von windows
in den Speicher geladen werden muss und das dann alle
Anwendungen darauf Zugriff haben.
Wenn das so ist. Wie kann ich dafür sorgen das meine Anwendungen
sich die DLL jedes mal neu und nur für sich in den Speicher laden?

Macht LoadLib das bereits so wie ich's brauche?
Ich glaube in der SDK-Hilfe stand das Loadlib (edit: vorher freelib) nur den Refcount auf die DLL erhöht.

Was muss ich tun?

[mkinzler]

das ist doch der Sinn einer DLL, daß sie nur einmal geladen wird und nur einmal Speicher verbraucht.
Warum willst du die DLL exclusiv für dein Programm laden?

Zitat:

Macht LoadLib das bereits so wie ich's brauche?

Nein.

Zitat:

Ich glaube in der SDK-Hilfe stand das Freelib nur den Refcount auf die DLL erhöht.

Der RefCount müsste erniedrigt werden.

[SirThornberry]

innerhalb eines Prozesses wird eine DLL nur einmal in den Speicher geladen und ansonsten wir die Referenz erhöht. Aber das eine DLL für alle Prozesse nur einmal geladen wird ist mir neu. Dann könnte ja ein Programm einen wert in der DLL ändern und alle anderen Programme greifen dann auf die Änderung zu.

[QuickAndDirty]

Ich mappe funktionen der Standard Session von DbTables.
kann aber mal sein das 2 Anwendungen unterschiedliche Sessions
brauchen. In meinem Falle zwar nicht, aber glaube das dürfte auch
ein Problem mit der thread Sicherheit geben.

[hoika]

Hallo,

der Code steht nur einmal im Speicher,
bei den Daten, sofern globale Variablen verwendet werden,
kommt es darauf an.

Früher ... gab es mal eine "shared data" Anweisung (c++),
die es erlaubte, Daten zwischen Prozessen auszutauschen.

Sowas sollte man nicht tun.

Ich glaube mich zu erinnern, dass jetzt (ab NT?) jeder Prozess
standardmäßig sein eigenes Datensegmant besitzt.

Prinzipiell würde ich in einer DLL keine Daten ablegen,
dass kann man den Prozeduren und Funktionen der DLL auch übergeben.

Heiko

[QuickAndDirty]

@hoika und Mkinzler: Wer von euch hat recht?
Werden also Globale Variablen wie das Session objekt in der DbTables
für jede Anwendung gesondert geführt. Der Code aber geteilt?
ich will noch darauf hinweisen das ich die Sharemem unit verwende
und so wie ich die verstehe übernimmt dann Borlandmm.dll die
Heapverwaltung.

[rosseaux]

Indem man einen eigenen DLL Loader schreibt, wie ich es getan habe, siehe http://www.delphigl.com/forum/viewto...8dbcc191bab3ec oder auf http://bero.0ok.de/

[Vjay]

Die DLLs werden einmal "real" geladen und in die verschiedenen Prozesse, welche sie benötigen "eingespiegelt".

Die Prozesse ansich bemerken davon nichts, bzw. es spielt für sie keine Rolle.
Wenn du nun rangehst und am Codesegment deiner Dll rumfummelst, wird eine komplette Kopie erstellt (copy on write).

Die Variablen der einzelnen DLL- Instanzen sind logischerweise nicht miteinander verbunden, da sie im Speicher der verschiedenen Prozesse angelegt sind.

[mkinzler]

Zitat:

@hoika und Mkinzler: Wer von euch hat recht?

Beide, da ich dich falsch verstanden habe. Der Code der DLL wird nur einmal geladen, der Datenteil existiert aber für jede Instanz.

[QuickAndDirty]

@Rosseau: wirklich gut was du da auf die Beine gestellt hast, aber nicht das passende für mich, glaube ich (müste man ja erst ausprobieren).

@VJAY: danke das hört sich gut an. Nach einigem Nachdenken glaube ich das es dann auch egal ist was borlandmm.dll macht.
Was genau meinst du mit am Datenteil Rumfummeln?
Ich gebe in der regel alles was ich mit dem DBTables.Session Objekt machen will an eine DLL Funktion. Welche die Manipulation
dann vornimmt. also ist der einezige der an dem Objekt "rumfummelt" die DLL, oder? Ausserdem greife ich ja au nur lesend
darauf zu, das Objekt wird im initalization teil von DbTables in der DLL erzeugt.

@mKinzler: ja, es fehlt mir eine Funktion die das Was ich meine auch aufschreibt
Ansonsten gut zu wissen das ich mir wohl fast Sorgen machen muss.