Embedding manifest into the regression tests (was: [testers] [log] Problems with tests)
On 13.05.2013 13:23, Andrey Semashev wrote:> On Mon, May 13, 2013 at 12:58 PM, Sergey Cheban <s.cheban@drweb.com> wrote:
The problem is related to the fact that MS Windows (at least, Windows Server 2012) requires elevation for the execulables with names that match the *patch*.exe mask. So, util_dynamic_type_disPATCHer and util_static_type_disPATCHer require elevation. lol, what a wonderful and obvious security policy on MS part, isn't it? :)
I've found that the same tests succeeded for the msvc-9.0 toolset. It is because the manifest file is generated for this toolset. I've found that the "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\crtdefs.h" file contais the following: =============================================== #pragma comment(linker,"/manifestdependency:\"type='win32' " \ "name='" __LIBRARIES_ASSEMBLY_NAME_PREFIX ".DebugCRT' " \ "version='" _CRT_ASSEMBLY_VERSION "' " \ "processorArchitecture='x86' " \ "publicKeyToken='" _VC_ASSEMBLY_PUBLICKEYTOKEN "'\"") =============================================== and the "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\crtdefs.h" and "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\crtdefs.h" contain no such code. The bjam scripts embed the manifest into the executable if it was generated by the linker. And the linker generates the manifest by default if the /manifestdependency option was specified. May be, it is reasonable to add the "/MANIFEST" to the linker options explicitly. Btw, I see the following in the msvc.jam: ================================================ if [ MATCH ^([67]) : $(version) ] { .... } else { .... # Make sure that manifest will be generated even if there is no # dependencies to put there. toolset.flags $(toolset).link LINKFLAGS $(conditions)/<embed-manifest>off : /MANIFEST ; } ================================================ -- Sergey Cheban
On Monday 13 May 2013 16:06:01 Sergey Cheban wrote:
I've found that the same tests succeeded for the msvc-9.0 toolset. It is because the manifest file is generated for this toolset. I've found that the "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\crtdefs.h" file contais the following: =============================================== #pragma comment(linker,"/manifestdependency:\"type='win32' " \ "name='" __LIBRARIES_ASSEMBLY_NAME_PREFIX ".DebugCRT' " \ "version='" _CRT_ASSEMBLY_VERSION "' " \ "processorArchitecture='x86' " \ "publicKeyToken='" _VC_ASSEMBLY_PUBLICKEYTOKEN "'\"") =============================================== and the "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\crtdefs.h" and "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\crtdefs.h" contain no such code.
The bjam scripts embed the manifest into the executable if it was generated by the linker. And the linker generates the manifest by default if the /manifestdependency option was specified.
May be, it is reasonable to add the "/MANIFEST" to the linker options explicitly.
I know little about Windows manifests, but if I'm not mistaken, /manifestdependency describes the dependency to be put in the manifest and /MANIFEST only tells the linker to generate the .manifest file. If MSVC 10 and 11 removed their /manifestdependency then what should be put into the manifest?
Am 13.05.2013 19:50, schrieb Andrey Semashev:
On Monday 13 May 2013 16:06:01 Sergey Cheban wrote:
[snip] The bjam scripts embed the manifest into the executable if it was generated by the linker. And the linker generates the manifest by default if the /manifestdependency option was specified.
May be, it is reasonable to add the "/MANIFEST" to the linker options explicitly.
I know little about Windows manifests, but if I'm not mistaken, /manifestdependency describes the dependency to be put in the manifest and /MANIFEST only tells the linker to generate the .manifest file. If MSVC 10 and 11 removed their /manifestdependency then what should be put into the manifest?
Is this really about dependency? In Visual Studio, MSBuild is configured to insert this into .exe link options by default: /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed Ciao, Dani
On Monday 13 May 2013 20:39:21 Daniela Engert wrote:
Am 13.05.2013 19:50, schrieb Andrey Semashev:
On Monday 13 May 2013 16:06:01 Sergey Cheban wrote:
[snip] The bjam scripts embed the manifest into the executable if it was generated by the linker. And the linker generates the manifest by default if the /manifestdependency option was specified.
May be, it is reasonable to add the "/MANIFEST" to the linker options explicitly.
I know little about Windows manifests, but if I'm not mistaken, /manifestdependency describes the dependency to be put in the manifest and /MANIFEST only tells the linker to generate the .manifest file. If MSVC 10 and 11 removed their /manifestdependency then what should be put into the manifest?
Is this really about dependency? In Visual Studio, MSBuild is configured to insert this into .exe link options by default:
/MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed
From MSDN ([1], [2]) this seems to be the default, if manifest is generated.
I'm not sure what is the problem with manifests as it seems it should be generated by default. So either it is not generated when there are no /manifestdependency entries or I'm missing something. I hope someone with more experience can comment on this. [1] http://msdn.microsoft.com/en-us/library/f2c0w594.aspx [2] http://msdn.microsoft.com/en-us/library/bb384691.aspx
13.05.2013 21:50, Andrey Semashev пишет:
>> May be, it is reasonable to add the "/MANIFEST" to the linker options
>> explicitly.
> I know little about Windows manifests, but if I'm not mistaken,
> /manifestdependency describes the dependency to be put in the manifest and
> /MANIFEST only tells the linker to generate the .manifest file. If MSVC 10 and
> 11 removed their /manifestdependency then what should be put into the
> manifest?
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).
--
Best regards,
Sergey Cheban
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.
participants (3)
-
Andrey Semashev -
Daniela Engert -
Sergey Cheban