Add app compatibility GUID for Windows 8 to chrome, mini_installer, and setup's manifests

Add app compatibility GUID for Windows 8 to chrome, mini_installer, and setup's manifests

As per the "Windows 8 and Windows Server 2012 Compatibility Cookbook"'s "App (executable) manifest" entry at http://msdn.microsoft.com/en-us/library/windows/desktop/hh848036(v=vs.85).aspx, this will turn on:

Shell themes status in high contrast mode
Windows 8: Returns the real theming status for when in high contrast mode.
Windows 7: Returns theming as unavailable when in high contrast mode because DWM is still on.
Windows Vista (default): Returns theming as unavailable when in high contrast mode because DWM is still on.

Shell iPersistFile::Save method
Windows 8: CShellLink::Save now determines if the IPersistFile handler is called with a relative path argument and fails the call if it is.
The public documentation describing this behavior indicates that path argument has to be an absolute path:
Windows 7 and earlier (default): CShellLink::Save does not determine if the iPersistFile handler sends a relative path check and allows apps to continue working with absolute or relative paths.

Program Compatibility Assistant (PCA)
Windows 8: Apps with the compatibility section do not get the PCA mitigation.
Windows 7: Apps with the compatibility section are tracked for potential compatibility issues for Windows 8 changes (described in this document).
Windows Vista (default): Apps that fail to install properly or crash during runtime under some specific circumstances get the PCA mitigation. For more information, see the Resources section.

Everything else will remain the same as the already turned on Windows 7 behavior for Chrome.

BUG=127765
TEST=Build, install, and run Chrome on Windows 8.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=152552

[gab, 2012-08-20 20:19:39]

Sir, as discussed in an email thread, enabling Win8 compatibility mode.

[robertshield, 2012-08-20 21:00:14]

On 2012/08/20 20:19:39, gab wrote:
> Sir, as discussed in an email thread, enabling Win8 compatibility mode.

should we add this manifest to delegate_execute.exe as well? if so, any others?

[gab, 2012-08-20 21:28:46]

On 2012/08/20 21:00:14, robertshield wrote:
> On 2012/08/20 20:19:39, gab wrote:
> > Sir, as discussed in an email thread, enabling Win8 compatibility mode.
> 
> should we add this manifest to delegate_execute.exe as well? if so, any
others?

Makes sense, on that note though we probably want to have a single manifest be
the root of all our executables (e.g. this is only used to augment the manifest
generation as specified at [1]; we could have one manifest file and point all
similar gyp entries to it).

The only difference right now is that chrome.exe.manifest, as opposed to the
other 2 manifests, has:
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="Win32" name="Microsoft.Windows.Common-Controls"
version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df"
language="*"></assemblyIdentity>
    </dependentAssembly>
  </dependency>

but this dates back to http://crrev.com/5851. From the very old codereview there
I gather that this was originally put in there as we used to replace the
manifest with ours... now that we have VS merge them we probably don't need
this.

I suggest we have one manifest, as below, and have all our executables use the
same one (and even if we should need more things in say chrome.exe.manifest and
not others one day, we can always add chrome.manifest.extra to
AdditionalManifestFiles say):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <!--The ID below indicates application support for Windows Vista -->
      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
      <!--The ID below indicates application support for Windows 7 -->
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
      <!--The ID below indicates application support for Windows 8 -->
      <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
    </application>
  </compatibility>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker" />
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

[1]
http://code.google.com/searchframe#OAMlx_jo-ck/src/chrome/chrome_exe.gypi&exa...

[robertshield, 2012-08-20 21:33:23]

On 2012/08/20 21:28:46, gab wrote:
> On 2012/08/20 21:00:14, robertshield wrote:
> > On 2012/08/20 20:19:39, gab wrote:
> > > Sir, as discussed in an email thread, enabling Win8 compatibility mode.
> > 
> > should we add this manifest to delegate_execute.exe as well? if so, any
> others?
> 
> Makes sense, on that note though we probably want to have a single manifest be
> the root of all our executables (e.g. this is only used to augment the
manifest
> generation as specified at [1]; we could have one manifest file and point all
> similar gyp entries to it).
> 
> The only difference right now is that chrome.exe.manifest, as opposed to the
> other 2 manifests, has:
>   <dependency>
>     <dependentAssembly>
>       <assemblyIdentity type="Win32" name="Microsoft.Windows.Common-Controls"
> version="6.0.0.0" processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
> language="*"></assemblyIdentity>
>     </dependentAssembly>
>   </dependency>
> 
> but this dates back to http://crrev.com/5851. From the very old codereview
there
> I gather that this was originally put in there as we used to replace the
> manifest with ours... now that we have VS merge them we probably don't need
> this.
> 
> I suggest we have one manifest, as below, and have all our executables use the
> same one (and even if we should need more things in say chrome.exe.manifest
and
> not others one day, we can always add chrome.manifest.extra to
> AdditionalManifestFiles say):
> 
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
>   <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
>     <application>
>       <!--The ID below indicates application support for Windows Vista -->
>       <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
>       <!--The ID below indicates application support for Windows 7 -->
>       <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
>       <!--The ID below indicates application support for Windows 8 -->
>       <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
>     </application>
>   </compatibility>
>   <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
>     <security>
>       <requestedPrivileges>
>         <requestedExecutionLevel level="asInvoker" />
>       </requestedPrivileges>
>     </security>
>   </trustInfo>
> </assembly>
> 
> [1]
>
http://code.google.com/searchframe#OAMlx_jo-ck/src/chrome/chrome_exe.gypi&exa...

sgtm. lgtm here so that you can commit this first then do the other thing.

[commit-bot: I haz the power, 2012-08-20 21:49:56]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/gab@chromium.org/10837344/1

[commit-bot: I haz the power, 2012-08-20 21:50:01]

Failed to apply patch for chrome/app/chrome.exe.manifest:
While running patch -p1 --forward --force;
patching file chrome/app/chrome.exe.manifest
Hunk #1 FAILED at 3.
Hunk #2 FAILED at 24.
2 out of 2 hunks FAILED -- saving rejects to file
chrome/app/chrome.exe.manifest.rej