Registry-Probleme unter Vista

[wido]

Hast Du Dir meinen Screenshot mal angesehen? Wenn TRegIniFile den Key, den Du definierst, nicht öffnen kann, schreibts die Daten einfach irgendwo hin. Will gar nicht wissen was passiert, wenn Du Werte mal löscht. Ob es dann auch einfach irgendwo rumdeleted? Allein deswegen würd ich meine Unit schnellstens überarbeiten. Denn offensichtlich tut sie Sachen, von denen Du gar nichts weißt ;).

[Popov]

Zitat:

Zitat von wido

Hast Du Dir meinen Screenshot mal angesehen? Wenn TRegIniFile den Key, den Du definierst, nicht öffnen kann, schreibts die Daten einfach irgendwo hin. Will gar nicht wissen was passiert, wenn Du Werte mal löscht. Ob es dann auch einfach irgendwo rumdeleted? Allein deswegen würd ich meine Unit schnellstens überarbeiten. Denn offensichtlich tut sie Sachen, von denen Du gar nichts weißt ;).

Ich hab mir das angesehen mit Reg Monitor. Aber keine Angst, so ist es nicht. Hier zwei Beispiele aus der TRegIniFile:

Delphi-Quellcode:

constructor TRegIniFile.Create(const FileName: string; AAccess: LongWord);
begin
  inherited Create(AAccess);
  FFilename := FileName;
  OpenKey(FileName, True);
end;

procedure TRegIniFile.WriteString(const Section, Ident, Value: String);
var
  Key, OldKey: HKEY;
begin
  CreateKey(Section);
  Key := GetKey(Section);
  if Key <> 0 then
  try
    OldKey := CurrentKey;
    SetCurrentKey(Key);
    try
      inherited WriteString(Ident, Value);
    finally
      SetCurrentKey(OldKey);
    end;
  finally
    RegCloseKey(Key);
  end;
end;

Würdest du es besser machen? Ich mache ja keinem einen Vorwurf, aber das ist das was ich oben meinte. Jeder kann sich den Quellcode ansehen. Die Unit schreibt also nicht wahllos irgendwo etwas hin, sondern da wo es soll. Ich weiß nicht wo die Menge an Zugriffen kommt, aber garantiert nicht von TRegIniFile. Eventuell von API.

[wido]

Zitat:

Zitat von Popov

Würdest du es besser machen? Ich mache ja keinem einen Vorwurf, aber das ist das was ich oben meinte. Jeder kann sich den Quellcode ansehen. Die Unit schreibt also nicht wahllos irgendwo etwas hin, sondern da wo es soll. Ich weiß nicht wo die Menge an Zugriffen kommt, aber garantiert nicht von TRegIniFile. Eventuell von API.

Ich bezweifle, daß es legal ist VCL Sourcen einfach so ummadum zu posten. Aber das soll ein Mod entscheiden ...

Du solltest Dir anschauen worauf da zugegriffen wird:
Zuerst wird versucht normal auf HKCU\Software\Project1 zuzugreifen. Das ist so gewollt. Das ist der Pfad, den Du definiert hast. Und der Zugriff wird verboten. Was macht die hübsche Komponente? Naja, schreib ichs halt einfach in den Hauptschlüssel -> HKCU (siehe ab Zeile 4). Was meinst was passiert, wenn Du mal die Section Software löscht? "Oh, ich kann den Registry Pfad in dem ich eigentlich löschen soll nicht öffnen. Lösch ich halt lustig im Root Pfad von HKCU rum."

Das ist ein Bug. Vielleicht nicht unmittelbar in deinem Code, aber einem User dem Du undefiniert evtl. Subkeys löscht wird das eher nicht interessieren.

[Popov]

Zitat:

Zitat von wido

Das ist ein Bug.

Lol, das ist kein Bug. Siehe Code. Wenn Bug, dann in TRegistry. Dann bringt die Nutzung von TRegistry auch nichts ;)

[Popov]

Zitat:

Zitat von DeddyH

Tja, was soll man dazu noch sagen?

So ein Jammer auch :feuerchen:

[DeddyH]

OK, wenn Dir das lieber ist:
[ironic]Oh großer taktaky Popov, Du schreibst so fehlerfreie Programme, erklär Deinen Usern, dass sie gefälligst die UAC abzuschalten und sich als Admin anzumelden haben, damit Dein großartiges Programm vollen Zugriff auf die Registry hat und Du Dich nicht mit so unwichtigen Dingen wie Fehlersuche (da ja bei Dir keine solchen auftreten) beschäftigen musst. Und verzeih uns, dass wir Deinen Code angezweifelt haben, denn TRegIniFile ist ja bereits seit Jahren ausgereift, so lange schon, dass zum Zeitpunkt der Erstellung dieser Unit noch kein Mensch an Windows 2000, XP oder gar Vista gedacht hat.[/ironic]

Wenn das die Art Antwort ist, auf die Du gewartet hast, bist Du hier falsch.

[wido]

Zitat:

Zitat von Popov

Lol, das ist kein Bug. Siehe Code. Wenn Bug, dann in TRegistry.

Das ist dem User oder auch Kunden doch völlig egal. Deine Software hat sein Userprofil geschrottet. Rest interessiert seinen Anwalt doch ohnehin nicht ;). Ok, geb zu ... das war übertrieben. Kann allerdings schneller gehen als man denkt. Insbesondere dann wenn man wie Du seine Software gänzlich ohne eine Form von Lizenzbedingungen verteilt :).

[Fussball-Robby]

Ich würde mal sagen, mindestens zwei Drittel der Posts hier haben nichts mehr mit der ursprünglichen Frage zu tun und greifen hier irgendjemanden persönlich an. Es ging hier, falls ihr es schon vergessen habt, darum, dass es unter Vista Probleme mit der Registry gibt. Wenn Popov behauptet, es läge am OS, und die anderen meinen, es läge am Code, hilft das hier denke ich keinem weiter. Ich habe kein Vista, darum kann ich im Bezug darauf wenig sagen.
Wenn hier alle mal konstruktive Vorschläge machen würden und Popv auf diese eingehen und sie ausprobieren würde, könnten wir das Problem vielleicht lösen.
Aber so, wie das hier gerade läuft, wird das wohl nichts :roll:

Mfg

[Popov]

Zitat:

Zitat von DeddyH

Und verzeih uns, dass wir Deinen Code angezweifelt haben, denn TRegIniFile ist ja bereits seit Jahren ausgereift, so lange schon, dass zum Zeitpunkt der Erstellung dieser Unit noch kein Mensch an Windows 2000, XP oder gar Vista gedacht hat.[/ironic]

Ähm, dir ist aber klar, daß sich Delphi auch entwickelt hat? Das Programm ist mit Delphi 7 kompiliert und dieses wird weiter entwickelt. Und glaub mir, ich kenne den Quellcode von Delphi 3 und Delphi 7 und die unterscheiden sich. Ich weiß nicht was du dir vorstellst? Das Borland einmal den Code entwickelt und den dann nie wieder anpackt? Beachte als Beispiel mal Access. Es ist ein Bestandteil von TRegIniFile Code. Bei Delphi 3 gabe es das nicht und bei Windows 98 brauchte man es nicht.

Ich will nichts sagen, aber das sind unqualifizierte Äußerungen. Ich gestehe dir durchaus zu keine Enterprise Version haben zu müssen, so daß du den Code dir nicht angucken kannst, aber wenn du eine Version hast, dann hätte ich nach so langer Diskussion mir den Code schon längst angeguckt. Dann wüßtest du, daß das was du sagst nicht stimmt.

[DeddyH]

Das wird mir jetzt echt zu blöd. Könnte mal jemand den Thread closen?

[Popov]

Moment, ich hab dich so eben drauf hingewiesen, daß du dich unprofessionell benommen hast und das ist deine Antwort?

[wido]

Zitat:

Zitat von Popov

Ich will nichts sagen, aber das sind unqualifizierte Äußerungen. Ich gestehe dir durchaus zu keine Enterprise Version haben zu müssen, so daß du den Code dir nicht angucken kannst, aber wenn du eine Version hast, dann hätte ich nach so langer Diskussion mir den Code schon längst angeguckt. Dann wüßtest du, daß das was du sagst nicht stimmt.

Mach mal folgendes:
Schreib Dir ein kleines tool wie ich, daß deine Unit verwendet und in dem einfach nur folgendes steht:

Delphi-Quellcode:

EraseIniSection('Software');

Dann verbietest Du Dir selbst einfach mal den Schreibzugriff auf den Registry Key in den Du schreiben willst ('HKCU\Software\Project1' z.B.) und startest Dein Programm. Nachdem Du Dein Userprofil danach gelöscht und neu erstellt hast weil der kleine Befehl es komplett unbrauchbar gemacht hat, darfst Du mir gerne nochmal erzählen, daß ich Unrecht habe ;). Siehe dazu auch das geloggte Experiment auf meinem Testrechner im Attachment :).

[Daniel]

Meine Herren,

bitte zurück zum Thema. Ob die Klasse "TRegIniFile" unter Vista unter allen Umständen wie die Original-Klasse TRegistry funktioniert, müsste ein detaillierter Test klären. Fakt ist, dass man unter Vista doppelt und dreifach aufpassen muss, nicht in die Restriktionen des User-Accounts zu laufen.

[DeddyH]

Hallo Cheffe, eben darum sollte es ja ursprünglich gehen (wenn ich die ersten Ansätze der anderen zur Fehlersuche richtig interpretiert habe). Fakt ist ja nun mal, dass TRegIniFile die Rückgabewerte seines Vorfahren nicht prüft und stattdessen optimistisch in die Zukunft sieht. Wenn das OpenKey im Konstruktor von TRegIniFile schon nicht tut, wie soll dann weiter verfahren werden? Nun wollten wir vorsichtig andeuten, stattdessen vielleicht lieber auf TRegistry zurückzugreifen, da man auf diese Weise prüfen kann, wo es denn nun wirklich hakt. Wie das geendet hat, kann man ja nachlesen.

[Daniel]

Ich habe mir mal eben das Demo-Programm abgesehen und dabei einen Blick auf die Klasse "TRegIniFile" geworfen. Ich halte diese Klasse für problematisch, weil sie eben nicht dediziert prüft, wo was falsch gelaufen ist und dies an die Anwendung zurückliefert.

Für die Fehlersuche ist eine direkte Verwendung der Klasse TRegistry geeigneter, da man hier Operation für Operation auf Ihren Erfolg hin prüfen kann:

TRegistry.Create
TRegistry.RootKey = _XY_
KeyExists
CreateKey
OpenKey
Read_XYZ_
Write_XYZ_
CloseKey

Danach ist unmittelbar klar, wo es beim Anwender knallt und oftmals ergibt sich dann aus der Situation auch direkt die Ursache für das Fehlverhalten.

[edit]
@DeddyH: Habe Deine Antwort zu spät gelesen ... die rote Box ist gerade im Testforum :stupid:
[/edit]

[DeddyH]

[OT]

Zitat:

Zitat von Daniel

... die rote Box ist gerade im Testforum :stupid:

Da ist meine ständig :lol: [/OT]

[Luckie]

Zitat:

Zitat von Daniel

Ob die Klasse "TRegIniFile" unter Vista unter allen Umständen wie die Original-Klasse TRegistry funktioniert, müsste ein detaillierter Test klären.

Genau das versuchen wir Popov seit dem ersten Posting klar zu machen. Aber er weigert sich ja beharrlich eine Alternative in betracht zu ziehen.

Zitat:

Zitat von Popov

Zitat:

Zitat von Luckie

Genau das ist doch das Problem. Benutze TRegistry damit du endlich mal einen Fehler ls Feedback bekommst.

Luckie, das nötige Feedback habe ich schon.

Ich meine nicht das Feedback von deinen Kunden, sondern ein Feedback von Windows in Form einer Fehlermeldung! Aber so lange du auf dieser komischen TregistryIni-Klasse beharrst, wirst du das nie bekommen.

Zitat:

Der Code in meiner Unit entfällt keine Fehler.

Selbst Borland ist nicht unfehlbar. Menschen machen Fehler, das liegt in ihrer Natur.

Zitat:

Der Programmpfad zu wenige Rechte? Möglich, aber dann bringt mir OpenKey auch keine bessere Info.

Doch, denn dann würde GetLastError Fehlercode 5 ("Zugriff verweigert") zurückgeben und du wüsstest, warum es nicht funktioniert.

Zitat:

Ich schätze, daß du einfach die TRegIniFile nicht kennst

Was gibt es da zu kennen? Ich habe es nie benutzt, eben weil es nur da ist aus Kompatibilitätsgründen zu Windows 3.1x.

Zitat:

Zitat:

Wird also mal zeit endlich die Unit mal zu überarbeiten.

Besteht keine Notwendigkeit.

Dann ist dir nicht zu helfen. So lang du darauf bestehst, dass dein und Borlands Code fehlerfrei sind und nicht mal ansatzweise bereit bist etwas auszuprobieren, ist es sinnlos hier weiter zu diskutieren und dir helfen zu wollen.

Zitat:

Zitat:

Doch das besagt, dass TRegIni versucht so zu arbeiten wie unter 16-Bit Windows 3.1x. Und das ist schon mehr als veraltet. Vista unterstützt keine 16-Bit Programme mehr (in wiefern das hier eine Rolle spielt, weiß ich nicht).

Diesen Kommentar hätte ich von sonstwem erwartet, aber nicht von dir. TRegIniFile wird von TRegistry abgeleitet. Wo siehst du da 16 Bit? Wo besteht das Problem sich vor so einem Kommetar den Quellcode der TRegIniFile anzugucken? Dann würde man eventuell andere Kommentare abgeben.

Dr Code ist natürlich 32-Bit, aber er versucht zu arbeiten wie unter Windows 16-Bit.

Zitat:

Es ist eigentlich schlimm, denn die Kommentare zeigen, daß man etwas sagt was üblich ist, aber sich nicht mit dem Problem beschäftigt.

Nein schlimm ist, dass du absolut resistent gegen irgendwelche Vorschläge von uns bist. Ich frage mich lansam, ob du überhaupt Hilfe willst.

[Luckie]

Zitat:

Zitat von Daniel

Für die Fehlersuche ist eine direkte Verwendung der Klasse TRegistry geeigneter, da man hier Operation für Operation auf Ihren Erfolg hin prüfen kann:

Das sagen wir seit vier Seiten Postings.

[Daniel]

Zitat:

Zitat von Luckie

Das sagen wir seit vier Seiten Postings.

... schon, aber es war mir wichtig und ... außerdem bin ich Admin. *g*



Davon mal abgesehen, funktioniert die Demo-Anwendung bei mir unter Windows Vista. Und das ohne besondere Rechte.

[Daniel]

Eine Kleinigkeit noch:

Mischaeeeeel hat geschrieben:

Der Code ist natürlich 32-Bit, aber er versucht zu arbeiten wie unter Windows 16-Bit.

So weit würde ich nicht gehen. Die Klasse "TRegIniFile" imitiert die Schnittstellen der guten, alten INI-Datei. Intern werkelt aber ein vollständiges und aktuelles Objekt der Klasse "TRegistry". An der tatsächlich verrichteten Arbeit ist nichts auszusetzen, nur sind die Möglichkeiten, auf diesen Vorgang einzuwirken, viel zu gering. Das Beginnt bei der expliziten Wahl der Zugriffsrechte und gipfelt eben - wie in diesem Fall - an der Fehlerbehandlung, die in einem "geht" bzw. "geht nicht" mündet.

Das soll kein Plädoyer für die Verwendung dieser Klasse sein, aber als Übergangslösung war sie damals - Ende der 90er - durchaus geeignet. Nur ist sie eben mittlerweile von der Realität überholt worden.

[DeddyH]

Zitat:

Zitat von Daniel

Nur ist sie eben mittlerweile von der Realität überholt worden.

Unsere Rede seit Beginn des Threads, aber wir sind ja unqualifiziert. OK, bin ja schon still :duck:

[Luckie]

Zitat:

Zitat von Daniel

Die Klasse "TRegIniFile" imitiert die Schnittstellen der guten, alten INI-Datei.

Das wollte ich eigentlich damit ausdrücken.

[wido]

Zitat:

Zitat von Daniel

An der tatsächlich verrichteten Arbeit ist nichts auszusetzen, nur sind die Möglichkeiten, auf diesen Vorgang einzuwirken, viel zu gering.

Sorry da jetzt OT werden zu müssen, aber an der dort verrichteten Arbeit ist sehr wohl was auszurichten. Immerhin werden alle Registry Operationen auf den Rootkey ausgeführt, wenn der beim Create übergebene Pfad zum Schreiben nicht geöffnet werden konnte. Ist vielleicht durchaus nur ein subtiler Bug, dafür sind die Ausmaße im Falle eines Auftretens umso größer. Ich verweise da nochmal an den von mir aufgezeichneten Selbstversuch. Aber wahrscheinlich würde niemand jemals darauf kommen "Software" oder einen beliebigen anderen Subkeynamen als Section Name bei TRegIniFile zu verwenden ...

[Daniel]

Is' ja gar nicht so off-topic.

Ich kann den von Dir angesprochenen Fehler momentan nicht entdecken. Hier mal der Auszug aus der .WriteInteger-Methode:

Delphi-Quellcode:

CreateKey(Section);
  Key := GetKey(Section);
  if Key <> 0 then
  try
    OldKey := CurrentKey;
    SetCurrentKey(Key);
    try
      inherited WriteString(Ident, IntToStr(Value));
    finally
      SetCurrentKey(OldKey);
    end;
  finally
    RegCloseKey(Key);
  end;

Zeile 1: Key wird erzeugt, wenn nicht vorhanden
Zeile 2: Key wird abgefragt und ...
Zeile 3: ... nur dann, wenn Key existiert, wird der folgende Code ausgeführt.

Ich sehe das als prinzipiell richtig an - ohne jetzt diese Klasse als Ganzes verteidigen zu wollen.

[DeddyH]

Ööhhmm.. OK, und wie weißt Du nun, ob es geklappt hat?

[Daniel]

Ob es geklappt hat? Och, das ist das Problem des Anwenders. *g*.

Ich war auf wido scharf ... also auf das von ihm angesprochene Problem:

Zitat:

Immerhin werden alle Registry Operationen auf den Rootkey ausgeführt, wenn der beim Create übergebene Pfad zum Schreiben nicht geöffnet werden konnte.

Das konnte ich aus dem Code nicht nachvollziehen.

[wido]

Könntest Du dann mal bitte folgendes probieren?

Kleine Testapp:

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

uses
  registry;

begin
  with TRegIniFile.Create('Software\TestEntry\Test') do
    begin
      WriteString('Subkey', 'Bla', 'Blubb');
      Free;
    end;
readln;
  with TRegIniFile.Create('Software\TestEntry\Test') do
    begin
      WriteString('Subkey', 'Bla', 'Blubb');
      Free;
    end;
readln;
  with TRegIniFile.Create('Software\TestEntry\Test') do
    begin
      WriteString('Subkey', 'Bla', 'Blubb');
      Free;
    end;
readln;
end.

Starten, Registry Editor aufmachen, nach HKCU\Software gehen und die Rechte für den Zugriff auf TestEntry entfernen (Rechtsklick, Berechtigungen, Erweitert, "Vererbbare Berechtigungen einschließen" deaktivieren, Entfernen und den Dialog mit OK bestätigen). Dann Return in der Testapp und den View im Registry Editor aktualisieren. Der Section Name "Subkey" sollte jetzt als Unterschlüssel des Rootkeys HKCU erstellt worden sein inkl. der erwarteten Werte. Wenn Du dort die Rechte auch entfernst wie zuvor, kommt die Exception, die eigentlich vorher schon hätte kommen müssen: "Failed to create key subkey.".

Wäre interessant das mal zu tracen. Hab nur leider keine Sourcen, entsprechend kann ichs nicht selbst testen.

[Daniel]

Hut ab. Das Szenario spielt sich so ab wie von Dir beschrieben. Danke für die Demonstration.
Das ist böse - gerade beim Löschen wird's spaßig.

Okay. Die Klasse gehört auf den Müll.

[DeddyH]

Ihr könnt mich schizophren paranoid nennen, aber ich habe mir angewöhnt, meist Bool' sche Funktionen zu schreiben oder solche Prozeduren, die einen Var-Parameter für evtl. ErrorCodes enthalten. Das zumindest dann, wenn man später auf eine fehlerfreie Abarbeitung vertrauen muss. Das erscheint zwar im ersten Moment viel Schreibarbeit, hilft aber später evtl. enorm bei der Fehlersuche.

[edit] Krankheiten verwechselt :oops: [/edit]

[Dezipaitor]

Zitat:

Zitat von DeddyH

Ihr könnt mich schizophren nennen, aber ich habe mir angewöhnt, meist Bool' sche Funktionen zu schreiben oder solche Prozeduren, die einen Var-Parameter für evtl. ErrorCodes enthalten. Das zumindest dann, wenn man später auf eine fehlerfreie Abarbeitung vertrauen muss. Das erscheint zwar im ersten Moment viel Schreibarbeit, hilft aber später evtl. enorm bei der Fehlersuche.

Wenn du das selbst so machst ist das ok, nach meiner Meinung. Aber wenn das jemand anderes Verwenden soll, dann kann ich dir garantieren, dass der bool-Wert ignoriert wird.

[Popov]

Zitat:

Zitat von Daniel

Ich habe mir mal eben das Demo-Programm abgesehen und dabei einen Blick auf die Klasse "TRegIniFile" geworfen. Ich halte diese Klasse für problematisch, weil sie eben nicht dediziert prüft, wo was falsch gelaufen ist und dies an die Anwendung zurückliefert.

Für die Fehlersuche ist eine direkte Verwendung der Klasse TRegistry geeigneter, da man hier Operation für Operation auf Ihren Erfolg hin prüfen kann:

TRegistry.Create
TRegistry.RootKey = _XY_
KeyExists
CreateKey
OpenKey
Read_XYZ_
Write_XYZ_
CloseKey

Danach ist unmittelbar klar, wo es beim Anwender knallt und oftmals ergibt sich dann aus der Situation auch direkt die Ursache für das Fehlverhalten.

Hallo Daniel, deine Ausführungen sind zum Teil richtig, zum Teil leider unrichtig.

Du, wie zum Teil die anderen, sehen die TRegIniFile im ganzen Zusammenhang der Registry und dann sagt ihr euch, daß sie zu wenig Möglichkeiten liefert. Das ist nicht richtig, denn die TRegIniFile arbeitet nur in dem Bereich HKCU/Software. Würde ich mit TRegIniFile versuchen auf die ganze Registry zugreifen zu wollen, du hättest dann Recht, denn dann könnte man über zu wenig Möglichkeiten sprechen. Es ist ja nicht so als ob ich nur die TRegIniFile nutze. Im Schnitt nutze ich die TRegistry wohl öfters wenn ich allgemein mit der Registry arbeite, aber hier geht es nur um den einen Pfad. Und das besondere an dem Pfad ist, daß man hier wiederum einiges an möglichen Fehlern ausschließen kann. Und es ist das was ich versuche klar zu machen.

Die HKCU/Software ist in der Regel nicht schreibgeschützt, bzw. in Rechten eingeschränkt. Man hat dort die Möglichkeiten die Rechte einzuschränken, weil es ein Teil der Registry ist und man für die HKCU keine Sonderregeln erst5ellen wollte, aber die HKCU/Software hat keinerlei Bereiche mit geringeren Rechten. Ist ja auch unnötig, da die HKCU abhängig vom Konto ist. Jedes Konto hat seine eigene HKCU. Wechsele ich das Konto, habe ich eine andere HKCU. CU bedeutet Current User. Das sage ich so deutlich, denn das muß man sich erst bewust machen. Die HKCU/Software ist also nicht in Rechten eingeschränkt wie andere Teile der Registry. Bei den anderen Teilen der Registry kann einem doch tatsächlich passieren, daß man zwar lesen kann, aber nicht schreiben, oder, daß man garnichts darf. Bei der HKCU/Software kann es das nur theoretisch passieren. Somit entfällt die Notwendigkeit Fehler abzufangen, denn es kann keine Fehler geben. Fehler kann es nur geben wenn die Festplatte voll ist. Aber dann ist es wohl das kleinste Problem und völlig uninteressant ob die Einstellungen nicht gespeichert werden konnten. Die zweite Fehlermöglichkeit ist auch nur eher theoretisch. Theoretisch kann man den Pfad in Rechten einschränken. Aber wer tut das? Wozu? Da jedes Konto eine eigene HKCU hat, kann kein anderes Konto Zugriff auf den Teil der Registry erlangen. Rechteverwaltung ist also unnötig. Ich kann ALLEN die Rechte nehmen, selbst den Admins, und die werden nie Probleme haben, denn ein Admin wird nie deswegen Problem haben, denn er er hat überhaupt keine Möglichkeit auf diese HKCU zuzugreifen.

Die HKCU/Software hat einen gewissen Sonderstatus gegenüber den anderen Teilen der registry, denn dieser Bereich ist ein von Microsoft garantierter Bereich. Auf diesen Bereich kann man immer zugreifen und wird nie Probleme bekommen. Die Probleme sind nur theoretisch. Wozu soll ich also irgendwo auf Fehlersuche gehen wo es überhaupt keine Fehler geben kann? Ich bin ein wenig gespalten über die Herren die hier meinen mich aufklären zu müssen, denn anscheinend haben die keine Ahnung über diesen Teil der Registry. Eigentlich müßte ich erschrocken sein. Wenn die keine Ahnung von der HKCU/Software haben, dann kann man annehmen, daß sie ihre Einstellungen an jeden Teil der Registry schreiben. Und wenn sie sie in HKCU/Software schreiben, dann nur zufällig, weil sie vielleicht gehört haben, daß auch die anderen es so machen. Dabei kann es bei der HKCU/Software unter üblichen Umständen keine Fehler geben.

Nun betrachten wir mit diesem Wissen die TRegIniFile noch einmal. Die TRegIniFile hat keine Fehlerabfragen, weil es nicht geplannt ist, daß es Fehler gibt. Noch ein malfür alle die es nicht verstanden haben: im Gegensatz zu anderen bereichen der Registry hat man auf HKCU/Software immer Zugriff. Dieser Bereich soll die INIs ersetzten, er sollte den Windowsordenr entlasten, also hat Microsoft dem Konto volle und uneingeschränkte Rechte über diesen Teil der Registry gegeben. Wieso wissen es die Leute, die Programmierer, die hier meckern das nicht? Ich möchte mal einen sehen der unter normalen Umständen, d.h. ohne die Registry manipuliert zu haben, in diesem Bereich Probleme hatten. Gibt es nicht.

Also Daniel, wie du siehst stellt sich die Frage nach mehr Möglichkeiten der TRegistry garnicht. Wer in HKCU/Software mit TRegisry arbeitet und Fehler abfrag, der hat keine Ahnung was er da macht. Und da ich bei TRegIniFile mit Create und Free alles korrekt einleite und freigeben, besteht auch hier kein Grund zu Sorge.

Letztendlich kann man TRegIniFile nur die wenig Möglichkeiten vorwerfen, d.h. sie kann letztendlich nur Strings speichern und lesen, aber das ist ein anderes Thema und wenn ich was anderes brauch, dann werde ich es schon nehmen.

Ich hoffe jetzt einige aufgeklärt zu haben. Bevor man etwas kritisiert, sollte man es kennen. Das ist wie mit den Auto und dem Fallschirm. Im Auto brauche ich nun mal keinen Fallschirm, auch wenn theoretisch die Möglichkeit besteht, daß ich mal über eine Schlucht stürze. Das gleiche ist auch mit TRegIniFile. Es besteht die theoretische Möglichkeit, daß die Festplatte voll ist und dann kriege ich keine Fehlermeldung. Aber genau sowenig wie ich bei Autofahren einen Fallschirm brauche, brauche ich bei TRegIniFile eine Fehlermeldung.

Ich hoffe, daß es jetzt keine Unklarheiten mehr gibt. Ansonsten bin ich für Rückfragen gerne bereit. Und für alle Profis die sich jetzt in der Ehere gekränkt fühlen: man kann nicht alles wissen. Es gibt auch Bereiche wo ich keine Ahnung habe.

[Popov]

Zitat:

Zitat von Luckie

Genau das versuchen wir Popov seit dem ersten Posting klar zu machen. Aber er weigert sich ja beharrlich eine Alternative in betracht zu ziehen.

Siehe oben.

Zitat:

Ich meine nicht das Feedback von deinen Kunden, sondern ein Feedback von Windows in Form einer Fehlermeldung! Aber so lange du auf dieser komischen TregistryIni-Klasse beharrst, wirst du das nie bekommen.

Du äußerst dich über etwas was du nicht kennst.

Zitat:

Selbst Borland ist nicht unfehlbar. Menschen machen Fehler, das liegt in ihrer Natur.

Wie gesagt, ich nutze meine Unit (die natürlich die TRegIniFile) seit sechs Jahren in eigentlich allen meinen Programmen. Der Grund ist, daß ich sofort und ohne Aufwand, meine Einstellungen an die richtige Stelle gespeichert kriege. Die TRegistry nehme ich nur wenn ich etwas außerhalb des Pfades mache. Ich hab bei sechs Jahen und 500.000 Zugriffen noch keinen einziges Mal ein Problem gehabt (zumindest bei Win 98 und XP). Ich schätze das sagt alles. Wir brauchen uns nach 500.000 fehlerfreien Zugriffen wohl keine Gedanken über Bugs machen, oder?

Zitat:

Doch, denn dann würde GetLastError Fehlercode 5 ("Zugriff verweigert") zurückgeben und du wüsstest, warum es nicht funktioniert.

Würdest du die TRegIniFile besser kennen, du würdest es nicht behaupten.

[Popov]

Zitat:

Zitat von Daniel

nur sind die Möglichkeiten, auf diesen Vorgang einzuwirken, viel zu gering. Das Beginnt bei der expliziten Wahl der Zugriffsrechte

Wie schon gesagt, die TRegIni File arbeitet NUR in HKCU/Software und dort gibt es nichts für Zugriffsrechte. Problem ergibt sich überhaupt nicht.

Zitat:

und gipfelt eben - wie in diesem Fall - an der Fehlerbehandlung, die in einem "geht" bzw. "geht nicht" mündet.

Soweit die Festplatte nicht voll ist oder sich ein Kollege einen Scherz erlaubt und einem bewußt Rechte einschenkt, funktioniert der Zugriff IMMER.

Die Punkt wieso ich hier trotzdem gefragt habe, war nicht allgemeiner Natur, weil ich Probleme unter XP habe, sondern die Frage war ob Vista den Bereich HKCU/Software inzwischen anders handhabt als XP. Erst bei ja, unter Vista hat man da nicht volle Rechte, könnte man über Alternativen und Fehlerabfangen sprechen. Unter XP besteht keine Notwendigkeit für eine Fehlerroutine.

Und noch was (ist nicht an dich gerichtet) - ich behaupte allen ins Gesicht, daß keiner in seinem Programm solche Abfragen IMMER und bei JEDEM Zugriff einbaut. Das wäre gelogen. Ich kenne die Leute und weiß wie faul Programmier sind. Wenn überhaupt, dann wird das nur in Ausnahmen oder "besseren" Programmen eingebaut. Bei mir dagegen ist selbst das kleinste und unwichtigste Programm 100% XP Kompatibel.

[Popov]

Zitat:

Zitat von wido

Zitat:

Zitat von Daniel

An der tatsächlich verrichteten Arbeit ist nichts auszusetzen, nur sind die Möglichkeiten, auf diesen Vorgang einzuwirken, viel zu gering.

Sorry da jetzt OT werden zu müssen, aber an der dort verrichteten Arbeit ist sehr wohl was auszurichten. Immerhin werden alle Registry Operationen auf den Rootkey ausgeführt, wenn der beim Create übergebene Pfad zum Schreiben nicht geöffnet werden konnte. Ist vielleicht durchaus nur ein subtiler Bug, dafür sind die Ausmaße im Falle eines Auftretens umso größer. Ich verweise da nochmal an den von mir aufgezeichneten Selbstversuch. Aber wahrscheinlich würde niemand jemals darauf kommen "Software" oder einen beliebigen anderen Subkeynamen als Section Name bei TRegIniFile zu verwenden ...

Entschuldige wenn ich es sage, aber du erzählst Bullshit. Du hast ein Programm das du anscheinend nicht deuten kannst und deutest irgend etwas. Keine Angst, ich hab genug Erfahrung in dem Bereich. Das was du sagst ist unmöglich. Eigentlich müßtest du, wenn du ein wenig Ahnung von der Materie hast, sehen, daß es unmöglich ist. Ich hab dir den Save Code gezeigt. Dieser Code ist zwischen meinem Programm und TRegistry. Sonst ist da nichts. Siehst du in dem Code irgendwelche unkontrollierten Zugriffe? Ich nicht. Das bedeutet, daß die Zugriffe die du in deinem Programm gesehen hast nicht von der TRegIniFile kommen. 100% nicht. Also was erzählst du da für ein Unsinn? Ich denke, daß du voller Freude glaubst etwas entdeckt zu haben, ist aber nicht so. Wieso das so ist kann ich dir zwar auch nicht sagen, vielleicht arbeitet Vista anders und emuliert inzwischen den Softwarepfad intern, aber von dem Ergebnis wiird alles korrekt gehandhabt. Und bevor du nochmal irgendwelche Vermutungen äußerst, solltest du mehr bieten, als eine Screenshot eines Programms welches du nicht deuten kannst.

[Medium]

Ich habe glaube ich bislang niemals zuvor jemanden hier gesehen, der im ersten Posting eine Frage stellt, nur um 5 Seiten lang danach sämtlichen Antwortern vor das Schienbein zu treten, was ihnen denn einfiele sinnvolle Vorschläge zu machen, dein Programm wäre doch perfekt!
Und da dein Programm, wie du selbst professionell nachgewiesen hast, die höchste Gütestufe die ein sterblicher je erreichen könnte hat, gibt es auch kein Problem zu lösen. Zumindest behauptest du das hier. Dann leb' eben mit deinem perfekten Programm, aber tu nicht so, als würdest du von so kleinen Kreaturen wie uns Hilfe benötigen.

Mir ist schon ganz schwindlig vom ganzen Kopfschütteln, echt unglaublich.

[Luckie]

Zitat:

Zitat von Popov

Die TRegIniFile hat keine Fehlerabfragen, weil es nicht geplannt ist, daß es Fehler gibt.

:wall:
Na dann ist doch alles in Butter und der Heilige Geist in Patschen ist daran Schuld, dass bei manchen Benutzern anscheinend nichts gespeichert wird.

Zitat:

Zitat:

Ich meine nicht das Feedback von deinen Kunden, sondern ein Feedback von Windows in Form einer Fehlermeldung! Aber so lange du auf dieser komischen TregistryIni-Klasse beharrst, wirst du das nie bekommen.

Du äußerst dich über etwas was du nicht kennst.

Wieso? Du erzählst uns doch immer, dass TRegIniFile alle Fehler einfach verschluckt.

Zitat:

Wie gesagt, ich nutze meine Unit (die natürlich die TRegIniFile) seit sechs Jahren in eigentlich allen meinen Programmen.

In der Zwischenzeit sind drei Betriebssysteme von Microsoft erscheinen und es hat eine Entwicklung statt gefunden.

Zitat:

Ich hab bei sechs Jahen und 500.000 Zugriffen noch keinen einziges Mal ein Problem gehabt (zumindest bei Win 98 und XP). Ich schätze das sagt alles. Wir brauchen uns nach 500.000 fehlerfreien Zugriffen wohl keine Gedanken über Bugs machen, oder?

Du willst es nicht verstehen oder? Vista ist nicht XP und schon gar nicht 98!

Zitat:

Zitat:

Doch, denn dann würde GetLastError Fehlercode 5 ("Zugriff verweigert") zurückgeben und du wüsstest, warum es nicht funktioniert.

Würdest du die TRegIniFile besser kennen, du würdest es nicht behaupten.

Herr im Himmel hilf mir. Fakt ist, dass anscheinend nichts gespeichert wird. Du, ich und wir alle wollen jetzt herausfinden, warum nichts gespeichert wird. Richtig? So. Nur hilft es uns nicht, wenn du uns andauernt die ach so tollen Vorzüge von TRegIniFile predigst, da die Klasse, wie du selbst sagt, alle Fehler einfach verschluckt. Wir drücken bei unserem Patienten also über all rum und der sagt uns nicht, wo es ihm weh tut. Ergo können wir ihm auch nicht helfen.

Zitat:

Zitat von Popov

Erst bei ja, unter Vista hat man da nicht volle Rechte, könnte man über Alternativen und Fehlerabfangen sprechen. Unter XP besteht keine Notwendigkeit für eine Fehlerroutine.

Offensichtlich sind wir hier alle der Meinung, dass es da keine Probeme geben dürfte. Jetzt wäre es an dir mit einer entsprechenden Fehlerbehandlung dies zu überprüfen. Warum um Herr Gotss Willen sträubst du dich so davor?

Zitat:

Und noch was (ist nicht an dich gerichtet) - ich behaupte allen ins Gesicht, daß keiner in seinem Programm solche Abfragen IMMER und bei JEDEM Zugriff einbaut. Das wäre gelogen. Ich kenne die Leute und weiß wie faul Programmier sind. Wenn überhaupt, dann wird das nur in Ausnahmen oder "besseren" Programmen eingebaut. Bei mir dagegen ist selbst das kleinste und unwichtigste Programm 100% XP Kompatibel.

Keinen Kommentar.

[Popov]

Zitat:

Zitat von Daniel

Hut ab. Das Szenario spielt sich so ab wie von Dir beschrieben. Danke für die Demonstration.
Das ist böse - gerade beim Löschen wird's spaßig.

Okay. Die Klasse gehört auf den Müll.

Nicht so schnell mit den scheuen Pferden. Das was wido hier vorgeführt hat ist ein billiger Trick. Warum? Das steht hier:

Zitat:

Zitat von wido

Starten, Registry Editor aufmachen, nach HKCU\Software gehen und die Rechte für den Zugriff auf TestEntry entfernen (Rechtsklick, Berechtigungen, Erweitert, "Vererbbare Berechtigungen einschließen" deaktivieren, Entfernen und den Dialog mit OK bestätigen). Dann Return in der Testapp und den View im Registry Editor aktualisieren. Der Section Name "Subkey" sollte jetzt als Unterschlüssel des Rootkeys HKCU erstellt worden sein inkl. der erwarteten Werte. Wenn Du dort die Rechte auch entfernst wie zuvor, kommt die Exception, die eigentlich vorher schon hätte kommen müssen: "Failed to create key subkey.".

Wido hat die Rechte manipuliert. Ich hab weiter oben geschrieben, daß das einer der theoretischen Möglichkeiten ist, in der Praxis aber nicht vorkommt. Warum nicht? Weil die HKCU Kontoabhängig ist. Jedes Konto hat seine eigene HKCU. Das ist nicht wie in anderen Teilen der Registry wo User A und User B den gleichen Wert nutzen können und man deshalb mit Zugriffsrechten arbeitet. Bei HKCU kann nicht mal der Administrator (vorausgesetzt er macht es aus seinem eigenem Konto) auf die HKCU des Users A oder B zugreifen. Und weil es so ist, besteht überhaupt keinerlei Notwenigkeit für Zugriffsbeschränkungen. Die Zugriffskontrolle regelt Windows selbst. User A bekommt seine eigene HKCU, User B auch die eigene. Aus diesem grund besteht also nicht die Notwendigkeit bei der HKCU des USer A für User B etwas einzuschrenken. Wenn man will kann man User B alle rechte geben. Er wird trotzdem nicht auf die HKCU des Users A zugreifen können Deshalb hat HKCU immer die nötigen Zugriffsrechte. wido hat in seinem Wahn etwas beweisen zu wollen das mit der Registry gemacht, was nie in der Praxis vorkommen wird. Er ist in die Regisry gegangen und hat mit voller Absicht die Rechte beschränkt. Und dann hat er sein Programm ausgeführt und sagte: bitteschön.

Wie ich schon gesagt habe, um die TRegIniFile zu begreifen muß man erst um den besonderen Status der HKCU wissen. Wenn man sie für ein beliebiges Teil der Registry hält, dann hat man keine Ahnung. Das Beispiel von wido ist nur theoretisch möglich. In der Praxis sind aber die Rechte nicht beschränkt.

Kleine Infostunde: man stelle sich vor, man arbeitet mit einem eingeschränktem Konto. Dann will man etwas installieren und man macht das in seinem eing. Konto über RunAs und das Adminkonto. Gesagt, getann, das Programm wurde installiert und auch gleich die SN eingegeben. Die wurde in in der HKCU abgelegt. Frage, ist das Programm auchg für das eigene Konto freigeschaltet? Nein, denn es wurde in der HKCU des Adminkontos angelegt. Eine All Users UKCU gibt es auch nicht. Jeder User hat seine eigene HKCU und die hat IMMER voller Rechte, es seiden es kommt Wilo und schrenkt sie über den RegEditor ein ;)

Also wilo, ein netter Trick und du hast doch tatsächlich einige beeindruckt, sogar den Forenadmin. Aber jetzt bin ich da. Zeig mir mal den Trick nochmal, allerdings ohne künstliche Manipulation der Registry. Dafür darfst du dich aller meine Konten bedienen. Es sind 4 Konten, zwei Adminkonten und zwei mit eing. Rechten. Du darfst alle Tricks nutzen, bis auf die Festplatte voll machen und die Rechte der HKCU künstlich beschränken, was in der Praxis nicht vorkommt.

Ich warte.

[Popov]

Zitat:

Zitat von Medium

Ich habe glaube ich bislang niemals zuvor jemanden hier gesehen, der im ersten Posting eine Frage stellt, nur um 5 Seiten lang danach sämtlichen Antwortern vor das Schienbein zu treten,

Tut mir leid, aber es gab nur einen, vielleicht auch zwei Leute die auf die Frage eingegangen sind. Die Frage war nicht was ich machen soll, weil mein Programm nicht funktioniert, sondern ich fragte ob es bei Vista Unterschiede in dem Bereich zu XP gibt. Da ist so als ob ich in einem KFZ Forum die Reifen angesprochen hätte und man sich dann den Rest des Threads darüber unterhalten würde ob Benzin oder Diesel besser ist. Daß es bei der Frage um Reifen ging, daß ist dir anscheinend nicht aufgefallen ;)

[Popov]

Zitat:

Zitat von Luckie

Zitat:

Zitat von Popov

Die TRegIniFile hat keine Fehlerabfragen, weil es nicht geplannt ist, daß es Fehler gibt.

:wall:
Na dann ist doh alles in Butter und der heilige geist in Patschen ist daran Schuld, dass bei manchen Benutern anscheinend nichts gespeichert wird.

*LOL* Ich weiß nicht wie ich auf dich eingehen soll ohne dir weh zu tun. Du weißt doch wie aufbrausend ich sein kann. Wenn ich also nach so einem Satz zu dir immer noch freundlich bin, dann kannst du dir was drauf einbilden. Auch wenn wir nicht immer der gleichen Meinung waren in der Vergangenheit, so habe ich immer deine Kenntnis bezüglich Systemprogrammierung respektiert. Hier aber gibst du Kommentare ab ohne das Problem zu verstehen. Und man kann nicht behaupten, daß ich einige hier nicht aufgeklärt habe. Fehler können in der Registry passieren, aber eigentlich nur wegen Zugriffsbeschränkungen oder fehlendem Speicherplatz. Das erste kann hier aber nur theoretisch passieren. Würdest du das begreifen, würdest du erkennen, daß es kaum möglich ist Fehler zu machen.

Zitat:

In der Zwischenzeit sind drei Betriebssysteme von Microsoft erscheinen und es hat eine Entwicklung statt gefunden.

Jep, aber ich arbeite mit Delphi 7 und die ist was XP eingeht auf dem neusten Stand. Wo siehst du da Probleme? Wenn ich mit Delphi 3 ankommen würde, dann könntest du zumindest sagen, daß es damals noch kein XP gab. Aber wir sprechen von Delphi 7 und einer überarbeiteten Version von TRegIniFile.

Zitat:

Du willst es nicht verstehen oder? Vista ist nicht XP und schon gar nicht 98!

Acha, endlich, nach sechs Seiten nähern wir uns endlich der Frage im ersten Beitrag. Die Frage war, gibt es in diesem Bereich zwischen Vista und XP unterschiede. Das war die Frage ;)

Zitat:

Herr im Himmel hilf mir. Fakt ist, dass anscheinend nichts gespeichert wird. Du, ich und wir alle wollen jetzt herausfinden, warum nichts gespeichert wird. Richtig?

NEIN. Ich schreibe es vorsichtshalber groß, damit man es nicht übersieht. Nein, es gibt keine Speicherprobleme. Von XP nutzern habe ich bisher noch NIE eine Meldung bekommen. Auch kommt die Meldung nicht von allen Vista Nutzern. Nur eine Handvoll hat sich beschwert. Um ehrlich zu sein frage ich mich inzwischen ob es überhaupt Speicherprobleme gibt. Eventuell sind es andere Probleme und die Leute deuten es als Speicherprobleme. Wie gesagt, ich konnte den Fehler unter den anderen Vista Nutzern nicht reproduzieren.

Also, so wie du es ausgedrückt hast ist es nicht. Es gibt keine Speicherproblem.

Zitat:

So. Nur hilft es uns nicht, wenn du uns andauernt die ach so tollen Vorzüge von TRegIniFile predigst, da die Klassem, wie du selbst sagt, alle Fehler einfach verschluckt. Wir drücken bei unserem Patienten also über all rum und der sagt uns nicht, wo es ihm weh tut. Ergo können wir ihm auch nicht helfen.

So, theoretisch könnte ich das natürlich machen. Es würde mich nur ein Lächeln kosten. Aber merkst du was? Würde ich es machen, würde ich das Problem nur mit Spucke und Kleister zusammenfrikeln. Um eine Registry Routine zu schreiben die mit Fehlermeldungen gibt brauche ich kein Forum, das kriege ich auch alleine hin. Was ich seit 6 Seiten wissen will ist - wieso gibt es diese Fehler überhaupt. Was ich mir erhofft habe waren Hinweise (keine Tipps) wie z.B. daß Vista den Zugriff auf die HKCU/Software einschränkt. Das wäre eine Info. Wenn dem so wäre, dann keine Angst, das Programm wäre schon längst umgeschrieben. Dafür würde ich 10 Minuten brauchen. Wobei 3/4 der Zeit für Kommentare draufgehen würden. Aber die Info habe ich nicht bekommen. Stattdessen wir mir erzählt, daß ich eine Fehlerabfrage einbauen soll. Ich frage daraufhin wo da Fehler passieren können. Und dann kriege ich die qualifizierten Antworten, wie - naja, wir glauben, daß da Fehler kommen könnten. Was ist das hier? Eine Kirche und wir diskutieren über Glaubensfragen oder ein Delphiforum in dem man fakten gesagt bekommt?

Zitat:

Keinen Kommentar der Zeit für Kommentar.

Wieso zitierst du es dann ;)

[Popov]

Ok, mir ist gerade beim lesen des letzten Postings etwas aufgefallen. Vielleicht kommen die unterschiedlichen Sichtweise wegen der unterschiedlichen Art der Programmierung. Ich hab glaube ich bereits auf der zweiten Seite etwas über mich geschrieben was wichtig ist, aber anscheinend nicht richtig herausgestellt:

Ich mag keine Fehlermeldungen. Zumindest keine System-Fehlermeldungen. Ich hab da eine gewisse Abneigung dagegen. Andere arbeiten mit ihnen, ich versuche sie zu vermeiden. Wenn ich programmiere, dann versuche ich alle möglichen Problem schon vorher abzufangen. Genanntes Beispiel war - bevor ich eine Text Datei in die Memo lade, prüfe ich ob es die Datei überhaupt gibt. Das wäre eine von den möglichen Abfragen die ich einbaue bevor ich den Text lade und das Risiko eingehe, daß die Datei nicht da ist. Ich könnte mir das sparen und den Ladevorhang in try except einbauen und dann die Fehlermeldung auswerten.

Worauf ich hinaus will. Wie man ein Fehler abfängt ist mir schon klar, aber ich möchte den Grund für den Fehler wissen.

Mir geht es nicht wie ich einen Fehler hier abfrage, sondern was könnte der Grund sein wieso einige die Probleme haben.