The cabinet file is an efficient way to package components on Web pages. You can use cabinet files to deploy Java classes for use through Internet Explorer 3.0 and 4.0. Cabinet files also support installation of Java classes in the Java Package Manager when used with Internet Explorer 4.0.
When packaging with cabinet files, you should understand:
For More Information For more information on digital signing, see Distribution Unit Signing and Security.
The Java language supports the concept of Java packages to manage the namespace of classes, but does not provide for installing or managing packages. The Microsoft® Win32® Virtual Machine for Java (Microsoft VM) provides package management services with the Java Package Manager (JPM). Microsoft Internet Explorer 4.0 uses the Java Package Manager to provide code download services for Java applets. You can exploit these code download services by using the Microsoft development environment to package your Java classes into a cabinet file.
In order to use Internet Explorer 4.0 and Java Package Manager code download services, all the Java classes in the cabinet file must be in a Java Package. A Java Package is a collection of classes that share a common namespace. For instance, if a class named "test.java" contains the line "package com.ms.fx", the full name of the compiled class would be "com.ms.fx.test". For further information about how to create Java packages, see the Visual J++ documentation.
Cabinet files can contain an inventory file called an .osd file. The Microsoft development environment automatically creates the .osd file. This file contains a list of all the Java packages and applications in the cabinet file. The .osd file instructs Internet Explorer 4.0 to install the contents of the cabinet in the Java Package Manager. The .osd file also contains a friendly name that is displayed in the Windows Downloaded Program Files folder when the cabinet file is installed.
Cabinet files can carry additional security information in the digital signature to specify Java permissions. When signing cabinet files that contain Java components, you can specify the permissions that the Java component requires, allowing the components to access more features of the local system. This brings applets equal to the capabilities of Microsoft® ActiveX® controls without sacrificing the security in the Java implementation.
Signing a cabinet file with Java permissions gives developers more detailed control over the security restrictions placed on their Java component. Java permissions are optional.
Setting Java permissions also cuts down on the number of dialog boxes presented to your user. Java classes may automatically receive some permissions when Microsoft Internet Explorer zones are used.
Note If you are using only ActiveX controls in your cabinet file, do not use the Java permissions for signing security levels.
Cabinet files may contain both Microsoft ActiveX Controls and Java code. Because ActiveX controls must be fully trusted to run, they are treated differently from Java code. For ActiveX controls to run when they are in a cabinet file that uses Java permission signing, you must specify that the cabinet file may contain ActiveX controls in the signature. Then, when you include ActiveX controls in the cabinet file, they will either be denied, allowed to run, or query the user, depending on the security settings of the zone.
With the Microsoft development environment, you can easily sign a cabinet file at four possible security levels: high, medium, low, and custom.
High security level means lots of restriction for your Java applet or application. This level ensures that the Java code contained in the cabinet file will only run in the Java "sandbox" (a protected space that prevents the applet from accessing files and selected system services). Signing a cabinet file with the high security setting ensures that the Java code will never be able to do more than it would in the sandbox, regardless of where the code came from or what the user allows it to do. Because the Java code is so restricted, the applet or application will be allowed to run without any intervention from your user.
Medium security level means high security with some exceptions for your Java applet or application. Applets signed with the medium security level request user-directed I/O, store data (up to 1MB) in the user's computer scratch space (storage on the client machine that an applet can safely access without needing full access to the client file system), and call user-directed file I/O routines, to ensure that all file operations are done with your user's intervention. A cabinet file signed with medium security will run without intervention in Low and Medium security zones. Zones are areas of control as defined by Microsoft Internet Explorer.
Low security level means there are no restrictions on the Java code in the cabinet. Only a zone set at Low security can grant this much access without first asking the user. High and medium security prompt the user before running the applet.
With the custom level, you can set the specific, individual permissions that the Java classes need.
You can reach these settings in the development environment by right-clicking on your cabinet packaging project and pointing to Properties. These options are listed in the Java Permission tab of the Cabinet Properties dialog box.
For More Information For more information, see "Trust-Based Security for Java" in the Microsoft SDK for Java.
When Java classes are packaged into cabinet files and .zip files, the HTML tags that reference the classes in the cabinet files and .zip files must also reference the deployed cabinet files and .zip files. The Microsoft development environment deployment feature performs all required modifications to the HTML to ensure that all <APPLET> and <OBJECT> tag references to Java classes deployed in cabinet files and .zip files are properly maintained.
As components on Web pages become larger and more complex, it is increasingly important to find a fast and effective way to download the required classes. By default, Java classes are downloaded one .class file at a time and in uncompressed format. In this case, not only is additional time needed to negotiate the transfer of each file, but extra bytes may be transferred because of the lack of compression. For feature and class-rich Java authored components, this download time can be excessive.
A cabinet file can serve as a single, compressed repository for all .class files and all audio and image data required by the Java applet. Only the cabinet file is downloaded, so the time of download is whatever it takes to negotiate the transfer and download the compressed bytes. Once downloaded, the system extracts and installs the contents of the cabinet file.