OS Version Windows 10 ermitteln.

[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:
  FWinVerMin := 0;


Ooops - EDIT, ein Käfer.... (ist im Code auf S. 7 #59 bereits geändert)
Falsch ist die Zeile:
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:
if (NOT (WinVerMaj > MemVerMaj)) AND (NOT (WinVerMin >= MemVerMin)) then

[TiGü]

Zitat von 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.

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.
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 von jaenicke:

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 von TERWI:

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 von Delphi-Laie:

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 von Delphi-Laie:

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 von jaenicke:

Zitat von Delphi-Laie:

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 von Delphi-Laie:

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...