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

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

[Cedric Blancher]

Good morning!

How does cygwin uname -s work, i.e. how does it get the OS version,
revision and build number ('10.0-19045')?
I tried to replicate it via GetVersionEx(), but that is deprecated.

Ced
-- 
Cedric Blancher <cedric.blancher@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

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

[Christian Franke]

Cedric Blancher via Cygwin wrote:
> How does cygwin uname -s work, i.e. how does it get the OS version,
> revision and build number ('10.0-19045')?
> I tried to replicate it via GetVersionEx(), but that is deprecated.
>

AFAICS, MS does not offer an official way to retrieve the actual Windows 
version via the Win32 API layer. GetVersionEx() is unable to detect 
Windows versions which are more recent than the compatibility level 
advertised in the application manifest.

Cygwin uses the undocumented RtlGetNtVersionNumbers() from ntdll.dll 
because even RtlGetVersion() may not return the correct values. See 
function wincapc::init()
https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/wincap.cc

-- 
Regards,
Christian

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

[Bill Stewart]

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

On Tue, Mar 19, 2024 at 4:21 AM Christian Franke wrote:

Cygwin uses the undocumented RtlGetNtVersionNumbers() from ntdll.dll
> because even RtlGetVersion() may not return the correct values. See
> function wincapc::init()
>
> https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/wincap.cc
>

Can you please clarify the circumstances under which the RtlGetVersion
function "may not return the correct values"?

(I am not aware of any, hence the question.)

Bill

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

[Richard Campbell]

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

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


-Richard Campbell.

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

[Bill Stewart]

[-- 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

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

[Corinna Vinschen]

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

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

[Bill Stewart]

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

On Tue, Mar 19, 2024 at 10:21 AM Corinna Vinschen wrote:

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

Interesting. Thanks for the clarification!

Bill

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

[Christian Franke]

Corinna Vinschen via Cygwin wrote:
> 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.

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)

-- 
Regards,
Christian

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

[Bill Stewart]

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

On Wed, Mar 20, 2024 at 5:40 AM Christian Franke wrote:

Corinna Vinschen via Cygwin wrote:
>
> > 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)


Thanks for testing. That was my recollection (RtlGetVersion is not subject
to manifesting).

Bill

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

[Corinna Vinschen]

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.


Corinna

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

[Christian Franke]

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

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

[Corinna Vinschen]

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



Thanks,
Corinna

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

[Ray Satiro]

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

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

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

[Corinna Vinschen]

On Mar 22 18:13, Ray Satiro via Cygwin wrote:
> On 3/21/2024 11:15 AM, Corinna Vinschen via Cygwin wrote:
> >    https://cygwin.com/cgit/newlib-cygwin/commit/?id=48511f3d3847c
> 
> The code in that commit doesn't look right. RtlGetNtVersionNumbers is a void
> function

The code doesn't request a return value.

> and the third parameter may not be just the build number.

Fixed a month later:
https://cygwin.com/cgit/newlib-cygwin/commit/?id=63f19278b998b


Corinna

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

[Christian Franke]

On Mar 21 16:15, Corinna Vinschen via Cygwin wrote:
> On Mar 21 09:58, Christian Franke via Cygwin wrote:
>>>> ..
> I just gave it a try on W11. The results are even more funny than I
> anticipated:
>
> ...
>
> 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.

Or:
Keep RtlGetVersionNumbers, compare result with RtlGetVersion and emit 
debug output if both differ. This would allow to diagnose a possible 
future reappearance of the issue.


>    After such a long time, I don't know
> on which version of Windows we observed the problem.

Some developer preview?

Meantime I also tested with Win10 1607, 1703, 1709, 1803 VM snapshots 
with same result.

-- 
Regards,
Christian

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

[Corinna Vinschen]

On Mar 23 10:57, Christian Franke via Cygwin wrote:
> On Mar 21 16:15, Corinna Vinschen via Cygwin wrote:
> > On Mar 21 09:58, Christian Franke via Cygwin wrote:
> > > > > ..
> > I just gave it a try on W11. The results are even more funny than I
> > anticipated:
> > 
> > ...
> > 
> > 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.
> 
> Or:
> Keep RtlGetVersionNumbers, compare result with RtlGetVersion and emit debug
> output if both differ. This would allow to diagnose a possible future
> reappearance of the issue.

Good idea! Do you want to create a patch?


Thanks,
Corinna

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

[Christian Franke]

Corinna Vinschen via Cygwin wrote:
> On Mar 23 10:57, Christian Franke via Cygwin wrote:
>> On Mar 21 16:15, Corinna Vinschen via Cygwin wrote:
>>> On Mar 21 09:58, Christian Franke via Cygwin wrote:
>>>>>> ..
>>> I just gave it a try on W11. The results are even more funny than I
>>> anticipated:
>>>
>>> ...
>>>
>>> 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.
>> Or:
>> Keep RtlGetVersionNumbers, compare result with RtlGetVersion and emit debug
>> output if both differ. This would allow to diagnose a possible future
>> reappearance of the issue.
> Good idea! Do you want to create a patch?
>

I tried, but without success. Unfortunately debug_printf() does not work 
because wincap.init() is called before get_cygwin_startup_info() which 
calls strace.activate().

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

[Corinna Vinschen]

On Mar 24 15:42, Christian Franke via Cygwin wrote:
> Corinna Vinschen via Cygwin wrote:
> > On Mar 23 10:57, Christian Franke via Cygwin wrote:
> > > On Mar 21 16:15, Corinna Vinschen via Cygwin wrote:
> > > > On Mar 21 09:58, Christian Franke via Cygwin wrote:
> > > > > > > ..
> > > > I just gave it a try on W11. The results are even more funny than I
> > > > anticipated:
> > > > 
> > > > ...
> > > > 
> > > > 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.
> > > Or:
> > > Keep RtlGetVersionNumbers, compare result with RtlGetVersion and emit debug
> > > output if both differ. This would allow to diagnose a possible future
> > > reappearance of the issue.
> > Good idea! Do you want to create a patch?
> > 
> 
> I tried, but without success. Unfortunately debug_printf() does not work
> because wincap.init() is called before get_cygwin_startup_info() which calls
> strace.activate().

small_printf should work, just needs "\r\n" in the Windows console.

But, anyway, nothing speaks aginst just sticking to the current code.
It works and probably continues to work...


Thanks,
Corinna