From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2155) id 0B0DB3858D1E; Tue, 19 Mar 2024 16:20:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0B0DB3858D1E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1710865256; bh=t6RibsIZwuBeTiSux92FB1k7Bc1InxpJg5AtG/v/01I=; h=Date:From:To:Subject:Reply-To:References:In-Reply-To:From; b=GcOupjT8C6VOjuTHgLmoLvW6WksoABsCX6tNdQL3wSBlLDSBbtclnj7pX7IjlTW1+ XHBL/YSNSooZMZhg+2ayzI0FC/JqZ1muYWK6d3I4D2nNQlYW2O7Gehz43MP3uXCPyF ck1Z7mvuhu3dCGF+y35KMzhSWWx4mu+R4O58xd7E= Received: by calimero.vinschen.de (Postfix, from userid 500) id 34A91A80D11; Tue, 19 Mar 2024 17:20:54 +0100 (CET) Date: Tue, 19 Mar 2024 17:20:54 +0100 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: GetVersionEx() depreciated, what should be used instead for Windows 7/8/10? Message-ID: Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: 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. 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