public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: GetVersionEx() depreciated, what should be used instead for Windows 7/8/10?
Date: Tue, 19 Mar 2024 17:20:54 +0100	[thread overview]
Message-ID: <Zfm7ZqZBdMBaoEOM@calimero.vinschen.de> (raw)
In-Reply-To: <CANV9t=QHLHyv_jvvrCREpyrEX=JqmTdQvnmfUXbSKuvMrhHn9A@mail.gmail.com>

On Mar 19 09:18, Bill Stewart via Cygwin wrote:
> 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.

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.

Fortunately Microsoft didn't change the required manifest GUID entry
since the introduction of Windows 10.  Even Windows 11 is still using
the same GUID.


Corinna

  reply	other threads:[~2024-03-19 16:20 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-19  6:25 Cedric Blancher
2024-03-19 10:20 ` Christian Franke
2024-03-19 14:03   ` Bill Stewart
2024-03-19 15:00     ` Richard Campbell
2024-03-19 15:18       ` Bill Stewart
2024-03-19 16:20         ` Corinna Vinschen [this message]
2024-03-19 16:32           ` Bill Stewart
2024-03-20 11:39           ` Christian Franke
2024-03-20 14:26             ` Bill Stewart
2024-03-20 19:06             ` Corinna Vinschen
2024-03-21  8:58               ` Christian Franke
2024-03-21 15:15                 ` Corinna Vinschen
2024-03-22 22:13                   ` Ray Satiro
2024-03-23  9:37                     ` Corinna Vinschen
2024-03-23  9:57                   ` Christian Franke
2024-03-23 21:04                     ` Corinna Vinschen
2024-03-24 14:42                       ` Christian Franke
2024-03-24 21:05                         ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zfm7ZqZBdMBaoEOM@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).