 | ||||||
| ||||||
Open Software Description (OSD) files are used to describe software components, their versions, their underlying structures and their dependence on other components. This article describes the design and organization of OSD files.
All OSD files have the same basic foundation. Each OSD file starts out with the Extensible Markup Language (XML) version identification and the documentation type declaration (DTD) file. The declaration includes the path to the OSD DTD file, which describes all the elements that are supported by OSD.
The following example shows the XML version identification and DTD (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 namespace can be created that references that DTD file.
The following example shows how to create the XML namespace msicd for the Internet Component Download DTD file.
<?XML::namespace href="http://www.microsoft.com/standards/osd/msicd.dtd"
as="msicd"?>
The XML namespace allows any of the elements defined in the Microsoft Internet Component Download Reference to be used in the following format (where <element> is an element described in the reference):
msicd::<element>
The main section of an OSD file begins and ends with the SOFTPKG element. 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 typical OSD file is arranged 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>
As previously mentioned, <SOFTPKG> and </SOFTPKG> are the opening and closing elements 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 name and summarize 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>
All three sections (JAVA, NATIVECODE, DEPENDENCY) are not required in an OSD file. For example, if a software author is distributing a stand-alone Java application, the NATIVECODE and DEPENDENCY sections won't appear in the OSD.
Notice that the JAVA, NATIVECODE, and DEPENDENCY sections are similarly arranged in the OSD file.
|
<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> |
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® 2000, 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="http://www.programs-r-us/hello-95.cab">
</IMPLEMENTATION>
<IMPLEMENTATION>
<OS VALUE="winnt" />
<CODEBASE HREF="http://www.programs-r-us/hello-nt.cab">
</IMPLEMENTATION>
<IMPLEMENTATION>
<OS VALUE="mac" />
<CODEBASE HREF="http://www.programs-r-us/hello-mac.cab">
</IMPLEMENTATION>
</CODE>
</MSICD::NATIVECODE>
Notice that the CODEBASE in each IMPLEMENTATION grouping actually points to different cabinet files (.cab) on the server. The CODEBASE element is described in the next section.
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 cabinet file as the OSD file, in which case you don't need to use CODEBASE at all. Your browser will automatically look in the current cabinet file.
If the files are somewhere on the Internet, the CODEBASE element points to that URL.
<CODEBASE HREF="http://www.server1.com/install-me.cab">
Complex setup instructions, such as for adding/modifying registry entries, creating advanced setup functionality in custom destination directories, and so on, are not possible using OSD syntax alone. An INF file is required for such complex setup functionality.
You can point to an INF file located in the same cabinet file as the OSD file. This is an effective way of processing a subset of setup:
<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>
CODE items under NATIVECODE get processed in the order in which they appear in the OSD file, but they get installed and registered in the reverse of their order in the OSD file. 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 file (see Using INF Files for details), the order of processing between CODE items and items in the [Add.Code] section in the INF file is as if the CODE items appeared before items in [Add.Code]. Packages under JAVA are installed before CODE items under NATIVECODE.
The following articles provide more information about subjects related to Internet Component Download and Open Software Description.
Overviews
References
Tutorials
Did you find this topic useful? Suggestions for other topics? Write us!
© 1999 Microsoft Corporation. All rights reserved. Terms of use.
Back to top