Inside Multimedia 1995 May

home *** CD-ROM | disk | FTP | other *** search

/ Inside Multimedia 1995 May / IMM0595.ISO / driver / mitsumi / mscdex.txt < prev next >

Wrap

Text File | 1992-06-02 | 103.0 KB | 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.