CMD mit Output

[Willie1]

Hallo Leute,
wie immer, werde ich hier im Forum fündig. Suchte nach CMD mit Output:

https://www.delphipraxis.net/169697-...t-ausgabe.html

Michael (Alleinherrscher) ist ja fleißig gelobt worden, dem kann ich mich nur anschließen. Aber ein Haar in der Suppe habe ich gefunden: der Parameter "ver" wird ignoriert. "help ver" funktioniert richtig. Warum wird bei "ver" einfach nichts angezeigt?


Gruß Willie.

[HolgerX]

Hmm..

Das hat nichts mit den Source von Michael zu tun!

Zitat unbekannter Herkunft:

(*
Um Kommandozeilenbefehle ausführen zu können, die keine eigenständigen
Anwendungen sind (wie der DOS-Befehl “dir”), muss der
Name des Kommandozeileninterpreters davor stehen. “cmd.exe” ist das unter
Windows NT/2000/XP/.. und “command.com” unter Windows 9x. Der Parameter /c sorgt
dafür, dass der Kommandozeilenbefehl ausgeführt und die Kommandozeile
anschließend wieder geschlossen wird.
*)

Somit verwende 'cmd.exe /A /C ver' und dessen Ausgabe wird in deinem Memo erscheinen.

[Willie1]

... ich finde Michaels Quelltext gut.

Obwohl er mir nicht weiterhilft. Das mit /c wusste ich, aber egal, ob mit /a oder /c oder ohne, es passiert nichts. Seit irgeneinem Windows-Update funktioniert die Console nicht mehr, wie gewohnt. Das hatte ich vor über einem Jahr beim Einbau von Exiftool (von Phil Harvey) in ein eigenes Programm erkennen müssen.
Könnte es sein, dass Microsoft cmd durch Powershell ersetzt. Zur Zeit gibt es ja beides.
Gruß Willie.

[Rudy Velthuis]

Zitat:

Code:

(*
  Um Kommandozeilenbefehle ausführen zu können, die keine eigenständigen
  Anwendungen sind (wie der DOS-Befehl “dir”), muss der
  Name des Kommandozeileninterpreters davor stehen. “cmd.exe” ist das unter
  Windows NT/2000/XP/.. und “command.com” unter Windows 9x. Der Parameter /c sorgt
  dafür, dass der Kommandozeilenbefehl ausgeführt und die Kommandozeile
  anschließend wieder geschlossen wird.
*)

Man sollte einfach den Inhalt der Environment-Variable COMSPEC benutzen. In meinem Fall ist das

Code:

ComSpec=C:\Windows\system32\cmd.exe

Und nein, Powershell ersetzt cmd.exe nicht. Beide sollten sich nicht in die Quere kommen.

[HolgerX]

Hmm..

Zitat:

Zitat von Willie1 (Beitrag 1427272)

... ich finde Michaels Quelltext gut.

Obwohl er mir nicht weiterhilft. Das mit /c wusste ich, aber egal, ob mit /a oder /c oder ohne, es passiert nichts. Seit irgeneinem Windows-Update funktioniert die Console nicht mehr, wie gewohnt. Das hatte ich vor über einem Jahr beim Einbau von Exiftool (von Phil Harvey) in ein eigenes Programm erkennen müssen.
Könnte es sein, dass Microsoft cmd durch Powershell ersetzt. Zur Zeit gibt es ja beides.
Gruß Willie.

Anbei ein kleines Testtool, probiere es bei dir aus.
(Erstellt mit D6)
Es erstellt im gleichen Verzeichnis eine kleine Textdatei (CMDs.txt) welche genutzt wird, um sich die DOS-Befehle zu merken ;).

Wenn dieses bei Dir läuft, kann ich den Src noch hier einstellen..

Edit:
Wobei, es benutzt die Funktion von hier:
https://www.delphipraxis.net/164364-...-einlesen.html

[Willie1]

Hallo Holger,
kannst du mir den Quelltext schicken. Ich führe nicht gerne unbekannte Exe-Dateien aus. Danke!
Pf enthält den Pfad zum temporären Ordner. (user\[Name]\apdata\Local\temp) wg. der Schreibrechte.

Delphi-Quellcode:

ShellExecute(0,'open',PWideChar('cmd.exe'),PWideChar('/c ver >'+Pf+'ver.txt'),PWideChar(ExtractFilePath(ParamStr(0))),SW_HIDE);

Auf einem Rechner läuft das, auf einem anderen nicht. Beide habe exakt dasselbe Windows mit dem gleichen Temp-Ordner.

Willie.

[Delphi.Narium]

Was sagt denn der Rückgabewert von ShellExecute aus?

Derweil: Momentan ist absolut unklar, ob ShellExecute scheitert oder Ver oder "nur" die Ausgabe nicht "abgeholt" werden kann.

Geht es darum, die Windowsversion zu erfahren?

Warum dann nicht mit Bordmitteln von Delphi?
z. B. hier (mit mehreren Alternativvorschlägen): https://stackoverflow.com/questions/...indows-version

[Dalai]

Ich würde ja einfach cmd.exe /k mit SW_SHOW Flag ausführen, um zu sehen, woran es genau scheitert.

Grüße
Dalai

[Willie1]

Hallo Leute,
ich will in meiner About-Box die installierte Windows-Version anzeigen. Ich habe es so gemacht:

Delphi-Quellcode:

function WinVersionAPI_asString: string;
var
  osInfo: tosVersionInfo;
begin
  Result := 'unknown';
  osInfo.dwOSVersionInfoSize:= Sizeof( osInfo );
  if DWORD(GetVersionEx( osInfo )) <> 0 then
    with osInfo do begin
      case dwPlatformId of
        VER_PLATFORM_WIN32_WINDOWS :
          Result:='Kein NT-OS';
        VER_PLATFORM_WIN32_NT :
          Result:=Format('%d.%d Built %d %s',[dwMajorVersion,dwMinorVersion,dwBuildNumber,string(szCSDVersion)]);
      end
    end
  //if
end; {WinVersionAPI_asString}

Ich habe hier im Forum gelernt, dass hier nicht immer die richtige Version angezeigt wird. (Manifest). Dann habe ich es mit cmd /c ver >...ver.dat gemacht, das hat ca. 1 Jahr funktioniert jetzt wird nichts mehr angezeigt. Siehe mein Beispiel.
Das war der Sinn meine Anfrage!

Ich will keinen Programm-Code, abhängig von der Windows-Version schreiben, NUR die installierte Windows-Version ermitteln und anzeigen.
Willie.

[Delphi.Narium]

Und wie wäre es damit?

https://www.arclab.com/en/kb/cppmfc/...-registry.html --> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion

https://www.windows-commandline.com/...-from-command/

http://delphidabbler.com/articles?article=23&part=2

In der SysUtils müsste es eigentlich bereits entsprechend befüllte globale Variabeln geben, die man einfach in seine Ausgabe einbauen kann, ohne irgendwas selbst ermitteln zu müssen.

Neben Ver zur Versionsausgabe gibt es auch noch Systeminfo (auf der Kommandozeile).

[Dalai]

Zitat:

Zitat von Willie1 (Beitrag 1427738)

Dann habe ich es mit cmd /c ver >...ver.dat gemacht, das hat ca. 1 Jahr funktioniert jetzt wird nichts mehr angezeigt.

Hast du denn mal meinen Vorschlag umgesetzt, um zu sehen, woran es klemmt?

Davon abgesehen: Wo ist das Problem, ein passendes Manifest in die Anwendung zu packen, so dass GetVersionEx immer die richtigen Werte liefert?

Grüße
Dalai

[TurboMagic]

In der JCL oder JVCL ist auch irgendwo eine ausführliche Routine zur Ermittlung der Windows Version und Variante...

[HolgerX]

Hmm..

Wenn es nur um die Windows-Version geht, dann würde ich mal hier in DP suchen..
.. und schon gibt es einen ausführlichen Thread darüber:

https://www.delphipraxis.net/186147-...mitteln-7.html


Ich verwende die Kernel-Methode, diese funktioniert auch ohne Manifest.. ;)

https://www.delphipraxis.net/1311524-post27.html

[Willie1]

Danke Freunde, Freudinnen sind wohl keine dabei.
Von Systeminfo, sehr umfassend, in der Console hatte noch nie gehört. Das Problem werde ich jetzt mit euren Hinweisen lösen
Gruß Willie.

[Willie1]

Hallo Dalai,
ich werde es so machen und denke, dass es mit Windows 7 bis 10 funktioniert.

Delphi-Quellcode:

begin
  Reg:=TRegistry.Create;
  Reg.RootKey:=HKEY_LOCAL_MACHINE;
  Reg.OpenKeyReadOnly('SOFTWARE\Microsoft\Windows NT\CurrentVersion');
  s:=Reg.ReadString('ProductName');
  s:=s+' '+Reg.ReadString('Releaseid');
  s:=s+'.'+Reg.ReadString('CurrentBuild');
  Label1.Caption:=s;
  Reg.Free;
end;

Willie.

[old7]

uses
ShellApi;

{$R *.dfm}

const
sInfoVersion = 'Version 20191503';

procedure TForm1.ButtonInfoClick(Sender: TObject);
begin
ShellAbout(Handle,
'Windows mit WillieProgramm',
'WillieProgramm ' + sInfoVersion + #13 +
'Copyright 2019 Willie.',
Application.Icon.Handle);
end;

end.

[Willie1]

Hallo,
Die About-Box von Windows will ich nicht benutzen. Zu viel Werbung für Microsoft!
Ich habe jetzt die 3 Methoden, die installierte Windows Version an zu zeigen (Win-API, Console und Registy) zum Laufen gebracht und bringen für Windows 10,8.1,7 und Vista das richtige Ergebnis.

Eine Frage bleibt noch: in der Registry steht das Installationsdatum des OS, es wäre lustig, wenn ich das noch in meine About-Box unterbringen könnte. Wie wird das Datum aus gelesen? Weiß das jemand?
Willie.

[Delphi.Narium]

Das sieht schwer nach 'nem Unix-Timestamp aus, also Sekunden seit 1.1.1970.

Ungefähr sowas?

Delphi-Quellcode:

ShowMessage(DateTimeToStr(UnixToDateTime(Registry.ReadInteger('SOFTWARE\Microsoft\Windows NT\CurrentVersion','InstallDate',0)));

[Willie1]

Hallo, ich bin im Web fündig geworden. Hilft mir aber nicht so richtig weiter.
https://www.it-administrator.de/them...ent/63694.html


Wenn ich den Wert aus der Registry so auslese, wie von dir beschrieben, ergibt das 01.01.1970.
Willie.

[HolgerX]

Hmmm..


Handelt es sich bei deiner Applikation um eine 32 Bit?
Denn dann liest du auf einem 64 Bit Windows bei deiner Reg-Abfrage nicht aus
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion

sondern durch das Redireckt von Windows aus
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\ Windows NT\CurrentVersion

Dort ist das 'InstallDate' dann '0' und somit der 1.1.1970...

Um aus einer 32 Bit App auf den 64 Bit Pfad zuzugreifen musst Du 'KEY_WOW64_64KEY' beim

Reg := TRegistry.Create(KEY_WOW64_64KEY or KEY_ALL_ACCESS);

Verwenden, dann wird auch aus eine 32 Bit App auf 'HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion' zugegriffen.

Hier mal ein Beispiel:

Delphi-Quellcode:

uses
  Registry, DateUtils;

const
 KEY_WOW64_64KEY = $0100;
 KEY_WOW64_32KEY = $0200;

procedure TForm1.Button1Click(Sender: TObject);
var
  Reg: TRegistry;
  tmpInstallDate : Cardinal;
begin
  Reg := TRegistry.Create(KEY_WOW64_64KEY or KEY_ALL_ACCESS);
  try
    Reg.RootKey := HKEY_LOCAL_MACHINE;
    if Reg.OpenKey('\Software\Microsoft\Windows NT\CurrentVersion', False) then
    begin
      tmpInstallDate := Reg.ReadInteger('InstallDate');
      Reg.CloseKey;
    end;
  finally
    Reg.Free;
  end;
  Edit1.Text := DateTimeToStr(UnixToDateTime(tmpInstallDate));
end;

'CurrentVersion' hingegen ist in beiden Zweigen identisch..

[Dalai]

@HolgerX:
Der Code wird in dieser Form ausschließlich mit Adminrechten funktionieren, denn er öffnet den Zweig erstens mit OpenKey (was per default versucht, schreibend zu öffnen) und zweitens im Konstruktur mit KEY_ALL_ACCESS. Schreibzugriff auf HKLM haben nur Admins (und Nutzer, denen die Rechte gegeben wurden). Sehr viel sinnvoller ist es, Schlüssel nur lesend zu öffnen, wenn man nur lesen will:

Delphi-Quellcode:

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

Grüße
Dalai

[HolgerX]

Hmm..

Komisch..

Ich hab hier mein Delphi ohne Admin-Rechte gestartet, genau mit diesem Code..

Läuft!

Admin Rechte brauche ich nur wenn ich wirklich 'schreiben' will..

Aber hast recht, man sollte mit

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

Öffnen...

Das Beispiel war auch einfach nur (schnell) der Delphi-Hilfe entnommen und nur der Pfad und 64bit angepasst..

(Getestet mit D6 auf Win8.1 64Bit)

[Willie1]

Hallo Holger,
dein Quelltext bringt bei mir zunächst das falsche Ergebnis (18.02.1970). Wenn ich

Delphi-Quellcode:

Reg.OpenKey()

durch

Delphi-Quellcode:

Reg.OpenKeyReadOnly()

ersetze, liefert er das richtige Ergebnis. Bravo.
Seit ihr sicher, dass dieses Konstrukt mit allen Systemen ab Windows 7 funktioniert? Es würde ja einen blöden Eindruck machen, wenn meine About-Box hier Unsinn liefern würde. Ich habe nur Rechner mit Windows 10 und Vista. Ich will nicht schon wieder Freunde anhauen müssen, zu testen. Was denkt ihr?
Gruß Willie.

[Willie1]

Holger, noch 2 Nachträge: (Das war ein guter Tipp.)
KEY_WOW64_64KEY ich habe verstanden, er erlaubt den lesenden Zugriff von einem 32-Bit-Prozess auf die 64-Bit Registry. Aber warum können die anderen Werte auch aus der 32-Bit Reg gelesen werden. Meine Vermutung: InstallTime ist eine 64-Bit Zahl!

Mit

Delphi-Quellcode:

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

geht es auch mit

Delphi-Quellcode:

Reg.OpenKey()

Willie.

[hoika]

Hallo,

Zitat:

Ich will nicht schon wieder Freunde anhauen müssen, zu testen

Es bliebt Dir aber nichts anderes übrig.
Es sei denn, Du hast die Betriebssysteme noch da und kannst sie testweise in einer virtuellen Maschine installieren.

[Dalai]

Zitat:

Zitat von Willie1 (Beitrag 1428682)

Meine Vermutung: InstallTime ist eine 64-Bit Zahl!

Mit Sicherheit nicht. Unix Timestamps sind 32 bit lang (und auch noch mit Vorzeichen), daher auch der Wind um den Überlauf im Jahr 2038. Der Grund ist ein anderer: Einmal liest du Werte aus HKLM\Software, das andere Mal aus HKLM\Software\Wow6432Node. Beide Zweige gibt es gleichzeitig, und sie enthalten unterschiedliche Werte/Daten. Schau einfach mal mit Regedit rein, dann wirst du das sehen.

Ach, noch eine Sache: nicht einfach pauschal mit

Delphi-Quellcode:

KEY_READ or KEY_WOW64_64KEY

lesen, sondern abhängig davon, ob das Programm auf einem 64-bit Windows ausgeführt wird oder nicht.

Grüße
Dalai

[HolgerX]

Hmm..

[QUOTE=Dalai;1428684]

Zitat:

Zitat von Willie1 (Beitrag 1428682)

Ach, noch eine Sache: nicht einfach pauschal mit

Delphi-Quellcode:

KEY_READ or KEY_WOW64_64KEY

lesen, sondern abhängig davon, ob das Programm auf einem 64-bit Windows ausgeführt wird oder nicht.

Richtig, ich nutze KEY_WOW64_64KEY nur dann, wenn ich auf einem 64Bit OS bin und auch wirklich auf die 64Bit-Verzeichnisse in der Reg zugreifen will.
Benutzen tue ich es auch unter Win7 64Bit, Vista ignoriere ich und unter XP gab es das WOW64 noch nicht (XP 64Bit ist nie wirkich im Markt erschienen).

Zum Thema 'Wie erkenne ich ein 64Bit OS?' einfach mal hier im Forum suchen, da gibt es mehre Threads...

[Willie1]

Zitat:

Mit Sicherheit nicht. Unix Timestamps sind 32 bit lang (und auch noch mit Vorzeichen), daher auch der Wind um den Überlauf im Jahr 2038. Der Grund ist ein anderer: Einmal liest du Werte aus HKLM\Software, das andere Mal aus HKLM\Software\Wow6432Node. Beide Zweige gibt es gleichzeitig, und sie enthalten unterschiedliche Werte/Daten. Schau einfach mal mit Regedit rein, dann wirst du das sehen.

Dalai

Sieh dir InstallTime in der Registry an, das passt in keine Integer-Zahl!

Ich weiß, Vista ist abgemeldet, aber da hab' ich noch ein 32-Bit-Windows, auch da läuft der Code von Holger korrekt, richtiges Installationsdatum, das ist doch erfreulich.

Willie.

[Dalai]

Zitat:

Zitat von Willie1 (Beitrag 1428800)

Sieh dir InstallTime in der Registry an, das passt in keine Integer-Zahl!

Das hab ich. Und die Zahl 1.477.590.874 passt sehr wohl in einen Integer. Ich will nicht ausschließen, dass dieser Registry-Wert kein Unix Timstamp ist, aber wenn es einer ist, ist er mit Sicherheit maximal 32 bit lang.

Grüße
Dalai

[HolgerX]

Hmm..

Also bei mir in der Registry ist InstallDate als REG_DWORD angelegt und dies entspricht unter Delphi dem Cardinal (0 bis 4.294.967.295).
Ich denke, da passen noch einige Jahre rein ;)

Und UnixToDateTime verarbeitet nen Int64...

[Willie1]

Holger,
es geht um InstallTime nicht InstallDate. InstallTime ist zu groß für Integer auch für Cardinal. Seht es euch an.. Willie.

[Dalai]

Sorry, ich dachte die ganze Zeit, wir reden nur von InstallDate. Mein Win7 hat kein InstallTime in dem genannten Registry-Zweig. Vielleicht eine Neuerung von Win10? Anyway, InstallDate gibt's auch schon bei XP. Insofern ist dieser Wert der wahrscheinlich zuverlässigere.

Und, InstallDate enthält bereits das Datum und die Uhrzeit, eben weil's (sehr wahrscheinlich) ein Unix Timestamp ist.

Grüße
Dalai

[HolgerX]

Hmm..

Und unter meinem WIN8.1 (64Bit) gibt es auch nur 'InstallDate'...

[HolgerX]

Hmm..

So, mal ein bischen recherchiert...

'InstallTime' gibt es nur mit Windows10..

Es ist ein REG_QWORD, somit 64Bit Integer und enthält einen LDAP/FileTime TimeStamp.
Dieser passt unter D6 in einen Int64.

Ich musste meinem D6 erst das Lesen von REG_QWORD beibringen und konnte dann die Zahl mit FileTimeToDateTime in einen DateTime konvertieren.

Delphi-Quellcode:

uses
  Registry, RTLConsts, DateUtils;

const
 KEY_WOW64_64KEY = $0100;
 KEY_WOW64_32KEY = $0200;

const
  REG_QWORD         =  11;

function FileTimeToDateTime(ft: TFileTime): TDateTime; overload;
var
  tzi: TTimeZoneInformation;
  lt, st: TSystemTime;
begin
  GetTimeZoneInformation(tzi);
  FileTimeToSystemTime(ft, st);
  SystemTimeToTzSpecificLocalTime(@tzi, st, lt);
  Result := SystemTimeToDateTime(lt);
end;

function FileTimeToDateTime(ft_Int: Int64): TDateTime; overload;
var
  ft: TFileTime;
begin
  Int64(ft) := ft_Int;
  Result := FileTimeToDateTime(ft);
end;


type
  TRegistryEx       =  class(TRegistry)
  public
    function       ReadInt64(const Name: String): Int64;
    procedure      WriteInt64(const Name: String; Value: Int64);
  end;

{ TRegistryEx }

function TRegistryEx.ReadInt64(const Name: String): Int64;
var  dwType:        DWORD;
     dwSize:        DWORD;
begin
  dwType:=REG_NONE;
  dwSize:=SizeOf(Int64);
  if (RegQueryValueEx(CurrentKey, PChar(Name), nil, @dwType, PByte(@result), @dwSize) <> ERROR_SUCCESS) then
     raise ERegistryException.CreateResFmt(@SRegGetDataFailed, [Name]);
  if (dwType <> REG_QWORD) then raise ERegistryException.CreateResFmt(@SInvalidRegType, [Name]);
end;

procedure TRegistryEx.WriteInt64(const Name: String; Value: Int64);
var  dwType:        DWORD;
     dwSize:        DWORD;
begin
  dwType:=REG_QWORD;
  dwSize:=SizeOf(Int64);
  if (RegSetValueEx(CurrentKey, PChar(Name), 0, dwType, @Value, dwSize) <> ERROR_SUCCESS) then
     raise ERegistryException.CreateResFmt(@SRegSetDataFailed, [Name]);
end;

{ TForm1 }

procedure TForm1.Button1Click(Sender: TObject);
var
  Reg: TRegistryEx;
  tmpInstallDate : Cardinal;
  tmpInstallTime : Int64;
begin
  tmpInstallDate := 0;
  tmpInstallTime := 0;

  Reg := TRegistryEx.Create(KEY_WOW64_64KEY or KEY_ALL_ACCESS);
  try
    Reg.RootKey := HKEY_LOCAL_MACHINE;
    if Reg.OpenKey('\Software\Microsoft\Windows NT\CurrentVersion', False) then
    begin
      tmpInstallDate := Reg.ReadInteger('InstallDate');

      if Reg.ValueExists('InstallTime') then
        tmpInstallTime := Reg.ReadInt64('InstallTime');

      Reg.CloseKey;
    end;
  finally
    Reg.Free;
  end;
  Edit1.Text := DateTimeToStr(UnixToDateTime(tmpInstallDate));
  Edit2.Text := DateTimeToStr(FileTimeToDateTime(tmpInstallTime));
end;

Der Source für TRegistryEx stammt von hier:
https://www.experts-exchange.com/que...-registry.html

Den Link zum FileTimeToDateTime mit Int64 habe ich leider verdaddelt...

[Sherlock]

Zitat:

Zitat von hoika (Beitrag 1428683)

Hallo,

Zitat:

Ich will nicht schon wieder Freunde anhauen müssen, zu testen

Es bliebt Dir aber nichts anderes übrig.
Es sei denn, Du hast die Betriebssysteme noch da und kannst sie testweise in einer virtuellen Maschine installieren.

Es gibt da was von Ratiopharm....äh Microsoft:
https://developer.microsoft.com/en-u...dge/tools/vms/

Damit kann man alle noch offiziell unterstützen Win-Versionen zum Testen von *räusper* IE-Funktionalitäten *Zwinker* herunterladen.

Sherlock

[Willie1]

Hallo Holger, Leverkuseen City, da bin ich gestern gewesen.
Ganze Meine Code, werde es checken. Ich habe das auslesen so gemacht: (es klappt)

Delphi-Quellcode:

procedure TForm1.Button5Click(Sender: TObject);
var
  Reg: TRegistry;
  Buf: array[0..7] of Byte;
  id: uint64;
  idt: TDateTime;
begin
  FillChar(Buf, SizeOf(Buf),0);
  Reg:=TRegistry.Create(KEY_WOW64_64KEY);
  Reg.RootKey:=HKEY_LOCAL_MACHINE;
  if Reg.OpenKeyReadOnly('SOFTWARE\Microsoft\Windows NT\CurrentVersion') then begin
    Reg.ReadBinaryData('InstallTime',Buf,SizeOf(Buf));
//    id:=$1d3ea9f6e412ca2;  so steht's in der Registry
    Move(Buf,id,SizeOf(id));
//  ab hier komme ich nicht weiter!
    Reg.CloseKey;
  end;
  Reg.Free
end;

Dann wird mir deine Function weiter helfen. Es funktioniert!!!
Sherlock, Danke für den Tipp. Ich werde "Ratiopharm" nicht befragen müssen. Einen Freund kann ich nerven und mein Bruder ist manches von mir gewöhnt. Gruß Willie.

[Willie1]

Hallo, jetzt zum letzten Mal dieses Thema!:!:
Das Installationsdatum aislesen klappt jetzt, sowohl mit InstallDate als auch mit InstallTime. Nur mit der Zeitzone komme ich nicht klar Mit SystemInfo ermittelt ist Datum-Zeit 13.05.2018 10:47 . Ohne Anpassung ergibt es 09:47 mit der function hier aus dem Forum 11:47. Was ist jetzt richtig?

Delphi-Quellcode:

function DateTimeToLocalTimeDT(dt: TDateTime): TDateTime;
var
  tzi: TTimeZoneInformation;
  lt, st: TSystemTime;
begin
  GetTimeZoneInformation(tzi);
  DateTimeToSystemtime(dt, st);
  SystemTimeToTzSpecificLocalTime(@tzi, st, lt);
  Result := SystemTimeToDateTime(lt);
end;

Willie.

[Delphi.Narium]

11:47 - Sommerzeit
10:47 - Ortszeit
09:47 - Greenwich mean time (UTC)

[Willie1]

Ach so!
Gestern kam durch Zufall das letzte Release-Update von Windows mit neuem Install-Datum, das stimmt. Ist klar, gestern war noch Normalzeit (Winter). Danke für eure Geduld Willie.

[Rollo62]

<OT>
Hat schon jemand einen Algorithmus für eine ausführliche Funktion "IsSommerzeit" zur Berechnung der Zeitverschiebung geschrieben ?

Müsste ja sowas wie "von bis" und das jeweilige Einführungsdatum der verschiedenen Länder berücksichtigen.

Bisher hat ja vielleicht auch einfach grob "Jahr >= 1980" gut funktioniert.

Wenn angeblich die Sommerzeit demnächst in der EU abgeschafft wird sollte man eventuell jetzt schonmal darüber nachdenken, wie man fehlerfrei die "echte" Zeit fehlerfrei in den jeweiligen Zeitzonen berechnen kann.

Ist zwar zum Glück nicht mein aktuelles Thema, könnte es aber vielleicht schnell mal werden.

</OT>