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

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

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>

[Memnarch]

Zitat von Daniel:

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

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

[mm1256]

Zitat von Memnarch:

Zitat von mm1256:

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

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