Gleiche DLL im selben Prozess mehrfach laden?

[nuclearping]

Hallo,

in unserem Projekt hat sich jetzt die Notwendigkeit ergeben, dass gewisse Algorithmen so ausgelagert werden, dass dritte keinen Einblick in die Funktionsweisen bekommen.

Also habe ich kurzerhand eine wichtige Klasse, welche vorher einfach instanziert werden konnte, wenn man die Unit eingebunden hat, in eine DLL ausgelagert, die dynamisch geladen wird. Dazu habe ich ein "Framework" zu der Klasse erstellt, welches die Funktionen nach aussen hin noch genauso anbietet wie vorher, intern jedoch lediglich die Funktionen an die DLL übergibt. Im Constructor wird die DLL per LoadLibrary geladen und im Destructor wieder freigegeben.

Diese Klasse wird im Programm an verschiedenen Stellen mit unterschiedlichen Parametern und Zuständen erzeugt. Nun habe ich aber das Problem, dass die DLL ja nur einmal in den Prozess geladen wird und ein zweiter Aufruf von LoadLibrary lediglich das Handle auf diese DLL zurückliefert. Erneute Aufrufe des Constructors überschreiben dann somit die bereits bestehende Klasse in der DLL und das Programm fährt gegen die Wand.

Die SuFu hat mir nur das ausgespuckt -> http://www.delphipraxis.net/internal...brary+mehrfach

Die Lösung mit dem "On-the-fly-Umbenennen" kommt mir aber nicht in die Tüte. Gibt es wirklich keine Möglichkeit, die DLL einfach so wie eine Klasse unabhängig voneinander zu "instanzieren"? Wo ist das Problem dabei?

Danke.

Mario

[chaosben]

Herzlich Willkommen in der DP!

Warum willst du die DLL mehrfach laden? Lade sie doch einmal (im initialization der Unit z.B.).

Ich glaube da gibt es ein Verständnis-Problem bezüglich DLL's. Solche Bibliotheken arbeiten in der Regel Prozedur-orientiert und nicht mit Klassen. Das heißt ich kann die Prozeduren der DLL aufrufen wie ich gerade lustig bin, ohne an irgendwelche Objekte zu denken.
Und ganz wichtig: Niemals Objekte über DLL-Grenzen hinweg benutzen. (in der Regel)

[Luckie]

Zitat von nuclearping:

in unserem Projekt hat sich jetzt die Notwendigkeit ergeben, dass gewisse Algorithmen so ausgelagert werden, dass dritte keinen Einblick in die Funktionsweisen bekommen.

Also habe ich kurzerhand eine wichtige Klasse, welche vorher einfach instanziert werden konnte, wenn man die Unit eingebunden hat, in eine DLL ausgelagert

Und warum ist das deiner Meinung nach jetzt sicherer? Ob der Code nun im Programm selber oder in der DLL ist, macht keinen unterschied.

[nuclearping]

Es geht nur um freie Mitarbeiter, die die Routinen zur Ansteuerung der Hardware und zur Auswertung der Daten brauchen, um die Software zu erweitern. Aber denen geht ja unsere "Rezeptur" nichts an. Daher bekommen sie die DLL und das Interface, womit sie arbeiten können. Sonst bräuchten sie die Units, womit sie auch gleich den Code für die Algorithmen hätten.

Zitat von chaosben:

Ich glaube da gibt es ein Verständnis-Problem bezüglich DLL's. Solche Bibliotheken arbeiten in der Regel Prozedur-orientiert und nicht mit Klassen. Das heißt ich kann die Prozeduren der DLL aufrufen wie ich gerade lustig bin, ohne an irgendwelche Objekte zu denken.
Und ganz wichtig: Niemals Objekte über DLL-Grenzen hinweg benutzen. (in der Regel)

Ja, aber warum lädt Windows - auf Wunsch - nicht die DLL mehrfach in den Prozess? Ich hatte immer das Verständnis, dass das Handle ja alles trennen sollte.

[Luckie]

Zum kompilieren brauchen sie doch nur die kompilierten Units (*.dcu). Somit hätten sie auch keine Einsicht in den Quellcode.

[nuclearping]

Aber nicht, wenn wir mit D6 und der eine zB mit D7 arbeitet, leider ...

[chaosben]

Zitat von nuclearping:

Ja, aber warum lädt Windows - auf Wunsch - nicht die DLL mehrfach in den Prozess?

Das liegt imho an der Art und Weise, wie DLL's geladen werden. Wenn ich mich nicht ganz sehr irre, wird der Code der DLL in den Speicherbereich der Anwendung "kopiert". Würde man ein DLL mehrmals laden können, würde ein und das selbe mehrfach im Speicher liegen.

//Offtopic:

Zitat von nuclearping:

wenn wir mit D6 und der eine zB mit D7 arbeitet

Und genau das ist der Grund, warum man keine Objekte über DLL-Grenzen nutzen sollte. (Nur so als Info )

[nuclearping]

Ja, aber das wäre ja gerade Sinn der Sache in dem Fall!

Naja, mal schauen, ob und wie ich die Callbacks "On Demand" übergeben kann. Sonst muss ich mir was anderes einfallen lassen.

Zitat:

Und genau das ist der Grund, warum man keine Objekte über DLL-Grenzen nutzen sollte. (Nur so als Info Smile )

Macht er ja nicht wirklich, es sei denn das zählt bereits für TLists - aber wie ich's vermute tut's das bereits ...

Was hätte ich denn sonst noch für Möglichkeiten? In C++ könnte man ja die *.obj weitergeben, aber damit sind wir hier ja nicht unterwegs.

[chaosben]

Zitat von nuclearping:

Macht er ja nicht wirklich, es sei denn das zählt bereits für TLists ... Was hätte ich denn sonst noch für Möglichkeiten

DIE Alternative zu DLL's sind BPL's. Das sind zwar auch nur DLL's aber da kümmert sich Delphi drum, das man die Objekte keuz und quer benutzen kann.

[nuclearping]

Aber ist da das Konzept nicht das gleiche? Wenn ich mit LoadLibrary statt einer DLL eine BPL lade ...?