A.2 txtsetup.oem Files

This section describes the format of a txtsetup.oem file, and includes a sample txtsetup.oem file at the end of the section.

A txtsetup.oem file consists of several sections that use the following general format:

[SectionName]
key = value1,value2,...
 

The name of the section is enclosed in square brackets, [ ]. The pound sign (#) or semicolon (;) character at the beginning of a line indicates a comment. Strings with embedded spaces, commas, or hashes must be enclosed in double-quotes (“ ”).

The following sections must be included:

Disks Section

The [Disks] section lists all disks in the disk set.

[Disks]
d1 = description,tagfile,directory
d2 = description,tagfile,directory
   .
   .
   .
 
d1, d2, ...
Key that can be used in subsequent sections to identify the disk.
description
Disk name string used to prompt the user to insert the disk
tagfile
Specifies the name of the file whose presence on the disk indicates to the Setup program that the correct disk has been inserted. The file name should be specified as a full path from the root, for example, \yourtagfile.ext, but it should not specify a drive.
directory
Specifies the directory on the disk where the files are located. The directory should be specified as a full path from the root, for example, \diskdir, but it should not specify a drive.
Defaults Section

The [Defaults] section lists the default option for each hardware component supported by this file (as indicated by the presence of a [component] section for the component). The default is highlighted in the menu of options presented to the user.

[Defaults]
component = ID
    .
    .
    .
 
component
Specifies one of the following components: computer, display, keyboard, mouse, CD-ROM, or SCSI.
ID
Specifies a string that identifies the default option. This string matches an ID specified in the corresponding [component] section.
Component Section

A [component] section lists the options available for a particular component.

[component]
ID = description
    .
    .
    .
 
ID
Specifies a unique string (within this section) that identifies the option. For the computer component, if this string ends in “_up”, Setup copies the uniprocessor kernel; if this string ends in “_mp”, Setup copies the multiprocessor kernel; if it ends in neither, the results are unspecified and you might get either kernel.
Files.component.ID Section

A [Files.component.ID] section lists the files that should be copied if the user selects a particular component option. One section of this type must be present for each option listed in each component section. The component portion of the section name corresponds to the name of a [component] section, and the ID portion corresponds to an ID key in a [component] section.

[Files.component.ID]
file_type = source_disk,filename[,keyname]
 
filetype
Identifies the type of file. One of the following is specified:
driver
Valid for all components. File is copied to systemroot\system32\drivers.
port
Valid for keyboard, mouse, and SCSI components. Allows distinction between port and class driver -- but equivalent to driver type.
class
Valid for keyboard and mouse components. If specified, replaces the standard class driver. File is copied to systemroot\system32\drivers.
dll
Valid for all components. Useful for GDI portion of a display driver. File is copied to systemroot\system32.
hal
Valid only for computer component. File is copied to systemroot\system32\hal.dll (80386/80486), or to \os\winnt\hal.dll on the system partition (ARC).
inf
Valid for all components. Used to copy a GUI INF file for use with system maintenance setup. File is copied to systemroot\system32.
detect
Valid for the computer component (80386/80486 only). If specified, replaces the standard 80386/80486 hardware recognizer. File is copied to c:\ntdetect.com.
source_disk
Identifies the disk from which to copy the file, and must match an entry in the [Disks] section.
filename
Name of the file not including the directory path. The filename is appended to the directory specified for the disk in the [Disks] section to form the full path of the file on the disk.
DriverKey
Name of the key to be created in the registry services tree for this file, if the file is of type driver, port, or class. This value is used to form [Config.DriverKey] section names (see below).
Config.DriverKey Section

A [Config.DriverKey] section specifies values to be set in the registry for particular component options. Required values in the Services\DriverKey key are created automatically. Use this section to specify additional keys to be created under Services\DriverKey and values under Services\DriverKey and Services\DriverKey\subkey_name.

[Config.DriverKey]
value = subkey_name,value_name,value_type,value...
    .
    .
    .
 
subkey_name
Specifies the name of a key under the Services\DriverKey tree in which to place the specified value. The key is created if it does not exist. If the empty string (““) is specified, the value is placed under the Services\DriverKey tree.
value_name
Specifies the name of the value to be set within the key.
value_type
A string like REG_DWORD that identifies the type of data for this value. See below.
value
Specifies the actual value; its format depends on value_type.

The following types can be specified in the value_type field in [Config.DriverKey] sections:

REG_DWORD
One value is allowed; it must be a string of 1-8 hex digits.

For example:

value = parameters,NumberOfButtons,REG_DWORD,0X2.
 
REG_SZ, REG_EXPAND_SZ
One value is allowed; it is interpreted as the zero-terminated string to be stored.

For example:

value = parameters,Description,REG_SZ,"This is a text string"
 
REG_BINARY
One value is allowed; it is a string of hex digits, each pair of which is interpreted as a byte value.

For example (stores the byte stream 00,34,ec,4d,04,5a):

value = parameters,Data,REG_BINARY,0034eC4D045a
 
REG_MULTI_SZ
Multiple value arguments are allowed; each is interpreted as a component of the multisz.

For example:

value = parameters,Strings,REG_MULTI_SZ,String1,"String 2",string3
 
Example txtsetup.oem file

The following is an example of a txtsetup.oem file:

[Disks]
d1 = "Oem mouse driver disk 1",\oemmou01.tag,\
 
[Defaults]
mouse = m2
 
[mouse]
m1 = "Oem mouse type 1"
m2 = "Oem mouse type 2"
 
[Files.mouse.m1]
port = d1,m1.sys,oemmou1
 
[Files.mouse.m2]
port = d1,m2.sys,oemmoup
#replace the mouse class driver
class = d1,oemmoucl.sys,oemmouc
 
[Config.oemmou1]
value = parameters,xres,REG_DWORD,10
value = parameters,yres,REG_DWORD,20
value = parameters,description,REG_SZ,"Mouse type 1"
 
[Config.oemmoup]
value = parameters,xres,REG_DWORD,10
value = parameters,yres,REG_DWORD,20
value = parameters,description,REG_SZ,"Mouse type 2"
 
[Config.oemmouc]
value = parameters,description,REG_SZ,"Mouse class"
 

A single distribution disk with a single txtsetup.oem file can be used to support multiple hardware devices. To do this, the txtsetup.oem file would contain a single [Defaults] section with an entry specifying the default choice for each hardware type. The file would also contain a [Component] entry for each hardware type and the appropriate associated [Files.Component.ID] and [Config.DriverKey] entries.