Info-Fenster von Windows anzeigen

[Assarbad]

Zitat von jaenicke:

Du musst in deinem Anwendungsmanifest angeben, dass deine Anwendung mit Windows 10 kompatibel ist, dann wird auch alles korrekt angezeigt.

Wer schummeln möchte, darf auch gern RtlGetVersion aus der ntdll.dll bemühen:

Code:

NTSTATUS
NTAPI
RtlGetVersion(
    LPOSVERSIONINFOEXW lpVersionInformation
);

Also wenn mich mein Delphi-Foo nicht ganz verlassen hat, sollte das in etwa so aussehen:

Delphi-Quellcode:

type
    NTSTATUS = LONG; // oder JwaWinType.pas
// JwaWinNT.pas hat OSVERSIONINFOEXW ... und nein, es ist kein Schreibfehler daß es die W-Version ist
function RtlGetVersion(var osvix: OSVERSIONINFOEXW): NTSTATUS; stdcall;
// Nicht vergessen dwOSVersionInfoSize auszufüllen vor dem Aufruf!!!

Da gibt's dann die ehrliche Version auch ohne Manifest.

[Assarbad]

Zitat von Willie1:

Aber wenn der Programmierer mit dem Manifest selbst bestimmt, welche Version es sein soll, ist eine Abfrage wohl tatsächlich unnötig. Ich verstehe die Absicht von Microsoft nicht!

Es hat sich einiges an Semantik in den einzelnen Windowsversionen geändert. In Anniversary-Release wäre da bspw. die Nutzung langer Pfadnamen (nicht mehr PATH_MAX == 260) zu nennen.

Programme ab Windows XP dürfen sich aussuchen welche Version der Common Controls sie benutzen. Auch das wird über das Manifest gesteuert.

Im Grunde besagt das Manifest also: Hör mal, ich weiß bescheid über die Eigenheiten von Windows X.Y, keine Notwendigkeit mir was vorzugaukeln. Dementsprechend sollte so ein Programm dann aber auch über High-DPI und andere moderne Funktionen bescheid wissen und sich entsprechend verhalten.

Raymond Chen hat schon vor langer Zeit darüber geschrieben warum die Versionsabfragen unheimlich kompliziert sind und warum neuere Windowsversionen schummeln müssen. Viele ältere Programme haben nämlich selten dämliche Versionsprüfungen eingebaut (so nach dem Motto: Hauptversion >=5 und Unterversion >=1 ... und dann meinen man hätte alle Windowsversionen ab XP abgedeckt). Daher auch die neueren Funktionen ala VerifyVersionInfo. Da aber ältere Programme sich nicht verändern und damit auch kein Manifest bekommen werden in dem steht "ick kenn mir aus mit Windows 10, wa?!", funktioniert die von MS beabsichtigte Methode zur Rückwärtskompatibilität erstaunlich gut.

[jaenicke]

Zitat von Willie1:

Aber wenn der Programmierer mit dem Manifest selbst bestimmt, welche Version es sein soll, ist eine Abfrage wohl tatsächlich unnötig. Ich verstehe die Absicht von Microsoft nicht!

Wie Assarbad schon geschrieben hat, liegt der Grund in fehlerhaften Versionsprüfungen durch viele Entwickler in der Vergangenheit.

Viele haben einfach wie Assarbad schrieb auf >= Version XY geprüft, viele aber auch auf Majorversion = 5 usw.
Dadurch liefen viele Programme nur durch die Versionsprüfung nicht unter neueren Versionen von Windows und andere ließen sich starten, funktionierten aber nicht.

Die einzig sinnvolle Versionsprüfung wäre auf das Feature zu prüfen, das man benötigt. Denn wenn man etwas verwendet, das in einer neueren Version nicht mehr drin ist, hilft es nix, dass die Version >= Version XY ist...
Und umgekehrt wurden auch schon Features per Update zur Verfügung gestellt, z.B. einiges in XP SP3. Anwendungen, die auf die Windowsversion prüfen, würden dann aber nicht funktionieren obwohl das Feature dort dann doch verfügbar ist.

Durch die Angabe im Manifest für welche Version eine Anwendung entwickelt wurde, kann Windows nun spezifische Kompatibilitätsoptionen automatisch anwenden, weil es weiß was es in der Version gab.

[Assarbad]

Zitat von jaenicke:

Die einzig sinnvolle Versionsprüfung wäre auf das Feature zu prüfen, das man benötigt.

Genau das ermöglicht natürlich bekanntlich COM, aber man muß Kopfstände machen um das auch nutzen zu können, weil bei zu niedriger Angabe der WINVER die entsprechenden Symbole und GUIDs einfach versteckt werden. Warum sollte es auch nicht einem für Windows 2000 geschriebenen Programm möglich sein auf Windows 7 die Fortschrittsleiste in der Taskbar zu benutzen? Ermitteln ob man das COM-Interface instanziieren kann, würde als Prüfung ausreichen.

[mm1256]

Aus diesen Gründen (einfach+zuverlässig, auch in Zukunft, egal was MS irgendwann mal wieder anstellt) verwende ich zur Windows-Versions-Bestimmung die FileInfo aus der kernel32.dll. Dazu brauchst du weder COM, Manifest, Win-API oder sonst welches Gedöns.

[Assarbad]

Na dann viel Erfolg. Falls dein Programm wirklich so supercool sein sollte, kannst du vermutlich allerlei anstellen und MS wird sich danach bemühen die Kompatibilität zu neueren Windowsversionen für dich zu gewährleisten. So wie sie es auch in der Vergangenheit machten. Ansonsten fällst du unter Umständen durch's Raster. Aber das ist schließlich deine Sache, denn du verläßt dich auf etwas zu dem MS keinen Vertrag abgeschlossen hat. Die API hingegen ist ein Vertrag auf den du dich verlassen kannst. Kurzum: du trägst das volle Risiko.

Im übrigen bist du mit deiner Methode dann wieder bei händischen Versionsüberprüfungen ala (Hauptversion >=5 und Unterversion >=1). Ich will nicht anzweifeln, daß du es richtig hinbekommen kannst, aber können und machen sind zwei verschiedene Handschuhe.

Die von jaenicke vorgeschlagene Methode ist aber in jedem Fall überlegen, da sie darauf abzielt, daß das Programm ermittelt welche Funktionen in der Laufzeitumgebung bereitstehen und sich dementsprechend verhält. Das hat auch nix mit COM per-se zu tun, sondern COM funktioniert nach diesem Blackbox-Prinzip. Will heißen wenn du eine GUID/CLSID hast dann kannste dich darauf verlassen, daß wenn du das Interface instanziieren kannst, es auch da ist.

[jaenicke]

Zitat von mm1256:

Aus diesen Gründen (einfach+zuverlässig, auch in Zukunft, egal was MS irgendwann mal wieder anstellt) verwende ich zur Windows-Versions-Bestimmung die FileInfo aus der kernel32.dll.

Und genau deshalb gibt es bei Microsoft die Überlegung bei der Prüfung der Versionen solcher System-DLLs ebenfalls emulierte Werte zurückzuliefern...
Eben weil durch die Umgehung der offiziellen Wege genau die genannten Probleme weiter da sind. Durch dieses Gefrickel durch diverse Programmierer ist der ganze Kompatibilitätslayer ja nur so kompliziert.

Wenn du natürlich nur einen Notepad-Klon schreibst, ist die Wahrscheinlichkeit, dass du ein bestimmtes Feature brauchst, nicht so hoch. Da braucht man aber eigentlich auch keine Versionsinfo-Prüfung. Aber bei allen etwas komplexeren Projekten sollte man das ganze schon sauber lösen.

Die Featureprüfung geht natürlich auch bezogen auf API-Funktionen. Wenn ich eine bestimmte API-Funktion brauche, schaue ich einfach nach, ob diese da ist. Fehlt diese in früheren oder zukünftigen Windowsversionen, weiß ich, dass mein Programm dort definitiv nicht funktioniert und kann das auch so dem Benutzer anzeigen.

[mm1256]

Hab's mir schon gedacht, dass ihr diese Vorgehensweise "zerlegt". Fakt ist aber, dass die Fileinfo Bestandteil des PE-Aufbaus ist und sich in zig Jahren nicht geändert hat und sich wohl zukünftig auch nicht ändern wird, denn sonst würde man alles abschießen, was es mal vorher gegeben hat. Und darum ist die Fileinfo eine zukunftsfähige Lösung. Auch wenn Windows wieder mal an der API rum schrauben sollte. Dann gehen nämlich z.B. die Manifeste wieder genauso den Bach runter, wie beim Wechsel von 8.0 zu 8.1.

[jaenicke]

Zitat von mm1256:

Fakt ist aber, dass die Fileinfo Bestandteil des PE-Aufbaus ist und sich in zig Jahren nicht geändert hat und sich wohl zukünftig auch nicht ändern wird

Darum geht es auch gar nicht so sehr. Das Problem ist ja die fehlerhafte Verwendung der so gewonnenen Daten durch sehr viele Programmierer.
Wenn alle das nur in einem Info-Fenster anzeigen würden und sich nen Kullerkeks drüber freuen würden, wäre das ja kein Problem. Problematisch wird es wie gesagt, wenn auf dem Wege versucht wird festzustellen, ob das eigene Programm unter der Windowsversion läuft.