DLL in externen Prozess auslagern?

[Artjomka (Gast)]

Gibt es eine Möglichkeit eine DLL in einem externen Prozess auszulagern? 
Ich möchte, dass die DLL auch nach Beendigung der Anwendung im Speicher 
geladen bleibt.

Also eine zweite Windows EXE z.B., welche die DLL lädt (also eine Art 
"DLL-Server"). Die eigentliche Anwendung greift dann auf die DLL 
Funktionen der zweiten Anwendung zu.

Sinn und zweck ist, dass die DLL eine Verbindung (mittels COM-Port) zu 
einem externen Gerät aufbaut. Die Verbindung soll nicht geschlossen 
werden, da das Initialisieren der Verbindung jedes mal viel Zeit kostet 
(liegt daran, dass die DLL leider so programmiert ist, dass beim 
Verbinden schon diverse Initialisierungen getätigt werden).

[Peter II (Gast)]

Artjomka schrieb:
> Sinn und zweck ist, dass die DLL eine Verbindung (mittels COM-Port) zu
> einem externen Gerät aufbaut. Die Verbindung soll nicht geschlossen
> werden, da das Initialisieren der Verbindung jedes mal viel Zeit kostet
> (liegt daran, dass die DLL leider so programmiert ist, dass beim
> Verbinden schon diverse Initialisierungen getätigt werden).

dafür scheibt man einen Dienst. Die Anwendungen kommunizieren dann per 
IPC oder über Sockets mit dem Dienst.

[Artjomka (Gast)]

Dann muss ich aber für jede funktion ein interface / wrapper schreiben. 
Die DLL besteht aus einer Vielzahl von Funktionen mit unterschiedlichen 
Aufrufparametern etc.

[Peter II (Gast)]

Artjomka schrieb:
> Dann muss ich aber für jede funktion ein interface / wrapper schreiben.
> Die DLL besteht aus einer Vielzahl von Funktionen mit unterschiedlichen
> Aufrufparametern etc.

nicht zwingend. Man du kannst auch einfach die Read/Write Funktion der 
Schnittstelle rausgeben.

Oder du gibt es Objekt raus was dann alle Funktionen hat, dann hat die 
Dll nur eine Funktion.

[Rufus Τ. F. (rufus)]

Zur Interprozesskommunikation kann man auch COM* verwenden. Das ist zwar 
ein Krampf im Arsch, wenn man irgendwas debuggen will, aber es bietet 
die Möglichkeit, clientseitig sowohl mit "in-process"-Servern (DLL) als 
auch "standalone"-Servern (eigener Prozess) zu kommunizieren. COM ist 
die Grundlage der Automationsschnittstelle von Windows; die wird 
beispielsweise schon lange von Office (Word, Excel & Co.) verwendet, und 
kann aus VBScript heraus angesprochen werden. Wenn alles funktioniert, 
ist das 'ne schicke Angelegenheit. Nur ... wenn nicht alles 
funktioniert, ist das Debuggen ein Krampf im Arsch, weil Fehlermeldungen 
meistens nur "geht nicht"-Aussage-Qualität haben.


*) Nein, auch wenn serielle Schnittstellen gerne "COM" genannt werden, 
hat das nichts damit zu tun. Das ist das "Component Object Model".

[Bernd K. (prof7bit)]

Artjomka schrieb:
> dass die DLL auch nach Beendigung der Anwendung im Speicher
> geladen bleibt.

Dann beende die Anwendung einfach nicht, das wäre die simpleste Lösung 
wenn Du es eilig hast und das heute Abend noch fertig werden soll, 
schließe oder verstecke lediglich das Fenster wenn der Benutzer auf das 
"X" klickt.

Dazu gehört dann natürlich noch ein bisschen UI mit dem der Nutzer die 
Anwendung ohne Fenster immer noch erreichen, das Fenster wieder öffnen 
oder sie tatsächlich komplett beenden kann (Tray-Icon zum Beispiel), und 
natürlich das Verhindern mehrerer gleichzeitig laufender Instanzen.