Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version
On 09/18/2015 02:24 PM, Brad King wrote: > After working out the support for manifests across all generators > as discussed elsewhere in this thread, I've added your manifest > file to CMake's own build: > > Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8 (#15674) > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cdd15551 That broke the build of cmake-gui due to an incorrect relative path to the manifest file. I've revised the commit accordingly: Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8 (#15674) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=17009189 -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
Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version
On 09/18/2015 02:58 PM, James Johnston wrote: > While on the subject, there are some other additions to the manifest you > might want to consider. I think these are worth considering but we're too close to the 3.4 freeze to make these changes now. Please look at adding these during post-3.4 development. 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
Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version
> -Original Message- > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] > On Behalf Of Brad King > Sent: Friday, September 18, 2015 18:24 > To: Gilles Khouzam > Cc: cmake-developers@cmake.org > Subject: Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: > Correctly determine Windows version > > On 09/10/2015 07:24 PM, Gilles Khouzam wrote: > > This patch adds a simple version manifest > > Source\cmake.version.manifest to the CMake executables. > > After working out the support for manifests across all generators as > discussed elsewhere in this thread, I've added your manifest file to CMake's > own build: > > Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8 (#15674) > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cdd15551 While on the subject, there are some other additions to the manifest you might want to consider. The above block will disable UAC heuristics on Windows Vista and above, such that elevation won't ever be requested. It will also disable the Program Compatibility Assistant for Vista IIRC. (as I understand it, supportedOS wasn't added until Windows 7. Why there is a GUID in there for Vista, I'm not sure. App manifests are not the best documented thing on MSDN IMHO.) It would probably be appropriate to use this for all CMake executables. The above block will declare a preference to use the newer common controls library introduced with Windows XP. Without this, Windows will fall back on the old Windows 2000 era of common controls (i.e. Windows 95 style buttons). This would be appropriate for cmake-gui. Since it uses Qt though, the effect is probably minimal, but if some API were called such that native Win32 controls were used somewhere, this would improve the appearance. http://schemas.microsoft.com/SMI/2005/WindowsSettings;> True/PM The above block will make the cmake-gui DPI aware, such that DPI virtualization is disabled on Windows Vista and above. In laymen's terms, it fixes "blurry text". It looks like Qt already does this (I just tested CMake 3.3 on a high DPI profile.) See http://doc.qt.io/qt-5/highdpi.html. Probably they do it by calling the SetProcessDpiAwareness function. However, this API has some caveats; from MSDN: " The SetProcessDPIAware function in Windows Vista and later versions sets the current process as DPI-aware. However, the use of the SetProcessDPIAware function is discouraged. For example, if a DLL caches DPI settings during initialization, invoking SetProcessDPIAware in your application might generate a possible race condition. For this reason, we recommend that an application enable DPI awareness by using the application's assembly manifest rather than by calling SetProcessDPIAware." --- https://msdn.microsoft.com/en-us/library/windows/desktop/dn469266(v=vs.85).a spx And also: " If you use the SetProcessDpiAwareness method to set the DPI awareness level, you must call SetProcessDpiAwareness prior to any Win32API call that forces the system to begin virtualization." The safer path seems to me to be put it in the manifest, as recommended by MSFT. Note there are two possible values: "True" and "True/PM". "PM" stands for per-monitor DPI aware (introduced with Windows 8.1). Looks like Qt supports PM now, but since it was introduced in Windows 8.1, probably only very recent versions of Qt. You'd have to be careful what is in the manifest agrees with the version of Qt being used. (e.g. you don't want to declare "True/PM" on a non-PM older version of Qt, else no per-monitor scaling would happen at all - virtualized or otherwise). Since Qt does call SetProcessDPIAware and cmake-gui does seem to scale OK right now, including this block may end up being a little "pointless" in practice, despite the caveats from MSDN above. Finally there is this block; I'm not exactly sure which versions of Windows might actually require this or what. I'm a little fuzzy on why I included it. Most of the built-in Windows accessories seem to have this in their manifests though. IIRC it's especially needed with the common controls manifest block. Best regards, James Johnston -- 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
Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version
Great. Thanks -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Friday, September 18, 2015 11:24 To: Gilles KhouzamCc: cmake-developers@cmake.org Subject: Re: [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version On 09/10/2015 07:24 PM, Gilles Khouzam wrote: > This patch adds a simple version manifest > Source\cmake.version.manifest to the CMake executables. After working out the support for manifests across all generators as discussed elsewhere in this thread, I've added your manifest file to CMake's own build: Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8 (#15674) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cdd15551 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
Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version
On 09/10/2015 07:24 PM, Gilles Khouzam wrote: > This patch adds a simple version manifest Source\cmake.version.manifest > to the CMake executables. After working out the support for manifests across all generators as discussed elsewhere in this thread, I've added your manifest file to CMake's own build: Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8 (#15674) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cdd15551 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
Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version
On 09/10/2015 07:24 PM, Gilles Khouzam wrote: > This patch fixes the issue where on Windows 8 and above, by > default the system version returned is always Windows 8. > > In order for GetVersionEx to work properly, a manifest must be > embedded in the exe telling it to ignore the new behavior and > give the proper version. Thanks. I've started by extracting the changes to GetVersionEx calls. Yesterday I reverted the recent RtlGetVersion change: Revert "Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8.1" http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4c7744c8 I rebased your patch on that and applied the part that gets the third version component: Windows: Set CMAKE_HOST_SYSTEM_VERSION with three components http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4734df5f I also extracted the KWSys part of the change and applied it upstream: http://review.source.kitware.com/20180 http://review.source.kitware.com/20181 Once those test cleanly they will be integrated into KWSys and then updated in CMake. Then I can rebase everything else on top of that. 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
Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version
Well this is quite cool. :) It's been an issue I've wanted to see addressed as well but haven't had the time to look at it. Not because of CMake itself not having a manifest (the improper GetVersionEx detection didn't affect me), but because I need to embed an app manifest in my own programs. I have some ideas while you are on the subject: 1. No documentation files were updated. I wonder if there is a good place in the docs for this? 2. If the user doesn't use the Visual Studio generator, still support embedding the manifest. For example, if I use Ninja generator in conjunction with Visual C++'s link.exe I'd like user-specified manifests to be merged with mt.exe. The second request is currently a big pain point with CMake to get working correctly. Ideally I want to reproduce the VS way of doing things, which is: a. Have link.exe generate default manifest for referencing the CRT side-by-side assemblies. b. Use mt.exe to put it all together in the output. Because CMake already does *some* things with the linker it makes it impossible for me to cleanly specify and use link.exe manifest-related switches myself. For example, it hard-codes usage of link.exe /MANIFESTFILE and the user can't specify their own location. And the locations it does use are undocumented. See Source/cmcmd.cxx and search for vs_link_exe to see what I'm talking about. (For that matter, git grep CMake for vs_link_exe and vs_link_dll to see how those commands end up getting used in the first place). Ultimately for now I wound up with this kludge to get link.exe intermediate manifest AND my own: if(CMAKE_CONFIGURATION_TYPES) # multiple-configuration generator? # WARNING: This magic directory location is an undocumented aspect of the # Visual Studio generator. list(APPEND inputManifests ${CMAKE_CURRENT_BINARY_DIR}/${AAM_TARGET}.dir/$/$<TARGET_FILE_NAME:$ {AAM_TARGET}>.intermediate.manifest ) else() # Can't change /MANIFESTFILE because CMake assumes the default... (see above) list(APPEND inputManifests $<TARGET_FILE:${AAM_TARGET}>.manifest) endif() list(APPEND inputManifests my_own_manifests.manifest) Which is then fed into add_custom_command( POST_BUILD COMMAND mt.exe -manifest ${inputManifests} ). Basically I'm hard-coding the hard-coded /MANIFESTFILE: locations used by various CMake generators, since it doesn't work for me to try to change it. Obviously the situation is not ideal because CMake makes no promises about where it puts the intermediate manifests from the linker. It would be certainly be nice if CMake supported user-provided manifests across most/all Windows generators as first-class support, not just Visual Studio 10. Especially the make-like tools (various Makefile generators, Ninja). :) Best regards, James Johnston From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Gilles Khouzam Sent: Thursday, September 10, 2015 23:25 To: Brad King Cc: cmake-developers@cmake.org Subject: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version This patch fixes the issue where on Windows 8 and above, by default the system version returned is always Windows 8. More info on this can be found on http://blogs.msdn.com/b/cjacks/archive/2009/03/27/manifesting-for-compatibil ity-on-windows-7.aspx In order for GetVersionEx to work properly, a manifest must be embedded in the exe telling it to ignore the new behavior and give the proper version. This patch adds support to specify manifests and teaches CMake how to embed them using Visual Studio. This patch adds a simple version manifest Source\cmake.version.manifest to the CMake executables. This removes the use of RtlGetVersion and properly uses GetVersionEx which will now return the proper operating system version for all operating systems until Windows 10. This patch also fixes a potential buffer overrun and improper call of GetVersionEx in SystemTools.cxx where GetVersionExW is called with a OSVERSIONINFOEXA struct causing a failure since the size is improper for the API. Fixing this, GetVersionEx should never fail anymore. Update the OSVersionAndName for new versions of Windows released after Windows 7. This change will require a double compile of CMake (I'm not sure if this is what the dashboards are doing) to have the functionality enabled, since the first step will build a new CMake that will know how to embed a manifest. The second compile with the version of CMake that knows how to embed a manifest, will then embed the manifest in CMake enabling this feature. Thanks ~Gilles -- 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 offe
[cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version
This patch fixes the issue where on Windows 8 and above, by default the system version returned is always Windows 8. More info on this can be found on http://blogs.msdn.com/b/cjacks/archive/2009/03/27/manifesting-for-compatibility-on-windows-7.aspx In order for GetVersionEx to work properly, a manifest must be embedded in the exe telling it to ignore the new behavior and give the proper version. This patch adds support to specify manifests and teaches CMake how to embed them using Visual Studio. This patch adds a simple version manifest Source\cmake.version.manifest to the CMake executables. This removes the use of RtlGetVersion and properly uses GetVersionEx which will now return the proper operating system version for all operating systems until Windows 10. This patch also fixes a potential buffer overrun and improper call of GetVersionEx in SystemTools.cxx where GetVersionExW is called with a OSVERSIONINFOEXA struct causing a failure since the size is improper for the API. Fixing this, GetVersionEx should never fail anymore. Update the OSVersionAndName for new versions of Windows released after Windows 7. This change will require a double compile of CMake (I'm not sure if this is what the dashboards are doing) to have the functionality enabled, since the first step will build a new CMake that will know how to embed a manifest. The second compile with the version of CMake that knows how to embed a manifest, will then embed the manifest in CMake enabling this feature. Thanks ~Gilles Issue15674.patch Description: Issue15674.patch -- 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