Category : Recently Uploaded Files
Archive   : INFOPACK.ZIP
Filename : TESTDRV.TXT

 
Output of file : TESTDRV.TXT contained in archive : INFOPACK.ZIP
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 .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

;

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.
TESTDRV Test Utility - Copyright (C) Microsoft Corp. 1990. All rights reserved - page {page|3}


Microsoft MS-DOS CD-ROM Extensions
TESTDRV Test Utility
15 August 1990


TESTDRV Test Utility - Copyright (C) Microsoft Corp. 1990. All rights reserved - page {page|1}





  3 Responses to “Category : Recently Uploaded Files
Archive   : INFOPACK.ZIP
Filename : TESTDRV.TXT

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: http://www.os2museum.com/wp/mtswslnk/