TRegistry: Unterschied zwischen Konsole und GUI?

[DeddyH]

Hallöle,

gegeben sei folgende Funktion:

Delphi-Quellcode:

function GetTheUltimateAnswer(out Value: string): Boolean;
const
  Key   = 'SOFTWARE\Deep Thought';
  Ident = 'Die Frage nach dem Leben, dem Universum und einfach allem';
var
  Reg: TRegistry;
begin
  Value := '';
  Result := false;
  Reg := TRegistry.Create(KEY_READ);
  try
    Reg.RootKey := HKEY_LOCAL_MACHINE;
    if Reg.OpenKey(Key, false) then
      try
        Value := Reg.ReadString(Ident);
        Result := Value <> '';
      finally
        Reg.CloseKey;
      end;
  finally
    Reg.Free;
  end;
end;

In einem GUI-Programm bekomme ich true und damit einen Wert zurück, in einer Konsolenanwendung nicht (natürlich bei exakt identischem Code). Hat jemand eine Ahnung, woran das liegen könnte?

Nachtrag: mit einem anderen Schlüssel funktioniert das auch in der Konsole, hä? :gruebel:

[Bummi]

42

Rechte?

[DeddyH]

Leserechte sind vorhanden, außerdem ist das ja derselbe User, oder wird ein Konsolenprogramm in einem anderen Kontext ausgeführt? Achja, OpenKey wird noch ausgeführt, nur beim ReadString kommt nix zurück.

[himitsu]

Eventuell bekommt die Konsole andere Rechte, bzw. die (eventuell aktivierte) Virtualisierung greift bei Konsolen anders ein?

Bei Dateioperationen weiß ich z.B. daß dort die OEM-Codepage verwendet wird, wärend GUI-Anwendungen auf ANSI laufen.
(drum sieht WriteLn('ä') etwas komisch aus, bzw FindFirst mit solchen Umlauten wirkt auch nicht unbedingt so, wie gewollt)

AreFileApisANSI
SetFileApisToANSI
SetFileApisToOEM
Vielleicht gibt's sowas auch für die Registry, bzw. es wirkt sich auch auf Diese aus.

[add]
OpenKeyReadOnly?

[DeddyH]

Hmm..., der originale Ident enthält einen Tiefstrich, ob es daran liegt? Aber ist der denn unterschiedlich zwischen Ansi und OEM, zumindest ist mir das nie aufgefallen.

[Bummi]

Reg := TRegistry.Create(KEY_READ OR KEY_WOW64_64KEY );

geht bei mir im nicht Wow6432Node

[DeddyH]

Nochmal: derselbe Code mit demselben Delphi auf demselben System (Vista 32 Business) liefert entweder ein Ergebnis(GUI) oder nicht(Konsole). Wahrscheinlich hat das tatsächlich mit der Zeichenkodierung zu tun, aber bevor ich jetzt mit OEMToCharBuff o.ä. herumhantiere habe ich nun doch ein "normales" VCL-Progrämmchen daraus gemacht. Interessant ist der Effekt trotzdem.

[himitsu]

Du kannst auch das {$APP CONSOLE} aus der Konsolenanwendung entfernen, dann ist es quasi eine GUI-Anwendung, ohne GUI.

Funktioniert es dann?

(Notfalls kann man sich dann über CreateConsole AllocConsole ein Konsolenfenster in seine GUI-Anwendung holen)

[DeddyH]

Tut auch nicht, nur als Standard-VCL-Programm. Komisch, das. Ich probier das jetzt mal mit Umkodieren, weil es mich interessiert.

[edit] Jetzt wird es ganz ulkig: KeyExists liefert auch unter VCL false, ausgelesen wird trotzdem der richtige Wert :shock: [/edit]

[edit2] Logisch, das müsste ja auch ValueExists heißen :oops: [/edit2]

[jaenicke]

Und auch hier wieder mal der Hinweis auf den Process Monitor. ;-) Damit siehst du sofort und ohne Mühe worauf zugegriffen wird...

Damit debugge ich so etwas immer schnell und brauche nicht lange suchen.

[p80286]

Zitat:

Zitat von DeddyH (Beitrag 1174341)

Tut auch nicht, nur als Standard-VCL-Programm. Komisch, das. Ich probier das jetzt mal mit Umkodieren, weil es mich interessiert.

[edit] Jetzt wird es ganz ulkig: KeyExists liefert auch unter VCL false, ausgelesen wird trotzdem der richtige Wert :shock: [/edit]

[edit2] Logisch, das müsste ja auch ValueExists heißen :oops: [/edit2]

Das hätte ich jetzt gerne mal langsam und zum mitschreiben.
solange Du Dich auf 0-9, A-Z und a-z beschränkst ist OEM mit ANSI gleich. Erst bei den Umlauten und den Sonderzeichen wird es interessant. "_" ist auf jeden Fall in beiden Fällen das gleiche.

Gruß
K-H

[DeddyH]

Zitat:

Zitat von p80286 (Beitrag 1174373)

solange Du Dich auf 0-9, A-Z und a-z beschränkst ist OEM mit ANSI gleich. Erst bei den Umlauten und den Sonderzeichen wird es interessant. "_" ist auf jeden Fall in beiden Fällen das gleiche.

Der Auffassung war ich bislang auch. Fakt scheint aber zu sein, dass der Unterstrich den Ausschlag gibt. Eine vorherige Abfrage mit ValueExists ergibt auch noch true, erst das ReadString liefert mir bei einem NonVCL-Programm kein Ergebnis. Lese ich aber im selben Schlüssel einen anderen Wert ohne Unterstrich im Namen aus, funktioniert das wie gewohnt. Woran genau das nun liegt, habe ich nicht weiter verfolgt.

[Ralf Kaiser]

Zitat:

Zitat von DeddyH (Beitrag 1174394)

Lese ich aber im selben Schlüssel einen anderen Wert ohne Unterstrich im Namen aus, funktioniert das wie gewohnt. Woran genau das nun liegt, habe ich nicht weiter verfolgt.

Hast du mal versucht in den beiden Varianten einen Wert mit einem Unterstrich anzulegen und dann mit RegEdit zu vergleichen ob da ein Unterschied besteht?

[DeddyH]

Funktioniert, ob Konsole oder GUI:

Delphi-Quellcode:

procedure TestKey;
const
  KeyName = '\Software\Test\Test';
var
  Reg: TRegistry;
begin
  Reg := TRegistry.Create;
  try
    Reg.RootKey := HKEY_CURRENT_USER;
    if Reg.OpenKey(KeyName, true) then
      try
        Reg.WriteString('A_B', 'Ohne GUI');//oder eben "Mit GUI"
      finally
        Reg.CloseKey;
      end;
  finally
    Reg.Free;
  end;
end;

OK, anderer RootKey, aber daran wird es wohl kaum liegen.

[CCRDude]

Ganz oben stand schon ein Hinweis... wie sieht's denn mit Manifesten (re Virtualisierungsstatus) und Elevation aus?

[DeddyH]

Außer dem Standard-Manifest, das Delphi sowieso einbindet, ist nichts weiter vorhanden. Aber wie bereits erwähnt ist das Problem nur noch ein akademisches, da ich nun doch eine VCL-Anwendung daraus gemacht habe.

[jaenicke]

Wie schon geschrieben:
Wenn du es noch schnell und einfach herausfinden möchtest woran es denn nun lag, brauchst du nur den Process Monitor zu starten und den Filter auf "Processname is DeineExe.exe" zu setzen. Da so viele Registryzugriffe an der Stelle ja nicht passieren, findet man die Stelle im Log auch leicht.

[himitsu]

Wobei die VCL auch so manche Dinge initialisiert, vorallem irgendwelches OLE-Zeugs und sonstewas.

[p80286]

Ich hab mir mal ein paar Fonts in Ansi/OEM angeschaut, Zum einen haben verschiedene Fonts den Unterstrich (bzw. etwas das so aussieht) mehrfach vorhanden, zum anderen varieren die Positionen auch noch. Zuverlässig ist da nur x5F.
Ein Hoch auf dieses codepage Wirrwar und das was man sieht.

Gruß
K-H