On Tuesday 14 May 2013 00:37:36 Sergey Cheban wrote:
The manifests are used for several puropses in Windows: 1. To specify the dependencies between components. 2. To specify the security level of the application. 3. To specify the compatibility level between the application and the operating system. 4. To register the COM classes implemented in the assembly.
According to the MSDN (http://msdn.microsoft.com/en-us/library/f2c0w594%28v=vs.80%29.aspx), "if /MANIFEST is not specified and the linker is passed /MANIFESTDEPENDENCY comments, a manifest file will be created".
If there are no /MANIFESTDEPENDENCY options and the /MANIFEST option is specified, some manifest will be generated anyway. Its content will depend on the /MANIFESTUAC linker option.
By default, the following manifest is generated: ================================= <?xml version='1.0' encoding='UTF-8' standalone='yes'?> <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedPrivileges> <requestedExecutionLevel level='asInvoker' uiAccess='false' /> </requestedPrivileges> </security> </trustInfo> </assembly> =================================
In msvc-9.0, the CRT contains the /manifestdependency comment, and so the manifest is generated by default and bjam uses it. In msvc-10.0 and msvc-11.0, the CRT does not contain the /manifestdependency comment, and so the manifest is not generated by default.
Generally speaking, the modern windows application should have the manifest inside. Otherwise, the modern versions of Windows will run it in the compatibility mode (for example, they may guess the required security level from the name of the executable file).
Thanks for the explanation. So we basically need to always pass /MANIFEST to the linker and probably make embed-manifest feature on by default? Worth trying, but not right now while we wait for test results on Boost.Log and Boost.TTI. I'll try that locally tomorrow.