C++ IPC - Integrity: Systemverbindlichkeitsstufe

tempo.1

Cadet 4th Year
Registriert
Feb. 2007
Beiträge
93
Hallo zusammen,

vor kurzem bin ich in die C++ Programmierung eingestiegen und bin leider noch nicht weit gekommen (brutaler Anfänger). Meine erste Aufgabe ist nun ein bestehendes Programm, das auf XP Basis lief, auf spätere Win Versionen upzudaten.
Grob gesagt ist das Programm so aufgebaut, dass ein Dienst im Hintergrund läuft (automatischer Start) und ein Dienst - Konfigurationstool, dass vom Benutzerkonto aus gestartet wird. Das Problem dabei ist nun: Windows Integrity Mechanism Design.
Ein Prozess niedriger Ordnung (Konfigurationstool) darf nicht mit dem Prozess höherer Ordnung (Der Dienst) kommunizieren.
Habt ihr Profis da draußen evtl. einen Lösungsansatz oder eine Idee, wie ich nun eine PostThreadMessage von dem KonfigTool an den Dienst schicken kann?
GetLastError() erzeugt immer die Meldung: ERROR_INVALID_THREAD_ID.

Schonmal Danke im voraus...
 
Super, erstmal vielen Dank.

Das ChangeWindowMessageFilterEx müsste das sein, was ich suchte.
Leider muss ich dafür das Dienste Projekt erst von VS6 auf VS2010 updaten...
Das wollte ich eigentlich vermeiden, aber es scheint wohl der einzige Weg zu sein...

Gruß
 
Hallo,

Upgraden:
Wenn ich das VS6 - Projekt in VS10 öffnen will, kommen ein paar Fehler, wie Bsp., dass er die fstream.h nicht findet. Wenn ich das *.h entferne, findets der Compiler. Dann fehlt noch hier und dort mal das using namespace std, usw. Lauter kleinkram...

Wenn ich die Funktion vom Konfigurationsprozess aufrufen möchte, habe ich ein Problem mit dem ersten Parameter. Der Dienst hat kein Window Handler, woraufhin ich kein hWnd übergeben kann.
Folglich muss ich die ChangeWindowMessageFilter Funktion benutzen, um eine Message dem Filter hinzuzufügen. Diese jedoch kann ich nur im Dienst aufrufen, oder?

Gruß
 
Das mit dem fstream.h na ja, in ISO C++ sollte sowieso nur fstream heißen, wie der Rest vom Kram. Dann viel Spaß mit dem Kleinkram. :)

OK, dann ist klar, dass du nur ChangeWindowMessageFilter verwenden kannst. Du hast aber den Satz in der MSDN ganz oben schon gelesen?! Sonst gehts mit Windows 8 nochmal von vorne los...
 
Servuce,

Ich glaub, als das Programm erstellt worden ist, gabs noch gar keine ISO :D

Den Satz habe ich gelesen. Leider. Ich hoffe, dass es, wenn es soweit ist, einen Ersatz geben wird.
Ein Service ist ja dazu da Informationen zu liefern.
Also: "Horsch, geb ma mol a Bier"
Antwort: "Da hosch"
Bei einem SQL Server oder ähnlichem ist dass ja auch nichts anderes. Server und Konfigurationsmanager.

Ein Alternativplan existiert auch bereits: Ich erstelle einfach ein leeres "fakewindow" und hoffe das funktioniert.

Vielen Dank für deine Hilfe, Gruß
 
Servus,

nachdem ich mich nun in den Quellcode des Dienstes eingearbeitet und einen solchen Message Filter eingebaut habe, tuts immernoch nicht.

Lange Zeit später und eine LogFileForMessages Klasse reicher habe ich entdeckt, dass die ID's unterschiedlich sind. Also beim RegisterWindowMessage bekommt der Dienst beim selben Namen eine andere MessageID als die Applikation. Das senden einer PostThreadMessage klappt dann, jedoch kommt nie etwas an. Das kommt dann wohl offenbar von der User Interface Privilege Isolation. Windows ab Version Vista untersagt die Kommunikation mit Diensten aus anderen Sessions (Desktops) und auch mit Diensten, die höher privilegiert sind.
Der Namensstring und die Message wird nun beim RegisterWindowMessage in einer Atom Table abgelegt. Es muss doch folglich möglich sein aus einer Globalen Atom Table die MessageID raus zubekommen und aufgrund dieser dann einen RegisterWindowMessage mit der ID zu öffnen.

So, lieg ich da nun richtig, oder habe ich irgendwas übersehen? Meint ihr, dass es mit dem oder einem anderen Trick möglich ist, die Message doch zu versenden, oder muss ich eine andere IPC Methode, wie Named Pipes verwenden, oder taucht da ein ähnlicher Fehler auf?

Bin Dankbar für jede Hilfe, Gruß
 
http://en.wikipedia.org/wiki/Windows_service
Interresant, da steht ein Hinweis drin:
Although typically services do not have a user interface, developers can add forms and other UI components. In this case, the "Allow service to interact with desktop" should be checked on the Logon tab in the Service properties dialog (though care should be taken with this approach as this can cause a security risk since any logged in user would be able to interact with the service
Hast du das bedacht, möglicherweise funktioniert es deswegen nicht.
 
Zurück
Oben