-
Bug
-
Resolution: Fixed
-
P2
-
7
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.
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.
- duplicates
-
JDK-6994393 javaw.exe is missing 'Microsoft.Windows.Common-Controls' dependency in assembly
-
- Closed
-
- relates to
-
JDK-6829055 Update application manifests with new Windows 7 dpiAware section
-
- Closed
-
-
JDK-8055453 Not possible to specify a Java application as per-monitor DPI aware in Windows 8
-
- Closed
-