Hallo zusammen, ich habe mich nun etwas durchs Forum gelesen zu sämtlichen Sachen mit DLL , Interprozesskommunikation und Multihreading. Wirklich schlauer bin ich noch nicht, eher verunsicherter dank solcher Wörter wie "DLL-Hell" :-D Folgendes Szenario habe ich. Es gibt eine Anwendungsdatei die Daten verarbeitet und per TCP/IP an eine Oberfläche weiterleitet. Zusätzlich muss es Daten austauschen mit einem zweiten Programm welches über verschiedene HW Peripherien Daten erhält. Das Oberflächen Programm können wir einfach mal ignorieren. Im Moment ist es so gelöst das beide Programme eine Exe sind und über ein Virutalles Memmoryfile sprechen. Der Zugriff dadrauf wird per Global Mutex geregelt. Da die Programme aber nicht wirklich alleine laufen müssen wäre nun der Gedanke die Programme zusammen zuführen. Es muss einzig und allein möglich sein, den einen Teil ohne den anderen Teil auszutauschen. Deswegen war auch früher der Gedanke der zweiten Exe entstanden. Da ich nun die ersten Versuche mit einer DLL gemacht habe scheint es mir garnicht so unvernünftig eine DLL zu nehmen. Damit könnte ich sogar auf die Glboale Mutex und das Virtuelle File verzichten und einfach ein großes Array deklarieren und dieses in der DLL Freigeben bzw. Funktionen für den Zugriff schaffen. In der Exe die eine DLL werden soll gibt es kein malloc oder der gleichen, alle Variablen/Arrays/Strukturen werden fest deklariert. Es werden dort mehrere Threads mit hoher Priorität erstellt. Nun kommen ein paar Verständnisfragen: - Funktionen und Globale Variablen die ich nicht per DLLImport / Export Prefix deklariere können im anderen Programm nicht gesehen/benutzt/manipuliert werden, richtig? - Speicherprobleme kan es nicht geben?! Probleme mit Heap oder Stack in irgendeiner weise? - Threads können mit hoher Priorität erstellt werden oder hängen sie in irgendeinerweise an der Exe die sie erzeugt haben? - Ich hatte was von Createthread Problem gelesen aber es nicht ganz verstanden. Was ist dort das Problem? Kann das bei mir auftretten? Die Exe ruft eine Init Funktion der DLL auf, die DLL erzeugt die Tasks und diese laufen endlos im Hintergrund bis das Haupt-Exe-Programm geschlossen wird. Die Funktionalität, dass die DLL von mehreren Programmen genutzt wird benötige ich garnicht. Ich möchte nur keine Statisch gelinkte Bibliothek haben, um dass Programm austauschen zu können!
Josef schrieb: > Da ich nun die ersten Versuche mit einer DLL gemacht habe scheint es mir > garnicht so unvernünftig eine DLL zu nehmen. Damit könnte ich sogar auf > die Glboale Mutex und das Virtuelle File verzichten und einfach ein > großes Array deklarieren und dieses in der DLL Freigeben bzw. Funktionen > für den Zugriff schaffen. Das funktioniert nicht; der in einer DLL verwaltete Speicher gehört dem aufrufenden Prozess, nicht der DLL. Und somit hat jeder Deiner zwei Prozesse seinen eigenen Speicherblock, der nichts mit dem anderen zu tun hat.
Rufus Τ. Firefly schrieb: > Das funktioniert nicht; der in einer DLL verwaltete Speicher gehört dem > aufrufenden Prozess, nicht der DLL. Und somit hat jeder Deiner zwei > Prozesse seinen eigenen Speicherblock, der nichts mit dem anderen zu tun > hat. kann sein muss aber nicht. Man kann unter windows einer DLL über pragmas mitteilen das globale Variablen in der DLL zwischen verschienden anwendungen geshared werden. Dann ist die Variabel in der DLL in alle Anwendungen identisch. Hatte ich mal für eine spezialaufgabe gebraucht und fand es recht pratisch. http://msdn.microsoft.com/de-de/library/h90dkhs0%28v=vs.80%29.aspx
Oh da habe ich mich etwas falsch ausgedrückt. Das eine Exe Programm würde als DLL bei dem anderen eingebunden. Also Anstatt die Kommunikation "Exe - Virtual File - EXE" würde dann "EXE - Global Array - DLL" stattfinden. Und das Global Array mit dllexport/import freigeben. Aber verstehe ich dass nun richtig, dass wenn ein anderes Programm die DLL Wieder aufruft dort die globalen Variablen der DLL wieder neu erstellt werden und nicht mit Inhalt von dem anderen Aufruf gefüllt sind?! Das nicht expliziet angegeben Globale Variablen/Funktionen der DLL in der Exe zur Verfügung stehen wollte ich auch eher vermeiden und nicht extra schaffen, aber besten Dank für den Hinweis dass so etwas möglich ist.
Zusatz: Wird die Echtzeitfähigkeit in irgendeiner Weise beeinträchtigt wenn man dass ganze als DLL startet?
Damit meinte ich nur, daß das Starten eines Prozesses wohl etwas schneller gehen kann, wenn alles in einer EXE steht; bei DLLs muß ja mehr gemacht gemacht werden. (Kann auch andersrum aussehen, wenn eine DLL bereits im Speicher ist beim Starten der EXE.) Zur Laufzeit sollte man keinen Unterschied mehr spüren (eine evtl. Indirektion mehr ist bestenfalls meßbar, wenn man sehr genau hinschaut - wenn überhaupt). "Echtzeitfähigkeit" hängt eher von anderen Dingen ab, z.B. ob angesprungener Code erst nachgeladen werden muß etc. und weniger davon, ob er in einer DLL steht oder in einer EXE.
Ah Ok! Ich hatte schon die Befürchtung das der loadlibary Befehl den kompletten Shedular aufs Ohr legt oder sonstige spielereien macht. Klaus Wachtler schrieb: > "Echtzeitfähigkeit" hängt eher von anderen Dingen ab, z.B. ob > angesprungener Code erst nachgeladen werden muß etc. und weniger davon, > ob er in einer DLL steht oder in einer EXE. Gut, dass liegt aber nicht in meiner Hand bzw kann doch auch bei EXE und DLL auftretten. Die DLL macht bei mir auch nicht mehr als eine EXE. das Automatische Starten bzw diese Treiberfunktionen sind nicht vorgesehen, es ist nur eine eigene Initfunktion vorgesehen, mit der ich meine Tasks in der DLL Starte und der Programmablauf durchläuft. Im Moment habe ich aber auch dass Problem, dass eine andere Exe (Win CE Consolen Programm= nach einem Druck auf das X zwar geschlossen wird aber im Prozessviewer immer noch (nach Refresh) angezeigt wird. Also im Hintergrund definitiv weiter läuft. Wie kann ich sowas abfangen?! Was passiert da? Kann ich den Klick auf das X erkennen und eine Aufräumfunktion starten?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.