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! :hi:

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:

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:

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. :gruebel:

[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:

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:

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! :mrgreen:

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:

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

:gruebel:

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 ...?

[chaosben]

Dann wäre es das selbe.

Aber wenn du deiner Anwendung sagst (Projekt-Optionen): "Benutze Runtime-Packages und LoadPackage(MyFunctions.bpl)" dann kannst du ganz normal auf die Klassen, die aus der BPL stammen, zugreifen. Ganz so als hättest du sie per Unit geused (was für ein Wort). Dafür musst du aber nur die BPL und die DCP weitergeben und nicht den Sourcecode.

[nuclearping]

Und das funktioniert über Delphi-Grenzen hinweg? Also wenn ich das mit D6 erstelle, kann das einer mit D7 einbinden und compilen, ohne dass er die Sources braucht?

[Luckie]

Nein, ich glaube auch BPLs sind Versions abhängig.

[chaosben]

Hmmm ... wenn Luckie sagt "ich glaube" dann gibt es scheinbar kein geschriebenes Gesetz, was die Sache eindeutig regelt. :)

Insofern müsste man es mal ausprobieren.

//edit: Ich denke, so lange die Abhängigkeiten erfüllt werden, sollte es nicht von der Version abhängen. Weil: Der Zugriff auf die Objekte und Klassen in der DLL erfolgt ja über Strings. Also ist der Teil schon mal versionsunabhängig.
Wenn meine BPL eine andere BPL required, muss ich natürlich dafür sorgen, das die passende da ist. Man kann z.B. nicht einfach die vcl.bpl von D6 mit der von D7 tauschen. Dann knallts natürlich.
Insofern sollte die Version in diesem Fall hier, keine Rolle spielen.

[nuclearping]

Ich glaub auch, dass sie Versionsabhängig sind. Wenigstens die VCL60 wird er gegen die VCL70 tauschen wollen, dann will er nochmal neu compilen und dann ists das gleiche Problem wie vorher. ;)

Mir ist aber grad eine schmutzige Idee gekommen ... :stupid:

[Luckie]

Ich beziehe in diesem Fallmein Wissen nicht aus eigener Erfahrung, sondern weil ich meine dies mal hier im Forum von anderen Mitglieder so gehört zu haben. Und man muss es nicht unbedingt ausprobieren, es reicht die Dokumentation dazu zu konsultieren. Ein Hinweis liefert auch die Tatsache, dass die Namensgebung von den Delphi ID eigenen BPLs immer die Compiler Version beinhalten.

Zitat:

Nicht zu unterschätzender Nachteil bei der Weitergabe einer Anwendung mit Laufzeitpackages ist jedoch, dass diese sich von Delphi-Version zu Delphi-Version unterscheiden, was zu Konflikten beim Anwender führen kann.

Quelle: http://www.delphi-treff.de/delphi-ide/packages/

Zitat:

Zitat von nuclearping

Mir ist aber grad eine schmutzige Idee gekommen ... :stupid:

Keine Ferkeleien hier im Forum. :mrgreen:

[chaosben]

Ja, das hab ich auch grad gelesen, aber das bezieht sich ja zu 95% auf die Packages für Delphi. Die sind durch die Abhängigkeiten zur VCL,... natürlich versionsabhängig.

Aber so ein kleines, feines Package mit einer selbstgeschrieben Klasse drin, sollte in den meisten Delphis funktionieren. (Behaupte ich, ohne es ausprobiert zu haben)

[Luckie]

Nun ja, wenn der Delphi Compiler intern was anderes macht, als zum Beispiel der Vorgänger mit dem die BPL erstellt wurde, dann passt das schon nicht mehr zusammen.

[chaosben]

Das stimmt.

Aber was soll er denn anders machen? Die Schnittstelle zur BPL sind ja die exportierten Funktionen. Diese haben einen Namen gemäß er Delphi-Nomenklatur (diese Dinger mit Funktion@Klasse@Unit). Solange diese Nomenklatur gleich bleibt, sollte es klappen.

Aber so, werden wir das wahrscheinlich nicht klären. Entweder finden wir einen Compiler-Freak der uns eine eindeutige Antwort gibt, oder wir müssen es ausprobieren. :)

[nuclearping]

Ich probier erstmal meinen Schweinekram hier, wenn das nicht klappt, dann das mit der BPL ... ;)

Aber erstmal Pause ... Seh schonwieder den Wald vor lauter Bäumen nicht mehr. :mrgreen:

[Lossy eX]

Wäre es da nicht evtl. einfacher die DLL so zu strukturieren, dass der gleichzeitige Zugriff aus einer Anwendung funktioniert? Also keine globalen Variablen innerhalb der DLL verwenden und damit ist meistens schon ein Großteil getan.

Typischerweise kann man so etwas dann so lösen, dass die Objekte als Parameter übergeben werden. Entweder per ID oder sogar direkt den Pointer. Ich kenne jetzt die Schnittstelle nicht weswegen ich da kein wirklich sinnvolles Beispiel nennen kann. Aber ich denke an nachfolgendem Pseudo-Code dürfte das Prinzip klar werden.

Code:

net_connect(ip, port): pointer;
net_close(net: pointer);
net_read(net: pointer; ...);
net_write(net: pointer; ...);


// Das Innere der Methoden könnte dann so aussehen.
net_connect(ip, port): pointer;
begin
  Result := TNetConnection.Create(ip, port);
end;

net_close(net: pointer);
begin
  TNetConnection(net).Close;
  TNetConnection(net).Free;
end;

net_read(net: pointer; ...);
begin
  TNetConnection(net).Read;
end;

Vorteil davon wäre, falls sich was an den Klassen verändert bleiben sie kompatibel, da ja alles innerhalb der DLL abgewickelt wird. Evtl kann man dem Kompfort zu liebe dann auch noch eine Wrapperklasse erstellen. Das ist sicher etwas mehr Aufwand aber ich denke das wäre die solideste Lösung.

[hanspeter]

Zitat:

Zitat von chaosben

Ja, das hab ich auch grad gelesen, aber das bezieht sich ja zu 95% auf die Packages für Delphi. Die sind durch die Abhängigkeiten zur VCL,... natürlich versionsabhängig.

Aber so ein kleines, feines Package mit einer selbstgeschrieben Klasse drin, sollte in den meisten Delphis funktionieren. (Behaupte ich, ohne es ausprobiert zu haben)

Definitiv nein.
Alle Laufzeit BPL müssen mit der gleichen Compilerversion compiliert sein. Borland hat mit jeder Version das interne Format der
BPL geändert.
In der Regel muss auch noch mit der gleichen Sourceversion bei Abhängigkeiten compiliert werden.
Das das nicht geklappt hat, merkt erst der Anwender. (Package kann nicht geladen werden, da mit einer anderen Version von ...
compiliert wurde.) Ich habe in einem Projekt 3 Packages als Laufzeitpackages declariert.
Alle nicht durchschaubaren Abhängigkeiten haben dazu geführt, das ich etwa 60 Mbyte Laufzeitumgebung mit ausliefern mußte.

Gruß Peter

[nuclearping]

Zitat:

Zitat von Lossy eX

Wäre es da nicht evtl. einfacher die DLL so zu strukturieren, dass der gleichzeitige Zugriff aus einer Anwendung funktioniert? Also keine globalen Variablen innerhalb der DLL verwenden und damit ist meistens schon ein Großteil getan.

Typischerweise kann man so etwas dann so lösen, dass die Objekte als Parameter übergeben werden. Entweder per ID oder sogar direkt den Pointer.

Die einzige globale Variable in der DLL ist diese eine Klasse. Die kann ich aber nicht vermeiden, da die verschiedenen Funktionen darauf zurückgreifen. Ich müßte dann jedesmal in der Funktion die Klasse erstellen.

Per Pointer geht nicht, da der Benutzer ja von ausserhalb mit der Klasse arbeiten muss. Ergo muß der Compiler sie kennen und da sind wir wieder beim Problem.

Ich versuche das jetzt per ID umzusetzen, indem ich in der DLL eine TObjectList habe, die die Instanzen der Klasse mitschleppt und vor jedem Zugriff auf die Funktionen, die Klasse ausserhalb durch ihre ID die richtige Instanz setzt.

[shmia]

Hier wäre eine ActiveX-DLL wohl eine gute Lösung.
Damit umgehst du alle bisherigen Probleme.
Vorteile:
* aus vielen Prog.-sprachen verwendbar; keine Probleme mit vesch. Delphi Versionen
* man kann beliebig viele Objekte aus der DLL erzeugen, obwohl die DLL nur einmal geladen wurde
* du bietest deinen Benutzern eine definierte Schnittstelle an; die ActiveX-DLL ist selbstdokumentierend

Natürlich zu dem Preis, dass du dich erst in die Materie einarbeiten musst und manche Dinge etwas holprig von der Hand gehen. Es gibt auch Einschränkungen der Datentypen, die benützt werden können.

[nuclearping]

Hm, das klingt auch gut. Warum hat das noch keiner früher gesagt? :P Danke, werd mir das auf jeden Fall mal anschauen.

Die Lösung mit der Trennung der Instanzen in der DLL per Liste und ID funktioniert übrigens auch soweit ich das sehe.

[chaosben]

Nachtrag zum Thema BPL's: Ja, sie sind Compiler-spezifisch. Schade. :(