OS Version Windows 10 ermitteln.

[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

Delphi-Quellcode:

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:

Zitat von Sir Rufo (Beitrag 1311534)

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.

[Bernhard Geyer]

Zitat:

Zitat von bepe (Beitrag 1311533)

:-D 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."

[mm1256]

Zitat:

Zitat von Luckie (Beitrag 1311544)

... "OK, Benutzung auf eigenes Risiko. Für diese Windows Version ist das Programm nicht getestet."

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.

Wie in einem vorherigen Beitrag schon angemerkt, man muss die Versionsprüfung und den Umgang damit immer im Zusammenhang mit der Branche sehen, und mit dem Einsatzzweck. Wenn ein Telefonbuch eine falsche Telefonnummer anzeigt, dann wählt der User halt mal eine falsche Nummer. Was solls. Aber wenn eine Finanzsoftware Fehler verursacht dann ist das einfach eine andere Liga, die entsprechend mit anderen Maßstäben beurteilt werden muss.

[Gerd01]

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.

[Sir Rufo]

Beitrag #27 -> Nachtrag

[Bernhard Geyer]

Zitat:

Zitat von mm1256 (Beitrag 1311545)

Zitat:

Zitat von Luckie (Beitrag 1311544)

... "OK, Benutzung auf eigenes Risiko. Für diese Windows Version ist das Programm nicht getestet."

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.

Bei solchen Hintergrund ist es klar das du hier natürlich versuchst eine harte Bremse einzuziehen. Hat den der Kunde den auch Wartung oder ähnliche? Oder hatte er es vor Jahren gekauft und du solltest jetzt über allgemein Produkthaftung dafür gerade stehen (auch wenn du entsprechende Klauseln im Lizenzvertrag hattest)?
Das Urteil ist damit aber sehr ungewöhnlich. Du hast ja damals gar nicht wissen können wie sich Jahre später neuere Windows-Versionen verhalten.
Die Details der Urteilsbegründung wären hier sehr interessant.

[markus5766h]

Zitat:

Zitat von Willie1 (Beitrag 1311493)

Hallo,
bin gerade auf Windows 10 umgestiegen. Um die Windows-Version aus einem eigenen Programm zu ermitteln, geht mit cmd.exe ver >ver.txt. Das liefert bei XP,Vista,7,8,8.1,10 das korrekte Ergebnis. Poershell kennt ver allerdings nicht. Wird es in Zukunft cmd noch geben?

Gruß Willie.

Hallo,
unter PowerShell ist es winver