Extending Internet Component Download Using OSD


		Contents Index Topic Contents
	Previous Topic: Internet Component Download Using INF Next Topic: Microsoft Internet Component Download Reference

Extending Internet Component Download Using OSD

Microsoft® Internet Explorer 3.0 introduced the Internet Component Download (ICD) mechanism. When visiting a Web page, ICD lets your browser pull down and install programs from the Internet automatically. This gave any software author or vendor the ability to package an application and place it on a server for download. But Internet Component Download, as implemented in Internet Explorer 3.0, was limited for the following reasons:

No support for Java class libraries

No support for stand-alone Java applications

INF files are not written according to any standard syntax or grammar

Old distribution units are limited in flexibility because they cannot adequately express software dependencies

Open Software Description (OSD) provides the Internet Component Download mechanism with the ability to download Java applications, Java packages, and ActiveX™ Controls. OSD also provides the ability to handle complex file dependencies that might be spread out over multiple distribution units on the Internet, and provides automatic installation of missing components.
For more information on Internet Component Download, see the Microsoft Internet Component Download documentation.
Supporting the Extended Functionality

Each distribution unit requires a single OSD file that contains the installation instructions for the application, just as an INF file does. The advantages of OSD are that it is more expressive than INF and it is being written in a standardized form.
An OSD file is supported in the following cases:

Inclusion in cabinet (CAB) files
Exactly one file in the CAB can be an OSD file. The inclusion of an INF file in CAB is still supported for compatibility. Therefore, a CAB file should contain one OSD file, one INF file, or both an INF file and an OSD file. If both file types are present and your browser (for example, Microsoft Internet Explorer 4.0) knows about OSD files, the CAB is processed according to the following priorities:

The parser looks inside the current CAB for the OSD file. If found, it is processed. It is also legal for the OSD file to reference the INF file. In this case, both files are processed, but notice that the OSD file is really in control here.

If there is no OSD file present, the parser looks for an INF file to process.

If your browser (for example, Internet Explorer 3.0) does not know about Open Software Description, the INF file is processed first because that is the only option.

In the CODEBASE attribute of the OBJECT element
The CODEBASE attribute can now point to a stand-alone OSD file, which presents the same security/trust issue as having it point to a stand-alone INF file. Both of these are flat text and are not signable with Authenticode™ tools today, so component download will treat them as unsigned. Microsoft Internet Explorer will decline trust in the default browser security modes. One solution is to package the OSD file as the only file in a single CAB file and sign the CAB file.

OSD skeleton

All OSD files use the same basic skeleton. Each OSD file starts out with the Extensible Markup Language (XML) version identification and the documentation type declaration. The documentation type declaration includes the path to the OSD document type declaration (DTD) file, which describes all the elements that are supported by OSD.
The following example shows the XML version identification and documentation type declaration (with the actual location of the OSD DTD file).
<?XML version="1.0"?>
<!DOCTYPE SOFTPKG SYSTEM "http://www.microsoft.com/standards/osd/osd.dtd">
In many instances, the OSD file requires a richer vocabulary to describe the software or its dependencies. For example, describing native code or Java applications requires the elements defined in the Microsoft Internet Component Download DTD file. To include the Internet Component Download DTD file, an XML name space can be created that references that DTD file.
The following example shows how to create the XML name space msicd for the Internet Component Download DTD file.
<?XML::namespace href="http://www.microsoft.com/standards/osd/msicd.dtd" as="msicd"?>
The XML name space allows any of the elements defined in the Microsoft Internet Component Download Reference to be used in the following format:
msicd::<element>
where <element> is an element described in the reference.
The main section of an OSD file begins and ends with the SOFTPKG tag. The three major sections enclosed inside SOFTPKG are used to express installation instructions for Java code, native code (meaning that the files are platform-dependent), and dependency code (one program is used by another). The basic OSD skeleton looks like this:
<?XML version="1.0"?>
<!DOCTYPE SOFTPKG SYSTEM "http://www.microsoft.com/standards/osd/osd.dtd">
<?XML::namespace href="http://www.microsoft.com/standards/osd/msicd.dtd" as="msicd"?>

<SOFTPKG NAME="unique name of distribution" VERSION="4,0,5,0" STYLE="MSICD">
    <MSICD::JAVA> ... </MSICD::JAVA>
    <MSICD::NATIVECODE> ... </MSICD::NATIVECODE>
    <DEPENDENCY> ... </DEPENDENCY>
</SOFTPKG>
Integration with Java

Unlike INF files, OSD files support the inclusion of Java packages and stand-alone Java applications in a distribution unit. Specifically, this is done with the JAVA and PACKAGE tags.
<MSICD::JAVA>
    <PACKAGE NAME="com.ms.package.basic" VERSION="1,1,0,0">
    .
    .
    .
    </PACKAGE>
</MSICD::JAVA>
Relationship between OSD and INF

As mentioned previously, an OSD file is a markup tag file written according to XML syntax and grammar. An INF file is a file containing name-value pairs. Both serve the same purpose of specifying file dependency, program version number, and computer configuration information.
Using OSD to describe distribution units allows a cascading model, where one distribution unit can be dependent on others, which in turn can be dependent on others, and so on. In contrast, INF can express only one level of dependency. Allowing a component to specify dependencies at a high level allows installation details of dependencies to stay within their CABs versus cluttering the main OSD.
Pointing to an INF from the OSD

One can point to an INF in the same CAB as the OSD, for further processing of a subset of setup in the following manner. Setup capability, such as adding/modifying registry entries, advanced setup functionality in custom destination directories, and so on, is not available in the OSD syntax and so would require being pointed to by an accompanying INF file in the CAB.
<MSICD::NATIVECODE>
    <CODE NAME="Adventure Works Goodbye World"
    CLASSID="84D8E454-1000-1000-1000-45EA43332000"
    VERSION="1,0,0,0">
        <IMPLEMENTATION>
            <OS VALUE="win95" / >
            <CODEBASE FILENAME="goodby.inf" />
        </IMPLEMENTATION>
    </CODE>
</MSICD::NATIVECODE>
Sample OSD file sections

Building on the OSD Skeleton and Integration with Java sections, which contained small samples of what an OSD file looks like, this section will show examples of OSD usage.
Introducing the distribution

As previously mentioned, <SOFTPKG> and </SOFTPKG> are the opening and closing tags in the main section of an OSD file. This is analogous to the roles that <HTML> and </HTML> play in an HTML file. After the opening SOFTPKG, the TITLE and ABSTRACT elements are used to give a more verbose description of the distribution.
<?XML version="1.0"?>
<!DOCTYPE SOFTPKG SYSTEM "http://www.microsoft.com/standards/osd/osd.dtd">
<?XML::namespace href="http://www.microsoft.com/standards/osd/msicd.dtd" as="msicd"?>

<SOFTPKG NAME="unique name or GUID" VERSION="1,0,0,0" STYLE="MSICD">
    <TITLE>My Very First Distribution!</TITLE>
    <ABSTRACT>This software distribution will install
        my Hello World program written in C++</ABSTRACT>
    .
    .
    .
</SOFTPKG>
Setting the file location

Use the CODEBASE element to tell the client browser where the files are located. The simplest case is if the files are already in the same CAB as the OSD file. If this is the case, don't use CODEBASE at all. Your browser will automatically look in the current CAB.
If the files are somewhere on the Internet, make CODEBASE point to that URL.
<CODEBASE HREF=<A HREF="http://www.server1.com/install-me.cab">
    http://www.server1.com/install-me.cab</A> / >
Handling different computer setups

Use the IMPLEMENTATION element to indicate what type of hardware your code requires. The following example shows that the program "Adventure Works Hello World" version 1.1 is available for three types of computer setups: a PC running Microsoft Windows® 95, a PC running Microsoft Windows NT®, and a Macintosh® running MacOS.
<MSICD::NATIVECODE>
    <CODE NAME="Adventure Works Hello World"
    CLASSID="84D8E454-0001-0001-0001-45EA43332000"
    VERSION="1,1,0,0" >

        <IMPLEMENTATION>
            <OS VALUE="win95" />
            <CODEBASE HREF="<A HREF="http://www.programs-r-us/hello-
                95.cab">http://www.programs-r-us/hello-95.cab</A>" />
        </IMPLEMENTATION>

        <IMPLEMENTATION>
            <OS VALUE="winnt" />
            <CODEBASE HREF="<A HREF="http://www.programs-r-us/hello-
                95.cab">http://www.programs-r-us/hello-nt.cab</A>" />
        </IMPLEMENTATION>

        <IMPLEMENTATION>
            <OS VALUE="mac" />
            <CODEBASE HREF="<A HREF="http://www.programs-r-us/hello-
                95.cab">http://www.programs-r-us/hello-mac.cab</A>" />
        </IMPLEMENTATION>
    </CODE>
</MSICD::NATIVECODE>
Notice that the CODEBASE in each IMPLEMENTATION grouping actually points to different files on the server.
Setting dependencies

Following the example above, what if Adventure Works comes out with a new program called "Adventure Works Goodbye World." However, Goodbye World is really an extension of Hello World, so you have to have Hello World on your computer before Goodbye World works properly.
The following sample instructs your computer to get Hello World from the location indicated, and then get Goodbye World.
<SOFTPKG NAME="Adventure Works Goodbye World" VERSION="1,0,0,0" STYLE="MSICD">
    <MSICD::NATIVECODE>
        <CODE NAME="Adventure Works Goodbye World"
        CLASSID="84D8E454-1000-1000-1000-45EA43332000"
        VERSION="1,0,0,0">

        <IMPLEMENTATION>
            <OS VALUE="win95" / >
            <CODEBASE HREF="<A HREF="http://www.programs-r-us/hello-
                95.cab">http://www.programs-r-us/goodbye-95.cab</A>" />
        </IMPLEMENTATION>
        </CODE>
    </MSICD::NATIVECODE>

    <DEPENDENCY ACTION="install">
        <SOFTPKG NAME="Adventure Works Hello World" VERSION="1,1,0,0">
            <IMPLEMENTATION>
                <OS VALUE="win95" />
            <CODEBASE HREF="<A HREF="http://www.programs-r-us/hello-
               95.cab">http://www.programs-r-us/hello-95.cab</A>" />
            </IMPLEMENTATION>
        </SOFTPKG>
    </DEPENDENCY>
</SOFTPKG>
Letting OSD worry about all the dependencies means that users don't have to. They only know that they want the Adventure Works Goodbye World application. If there's anything that Goodbye World needs, it will be installed in the fly.
There are two types of dependencies. Notice that the above example has ACTION="install" as an attribute-value of DEPENDENCY. The other type is ACTION="assert".
For example, a user might be running Goodbye World version 1.0 and like it. When version 1.1 comes out, the user decides not to install it and stays with version 1.0. When patches or updates come out specifically for version 1.1 (which the user doesn't have), how does OSD know not to bother the user with these advertisements that don't pertain to him or her? By using ACTION="assert". The following code section shows how OSD can make an advertisement of a version 1.1 patch only to those people running that version.
<SOFTPKG NAME="Vocabulary Patch for Goodbye World version 1.1 only" VERSION="1,0,0,0">



<DEPENDENCY ACTION="assert">
    <SOFTPKG NAME="Adventure Works Goodbye World" VERSION="1,1,0,0">
        <IMPLEMENTATION>
            <OS VALUE="win95" />
        </IMPLEMENTATION>
    </SOFTPKG>
</DEPENDENCY>
</SOFTPKG>
Therefore, if a computer does not satisfy the prerequisites (having Microsoft Windows 95 and Goodbye World v1.1) indicated in the DEPENDENCY section, it completely ignores this SOFTPKG. Thus the user is not unnecessarily bothered.
More on general OSD structure

The OSD Skeleton section mentions that the OSD file has three main sections: Java, Nativecode, and Dependency. Not all three sections need to appear in an OSD file; only the sections that are used need to be included. For example, if a software author is distributing a stand-alone Java application, the Nativecode and Dependency sections probably won't appear in the OSD.
Notice that the Java, Nativecode, and Dependency items share a similar structure when used in OSD.

<MSICD::JAVA>
<PACKAGE ...>
<IMPLEMENTATION>
<CODEBASE .../>
</IMPLEMENTATION>
</PACKAGE>
</MSICD::JAVA>

<MSICD::NATIVECODE>
<CODE ...>
<IMPLEMENTATION>
<CODEBASE .../>
</IMPLEMENTATION>
</CODE>
</MSICD::NATIVECODE>

<DEPENDENCY>
<SOFTPKG ...>
<IMPLEMENTATION>
<CODEBASE ... />
</IMPLEMENTATION>
</SOFTPKG>
</DEPENDENCY>

Processing order

The DEPENDENCY items to be installed are triggered in the order in which they appear in the OSD file, and they come with no guarantee on the order in which they will actually get installed. The only guarantee is that the dependencies will be installed before the main component in the SOFTPKG tag gets installed. If specific ordering dependencies are necessary, the components should be arranged in a tree fashion as dependency nodes where one can be assured that nodes deepest in the tree will get installed first.
CODE items under NATIVECODE get processed in the order in which they appear in the OSD, but they get installed and registered in the reverse of their order in the OSD. Thus dependent files should be placed below the CODE items that depend on them being available/installed. When the OSD is mixed with an INF (see Internet Component Download INF document for details), the order of processing between CODE items and items in the [Add.Code] section in the INF is as if the CODE items appeared before items in [Add.Code]. Packages under JAVA are installed before CODE items under NATIVECODE.

Top of Page
© 1997 Microsoft Corporation. All rights reserved. Terms of Use.