JDK-6607511 : Windows Vista improvements
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u5
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_vista
  • CPU: generic
  • Submitted: 2007-09-21
  • Updated: 2010-04-04
  • Resolved: 2007-10-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Related Reports
Duplicate :  
Relates :  
Relates :  
The new out-of-process Java Plug-In solves many longstanding problems with signed applet support on Windows Vista. However, there are a couple of outstanding issues with the user experience of the new plugin.

1. We need to add an ElevationPolicy registry entry for javaw.exe during installation of the JRE as per http://msdn2.microsoft.com/en-us/library/bb250462.aspx to suppress the security dialog which is presented when launching the medium integrity sub-process which executes the applet.

2. We need to either diagnose why the shared memory transport fails to allow mapping of the file in the medium integrity client process, or implement a transport using named pipes, to work around the Windows Firewall security dialog presented while opening up the port to allow connection of the client and server processes.
After discussion with Microsoft it is clear that more changes are necessary:

3. We need to write a custom broker process rather than registering javaw.exe as a silently elevated broker process. The new broker needs to validate command line arguments, for example disallowing pointing the classpath or boot classpath into the LocalLow directory.
4. The broker process must clear out the JAVA_ARGS environment variable to prevent setting command-line arguments in this manner.

5. The broker process will pass the command-line arguments up to the Java level for consumption by our code via the sun.plugin2.jvm.args system property. It must be forbidden by the launcher as well as via the JVMParameters to set this property.

EVALUATION This bug is being marked as a duplicate of 6622332 for bookkeeping purposes and does not need to be re-verified independently. In the case of a regression please file a new bug.

SUGGESTED FIX http://analemma.sfbay.sun.com/net/jano2/export2/hotspot/users/kbr/webrevs/mjre/6606270_6606271_6606272_partial_6607511_installer/ http://analemma.sfbay.sun.com/net/jano2/export2/hotspot/users/kbr/webrevs/mjre/6607511_vista_improvements/

EVALUATION Changed WindowsIPCFactory to use named events and file mapping objects. This allows use of the shared memory transport on Windows Vista, eliminating the Windows Firewall security dialog associated with using the socket transport. At this point the Windows Vista installable bundles are done; installation is exactly as on Windows XP, with no additional security dialogs, and signed applets work transparently. Passed JVM command-line arguments from our custom Windows Vista launcher to Java via the sun.plugin2.jvm.args system property, and parsed them in PluginMain. This will be used by the fix for verification of secure properties (6607516). Forbade specification of this system property via JVMParameters.

EVALUATION A partial fix for the described problems has been checked in. A new broker process, jp2launcher.exe, has been created and an ElevationPolicy for it is added to the registry by the installer. A helper broker process, jp2ssvbroker.exe, has been created for the new SSV helper object, jp2ssv.dll, and is also given an ElevationPolicy to be able to do its work on Vista. The launcher still needs to pass the command-line arguments up to Java in the form of a system property. From talking with Microsoft, the remaining issues with the shared memory transport are now understood; handles can not really be passed between low integrity controls and their medium integrity broker processes. Window handles (HWNDs) are apparently a special case. Instead, both the file mapping and the event objects will need to be named and the names passed between the parent and sub-processes. This will be a straightforward change.