Re: GetVersionEx() depreciated, what should be used instead for Windows 7/8/10?

[Christian Franke <Christian.Franke@t-online.de>]

Corinna Vinschen via Cygwin wrote:
> On Mar 20 12:39, Christian Franke via Cygwin wrote:
>> Corinna Vinschen via Cygwin wrote:
>>> You have to create an application with an application manifest not
>>> supporting your OS.
>>>
>>> For Cygwin apps, this occured when you built, say, an executable under
>>> Windows 8.1 before Windows 10 support was added to the Cygwin toolchain:
>>> the manifest linked to the Cygwin executable didn't yet contain a GUID
>>> entry for Windows 10 support.
>>>
>>> In this case, RtlGetVersion returns an OS version 6.3 even when running
>>> under the 10.0 kernel.  This behaviour exists back 'til Windows Vista.
>> Could not reproduce the latter on Win10. I tested with recent Win10 and
>> Win11 and also found a Win10 1511 (and Slackware 1.1.2, Win3.1, OS/2, ...)
>> in my VM image museum.
>>
>> Regardless of the exe manifest, RtlGetVersion and RtlGetNtVersionNumbers
>> return the correct versions:
>> 10.0.22621 (Win11 22H2)
>> 10.0.19045 (Win10 22H2)
>> 10.0.10586 (Win10 1511)
>>
>> Without a manifest, GetVersionEx returns:
>> 6.2.9200 (Win8)
> Please check on commit 48511f3d3847c.  It was a real, existing problem
> at the time.  I wouldn't have added the RtlGetNtVersionNumbers call
> just for fun.
>

Of course.
I learned about the existence of RtlGetNtVersionNumbers via this commit 
and was curious, which Windows versions were affected but found none. 
This suggests that only some early Win10 versions were affected.

-- 
Regards,
Christian