GetVersionEx unter Windows 10

[greenmile]

Hallo,

GetVersionEx meldet in meinem Delphi XE3 Programm immer "6.2", also Windows 8. Das liegt an einem netten "Feature" von Microsoft, siehe http://forum.delphi-treff.de/index.p...r-Windows-8-1/. Anscheinend muss man für 10 ein Manifest einbinden. Hat jemand Informationen, wie die Datei auszusehen hat? Oder hat die womöglich jemand? Viel Informationen findet man leider nicht darüber, die Link oben war fast der einzige für Delphi.

[Daniel]

Allem Anschein nach verabschiedet sich MS von den konkreten Versionsnummern als Entscheidungskriterium und möchte uns Entwickler dazu bewegen, auf Releases zu prüfen:

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

• IsWindows7OrGreater
• IsWindows7SP1OrGreater
• IsWindows8OrGreater
• IsWindows8Point1OrGreater
• IsWindowsServer
• IsWindowsVistaOrGreater
• IsWindowsVistaSP1OrGreater
• IsWindowsVistaSP2OrGreater
• IsWindowsXPOrGreater
• IsWindowsXPSP1OrGreater
• IsWindowsXPSP2OrGreater
• IsWindowsXPSP3OrGreater
• IsWindowsVersionOrGreater

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.

[greenmile]

Hatte ich auch gesehen, ich habe vergleichbare Funktionen auch in einer Unit, die haben meine Idee geklaut ;)
Damit kann ich aktuell aber leider nicht prüfen, ob es Windows 10 ist (es gibt nur 8.1 or greater). Bleibt mir eigentlich nur noch dieses Manifest.

[himitsu]

Zitat:

Zitat von greenmile (Beitrag 1283832)

Anscheinend muss man für 10 ein Manifest einbinden. Hat jemand Informationen, wie die Datei auszusehen hat? Oder hat die womöglich jemand? Viel Informationen findet man leider nicht darüber, die Link oben war fast der einzige für Delphi.

http://forum.delphi-treff.de/index.p...243#post438243 :roll:

Beschreibungen kannst du im Thread vom Manifest-Creator finden.
(ich muß dann nur nochmal eine aktuelle Version der ManifestCreatorLang.xml im ersten Post anpinnen ... Den Wert für Windows 10 findet man am Ende des Threads)

[mm1256]

Hallo,

"die spinnen doch, die Römer"....aber mal im Ernst. Ob die Gründe die MS hat nun sinnvoll sind oder nicht, darüber mag man unterschiedlicher Meinung sein. Bei jeder Windows-Version an den Manifesten rum schrauben ist mir persönlich zu blöd. Damit meine SW abwärtskompatibel zu den älteren OS bleibt lese ich nach wie vor mit GetVersionEx die TOSVersionInfoEx aus, und aktualisiere dann die TOSVersionInfoEx.dwBuildNumber (die ich dann auch auswerte) aus der Registry. Das mag zwar etwas blauäugig sein, und aus programmiertechnischer Sicht nicht das Feinste, es funzt aber. Und solange MS die Registry bedient wird es mit jeder neuen Windows-Version ohne Änderung funktionieren. Hat auch funktioniert, als die ersten meiner Kunden meine Software mit der Technical Preview ausprobiert haben. Sprich, die SW hat ein unbekanntes OS erkannt, und den Programmstart abgelehnt.

[greenmile]

Hier das Manifest für alle, die es noch brauchen. Einfach mit BRCC32 compilieren, einbinden und schon spuckt Windows die korrekte Nummer aus:

Code:

<?xml version="1.0" encoding="utf-8" ?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
  <assemblyIdentity version="1.0.0.0" name="MyApplication.app"/>

  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
        <application>
            <!-- Windows 8.1 -->
            <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
            <!-- Windows Vista -->
            <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
            <!-- Windows 7 -->
            <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
            <!-- Windows 8 -->
            <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
            <!-- Windows 10 -->
            <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
        </application> 
    </compatibility>
    
  <asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
    <asmv3:windowsSettings
         xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
      <dpiAware>True/PM</dpiAware>
    </asmv3:windowsSettings>
  </asmv3:application>
</asmv1:assembly>

[himitsu]

Zitat:

Zitat von greenmile (Beitrag 1283835)

Hatte ich auch gesehen, ich habe vergleichbare Funktionen auch in einer Unit, die haben meine Idee geklaut ;)
Damit kann ich aktuell aber leider nicht prüfen, ob es Windows 10 ist (es gibt nur 8.1 or greater).

Dann hast du bestimmt falsch geguckt. :zwinker:

IsWindowsVersionOrGreater

Die anderen Version-Helper-Funktionen werden am Ende bestimmt auch nur auf diese API gehen.

[dGeek]

Seit Windows 8.1 ist GetVersion/GetVersionEx nicht mehr zuverlässig.

Die folgende Komponente ist bis Windows 7 kompatibel und lässt sich sehr einfach bis Windows 10 erweitern:
http://www.delphipraxis.net/97999-%5...erkennung.html

Ab Windows 8 lese ich nur noch die Registry aus, da Windows 8.1 glaube ich als Windows 8 identifiziert wird.

[Dalai]

Mir gefällt diese Entscheidung von MS auch nicht, aber mal ernsthaft: ob man nun im eigenen Code Anpassungen an neue Windows-Versionen macht oder das Manifest ändert, ist doch egal - neu kompilieren muss man sowieso.

Zitat:

Zitat von dGeek (Beitrag 1284026)

Seit Windows 8.1 ist GetVersion/GetVersionEx nicht mehr zuverlässig.

[...]

Ab Windows 8 lese ich nur noch die Registry aus, da Windows 8.1 glaube ich als Windows 8 identifiziert wird.

Und die Registry ist deiner Meinung nach zuverlässiger?

MfG Dalai

[mm1256]

Zitat:

Zitat von dGeek

Ab Windows 8 lese ich nur noch die Registry aus, da Windows 8.1 glaube ich als Windows 8 identifiziert wird.

Mit GetVersionEx .... richtig, dafür gibts ja die neue API.

Zitat:

Zitat von Dalai

Und die Registry ist deiner Meinung nach zuverlässiger?

Ich gehe ja auch den parallelen Weg über die Registry. Zuverlässiger...bin ich voll deiner Meinung, zuverlässiger ist das sicher nicht. Aber zumindest ist für eine ältere App für Windows 7 compiliert ein Unterschied erkennbar gewesen, zwischen Windows 7, 8.0 und Windows 8.1.

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?

Für [1] sind die Manifeste und das entsprechende API ja wunderbar geeignet, aber für [2] ??? Das ging doch zwischen 7/8/8.1 total in die Hose, wenn man nicht gleich bei 8.0 aufgepasst hat.

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

[Daniel]

Stop, stop stop.
Es ging um die Prüfung der Windows-Version. Um Screenshots von Arbeitsplätzen aus Arztpraxen geht es hier nicht. :roll: Bleibt bitte beim Thema.


"IsWindowsVersionOrGreater " ist im MSDN mit folgendem Kommentar versehen:

Zitat:

Important You should only use this function if the other provided Version Helper functions do not fit within your scenarios.

[dGeek]

Haut mich nicht, aber ich hole das Thema noch einmal hervor, sodass es nicht untergeht.

[dGeek]

Zitat:

Zitat von Daniel (Beitrag 1283833)

Allem Anschein nach verabschiedet sich MS von den konkreten Versionsnummern als Entscheidungskriterium und möchte uns Entwickler dazu bewegen, auf Releases zu prüfen:

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

• IsWindows7OrGreater
• IsWindows7SP1OrGreater
• IsWindows8OrGreater
• IsWindows8Point1OrGreater
• IsWindowsServer
• IsWindowsVistaOrGreater
• IsWindowsVistaSP1OrGreater
• IsWindowsVistaSP2OrGreater
• IsWindowsXPOrGreater
• IsWindowsXPSP1OrGreater
• IsWindowsXPSP2OrGreater
• IsWindowsXPSP3OrGreater
• IsWindowsVersionOrGreater

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.

Diesbezüglich verstehe ich überhaupt nichts mehr (zu viele sinnlose Änderungern).
Daher eine total dumme Frage:

damit ich die neuen APIs (siehe oben) nutzen kann ..
- muss ich meine Software unter Windows 8.1 kompilieren
oder
- kann ich die aktuell auch mit meinem XE2 unter Windows 7 Home Edition nutzen
oder
- brauche ich eine neue Delphi-Version UND Windows 8.1?

[mm1256]

Hallo dGeek,

[edit] erst mal, es gibt keine dummen Fragen, nur leider viel zu oft dumme Antworten[/edit] ...das wollte ich noch los werden

Zitat:

damit ich die neuen APIs (siehe oben) nutzen kann ..
- muss ich meine Software unter Windows 8.1 kompilieren

nein

Zitat:

- kann ich die aktuell auch mit meinem XE2 unter Windows 7 Home Edition nutzen

bringt nur ab Win 8 was

Zitat:

- brauche ich eine neue Delphi-Version UND Windows 8.1?

Das geht mit (fast???) jedem Delphi, ist ja WinApi

Soweit ich das verstehe - also Bitte an die Wissenden: korrigieren wenn ich es falsch verstanden habe - die neue API ist ein Ersatz für die alten Funktionen GetVersion und GetVersionEx ab Windows 8.0. Mit allen vorherigen Versionen funktioniert GetVersion und GetVersionEx nach wie vor. Es gibt auch keine Fehlermeldung, wenn du die Beiden unter 8.0, 8.1, Server 2012 usw. verwendest. Es werden aber nicht mehr alle Daten in der TOSVersionInfoEx zur Verfügung gestellt, z.B. die "dwBuildNumber". GetVersion und GetVersionEx sind also ab Windows 8.0 nicht mehr geeignet, die Windows-Version zu bestimmen.

Das war ja mein Ansatz: Wenn sich die MS-Ler schon für neuere Windows-Versionen immer wieder neue Tugenden einfallen lassen um die Version zu bestimmen, dann habe ich doch mit "älterer" (vor einigen Jahren compilierter) Software generell das Problem, dass eine neue Windows-Version mit GetVersionEx gar nicht erkannt wird. Die alte Software glaubt, sie läuft immer noch unter Win7. Und das ist das Fatale daran, wenn man sich früher ausschließlich auf GetVersionEx verlassen hat. Und darum bin ich auch froh darüber, zusätzlich zu GetVersionEx die Build-Nummer aus der Registry ausgelesen zu haben. Der Vergleich ergibt nämlich bei meiner alten Software einen Unterschied, und das ist der Nutzen daran. Wie man mit der Erkennung des Unterschiedes umgeht, darüber wurde ja schon diskutiert.

[dGeek]

Ich nutze für die Versionsprüfung die bereits von mir hier im Forum gepostete downloadbare Komponente und die funktioniert bis Windows 10 inklusive dwBuildNumber etc. mit GetVersionExW sehr gut.

[mm1256]

Wo gibt es denn die Komponente - und ist die mit Source?

BTW ich habe gesucht, aber nichts gefunden. "version" ist ein ignoriertes Suchwort :?

[dGeek]

Die folgende Komponente ist bis Windows 7 kompatibel und lässt sich sehr einfach bis Windows 10 erweitern:
http://www.delphipraxis.net/97999-%5...erkennung.html

[Sir Rufo]

Mal eine ganz doofe Frage:

Wann und wozu benötige ich die konkrete Windows-Version (wenn ich kein "Ich-zeige-die-Windows-Version-an" Programm schreiben will)?

Es gibt APIs die ab einer Version erst vorhanden sind, welche, die ab einer Version ersetzt wurden oder (gibt es das) ab einer Version ersatzlos gestrichen wurden.

In die Zukunft kann ich nicht schauen, darum kann ich also auch nicht garantieren, dass alles immer funktioniert. Aber alle diese oben genannten Szenarien kann ich mit

Delphi-Quellcode:

IsWindowsVersionOrGreater

komplett behandeln ... und das funktioniert seit Windows 2000.

[dGeek]

Ich nutze die Versionsabfrage für statistische Gründe ;)

[Dalai]

Zitat:

Zitat von mm1256 (Beitrag 1284218)

Soweit ich das verstehe - also Bitte an die Wissenden: korrigieren wenn ich es falsch verstanden habe - die neue API ist ein Ersatz für die alten Funktionen GetVersion und GetVersionEx ab Windows 8.0. Mit allen vorherigen Versionen funktioniert GetVersion und GetVersionEx nach wie vor.

Ab Win8.1, wobei es möglich ist, dass MS hier seit 8.0 anregte, die neuen Funktionen zu nutzen bzw. die alten nicht zu benutzen. Ein 8.0 lässt sich auch mit GetVersionEx korrekt erkennen, 8.1 und höher nur dann, wenn die Applikation ein Manifest mit passender Kompatibilität aufweist.

Zitat:

Zitat von Sir Rufo (Beitrag 1284230)

Mal eine ganz doofe Frage:

Nö, die ist nicht doof, denn es gibt nur schlaue Fragen.

Zitat:

Wann und wozu benötige ich die konkrete Windows-Version (wenn ich kein "Ich-zeige-die-Windows-Version-an" Programm schreiben will)?

Ich habe ein Projekt namens Automatisierung, das Software automatisiert auf Windows installieren kann, ohne jedes Mal von Hand alle Installationsroutinen durchzuklappern. Zu diesem Zweck muss meine Automatisierung die Windows-Version kennen, um einige dieser Software-Produkte von vornherein gar nicht erst anzuzeigen, weil einige davon unter bestimmten Windows-Versionen gar nicht erst laufen. Dazu muss genau festlegbar sein, unter welchen Windows-Versionen die Software läuft, denn einige verweigern nunmal den Dienst auf neueren oder älteren Versionen.

MfG Dalai

[dGeek]

Zitat:

Ein 8.0 lässt sich auch mit GetVersionEx korrekt erkennen, 8.1 und höher nur dann, wenn die Applikation ein Manifest mit passender Kompatibilität aufweist.

Ich hatte es eben mal unter Windows 10 getestet und dort wird Windows von meiner Software korrekt erkannt, obwohl ich GetVersionEx(W) nutze.
Spezielle Manifeste nutze ich nicht :?

[Dalai]

Zitat:

Zitat von dGeek (Beitrag 1284241)

Zitat:

Ein 8.0 lässt sich auch mit GetVersionEx korrekt erkennen, 8.1 und höher nur dann, wenn die Applikation ein Manifest mit passender Kompatibilität aufweist.

Ich hatte es eben mal unter Windows 10 getestet und dort wird Windows von meiner Software korrekt erkannt, obwohl ich GetVersionEx(W) nutze.
Spezielle Manifeste nutze ich nicht :?

Da gibt es nur 3 Möglichkeiten:

• kein GetVersionEx benutzt bzw. (nur) die neuen Funktionen
• das Manifest gibt Kompatibilität mit Win10 an; das muss ja kein spezielles Manifest sein, k.a. ob irgendein neueres Delphi die Kompatibilität im Manifest hat, wobei ich das für Win10 nicht so recht glaube (aber wir sind ja hier nicht in der Kirche ;))
• du benutzt nicht nur GetVersionEx sondern (auch) andere Methoden, wie z.B. die hier im Thread erwähnte Registry

MfG Dalai

[himitsu]

Zitat:

Zitat von Dalai (Beitrag 1284240)

Ein 8.0 lässt sich auch mit GetVersionEx korrekt erkennen, 8.1 und höher nur dann, wenn die Applikation ein Manifest mit passender Kompatibilität aufweist.

Wenn es das nicht tut, dann wird es wie ein altes Programm behandelt und einige Dinge werden emuliert/umgeleitet, damit es fast so ist, als liefe es in einem alten Windows.
Und somit hat sich das Problem auch gelöst. :roll:

Ob es aber inntelligent ist, das Programm einfach nicht mehr zu starten, nur weil das Windows angeblich zu neu ist, ist auch keine gute Lösung.
> Schadensersatzansprüche?

Dann bringt Mikrosoft ein Windowsupdate raus, das ändert die Version und schon knallt es wieder, weil sich die Version geändert hat.

Eine Warnmeldung wäre ja auch möglich.
Und wie bereits erwähnt, kann man die Zukunft nicht planen, also kann man mit Sicherheit nur auf alte Versionen reagieren und eine Warnung/Funktionsverweigerung explizit auf "bekannte" Probleme ausrichten.
"Sie verwenden Windows 98. Hier gibt bekannte es es Probleme, welche die korekte Funktion des Programms beeinflussen ... Tschüss"

[Bernhard Geyer]

Zitat:

Zitat von Dalai (Beitrag 1284240)

Zitat:

Zitat von mm1256 (Beitrag 1284218)

Soweit ich das verstehe - also Bitte an die Wissenden: korrigieren wenn ich es falsch verstanden habe - die neue API ist ein Ersatz für die alten Funktionen GetVersion und GetVersionEx ab Windows 8.0. Mit allen vorherigen Versionen funktioniert GetVersion und GetVersionEx nach wie vor.

Ab Win8.1, wobei es möglich ist, dass MS hier seit 8.0 anregte, die neuen Funktionen zu nutzen bzw. die alten nicht zu benutzen. Ein 8.0 lässt sich auch mit GetVersionEx korrekt erkennen, 8.1 und höher nur dann, wenn die Applikation ein Manifest mit passender Kompatibilität aufweist.

Das ist aber schon seit Windows Vista so. Nicht umsonst laufen unsere Anwendungen mit 4 ID für Vista, 7, 8 und 8.1

[mm1256]

Zitat:

Zitat von himitsu (Beitrag 1284257)

Und wie bereits erwähnt, kann man die Zukunft nicht planen, also kann man mit Sicherheit nur auf alte Versionen reagieren....

Die Formulierung "die Zukunft zu planen" gefällt mir :thumb:

Mein Versuch das zu tun sieht so aus:

Delphi-Quellcode:

function WindowsBuildFromRegistry: Boolean;
var
  s: string;
begin
  Result := false;
  with TRegistry.Create(KEY_EXECUTE) do
  try
    RootKey := HKEY_LOCAL_MACHINE;
    if OpenKeyReadOnly(rsRegWinVerInfoKey) then
    try
      OSInfo.dwBuildNumber := Cardinal(StrToIntDef(ReadString('CurrentBuildNumber'),0));
      Result := true;
    except
    end;
    CloseKey;
  finally
    Free;
  end;
end;

function GetWinVersion: TWinVersion;
begin
  Result := WinUnknown;
  case OSInfo.dwPlatformId of
    VER_PLATFORM_WIN32s : Result := Win32s;
    VER_PLATFORM_WIN32_WINDOWS : begin
      if (OSInfo.dwMajorVersion = 4) and (OSInfo.dwMinorVersion = 0)
      then Result := Win95;
      if (OSInfo.dwMajorVersion = 4) and (OSInfo.dwMinorVersion = 10)
      then Result := Win98;
      if (OSInfo.dwMajorVersion = 4) and (OSInfo.dwMinorVersion = 90)
      then Result := WinME;
    end;{-VER_PLATFORM_WIN32_WINDOWS-}
    VER_PLATFORM_WIN32_NT: begin
      if (OSInfo.dwMajorVersion = 4) and (OSInfo.dwMinorVersion = 0)
      then Result := WinNT;
      if (OSInfo.dwMajorVersion = 5) and (OSInfo.dwMinorVersion = 0)
      then Result := Win2000;
      if (OSInfo.dwMajorVersion = 5) and (OSInfo.dwMinorVersion = 1)
      then Result := WinXP;
      if (OSInfo.dwMajorVersion = 5) and (OSInfo.dwMinorVersion = 2) then
      begin
        if GetSystemMetrics(SM_SERVERR2) <> 0
        then Result := Win2003R2 else
        if (OSInfo.wProductType = VER_NT_WORKSTATION)
        then Result := WinXP64 else
        if OSInfo.wSuiteMask = VER_SUITE_WH_SERVER
        then Result := WinHomeSrv
        else Result := Win2003;
      end;
      if (OSInfo.dwMajorVersion = 6) and (OSInfo.dwMinorVersion = 0) then
      begin
        if (OSInfo.wProductType = VER_NT_WORKSTATION)
        then Result := WinVista
        else Result := Win2008;
      end;
      if (OSInfo.dwMajorVersion = 6) and (OSInfo.dwMinorVersion = 1) then
      begin
        if (OSInfo.wProductType = VER_NT_WORKSTATION)
        then Result := Win7
        else Result := Win2008R2;
      end;
      if (OSInfo.dwMajorVersion = 6) and (OSInfo.dwMinorVersion = 2) then
      begin
        if WindowsBuildFromRegistry then begin
          case OSInfo.dwBuildNumber of
            9200 : case OSInfo.wProductType of
                     VER_NT_WORKSTATION       : Result := Win8;
                     VER_NT_DOMAIN_CONTROLLER : Result := Win2012;
                     VER_NT_SERVER            : Result := Win2012;
                   end;
            9600 : case OSInfo.wProductType of
                     VER_NT_WORKSTATION       : Result := Win81;
                     VER_NT_DOMAIN_CONTROLLER : Result := Win2012R2;
                     VER_NT_SERVER            : Result := Win2012R2;
                   end;
            9841..9880 : Result := Windows10; // Die Preview ist aktuell bei Build 9879
          end;
        end;
      end;
    end;{-VER_PLATFORM_WIN32_NT-}
  end;
end;

Wobei die Manifeste natürlich mit jeder neuen Win-Version angepasst werden.

[edit]Die Windows-Version-Prüfung habe ich natürlich in eine DLL ausgelagert, d.h. wenn z.B. in Kürze ein neues Buid der 10-er Preview kommt, dann tausche ich einfach die DLL aus und muss nicht gleich die komplette App neu compilieren

[Insider2004]

Übertreibt ihr nicht ein wenig? Ich hatte seit 20 Jahren nie die Notwendigkeit, die Windows Version abzufragen. Mein Zeugs ist so gemacht, dass es auf allen Windowsen läuft.

[mm1256]

Nun, "laufen" ist die eine Sache, aber wie löst du OS-Abhängige Situationen, z.B. wenn deine App unter normalem Userkontext läuft, und du eine App mit Admin-Rechten starten musst. Ein Beispiel, wie ich meine, wo man das OS kennen sollte oder muss:

Delphi-Quellcode:

{------------------------------------------------------------------------------}
{-- Anwendung starten, wenn nötig mit Admin-Rechten                          --}
{------------------------------------------------------------------------------}
function RuWin_ShellExec(aHandle: HWND; FileName, Parameters, Directory: string;
                         ShowCmd: Integer; AsAdmin, Wait: boolean): Boolean;
var
  SEI: TShellExecuteInfo;
begin
  FillChar(SEI, SizeOf(SEI), #0);
  SEI.cbSize := SizeOf(SEI);
  SEI.Wnd := aHandle;
  SEI.fMask := SEE_MASK_NOCLOSEPROCESS;
  {-Bis zu XP "AsAdmin" automatisch ignorieren-}
  if WindowsVersion < WinVista then AsAdmin := false;
  if AsAdmin
  then SEI.lpVerb := 'runas'
  else SEI.lpVerb := 'open';
  SEI.lpFile := PChar(FileName);
  SEI.lpParameters := PChar(Parameters);
  SEI.lpDirectory := PChar(Directory);
  SEI.nShow := ShowCmd;
  Result := ShellExecuteEx(@SEI);
  if Result then
  if Wait then begin
    if SEI.hProcess > 32 then begin
      WaitForInputIdle(SEI.hProcess, INFINITE);
      WaitForSingleObject(SEI.hProcess, INFINITE);
    end;
  end;
  CloseHandle(SEI.hProcess);
end;

Oder, wie löst man das besser?

[Bernhard Geyer]

Zitat:

Zitat von mm1256 (Beitrag 1284270)

Nun, "laufen" ist die eine Sache, aber wie löst du OS-Abhängige Situationen,

Für einfache Anwendungen beschränkt man sich halt auf das kleinest OS.
Und mit dynamischen Laden der API-Einsprungspunkte kann man auch einiges abfangen.

[greenmile]

Ich finde das alles ein wenig Overkill. Ich binde die Ressource mit $R ein und gut is'. So schnell kommen keine neuen Windows Versionen und falls mal eine ganz plötzlich um die Ecke kommt passe ich meine Ressource an. Ist mir lieber als Registry-Einträge zu lesen, die können morgen auch weg sein.