Discussion :

[Andnotor]

Salut à tous,

Problème étrange que celui-ci : une application correctement manifest-ée, compatible Windows 10, me retournait une version 6.1 (Seven)
J'utilise habituellement GetVersionEx mais voulais voir ce que retournait TOSVersion. Je reviens donc à GetVersionEx mais même constat, 32 ou 64 bits, toujours 6.1 !

Windows 10 Anniversary ayant apporté son lot de "petites" incompatibilités, je copie cet exe dans Program Files (on ne sait jamais) et boum... version 10 !
Je relance cet exe depuis le répertoire de debug (hors Delphi) et... 10 aussi

Constatation : lancer une app depuis Delphi (avec ou sans debug) entraîne l'impossibilité de récupérer une version correcte de l'OS.
A tout hasard, je contrôle encore le manifest de Delphi (Berlin), on ne sait jamais, peut-être que le nouveau processus hérite des privilèges du processus parent mais aussi de son niveau de compatibilité. Mais non, Delphi est bien déclaré compatible Windows 10.

Bref quelque chose de pas net la derrière... à voir si cela se produit aussi avec les versions antérieures de Delphi.


Mais c'est pas fini !

J'avais effectivement besoin de tester Windows 10 Anniversary. La version étant toujours 10.0, c'est le build qu'il faut contrôler : 14393 correspond à la version 1607 (2016, juillet. En passant, Microsoft est en train de nous refaire un bogue de l'an 2000 avec ces années sur deux chiffres, vivement 2100 !).
Mais TOSVersion.Build renvoie "0" ! Je contrôle l'implémentation de TOSVersion et étonnamment, après un GetVersionEx standard, le build est remis à zéro si l'OS est supérieur à 6.1, une obscure fonction NetWkstaGetInfo récupérant à nouveau les versions majeure et mineure est lancée et si tout s'est bien passé, ben... le build reste à zéro, sinon il est à nouveau récupéré mais en lisant cette fois-ci les infos de version de kernel32.dll

Pas net non plus, à revoir !

[foetus]

Cela ne semble pas être un bogue

Si je lis bien, cela voudrait dire que ton manifest ou ton application est seulement/ au plus compatible Windows 7 (6.1)

Source GetVersionEx function :

Applications not manifested for Windows 8.1 or Windows 10 will return the Windows 8 OS version value (6.2). Once an application is manifested for a given operating system version, GetVersionEx will always return the version that the application is manifested for in future releases.

Targeting your application for Windows :

In Windows 8.1 and Windows 10, the GetVersion and GetVersionEx functions have been deprecated. In Windows 10, the VerifyVersionInfo function has also been deprecated. While you can still call the deprecated functions, if your application does not specifically target Windows 8.1 or Windows 10, you will get Windows 8 version (6.2.0.0).

[Andnotor]

Si je lis bien, cela voudrait dire que ton manifest ou ton application est seulement/ au plus compatible Windows 7 (6.1)

Non, non. Une app sans information de compatibilité retournera Windows 8 (6.2), cette limitation a été introduite sous Windows 8.1.

J'ai tout de même encore essayé de supprimer toute compatibilité et là, nouvelle surprise : TOSVersion renvoie bien 10 (toujours hors Delphi) alors que GetVersionEx, 6.2 (normal). NetWkstaGetInfo a (avait) donc une certaine utilité mais qui est maintenant gênante sous Anniversary (build=0).

Mais ce n'est pas tant les manifests qui m'interpellent, ce sont des limitations connues (et gérées), mais la différence de comportement sous ou hors Delphi. On ne peut tout simplement pas déboguer une app en mode Windows 10...

[foetus]

Non, non. Une app sans information de compatibilité retournera Windows 8 (6.2), cette limitation a été introduite sous Windows 8.1.

Mais il te manque la suite: "Once an application is manifested for a given operating system version, GetVersionEx will always return the version that the application is manifested for in future releases. "

Donc si GetVersionEx te retourne 6.1 (Windows 7) c'est que ton application est "compatible" 6.1

On ne peut tout simplement pas déboguer une app en mode Windows 10...

Mais quelle surprise

Microsoft a voulu supprimer la Win32 de façon brutale avec Windows 8 (en sachant qu'il travaille depuis début 2000 sur couper les ponts): ce fut un four.
Maintenant il passe par la méthode détournée: pousser UWP avec des coups de pouce.

[Andnotor]

Donc si GetVersionEx te retourne 6.1 (Windows 7) c'est que ton application est "compatible" 6.1

En l’absence de manifest, l'application tourne en mode Vista mais cela n'a rien à voir avec la récupération de la version de l'OS qui a été rendue dépendante de ce manifest que depuis Windows 8.1.

With the release of Windows 8.1 (...) Applications not manifested for Windows 8.1 or Windows 10 will return the Windows 8 OS version value (6.2).

Les anciennes applications (ex. créées sous Delphi 2) retourneront au maximum Windows 8.

[SergioMaster]

Bonjour,

curieux, je suis allé voir comment la JVCL (TjvComputerInfoEx) faisait pour me donner la bonne version (enfin je crois )
bien que je n'aime pas trop la méthode : interrogation de la base de registre (et plus parce que je n'aime pas cette base fourre tout de m....e), tout y est

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
ProductId
ProductName
CurrentVersion

et bien plus encore

[Andnotor]

interrogation de la base de registre (et plus parce que je n'aime pas cette base fourre tout de m....e), tout y est

CurrentVersion m'affiche 6.3
Cette info n'est peut-être plus utilisée et n'a pas été mise à jour au passage de 8.1 à 10...

CurrentMajorVersionNumber, CurrentMinorVersionNumber et CurrentBuildNumber sont corrects !
Seule chose un peu gênante, CurrentBuildNumber est une chaîne. Sont-ils susceptibles d'y inscrire autre chose que du numérique ? A voir.

EDIT:
Un petit contrôle sur une version Insider (installation sans mise à jour depuis 8.1) et CurrentVersion affiche aussi 6.3 !

[Jipété]

Salut,

Pourquoi ne pas taper dans la structure OSVERSIONINFOEX avec un peu de parsing ?

Normalement il y a tout, là-dedans (voir la section "Remarks" et son tableau en bas de page).

[SergioMaster]

CurrentVersion m'affiche 6.3
Cette info n'est peut-être plus utilisée et n'a pas été mise à jour au passage de 8.1 à 10...
EDIT:
Un petit contrôle sur une version Insider (installation sans mise à jour depuis 8.1) et CurrentVersion affiche aussi 6.3 !

Idem pour moi, pourtant ProductName est bien à 'Windows 10 ....'
la faute à MS qui garde dans ce fourre-tout tout et n'importe quoi !

Pourquoi ne pas taper dans la structure OSVERSIONINFOEX avec un peu de parsing ?

sauf que, si tu regardes le wproducttype il n'y a ni W8 ni W10

reste à voir ce que l'on peut obtenir avec les WMI (root\CIMV2\Win32_OperatingSystem) je vais faire le test avec WMI code creator (non installé encore sur mon poste W10)

[Edit] après test sur mon poste w10 j'ai bien la version 10.0.10586

[Andnotor]

Pourquoi ne pas taper dans la structure OSVERSIONINFOEX avec un peu de parsing ?

C'est exactement ce qui est fait, GetVersionEx remplit cette structure.

[ShaiLeTroll]

On aurait pas eu le même débat la semaine dernière sur ce problème de version de compatibilité ? Connaître la version de Windows

Il semble qu'au lieu d'une fonction qui renvoie le numéro de version, il y a maintenant une pelleté de fonction pour chaque version
Pour ma part, je ne teste la version que pour choisir le code le plus adapté selon la version et ces fonctions "IsWindows...OrGreater" aurait été utiles si elles ne se basaient pas sur Manifest ou alors qu'un paramètre optionnel permette de récupérer soit la version de l'OS soit la version plafonné par compatibilité
Ils sont vraiment bizarre chez MS avec leur version, merci pour ce lien Targeting your application for Windows !

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

Sinon pour le mode Debug, c'est vrai que c'est un mode de fonctionnement très particulier !
Ce n'est pas la 1ère fois que l'on constate des différences !
Je pense au compter de boucle for, les optimisations, le contenu des variables locales ... combien de bug se produisent en Release ou Hors Delphi mais pas en Debug à cause de différence de paramètrage ou tout simple que le mode Debug introduit un comportement différent (genre le multi-thread)

A tout hasard, je contrôle encore le manifest de Delphi (Berlin), on ne sait jamais, peut-être que le nouveau processus hérite des privilèges du processus parent mais aussi de son niveau de compatibilité. Mais non, Delphi est bien déclaré compatible Windows 10.

C'est là qu'on voit que changer de version de Delphi à son importance
Delphi XE2(9.0) ou XE7 PRO (15.0), le manifest de BDS.exe n'inclue pas la section <compatibility><application> !
Berlin 10.1 Starter (18.0), contient bien le manifest nouvelle génération
D'ailleurs le manifest utilisé par l'exe généré sont aussi nouvelle génération, merci messieurs pour ces informations !

Quand on lance une application Delphi, BDS transmets par exemple ses variables d'environnement,
on peut penser que cela hérite d'autres éléments !
Et on pourrait même penser que BDS lance volontairement l'application en mode compatibilité

[Andnotor]

On aurait pas eu le même débat la semaine dernière sur ce problème de version de compatibilité ? Connaître la version de Windows

C'est suite à ce post que j'ai décidé de tester TOSVersion (j'ai hésité à continuer le même sujet)

Il semble qu'au lieu d'une fonction qui renvoie le numéro de version, il y a maintenant une pelleté de fonction pour chaque version

Effectivement, mais qui ne sont pas encore définies sous Delphi Berlin.

Est-ce que le manifeste des Delphi récents gère cela ?

Depuis Berlin, les manifests sont à jour (jusqu'à Win10).

Sinon pour le mode Debug, c'est vrai que c'est un mode de fonctionnement très particulier !
Ce n'est pas la 1ère fois que l'on constate des différences !

Ce que je constate là ne dépend pas du mode Debug, j'ai le même comportement en Release.
Le problème survient si le processus parent est bds.exe (application lancée depuis Delphi) mais pas si c'est explorer.exe (lancée depuis l'explorateur Windows).

Quand on lance une application Delphi, BDS transmets par exemple ses variables d'environnement,
on peut penser que cela hérite d'autres éléments !

C'est ce que j'ai cru aussi d'où le contrôle du manifest Delphi, de la compatibilité déclarée.

Et on pourrait même penser que BDS lance volontairement l'application en mode compatibilité

C'est bien cela qui me turlupine, sinon que la version détectée dépende du manifest ne me gêne pas plus que cela

[Jipété]

Pourquoi ne pas taper dans la structure OSVERSIONINFOEX avec un peu de parsing ?

C'est exactement ce qui est fait, GetVersionEx remplit cette structure.

Sans doute, mais tu ne nous dis pas comment tu l'appelles, et moi je lis là que l'on peut récupérer une structure ou une autre :

An OSVERSIONINFO or OSVERSIONINFOEX structure that receives the operating system information.

Before calling the GetVersionEx function, set the dwOSVersionInfoSize member of the structure as appropriate to indicate which data structure is being passed to this function.

Pourquoi ne pas taper dans la structure OSVERSIONINFOEX avec un peu de parsing ?

sauf que, si tu regardes le wproducttype il n'y a ni W8 ni W10

C'est exact, il faut parser wProductType + dwMajorVersion + dwMinorVersion.
Regarde à nouveau le tableau dans le lien que j'ai donné.

[foetus]

Je regardais vite fait sur Internet pour cette histoire et je suis tombé sur une bibliothèque StdUtils for NSIS v1.06 en C++ qui annonce "so we need to read the version of kernel32.dll directly now"

Ce sont des génies chez Microsoft