OS Version Windows 10 ermitteln.

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