GetVersionEx unter Windows 10

[dGeek]

Zitat:

Zitat von mm1256 (Beitrag 1284033)

Bei der Gelegenheit möchte ich mal eine Frage in den Ring werfen: warum verwendet man die Versionsprüfung?

1. Um im Code auf die verschiedenen Windows-Versionen reagieren zu können

2. Um zu verhindern, dass das Programm NICHT mit neueren bzw. unbekannten Windows-Versionen läuft

...oder was sonst noch?

Ich nutze die Versionsprüfung um sicherzustellen, dass das Betriebssystem, unter dem meine Anwendung ausgeführt wird, mindestens Windows XP ist.
Ich weiß zwar nicht, ob es noch Windows 2000-Nutzer gibt, aber sicher ist sicher.
Auch benutze ich eine programminterne Nutzer-Statstik, welche mit ausführlicher Genehmigung des Nutzers auf einem Server im Internet gespeichert wird.
Da stehen dann Dinge drin wie Betriebssystem, verfügbarer Arbeitsspeicher, Prozessor usw usw.

[himitsu]

Zitat:

Zitat von dGeek (Beitrag 1284037)

Ich nutze die Versionsprüfung um sicherzustellen, dass das Betriebssystem, unter dem meine Anwendung ausgeführt wird, mindestens Windows XP ist.
Ich weiß zwar nicht, ob es noch Windows 2000-Nutzer gibt, aber sicher ist sicher.

Das kann man ganz leicht sicherstellen, indem man ganz einfach eine API benutzt/einbindet (am Besten statisch :stupid:), welche es erst seit Windows 2000 existiert.

[dGeek]

Gibt es denn Nachteile GetVersion/GetVersionEx oder die Registry zu nutzen statt eine andere "API" ?

[mm1256]

Zitat:

Zitat von dGeek (Beitrag 1284037)

Ich nutze die Versionsprüfung um sicherzustellen, dass das Betriebssystem, unter dem meine Anwendung ausgeführt wird, mindestens Windows XP ist. Ich weiß zwar nicht, ob es noch Windows 2000-Nutzer gibt, aber sicher ist sicher.

+1 Ich könnte mich in den H... beissen, weil ich das früher nicht gemacht habe. Meine alten Programme vor 2002 laufen heute noch auf Windows 8. Da geht nix mit Update verkaufen :cyclops:

[OT] sorry

Zitat:

Zitat von dGeek (Beitrag 1284037)

Auch benutze ich eine programminterne Nutzer-Statstik, welche mit ausführlicher Genehmigung des Nutzers auf einem Server im Internet gespeichert wird. Da stehen dann Dinge drin wie Betriebssystem, verfügbarer Arbeitsspeicher, Prozessor usw usw.

Interessant, wie viele Gemeinsamkeiten man doch manchmal hat. Ich speichere das lokal in der DB und hol mir das ab, wenn ich es brauche. Zur Betriebssystem-Info spiele ich derzeit mit madExcept. Der schafft es bei einer Exception noch einen "perfekten" Screenshot hinzubekommen, was mir mit meiner eigenen Lösung nicht immer 100%-ig gelingt.
[/OT]

[greenmile]

Zitat:

Zitat von mm1256 (Beitrag 1284044)

+1 Ich könnte mich in den H... beissen, weil ich das früher nicht gemacht habe. Meine alten Programme vor 2002 laufen heute noch auf Windows 8. Da geht nix mit Update verkaufen :cyclops:

Genau darum geht es. Beim Start wird geprüft ob es die neueste Windows Version (zum Zeitpunkt der Entwicklung) ist. Wenn nicht, wird abgebrochen. :-D

[Memnarch]

Zitat:

Zitat von Daniel (Beitrag 1283833)

Man müsste also erst prüfen, ob eine der genannten Funktionen in der Kernel32.dll vorhanden ist und ggf. auch nutzen - wenn nicht, dann auf die alten Funktionen ausweichen, die dann ja - da man offenbar auf einem älteren Windows ist - zuverlässig laufen.
Ich denke da an einen Delphi-Wrapper, der einem diese ganze Fragerei wegkapselt.

Nope, es gibt nur IsWindowsVersionOrGreater. Alle anderen Funktionen sind in einer der HeaderDateien des Windows SDK definiert und benutzen diese.

Zitat:

Zitat von mm1256 (Beitrag 1284044)

Zur Betriebssystem-Info spiele ich derzeit mit madExcept. Der schafft es bei einer Exception noch einen "perfekten" Screenshot hinzubekommen, was mir mit meiner eigenen Lösung nicht immer 100%-ig gelingt.

Beachte bitte, dass du dich damit auf ganz glitschiges Terrein begibst!

MFG
Memnarch

[implementation]

Zitat:

Zitat von mm1256 (Beitrag 1284033)

2. Um zu verhindern, dass das Programm NICHT mit neueren bzw. unbekannten Windows-Versionen läuft

Was für ein unsympathisches Verhalten. Ganz ekeliges Antifeature. Wenn man seinen Enduser hasst, sorgt man dafür, dass er das Programm nicht starten kann :roll:


Edit: Das ist dann einer der Einsatzzwecke, für die "Wine on Windows" entwickelt wird. Auf den ersten Blick eine völlige WTF-Idee, aber damit könnte man genau solche Programme doch noch zum Arbeiten zwingen.

[mm1256]

Zitat:

Zitat von implementation (Beitrag 1284094)

Zitat:

Zitat von mm1256 (Beitrag 1284033)

2. Um zu verhindern, dass das Programm NICHT mit neueren bzw. unbekannten Windows-Versionen läuft

Was für ein unsympathisches Verhalten. Ganz ekeliges Antifeature. Wenn man seinen Enduser hasst, sorgt man dafür, dass er das Programm nicht starten kann :roll:

Sorry, da muss ich jetzt was dazu sagen, auch wenn es OT ist. Man muss diesen Sachverhalt im Kontext mit der jeweiligen Anwendung sehen. Es geht hier um ein WWS das demzufolge wichtige Kundendaten speichert, deren Konsistenz niemals in Frage gestellt sein darf. Früher - siehe vorherigen Beitrag - als ich noch keine Versionsüberprüfung durchgeführt habe, ist es immer wieder sporadisch vorgekommen, dass Datenbanken beschädigt waren, und keiner wusste warum.

Darum ist wichtig, dass sowohl Datenbank als auch meine SW 100%-ig auf einem neuen Betriebssystem getestet sind. Man kann das wie du als Antifeature bezeichen, es hat aber auch schon Fälle gegeben, wo Kunden erfolgreich geklagt haben, wenn eine SW ohne Warnung einfach weiter gelaufen ist, und in Folge davon die Daten geschrottet hat.

Ich hab auch andere Apps die keine Windows-Versions-Prüfung durchführen, z.B. ein Tool für Musiker, das Registrationen von Keyboards lädt. Wenn da aufgrund einer Fehlfunktion eine falsche Reg geladen würde, merkt der Anwender das und meldet sich. Aber ein Schaden kann daraus nicht entstehen.

Also bitte nicht Äpfel mit Birnen vergleichen. Jeder hat für seine Vorgehensweisen i.d.R. sehr gute Gründe. Wer seine Vorgehensweise nicht den marktüblichen Gegebenheiten anpasst verschwindet sowieso im Lauf der Zeit von selbst. Der Markt hat hier eine relativ gute Selbstbereinigungsfunktion :thumb:

[mm1256]

Zitat:

Zitat von Memnarch (Beitrag 1284067)

Zitat:

Zitat von mm1256 (Beitrag 1284044)

Zur Betriebssystem-Info spiele ich derzeit mit madExcept. Der schafft es bei einer Exception noch einen "perfekten" Screenshot hinzubekommen, was mir mit meiner eigenen Lösung nicht immer 100%-ig gelingt.

Beachte bitte, dass du dich damit auf ganz glitschiges Terrein begibst!

Darf ich bitte mal fragen was du damit meinst?

Es geht hier um die Qualitätssicherung: Feststellung wann und wo genau ein Fehler aufgetreten ist. Ich habe durch intensives Logging meine Fehlerrate (Anzahl von Exceptions die bei allen Kunden pro Monat auftreten) auf unter 2% drücken können, d.h. 98% meiner Kunden sehen einen ganzen Monat lang keine einzige Exception, obwohl sie täglich bis zu 8 Stunden mit der SW arbeiten. Jedem Kunden ist bewusst, dass er mit diesen Screenshots dazu beiträgt, dass das auch so bleibt. Darum ist es (für mich) wichtig, dass die Screenshots auch auf allen OS sauber funktionieren (sind wir also doch noch beim Thema gelandet und nicht total OT). Also was soll daran bitte falsch sein? Sicher enthalten Screenshots manchmal auch persönliche Daten, aber wenn das Vertrauen schon so weit gestört ist, dann macht eine Zusammenarbeit wohl eh keinen Sinn mehr.

[QuickAndDirty]

Zitat:

Zitat von mm1256 (Beitrag 1284098)

Sicher enthalten Screenshots manchmal auch persönliche Daten, aber wenn das Vertrauen schon so weit gestört ist, dann macht eine Zusammenarbeit wohl eh keinen Sinn mehr.

Ich würde einem Benutzer die Screenshots vor dem Senden Vorlegen. Und sie nicht ohne Einwilligung abschicken!
Ich kann mir nicht vorstellen, dass Kunden wie die Bundespolizei oder Arztpraxen das Loggen ihres Bildschirms verantworten möchten!
Teilweise sind die Rechner nicht mal im selben Netz wie der Internet Anschluss!