Hattest du das Problem nicht schonmal?
http://www.delphipraxis.net/internal...ct.php?t=70998
Ich will dir dazu nur kurz etwas erklären:
1. http://
msdn.microsoft.com/en-us/library/aa376868(VS.85).aspx
Zitat:
EWX_SHUTDOWN
...
The calling process must have the SE_SHUTDOWN_NAME privilege. For more information, see the following Remarks section.
...
Jeder Prozess hat einen Ausweiß (genannt Token), welcher Privilegien besitzt, die von einigen
WinAPI Funktionen abgefragt werden.
ExitWindowsEx fragt das Privileg SE_SHUTDOWN_NAME (ist nur ein Konstante von einem String) ab. Wenn du das Privileg aktiviert hast, dann darfst du den Rechner herunterfahren. Daher sehen die ExitWindowsEx Quelltexte auch so kompliziert aus (wegen C code).
Wenn ein Benutzer sich anmeldet, bekommt er ein solches Token. Das Token wird auf jeden neuen Prozess vererbt, der gestartet wird (Explorer ist gewöhnlich der erste).
Privilegien kann man an und abschalten. Manche
WinAPI Funktionen wollen ein aktives Privileg sehen. Manche reicht ein deaktiviertes (nur ganz wenige). Du kannst in keinem Fall nachträglich ein Privileg hinzufügen. Es ist nur möglich ein Privileg zu entfernen. Um mehr Privilegien zu bekommen, musst du ein neues Token bekommen (z.b. durch ein Logon, oder von einem Dienst).
Das SYSTEM-Token ist ein Spezialfall. Das Token gibt es immer und hat so gut, wie alle Privilegien. Einige wenige sind davon ausgenommen (können aber durch Policy, Registryeingriff, oder ein paar andere Tricks geändert werden).
2. Dienste und Desktop.
Windows benutzt sogenannte Sessions (Sitzungen), die WindowStations und diese wiederum Desktops enthalten (Paradebeispiele: winsta0 und default bzw. winlogon desktop).
Jede Sitzung ist von anderen Sitzungen fast vollständig getrennt. Du kannst keine Nachrichten mit SendMessage senden oder irgendwie direkt auf den Desktop dort zugreifen. Da SendMessage flach fällt, ist das Erzeugen eines Fensters damit auch nicht mehr möglich, denn CreateWindow und andere Funktionen arbeiten immer nur mit dem Desktop, der in derselben Session, wie dein Prozess läuft. Allerdings ist es nicht möglich die Session nachträglich zu ändern. Beim Erstellen des neuen Prozess muss man die Zielsitzung einmalig angeben - und das kann auch nur SYSTEM, welches das Privilege SE_TCB_NAME besitzt.
Und warum kann man in XP mit einem Dienst trotzdem Fenster erstellen? Ganz einfach, die Dienste laufen in derselben Sitzung (Nummer 0) wie der erste Benutzer in der Konsole. Beide haben dieselbe Sitzungsnummer und sind somit gegenseitig zugreifbar.
In Vista laufen Dienste in Sitzung 0. Der erste Benutzer läuft aber schon in Sitzung 1. Das nennt man seit jeher Session Isolation.
Dasselbe gilt wenn du unter XP einen Benutzer wechselst (FUS), dann wird nämlich eine komplette neue Sitzung angelegt. Du merkst das vielleicht, wenn der Bildschirm plötzlich für kurze Zeit ein Textmodusprompt anzeigt (VMs ändern dann ihre Fenstergröße auf Minimum, nur so.). Nach dem Benutzerwechsel kann dein Dienst nicht auf den aktuellen Bildschirm zugreifen. Er agiert nämlich (nur XP!) auf dem anderen Desktop. In Vista wurde dafür ein Kompatibilitätsanpassung eingeführt, die es erlaubt, die Nachricht des Dienstes zu sehen - dazu wird die Session umgeschaltet (Das ist auch die einzige Wirkung des "Allow Desktop" Flags in Vista). Es ist aber nicht sicher, wie lange das "Feature" bleibt (Win7 hat es vllt garnicht mehr - just a guess).
Warum sind Dienste so abgesichert worden?
Nun, die Absicherung wurde zu spät eingeführt. Das hätte schon so in Win 2000 und spätestens in XP sein sollen. Der Grund liegt darin, dass es möglich sein kann, dem Fenster/Dialog des Dienstes so fernzusteuern bzw. Befehle zu schicken, dass man Code in den Prozess einschleussen kann. Das nennt sich Shatter Attack (
http://en.wikipedia.org/wiki/Shatter_attack).