Probleme: TInifile und Vista

[Graffi]

Hallo,

sorry, Vista treibt mich langsam zum Wahnsinn:

In meiner Anwendung lese ich mehrere INI-Datei aus, was aber nur über "Ausführen als Administrator" korrekt funktioniert. Ohne Adminrechte bleiben die Ergebnisse immer leer.

Hier einmal meine stinknormale Routine. (Anm.: "CurrentDir" und "CurrentInifile" zeigen mit/ohne Admin selbigen Inhalt an, zb: "C:\program files\ich\" und "main" ... kann also nicht das Problem sein):

Delphi-Quellcode:

function ReadIniStr(Eintrag: string) : string;
var
  MyIniFile: TIniFile;
begin
  MyIniFile := TIniFile.Create(CurrentDir+CurrentInifile+'.ini');
  with MyIniFile do
  begin
    Result := Readstring(currentsection,eintrag,'');
  end;
  MyIniFile.Free;
end;

Kann mir evtl. jemand sagen, was Vista nun mal wieder von mir möchte?? :wall:

Gruss, Ralf

[Luckie]

CurrentDir dürfte dir zufälligerweise das Anwendungsverzeichnis liefern, weil dies das aktuelle Verzeichnis nach dem Start ist. Microsoft war bei Vista endlich mal so rigoros und hat das erstellen von Dateien im Programmverzeichnis verboten. (Einige Programmierer haben selbst nach 20 Jahren NT immer noch nicht gemerkt, dass Windows mittlerweile ein Mehrbenutzerbetriebssystem ist unter dem es auch Benutzer mit eingeschränkten Rechten gibt. Was dazu geführt hat, dass der Benutzer doch wieder als Administrator arbeitet, weil sonst diese Programme nicht liefen.)

Schreib die Ini-Dateien dort hin, wo sie in gehören, in das Verzeichnis des Benutzers:
http://www.michael-puff.de/Developer.../HOMEDIR.shtml

[Graffi]

[quote="Luckie"]CurrentDir dürfte dir zufälligerweise das Anwendungsverzeichnis liefern, weil dies das aktuelle Verzeichnis nach dem Start ist./quote]

Nein, das sind meine internen Variablennamen:

Delphi-Quellcode:

Var CurrentIniFile : string;
    CurrentSection : string;
    CurrentDir     : string;

Wie schon geschrieben, die Inhalte dieser Variablen sind -unabhängig von den Zugriffsrechten- vollig identisch.

Die ganze Abwicklung über z.B. %Home% halte ich nicht unbedingt für sinnvoll, da z.B. "Registrationsdaten" nur einmalig eingegeben werden sollten ...

[Nuclear-Ping]

So wie ich es verstanden habe ist es unter Vista eben nicht mehr so, dass Registrierungsdaten nur einmal gespeichert werden und dann von jedem Benutzerkonto aus abgerufen werden können. Stichpunkt "Virtualization".

Schau mal auf http://msdn2.microsoft.com/en-us/library/aa905330.aspx

[Luckie]

Und wie kommt der Wert von CurrebtDir zu stande?

[Graffi]

Wie schon geschrieben, sind die folgenden Variablen VON MIR:

Delphi-Quellcode:

Var CurrentIniFile : string;
    CurrentSection : string;
    CurrentDir     : string;

Diese setze ich erst in meiner Anwendung.

Probleme macht diese Routine:

Delphi-Quellcode:

function ReadIniStr(Eintrag: string) : string;
var
  MyIniFile: TIniFile;
begin
  MyIniFile := TIniFile.Create(CurrentDir+CurrentInifile+'.ini');
  with MyIniFile do
  begin
    Result := Readstring(currentsection,eintrag,'');
  end;
  MyIniFile.Free;
end;

Nur unter Admin-Rechten kommen hier Ergebnisse!!

[fkerber]

Hi!

Zitat:

Zitat von Graffi

Wie schon geschrieben, sind die folgenden Variablen VON MIR:

Delphi-Quellcode:

Var CurrentIniFile : string;
    CurrentSection : string;
    CurrentDir     : string;

Diese setze ich erst in meiner Anwendung.

Und auf welche Werte setzt du diese Variablen?


Ciao, Frederic

[Hansa]

Zitat:

Zitat von Luckie

...Microsoft war bei Vista endlich mal so rigoros und hat das erstellen von Dateien im Programmverzeichnis verboten...

Luckie, Du hast wohl kein Vista ? Sei froh. :mrgreen: Was heißt Programmvereichnis ? Habe soeben neuen User angelegt (-> Standardbenutzer). Dann habe ich mich als Administrator abgemeldet. Um was zu testen bin ich jetzt als "Testuser" im Windows. Dieser User hat soeben versucht einen neuen User anzulegen. Ging nicht (zu wenig Rechte). Der Testuser hat dann compiliert, also zumindest neue DCUs und EXE im Programmverzeichnis erzeugt. Dann hat er noch die INIs gelöscht. Die werden ja dann neu angelegt. Geht alles.

Was jetzt wirklich nicht geht : CD <Admin-Verzeichnis> Echt toll. Mittlerweile glaube ich, dass M$ eingesehen hat, dass es sie selber Geld kosten würde, die User unnötig zu gängeln. :mrgreen:

[alcaeus]

Hansa, koenntest du deine Vista-Probleme dort lassen, wo sie hingehoeren? Danke.

@Graffi: in welchen Verzeichnissen schreibst du rum, wie sehen die Berechtigungen aus, und ist UAC aktiviert oder deaktiviert?

Greetz
alcaeus

[mkinzler]

Wo hast du die Programme abgelegt? Im Standardpfad c:\Program Files hat ein Standardbenutzer kein Schreibrechte. Schreibzugriffe werden virtualisiert, d.h auf ein Verzeichnis in seinem Userverzeichnis umgelenkt.

[Hansa]

Zitat:

Zitat von alcaeus

Hansa, koenntest du deine Vista-Probleme dort lassen, wo sie hingehoeren? Danke.

Soll der Thread von Mod-Seite abgewürgt werden oder was ? :shock: Habe vorhin genau dasselbe gemacht, wie der Fragesteller. Ini-Datein gelöscht im Programmverzeichnis usw. und zwar als Nicht-Admin. Anscheinend liegt die genaue Beantwortung der Frage allerdings nicht im Sinne der DP. :???:

[mkinzler]

@Hansa mache dich mal mit dem Visualisierungskonzept des Dateisystems unter Vista schlau

[alcaeus]

Zitat:

Zitat von mkinzler

Schreibzugriffe werden virtualisiert, d.h auf ein Verzeichnis in seinem Userverzeichnis umgelenkt.

Ist das immer der Fall? Ich dachte der Virtual File Store wird nur benutzt, wenn die Anwendung in den Legacy-Mode geschaltet wird? :gruebel:

Greetz
alcaeus

[Bernhard Geyer]

Zitat:

Zitat von alcaeus

Ist das immer der Fall? Ich dachte der Virtual File Store wird nur benutzt, wenn die Anwendung in den Legacy-Mode geschaltet wird? :gruebel:

Legacy-Modus und Vista? :gruebel:
Eine Anwendung wird unter Vista bei aktiven UAC immer virtualisiert außer es wird per erweiterten Manifest deaktiviert.

[alcaeus]

Zitat:

Zitat von Bernhard Geyer

Legacy-Modus und Vista? :gruebel:
Eine Anwendung wird unter Vista bei aktiven UAC immer virtualisiert außer es wird per erweiterten Manifest deaktiviert.

Ich meinte den Compatibility-Mode, bzw. Kompatibilitaets-Modus. Ich dachte der VFS waere nur dann aktiv, sonst nicht.

Greetz
alcaeus

[PeterPanino]

Zitat:

Zitat von mkinzler

Wo hast du die Programme abgelegt? Im Standardpfad c:\Program Files hat ein Standardbenutzer kein Schreibrechte. Schreibzugriffe werden virtualisiert, d.h auf ein Verzeichnis in seinem Userverzeichnis umgelenkt.

Ich habe (als Administrator) in Vista eben ein von mir geschriebenes Programm im Programmverzeichnis (in C:\Program Files\MeinProgramm\) gestartet. Dieses Programm speichert eine Konfigurationsdatei im eigenen Programmverzeichnis (C:\Program Files\MeinProgramm\) und lädt diese Datei beim nächsten Programmstart dann automatisch wieder.

Jetzt kommt das Rätselhafte: Diese Datei wird nachweislich gespeichert und geladen, ist aber NIRGENDS auffindbar!! Ich habe das ganze C-Laufwerk durchsucht! (Natürlich sind die Ordneroptionen so eingestellt, dass versteckte und Systemdateien angezeigt werden).

Ich habe dann das Programm so angepasst, dass im Programm der Speicherpfad der Datei angezeigt wird, und es ist natürlich das obige Programmverzeichnis (C:\Program Files\MeinProgramm\), aber dort ist die Datei nicht und auch sonst nirgends!

Es ist mir natürlich klar, dass das das obige Programmverzeichnis von Windows Vista ofrfensichtlich irgendwie umgebogen wird, aber WOHIN???

[Christian Seehase]

Moin Peter,

das muss jetzt kein Vista-Phänomen sein.
Manche ini-Dateien werden nicht als Datei gespeichert, sondern in die Registry geschrieben, dass hängt vom Namen ab.
Für TIniFile ist dieser Vorgang vollständig transparent.

Ich habe allerdings auch schon die Erfahrung gemacht (unter XP!), dass Dateien über die Suche nicht gefunden werden, wenn sie sich im Windows-Verzeichnis oder darunter befinden, und man die Suche in C:\-Root starten lässt.
Schau mal direkt im Windows-Verzeichnis nach.

[PeterPanino]

Zitat:

Zitat von Christian Seehase

Moin Peter,

das muss jetzt kein Vista-Phänomen sein.
Manche ini-Dateien werden nicht als Datei gespeichert, sondern in die Registry geschrieben, dass hängt vom Namen ab.
Für TIniFile ist dieser Vorgang vollständig transparent.

Ich habe allerdings auch schon die Erfahrung gemacht (unter XP!), dass Dateien über die Suche nicht gefunden werden, wenn sie sich im Windows-Verzeichnis oder darunter befinden, und man die Suche in C:\-Root starten lässt.
Schau mal direkt im Windows-Verzeichnis nach.

Die besagte Konfigurationsdatei ist keine INI-Datei, sondern hat eine andere Endung (.sch). Ich habe auch im Windows-Verzeichnis nachgesehen, und dort ist sie auch nicht! Aber sie wird gespeichert und geladen! :wall:

Könnte es sein, dass Windows Vista in Wirklichkeit ein Rootkit ist? :pale:

Bearbeitet 1: Habe soeben die gesamte Registry sowohl nach dem Namen der Datei als auch nach einer sehr eindeutigen Zeichenfolge durchsucht, die in der Datei gespeichert wird: Nichts gefunden, das heißt, dass das Speichern der Datei keinesfalls auf die Registry umgebogen wird.

Bearbeitet 2: Es wird immer seltsamer: Ich habe jetzt ohne UAC (Benutzerkontensteuerung) gebootet, und da waren im Programmverzeichnis immer noch keine der gesuchten Konfigurationendateien. Beim Start des Programmes wurde die Meldung angezeigt, dass die Konfigurationsdateien nun erzeugt werden und wurden auch erzeugt. Da aber mein Programm die Programmstarts zählt und dabei jedesmal eine Variable erhöht und diese dann in eine der Konfigurationsdateien schreibt, weiß ich von der angezeigten Zahl der Programmstarts, dass diese Konfigurationsdatei auch schon vorher dagewesen sein muss! Dann nochmals mit eingeschaltetem UAC gebootet und siehe da: Die gesuchten Dateien waren jetzt im Programmverzeichnis immer noch da, inklusive der richtig angezeigten Programmstart-Zählervariable. Ich weiß nicht, was ich davon halten soll.

[alcaeus]

@Peter:

informieren hilft: http://en.wikipedia.org/wiki/Securit...ccount_Control
Ich zitiere:

Aus dem Wikipedia-Artikel:

Many applications break for standard users (non-admins) today because they attempt to write to protected areas that the standard user does not have access to. UAC will improve application compatibility for these users by redirecting writes (and subsequent reads) to a per-user location within the user’s profile. For example, if an application attempts to write to “C:\program files\appname\settings.ini” and the user doesn’t have permissions to write to that directory, the write will get redirected to “C:\Users\username\AppData\Local\VirtualStore\Prog ram Files\appname\.” To make it easier to find these redirected files has been added a new button to Windows Explorer. If there is a virtualized version of a file related to the current directory, a Compatibility Files button appears that will take you to the virtual location to view that file.

Natuerlich funktioniert das nur bei aktiviertem UAC; bei deaktiviertem UAC hast du auf den Programm-Ordner den gewohnten Schreibzugriff wenn du Admin bist.

Wird dadurch einiges klarer? ;)

Greetz
alcaeus

[PeterPanino]

Zitat:

Zitat von alcaeus

@Peter:
Natuerlich funktioniert das nur bei aktiviertem UAC; bei deaktiviertem UAC hast du auf den Programm-Ordner den gewohnten Schreibzugriff wenn du Admin bist.
Greetz
alcaeus

Vielleicht hast du meine Nachricht nicht genau genug gelesen: Die Dateien waren offensichtlich vorher schon da aber irgendwie doch nicht da - für das Dateisystem - (hört sich blöd an, ist aber so, siehe Programmstart-Zählervariable). Deswegen meine Verwunderung.

Ich nehme an, dass Vista im Zusammenhang mit dem UAC irgendwelche "dirty tricks" im Dateisystem ausführt ...

[CCRDude]

Ich glaube er hat Deine Nachricht schon richtig gelesen, immerhin hat er zitiert wo Du die Dateien "findest" (falls Du sie da "normal" nicht gefunden hast: im Explorer etc. wird sowas selbstverständlich erstmal ausgeblendet, wie so vieles). Außerdem, daß Virtualisierung im Spiel ist, und das ist ein Feature, kein Dirty Trick ;)

Und ich glaube, die Lösung, einfach ein Manifest einzubinden (mit Einstellung requireAdministrator... solche Programme, die unbedingt ins Programmverzeichnis schreiben müssen, sind dann schuld daran, daß das an sich sinnvolle Feature UAC den Benutzer durch unnötig viele Rückmeldungen nervt, so daß UAC bald überall ausgeschaltet sein wird wenns nicht schon ist), wurde hier auch schon genannt ;)

[PeterPanino]

Zitat:

Zitat von CCRDude

... im Explorer etc. wird sowas selbstverständlich erstmal ausgeblendet ...

Ich hatte doch weiter oben ausdrücklich geschrieben, dass die Ordner-Optionen zum Ausblenden versteckter Dateien und Systemdateien ausgeschaltet sind, also müssten die Dateien doch angezeigt worden sein. Und dass die Virtualisierung im Spiel ist, ist mir auch klar (hatte ich auch geschrieben). Aber auch mit normaler Virtualisierung wären die Dateien eben einfach woanders hin geschrieben worden, aber das wurden sie eben nicht, wie ich geschrieben hatte. Und dass es besser ist, Daten nicht in das Programmverezichnis zu schreiben, ist ebenfalls logisch - ich hatte eigentlich vor, zu dem ursprünglichen Thread etwas beizutragen oder aufklären zu helfen, nur haben sich dann eben weitere Fragen ergeben.

Trotzdem vielen Dank für eure Hinweise!

[Graffi]

Es stellt sich mir jetzt jedoch die Frage, wie ich am besten meine Anwendung installiere, damit nur "einmalig" eine Registrierung eingegeben werden muss?!

Wieder auf die Registry ausweichen kann doch nicht die Lösung sein.
Bislang habe ich einen Unterordner für meine Konfigurationsdateien "meinprog\config\".

Kann ich evtl. den *tatsächlichen* Pfad meiner Anwendung ermittelt??

Gruss, Ralf

[mkinzler]

Erzwinge für den Installer Admin-Rechte, dann kannst du im "alten" Pfad schreiben oder lege die Ini unter ALLUSERS ab.

[Luckie]

Zitat:

Zitat von mkinzler

oder lege die Ini unter ALLUSERS ab.

Ich weiß ja nicht, wie es unter Vista ist, aber unter Windows XP kann man las normaler Bneutzer im ALLUSERS Profil auch nicht schreiben. Wäre ja auch schrechklich, dann könnte ja jeder seinen ganzen Mist im Startmenü ablegen udn jeder Benutzer hätte dann so ein zu gemülltes Startmenü. In das Profil kann nur der Admin schreiben und das ist auch gut so. Dort legt der Admin Sachen ab, die für eben alle Benutzer von Relevanz sind.

[alcaeus]

Zitat:

Zitat von Luckie

Zitat:

Zitat von mkinzler

oder lege die Ini unter ALLUSERS ab.

Ich weiß ja nicht, wie es unter Vista ist, aber unter Windows XP kann man las normaler Bneutzer im ALLUSERS Profil auch nicht schreiben.

Er meinte ja auch vom Installer aus - der wie erwaehnt mit Admin-Rechten laeuft :)

Greetz
alcaeus

[mkinzler]

Ich hatte mich etwas unklar ausgedrückt, ich meinte ALLUSER als Alternative zum Programmverzeichnis nicht als Alternative zu den Adminrechten.

[Graffi]

Der Vorschlag mit den Admin-Rechten hört sich ganz gut an - Danke!

Werde mein Inno-Setup versuchen zu verbiegen - melde mich noch mit dem Ergebis.

@mkinzler
War mir schon klar, wie Du das mit ALLUSER gemeint hattest!!

[mkinzler]

Zitat:

@mkinzler
War mir schon klar, wie Du das mit ALLUSER gemeint hattest!!

Es war aber trotzdem missverständlich von mir formuliert, auf welchen Umstand mich Luckie aufmerksam gemacht hat.

[CCRDude]

Kurze Anmerkung: gibt es für "All Users" direkt eine Shell-Konstante? Imho doch nur für die entsprechenden Unterordner?

Für eine INI-Datei würde ich allgemein erstmal CSIDL_COMMON_APPDATA verwenden ($0023 als Wert, in InnoSetup {commonappdata} ), und dort, in einem All Users-Unterordner, hat auch ein Normalo-User durchaus Schreibzugriff (gerade mal nen "Hans Dampf" angelegt und nen TotalCommander mit dessen Account gestartet, um dort ein bißchen zu testen ;) )!
In CSIDL_COMMON_STARTMENU natürlich nicht.

[cytrinox]

Edit: damn, falscher Thread :roteyes:

[CCRDude]

Imho läuft die Virtualisierung eh nur, wenn Du kein Manifest in der Datei eingebunden hast. Sobald das drin ist, wird nicht mehr virtualisiert, sondern halt ein Fehler ausgespuckt, wenn Du nicht die Rechte für den Zugriff hast.
Ist auch irgendwie logisch - Virtualisierung ist ja nur als Übergangslösung gedacht (ausdrücklich ohne Garantie daß es sie in zukünftigen Windows-Versionen immer noch geben wird), für Programme die noch nicht auf Vista angepasst sind - sobald das richtige Manifest drin ist, ist das Entwickler ja Vista-aware.

Allerdings: Microsoft hat sich schon etwas dabei gedacht... vielleicht solltest Du halt nochmal ein paar Schritte zurückgehen und das Design an sich überdenken, das in HKLM bzw. allgemein einen global beschreibbaren Registry-Schlüssel benötigt?

Der Ordner selber sollte unter Vista dann C:\ProgramData\ sein (sagt zumindest HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Explorer\Shell Folders\Common AppData\, das meist äquivalent zu den Shell-Funktionen ist). Wichtig: dort NICHT mehr der "Application Data"-Unterordner (aber da die Shell eh immer das richtige Verzeichnis zurückgibt...). LogoUser1, ein eingeschränkter User aus der Vista-Logotest-Umgebung, kann dort auch einen Ordner anlegen, ist also unter Vista genauso.

PS: Egal, dann im falschen auch geantwortet :D

[Luckie]

Zitat:

sagt zumindest HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Explorer\Shell Folders\Common AppData\, das meist äquivalent zu den Shell-Funktionen ist

Bitte nicht aus der Registry lesen, wen es dazu API-Funktionen gibt: The long and sad story of the Shell Folders key

[CCRDude]

Deswegen sagte ich ja auch:

Zitat:

Zitat von CCRDude

aber da die Shell eh immer das richtige Verzeichnis zurückgibt

Bzw. zitierte im anderen Topic sogar den Code, der das über die Shell-API und nicht die Registry macht!

Nur: auf einer frischen Vista-Testmaschine hab ich nunmal nur regedit zur Anhand, um nachzusehen welcher Ordner gemeint ist. Kleines Shell-Tool schreiben, Snapshot setzen, ausprobieren und zurücksetzen wäre für das bloße Vorab-Nachsehen, in welchem Ordner ich testen muß, wohl etwas zuviel verlangt, muss schließlich nebenbei auch noch arbeiten :roll:

[cytrinox]

Zitat:

Zitat von CCRDude

Imho läuft die Virtualisierung eh nur, wenn Du kein Manifest in der Datei eingebunden hast. Sobald das drin ist, wird nicht mehr virtualisiert, sondern halt ein Fehler ausgespuckt, wenn Du nicht die Rechte für den Zugriff hast.
Ist auch irgendwie logisch - Virtualisierung ist ja nur als Übergangslösung gedacht (ausdrücklich ohne Garantie daß es sie in zukünftigen Windows-Versionen immer noch geben wird), für Programme die noch nicht auf Vista angepasst sind - sobald das richtige Manifest drin ist, ist das Entwickler ja Vista-aware.

:wall:

Also nochmal ganz ganz ganz langsam :P

• Ich will nicht wissen was passiert, wenn ein Manifest eingebunden ist
• Ich will nicht wissen was passiert, wenn ich nicht die Rechte für den Zugriff habe
• Ich will nicht wissen was passiert, wenn UAC usw. nicht aktiv ist
• Ich will auch nicht wissen, was passiert, wenn diese Überungslösung später nicht mehr existiert

sondern schlicht und ergreifend wie Windows Vista jetzt im Moment darauf reagiert wenn kein Manifest eingebunden ist, die Rechte stimmen und UAC aktiv ist!


Alles klar soweit? :hi:

[CCRDude]

Also kurz gesagt: Du willst pfuschen! :mrgreen:

Und aus genau diesem Grund, weil das eben häufig passiert, werden immer mehr Benutzer UAC abschalten, weil es einfach zu viele UAC-Warnungen gibt (weil Entwickler sich nicht drum kümmern). Gleichzeitig aber wird wieder gejammert, wie unsicher Windows doch ist, nachdem man es selber torpediert hat.. ist ungefähr so wie die "etwas" ältere Geschichte, die Luckie da verlinkt hat ;)

Insofern ist die Antwort einfach: probier es doch aus :P

[cytrinox]

Nein will ich nicht. Hier gehts ja grad drum es richtig zu machen.

Und da wir bei unserer Software einfach die Möglichkeit brauchen, bestimmte Informationen global für alle user abzuspeichern war meine Frage nur, wie und wo ich das am besten mache.

Und bisher sind wir soweit, dass es keine andere Möglichkeit gibt als unter HKLM einen Schlüssel für alle User freizugeben.

Meine Frage ist ja nur, ob das UAC Zeugs von Vista da was dagegen hat, will heißen dass der Zugriff, trotz passender Rechte einfach verboten ist und somit momentan virtualisiert wird.

Sollte das der Fall sein will ichs ja garnicht so machen, denn ich brauche eine Lösung die sich mit UAC verträgt. Und eben drum wieder die Frage: Wie verhält sich Windows Vista wenn.....

Und jammern über Windows ist nur insofern gegeben, dass es wohl 2 Arten von Programmen gibt: welche die benutzerbezogen arbeiten - z.B. Photoshop, wo jeder Benutzer seine eigenen Einstellungen usw. hat.
Und eben auch Programme die global arbeiten müssen, weil sie z.B. ihre eigene Benutzerverwaltung mitbringen.

In meinem Fall hab ich sowas eben vorliegen, d.h. dass z.b. 3 Admins im Programm angelegt sind und jeder von denen darf die Lizenzdaten abändern. Im Windows System selbst können das aber alles 3 eingeschrhänke Benutzer sein. Ich kanns auch nicht ändern - aber dann will ichs wenigstens richtig machen.

[CCRDude]

Nun, und da Virtualsierung Dir da aber in die Quere kommen könnte, solltest Du dich quasi zwingend mit Manifesten beschäftigen, eben um sicherzustellen, daß es auch echt geschrieben wird, oder im Fehlerfall Du wenigstens einen Fehler als Anhaltspunkt zurückbekommst.
(ist zumindest meine Meinung, daß ein Programm mit Fehlermeldungen auch erkennen sowohl während als auch nach der Entwicklung leichter zu debuggen ist, als etwas, wo man bei jeder Ungereimtheit raten muss, ob nun virtualisiert wurde oder nicht ;) ).
Mit Manifest sagst Du Vista ganz klar: "dieses Programm benötigt Admin-Rechte" oder "dieses Programm benötigt KEINE Admin-Rechte", d.h. der Benutzer bekommt im ersten Fall nicht ständig diesen UAC-Dialog um die Ohren gehauen ;)

Im übrigen: auch "so" würde ich das MS-Dokument zu UAC als Lektüre empfehlen, weil dort genauer drinsteht, was wann wie virtualisiert wird (hab gerade leider gerade nichts auf diesem Rechner, was .doc lesen kann, deswegen kann ich nicht reinsehen und zitieren).

[cytrinox]

Jau, da geb ich dir vollkommen Recht :)

Aber sagen wir mal ich leg per Manifest fest, dass das Programm Adminrechte braucht - dann würde bei jedem Programmstart nach dem Adminpasswort gefragt, oder? -> Weißt du was die Kunden dann mit mir machen? :p

Ich such mir mal das Dokument und blätter durch, vielleicht find ich ja eine Antwort :)