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

[Bill Stewart <bstewart@iname.com>]

[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]

On Tue, Mar 19, 2024 at 9:01 AM Richard Campbell wrote:

On Tue, Mar 19, 2024 at 9:04 AM Bill Stewart via Cygwin <cygwin@cygwin.com>
> wrote:
>
> > Can you please clarify the circumstances under which the RtlGetVersion
> > function "may not return the correct values"?
>
> "Originally, using RtlGetVersion instead of GetVersionEx was supposed to
> fix the fact that GetVersionInfo returns the wrong kernel version if the
> executable has been built with an old manifest (or none at all), starting
> with Windows 8.1.  Either this never really worked as desired and our
> testing was flawed, or this has been changed again with Windows 10, so
> that RtlGetVersion does the kernel faking twist as well.  Since we're
> only reading the value in the first process in a process tree. the entire
> process tree is running with a wrong OS version information in that case.
>
> Fortunately, the (undocumented) RtlGetNtVersionNumbers function is not
> affected by this nonsense, so we simply override the OS version info
> fields with the correct values now."
>
> https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=48511f3d3847c35352d09cded56e25f0c1b22bc9
>

Interesting. I have not yet been able to find a scenario where the
RtlGetVersion function gets "manifested" like GetVersionEx.

I wrote a small Win32 console utility for displaying and testing OS
information (requires Windows Vista/Server 2008 or later):

https://github.com/Bill-Stewart/osinfo

It uses RtlGetVersion, and this function works correctly for me in all
current Windows versions (Windows 10, Server 2016, Windows 11, Server 2019,
Server 2022, etc.).

I'm not sure of the exact scenario that led to the "RtlGetVersion is
subject to manifesting" conclusion, but I can't reproduce it.

I would be interested to know what results the osinfo.exe tool reports in
these scenarios.

Regards,

Bill