From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout06.t-online.de (mailout06.t-online.de [194.25.134.19]) by sourceware.org (Postfix) with ESMTPS id AD8D73858CD1 for ; Wed, 20 Mar 2024 11:39:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AD8D73858CD1 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=t-online.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=t-online.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org AD8D73858CD1 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=194.25.134.19 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710934797; cv=none; b=j4KaxgZ/c32P1RznoeeQyuJWPiju5GABbMCvyvcernbktuv15AlvDkHvl3DjfGt/3BMy2XAj/NZHQVHeFmxuMmQpAjgcUL41AAINWGmMcnuuS7Yf42PcjhfNyNQ55Yv+013nyqDTObdbeyVi8Xw20+s5VHfr9YtJvF2ODOQmW/I= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710934797; c=relaxed/simple; bh=U1zAaS0itedKuDl+29BsW5FRXyDqzs89zWAAO83Yp+E=; h=Subject:To:From:Message-ID:Date:MIME-Version; b=LXbAH3Gm+7KBPbO8AYIxa7SJ89DDp5rMw082fReAaU9MxsVNR3m1HeijAAO6beKBsfGsTksKZeB4EKW4/P3AsPHJ3tgPCYwXfnGZ4YHWhw3Bj7KK/+UACweBPRg+vwAW8Xgro1uyhTItEUTiuwz88lUx9UvUaN54uQap7uV0F1g= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fwd87.aul.t-online.de (fwd87.aul.t-online.de [10.223.144.113]) by mailout06.t-online.de (Postfix) with SMTP id CDB7112235 for ; Wed, 20 Mar 2024 12:39:48 +0100 (CET) Received: from [192.168.2.102] ([87.187.47.57]) by fwd87.t-online.de with (TLSv1.3:TLS_AES_256_GCM_SHA384 encrypted) esmtp id 1rmuIO-25J6tU0; Wed, 20 Mar 2024 12:39:48 +0100 Subject: Re: GetVersionEx() depreciated, what should be used instead for Windows 7/8/10? To: cygwin@cygwin.com References: From: Christian Franke Reply-To: cygwin@cygwin.com Message-ID: <0d8daf74-2861-8b08-b47c-28cf5d3b991f@t-online.de> Date: Wed, 20 Mar 2024 12:39:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 SeaMonkey/2.53.16 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TOI-EXPURGATEID: 150726::1710934788-877FD968-3F15E044/0/0 CLEAN NORMAL X-TOI-MSGID: 8180fd73-1132-427d-81fd-01cddb7c4999 X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 >>> 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