Ich bin dabei nen Dienst zu schreiben und möchte gern zum einen die Exe so starten, das sie tut was sie soll.

Desweiteren möchte ich gern die exe mit einen Parameter starten, der dann eine Graphische oberfläche aufzeigt, und sich mit dem laufenden Prozess verbindet und diesen steuern kann. Zum Beispiel laufenden Jobs unterbricht oder globale Einstellungen verändern, usw.

Meine Idee war das ganze mit Callback-Funktionen durchzufuehren, aber irgendwie weiß ich nicht wie ich da anfangen soll. Kann mir da vllt jemand helfen?

Vielen Dank

Mfg Marco

Edit: Titel angepasst für mehr ausdruck.

Und wie soll man des ganze dann unter Linux/Unix machen??

Da mein ich es auch schon gesehen zu haben, jetzt nicht direkt mit Graphik-Oberfläche aber mit Kommandos.

Mfg Marco

Grüssli

Und dieses Programm möchte ich einfach von "extern" steuern, wie, ob über Graphik oder über Text-Kommandos ist nicht das wichtige, es ist die Frage ob es geht und wie man anfängt.

Also nur nochmal zur verdeutlichung, sollte es aus dem ersten Thread nicht verständlich gewesen sein, ich will "nur" die stelle wissen, wie ich mit einen eigenen Prozess "reden" kann und das ganze am besten über Standard-C++.

Mfg Marco

Also nur nochmal zur verdeutlichung, sollte es aus dem ersten Thread nicht verständlich gewesen sein, ich will "nur" die stelle wissen, wie ich mit einen eigenen Prozess "reden" kann und das ganze am besten über Standard-C++.

Naja, Standard C++ hat auch keine Kenntnisse über Prozesse. Also musst du auch auf System spezifische Funktionen zurückgreifen. Vielleicht wäre dir da auch Boost.Interprocess eine Hilfe, sofern beide Prozesse die deinigen sind

Grüssli

Und über Callbacks geht sowas nicht? Habs mir so gedacht das sich der 2. Aufruf (weiß es ja über CreateMutex) in nen Callback-Interface einträgt und sich das ganze dann darüber steuert.

Mfg Marco

Und über Callbacks geht sowas nicht? Habs mir so gedacht das sich der 2. Aufruf (weiß es ja über CreateMutex) in nen Callback-Interface einträgt und sich das ganze dann darüber steuert.

Mir wäre zumindest nicht bekannt, dass man aus einem anderen Prozess heraus eine Funktion aufrufen kann. Das würde ich auch als ziemliches Sicherheitsleck ansehen.

Du kannst gerne mal diesen Artikel in der MSDN durchlesen:
http://msdn.microsoft.com/en-us/library/aa365574.aspx

Der sollte alle Fragen zur Kommunikation zwischen Prozessen auf Windows beantworten oder zumindest die meisten. Falls danach noch weitere bestehen, kannst ja im WinAPI Unterforum nachfragen gehen.

Grüssli

Marc-O schrieb:

Und über Callbacks geht sowas nicht? Habs mir so gedacht das sich der 2. Aufruf (weiß es ja über CreateMutex) in nen Callback-Interface einträgt und sich das ganze dann darüber steuert.

Mir wäre zumindest nicht bekannt, dass man aus einem anderen Prozess heraus eine Funktion aufrufen kann. Das würde ich auch als ziemliches Sicherheitsleck ansehen.

Du kannst gerne mal diesen Artikel in der MSDN durchlesen:
http://msdn.microsoft.com/en-us/library/aa365574.aspx

Der sollte alle Fragen zur Kommunikation zwischen Prozessen auf Windows beantworten oder zumindest die meisten. Falls danach noch weitere bestehen, kannst ja im WinAPI Unterforum nachfragen gehen.

Grüssli

Hey vielen dank, die Website hilfe Aber sie hat mir auch einen Weg gezeigt der für andere Betriebssysteme geht nicht nur für Windows und das sind Named Pipes.

Für andere die sowas auch suchen hier noch ein Link:
Pipe

Da steht auch ein bischen C-Code zum testen, werd denn jetzt mal ausprobieren.

Mfg Marco

• Shared Memory

Nich die eleganteste Art, aber Du kannst einen benamten Speicherblock allozieren, auf den Du von Deinem Daemon Prozess (der ohne GUI) lesend pollst und in den Du von Deinen GUI Prozess aus schreibst. So könntest Du ein Kommandoprotokoll festlegen und auf Änderungen des Speichers entsprechend reagieren.

• Festgelegte Dateien

Du kannst statt gemeinsam genutztem RAM natürlich auch eine Datei auf der Festplatte benutzen, die Du entsprechend schreibst und liest. Ist halt etwas langsamer, dafür nicht so eingeschränkt was die Festlegung auf Speicherplatz angeht.

• TCP

Du kannst selbstverständlich auch einen Server aufsetzen. Als Protokoll bietet sich TCP an, den Port kannst Du dann festlegen. Damit kannst Du selbstverständlich auch auf lokale Server zugreifen. Der Vorteil bei dieser Variante ist, dass Du Deinen Daemon Prozess auch leicht über's Netzwerk steuern kannst.

Vielleicht konnte ich Dich ja bißchen inspirieren