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