About OSD File Architecture
Note This technology is obsolete as of Windows Internet Explorer 7 and should not be used.
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.
- OSD File Foundation
- XML Namespace
- The SOFTPKG Element
- The TITLE and ABSTRACT Elements
- Three Sections of an OSD File
- The IMPLEMENTATION Element
- The CODEBASE Element
- Complex Setup Instructions
- Processing Order
- Related topics
OSD File Foundation
All OSD files have the same basic foundation. Each OSD file starts out with the XML version identification and the Document Type Definition (DTD) file. The definition includes the path to the OSDDTD 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 "https://msdn.microsoft.com/workshop/standards/osd/osd.dtd">
XML Namespace
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="https://msdn.microsoft.com/workshop/standards/osd/msicd.dtd"
as="msicd"?>
The XML namespace allows any 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 SOFTPKG 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 "https://msdn.microsoft.com/workshop/standards/osd/osd.dtd">
<?XML::namespace href="https://msdn.microsoft.com/workshop/standards/osd/msicd.dtd"
as="msicd"?>
<SOFTPKG NAME="unique name of distribution" HREF="http://www..." VERSION="4,0,5,0">
<MSICD::JAVA> ... </MSICD::JAVA>
<MSICD::NATIVECODE> ... </MSICD::NATIVECODE>
<DEPENDENCY> ... </DEPENDENCY>
</SOFTPKG>
The TITLE and ABSTRACT Elements
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 "https://msdn.microsoft.com/workshop/standards/osd/osd.dtd">
<?XML::namespace href="https://msdn.microsoft.com/workshop/standards/osd/msicd.dtd"
as="msicd"?>
<SOFTPKG NAME="unique name or GUID" VERSION="1,0,0,0" HREF="http://www...>
<TITLE>My Very First Distribution!</TITLE>
<ABSTRACT>This software distribution installs
my Hello World program written in C++</ABSTRACT>
.
.
.
</SOFTPKG>
Three Sections of an OSD File
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> |
The IMPLEMENTATION Element
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 Windows 98, a PC running 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.
The CODEBASE Element
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 automatically looks 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
Complex setup instructions, such as for adding or 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>
Processing Order
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.
Related topics
Conceptual
Introduction to Internet Component Download
Introduction to Open Software Description
Microsoft Internet Component Download Reference