Hi,

ich probiere gerade mit UAC unter Vista rum und habe dazu ein Programm von Aleksander Oven, zu finden hier, runtergeladen und angepaßt.
Angepaßt in dem Sinn, dass ich zum Testen eine Datei-Kopierfuntion eingebaut habe, die auf einem TForm (erzeugt und aufgerufen aus der COM dll) eine ProgressBar und ein wenig Status Texte ausgibt.

Dies funktioniert erstaunlicherweise wunderbar, die Datei wird im Elevated Modus auch in normalerweise nicht erlaubte Systemordner hineinkopiert nur der besagte Statusdialog, ist nicht themed. Das Hauptfenster, das letztendlich der Aufrufer dieses COM Objektes ist, ist hingegen themed (Siehe Bild im Anhang).

Wenn ich in dem Kopier-Statusfenster diese Anweisung einfüge chkThemed.Checked := IsThemeActive; dann ist die Checkbox sehrwohl abgehakt, also sollte es eigentlich funktionieren.

Es hilft übrigens nichts, wenn ich ein Vista or XP Manifest mit in die COM Dll als Resource einbinden. Ich frage mich nur, wie Microsoft dies mit den diversen Dialogen macht, die per Elevation aufgerufen werden.

Deine COM-DLL wird von einen hochprivilegierten Prozess gestartet, mit dem Admintoken ausgeführt und als COM-Server initialisiert. Soweit ich weiß, haben diese SYSTEM Prozesse kein Thememanifest, da es ein Sicherheitsproblem ist.

Die einzige Lösung die ich mir vorstellen könnte, ist dass du den FortschrittsDialog schon vorab in deinem eigenen Prozess baust und dann die COM Methode aufrufst, welche dir Fortschrittsnachrichten sendet. COM hat ne Menge Möglichkeiten Nachrichten zu versenden.

Danke Christian für deine Antwort.

was ich aber dabei nicht verstehe ist, dass es in Vista zig Dialoge gibt, die so funktionieren: Also erstmal einen Button mit Shield-Symbol anbieten und anschließend dann einen neuen Dialog starten, der im Elevated Modus läuft und der aber sehrwohl themed ist.

Gutes Beispiel ist das Verändern der Uhrzeit. Wie machen die das dann bei den Windows Porgrammen selbst?

Der Uhrzeitdialog wird auch nur als normaler Dialog gestartet. Bevor der Dialog angezeigt wird, wird eben ein Elevated COM Object angefordert, was die UAC auf den Plan ruft. Bei Erfolg wird der Dialog dargestellt. Erst wenn der Benutzer auf OK klickt, werden die im Dialog gesammelten Daten an eine Methode im COM Objekt übergeben. Die Methode ändert dann die Einstellung.

Man kann es gut mit diesem Programm sehen:
http://technet.microsoft.com/de-de/sysinternals/bb896653(en-us).aspx

Wenn du es als Admin startest, dann kannst du folgendes sehen:

1. Uhrzeitdialog öffnen -> Explorer.exe startet rundll32.exe
2. Adminrechte anfordern für Uhrzeit ändern ->
dllhost.exe wird in wininit.exe/services.exe/svchost.exe (ein Dienst in einem Pool macht die Aufgabe) gestartet

Eigenschaften des Prozesses
Dllhost liegt in C:\Windows\system32\DllHost.exe

gestartet wurde es über
C:\Windows\system32\DllHost.exe /Processid:{9DF523B0-A6C0-4EA9-B5F1-F4565C3AC8B8}

Die GUID ist die ID des timedate.cpl Systemsteuerungs COM Moduls. Darin liegt ein COM Objekt, welches die Uhrzeit ändert. Es stellt aber keine GUI dar. Die GUI liegt zwar auch darin, aber eben nicht im COM.

Wenn du dein Formular in der COM Methode ausführst, dann wird es innerhalb von DllHost.exe dargestellt. Diese EXE hat aber garkein Theme. Ergo, das Formular auch nicht.

---
Mit dem Zielbutton rechts in der Process Explorer Toolbar, kannst du übrigens überprüfen, welches Fenster zu welchem Prozess gehört.

Noch was:

Schau dir die Performance Eigenschaften von rundll32.exe und dllhost.exe an. Insbesondere die Anzahl der Handles. Du siehst einen beträchtlichen Unterschied. rundll32.exe mit der GUI (führt timedate.cpl aus) hat mehr GDI und User Handles als die andere EXE. Das lässt den Schluss zu, dass ein Prozess mehr Darstellen muss als der andere.

Christian,

was mich noch interessieren würde: Wäre es denn möglich meiner CopyFile Routine einen Pointer auf eine Methode oder dergleichen aus dem Hauptprogramm mitzugeben um diese Methode diese dann in dem COM Server einfach aufzurufen?

Oder ist dies wegen diesem Out-Of-Process Server nicht möglich auf den "Speicher" des rufenden Programmes zuzugreifen?

Zitat von Roaster:

Oder ist dies wegen diesem Out-Of-Process Server nicht möglich auf den "Speicher" des rufenden Programmes zuzugreifen?

Bestimmt nicht unmöglich, da dieser COM-Server ja im Admin-Mode läuft, aber warum nutzt Du nicht einfach ein CallBack-Interface?

......

Pointer gehen ohne Marshalling über Prozessgrenzen überhaupt nicht. Was du aber machen kannst, ist ein COM-Objekt als CallbackInterface zu deklarieren und dann darüber die Clientmethoden aufzurufen.
Ein Callbackinterface ist eine normale COM Klasse, die jedoch nicht beim Server implementiert wird, sondern beim Client. Du leitest ein COM Objekt von diesem Interface ab, implementierst dort drin eine Callbackmethode und übergibst dann das Interface an deine COM Methoden im Server, in der du Dateien kopierst. Dort drin kannst du dann die COM-Callback Methode einfach aufrufen. COM erledigt den Rest. Natürlich muss dieses Interface dem Server + Client bekannt sein und nur COM Bekannte Datentypen enthalten.

Ähh sorry, you lost me

ich werd's morgen mal versuchen das umzusetzen. Vielen Dank aber schon mal für den Vorschlag.
Wie kommt man denn auf so eine Idee überhaupt. Das muss man ja studiert haben

Ist in der deiner Jedi APILib aus der Sig ein Beispiel hierzu drin? Wohl eher nicht da es sich eigentlich um ein COM Thema handelt, oder?

Die JWSCL enthält das Thema Vista Elevation mit COM. Aber was du haben willst ist eine COM Grundlage, die man in jedem COM Buch nachlesen kann. Ich persönlich habe Andread Kosch COM/DCOM/COM+ mit Delphi gelesen worin das alles gut beschrieben wird.