DLL doppelt nutzen

[norwegen60]

Hallo,

ich habe eine Treiber-DLL die per RS232 auf ein Messgerät zugreift. Die Anworten des Geräts werden per CallBack an die übergeordnete EXE zurück gegeben.

Ist es möglich, aus einer zweiten EXE festzustellen, ob diese DLL bereits geladen ist und sie auch von dieser zweiten EXE aus zu nutzen?

Mögliches Konflikt-Potential ist kein Problem, da die zweite Anwendung keine Settings vornimmt sondern nur die aktuelle angezeigten Werte auch mitbekommen soll.

Eigenständiges Laden der DLL ist natürlich keine Lösung da der COM besetzt wäre.

Grüße
Gerd

[Uwe Raabe]

Obwohl die DLL nur einmal geladen wird, wenn sie von zwei Prozessen benutz wird, verwaltet sie für jeden Prozess einen eigenen Datenbereich. Heißt, der Code ist zwar nur einmal da, aber z.B. alle globalen Variablen gibt es für jeden Prozess separat.

Selbst wenn man das irgendwie lösen könnte, steht da immer noch das Problem der gleichzeitigen Verwendung. So könnten beide Prozesse gleichzeitig Daten über den COM-Port lesen oder schreiben. Ich glaube kaum, dass das gut gehen kann.

Ohne genaue Kenntnis des Aufbaus und der Arbeitsweise der DLL kann man aber auch kaum valide Aussagen machen. Eventuell muss man einen Wrapper-Service um die DLL herum bauen, die das alles sauber für mehrere Clients verarbeitet.

[Incocnito]

Wenn zwei Anwendungen die gleiche DLL benutzen, heißt es quasi nur, dass die den gleichen Programmablauf benutzen.
Jeder mit seinem eigene Head, Cache, RAM, whatever.
Für sowas bliebe dir nur eine eigene EXE zu bauen, die mit dem COM spricht und Aufrufe des COM dann (beispielsweise per REST) mit der Gemeinschaft teilt. Das wäre in deinem Fall zumindest mit höchster Wahrscheinlichkeit das Mittel zur Wahl.

LG Incocnito
Uwe war schneller 😂

[norwegen60]

Vielen Dank für die schnellen Antworten. Ich hatte geahnt, dass es nicht geht, aber oft gibt es eben doch ein Hintertürchen.

Das Konflikt-Potential ist mir bewusst. Deshalb hatte ich es extra erwähnt.

Ein Wrapper oder eine anderst geartete Zwischenschicht ist nicht möglich, da die eigentliche Anwendung existiert und nicht angefasst werden soll.

Ziel war es, parallel zu dieser Erstanwendung ein Logger zu hängen, der bei bestimmten Grenzwerten/Ereignissen anfängt die Messdaten zu loggen. Wenn man die Anwendung oder DLL ändern könnte, könnte man das direkt dort implementieren. Schön wäre es eben gewesen, ich könnte die Log.exe wie ein Snifferkabel parallel hängen.

[himitsu]

Du kannst schauen, ob der COM Port frei (du ihn also öffnen kannst) ,
dann wäre die DLL nicht geladen (wenn sie auf den Port zugreift)

Du könntest dir in der EXE selber ein globales "Flag" setzen, wenn dort die DLL geladen wird und das prüfen.
CreateMutex

Oder du müsstest eben die anderen Prozesse durchgehen, dir da die DLLs auflisten und nachsehn
EnumProcesses OpenProcess EnumProcessModules GetModuleFileNameEx

[add]
Du könntest auch die TreiberDLL umgenennen,
eine eigene DLL mit den selben öffentlichen Schnittstellen erstellen, welche den Zugriff zur eigentlichen DLL durchreicht.
Und während die Anwendung nicht auf die DLL zugreift, könntest du in deiner DLL oder via IPC zur LoggerEXE die Grenzwerte abfragen/prüfen.

Oder in der NeuenDLL der LogggerEXE mitteilen, wann sie starten kann oder sich beenden soll.
-> wird das Programm gestartet, läd deine DLL (eigentlich die TreiberDLL), dann dem Logger sagen "aufhören" und deine TreiberDLL freigeben, damit das Programm drauf zugreifen kann.
-> wird das Programm wieder beendet (deine DLL entladen), dann "hey Logger, du kannst wieder"
-> und ansonsten einfach nur alle Funktionsaufrufe/Callbacks zwischen TreiberDLL und Programm durchreichen/weiterleiten

[Uwe Raabe]

Zitat:

Zitat von norwegen60 (Beitrag 1499218)

Schön wäre es eben gewesen, ich könnte die Log.exe wie ein Snifferkabel parallel hängen.

Sowas habe ich schon mal mit Virtuellen Com-Ports realisiert. Man legt zwei virtuelle Ports an und verbindet die mit einem virtuellen Null-Modem Kabel. Die Applikation wird auf den einen virtuellen Port eingestellt und der Sniffer lauscht auf dem anderen und schleift alles auf den realen Port weiter (und umgekehrt). Es gibt aber auch schon fertige Sniffer-Tools für diesen Zweck.

[TBx]

Wenn ich Dich richtig verstanden habe, dann ist das ein typisches Szenario für einen Proxy.

In dem Fall baust Du Dir eine DLL mit den gleichen öffentlichen Schnittstellen wie die bestehende. Deine DLL macht dann nichts anderes, als alle Aufrufe an die ursprüngliche DLL weiter zu leiten. Dann kannst Du alle Daten, die durch Deine Proxy-DLL laufen beliebig mitloggen.

Wenn es zeitkritisch ist, würde ich den ganzen Datenstrom mitloggen und separat auswerten.

Dann brauchst Du Deine DLL dem Programm nur noch unterzujubeln.

[zeras]

Wenn du eine weitere serielle Schnittstelle an dem Rechner hast, kannst du das auch hardwareseitig lösen. Dann einfach den RX Port der ersten Schnittstelle mit dem RX Port der 2. Schnittstelle verbinden. Wenn dann der Rechner schnell genug ist und keine Daten verliert, kannst du mit der 2. Schnittstelle alles mitlesen. Es darf dann aber kein Handshake benötigt werden. Das musst du halt sehen, was da an Daten ankommt.
Ist ähnlich den oben beschriebenen, hier nur auf Hardwareebene.
Habe ich auch schon einmal realisiert.