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

[Ray Satiro]

On 3/21/2024 11:15 AM, Corinna Vinschen via Cygwin wrote:
> On Mar 21 09:58, Christian Franke via Cygwin wrote:
>> 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)
> I just gave it a try on W11. The results are even more funny than I
> anticipated:
>
> I created a simple application just calling GetVersionEx, RtlGetVersion
> and RtlGetNtVersionNumbers.
>
> Linked with our Cygwin default manifest claiming W10 compatibility, the
> result is the expected:
>
>    GetVersionEx          : 10.0.22631
>    RtlGetVersion         : 10.0.22631
>    RtlGetNtVersionNumbers: 10.0.22631
>
> The "Operating system context" in Task Manager is empty.
>
> Next I linked against a Windows 8.1 manifest:
>
>    GetVersionEx          : 6.3.9600
>    RtlGetVersion         : 10.0.22631
>    RtlGetNtVersionNumbers: 10.0.22631
>
> So GetVersionEx reports Windows 8.1, RtlGetVersion/ RtlGetNtVersionNumbers
> both report W10.  The "Operating system context" in Task Manager reports
>
>    "Windows 8.1"
>
> No surprise there.
>
> Next I linked against a Windows 7 manifest:
>
>    GetVersionEx          : 6.2.9200
>    RtlGetVersion         : 10.0.22631
>    RtlGetNtVersionNumbers: 10.0.22631
>
> So GetVersionEx reports Windows 8, not Windows 7.
>
> However, the "Operating system context" in Task Manager reports
>
>    "Windows 7"
>
> I also tried this with a Vista manifest:
>
>    GetVersionEx          : 6.2.9200
>    RtlGetVersion         : 10.0.22631
>    RtlGetNtVersionNumbers: 10.0.22631
>
>    "Windows Vista"
>
> So Task Manager reports the right context per the manifest, but
> GetVersionEx doesn't go below Windows 8.
>
> Same goes for Windows 10...
>
>    GetVersionEx          : 6.2.9200
>    RtlGetVersion         : 10.0.19045
>    RtlGetNtVersionNumbers: 10.0.19045
>
>    "Windows Vista"
>
> as well as for Windows 8.1:
>
>    GetVersionEx          : 6.2.9200
>    RtlGetVersion         : 6.3.9600
>    RtlGetNtVersionNumbers: 6.3.9600
>
>    "Windows Vista"
>
> So, yeah, with your observations especially on older W10 versions and
> with 8.1 doing the same thing, I guess we can safely drop the extra call
> to RtlGetNtVersionNumbers now.  After such a long time, I don't know
> on which version of Windows we observed the problem.
>
> For those interested in patch forensics, I searched the archives and
> came up with two mail threads referring to GetVersionEx and RtlGetVersion:
>
>    https://cygwin.com/pipermail/cygwin/2013-November/211795.html
>    https://cygwin.com/pipermail/cygwin/2014-June/215836.html
>
> Unfortunately I found*no*  thread talking about RtlGetNtVersionNumbers,
> so the only information we have now is the commit message of
>
>    https://cygwin.com/cgit/newlib-cygwin/commit/?id=48511f3d3847c


The code in that commit doesn't look right. RtlGetNtVersionNumbers is a 
void function and the third parameter may not be just the build number. 
The first two parameters are sort of known because the CRT used to use 
it to get the major and minor version but passed NULL for the third 
parameter.

typedef void (__stdcall *NTVERSION_INFO_FCN)(PDWORD, PDWORD, PDWORD);

I assume that it contains at least the build number and type (production 
or checked), according to a blog post discussing it [1].

Here's results from a test program [2] with manifest on Windows 11:

 >test-RtlGetNtVersionNumbers.exe
GetVersionExW: 10.0.22000
RtlGetVersion: 10.0.22000
RtlGetNtVersionNumbers: 10 major, 0 minor, 4026553840 unknown
LOWORD of unknown: 22000 (0x55f0)
HIWORD of unknown: 61440 (0xf000)


[1]: 
https://dennisbabkin.com/blog/?t=how-to-tell-the-real-version-of-windows-your-app-is-running-on
[2]: https://gist.github.com/jay/ae07fba61fe6853f5620eb142c66807b