Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-7013109

windows application manifest problems

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • P2
    • 7
    • 7
    • infrastructure
    • 7
    • b128
    • generic, x86
    • generic, windows_7
    • Verified

    Description

      It appears we don't have the application manifests built properly in JDK
      7 for windows.

      We started adding manifests way back in 6u87
      6722527: Need manifest for every exe file in jre/bin directory
      http://monaco.sfbay.sun.com/detail.jsf?cr=6722527

      This created a manifest resourcesrc/windows/resource/template.manifest
      which was included into the "version.rc" file picked up
      by the resource compiler (rc.exe), which then applied the manifest
      to the .exe files.

      Next, because apps apparently can't have two manifests and pass the
      windows logo test we consequently lost the AWT manifest as noted in:
      6748350: REGRESSION:Eclipse does not pick up the correct theme for Vista
      http://monaco.sfbay.sun.com/detail.jsf?cr=6748350
      To fix it these were combined in src/windows/resource/template.manifest

      [NB its a bit confusing to me that 6748350 is a regression since the work to
      pick up those styles,
      6359035: Apply WinXP visual styles to AWT native dialogs ,
      was apparently new in 6u10. That fix also went into JDK 7 b02]

      The result of the manifest change is that whilst there's no per
      "dll" manifests in 6u10+ the .exe ones look like this :

      java.exe in 1.6.0_21

      <?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
      -
      <assemblyxmlns="*urn:schemas-microsoft-com:asm.v1*"manifestVersion="*1.0*">
      <assemblyIdentity
      version="*6.0.210.51*"processorArchitecture="*X86*"name="*java.exe*"type="*win32*"/>

      <description>Java(TM) SE Runtime Environment java Process.</description>
      -<dependency>
      -<dependentAssembly>
      <assemblyIdentity
      type="*win32*"name="*Microsoft.Windows.Common-Controls*"version="*6.0.0.0*"processorArchitecture="***"publicKeyToken="*6595b64144ccf1df*"language="***"/>

      </dependentAssembly>
      </dependency>
      -<!--

       Identify the application security requirements.

      -->
      -<trustInfoxmlns="*urn:schemas-microsoft-com:asm.v3*">
      -<security>
      -<requestedPrivileges>
      <requestedExecutionLevel level="*asInvoker*"uiAccess="*false*"/>
      </requestedPrivileges>
      </security>
      </trustInfo>
      </assembly>


      Now in theory 6722527 this should have been part of the 6u10 forward
      port of deployment work
      in jdk 7 b64, but actually I don't see that the template was brought
      forward at all, nor do I even see the references to it that were
      in make/common/Program.gmk, version.rc, various tool Makefiles
      in 6u10, so I don't think this forward port was complete as it
      omitted the JDK portion of the fix:
      Clearly we are not getting the combined manifest here :

      java.exe in 1.7.0 b02 - b107

      <?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
      -
      <assemblyxmlns="*urn:schemas-microsoft-com:asm.v1*"manifestVersion="*1.0*">
      <assemblyIdentity
      version="*1.0.0.0*"processorArchitecture="*X86*"name="*Sun Microsystems,
      Inc., Java(tm) 2 Standard Edition*"type="*win32*"/>
      <description>AWT</description>
      -<dependency>
      -<dependentAssembly>
      <assemblyIdentity
      type="*win32*"name="*Microsoft.Windows.Common-Controls*"version="*6.0.0.0*"processorArchitecture="***"publicKeyToken="*6595b64144ccf1df*"language="***"/>

      </dependentAssembly>
      </dependency>
      </assembly>


      Finally, when we switched compilers to VS2010, LINK.EXE" is being used instead to
      auto-generate
      a default manifest, which is then applied using MT.EXE
      I suspect, but am not sure, that this "over-writes" the one added by RC.EXE
      with the result that we have again regressed
      6748350: REGRESSION:Eclipse does not pick up the correct theme for Vista
      but we were already in a mess anyway ..

      The reason MT.EXE is being used began with the VS2005/VS2008 work where
      manifests needed to be used to support side-by-side assembly for the
      C runtime.

      java.exe in 1.7.0 b125

      -
      <assemblyxmlns="*urn:schemas-microsoft-com:asm.v1*"manifestVersion="*1.0*">
      -<trustInfoxmlns="*urn:schemas-microsoft-com:asm.v3*">
      -<security>
      -<requestedPrivileges>
      <requestedExecutionLevel level="*asInvoker*"uiAccess="*false*"/>
      </requestedPrivileges>
      </security>
      </trustInfo>
      </assembly>

      I'm not sure which is the path of least resistance, and/or better solution

      If we want to use "rc.exe" to apply manifests we don't need LINK.EXE
      or MT.EXE to be involved at all so far as I can see, but we need to
      forward port the 6u10 work that was supposed to be there already.

      If we want to use MT.EXE we don't need to forward port that work
      (although I'd sure like to see a webrev of the original work to compate)
      and instead probably just need to make MT.EXE use our hand-coded template
      rather than the LINK generated one.

      The JDK7 manifest file needs to be augmented with the UAC level of course
      but I also notice that in 6ux there are capitalised strings
      IMVERSION and PROGRAM in the template
      and these are replaced with a build string such as 6.0.230.4
      and program name such as "javaw" or "appletviewer"
      the code in 6ux gets these in there using SED.
      So maybe we don't need RC but we do need to bring forward some part
      of the 6ux fix after all.

      Since in 6ux there's no manifests at all on the DLLs I'm not sure
      if we need them here in JDK7 either, even with VS2010.
      As it is all there was in there pertained to UAC which only
      applies to programs.

      Attachments

        Issue Links

          Activity

            People

              prr Philip Race
              prr Philip Race
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: