Thanks Brad.

As I've been writing this code, I was looking for the build number and came 
across the code in cmGlobalGenerator that sets the CMAKE_HOST_SYSTEM_VERSION. 
Even though GetVersionEx is deprecated, it is the right way to get the system 
version, loading ntdll and getting RtlGetVersion is not a good practice as 
those are private APIs that could change. On newer systems (Windows 8 and 
above) by default the version returned doesn't go beyond Windows 8 Build 9200, 
but you can apply a manifest to the executable that will let the API give you 
the correct information and this is a more correct way of handling this.

I don't know if there's another reason for the code to be as it is, but I think 
it would be a better practice to opt into the proper GetVersionEx behavior by 
adding a manifest than by calling GetProcAddress on an internal API.

-----Original Message-----
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Wednesday, September 9, 2015 08:00
To: Gilles Khouzam <gilles.khou...@microsoft.com>
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support

On 09/03/2015 03:19 PM, Gilles Khouzam wrote:
> Perhaps the default selection (at least for Store apps since that's 
> the one that requires the flag) should be the newest SDK less than the 
> version of the host System.

Yes, I think that makes sense.

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Reply via email to