OS Version Windows 10 ermitteln.

[Willie1]

Hallo,
die Tatsache, dass die Registry bei CurrentVersion bei Win 10 den falschen Wert 6.3 zurück gibt, zeigt doch, dass MS diesen Reg-Key nicht weiter pflegt Der Weg über CMD liefert dagegen immer das korrekte Ergebnis ohne Verrenkungen, zumindest so lange wie es CMD gibt!
Auf die Diskussion, warum man/frau aus einem Programm heraus die aktuelle Windows-Version wissen will, möchte ich mich nicht einlassen.
Schönen Sonntag
Willie.

[Bernhard Geyer]

Zitat:

Zitat von Willie1 (Beitrag 1311574)

Hallo,
die Tatsache, dass die Registry bei CurrentVersion bei Win 10 den falschen Wert 6.3 zurück gibt, zeigt doch, dass MS diesen Reg-Key nicht weiter pflegt Der Weg über CMD liefert dagegen immer das korrekte Ergebnis ohne Verrenkungen, zumindest so lange wie es CMD gibt!
Auf die Diskussion, warum man/frau aus einem Programm heraus die aktuelle Windows-Version wissen will, möchte ich mich nicht einlassen.
Schönen Sonntag
Willie.

Ist mir aus gerade erst aufgefallen. Damit hat als MS genau das gleiche gemacht wie schon beim IE der auch nicht mehr über die Registry abfragbar ist.

Bliebe nur die Build-Nummer. Hier wäre dann ein IsMaxBuildNummer(xxx) ausreichend.
Damit wäre man (aktuell) sicher tiefgreifende Updates mitzubekommen (müssten ja neue Buildnummern werden), müsst aber Supporttechnisch immer die aktuellen Builds vor der Veröffentlichung testen um sicher zu sen das es klappt. Hätte halt die Gefahr das eine Krankheit/Unfall/Urlaub dazu führt bei einer neuen Version diese nicht rechtzeitig freigeben zu können und dann ebenfalls verklagt zu werden (wegen unverhältnismäßige Behinderung der Nutzung)

[mm1256]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1311578)

Hätte halt die Gefahr das eine Krankheit/Unfall/Urlaub dazu führt bei einer neuen Version diese nicht rechtzeitig freigeben zu können und dann ebenfalls verklagt zu werden (wegen unverhältnismäßige Behinderung der Nutzung)

Perfekte Schlussfolgerung, da stimme ich dir (in diesem Thread) das erste mal voll zu. Und jetzt denke ich wird auch klar, warum das Gedöns mit Versions-Nummern und Build so viele Nachteile hat.

Weiterer Vorteil: Ich kann mich "selber hacken" denn sollte ich mal aus welchen Gründen auch immer nicht mit einem Release nachkommen, hab ich mir in der Zwischenzeit eine Notbremse eingebaut (Nachtrag zu #26)

Delphi-Quellcode:

...
    with TRegistry.Create do
    try
      RootKey := HKEY_LOCAL_MACHINE;
      if OpenKeyReadOnly(rsMyPersonalWinVerRegKey)
      then aWinInfo.ProductName := ReadString('ProductName');
      if OpenKeyReadOnly(rsWinVerRegKey) then begin
        if aWinInfo.ProductName = ''
        then aWinInfo.ProductName := ReadString('ProductName');
...

[FarAndBeyond]

Zitat:

Das hatten wir auch schon. Da hat der Kunde seinen Hardwarelieferanten - der gleichzeitig auch einer meiner Vertriebspartner ist - beauftragt meine Software zu installieren, die aber damals nicht für XP freigegeben war. Dann wurde Monate später festgestellt, dass eine Datei der Datenbank defekt ist. Das Problem bzw. die Ursache war die Datenbank. Dummerweise musste daraufhin eine komplette Inventur neu gemacht werden und einiges mehr. Schaden über 30.000 Euro. Und wer hat das dann bezahlt? Ich, bzw. meine Versicherung, weil der Richter der Meinung war, ein einfacher Hinweis reicht für den Anwender nicht aus, die Tragweite der möglichen Folgen erkennen zu können.

Alter Schwede, wie genau ist nochmal die Definition von "Grob Fahrlässig" ???
Das zeigt einmal mehr das man vor Gericht bestenfalls ein Urteil bekommt und das das Ganze nichts mit Moral, Intelligenz und/oder Ethik zu tun hat, sondern nur mit Geld und Macht.
Mal ehrlich, das ist doch ein Scherz...
Das erinnert an "Raucher verklagt ZigarettenIndustrie..."

Zitat:

die Tragweite der möglichen Folgen erkennen zu können.

Was können denn wohl die Folgen sein, wenn man Software auf einem neuen OS einsetzt, die dafür gar nicht entwickelt worden ist...???
Richtig! Alles Mögliche !!!

Was, ist der Hardwarelieferant außen vor oder was ???
Der Intelligenzquotient wurde für Richter nochmals angepasst... auf die Höhe unterhalb von Toilettenpapier... wat eyh...
Interessant womit man so rechnen muß...

[Perlsau]

Zitat:

Zitat von FarAndBeyond (Beitrag 1326357)

Alter Schwede, wie genau ist nochmal die Definition von "Grob Fahrlässig" ???
Das zeigt einmal mehr das man vor Gericht bestenfalls ein Urteil bekommt und das das Ganze nichts mit Moral, Intelligenz und/oder Ethik zu tun hat, sondern nur mit Geld und Macht. Mal ehrlich, das ist doch ein Scherz... Das erinnert an "Raucher verklagt ZigarettenIndustrie..."

Nein, solche Dinge geschehen tatsächlich. Mir hat vor einigen Monaten ein Auftraggeber indirekt mit einer Schadensersatzklage gedroht, nur weil er selbst bereits terminliche Zusicherungen an Kunden gemacht hatte, bevor die Entwicklung abgeschlossen war. Auslöser war ein unkommentierter Zahlungsverzug, der auch auf Nachfrage nicht aufgeklärt werden konnte, denn er wich diesem Thema tagelang mit allerlei ominösen Antworten aus (von "hab jetzt keine Zeit mehr" bis "muß ich erst in der Buchhaltung nachfragen", und das bei einer OHG, die er und seine Frau betreiben). Daraufhin stellte ich die Remote-Arbeit ein, bis die letzte Rechung beglichen war, und teilte dies mit ... was er dann wiederum zum Anlaß nahm, offiziell die Zahlungen einzustellen, und mir drohte, da er sich selbst angeblich bereits zu Regreßzahlungen genötigt sah. Das war ein derart offensichtliches und durchschaubares Manöver, daß niemand, der das mitbekam, daran zweifelte, daß es lediglich darum ging, nichts mehr zu bezahlen. Das, was noch fehlte, hatte er angeblich in drei Minuten selbst erledigt. Also war die Software fertig bzw. die Arbeit erledigt. Mir entstand dabei ein Schaden von knapp 1400 Euro. Mit diesem Manöver hatte der Kunde meinen Stundenlohn auf eineinhalb Euro gedrückt. Machen kann ich nichts, weil er inzwischen bestreitet, daß ich in den Stunden, die ich abgerechnet habe, überhaupt für ihn gearbeitet hatte. Und hätte ich weiter für ihn gearbeitet, denn täglich kamen neue Anforderungen hinzu, fast wie bei einem festen Arbeitsverhältnis, wäre der Schaden noch größer geworden, denn am Ende hätte er nichts bezahlt. Solche Betrüger gibt es leider mehr als genug, und ich bin leider auch nicht der einzige, den dieser Kunde geschädigt und betrogen hatte, wie ich inzwischen erfahren mußte.

Wenn jemand solches und ähnliches erlebt hat, würden mich Einzelheiten via PM, Mail oder Telefon durchaus interessieren ...

[ergo2000]

Also ich nutze einfach nachfolgende Funktion. Sie funktioniert bei mit allen Windows-Versionen problemlos.

Delphi-Quellcode:

function WMI_Get_Betriebssystem(const mit_Version:boolean=false):shortstring;
const[INDENT][/INDENT]wbemFlagForwardOnly = $00000020;

var  
  FSWbemLocator : OLEVariant;
  FWMIService   : OLEVariant;
  FWbemObjectSet: OLEVariant;
  FWbemObject   : OLEVariant;
  oEnum         : IEnumvariant;
  iValue        : LongWord;

begin
  Result:='?';
  try
  FSWbemLocator := CreateOleObject('WbemScripting.SWbemLocator');
  FWMIService   := FSWbemLocator.ConnectServer('localhost', 'root\CIMV2', '', '');
  FWbemObjectSet:= FWMIService.ExecQuery('SELECT Name, Version FROM Win32_OperatingSystem','WQL',wbemFlagForwardOnly);
  oEnum         := IUnknown(FWbemObjectSet._NewEnum) as IEnumVariant;
  if oEnum.Next(1, FWbemObject, iValue) = 0 then
           begin
            result:=String(FWbemObject.Name);
            if Pos('|',result)>0 then
               result:=copy(result,1,Pos('|',result)-1);


            if Pos('Microsoft ',result)>0 then
                  Try
                   result:=trim( copy(result,Pos('Microsoft ',result)+10,40));
                  except
                  end;

            if mit_Version then
               begin
                result:=result+'  [ '+String(FWbemObject.Version)+' ]';
               end;

            FWbemObject:=Unassigned;
           end;
  except

    try
     Result:=WMI_Get_Betriebssystem;
    except
      Result:='?';
    end;

  end;
end;

Der Code stammt urspünglich irgenwo von "theroadtodelphi" oder "delphifeeds" oder so.

Ralf

[Willie1]

Hallo,
ab Windows 10 wird auch in der Registry nicht mehr der richtige Wert angezeigt!

Hat sich erledigt, zitiere mich selbst.

[Luckie]

Auch nicht mit passenden Manifest in der Anwendung? Da war doch mal was, wenn ich mich recht entsinne.

[CHackbart]

Also mit dem korrekten Manifest liefert GetVersionEx für die Major- und Minorversionsnummer unter Windows 10 den passenden Wert.

[bra]

Zitat:

Zitat von CHackbart (Beitrag 1326617)

Also mit dem korrekten Manifest liefert GetVersionEx für die Major- und Minorversionsnummer unter Windows 10 den passenden Wert.

Leider funktioniert das wohl nur, solange das Manifest der letzten Version entspricht. Wenn also irgendwann mal ein Windows 10+/10.1/11 (oder wie immer das heißen wird) kommt, erkennt die alte Version des Programms das wieder nicht mehr.

[RWarnecke]

Vielleicht hilft Dir ja diese API weiter.

[mensch72]

Was für ein Stress mit Manifests, Registry und zig verschiedenen API Calls...

In der VersionInfo Resource der "kernel" oder "user" DLL steht seit Win2000 bis heute incl. aller ServicePacks dazwischen stets die reale&richtige OS Version drin.

Wer einfach wissen will, welches OS läuft liest das ganz ohne "simulierte" Werte dort aus und macht damit, was immer er will.

[AlexII]

Zitat:

Zitat von mensch72 (Beitrag 1326716)

Was für ein Stress mit Manifests, Registry und zig verschiedenen API Calls...

In der VersionInfo Resource der "kernel" oder "user" DLL steht seit Win2000 bis heute incl. aller ServicePacks dazwischen stets die reale&richtige OS Version drin.

Wer einfach wissen will, welches OS läuft liest das ganz ohne "simulierte" Werte dort aus und macht damit, was immer er will.

Ein Beispiel vllt?

[himitsu]

Zitat:

Zitat von AlexII (Beitrag 1326717)

Ein Beispiel vllt?

Wofür?

Das Auslesen von Versionsinfos ... zu finden in der CodeLib, bei Luckie, in Goggle usw.



Und wollen wir hoffen, dass kernel32.ddl (x86) und kernel32.dll (x64) gleich Versioniert sind.

[geskill]

Also ich kann noch die DSiWin32.pas empfehlen. Dort gibt es die DSiGetWindowsVersion()-Funktion. Wird auch in der OmniThreadLibrary verwendet.

[Sir Rufo]

Zitat:

Zitat von geskill (Beitrag 1326938)

Also ich kann noch die DSiWin32.pas empfehlen. Dort gibt es die DSiGetWindowsVersion()-Funktion. Wird auch in der OmniThreadLibrary verwendet.

Und da gibt es noch eine

Delphi-Quellcode:

DSiGetTrueWindowsVersion

und die holt sich die Informationen (wie von Microsoft empfohlen) über:

Delphi-Quellcode:

function DSiGetTrueWindowsVersion: TDSiWindowsVersion;

    function ExportsAPI(module: HMODULE; const apiName: string): boolean;
    begin
      Result := GetProcAddress(module, PChar(apiName)) <> nil;
    end; { ExportsAPI }

  var
    hKernel32: HMODULE;

  begin { DSiGetTrueWindowsVersion }
    hKernel32 := GetModuleHandle('kernel32');
  ...

[a.def]

Zitat:

Zitat von Gerd01 (Beitrag 1311550)

Ich habe den Gedanken von Sir Rufos, die Productversion von kernel32.dll zu prüfen, mal aufgegriffen und eine Abfrage meiner kernerl32.dll gemacht.

Code:

C:\Windows\System32\kernel32.dll
FFI: Product Version: 10.0.10240.16384
FFI: File Version: 6.2.10240.16384
Number of Translations: 1
Translation: 040704B0
  Comments = ""
  CompanyName = "Microsoft Corporation"
  FileDescription = "Client-DLL für Windows NT-Basis-API"
  FileVersion = "10.0.10240.16384 (th1.150709-1700)"
  InternalName = "kernel32"
  LegalCopyright = "© Microsoft Corporation. Alle Rechte vorbehalten."
  LegalTrademarks = ""
  OriginalFilename = "kernel32"
  PrivateBuild = ""
  ProductName = "Betriebssystem Microsoft® Windows®"
  ProductVersion = "10.0.10240.16384"
  SpecialBuild = ""

Also in der Productversion kann man Major,Minor und Build auslesen. Nur die Frage ist, wie sicher ist das für andere Versionen? Ich werde mal weiter recherchieren.

Gerade versucht und gescheitert. Unter Windows 10 (1703) bekomme ich 10.0.15063.0 bei ProductVersion.

[holliesoft]

Zitat:

Gerade versucht und gescheitert. Unter Windows 10 (1703) bekomme ich 10.0.15063.0 bei ProductVersion.

15063 ist die korrekte Buildnummer der 1703. Schau mal in Winver.exe, da stehts.

[TERWI]

... ich hol den Thread noch mal hoch ...
Betreff der Diskussionen zur Notwendigkeit (& Richtigkeit) einer Versionsprüfung gebe ich aus meiner Sicht z.B. die "WLAN-API" mal zu Bedenken.
Dort gibt es seit XP über Vista, Win 7 und Win 8 je Version neue Funktionen, wo es schon Wissenswert ist, welches OS läuft und welche Funktionalität das Proggie damit noch gewährleisten kann
Ab WIN 10 gibt es dann eh eine neue API - ob die "alte" dort noch funzt ? (Hab z.Zt. keinen WIN-10 Rechner greifbar).

Problem scheint ja offensichtlich zu sein, das nicht nur Delphi-interne Funktionen u. a. API-Funcs scheinbar bei der Version 6.2 stehengeblieben sind - sofern hier kein Manifest-Update stattfindet. Angeblich soll WIN 10 dann auch 6.4 melden...

Die Registry auszulesen halte ich hier nach wie vor am sinnigsten - wird es diese doch sicher auch mit/nach WIN 11 o. ä. aus Kompatibilitätsgründen weiterhin geben / geben müssen !?
Mit WIN 8.1 bekomme ich hier als 'CurrentVersion' 6.3 - ohne ohne Änderung am Manifest.

Im Post #18 beschreibt Gerd01 seine Reg zur "CurrentVersion" für WIN 10.
Dort sieht man die Einträge "CurrentMajorVersionNumber" mit Wert=10 und "CurrentMinorVersionNumber" mit Wert = 0, die es in Versionen darunter nicht gibt.
Warum diese nicht zusätzlich prüfen ? Da offensichtlich neu in WIN 10 wird es diese mit entsprehenden Versions-Nummer sicher auch weiterhin geben.
Build-Nr und Produkt-Name u. a. sind auch so wie bisher

Ich hab mir dazu mal ein kleines, noch übersichtliches Tool gebastelt, was auf eine erforderlich Minimal-Version/Build testet und ggf. eine Info auswirft:

Delphi-Quellcode:

function CheckWinVer(var WinVerMaj : integer;
                     var WinVerMin : integer;
                     var WinVerBuild : integer;
                     var WinProdName : string;
                     ShowMsg : boolean) : boolean;
var
  reg: TRegistry;  // USES: Registry
  s1, s2 : string;
  MemVerMaj   : integer;
  MemVerMin   : integer;
  MemVerBuild : integer;
  MsgType     : TMsgDlgType;
begin
  result      := true;
  MsgType     := TMsgDlgType.mtInformation;
  MemVerMaj   := WinVerMaj;
  MemVerMin   := WinVerMin;
  MemVerBuild := WinVerBuild;
  reg := TRegistry.Create(KEY_READ);
  reg.RootKey := HKEY_LOCAL_MACHINE;
  if reg.OpenKey('SOFTWARE\Microsoft\Windows NT\CurrentVersion',false) then
  begin
    // since WIN 10:
    try
      WinVerMaj := reg.ReadInteger('CurrentMajorVersionNumber'); // dword:0000000a
      WinVerMin := reg.ReadInteger('CurrentMinorVersionNumber'); // dword:00000000
    except
      WinVerMaj := -1;
      WinVerMin := 0;
    end;
    if (WinVerMaj < 0) then
    begin
      s1 := reg.ReadString('CurrentVersion');
      s2 := Copy(s1, 1, Pos('.', s1) - 1);
      WinVerMaj := strtoint(s2);
      s2 := Copy(s1, Pos('.', s1) + 1, length(s1));
      WinVerMin := strtoint(s2);
    end;
    s1 := reg.ReadString('CurrentBuildNumber');
    WinVerBuild := strtoint(s1);
    WinProdName := reg.ReadString('ProductName');
    s1 := 'OS-Version: ' + WinProdName + #10#13 +
          inttostr(WinVerMaj) + '.' + inttostr(WinVerMin) + ' - Build ' + inttostr(WinVerBuild);
    s2 := '';
    // check necessaryVersion
    if NOT (WinVerMaj >= MemVerMaj) then
    begin
      s2 := #10#13 + '-> Major-Version lower as expected ! (' + inttostr(MemVerMaj) + ')';
      result := false;
    end;
    // if NOT (WinVerMin >= MemVerMin) then --- nicht ganz richtig ...
    if (NOT (WinVerMaj > MemVerMaj)) AND (NOT (WinVerMin >= MemVerMin)) then
    begin
      s2 := s2 + #10#13 + '-> Minor-Version lower as expected ! (' + inttostr(MemVerMin) + ')';
      result := false;
    end;
    if NOT (WinVerBuild >= MemVerBuild) then
    begin
      s2 := s2 + #10#13 + '-> Build-Nr. lower as expected ! (' + inttostr(MemVerBuild) + ')';
      result := false;
    end;
    if NOT result then
      MsgType := TMsgDlgType.mtWarning;
  end
  else
  begin
    result      := false;
    MsgType     := TMsgDlgType.mtError;
    WinVerMaj   := -1;
    WinVerMin   := -1;
    WinVerBuild := -1;
    WinProdName := 'Unknown Version';
    s1 := 'WARNING: Determine OS-Version failed !';
    s2 := '';
  end;
  reg.CloseKey();
  reg.Free;
  if ShowMsg then
  begin
    MessageDlg(s1 + s2, MsgType, [mbOK], 0);
  end;
end;

Aufruf:

Delphi-Quellcode:

// globale var's:
    FWinVerMaj   : integer;
    FWinVerMin   : integer;
    FWinBuild    : integer;
    FWinProdName : string;
....
// Definition min. z. B.:
  FWinVerMaj   := 6;   // >= XP     > 6 für WIN 10
  FWinVerMin   := 1;   // >= WIN 7  > 3 für WIN 10
  FWinBuild    := -1;  // no check
  FWinProdName := '';  // default
// Aufruf:
  if NOT CheckWinVer(FWinVerMaj,
                     FWinVerMin,
                     FWinBuild,
                     FWinProdName,
                     true) then // ShowMsg
    close; // ... oder halt was anderes ...

Funzt hier beim Test auf XP, WIN 7 und WIN 8.1 - je nach Vorgabe der Min.-Version
Könnte das mal bitte jemand mit einem WIN-10-Rechner testen ?

[bra]

OS-Version: Windows 10 Enterprise
10.0 - Build 15063
-> Minor-Version lower as expected ! (1)

So ist die Prüfung aber nicht sinnvoll, oder? Weil 10.0 ja größer als 6.1 sein sollte?

[TERWI]

Scheint ja wie gewünscht mit den beiden "neuen" Reg-Einträgen zu funktionieren:
Es wird korrekt 10.0 geliefert.
Die Antwort zum "Gemecker" steht dort schon:
-> Minor-Version lower as expected ! (1)
... mal die Definition zur Minor-Version ändern:

Delphi-Quellcode:

  FWinVerMin := 0;

8-)


Ooops - EDIT, ein Käfer.... (ist im Code auf S. 7 #59 bereits geändert)
Falsch ist die Zeile:

Delphi-Quellcode:

if NOT (WinVerMin >= MemVerMin) then

Die Minor-Ver. sollte nicht geprüft werden, wenn die Major-Ver. größer als gefordert ist.
Bitte ersetzen mit:

Delphi-Quellcode:

if (NOT (WinVerMaj > MemVerMaj)) AND (NOT (WinVerMin >= MemVerMin)) then

[TiGü]

Zitat:

Zitat von TERWI (Beitrag 1380434)

... ich hol den Thread noch mal hoch ...
Betreff der Diskussionen zur Notwendigkeit (& Richtigkeit) einer Versionsprüfung gebe ich aus meiner Sicht z.B. die "WLAN-API" mal zu Bedenken.

Konkret an dem Beispiel:
Statt immer zu prüfen, welche Windowsversion vorliegt, kann ja auch stattdessen auf die Funktionalität prüfen.
Also ob die DLL vorhanden ist, die die gesuchten Funktion enthält und dann per dynamischen Laden nachsehen, ob ich einen Zeiger auf die Funktion bekomme.
Oder - so kenne ich das von DirectX - man prüft über QueryInterface (oder Supports), ob die Instanz eines Betriebssystemsinterfaces, welches ich von einer Basisfunktion bekommen habe, weitere, neue Interfaces implementiert.

Beispiel: In Windows 98 wurde das Interface IFoo eingeführt. Dieses kommt aus der \Windows\System32\Foo.dll von der GetFooInstance()-Funktion.
Unter Windows Vista gab es neue Funktionalität. IFoo wurde abgeleitet und heißt jetzt IFoo2 = interface(IFoo).
Mit Windows 7 kam IFoo3, mit Windows 8 IFoo4 usw.

So kann ich dann beim Programmieren prüfen:

Delphi-Quellcode:

var
  HR: HRESULT;
  Foo: IFoo;
  Foo2: IFoo2;
  Foo3: IFoo3;
  Foo4: IFoo4;
  Foo5: IFoo5;
begin
  HR := GetFooInstance(Foo);
  if Succeded(HR) then
  begin
    if Supports(Foo, IFoo2, Foo2) then
      Bar2(Foo2);

    if Supports(Foo, IFoo3, Foo3) then
      Bar3(Foo3);

    if Supports(Foo, IFoo4, Foo4) then
      Bar4(Foo4);

    if Supports(Foo, IFoo5, Foo5) then
      Bar5(Foo5);
  end;

[TERWI]

Damit wir uns hier (alle) nicht missverstehen: Auch ich bin der Meinung, dass man NICHT IMMER eine Versionsprüfung machen muss ....
.... ich persönlich erachte es jedenfalls als recht sinnvoll, bereits beim Prog-Start diese zu prüfen und ggf. den Anwender darauf hinzuweisen, dass die Funktionalität evtl. eingeschränkt ist oder unter eben der OS-Ver. nix geht.
Das ist eben besonders bei der WLan-API recht augenfällig. Bei den versch. DirectX-Ver. ist es genau das gleiche.

Logo kann (und sollte !) man auf DDL-, Funktion/Zeiger darauf vorhanden u.v.m. Nur kann man sich ne Menge Tipperei & Prüferei sparen, wenn man Elementares schon vorher weiss. Wenn es denn wichtig erscheint ...

Die kleine Func war auch nur so ne Idee, ob das denn auch allein mit der Registry klappt. Scheint wohl so. 8-)
Geht natürlich auch anders, wie hier schon mehrfach angedeutet.

[hoika]

Hallo,
ich hole mit die Build-Nummer von Windows 10 so:

Delphi-Quellcode:

function ErmittleWindows10Build: String;
var
  Reg: TRegistry;
begin
  Result := '';
  try
    Reg:= TRegistry.Create(KEY_READ);
    try
      Reg.RootKey := HKEY_LOCAL_MACHINE;
      if Reg.OpenKeyReadOnly('SOFTWARE\Microsoft\Windows NT\CurrentVersion') then
      begin
        Result := Reg.ReadString('ReleaseId');
        Reg.CloseKey;
      end;
    finally
      Reg.Free;
    end;
  except
  end;
end { ErmittleWindows10Build } ;

und zwar nur dann, wenn die Major=8/Minor=2 (>=Windows 8) und die Major der kernel32.dll=10 ist.

[Delphi-Laie]

Zitat:

Zitat von jaenicke (Beitrag 1311480)

Ein Beispiel:
Wenn ich die API Funktion GetServiceTimes verwende, benötigt man für das Programm mindestens XP mit SP3. Statt deshalb eine Prüfung einzubauen, ob es sich mindestens um XP mit SP3 handelt, prüfe ich einfach ob die benötigte Funktion da ist. Ist sie es nicht, fehlt sie mir, ergo zeige ich einen Fehler an, dass das System nicht unterstützt wird.

Das hat dann den Vorteil, dass es unter allen WindowsVersionen klappt, und zwar auch dann, wenn die Funktion später einmal entfernt würde...
Wenn man auf die Windowsversion prüft, bekommt man das nicht mit.

Hierbei wird aber nicht auf eine Funktionalität, sondern nur auf einen Funktionsnamen (bzw. dessen Vorhandensein) geprüft. Namen sind jedoch Schall und Rauch. Vermutlich wird MS keine leeren Funktionen als Veralberung anbieten (oder doch, für irgendwelche "Testzwecke"?)...Worauf ich hinauslaufen möchte, ist, daß sich die Funktionalität hinter den Funktionsnamen auch ändern kann - was dann?

[jaenicke]

Zitat:

Zitat von TERWI (Beitrag 1380434)

Betreff der Diskussionen zur Notwendigkeit (& Richtigkeit) einer Versionsprüfung gebe ich aus meiner Sicht z.B. die "WLAN-API" mal zu Bedenken.
Dort gibt es seit XP über Vista, Win 7 und Win 8 je Version neue Funktionen, wo es schon Wissenswert ist, welches OS läuft und welche Funktionalität das Proggie damit noch gewährleisten kann

Genau, es gab immer wieder neue Funktionen in der Native WiFi API. Möchte man die nutzen, kann man ja problemlos prüfen, ob es die gibt. Genau das war doch der Kern der Diskussion.

Zitat:

Zitat von Delphi-Laie (Beitrag 1380460)

Worauf ich hinauslaufen möchte, ist, daß sich die Funktionalität hinter den Funktionsnamen auch ändern kann - was dann?

Ein solcher Fall ist mir noch nicht begegnet. Selbst die alten Win 3.x KompatibilitätsFunktionen simulieren noch die Funktionalität von damals. Und deshalb gibt es ja diverse Funktionen mit dem Suffix Ex usw. um eben die Originalfunktion nicht zu ändern.

//edit:
Bzw. Änderungen gab es schon, aber bei den Funktionen ist dann dokumentiert wie man die korrekte Buffergröße abfragen kann oder man kann auf die Unterstützung eines neuen Interfaces prüfen usw.
Z.B. gibt es ja diverse Versionen für die Enumerierung von Netzwerkressourcen. Aber auch da braucht man keine Prüfung auf die Windowsversion, wenn man das korrekt umsetzt.

Auch in unseren eigenen Interfaces und DLL Schnittstellen gibt es keine breaking changes, sondern nur kompatible Erweiterungen bzw. neue Interfaceversionen.

//edit
Natürlich gab es auch Fehler in Funktion in verschiedenen Windows Versionen. Aber in den Fällen macht es dann viel mehr Sinn auf die DLL Version zu prüfen, in der die Funktion enthalten ist, wenn man dafür Workarounds implementiert hat.

[Delphi-Laie]

Nun, "automatisch" muß sich die Funktionalität der Funktionen spätestens beim Sprung in die nächste Bitklasse (64->128) wiederum ändern.....

[jaenicke]

Zitat:

Zitat von Delphi-Laie (Beitrag 1380491)

Nun, "automatisch" muß sich die Funktionalität der Funktionen spätestens beim Sprung in die nächste Bitklasse (64->128) wiederum ändern.....

Ich weiß nicht warum du vermutest, dass es dort anders läuft als bei 32-Bit zu 64-Bit, wo das nicht der Fall war. Ich habe bisher keine entsprechenden Ankündigungen gesehen.

[Delphi-Laie]

Zitat:

Zitat von jaenicke (Beitrag 1380504)

Zitat:

Zitat von Delphi-Laie (Beitrag 1380491)

Nun, "automatisch" muß sich die Funktionalität der Funktionen spätestens beim Sprung in die nächste Bitklasse (64->128) wiederum ändern.....

Ich weiß nicht warum du vermutest, dass es dort anders läuft als bei 32-Bit zu 64-Bit, wo das nicht der Fall war. Ich habe bisher keine entsprechenden Ankündigungen gesehen.

Na ganz einfach, weil sich die Argumenten und / oder die Funktionswerte der Funktionen ändern!

Nicht alle Typen sind "mitwachsend".

Ich fand es positiv, daß Borland "mitwachsende" (=generische) Integervariablen einführte, Cardinal und das schon ältere Integer. Waren mit Delphi 1 bzw. Turbo-/Borland-Pascal 16 Bit (womöglich sogar nur 8 Bit auf Mikrocomputern). Mit Delphi 2 wuchsen diese auf 32 Bit an. Leider blieb Embarcadero dieser Linie nicht treu, kein Mitwachsen auf 64 Bit ab XE2.

[jaenicke]

Zitat:

Zitat von Delphi-Laie (Beitrag 1380530)

Na ganz einfach, weil sich die Argumenten und / oder die Funktionswerte der Funktionen ändern!

Nicht alle Typen sind "mitwachsend".

Deshalb werden in der Windows API ja auch überall eindeutige Typen (mitwachsend oder nicht) benutzt und keine Metatypen wie Integer, bei denen das nicht klar ist / war...

[BerndS]

Hallo,
Ich habe auf meinem PC Windows 10 Pro (64bit) 1903 und wunderte mich das mir meine Funktion als ProductName Windows 10 Enterprise anzeigt.
In habe mit Regedit die Werte anzeigen lassen und da stehen die richtigen Werte drin.
Das Problem tritt bei mir in einer 32 bit Anwendung auf.
Wie sich das unter 64 bit verhält kann ich nicht testen, da ich diese Zielplattform nicht installiert habe.

Durch die Suche habe ich diesen Thread gefunden. Dort wird im Beitrag 67 der ProductName auch falsch aus der Registry zurück gegeben.
Ich habe das Problem durch das Hinzufügen von KEY_WOW64_64KEY lösen können.

Delphi-Quellcode:

TRegistry.Create(KEY_READ or KEY_WOW64_64KEY)

Vielleicht ist dies Info für jemand hilfreich der diese Funktion nutzt.
Gruß Bernd