TRegistry Unterschied zwischen Delphi 7 und 2009

[Bernhard Geyer]

Nimm mal beim Pfad das führende Backslahs weg. Also Statt '\Software\Vendor\Productname' -> 'Software\Vendor\Productname'

[Popov]

Ich weiß, vielleicht wird das etwas OT, aber ich hab nie verstanden was so toll daran sein soll auf HKEY_CURRENT_USER, bzw. speziell auf "Software" über die TRegistry zuzugreifen, falls man nur 08/15 Daten drauf ablegen will. Nur um eine String abzuspeichern verbiegen sich einige mit dem Rattenschwanz an Zeilen, dabei bietet Delphi einen einfachen Zugriff. Solange es HKEY_CURRENT_USER ist.

[jaenicke]

Wenn du damit auf TRegIniFile hinaus willst:
Das ist nur eine Krücke um eine Migration der alten INIs von Windows 3.x auf Windows 9x und höher einfacher zu machen. Für neue Implementierungen macht es normalerweise keinen Sinn, weil man sich damit unnötig beschränkt, es damit aber nicht einfacher ist (wenn nicht schon INI-Code da ist).

[Popov]

Wo beschränkt man sich? Wenn ich keine Großfamilie habe, dann kaufe ich mir auch nicht einen Kleinbus, weil da zehn Personen rein passen, ich also mehr Möglichkeiten habe. Natürlich ist/war TRegIniFile dazu gedacht einfach seine Ini umzuschreiben, aber was ist gegen

Delphi-Quellcode:

  with TRegIniFile.Create('Software\' + ChangeFileExt(ExtractFileName(ParamStr(0)), '')) do 
  try
    WriteString(Section, Ident, 'Irgendein Text')
  finally 
    Free 
  end;

zu sagen, wenn man einen String speichern möchte?

Ist es cooler für das gleiche Ergebnis doppelt so viele Zeilen zu nutzen, weil es TRegistry ist? Ja, wenn ich mehr speichern will, nutze ich auch TRegistry. Um Einstellungen zu speichern, da verbiege ich mich nicht künstlich, nur weil in der Hilfe steht, dass es für die Migration der alten INIs von Windows 3.x auf Windows 9x ist. Es ist da, es reicht für 98% alle Fälle, warum also mehr?

[himitsu]

Und wo ist da der große Unterschied zu dem?

Delphi-Quellcode:

with TRegistry.Create(KEY_WRITE) do
try
  OpenKey('Software\MeineFirma\MeinProgramm\' + Section, True);
  WriteString(Ident, 'Irgendein Text');
finally
  Free;
end;

Abgesehn daon, daß bei Beidem die Fehlerbehandlung fehlt.

[Popov]

Hast du jetzt geantwortet um nur um zu antworten oder war es ernst gemeint?

[jaenicke]

Zitat von Popov:

Wo beschränkt man sich? Wenn ich keine Großfamilie habe, dann kaufe ich mir auch nicht einen Kleinbus, weil da zehn Personen rein passen, ich also mehr Möglichkeiten habe.

Ich nehme aber auch keinen Transportbeutel für meine Fische nur weil sie da auch Wasser drin haben. Da bleibe ich lieber beim Aquarium.

Die meisten Programme werden im Laufe der Zeit erweitert und damit werden dann auch z.B. mehr Einstellungen usw. benötigt. Da ist es viel besser, wenn man gleich TRegistry benutzt hat und damit auch die Möglichkeit hat die Möglichkeiten der Registry auszuschöpfen.

Davon abgesehen sehe ich aber auch nicht den großen Unterschied im Quelltext, nur dass du bei TRegIniFile keinerlei Möglichkeit zur Fehlerbehandlung hast, da du nirgends den Rückgabewert von OpenKey im Konstruktor bekommst. Du weißt also nicht, ob du hinterher überhaupt schreiben kannst, kannst also nur auf eine Exception prüfen (oder CurrentPath gegenprüfen, aber naja)...

[Popov]

@jaenicke

Wenn du dir TRegIniFile genauer ansiehst, wirst du bemerken, dass es auf HKEY_CURRENT_USER beschränkt ist. Mit TRegIniFile kann man also nicht irgendwo anders schreiben, nur in HKEY_CURRENT_USER Zweig. Das ist die Einschränkung. Und auf HKEY_CURRENT_USER hat man in der Regel immer Rechte, da es dem CURRENT_USER, als dem aktuellen Benutzer gehört. Man greift also auf den eigenen Zweig der Registry zu. Somit sollte es keine Probleme geben.

Die Probleme die du meinst tauchen in der Regel in anderen Zweigen auf.

Ich könnte mir nur den einen Grund vorstellen, dass ein anderes Programm auf meine Einstellungen zugreift, was eigentlich nicht vorkommen sollt.

Also nochmal, allgemein auf die Registry zugreifen, da gebe ich dir Recht. Hier gehen es aber um HKEY_CURRENT_USER.

[Shark99]

Zitat von Bernhard Geyer:

Nimm mal beim Pfad das führende Backslahs weg. Also Statt '\Software\Vendor\Productname' -> 'Software\Vendor\Productname'

Daran lag es nicht. Macht auch keinen Sinn, weil \ am Anfang die direkte Addressierung ist (kein Close des Keys zuvor notwendig). Ohne \ am Anfang ist der Key immer relativ zum gerade offenen Key (schon seit Delphi 3 und Windows 95).

Ich denke es liegt an was anderen. Ich hab auf der Kiste neben Delphi 7 und Delphi 2009 (Vollversionen) auch Delphi XE8 (30 Tage Trial). Kompiliere ich die Exe unter Delphi 7 und starte mit dem Explorer startet sie ohne Probleme. Aber sowohl unter 2009 als auch unter XE8 wenn ich die Exe über den Explorer starte kommt zuerst die Meldung 'The publisher could not be verified', was man sonst kennt wenn man eine Exe von einem Netzlaufwerk startet. Es ist aber hier alles lokal und zwar für alle 3 in c:\projects. Kopiere ich die Exes die von 2009 und XE8 erzeugt wurden woanders hin kommt die Meldung nicht mehr. Windows 7 mag also die von 2009 und XE8 erzeugten Exes nicht besonders und schränkt den Schreibzugriff auf die Registry, allerdings nur in dem Verzeichnis in dem sie kompiliert wurden.

Um die Theorie zu testen habe ich den Code leicht geändert:

Delphi-Quellcode:

FRegistry :=  TRegistry.Create(KEY_ALL_ACCESS OR KEY_WOW64_64KEY);
FRegistry.RootKey := HKEY_CURRENT_USER;
if FRegistry.OpenKey('\Software\Vendor\Productname', True) then
begin
   ShowMessage('ok');
end else
begin
   ShowMessage('not ok');
end;

Ergebnis:

Start aus c:\projects\project1: not ok
Nach Kopieren der Exe-Datei nach c:\test: ok

Also habe ich das Projekt nach c:\test\project1 verschoben. Starten -> ok. Wenn ich jedoch einen Rebuild mache und starte -> not ok.

Sehr sehr merkwürdige Sache. Ich denke es liegt irgendwie an meinem System. Ich verstehe aber nicht wieso die Exe wenn sie mit Delphi 7 kompiliert wird keinerlei Probleme macht. Vielleicht erkennt Windows 7 dass die Exe dann von einem Compiler ist der von der Era von vor Windows 7 stammt und gibt der Exe dann automatisch mehr Rechte (Kompatibilitätsmodus).

Trotzdem ist es extrem merkwürdig weil ich als Admin eingelogt bin und UAC komplett aus ist. 'Run as Administrator' ändert an der Sache nichts.

Bin wirklich mit meinem Latein am Ende.

[Dalai]

Schau mal genauer in folgende Registry-Zweige:

Code:

HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags
HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags
HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AppCompatFlags

ob dort deine EXE oder ähnliches mit Hinweis auf selbige auftaucht. Prüfe außerdem, ob die EXE an sich im Kompatibilitätsmodus läuft (Rechtsklick > Eigenschaften).

MfG Dalai