FindWindow in einem Service unter Vista

[Shark99]

Poste bitte den Code, wenn du wieder zu Hause bist.

[Fridolin Walther]

Die Lösung für Dein Problem:
Benutz einen anderen IPC Mechanismus. Mit Window Messages rumspielen in nem Service ist nicht nur relativ dämlich (weil Du auf Deine eigene Terminal Session begrenzt bist) sondern kann durchaus auch die ein oder andere Gefahr in sich bergen. Sollte Dein Service übrigens ein Window erzeugen um Window Messages zu empfangen, darf ich Dir an dieser Stelle sogar zu Deinem ersten exploitbaren Sicherheitsproblem gratulieren .

Das Problem wieso Dein FindWindow innerhalb eines Service unter Vista nicht funktioniert, ist recht einfach. Anders als bei XP rennen Services unter Vista in einer eigenen Terminal Service Session. Da alle Fenster und Fenster Handles nur für die jeweilige Session gelten in der sie auch erstellt wurden, findet Dein Service (der in Session 0 läuft) keinerlei Fenster von Applikationen die Du als Nutzer gestartet hast (welche nämlich in Session 1 laufen). Selbst wenn du übrigens ein Fenster Handle bekommen solltest, wäre es unmöglich von Session 0 heraus eine Message an Session 1 zu schicken.

Ich persönlich würde Dir zur Kommunikation Named Pipes empfehlen, da Du Dir um die Synchronisation weit weniger Gedanken machen muss als z.B. bei Memory Mapped Files. Entsprechende Beispiele findest Du hier im Board zu genüge.

Solltest Du mehr über die Hintergründe der Änderung wissen möchten, empfehle ich Google mit "vista session 0 isolation" und "shatter attacks" als Suchbegriffe.

[Tyrael Y.]

Da springe ich doch mal schnell in den Thread rein und schreibe
"ich bin wie immer in diesem Fall für TCP/IP, funktioniert immer und wird auch immer funktionieren"


...mal gucken in wie vielen anderen Threads, die das Thema "Window Messages /Services /Vista" behandeln ich noch diesen Satz schreiben werde...ich sollte mir einen Counter dafür anlegen

[nicodex]

Zitat von Tyrael Y.:

"ich bin wie immer in diesem Fall für TCP/IP, funktioniert immer und wird auch immer funktionieren"

"Immer" ist relativ. Named Pipes habe auch den Vorteil, dass sie einen Sicherheitskontext mitbringen.

[Bernhard Geyer]

Zitat von Tyrael Y.:

"ich bin wie immer in diesem Fall für TCP/IP, funktioniert immer und wird auch immer funktionieren"

Immer na ja: Wenn der Listener beim öffnen des TCP/IP-Port nur lokale verbindungen zu lässst dürften 99,9% der Firewalls still halten. Ansonsten gibt es genügend Firewalls die das (teilweise ohne Meldung) die Port-Öffnung blocken.

[Tyrael Y.]

Zitat von nicodex:

"Immer" ist relativ. Named Pipes habe auch den Vorteil, dass sie einen Sicherheitskontext mitbringen.

Wir reden hier über Interprozesskommunikation in diesem Fall wird TCP/IP immer funktionieren.
Wer weiss wie lange Named Pipes noch funktionieren werden. Da kann Microsoft auf die Idee kommen die nicht mehr zu unterstützen. Wie könnten sie aber auf die Idee kommen TCP/IP nicht mehr zu unterstützen?

[nicodex]

Zitat von Tyrael Y.:

Wer weiss wie lange Named Pipes noch funktionieren werden. Da kann Microsoft auf die Idee kommen die nicht mehr zu unterstützen. Wie könnten sie aber auf die Idee kommen TCP/IP nicht mehr zu unterstützen?

Sie könnten auch auf die Idee kommen, TCP/IP abzuschaffen.
Bei Named Pipes hast du als Entwickler den Vorteil, dass es der Implementation überlassen bleibt, welches Transportprotokoll verwendet wird (und "Lokales RPC" dürfte schneller sein, als deine TCP/IP-Verbindung).
Wie Bernhard Geyer bereits schrieb, ist eher die Praxis das Problem (Software-Firewalls).

[Tyrael Y.]

Zitat von nicodex:

Wie Bernhard Geyer bereits schrieb, ist eher die Praxis das Problem (Software-Firewalls).

Seit wann blockt man eingehende Verbindungen von 127.0.0.1 (localhost) oO?

[nicodex]

Zitat von Tyrael Y.:

Seit wann blockt man eingehende Verbindungen von 127.0.0.1 (localhost) oO?

Das musst du unsere Kunden fragen

[Luckie]

Zitat von Tyrael Y.:

Wer weiss wie lange Named Pipes noch funktionieren werden. Da kann Microsoft auf die Idee kommen die nicht mehr zu unterstützen.

Also wenn du so anfängst zu argumentieren, dann solltest du besser keine Programme für Windows mehr schreiben.