OS Version Windows 10 ermitteln.

[mm1256]

Zitat von Daniel:

Man muss natürlich aufpassen, dass man sich in der ganzen Prüferei nicht verliert.

YUPP - es kommt eben wie schon gesagt auf den Zweck an. Da ich ja heute zufällig an diesem Thema arbeite, anbei mal mein aktueller Stand. Nicht mehr als eine kleine kompakte Unit, so ähnlich stelle ich mir das vor, und vielleicht ist auch für Gerd eine Anregung dabei. Ist noch Beta-Status!! Wer mag, kann bei den noch offenen Strings gerne ergänzen.

[Sir Rufo]

Man bekommt im Übrigen die Versionsnummer auch heraus, wenn man die Versionsnummer der kernel32.dll ausliest. Die sollte eigentlich immer mit der Version konform gehen und auch immer vorhanden sein.

Nur für den Fall, das jemand eine Versionsnummer benötigt und sich nicht auf die Registry verlassen möchte und sich auch nicht von GetVersionEx täuschen lassen möchte (die im Übrigen in genau dieser kernel32.dll ihre Heimat hat).

Nachtrag

Eine kurze Recherche auf den MS-Seiten bringt dann Folgendes zu Tage:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms724429%28v=vs.85%29.aspx

To obtain the full version number for the operating system, call the GetFileVersionInfo function on one of the system DLLs, such as Kernel32.dll, then call VerQueryValue to obtain the \\StringFileInfo\\<lang><codepage>\\ProductVersion subblock of the file version information.

[mm1256]

Gut recherchiert Sir Rufo !

Auf den Trichter bin ich früher übrigens auch schon mal gekommen, aber die OS-Version bekommt man hierüber auch wieder nur über den Key "ProductVersion" und über die Umwege des Zerlegens und Auswertens der ProductVersion (MajorVersion.MinorVersion.Build).

[Bernhard Geyer]

Zitat von Sir Rufo:

Man bekommt im Übrigen die Versionsnummer auch heraus, wenn man die Versionsnummer der kernel32.dll ausliest. Die sollte eigentlich immer mit der Version konform gehen und auch immer vorhanden sein.

Nur für den Fall, das jemand eine Versionsnummer benötigt und sich nicht auf die Registry verlassen möchte und sich auch nicht von GetVersionEx täuschen lassen möchte (die im Übrigen in genau dieser kernel32.dll ihre Heimat hat).

Das ist aber auch nur der aktuelle Stand. Wenn in 5 Jahren MS die kernel32.dll aufgibt und diese in eine andere DLL verlagert klappt es damit auch wieder nicht.
Und falls jemand als Gegenargument liefert: Aber in den Delphi-Sourcen steht doch das die Funktion in kernel32 liegt. Windows kann den Ladeprozess bei benötigten DLLs umbiegen. In der Exe steht "kernel32.dll wird benötigt", Windows lädt dann aber "superduper32.dll".

Die Wahrscheinlichkeit ist zwar gering das das passiert, aber ausgeschlossen ist das nicht.

[bepe]

Zitat von Bernhard Geyer:

Das ist aber auch nur der aktuelle Stand. Wenn in 5 Jahren MS die kernel32.dll aufgibt und diese in eine andere DLL verlagert klappt es damit auch wieder nicht.
Und falls jemand als Gegenargument liefert: Aber in den Delphi-Sourcen steht doch das die Funktion in kernel32 liegt. Windows kann den Ladeprozess bei benötigten DLLs umbiegen. In der Exe steht "kernel32.dll wird benötigt", Windows lädt dann aber "superduper32.dll".

Die Wahrscheinlichkeit ist zwar gering das das passiert, aber ausgeschlossen ist das nicht.

Ist das dein Ernst? Mal abgesehen davon, dass wir von Windows reden, das ist immerhin bis in die Steinzeit abwärtskompatibel, dürfte ich mit dem "Argument" gar keine Software mehr schreiben. Immerhin könnten sich alle dokumentierten Funktionen mal ändern.

Benutz ja nicht die Bremse! In autonomen Fahrzeugen wird es vielleicht keine geben. Also gewöhn dich nicht daran.

(Sorry, aber das absurd breite Grinsen hat mich zu diesem Post gezwungen.)

[Bernhard Geyer]

Zitat von bepe:

Ist das dein Ernst? Mal abgesehen davon, dass wir von Windows reden, das ist immerhin bis in die Steinzeit abwärtskompatibel, dürfte ich mit dem "Argument" gar keine Software mehr schreiben. Immerhin könnten sich alle dokumentierten Funktionen mal ändern.

Borland ist mit Delphi genau in diese Falle gelaufen. Siehe http://entwickler-forum.de/showthrea...ll-geladen-ist

[mensch72]

Den Weg über VerionInfoResourcen von User32.dll und Kernel32.dll sowie ein paar weiterer für mich wichtiger MS-Dateien verwende ich auch, und sogar wenn möglich "hart", also mit einer eigenen Routine zum direktem Auslesen der Resource mit den Versionsinfos.

Auch wenn hier viele es aus funktionaler Anwendersicht sehen, auch ich definiere in meinen Verträgen als "Leistungsgarantie" nur die Funktion in der zum Zeitpunkt der Übergabe aktuellen Systemumgebung.
(Es gab da mal vor laaanger Zeit ein NT4 Update/ServicePack, was "nebenbei" gar manche TCPIP Kommunikation gestört oder beeinflusst hat oder danach noch ein paar Updates für ADO/OLEDB Datenbankzeug... SageKHK ist da auch gern abundzu betroffen)

Im Banken/Finanz & Industrieumfeld ist es also durchaus üblich, Software "fix" für eine definierte Softwareumgebung zu verkaufen, und die Programmausführung nach/für Systemupdates erst auf Anforderung und eigener Testfreigabe (und gegen Entgeld) zu erlauben. Speziell im Netzwerkbereich wurde MS immer besser. Aber wenn ich meine alte Software im Millisekundenbereich mit viel Mühe damals genau darauf optimiert habe, nützt mit in Win10 eine nun selbst optimal funktionierende Lösung für den gleichen API Call garnix, wenn Win10 per VersionInfoApi mir sagen würde, es ist noch ein Win7.

Klar kann man mit NEUEN Manifestdateien Win10 dazu bewegen, sich auch per API sauber zu melden, das nützt alten Programmen aber gar nix. Und genau da soll ja wenigstens eine Warnung möglich sein, das der Anwender nun das System nun voll auf eigenes Risiko ohne die nur für die alte OS-Version geltenden (und NUR dafür bezahlten) Support Ansprüche betreibt.
Ich verhindere bis jetzt da absichtlich nicht die (Weiter)Nutzung, nur lasse ich mir bei Problemen dann jegliche Analyse und den Support auch separat bezahlen.

[Luckie]

Alte Programme, die geschrieben worden bevor es Windows XYZ gab, erkennen die neuen Windows Versionen doch eh nicht. Also sollte die Ausgabe "Unbekannte Windows Version" sein. Und wenn das der Fall ist, kannst du sagen: "OK, Benutzung auf eigenes Risiko. Für diese Windows Version ist das Programm nicht getestet."

[Sir Rufo]

Und was machen wir, wenn morgen ein Klavier auf den Rechner fällt? Wie kommen wir dann an diese Information? Oder was machen wir, wenn der Rechner geklaut wurde?

Irgendwo muss man mal den Zopf abschneiden und ein Ei drauf schlagen.

Dass die Informationen nicht mehr in der Registry stehen oder GetVersionEx gefakte Informationen herausgibt (so ist es ja) ist wesentlich wahrscheinlicher, als dass ein Zugriff auf die kernel32.dll nicht mehr funktioniert.

Und wenn das so sein sollte, dann funktioniert nicht nur die eigene Anwendung nicht mehr, sondern 99% der anderen auch nicht mehr. Man ist also nicht alleine

[jaenicke]

Zitat von Sir Rufo:

Und wenn das so sein sollte, dann funktioniert nicht nur die eigene Anwendung nicht mehr, sondern 99% der anderen auch nicht mehr. Man ist also nicht alleine

Im Gegenteil, es funktioniert nur die Software nicht mehr, die sich auf irgendwelchen komischen Wegen eine unbedingt korrekte Versionsnummer holt und damit absichtlich neue Windowsversionen nicht unterstützt.
Das ist noch einmal die verschärfte Variante davon, die vor einigen Jahren vor Gericht gelandet ist, bei der die Versionsprüfung der Software aus Versehen neue Windowsversionen ausgeschlossen hat. Selbst da wurde der Hersteller dazu verurteilt diesen Fehler zu beheben... leider finde ich das entsprechende Urteil bzw. die Berichte dazu grad nicht. Ist schon ein paar Jahre her.