OS Version Windows 10 ermitteln.

[Willie1]

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

Hat sich erledigt, zitiere mich selbst.

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

[Willie1]

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.

[markus5766h]

Zitat von Willie1:

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

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

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 von Bernhard Geyer:

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

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