DLL in externen Prozess auslagern?

Artjomka Gast #4340975
Lesenswert?
• ▲
▼ 
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).
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Peter II Gast #4340995
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peter II Gast #4341221
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Rufus Τ. F. Persönliche Seite #4341233
Lesenswert?
• ▲
▼ 
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".
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Bernd K. #4341246
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren