Innosetup: Verständnisfrage zur Registry (HKCU)

[Codehunter]

Hallo!

Ich habe ein Setup, das unter HKCU\Software ein paar Schlüssel anlegt. Da das Setup dann als Administrator ausgeführt wird, landen die Schlüssel logischerweise im HKCU-Zweig vom Admin-Konto. Soweit klar. Ziel soll aber sein, dass jedes Benutzerkonto seine eigenen Programmeinstellungen bekommt, also jeweils einen HKCU-Zweig.

Was ich nicht verstehe ist, wie andere Installer verfahren wenn man dort auswählt "Für alle Benutzer einrichten". Wird dann dort alles in den HKLM-Zweig geschrieben und das eigentliche Programm "klont" die Einstellungen dann in den jeweiligen HKCU-Zweig? Oder wie muss man sich das vorstellen?

Grüße
Cody

[DeddyH]

Ich weiß nicht, wie andere das machen, aber eine Möglichkeit wäre: nach den Einstellungen in HKCU suchen und wenn gefunden, diese benutzen, ansonsten deren Pendants aus HKLM. So hat jeder Benutzer die gleichen Vorgabewerte, kann diese aber nach eigenem Gusto ändern.

[Codehunter]

Wie sind eigentlich nach heutiger Lesart (Vista und höher) die "Gepflogenheiten" im HKCU-Zweig? Darf man da mit einer Anwendung die nicht im Admin-Kontext läuft nach Herzenslust drin rum schreiben?

[mkinzler]

Ja. Wenn man nicht mit einem Guest-Account arbeitet.

[jaenicke]

Solange man an die passenden Stellen schreibt, kann man da schreiben wie man möchte, ja. Man sollte allerdings nie voraussetzen, dass man auch überall die Rechte hat, denn die kann man ja jederzeit ändern. Wenn das nicht geht, sollte das daher entsprechend abgefangen werden.

Das automatische Anlegen ist in der Tat ein üblicher Weg. Wenn man Delphi mit einem anderen Profil startet, wird das auch in der Registry entsprechend angelegt, wenn es noch nicht da ist.

[Codehunter]

Hmm, jetzt habe ich mal versucht so eine Klonerei zu implementieren. Im Adminkontext funktioniert das auch, die Schlüssel und Werte werden aus HKLM in HKCU geklont falls sie da nicht existieren. Im normalen Userkontext (NICHT Gast sondern Standardbenutzer) dagegen nach wie vor keine Schreiboperation möglich. Ich habe die Unit mal angehängt. Der ganze Zauber findet in ValueExists statt:

Delphi-Quellcode:

function TRegConfig.ValueExists(const AName: string): Boolean;
var
  HKCU, HKLM: TRegistry;
  Info: TRegDataInfo;
begin
  Result:= FALSE;
  try
    HKCU:= TRegistry.Create(KEY_ALL_ACCESS or KEY_WOW64_64KEY);
    HKLM:= TRegistry.Create(KEY_READ or KEY_WOW64_64KEY);
    HKCU.RootKey:= HKEY_CURRENT_USER;
    HKLM.RootKey:= HKEY_LOCAL_MACHINE;
    if HKCU.OpenKey(FReg.CurrentPath, TRUE) then begin
      if HKCU.ValueExists(AName) then begin
        Result:= TRUE;
        Exit;
      end else begin
        if HKLM.OpenKey(FReg.CurrentPath, FALSE) and HKLM.ValueExists(AName) then begin
          HKLM.GetDataInfo(AName, Info);
          case Info.RegData of
            rdString:  HKCU.WriteString(AName, HKLM.ReadString(AName));
            rdInteger: HKCU.WriteInteger(AName, HKLM.ReadInteger(AName));
          end;
          Result:= TRUE;
        end;
      end;
    end;
  finally
    FreeAndNil(HKCU);
    FreeAndNil(HKLM);
  end;
end;

[Der schöne Günther]

Kleine Frage am Rande, vielleicht bringt das auch die andere Frage nach "Installation für alle" etwas weiter:

Wie steht es heutzutage eigentlich mit der Registry-Virtualisierung? Den verlinkten Artikel würde ich so zusammenfassen:

• Will jemand ohne Adminrechte in HKLM\Software\ schreiben, wird das nach HKCU\Software\Classes\VirtualStore\ umgeleitet und zugelassen

In der Praxis kann ich das nicht nachvollziehen. Hatte das nur unter Windows Vista Bestand? Das einzige was ich beobachten kann, ist das ein Ausführen im Kompatiblitätsmodus bewirkt, dass das Öffnen eines Schlüssels in HKLM\Software zwar genehmnigt wird, wenn man Schreibrechte anfordert, aber letztendlich fehlschlägt, wenn man tatsächlich etwas schreiben möchte.

[jaenicke]

Zitat:

Zitat von Der schöne Günther (Beitrag 1250416)

Wie steht es heutzutage eigentlich mit der Registry-Virtualisierung?

Die greift nur, wenn die Anwendung kein Manifest drin hat, mit der sie bestätigt für XP und höher geeignet zu sein. Wenn die Anwendung ein solches Manifest drin hat, geht Windows davon aus, dass sie auch für die Windowsversion tauglich ist und führt diese Virtualisierung nicht aus.

Denn gedacht ist diese für alte Programme, die vor XP entstanden sind.

[Der schöne Günther]

Alter Schwede, genau das war es! Vielen Dank! :thumb:

[Codehunter]

Unabhängig von dem eigentlichen Problem ist mir gestern Abend noch ein weiteres eingefallen: Wenn ich diese Klonerei von HKLM nach HKCU betreibe, dann kann der Uninstaller am Ende die Registry nicht vollständig bereinigen. Woher soll der denn auch wissen was da später noch geklont wurde? Außerdem hätte der ja das selbe Problem wie der Installer, nämlich gar nicht an die HKCU aller Konten heran zu kommen.

Also irgendwo mach ich da noch einen grundsätzlichen Denkfehler...

[mkinzler]

Ich würde es auch nicht Klonen, sondern im 1. Schritt nur in HKLM schreiben, ändert ein Benutzer eine Einstellungen würde ich diese Änderung dann in HKCU schreiben. Das hat den Vortiel, dass bei einer Änderung der Standard, nicht alle Profile geändert werden müssen und das so einfacher ersichtlich ist, was individuell ist.

[DeddyH]

Genau so hatte ich es ja in #2 skizziert.

[Codehunter]

Zitat:

Zitat von mkinzler (Beitrag 1250463)

ändert ein Benutzer eine Einstellungen würde ich diese Änderung dann in HKCU schreiben

Ich nenne es der Einfachheit halber "Klonen", wobei mein Code im Grunde genau das tut was du sagst, nur beim Zugriff auf einen in HKCU nicht existierenden Wert wird er angelegt mit dem Default aus HKLM. Allerdings reicht in dem Fall schon ein Lesezugriff um das auszulösen. Das könnte ich noch ändern.

Doch an den beiden grundsätzlichen Problemen (kein Schreibzugriff als Standardbenutzer und Uninstaller) ändert das aber erstmal nichts.

[mkinzler]

Zitat:

Ich nenne es der Einfachheit halber "Klonen", wobei mein Code im Grunde genau das tut was du sagst, nur beim Zugriff auf einen in HKCU nicht existierenden Wert wird er angelegt mit dem Default aus HKLM.

Das würde ich (und Detlef) ja gerade nicht machen, nur bei Änderungen. Kein Wert in HKCU = benutze Default (HKLM)

[Codehunter]

Zitat:

Zitat von mkinzler (Beitrag 1250468)

Das würde ich (und Detlef) ja gerade nicht machen, nur bei Änderungen. Kein Wert in HKCU = benutze Default (HKLM)

Wie gesagt, das ließe sich ja leicht ändern. Nur muss man ja auch User-Settings speichern können. Das gehört nun mal nach HKCU und nicht nach HKLM.

[Codehunter]

OK, Kommando zurück :-D

Der Fehler lag in dem Fall ganz woanders. Das Setup hat (aus welchen Gründen auch immer) manche Reg-Values überhaupt nicht angelegt. Weder in HKLM noch in HKCU. In dem Fall griffen in meinem Programm nur die Failsafe-Defaults und die sagten ganz simpel "Bloß nix anfassen, Baustelle!". Ergo erzeugte mein Code auch keine Schlüssel oder Werte in HKCU.

Asche auf mein Haupt :wall:

[Luckie]

Noch eine Idee: Hinterlege die Standardeinstellungen im Programm. Werden sie geändert, werden sie in der Registry abgelegt. Beim Start wird geguckt, ob die Einstellungen in der Registry gefunden werden. Werden sie gefunden, werden diese geladen, ansonsten die Standardeinstellungen aus dem Programm.

[Codehunter]

Ist vielleicht sogar die sicherste Lösung, dann wäre das Programm von Haus aus "portable".

Allerdings löst das immer noch noch nicht das Uninstaller-Problem. So ließe sich jedenfalls der Effekt erklären, dass die Registry im Lauf der Zeit immer größer und träger wird ^^

[DeddyH]

Ich lehne mich mal weit aus dem Fenster und behaupte, das ist ein konzeptionelles Windows-Problem im Bezug auf den HKCU-Hive.

[generic]

Zitat:

Zitat von Codehunter (Beitrag 1250398)

Hallo!

Was ich nicht verstehe ist, wie andere Installer verfahren wenn man dort auswählt "Für alle Benutzer einrichten". Wird dann dort alles in den HKLM-Zweig geschrieben und das eigentliche Programm "klont" die Einstellungen dann in den jeweiligen HKCU-Zweig?

Bei dieser Frage geht es eigentlich nicht mehr da drum wo Einstellungen hin sollen.
Vielmehr unterscheidet der Windows Installer zwischen per-machine und per-user. Installation.

Bei einer Maschine Installation, wird die Anwendung unter "c:\programme" abgelegt.
Einstellung bezüglich der Software (keine Benutzereinstellungen) liegen dann unter HKLM.

Bei User Installation, werden keine Adminrechte benötigt. Die Anwendung installiert sich dann in Benutzerprofil inkl. der Anwendungseinstellungen unter HKCU.


Benutzerdaten werden immer erst beim ersten Programmstart eines Nutzers angelegt und dann in dessen Profil oder HKCU.
Falls Dateien von mehren Nutzer genutzt werden sollen, dann dürfen diese in %AppData% dazu sind aber Rechte zu vergeben, da der Ordner keine Schreibrechte für User hat.

Lässt sich hier auch nachlesen:
http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

http://blogs.msdn.com/b/windows_inst...windows-7.aspx




HKLM lässt sich übrigens auch nur mit erhöhten Rechten schreiben, daher lass das lieber die Finger von, da Benutzereinstellungen hin zu packen.

[Luckie]

Hier eine Meinung eines MS Entwicklers zu dem Problem mit den Daten in HKCU bei der Deinstallation: http://blogs.msdn.com/b/oldnewthing/...7/4948130.aspx

[Dalai]

Ich würde HKCU bei der Deinstallation ebenfalls in Ruhe lassen (außer vielleicht den vom gerade angemeldeten Nutezr). Langsamer wird ein System dadurch nicht, denn von der Registry werden immer nur die benötigten Teile geladen - und wenn das Programm, das diese Zweige benötigt/lesen würde, nicht mehr vorhanden ist, werden diese Teile der Registry auch nicht geladen. Für Rechnerbremsen gibt's ganz andere Ursachen.

MfG Dalai

[Codehunter]

Ich meine nur mich dunkel zu erinnern dass es eine Möglichkeit gab, Keys im HKCU zu markieren, dass sie beim nächsten Login/Logout gelöscht werden sollen. So ähnlich wie es auch mit manchen Systemdateien oder Temp-Dateien funktioniert.