Inside Multimedia 1995 August/IMM0895.ISO01.iso/driver/mitsumi/mscdex.txt

Text File | 1992-06-02 | 105KB | 2,265 lines

Installation Guide
for MS-DOS CD-ROM Extensions

Information in this document is subject to change without notice and does
not represent a commitment on the part of Microsoft Corporation.  The
software described in this document is furnished under a license agreement
or nondisclosure agreement.  The software may be used or copied only in
accordance with the terms of the agreement.  It is against the law to copy the
Installation Guide for MS-DOS CD-ROM Extensions on magnetic tape, disk
or any other medium for any purpose other than the purchaser's personal
use.

Copyright Microsoft Corporation, 1986-1990

Microsoft, the Microsoft logo and MS-DOS  are registered trademarks of
Microsoft Corporation.

IBM  is a registered trademark of International Business Machines
Corporation.


Contents


Introduction        4

Setting Up Your CD-ROM Drive    5

  What You Need        5
  Using the CD-ROM SETUP Program    5
  Restarting Your Computer After Running SETUP    6

Using Your CD-ROM Drive    7

What SETUP Does        7

  The CONFIG.SYS File    7
  The AUTOEXEC.BAT File    8
  Device Driver Names        8
  Command Line Switches    8

Questions and Answers    10


Installation Guide
for MS-DOS CD-ROM Extensions

________________________________________________
INTRODUCTION

This guide provides instructions for installing the operating software for your
CD-ROM drive on a computer that uses the MS-DOS operating system.

Compact Disc Read-only Memory (CD-ROM) represents a technology in the
storage and retrieval of information for personal computers.  A CD-ROM
drive provides a storage capacity of more than 1,500 floppy disks, more than
the contents of 100 textbooks - on a single CD-ROM disc.

Installing your CD-ROM drive is a simple procedure.  The SETUP disk
provided with your CD-ROM drive includes a program that leads you
through all the steps required to install your drive and configure it for use
with your system.

Once installed, your CD-ROM drive can be read like any other magnetic disk
drive.  You can use it immediately, without learning anything new; your
existing MS-DOS applications can access CD-ROM files directly.

_______________________________________________
SETTING UP YOUR CD-ROM DRIVE

What You Need

To install your CD-ROM drive for use with MS-DOS, you need:

-  An IBM personal computer or compatible with a minimum of 256K
memory.
-  A CD-ROM drive and controller card.
-  The MS-DOS CD-ROM Extensions disk provided with your CD-ROM drive.
-  MS-DOS, version 3.1 or higher.


If you are using a floppy disk system, you will also need:

- A blank, formatted floppy disk.
- A disk that includes MS-DOS, version 3.1 or higher.

Note:  The MS-DOS CD-ROM Extensions enable your drive to read compact
discs that use the High Sierra or  IS0 9660 format.

Using the CD-ROM SETUP Program

The SETUP program gives you step-by-step guidance for preparing your
computer system for use with a CD-ROM drive.  To begin using the SETUP
program, refer to the procedure below that applies to the type of system you
are using (hard-disk or two- or one-drive system).

If You have a Hard-Disk System

If you are using your CD-ROM drive with a hard-disk system, follow these
steps:

[1]  Insert the MS-DOS CD-ROM Extensions disk into drive A.
[2]  Type a: , Press ENTER
       Type Setup
[3]  Press ENTER
[4]  Follow the instructions that appear on your screen.


If you have a Two- or One-drive System

To install and use the SETUP program, you will need your MS-DOS system
disk (the disk you use to start your computer).  Before running the SETUP
program, you must make a new copy of your MS-DOS system disk and copy
necessary SETUP program files onto that disk.  This new disk should then be
used each time you start your computer for use with your CD-ROM drive.

To copy your MS-DOS system disk and install the SETUP files:

[1]  Insert your MS-DOS disk into drive A and start your computer.
[2]  When A> appears on your screen, type diskcopy.
[3]  Press ENTER.
[4]  Follow the instructions displayed on your screen.
       Insert your MS-DOS system disk when prompted for the source disk;
       insert the blank, formatted disk when prompted for the target disk.
[5]  When copying is complete, you will see the message "Copy Complete,
Copy
       Another? (Y/N)."  Press N and then press ENTER.
[6]  Remove the MS-DOS system disk from drive A and insert the MS-DOS
CD-ROM
      Extensions disk.
[7]  At A>, type setup
[8]  Press ENTER.
       Follow the instructions displayed on your screen.  If you have a one-drive
system,
       insert the newly copied disk in drive A when prompted to insert the disk
for drive B.


Note:  Label the newly copied CD-ROM start disk "MS-DOS with CD-ROM."
This is the disk you should now use to start your computer for use with your
CD-ROM drive.


Restarting Your Computer After Running SETUP

When you have completed the SETUP procedure listed above that applies to
the type of system you are  using, you need to restart your computer to
reconfigure your system based on the information you just added to your
AUTOEXEC.BAT and CONFIG.SYS files.

To restart your computer:

-  Press Ctrl-Alt-Del.

________________________________________________
USING YOUR CD-ROM DRIVE

After you have run the SETUP program, which modifies your
AUTOEXEC.BAT and CONFIG.SYS files to recognize the presence of your
CD-ROM drive, you are ready to use your computer with your CD-ROM
drive.

To use your CD-ROM drive with a hard-disk system:

-  Turn on your computer.
    Your hard-disk system will recognize the presence of your CD-ROM drive.

To use your CD-ROM drive with a floppy-disk system:

-  Insert the CD-ROM start disk (labeled "MS-DOS with CD-ROM") and start
your
   computer.

For technical information on how the SETUP program modified your system
to recognize the CD-ROM drive, see the following section, "What SETUP
Does."

________________________________________________
WHAT SETUP DOES

This section of Installation Guide for MS-DOS CD-ROM Extensions provides
technical information about the SETUP program.  You do not need to read
this section before installing and using your CD-ROM drive.

The SETUP program helps you adjust your system for use with a CD-ROM
drive and MS-DOS.  By responding to questions and messages displayed by
the SETUP program, you automatically modify your system's CONFIG.SYS
and AUTOEXEC.BAT files to recognize the presence of your CD-ROM drive.
The SETUP program also copies certain required files to the disk or directory
you use to start your computer.

The CONFIG.SYS file

First the SETUP program searches the root directory of the drive selected for
installation of MS-DOS CD-ROM Extensions for the presence of a
CONFIG.SYS file.  If the CONFIG.SYS file is not found, the SETUP program
automatically creates the file.

The SETUP program makes the following changes to your CONFIG.SYS file:

- Changes or adds the line for "last drive=" to read "last drive=z".
- Adds a line to the CONFIG.SYS file to load the device driver for the CD-
ROM
   drive.

The SETUP program modifies your CONFIG.SYS file to ensure your system
can add additional drives.  By adding the line "lastdrive=z", the SETUP
program tells your operating system that you may have up to 26 different
drives, each designated by an individual letter from a to z.  If your
CONFIG.SYS file has already identified the last drive, the SETUP program
increases this to allow for the presence of additional drives.

The AUTOEXEC.BAT File

The SETUP program searches the root directory of the drive selected for
installation of the MS-DOS CD-ROM Extensions for the AUTOEXEC.BAT
file.  If the SETUP program cannot find this file, it automatically creates the
file.

Next, the SETUP program adds a line to the AUTOEXEC.BAT file that tells
MS-DOS to invoke the MSCDEX.EXE program, with its correct parameters,
when you start your system.  The SETUP program also copies the
MSCDEX.EXE program and the CDROM.SYS device driver to the disk or
directory you use to start your computer.

Device Driver Names

Every device driver used by your system must have a unique name.  Due to
the way MS-DOS opens files, if there is a device driver with the same name
as a file in your current directory, MS-DOS will attempt to open the current
device driver, not the file.  For this reason, device driver names should not be
used as file names.

The SETUP program assigns unique names to the device drivers it uses.  For
example, it uses a name such as MSCD005 as a device driver name.


Command Line Switches

The SETUP program uses the following command line switches for line:

Switch                         Use_________________________________
Example____

/D:(device name)    Precedes the device driver name.  When com-
/D:MSCD001
            bined with the device driver name, this switch
    tells MSCDEX.EXE where to find the device
    driver.

/E    Tells MSCDEX.EXE to use expanded memory
     if your system is using expanded memory.
Switch                          Use
    Example

/L:(drive letter)    Determines what drive letter MSCDEX.EXE         /L:M
    uses as the first letter when assigning CD-
    ROM drive letters.  Instead of starting at the
    first free drive letter, MSCDEX.EXE starts at
     the drive letter specified by this switch.

/K    Tells MSCDEX.EXE to use any Kanji
    (Japanese) file structures, if present, rather than
    the default of standard alphanumeric file
    structures.

/S    Instructs MSCDEX.EXE to patch DOS to allow
    sharing of CD-ROM drives on MS-NET based
    network servers.

/M:(value)    Tells MSCDEX.EXE how much memory to           /M:10
    allocate for caching information on the CD-
    ROM.  The higher this value is, the better your
    performance will be, though you will have less
    room on the CD-ROM for other applications.
    The SETUP program uses a default value of 4
    to reserve 8 kilobytes for sector caching for a
    single drive.

/V    Provides memory usage statistics, such as how
    much memory is used by buffers, resident data,
    resident code.



The syntax for the "DEVICE=" line is follows:

     DEVICE=(drive.sys)/D:(device_name)(driver-specific switches)

A sample entry in AUTOEXEC.BAT to install MSCDEX.EXE would be:

     C:MSCDEX.EXE/D:MSCD000/D:MSCD001/M:60
________________________________________________
QUESTIONS AND ANSWERS

Here are answers to some questions that may arise as you use the SETUP
program to install your CD-ROM drive, or as you use your CD-ROM drive
with MS-DOS:

[1] Is there anything special I need to do to install my CD-ROM drive
for use with a network?

You should check your AUTOEXEC.BAT file to be sure that, upon
system startup, the network is installed before your CD-ROM drive
is installed.  Within your AUTOEXEC.BAT file, the line that
applies to the network must precede the line that applies to the CD-
ROM drive.

[2] Can I use my CD-ROM drive with any application or file that I
normally use with MS-DOS?

Applications that depend on MS-DOS standard interfaces are
compatible.  These applications can read files on your CD-ROM disc
just as they would on any floppy disk.  However, they cannot write
information to the CD-ROM drive.

[3] Does my computer always know that I am using a CD-ROM drive,
or do I need to run a special program each time I start my computer?

You do not need to run a special program each time you start your
computer.  When you install your CD-ROM drive and run the
SETUP program, your AUTOEXEC.BAT file is updated to reflect
the presence of the CD-ROM drive.  Your computer uses the
information in the AUTOEXEC.BAT file every time you turn on
your system or restart it.

[4] Are there any differences between the way I use my CD-ROM drive
and  the way I use any other disk drive with my computer?

The only difference to you as a user is that your CD-ROM drive is
read-only, which means you cannot write information to the CD-
ROM disc.  The CD-ROM disc acts like a write-protected floppy
disk.

[5] If I start a "shell" program like Windows or DOS SHELL, where
should the MSCDEX entry go in AUTOEXEC.BAT?

The entry should be before the entries that run other BAT files or start shell
programs, so that MSCDEX has a chance to create the CD-ROM drives before
the BAT files or "shell" programs are run.


Microsoft MS-DOS CD-ROM Extensions
CD-ROMifying Your Software
29 March 1989


CD-ROM is the first of what will probably be several alien file structures that
will start appearing in the MS-DOS world primarily with the introduction of
installable file systems under newer versions of DOS. The following will
attempt to outline some guidelines for writing software that will help in
porting your software to these new file systems and for CD-ROM specifically.

- Choice of filename characters

On the first Microsoft Test CD-ROM disc, the Codeview demo failed
because certain filename characters that were legal on MS-DOS were not
allowed according to the High Sierra file format. When the software
looked for file 'S1.@@@', it wasn't found because the character '@' is illegal
for High Sierra filenames and during High Sierra premastering, the file
was renamed 'S1'.

Valid High Sierra filename characters are the letters 'A' through 'Z',
the digits '0' through '9', and the underscore character '_'. All other
characters are invalid. Note that the letters 'a' through 'z' are not
included so that High Sierra file names are not case sensitive. Under
DOS, filenames are mapped to upper case before they are looked up so
this is typically not a problem. When choosing file name characters, keep
in mind the restrictions of the file structure format and the operating
systems your media may be targeted towards.

- Depth of path

The High Sierra format allows for pathnames to be up to 8 levels
deep. It's possible to create a path on MS-DOS that is deeper than that
but you won't be able to transfer it to a CD-ROM.

\one\two\three\four\five\six\seven\eight\file.txt    /* Ok
    */
\one\two\three\four\five\six\seven\eight\nine\file.txt    /*
Illegal    */

- Length of path

The High Sierra format allows for the entire pathname to be a
maximum of 255 characters. Since MS-DOS imposes a limit far lower
than this, this should not present a problem. The MS-DOS call to connect
to a sub-directory is limited to a directory string of 64 characters. The
length of path restriction is more a concern for Xenix/Unix than MS-DOS.

Amusingly enough, for MS-DOS versions 2.X and 3.X, the MS-DOS
call to create a sub-directory allows a directory string greater than 64
characters which allows you to create sub-directories that you cannot
connect to.

Unfortunately, a CD-ROM may potentially contain a pathname
that is much larger than 64 characters long. This is not a concern here
but is discussed in a related memo - "MS-DOSifying your CD-ROM". As a
rule, try to keep the length of your longest path less than 64 characters
and you should be pretty safe.

- Read-only

Even though most people understand that CD-ROM discs are read-
only, there's still a lot of software written by these same people that
assumes the current disk is always writable. For example, the Microsoft
Multiplan Demo assumes that it can create and write temporary files to
the presently connected drive.

In order to avoid this problem, try to provide another means of
letting the user specify where temporary files can be created. Many
applications check the environment for the variables TMP or TEMP
which contain the pathname to use when creating temp files. Most people
understand this convention now (or should anyway) and an added benefit
will be the speed improvement that will be recognized if the temp
directory is located on a ram-drive. If the environment variable is not set,
then the application can fall back on the assumption that the media is
writable or ask where temporary files should be kept.

As a rule, for both temporary and permanent files, if a file creation
error occurs, allow the user to re-specify the pathname used so that he
can work around the error. The last thing that should happen is for work
to be lost because the user was not allowed to store his output in a valid
place.

- Non-DOS formatted disks

Don't depend on the format of data on the disk. CD-ROM's do not
have a FAT so don't even bother looking for one. Do not talk to any media
at a physical level (reading/writing sectors) unless you expect to be media
dependent (such as CHKDSK or FORMAT). MS-DOS INT 21h calls
should provide everything you need to get at the file contents and
attributes.

- Small directories

For performance reasons, try to keep directory sizes smaller than
about 40 or so. Much beyond this and directory files grow beyond one
2048 byte sector. Typically this is not a problem, but if the number of
sector buffers chosen when MSCDEX is started is small and the directory
files are large, whatever software scanning the directory could potentially
thrash badly if every time the directory is searched for the next entry it
has to bring earlier directory sectors back into memory from the CD-ROM
drive.

For certain pathological programs, such as certain implementations
of the Xenix utility find, the penalty is about 1 second per directory sector
that you have to scan to get to the next entry. If the directory is large, say
8 sectors, the time for FIND to scan that one directory could potentially
take a half hour for something that would take less than a second if all
the entries fit in the cache.

The solution for this problem is to make sure that MSCDEX never
throws out of the cache what it will need next. This is accomplished by
growing the cache (very easy - simply change the parameter to MSCDEX)
and to make sure that the largest object that goes through the cache will
not clear it out. There is a balance between having too many directories
and too many files in a few directories, but the balance is heavily
weighted towards many small to medium sized directories. Keep this in
mind when laying out your files.

Since the penalty for using a file in the lowest sub-directory instead
of the root-directory is virtually nil and as more directories don't cost
much, it's a good idea to break up large directories into several smaller
ones. This will help avoid problems of flushing the disc sector cache. Try
to keep related files close together both in location on the CD-ROM and
in the same directories. Close proximity will reduce seek time when
accessing related files at the same time and having them in the same
directory will help prevent swapping out directory sectors.

- Updating CD-ROM databases and software

Many people are interested in providing updates to files that are
contained on a CD-ROM disc. They would like to create a directory on
their hard disk will all updated files in them and have the CD-ROM
Extensions look there first before searching the CD-ROM. Unfortunately,
by the time the Extensions get the request, it is very difficult for it to look
for updates on the hard disk so whatever alternative searching that is
necessary will have to be done in the application software.

For this reason, it's a good idea to have your path set so that it looks
through directories on the hard disk first. Another good strategy is to
copy executables to a directory on your hard disk so that they can be
updated and will also start up faster. Also, have the application software
itself search alternative hard disk directories for updates before it
searches the CD-ROM. This way both software updates and updated or
commonly used database files can be stored on a hard disk which will
both speed performance and allow incremental updating.

- Search Strategies

Try to avoid relying on the operating system to be part of your
search strategy. If your database is broken up into a hierarchy and your
order is imposed through the file structure by breaking up the database
into many files in a tree, then accessing data in the database is typically
going to require a lot of directory reading and searching.

Usually the time involved in doing this on a hard disk is not large,
but on a CD-ROM the search times can add up. Opening a file can be an
expensive operation simply because the directory must be read before the
file can be opened. At best, seeking to a location on the CD-ROM can take
10 msec or so; at worst, a seek can run to over a second on some older CD-
ROM drives. Some newer drives have worst case seek of about half a
second. Whenever this can be avoided you will save time. MSCDEX
caches as many directory sectors as it can so that searching the most
active directories is very quick, but any operations that search multiple
directories once through continually clears out the cache and renders it
ineffective.

The strategy used by Microsoft Bookshelf was to lump the entire
database into a single file and structure the indexing so that searching
used a minimum of seeks. Bookshelf uses packed b-trees with each node
holding as many entries as will fit into a single sector and also cache in
memory as much of the root of the tree as it can.

Combining databases avoids the extra overhead of repeatedly
opening and closing database files. Caching as much of the indexes in
memory as possible  allows searching of keywords to be completed
typically with a single seek.

In general, identify your software bottlenecks and through judicious
use of faster storage media (either memory or hard disk) you can both
have large storage and respectable performance.


- Portability

One of the advantages of the High Sierra format is data interchangeability
with other operating systems. One must take care to chose a subset of the
range of High Sierra features that are presently supported across different
operating systems to be sure you can read the disc in each of them. The
lowest common denominator then (this list is not complete - see also what
must be done to target MS-DOS) would need a logical block size of 512 bytes,
both type L and M path tables and for all fields, single volume sets, at least
one Primary Volume Descriptor and terminator. Be aware that if one of your
goals is data portability, you will have to do some additional research to see
what restrictions on the High Sierra format other operating systems may
impose.


Microsoft MS-DOS CD-ROM Extensions
MS-DOSifying your CD-ROM
23 March, 1990

Most of the following caveats apply to the present version of the
Microsoft CD-ROM Extensions. Future versions of the extensions are
expected to support many of the features listed below that are at present
best avoided. The behavior of the extensions with fields and records that
are presently ignored may change at any time.

- Correctness

Make sure that your disc is in valid High Sierra format. Nothing is
guaranteed if your disc is not in valid format. Surprisingly enough, we
have received several discs that have one or more illegally formatted data
areas ranging from directories being sorted incorrectly, incorrect path
table sizes, incorrect directory file sizes,  directories missing from the
path table, invalid directory names, etc. In almost every case, the
Extensions will behave incorrectly and at worst, the system will crash.
In addition to running validation software to verify the High Sierra
image, one should also verify that the Extensions work with your cdrom
disc and application software before distributing it. Unfortunately, it may
not matter if your disc is correct and the Extensions are wrong if they
don't work together. Please report any and all problems you think are in
the Extensions to Microsoft so that they can be fixed.

- Pathtable and Directory sizes

This bears repeating because many people have gotten it wrong.
Directory file sizes are always a multiple of the logical sector size - 2
kilobytes. Path table sizes are always the exact number of bytes that are
contained in the path table which is typically not a multiple of 2k. You
must not have blank directory sectors and the directory length must
reflect the correct length of the directory file. The directory sectors always
begin on a logical sector boundary.

- 8.3 File names

MS-DOS cannot handle longer than 8.3 filenames. If the CD-ROM
filename is longer than 8.3, then the filename will be truncated. If this
happens, two files that are not unique within 8.3 characters will map to
the same filename. For example:

filename1.txt    will appear as filename.txt
filename2.txt    will also appear as filename.txt

Kanji filenames are also limited to 8.3 or 4.1 kanji characters. Only
shift-kanji filenames are recognized at present. To get kanji, you must
specify a supplementary volume descriptor indicating you have kanji
filenames. Contact Microsoft to find out how this is done.

- Record Formats

The extensions do not support any record formats so if the RECORD
bit is set in the file flags byte in the directory entry for a file, it will be
ignored.

- Interleaving

In the present version, the Extensions do not support interleaving
so if the Interleave size and Interleave factor are non-zero, the file will
ignore these fields and return erroneous data.

- Multi-Extent Files

Multi-extent files are not supported in the present version. Each
extent of a multi-extent file will appear as a separate file with the same
name.

- Multi-volume

Multi-volume disc sets are not supported in the present version.
Directories that are located on another volume could potentially cause
the Extensions to crash if searched and erroneous data will be returned
for files that are located on another volume.

- Coded Character Sets

Only one coded character set or supplementary volume descriptor is
recognized in the latest version. This is for shift-Kanji.

- Version numbers

Version numbers are not supported by the Extensions. The
Extensions will strip the version string off the end of the filename so that
two identical filenames with different versions will appear to have the
same name. There is no way to specifically ask for any but the first
instance of that filename. Two files with the same name and different
version numbers have the same accessing problem as two files with
longer than 8.3 filenames that have been truncated to the same filename.

- Protection

Protection bits are not used on MS-DOS. If the protection bit is set
in the file flags byte in the directory entry for a file , it is ignored and
normal access is allowed.

- No XAR support

At present, the Extensions ignore the contents of any XAR record.

- Motorola format tables

The additional copies of the path table and any values in "Motorola"
format (most significant bytes using the lowest address values) are
ignored at present. MSCDEX only pays attention to "Intel" formatted
values. They should be included though for portability sake.

- Multiple copies of the path table

The Extensions presently only read and use the first copy of the
path table. Later versions may check to see that copies of the path table
agree.

- Additional Volume Descriptor Records

Boot records and Unspecified volume descriptors are ignored. The
first standard volume descriptor found is the one that is used. Additional
copies are ignored at present.

- File flags

The existence bit is treated the same as the hidden bit on MS-DOS.
Some other operating systems may not handle the existence bit so you
may not want to use it if you are targeting these systems. The directory
bit for High Sierra is treated the same as the directory bit in MS-DOS.
Files with the protection bit set are not found when searched for or
opened.
None of the remaining bits, (Associated/Record/Multi-
extent/Reserved), are handled at present. Using files with these bits set
will have undefined behavior.

- Unique Volume Identifiers

It is highly recommended that the volume identifier be unique. The
Extensions use the volume identifier to do volume tracking and to
double-check to see if the disc has changed. The more chance that users
will have two discs with the same volume identifier, the more chance that
this will confuse the Extensions and lead it to believe that the disc has
not changed when in fact it has.
It is also highly recommended that application programs use the
volume label to tell if the cdrom disc has changed. The volume label for a
CDROM on MS-DOS is obtained from the volume identifier field in the
primary volume descriptor. The call to get the volume label is very
inexpensive to make once the CDROM has been initialized and will cause
no disc I/O to be done unless the media has changed. This is the best way
for an application to tell if the disc it wants to work with is in the drive.
The application software should not communicate with the driver or drive
to determine if the media has changed or the Extensions may not learn
that the disc has changed and will not reinitialize what it knows about
the new disc.

- Many Small Directories or A Few Large Directories

   As a rule, it is better to have many small directories that contain
fewer files than one very large directory. The answer depends on your
application's behavior because if you try very hard, you can thrash
almost as badly with many small subdirectories as you can with one large
subdirectory. Reading further will help explain.

   What makes the difference? For each file open, suppose you have
1000 subdirectories with 40 files, on average you'll read about one sector
per file open and scan 1/2 of it. On the other hand, you could have 1
directory with 4000 files. On average, each file open in this large
directory (about 100 sectors) will involve scanning about 50 sectors to
open that one file. As long as it is very inexpensive to get to each
directory through the pathtable, clearly it is much better to have many
small directories.

   Further improvements can be made by grouping files that are
related and will be opened together in each of these subdirectories so that
as you open each successive file, the directory sector is very likely in the
disc cache and this will help minimize hitting the CD-ROM disc.   Putting
each file in a separate subdirectory is extreme and will cost you because
you will never gain the benefits of locating the next file in a directory
sector that has already been cached and you will needlessly enlarge the
pathtable.

   There is a limit though to how many subdirectories you may want
because if there are too many you may end up thrashing on the pathtable
sectors. Each pathtable sector holds pointers to approximately 100 to 200
directory files depending on the directory name lengths. If you have a
pathtable that is 10 sectors long, you will want at least 10 sectors of
memory buffers to hold the pathtable or you may risk re-reading sections
of the pathtable on every file open which will be very costly.

   The most important point you can learn is that you can vastly
improve your file open speed by making sure you have enough memory
buffers. If you are repeatedly trying to scan a 10 sector directory file
(approximately 400 entries) and you only have 4 sectors in the sector
cache, the cache is going to work against you because you will end up
churning it to death. If you allocate 14 sectors for example (/M:14), then
the whole directory file will find its way into the cache and you will stop
hitting the disc. The difference in speed may be several orders of
magnitude. A safe bet is to recommend reserving as many sectors are in
the pathtable plus the number of sectors for the largest directory plus 2.
The last two are reserved for data sectors and internal dynamic data.
This formula is complicated with multiple drives because the buffers are
not tied to specific drives and are shared and because not all drives are
active at the same time.

   Another rule, do not rely on the file system to do your searching for
you. If you are performance conscious, finding a chunk of data by looking
for it with a file name through the file system is expensive. 99% of the
time, locating data through the file system is fine because the cost is a
single one-time operation, but if this is repeated often enough, it may pay
to do some of the work yourself. What can be better is lump everything
into one big file and cache your own hierarchy, indexing, binary trees, or
whatever searching scheme you choose to use to get you to the data you
need rather than asking for the file system to tell you where it is.


Microsoft MS-DOS CD-ROM Extensions
Kanji Support
17 March 1989

The Kanji support in MSCDEX presently recognizes High Sierra CD-
ROM discs with a coded character set that has bit 0 set to 1 in the volume
flags indicating at least one escape sequence is not registered according to
ISO 2375, and has an escape sequence of three bytes in the coded character
set for descriptor identifiers field of "$+:". This indicates that the character
set is a private multi-byte G3 coded character set and identifies the disc as
having shift-Kanji.

In order to make MSCDEX scan for the SVD (Supplementary Volume
Descriptor) instead of the PVD (Primary Volume Descriptor), there is a new
command line argument /K. If this is present, MSCDEX will use the shift-
Kanji SVD if it is present, otherwise it will use the PVD. All discs are
required by ISO-9660 to have a PVD even if there is an SVD.


In addition, there is an accompanying program SVD that can be used to
change the default preference each CD-ROM drive has for scanning for a
SVD or PVD. The syntax is:

SVD [<drive letter>: <std | svd>]

Running SVD with no arguments will report the current settings. Including a
drive letter and either STD or SVD will change the preference for that drive
from one to the other.


Microsoft MS-DOS CD-ROM Extensions
Networking CD-ROMS
29 March 1989


Although it is possible to share CD-ROM drives on a local area network
or LAN, it is not as easy as it should be. While MS-DOS provides a single,
stable platform to develop a file system driver like the Microsoft CD-ROM
Extensions, there are a wide variety of LANs and LAN server
implementations that do not provide a stable platform for which a file system
driver like MSCDEX could be provided. Because each LAN implementation
takes a different approach for server support, the approach for CD-ROM
support on a server depends on what LAN implementation is being used.

This document should help clarify the present situation and help get you
started.

At present, there are several CD-ROM products that allow sharing of CD-
ROM drives on a LAN. These are:

    Microsoft    MSCDEX - The Microsoft CD-ROM Extensions
    Meridian Data    CD-NET
    Online        Opti-Net

Choosing which product depends on your LAN and your needs.

There are some LANs, such as Lantastic by Artisoft, that can share CD-
ROM drives using any version of MSCDEX on a Lantastic server. This is
possible because their servers run as an MS-DOS application and do I/O with
standard MS-DOS INT 21 services. LAN servers like this, that do not make
assumptions about the underlying media or try to bypass MS-DOS and do
use standard MS-DOS INT 21 services to access the drive letter, will likely
work with all versions of MSCDEX.

There are several LAN products based on MS-NET or a similar LAN
server model such as Ungermann-Bass or 3COM. Unfortunately, these
products do not access files on the server using standard INT 21 calls and for
several reasons due to assumptions inside MS-DOS about non-standard calls
from the server, you cannot share CD-ROM drives on MS-NET based servers.
Although the server seems to allow sharing of the CD-ROM drive letter,
requests to the server from workstations do not work correctly.

Fortunately, MSCDEX Version 2.10 has a command line switch (/S) that
instructs MSCDEX to patch the in-memory image of MS-DOS during its
initialization to fix these problems. By including this parameter on the
MSCDEX command line, MSCDEX can be loaded before the network server
software is started, and the CD-ROM drive letters can then be shared by MS-
NET based server software, and workstations will see the correct behavior.
This solution requires only that the server use MSCDEX Version 2.10 and no
software or hardware changes to the workstation. Only the server runs
MSCDEX or loads any CD-ROM related device drivers. To the workstation,
the CD-ROM server drives are indistinguishable from other server drives.

For LAN products that are not MS-NET based yet have NETBIOS
support such as Novell or IBM PC-NET, both Online and Meridian Data
have adapted the MSCDEX and CD-ROM Device Driver model to provide
LAN CD-ROM support. Each workstation runs MSCDEX and a special CD-
ROM device driver that accepts normal CD-ROM driver requests from
MSCDEX and uses the NETBIOS to transmit the command to a network
driver on a server. The network driver submits the request to a true CD-
ROM device driver on the server and transmits the results back to the
workstation pseudo CD-ROM driver. The psuedo driver in turn responds to
MSCDEX. So long as the workstation CD-ROM device driver responds
appropriately, MSCDEX is unaware that the command has passed through
the network to a server. Contact Meridian Data and Online for information
for these networks as they can both describe their products and features best.

Online offers one potential configuration for computer systems that do
not wish to dedicate a machine to be a server. The workstation operates as
above, but instead of communicating the workstations driver request to a
dedicated server process, another user's workstation running a special TSR
version of their system can field the driver request, submit it to the CD-ROM
driver, and respond to the requesting workstation. This allows a network of
workstations to share the CD-ROM drives that each computer has connected
to it at the same time all workstations are available to the users. This option
may work for many users although it does slow performance of the
workstation when outside requests come in and uses up memory for the TSR
system code.

At present, there is no available version of the CD-ROM Extensions for
OS/2 although there is a way to access CD-ROM data in OS/2 on a network.
Since from the outside, workstations cannot tell MS-DOS server drives that
are shared CD-ROM drives using version 2.10 of MSCDEX from traditional
block drives, even OS/2 machines can access the CD-ROM drive on the
server. Although this does mean including an MS-DOS server on an OS/2
LAN, it does provide at least an interim way to access CD-ROM data under
OS/2 at this time.

For more information on CD-ROM LAN products for LANs other than
MS-NET, contact:

Online Computer Systems
Mr. Mike Romanies
20251 Century Blvd
Germantown, MD 20874
301.428.3700

Meridian Data Inc.
Mr. Greg Smith
4450 Capitola Road Suite 101
Capitola CA 95010
408.476.5858
408.476.8908 (Fax)


Microsoft MS-DOS CD-ROM Extensions
Function Requests Specification
29 March 1989

There is a need for access to features from the MSCDEX redirector that
transend DOS capabilities. This proposal documents a means the application
can use to talk directly to MSCDEX to request information or set parameters
that only MSCDEX can provide. This document outlines the services
MSCDEX provides at present. Comments and suggestions are welcome.

Access to these functions is provided through an INT 2Fh interface. AH
contains 15h which is what MSCDEX will use to tell its requests from those
of other INT 2Fh handlers. AL will contain the code of the function to be
performed.

Function Request Command Codes:

    Contents of AL        Function

    00h            Get Number of CD-ROM drive letters
    01h            Get CD-ROM drive device list
    02h            Get copyright file name
    03h            Get abstract file name
    04h            Get bibliographic doc file name
    05h            Read VTOC
    06h            Turn debugging on
    07h            Turn debugging off
    08h            Absolute Disk Read
    09h            Absolute Disk Write
    0Ah            Reserved
    0Bh*            CD-ROM Drive Check
    0Ch*            MSCDEX Version
    0Dh*            Get CD-ROM drive letters
    0Eh*            Get/Set Volume Descriptor Preference
    0Fh*            Get Directory Entry
    10h**            Send Device Request
    11h-0FFh        Reserved

* - New functions added in version 2.00
** - New functions added in version 2.10

- Get Number of CD-ROM drive letters
________________

    AX    1500h
    BX    Number of CD-ROM drive letters used
    CX    Starting drive letter of CD-ROM drive letters (A=0, B=1, ...
Z=25)
________________

MSCDEX will return the number of CD-ROM drive letters in BX and
the starting drive letter in CX. The first CD-ROM device will be
installed at the starting drive letter and subsequent drives will be
assigned the next greater drive letter. A single device driver may be
assigned to more than one drive letter, such as the case of a device
driver that supports multiple units. MSCDEX keeps track of which
sub-unit a particular drive letter is assigned to.

NOTE: This function can be used to determine if MSCDEX is installed
by setting BX to zero before executing INT 2Fh. MSCDEX is not
installed if BX is still zero on return.
Also, in a networking environment, one cannot assume that drive
letters will always be assigned contiguously beginning with the
starting drive letter. Use function Get CD-ROM drive letters instead.

- Get CD-ROM drive device list
________________

    AX    1501h
    ES:BX    Transfer address; pointer to buffer to copy drive letter
device list
________________

The buffer must be large enough to hold the device list. By calling
function Get Number of CD-ROM Drive Letters, one can find out the
number of CD-ROM drive letters and the buffer size will be a multiple
of that. This will be an absolute maximum of 26. Each drive letter
device entry will consist of one byte for the sub-unit followed by 4 bytes
for the address of the device header assigned to that drive letter. This
byte for the sub-unit takes care of the problem of distinguishing which
unit is assigned to which drive letter for device drivers that handle
sub-units.

For example: Suppose there are two installed CD-ROM device drivers,
FOO, which supports 1 sub-unit, and BAR, which supports two sub-
units, on a system with 2 floppy drives (A=0 and B=1) and a hard disk
(C=2). Then asking for the number of CD-ROM drive letters will report
that there are 3 drive letters used starting at drive letter D=3. ES:BX
must point to a buffer that is at least 3*5 = 15 bytes long. The buffer
will be filled as follows:

ES:BX    = Buffer

Buffer    DB    0                ; sub-unit of FOO on drive letter
D:
    DD    <far addr of FOO device header>
    DB    0                ; sub-unit of BAR on drive letter
E:        DD    <far addr of BAR device header>
    DB    1                ; sub-unit of BAR on drive letter
F:
    DD    <far addr of BAR device header>


- Get copyright file name
________________

    AX    1502h
    ES:BX    Transfer address; pointer to a 38 byte buffer
    CX    CD-ROM drive letter (A=0, B=1, ... Z=25)
________________

MSCDEX will copy the name of the copyright file in the VTOC for that
drive letter into the buffer space provided. The copyright filename is
presently restricted in the High Sierra proposal to 8.3 but we require
38 bytes here for the possibility at a later date of handling 31
character file names plus 6 bytes for a ';' and 5 digit version number
and 1 byte for a NULL at the end. Carry will be set if the drive letter is
not a CD-ROM drive and error_invalid_drive (15) will be returned in
AX.

- Get abstract file name
________________

    AX    1503h
    ES:BX    Transfer address; pointer to a 38 byte buffer
    CX    CD-ROM drive letter (A=0, B=1, ... Z=25)
________________

MSCDEX will copy the name of the abstract file in the VTOC for that
drive letter into the buffer space provided. The abstract filename is
presently restricted in the High Sierra proposal to 8.3 but we require
38 bytes here for the possibility at a later date of handling 31
character file names plus 6 bytes for a ';' and 5 digit version number
and 1 byte for a NULL at the end. Carry will be set if the drive letter is
not a CD-ROM drive and error_invalid_drive (15) will be returned in
AX.


- Get bibliographic documentation file name
________________

    AX    1504h
    ES:BX    Transfer address; pointer to a 38 byte buffer
    CX    CD-ROM drive letter (A=0, B=1, ... Z=25)
________________

NOTE: This function is provided in advance of the ISO standard. For
discs complying with the May 28th draft from the High Sierra Group,
this function will return a null string as though the field is blank on
the disc.

MSCDEX will copy the name of the bibliographic documentation file in
the VTOC for that drive letter into the buffer space provided. The
bibliographic documentation filename is presently restricted in the
High Sierra proposal to 8.3 but we require 38 bytes here for the
possibility at a later date of handling 31 character file names plus 6
bytes for a ';' and 5 digit version number and 1 byte for a NULL at the
end. Carry will be set if the drive letter is not a CD-ROM drive and
error_invalid_drive (15) will be returned in AX.


- Read VTOC
________________

    AX    1505h
    ES:BX    Transfer address; pointer to a 2048 byte buffer
    CX    CD-ROM Drive letter
    DX    Sector index
________________

This function is provided to scan the Volume Descriptors on a disc. A
sector index of 0 will read the first volume descriptor, 1 reads the
second, etc. If there is no error, then AX will return 1 if the volume
descriptor read was the standard volume descriptor, 0FFh if it was the
volume descriptor terminator and there are no more volume
descriptors to be read, and 0 for all other types.

If there is an error in processing the request, the Carry Flag will be set
and AL will contain the MS-DOS error code. These will be either
error_invalid_drive (15) or error_not_ready (21).

- Turn debugging on
________________

    AX    1506h
    BX    Debugging function to enable
________________

This is used for development and is reserved. It will be non-functional
in the production version of MSCDEX.

- Turn debugging off
________________

    AX    1507h
    BX    Debugging function to disable
________________

This is used for development and is reserved. It will be non-functional
in the production version of MSCDEX.

- Absolute Disk Read
________________

    AX    1508h
    ES:BX    Disk Transfer Address; pointer to a buffer to copy data to
    CX    CD-ROM Drive letter (A=0, B=1, ... Z=25)
    DX    Number of sectors to read
    SI:DI    Starting sector
________________

This function corresponds to INT 25h. It will be converted directly into
a READ_LONG device driver request and sent to the correct device
driver. There are no requirements for this call to pop flags as there are
with INT 25h. SI holds the high word and DI the low word for the
starting sector to begin reading from.

If there is an error in processing the request, the Carry Flag will be set
and AL will contain the MS-DOS error code. These will be either
error_invalid_drive (15) or error_not_ready (21).

- Absolute Disk Write
________________

    AX    1509h
    ES:BX    Disk Transfer Address; pointer to buffer to copy data from
    CX    CD-ROM Drive letter
    DX    Number of sectors to write
    SI:DI    Starting sector
________________

This function corresponds to INT 26h. It is not supported at this time
and is reserved. It is intended to be used by authoring systems.

- CD-ROM Drive Check
________________

    AX    150Bh
    BX    Signature word
    CX    CD-ROM Drive letter (A=0, B=1,...Z=25)
________________

This function returns whether or not a drive letter is a CD-ROM drive
supported by MSCDEX. If the extensions are installed, BX will be set
to ADADh. If the drive letter is supported by MSCDEX, then AX is set
to a non-zero value. AX is set to zero if the drive is not supported. One
must be sure to check the signature word to know that MSCDEX is
installed and that AX has not been modified by another INT 2Fh
handler.

- MSCDEX Version
________________

    AX    150Ch
    BX    MSCDEX Version
________________

This function returns the version number of the CD-ROM Extensions
installed on the system. BH contains the major version number and
BL contains the minor version. Values returned are binary. For
example, BX would contain 0x020a for version 2.10. This function does
not work on versions earlier than 2.00 so if BX is zero before and after
this function is called, an earlier version of MSCDEX is installed.

- Get CD-ROM Drive Letters
________________

    AX    150Dh
    ES:BX    Transfer address; pointer to buffer to copy drive letter
device list
________________

The buffer must be large enough to hold a list of drive letters. The
buffer size will be a multiple of the number of drives returned by the
Get Number of CD-ROM drive letters function. There are a maximum
of 26 drive letters. Each drive letter entry is a single byte (0=A:, 1=B: ..
25=Z:) that exactly corresponds each respective entry returned by the
command Get CD-ROM drive device list. This command is included to
allow applications to locate CD-ROM drives supported by MSCDEX.
CD-ROM drive letters may sometimes be noncontiguous so this
command is necessary.

For example: Suppose there is an installed CD-ROM device driver
FOO supporting 3 sub-units on a system with 2 floppy drives (A=0 and
B=1), a hard disk (C=2) and a network drive (E=4). Note the network
drive occupies one of the drive letters normally taken by a CD-ROM
drive. MSCDEX assigns that CD-ROM drive to the next available
drive letter. Asking for the number of CD-ROM drive letters reports
there are 3 drive letters used starting at drive letter D=3. ES:BX must
point to a buffer that is at least 3 bytes long and will be filled as
follows:

ES:BX    = Buffer

Buffer    DB    3                ; drive letter for CD-ROM (D=3)
    DB    5                ; drive letter for CD-ROM (F=5)
    DB    6                ; drive letter for CD-ROM (G=6)

- Get/Set Volume Descriptor Preference
________________

    AX    150Eh
    BX    0 - Get Preference. 1 - Set Preference
    CX    CD-ROM Drive letter (A=0, B=1,...Z=25)
    DX    if BX = Get Preference
            DX = 0
            MSCDEX will return preference settings in DX
        if BX = Set Preference
            DH = volume descriptor preference
                1 - PVD - Primary Volume  Descriptor
                2 - SVD - Supplementary Volume Descriptor
            DL = Supplementary Volume Descriptor Preference
                if DH = PVD
                    DL = 0
                if DH = SVD
                    1 - shift-Kanji (an unregistered ISO coded
character set)
________________

Normally, MSCDEX will scan for the PVD (Primary Volume
Descriptor) when initializing a CD-ROM. This behavior can be altered
for each individual drive to scan for a SVD (Supplementary Volume
Descriptor) instead. A CD-ROM drive set to scan for an SVD will use
the PVD if there is no SVD present. There can be more than one SVD
on a CD-ROM but at present, MSCDEX will only recognize SVDs for
shift-Kanji CD-ROMs. Carry will be set, AX will be set to
error_invalid_function (1) and DX will be set to 0 if the coded character
set is not recognized.

If BX contains Get_Preference, MSCDEX will report the present
setting for that drive. If DX is still zero on return, that version of
MSCDEX does not support this function or reading SVDs. Otherwise
DX will contain the setting.

If the drive letter is not a CD-ROM drive, carry will be set and
error_invalid_drive (15) will be returned in AX. If BX is anything other
than Get/Set_Preference, AX will be set to error_invalid_function (1)
and carry will be set.

- Get Directory Entry
________________

    AX    150Fh
    CL    CD-ROM Drive letter (A=0, B=1,...Z=25)
    CH    Copy flags (bit 0: 0 - direct copy, 1 - copied to structure)
    ES:BX    Pointer to buffer with null-terminated path name
    SI:DI    Pointer to buffer to copy directory record information

    AX    0 is returned if the disc is High Sierra, 1 is returned if the disc
is ISO-9660
________________

The pathname expected is a null-terminated string e.g. char far *path
= "\\a\\b\\c.txt"; (note: the "\\" characters map to a single '\'
character in C so this would be '\a\b\c.txt' if printed). The path must
consist only of valid High Sierra or ISO-9660 filename characters and
must not contain any wildcards nor may it include entries for '.' or '..'.

The copy flags indicate how the data should be copied. If bit 0 (0x01) is
0, then the directory entry is copied as it appears on the disc. The
directory record is a direct copy from the directory file and it is up to
the application to choose what fields to use. If bit 0 is 1, then the
directory entry is copied into a structure that removes any differences
between High Sierra and ISO-9660 directory entries and makes some
fields more accessible or easily interpreted.

If copying the directory entry as it appears on the disc, the buffer to
copy the directory record should be at least 255 bytes long to include
all system use information and if copying into the common structure at
least 280 bytes long otherwise MSCDEX may overrun the end of the
buffer.

Carry will be set and an error code returned if there were problems
with the request. The error codes will be error_invalid_drive (15) if the
drive letter is incorrect, error_not_ready (21) if the disc didn't initialize
correctly, error_file_not_found (2) if the file was not found and
error_no_more_files (18) if the pattern fails to find a match or if
mscdex failed to allocate buffers.

The format of the directory record for High Sierra discs is:

    /* High Sierra directory entry structure */
typedef struct hsg_dir_entry
{
    uchar        len_dr;        /* length of this directory entry
    */
    uchar        XAR_len;    /* XAR length in LBN's (logical blocks
numbers)    */
    ulong        loc_extentI;    /* LBN of data Intel format            */
    ulong        loc_extentM;    /* LBN of data Molorola format
    */
    ulong        data_lenI;    /* length of file Intel format            */
    ulong        data_lenM;    /* length of file Motorola format
    */
    uchar        record_time[6];    /* date and time
    */
    uchar        file_flags_hsg;    /* 8 flags
    */
    uchar        reserved;    /* reserved field
    */
    uchar        il_size;        /* interleave size
    */
    uchar        il_skip;        /* interleave skip factor
    */
    ushort        VSSNI;        /* volume set sequence number Intel
    */
    ushort        VSSNM;    /* volume set sequence number Motorola
    */
    uchar        len_fi;        /* length of name                */
    uchar        file_id[...];    /* variable length name upto 32 chars
    */
    uchar        padding;    /* optional padding if file_id is odd length
    */
    uchar        sys_data[...]    /* variable length system data
    */
    } hsg_dir_entry;

The format of the directory record for ISO-9660 discs is:

    /* ISO-9660 directory entry structure */
typedef struct iso_dir_entry
 {
    uchar        len_dr;        /* length of this directory entry
    */
    uchar        XAR_len;    /* length of XAR in LBN's            */
    ulong        loc_extentI;    /* LBN of data Intel format            */
    ulong        loc_extentM;    /* LBN of data Molorola format
    */
    ulong        data_lenI;    /* length of file Intel format            */
    ulong        data_lenM;    /* length of file Motorola format
    */
    uchar        record_time[7];    /* date and time
    */
    uchar        file_flags_iso;    /* 8 flags
    */
    uchar        il_size;        /* interleave size
    */
    uchar        il_skip;        /* interleave skip factor
    */
    ushort        VSSNI;        /* volume set sequence num Intel
    */
    ushort        VSSNM;    /* volume set sequence num Motorola
    */
    uchar        len_fi;        /* length of name                */
    uchar        file_id[...];    /* variable length name upto 32 chars
    */
    uchar        padding;    /* optional padding if file_id is odd length
    */
    uchar        sys_data[...]    /* variable length system data
    */
    } iso_dir_entry;

Note that the difference between the two forms is the file flag byte
moved to account for an additional byte of date and time used for a
Greenwich mean time offset. Also, the C structs above are not
syntactically correct as C does not allow variable length arrays as
struct elements. They are meant to illustrate the differences between
the directory entries. See the May 28th draft of the High Sierra
proposal or ISO-9660 for a more complete explanation of the fields.

If bit 0 is set to one in the Copy Flags, then the format of the directory
entry structure that is returned is the following:

typedef struct dir_entry
 {
    uchar        XAR_len;    /* length of XAR in LBN's        */
    ulong        loc_extent;    /* logical block number of file start    */
    ushort        lb_size;        /* logical block size of  disc        */
    ulong        data_len;    /* length of file                */
    uchar        record_time[7];    /* date and time
    */
    uchar        file_flags;    /* 8 flags                */
    uchar        il_size;        /* interleave size            */
    uchar        il_skip;        /* interleave skip factor
    */
    ushort        VSSN;        /* volume set sequence number
    */
    uchar        len_fi;        /* length of the filename            */
    uchar        file_id[38];    /* filename, null terminated        */
    ushort        file_version;    /* version number of file            */
    uchar        len_su;        /* length of valid system use bytes
    */
    uchar        su_data[220]    /* up to 220 bytes of system use data    */
    } dir_entry;

The location of the extent is reported in logical block numbers and the
caller can use the logical block size on the disc (logical block sizes of
512, 1024, and 2048 bytes per sector are valid for CD-ROM) to
determine the exact sector and offset in that sector that the file extent
begins in. If the logical block size is 2048 then logical block numbers
are equivilent to logical sector numbers.

The Greenwich mean time offset byte in this structure for May 28
High Sierra discs is always 0. The file_id field contains the file
identifier less the semicolon and version number if present and is null
terminated. The version number is already parsed and is present in
binary form in file_version. All bytes beyond what are indicated by
len_fi and len_su in the file_id and su_data fields are undefined except
the null byte immediately following the file identifier which is not
counted as part of the filename length.

- Send Device Driver Request
________________

    AX    1510h
    CX    CD-ROM drive letter (A=0, B=1, ... Z=25)
    ES:BX    Address of CD-ROM device driver request header
________________

This function has been added to simplify communication with CD-ROM
drivers and help prevent contention between applications that wish to
communicate with the device driver. It is highly recommended that all
applications communicate with device drivers through this function request.
Applications using this function will not have to locate the device driver. The
format of the request header is specified by the Microsoft MS-DOS CD-ROM
Extensions Hardware-dependent Device Driver Specification. MSCDEX will
supply the sub-unit field.


Microsoft MS-DOS CD-ROM Extensions
Questions and Answers
23 March, 1990

Q: Does the /V option to MSCDEX actually cause a message to be displayed? I
can't make it do anything. I use:
    MSCDEX /D:CDDRV /V /M:8

A: Yes, a series of statistics are displayed. MSCDEX uses INT 10 function
0eH to write to the console, so if for some reason you are trapping this or
have software that captures this and doesn't display bios output to the screen
the information will not appear. All screen output uses this function so if any
output appears on the screen after loading MSCDEX, it is not clear why this
additional information does not appear.

Newer versions (2.0 and above) use the DOS write handle call for output
which will fix problems of I/O redirection of this output.

As it turned out, the machine that had this problem was not a strict IBM-
compatible machine and did not emulate a PC at the BIOS level.
Consequently, the messages written with INT 10h were not displayed.

Q: Is it normal for MSCDEX to hang the system if an error is returned by a
driver's IOCTL function? Wouldn't an error message be better?

The only ioctl calls sent to the driver in version 1.01 are to request the device
header address and media check. Media check calls will never hang no
matter what is returned so long as the driver returns. Illegal values may not
do what you want but it won't hang. Request device header address may
hang if the driver fails to set error conditions correctly as DOS expects them
as DOS will return from the ioctl call without error. MSCDEX will then
assume the bogus return values are correct and jump to a random location.

Q: Does MSCDEX do anything that should preclude its working in a non-
IBM-clone machine?

A: Except for the INT 10 problem mentioned earlier, no. If you can identify
any problems whatsoever,  we would be happy to learn about it, but as yet we
have heard of no other problems.  If your machine runs MS-DOS version 3.X
or 4.X, it should be capable of running the Extensions correctly.  As for
driver/drive-controller compatability problems, that may be another matter.
We do not guarantee anything about these because we do not write the device
drivers or design the hardware interface boards and cannot make any claims
concerning them. It is up to the drive manufacturer or device driver writer to
do this kind of compatability testing.

Q: Based on what I read in the spec, I decided to support only HSG type
addressing which seems to be allowed by the IOCTLI function #6 (Device
Status). I return 4 bytes of 00h if that function is called. I would have
thought that would be one of the first calls MSCDEX would make (after
"Find Header") but so far it hasn't called the status function. How will
MSCDEX know enough not to use Red Book addressing if it doesn't check
status first?

A: In version 1.01, ioctl function #6 is not called although it is called by
MSCDEX starting with version 2.00. Since all device drivers must support
some default functionality and as MSCDEX only uses the basic default now
(only High Sierra addressing for example), it wasn't a problem that it didn't
call this function to find out about non-default features that were supported.

Some software is being written that controls audio on a CD-ROM that
expects Red Book Addressing and checks the device status to see that it is
supported. The conversion algorithms are fairly simple and code fragments
are provided.

Q: Can you provide more info on how the READ/WRITE device control string
should work. Does the read device bytes command get information that was
written by the write device control string?

A: At present, there are very few people that use this command. There are a
couple other features that are either used only in special instances or not at
all at present. This is not to say that they won't be used at some later time.

   The purpose of these commands was to allow a standard way of delivering
commands that were not specified in the CD-ROM device driver spec to the
drive. For example, sending SCSI command strings and reading the
responses from the drive. This function is deliberately open-ended and vague
because it was intended to provide a catch-all mechanism for application
programs to communicate requests or request data in ways that were not
specified by the device driver spec. For application programs to use these
functions they have to know the driver supports these functions and also how
to communicate with that specific drive. The mechanism would let the driver
do what it does best and worry about which ports and interrupts to use. This
relieves the application program from these details and allow it to deal with
controlling the device at a higher level.

   Right now, if the driver does not support these functions, it should return
an error for Unknown Command. One could test whether these two function
were supported this way. Note: if there are commands which you feel should
be supported by the device driver specification, please communicate them to
us and we will consider adding them if they are of sufficient general interest.

Q: Would it be possible for me to get a sample source file for a driver?

A: Yes. Licensees are given source code to device drivers for:

    SONY - complete

    HITACHI - missing two modules. These are owned by Hitachi so we
      cannot supply them, though Hitachi will.

    PHILIPS - this driver communicates with the LMS CD-ROM driver
      supplied by LMS.

Q: How can an application access CD-ROM drives that are subunits of one
driver? The IOCTL calls do not take an argument for subunit. MSCDEX
seems to handle this OK since when I do a directory of each CD-ROM in turn
it accesses the correct drive. I do not see any clean way for an application to,
for example lock the door on CD-ROM drive G: which is the third drive
handled by the driver.

A: Requests all have a sub-unit field in the request header. Commands that
one would expect to be directed to a specific drive, such as open door, are
targeted at a particular drive through the use of the sub-unit field.

Q:  What is the current release version number of MSCDEX? The version I
have is version 1.01 that is marked EVALUATION COPY. When can I get a
final release version of it? Also will that final version include the changes to
do all I/O through MSDOS (i.e. no INT 10h).

A: The most recent released version is version 2.20. You can purchase this
from a number of licensees including all drive manufacturers. A Microsoft
MS-DOS CD-ROM Extensions availability list is available. Versions 2.00 and
up use MS-DOS for I/O and do not use the Bios for writing.

Q: Why doesn't MSCDEX allow IOCTL access via the drive letter (i.e. DOS
func. 44h subfunc. #4,5), as if the CD-ROM were a normal drive. I
understand that the driver is not a block device, but this is being handled
already in some way since you allow a user to perform file I/O to a CD-ROM
making it appear to be a block device. It would seem that all that would be
necessary to accomplish this is to intercept IOCTL calls in the same way that
file access calls are being intercepted.

A: MSCDEX doesn't presently hook int 21h, which is what this would
involve. It's doubtful that this will change. It's not that much more difficult to
open the file and send an IOCTL to the handle. File access calls are not
caught at an INT 21h level but are caught from within DOS at another
interface. CD-ROM drives are far more like network drives than traditional
MS-DOS FAT file structure block drives and their drivers. For example, try
to FORMAT a CD-ROM drive and you'll see. Part of all this prevents IOCTL's
to the drive letter from being directed to the appropriate driver.

Q: Why not allow access to the PLAY, STOP and SEEK functions via the INT
2Fh entry point as is allowed for READ LONG. This would be much simpler
than requiring the application to locate the driver header and then find the
STRATEGY entry point and create request control blocks etc. This is a lot of
code to start the music playing!

A: It's preferable to see future MS-DOS versions that provide standard
extensions to the application program interface for audio/video control (new
int 21h calls). The reason we haven't included play, etc. in the int 2Fh
interface is to avoid loading down MSCDEX with additional functionality
that most people don't use. Your suggestion would only move that code from
the CD-playing program into MSCDEX. It makes your program smaller at
the expense of making MSCDEX larger. As time goes on, this may change
and some of the functionality may move into the int 2Fh interface. In the
meantime, you can contruct device driver requests and use MSCDEX to send
them to the driver through the Send Device Driver Request function request.

Q: Shouldn't the specification eliminate the need for the application to OPEN
the driver by name? This is especially important in systems where the driver
creates a new driver header for each CD-ROM drive. As it is, MS-DOS allows
so few file handles to be open simultaneously that requiring applications to
open even more is very bad.

A: Simply close the driver handle after you have located the device header.
You no longer need to communicate through DOS to control it, so free the
handle and make it available for other programs to use. With version 2.10, it
is no longer necessary to OPEN the device driver in order to communicate
with it. Applications can communicate with the device driver using Send
Device Driver Request.

Q: Have you considered adding an addressing mode for the PLAY AUDIO
function that would allow the application to specify the PLAY address by
TNO instead of block number or min/sec/frame?

A: This has been considered but has not been added to avoid complicating the
device drivers unnecessarily. At the moment, most CD-ROM drives are used
without audio so our intent was to put what was needed for audio support in
the audio playing software. In addition, we chose to keep the interface simple
to leave more latitude for changes to the OS/2 API that may include newer
data types like audio and video. Nonetheless, more extensive audio support
may be added in the future. In the meantime, audio playing software has the
extra overhead of reading the audio table of contents and interpreting the
tracks itself.

Q: Why is there no CLOSE TRAY function in the driver spec? The CD-ROM
drive we are using (Toshiba SCSI) has this capability but I see no way to use
it via the Extensions. Why allow the user to OPEN it without allowing him to
close it?

A: A close tray command has been added.

Q: It seems that there should be bits in the Device Status word to indicate
whether a driver supports Reading/Writing device control strings.

A: Reading and writing device control strings was put in as a catch-all for
anything that was missed so that application programs could send specific
commands through the device driver to the device if they understood the
device and knew how to communicate to it. A manufacturers CD-ROM
diagnostic program would be an example of a program that might choose to
communicate with the drive in this way. If the driver does not support these
functions, it should return an error. One can test whether these two function
are supported by testing if the error returned is for Unknown Command.

Q: In the spec, treatment of the BUSY bit in the status word with regard to
the PLAY AUDIO function seems to assume only one CD-ROM drive. What
happens when the user has two or more drives each of which want to be
playing music? How does the application tell whether the desired drive is
busy? It would seem better to use some of the bits in the upper word of
Device Status to indicate BUSY for each drive, perhaps allowing 8 or 16
drives.

A: Requests all have sub-unit numbers associated with them. A request for
service from one sub-unit may report that the drive is busy at the same time
another sub-unit was not busy. The sub-unit field is used to distinguish
requests between the drives supported by the driver. The busy bit serves as
an indication of drive status for the sub-unit the request is for.

Q: If a CD-ROM file is opened in write-only mode, no error occurs.

A: True. The same happens on a floppy drive with a write-protect tab on it.  If
you do have a handle to a CD-ROM file in open_for_write mode, as soon as
you attempt to write, you will get an error. The correct model is to duplicate
the behavior of a file that has been set READ-ONLY. Read-only files return
error_access_denied if you try to open them in open_for_write or
open_for_both modes. MSCDEX has been changed to duplicate this behavior.

Q: What other non-MSDOS calls are issued by MSCDEX besides INT 10h?
A:
    INT 2Fh - dos callbacks
    INT 67h    - expanded memory
    INT 10h - all INT 10h calls went away with version 2.00 which uses
DOS write handle  instead.

Q: Why does MSCDEX do the READ LONG PREFETCH call after it has
done a DEVICE CLOSE call? Is this intentional?

A: MSCDEX version 1.X never issued device open or close. These were issued
by DOS as part of driver initialization. MSCDEX version 2.00 now issues
device open calls and will precede the prefetch call.

Q: In the device driver spec, it says that if more than one unit is supported by
the driver that this field should be set to the number of units. I suspect that
this is wrong since this is not a block device. As far as I can see, this field
should only ever be set to one since each unit will actually have its own
header with its own unique name.

A: CD-ROM device drivers are a hybrid of block and char device drivers and
are not technically legal as one or the other. Block drivers make some
assumptions about the media format that aren't meaningful for CD-ROM and
don't have a read call that can deal with CD-ROM's large data space. They
were made as char devices with some additional calls and rules. One of the
changes that was made for CD-ROM device drivers was to allow multiple
sub-units for the device so the treatment of this field is correct as specified
even though CD-ROM device drivers are character device drivers.

   If one has more than one CD-ROM drive, one can approach supporting
them from several ways. One could have separate device drivers for each
drive and load one per drive, have a single driver with multiple device
headers, or have a single driver with one device header that supports sub-
units. This last method is borrowed from block drivers. For the case that the
drives and drive commands are all the same, using sub-units will allow you
to distinguish between which drive receives which command. The
alternatives clutter DOS up with drivers or device headers. Sub-units may
not be legal character device driver fields but conceptually, they're the right
thing. Since CD-ROM device drivers could not be block drivers and had to be
char device drivers, some liberties were taken with the specification to merge
the best of both specifications.

Q: Is there any support through MSCDEX for WRITE LONG? I have a need
for this to support a CD mastering system. I would like to be able to treat a
WORM drive as a CD-ROM and allow writing to the drive once to create a
master and then be able to test it out by using it as CD-ROM to verify that
our data has been correctly stored in "High Sierra" format.

A: Such a call exists. It only serves to define a standard interface for CD-
ROM device drivers that are running over re-writable media - such as a CD
mastering system. It is in the driver specificiation starting with version 2.00
of the CD-ROM Extensions.

Q: How important is it that I should support RAW mode access in my driver?
What would this typically be used for?

A: This is something that is gaining in importance. Several drives support
reading in raw mode. Since drives and their command capabilities are
hardware dependent, you would know based on the capabilities of your
hardware if you were capable of supporting it. This function was added for
completeness. A standard way was needed to define how to get at the 288
bytes of EDC/ECC if drives allowed access and to have an avenue prepared if
people found useful applications that would not use EDC/ECC where they
wanted the additional space (such as gracefully degrading low-fidelity audio
or graphics). It will be useful for copying audio information or for audio
systems that will want to be able to manipulate audio tracks. Many people
have expressed interest in having this capability.

Q: In the structure for the UPC Code function, "The UPC/EAN code (last 4
bits are zero)". Does this mean the low order or high order 4 bits?

A: This is less ambiguous if you read Red Book under mode-2 of the Q-
channel info. This is now clarified in the UPC Code call. It should be the low
nibble of byte 7. Red Book specifies that MSB comes out first so the high
nibble will contain the 13th nibble of the UPC code and the 14th nibble will
be zero.
   Unfortunately, scanning for the UPC code is time consuming especially if it
is done by the software. This is due to the design of the q-channel in Red
Book. It's a pity because this could be a useful number to verify the correct
disc has been inserted. Most CD-ROMs do not have a UPC code or have it
zeroed out. The same seems to be true for CD-audio as well. We believe that
CD-ROM drives should scan for the UPC code as they read the Table of
Contents when initializing from power up or a new disc. If the hardware does
not do this, the UPC code has to be scanned by polling the q-channel which
may occasionally miss the UPC code.

Q: It would be nice if the device driver spec included a list of what types of
disk access functions would and would not work so that users could get an
idea of what utilities and applications will and will not work with the
extensions.

A: The device driver specification describes just what is necessary for writing
a CD-ROM device driver. The information you would like concerning things
such as INT 25h/26h not supported as well as the behavior
CHKDSK/FORMAT/etc belongs and is mentioned in the MSCDEX overview.

Q: If I have a low priority request and if the system has time, can the
prefetch request read into and transfer the data into a transfer address?

A: We have looked at this for some time but the bottom line is that
asynchronous I/O under DOS is very difficult to support in all cases. It is
difficult for MSCDEX or the CD-ROM device driver to know that the transfer
address is still valid because DOS never notifies MSCDEX or the device
driver if the requesting process was been terminated. The request runs the
risk of writing over another program. The best approach now is if the driver
wants to, it can reserve internal buffer space for data from the disc and put
prefetched data there. Then it can copy the data to the read transfer address
once the read request finally arrives. Alternately, some of the caching or
prefetching can reside in the CD-ROM controller or in the drive itself. The
CD-ROM XA device driver appendix though allows a mechanism for reading
files asynchronously although this requires a CD-ROM XA drive and imposes
burdens for the application to notify the driver when the process halts and to
move data .

Q: Is there any status indication that a prefetch transfer has occurred or
some interaction with the read long command?

A: There is no way to tell if a prefetch request was successful or the state of
it. The prefetch simply provides a hint to the driver and the read request
later is the request that finally takes delivery of the data.

Q: Read (ioctl input) When audio is playing, can location of head move?

A: I'm not entirely sure what you mean by this question but I will attempt to
answer a couple different ways and hope I provide the information you need.
   While audio is playing, the head is moving on the CD. If the driver receives
a command asking where the head is, the driver should ask the drive where
the head is presently positioned and report that. So as audio is playing, an
application program that is controlling the audio can monitor the progress of
audio playback and can either synchronize actions with the audio or report
the present location to the user. For example, a program to play audio discs
would be able to report the present track number and time elapsed on the
computer monitor much like a CD-audio player reports things on its LED
display. If the driver is sent a command that requires the movement of the
head or a change in the state of the machine (SEEK, READ, INITIALIZE,
PLAY AUDIO etc.) then the audio will be interrupted so that the drive can
perform the new request.  If the drive receives a command for status or some
other function that does not require the head to be moved or the state of the
machine to change, then audio play should continue.

Q: Are the parameters of Audio Disk Info and Audio Track Info BCD or
binary?

A: The parameters were vaguely specified in the device driver spec. The spec
has been clarified. They are as follows:

- Audio Disk Info
        binary    Lowest Track Number (1-99)
        binary    Highest Track Number (1-99)
        red book    Starting point of lead-out track

- Audio Track Info
        binary    Track Number (1-99)
        red book    Starting point of track
        as is    Track control information

The track control information is not a BCD or Binary number like the track
number. The byte contents as it appears on the disc should be carried
through unmodified by the driver and is interpreted according to the
Philips/Sony Red Book standard.

Q: Are the parameters for the Audio Q-channel info BCD or binary?

A: The parameters are as follows:

- Audio Q-Channel Info
        as is    Control and ADDR byte
        as is    Track Number
        as is    Point or Index (X)

        red book    MIN/SEC/FRAME
        zero    ZERO
        red book    AMIN/ASEC/AFRAME or PMIN/PSEC/PFRAME

The notes on when to convert from BCD to red book addresses for
MIN/SEC/FRAME, AMIN/ASEC/AFRAME and PMIN/PSEC/PFRAME is
already fairly clear in the spec. The other fields are passed through as is from
the disc. For additional information, see the two code samples AUDIO.C and
AUDIO.ASM.

Q: Must we support read sub-channel info and the read upc code?

A: No. It is not necessary that these be supported. At the present time and in
the forseeable future, MSCDEX will not be issuing these commands though
some applications may wish to.

- Read Sub-Channel Information

At the present time, nobody is using channels P or R through W. The read
sub-channel command was added to provide a standard way to specify access
to these channels in the event that they are used and to specify in one way or
another access to all information on a CD-ROM. The error detection or
correction for information in these channels is not as good as it is for data
returned from READ commands. There are existing standards for P, R-W
channel use and this command could be used to access this information once
discs abiding by these standards become more common.

- Read UPC Code

This command is conceivably much more useful. It is advised that it be
supported so that application software can exactly identify the CD-ROM in
the drive. This may be a consideration for audio software that wishes to try to
identify inserted audio discs (if the UPC code is present) or for software that
is specifically tied to a version of a CD-ROM. Unfortunately, the standard
does not specify a specific location for this information so that unless the
hardware reads it on disc initialization as we recommend, the device driver
must poll the q-channel and hope that it locates it. See also the sample code
in AUDIO.ASM.

Q: My driver seems to work ok except that whenever I connect to a sub-
directory and do a directory, I am suddenly back in the root directory again.
What's going wrong?

A: What is most likely happening is the driver is returning an incorrect value
for MEDIA CHECK and MSCDEX thinks that the disc is changing all the
time. When this happens, MSCDEX rereads the volume descriptors and
pathtable and reinitializes what it knows about the disc and changes the
current working directory back to root as if the drawer had been opened, the
disc removed, and then reinserted. This will be accompanied with a larger
amount of disc activity than one would expect for a simple directory scan.
Fixing the driver to return the correct value when asked for a media check
will correct this behavior.

Q: What is the best way for my application to know if the disc has changed
since it was last accessed?

A: Use the DOS function find first and look for the volume id. When the disc
has been read and MSCDEX has already initialized the internal information
it keeps for each disc, this is a relatively inexpensive operation. The
information is in memory and the disc does not have to be touched, so
checking the volume id is very quick. Only if the disc has been changed does
the disc have to be touched. This operation takes considerably longer than if
the disc was not changed but even so, this has to be done anyway because
MSCDEX has to read and initialize what it knows about the new disc so it
can report the volume id correctly so the application can know if the disc in
the drive is the one that it is looking for.

Q: When I do a directory, the first couple filenames are either duplicated or
they are random characters. What might cause this?

A: The problem comes from having the incorrect bytes in the file identifier
field for the first two directory entries. The first directory entry in each
directory file is supposed begin with a copy of the directory record for that
directory file followed by a copy of the directory record for the parent
directory (also known as '.' and '..' on Unix or MS-DOS). The filename or
directory identifier is supposed to be 1 byte long and the contents are
supposed to be 0 for the first directory entry and 1 for the second directory
entry. This is discussed in clause 6.8.2.2 of the ECMA standard or the ISO-
9660 proposal. Several places on the disc in question, you have a 1 where
there should be a 0 and in one directory, the file identifier consists of 0x8A
which is why DIR in that directory begins with an "e". Incorrectly formatted
discs will not be handled by the extensions correctly. This is why it is a good
idea to test your disc image using MSCDEX before you press a disc to make
sure your data is formatted correctly and as MSCDEX expects it.

Q: I have a directory file that is 4Kb long but when I do a DIR in that
directory, it is slower than usual and random filenames are printed out. I can
tell by watching the device driver commands that MSCDEX is asking for
sectors far beyond the end of the directory. I can see how this might account
for the random filenames but why is it scanning so far?

A: Problems such as this result from having with multi-sector directory files
that include empty sectors in the directory file. The High Sierra specification
does not allow you to have empty directory sectors at the end or to have gaps
in the middle. The problem stems from the fact that your directory length is
too long. For example, for the disc in question, the root directory begins at
sector 28 and its length is 4096 bytes but the second sector is completely
blank (all 0's). This confuses MSCDEX because it does not expect to see
empty sectors.

   Because LEN_DR of what would be the first directory entry in sector 29 is
0, MSCDEX thinks that there are no more entries in that sector. When it
reaches the end of the entries in each sector, MSCDEX rounds its offset up to
the start of the next sector:
    offset += (SECTOR_SIZE - 1);
    offset &= ~(SECTOR_SIZE - 1);
Since the offset did not changed when scanning sector 29 (there were no
entries in this sector to increment the offset) the above rounding algorithm
does not change the offset (2048 in, 2048 out). This is why MSCDEX
continues reading beyond the end of the directory file at sector 29 because
the offset did not grow past the directory length. MSCDEX continues reading
blank sectors (sectors 29 through 49 are all blank) until it reaches the first
non-blank sector.

It looks like what you are attempting to do is implement updatable High
Sierra and you want to allocate the directory space ahead of time and fill it in
later as needed. The format you are using though is not valid High Sierra
and also incurs the cost of reading the blank directory sectors at the end of
every directory. Instead, you should record the correct High Sierra directory
length in the directory length field for that directory (in this case 2Kb). What
remains is finding a place to store the value which tells how many blocks
have been reserved for each directory file. There are a number of places this
can be done, either in system/application use fields in the directory record, in
an XAR, or in a separate file either inside or outside the High Sierra
directory structure. The first is the easiest approach to take.

Be aware thought that CD-I may have plans to use the system use field in
the directory record so you may want to investigate Philips' plans to make
sure whatever scheme you use meshes well with what CD-I has in mind. The
CD-ROM XA specification includes methods for mediating use of the System
Use fields in the directory entry that you should look into. MSCDEX will
ignore the system use or application use information recorded so you can
store what you'd like in the form you like (ascii or binary). You may also
want a final pass over the directory hierarchy before mastering to remove
extraneous information from the directory record.

Q: I noticed that Function Request 0 Get Number of CD-ROM drive letters
may not always return unambiguous results. Suppose I start the network
first and use one of the drive letters for a network drive (F:). When I start the
Extensions, it will begin assigning drive letters after the last used drive
letter (C: on my machine).  If I have 4 CD-ROM drives on my system, they
will be assigned drive letters D:, E:, G:, and H:. Function 0 returns 4 in BX
for the number of CD-ROM drives and 3 in CX for drive letter D: correctly.
But as you can see, the CD-ROM drives do not use contiguous drive letters so
I cannot deduce from what this function returns that drive F: is not a CD-
ROM drive.

A: That is correct. This is why function 0Dh Get CD-ROM drive letters was
added. To get an unambiguous list of CD-ROM drives, use this function or
use function 0Bh CD-ROM Drive Check to tell if a drive letter is for a CD-
ROM drive.

Q: Is it possible to do an absolute read using the Extensions.  I am trying to
read mode 2 (uncooked) data using Function Request 8 Absolute Read. I use
a normal device I/O to turn off error correction and perform a read but all I
get back is 2048 bytes of data instead of the full 2356 bytes. Is there another
way in Int 2F to get the data uncooked?

A: Not at present. If you want to get at the data including error correction
code, you will have to communicate directly with the device driver. The
Extensions provides the Send Device Driver Request mechanism for
communicating with the device driver.

Q: Is it possible to access a non-High Sierra disc with the Extensions using
an absolute disc read?

A: One can use either the extensions to read a non-High Sierra disc using
INT 2Fh or one can communicate directly with the device driver to do this.
The device driver itself makes no distinction between High Sierra and non-
High Sierra discs so it can be used to read them although the burden of file
system translation and reading then falls on the application talking to the
driver. The INT 2Fh Absolute Read function simply packages the request to
read and sends it directly to the driver and returns the result.

Q: What we have done is, in AUTOEXEC.BAT, first loaded the MS-DOS CD-
ROM Extensions and then the MS-NET software. The error message is
"Redirector already installed". The network software is then not loaded.  We
are using MS-NET 1.1 in an HP product called ThinLAN. Any hints as to
what they should try next?

A: MSCDEX is a CD-ROM "redirector". It hooks into DOS the same way the
network redirector does to get requests for file access to files that are not on
local hard/floppy disks. As far as DOS is concerned, CD-ROM drives look just
like network drives. DOS passes all file accesses through the redirector
interface to the network redirector which in turn sends file access requests
out over the net. MSCDEX splices itself in front of the network redirector and
takes requests belonging to CD-ROM drives and passes the rest to the
network redirector.

The problem is that the network redirector code assumes that there will only
be one redirector installed (itself) whereas MSCDEX does not make this
assumption. If the network redirector is installed after MSCDEX (before it in
the interrupt chain), it will process all requests from DOS and never pass
any CD-ROM requests through to MSCDEX. For this reason, MSCDEX has
to be installed after the network redirector (before it in the interrupt chain)
and so MSCDEX prevents the network redirector from installing afterwards
to ensure this. Since you installed MSCDEX first, the network believes a
redirector is already installed so it does not install itself which is what you
are seeing. In order to install both, simply install your network software first
and MSCDEX second and you're set.

Q: CHKDSK, ASSIGN, and SUBST report that the CD-ROM is a network
disc. Why is this?

A: From the above explanation, you understand that to DOS, the CD-ROM
drives look like network drives. The programs CHKDSK, ASSIGN, and
SUBST check the same fields DOS does and think the same thing. There is
no way to get around this.

Q: RENAME gives error message "Duplicate file name or File not found"
instead of something that makes sense such as "Access denied" or "Can't
rename CD-ROM files".

A: The error message is coming from the code for RENAME and not
MSCDEX.  The error condition is being returned correctly but the error code
returned by version 1.01 is correct according to DOS documentation. The
problem seems to be that there are two error codes for access denied - 5 and a
special one 65 which is error_net_access_denied which is returned by the
network redirector when it has a problem. MSCDEX version 2.00 and up
returns error code error_net_access_denied and so RENAME now reports
"Access denied".


This document describes the file transfer tests DOSSPEED and WINSPEED
provided on DISK1.  These programs measure the rate that data can be read
from the CD-ROM, with DOSSPEED measuring this transfer rate in the
DOS environment and WINSPEED in the Windows environment.

The Need for Speed Tests

One thing that distinguishes CD-ROM media from other media is the nature
in which the data is provided, that is, it can be viewed as a "data stream."
The fact that an application can depend upon the data coming off the disc at
a guaranteed rate of 150Kb/second provides unique advantages.
Unfortunately there are various problems, which in practice can limit
throughput, creating the situation that while the transfer rate on any one
drive is fairly constant, it is often less 150Kb/second, sometimes much less.  If
an application prepares a data stream to be played off the disc it must be
able to make certain assumptions about the rate at which the data stream
will be provided.  If the designers of the application decide to support a drive
which cannot maintain 150Kb/second, then they have to make a decision
about what minimum transfer rate to support, and to do this they need
information about  sustainable transfer rates.  Therefore the sustainable
transfer rate available on your drive is important information which should
be determined and provided to your customers.

Description of DOS Speed Test

Usage information (This is also available by typing "DOSSPEED -?"):

DOSSPEED [pathname] [-r:X] [-b:X] [-p:X] [-f] [-t]

where:

[pathname]        Path and name of file to test.

-r        Sets the transfer rate in bytes/sec (150Kb/sec default).

-b:[blocksize]    Sets the blocksize (bytes per read request), which must be
from 1 to 65534 (16Kb default).

-p        Specifies the number of bytes used to prime the buffer. The
number of bytes range  from 1 to 65534 with a default of 0.  This
parameter allows a read-ahead buffer to fill up before the transfer
rate timing actually begins. This is useful when testing transfer
rates approaching the maximum rate available for CD-ROM
drives.

-f        Performs a straight speed test with no delays, that is, it doesn't
calculate how much time was spent blocked in the synchronous
read requests.

-t        Causes terse output in the following format (useful for input to a
spreadsheet):

<file><xfer rate><blocksize><primer><bytes read><real
xferrate><% time blocked>

DOSSPEED.EXE determines several characteristics of a CD-ROM drive.
The command line options give three degrees of freedom.  Some suggested
performance curves are:

    Transfer rate as a function of blocksize

    Transfer rate as a function of primer bytes

    CPU usage (% time blocked) as a function of blocksize

    CPU usage (% time blocked) as a function of expected transfer rate

    CPU usage (% time blocked) as a function of both blocksize and
expected transfer rate

It is important to consider the best use of a CD-ROM drive.  Applications
require sustainable transfer rates with suitable CPU bandwith available to
complete various tasks between contiguous read requests.  By considering
the CPU usage as a function of both blocksize and expected transfer rates, a
buffering solution may be determined.  Always select a relatively large file
for conducting DOSSPEED tests in order to reduce the small degree of error
in the timing loop.

Description of Windows Speed Test

This speed test operates as a Windows application.  The Windows speed test
pops up a window with a standard Files/Directories I/O dialog.  The tester
selects a file on the CD-ROM disc and, like the DOS test, it keeps track of
how much time elapses in reading the entire file, reports the average transfer
rate, how many total bytes were read, and how many bytes were read by each
request.  Unlike the DOS based test, this test doesn't analyze CPU
bandwidth available between read requests.

To run this test select Run from the File menu, and execute the command:
<drivename:\pathname\>WINSPEED.EXE.



TESTDRV is a rigorous test utility for CD-ROM device drivers to verify that
the drivers adhere to specifications.  This driver test attempts to fully
exercise all possible calls to the device driver and record the driver's progress.

Setup for TESTDRV

TESTDRV assumes that MSCDEX and the appropriate device driver are
installed. During initialization, TESTDRV reads the driver profile from the
file TESTDRV.PRO which assigns  the device status defaults for the test.
The following example shows a typical TESTDRV.PRO file:

    ; This is a sample TESTDRV.PRO
    ; Comments start with ';' and continue to the newline
    DriverName    = MSCD000    ; The driver to test
(specified as
            ; argument to the
<drivername>.SYS
            ; command line
    WriteDevice    = f    ; This device is not writable
    Redbook    = t    ; This device supports Redbook
            ; Addressing
    RawMode    = t    ; This device supports raw
mode data
    Prefetch    = t    ; This device supports
prefetching
    AudioControl    = t    ; This device supports audio
channel
            ; manipulation
    Audio    = t    ; This device supports
audio/video
            ; information
    AudioChannels    = 2    ; Number of supported
audio channels
    Interleave    = f    ; This device does not support
            ; Interleave mode
    InterleaveSize    = 0    ; Interleave size (may
range between
            ; 0-255)
    InterleaveSkip    = 0    ; Interleave skip (may
range between
            ; 0-255)
    Eject    = t    ; This device supports
software
            ; eject requests
    UPC    = t    ; This device implements UPC
code
            ; reading
    Output    = HEXDUMP.TXT    ; Output hex dumps to
this file.
            ; Blank assignment sends
output to
            ; stdout
    RedReadSectors    = 3:8:3,8:2:4    ; List of
sectors to read in ReadL
            ; tests (red book form)
    HSGReadSectors    = 0024180c,00ff3421 ; List of
sectors to read
            ; in ReadL tests (HSG form)
hex only

    ; <EOF>

If the profile variables are not set in the TESTDRV.PRO file, they will
default to the values shown above (except for the sector selections).

Running TESTDRV

To run the test simply install your device driver, initiate MSCDEX, and
execute TESTDRV.EXE. The default operation of TESTDRV can be modified
through command line flags and arguments. Either a hyphen (-) or a forward
slash (/) denotes the flags. The following command line flags and arguments
are available:

    filename    - Alternate driver profile. (default: TESTDRV.PRO)
    /A    - Attended operation, qualifying interactive tests. (default:
          unattended operation)
    /I    - Override disk recognition on control disk, (that is, behave as if
          the disk is unknown even if it is a member of the Test Set).
          (default: if recognized, several data matching tests are
qualified).
    /T    - Terse output, no hex dumps and fewer diagnostic messages.
    /[#]    - Where # is a digit between 0 and 7, the drive number.

In unattended (default) mode, all tests will be verified by both successful
completion, given an acceptable request, and successful error recovery, given
an unacceptable request.  The output has the following format:

 [Command Code.Subcommand Code]   [Status]
[Command[:Subcommand]]:[Test Comment]

For example, the test for the location of the driver head may return:

    3.1 TESTING  IOCTLI:LocHead: Value Corresponds to Q-
channel         Information.

    3.1 ERROR    IOCTLI:LocHead: Value Does not Correspond
to
        Q-channel  Information.
          LocHead returns     1:23:60 [Redbook]
          Q-channel returns     2:30:45 [Redbook]

Commands that return sector data or device dependent data will dump
output in hexadecimal.  If the disk is a recognized test disk and recognition is
turned on (default), sector data will be compared to correct values and only
the status returned.

Attended and Unattended Operation

Several calls to the driver cause or report physical changes in the drive unit
or require that audio disk information be played through audio channels like
conventional audio CD players.  These states should be confirmed by an
operator.  A series of YES/NO queries and simple directions allow the
operator to quickly step through these tests.  In order to allow for operator-
free testing, a set of alternate best-guess tests can be executed instead of the
ones that require confirmation.  Attended testing is a super-set of unattended
testing and should be considered the most complete run of the test program.
For example, the following sequence occurs in the attended mode:

    132 TESTING PlayReq: Can you hear music playing? [Yn]_
        { ..music plays and tester responds 'Y'.. }
    132 TESTING PlayReq: Request Completed Successfully.

Control Disk Verification

The test for verifying read data requires the Microsoft Bookshelf and
Microsoft Programmer's Library to be used as control disks. The test
procedure reads data from the control disks then compares both  raw and
cooked data for correspondence with archived data. If the test is run without
the control disks, the data read is dumped in hexadecimal and ASCII format
to the specified output.

Nonstandard CD-ROM Features

Several driver commands derive their results or actions from hardware
dependent features of the driver.  Since not all drivers can be supported in a
general release, special features of a device driver may not be adequately
tested.  (For example, write commands apply to few CD-ROM drives and are
only minimally supported  by error recovery tests.) If the hardware
dependent CD-ROM device driver document describes the results of a driver
request as undefined, the request will be tested for simple completion and
error recovery.   Requests that return data will dump the data to the selected
output in hexadecimal and readable ASCII format.