PRB: Cannot Read Red Book Audio Sectors in Windows 95, Windows 98, and Windows Me (180115)
The information in this article applies to:
- Microsoft Win32 Application Programming Interface (API), when used with:
- the operating system: Microsoft Windows 95
- the operating system: Microsoft Windows 98
- the operating system: Microsoft Windows Millennium Edition
This article was previously published under Q180115 SYMPTOMS
Some applications read raw sectors from compact discs by calling the
MSCDEX/CDFS Send Driver Request function (Int 2Fh, function 1510h) to issue
a Read Long command (command code 128) to the CD-ROM driver.
The Read Long command correctly reads sectors on ISO 9660 and High-Sierra
formatted discs. However, the Read Long command does not read sectors from
Red Book Audio discs or sectors from the audio session of a multisesson
disc. On such discs, the Read Long command returns a status word of 8102h,
which means that the command completed, but there was a "Device Not Ready"
error.
CAUSE
The Microsoft Windows 95, Windows 98, and Windows Millennium Edition (Me) CD-ROM file system driver (CDFS) supports the Read Long command only for ISO 9660 and High-Sierra discs (data discs). The Windows 95 CDFS does not support the Read Long command for Red Book Audio discs or the audio session of multisession discs.
RESOLUTION
Although the Windows 95, Windows 98, and Windows Me CDFS does not support reading Red Book Audio sectors, the Windows IO Subsystem does. It is possible to bypass CDFS by calling the IO Subsystem directly from a virtual device driver (VxD) or by calling WinASPI32.
Although applications cannot call IO Subsystem functions directly, they can
call VxDs that call IO Subsystem functions. Therefore, to read audio
sectors, you can write a VxD for your application to call. [Win32
applications use the DeviceIoControl() API to call VxDs; 16-bit Windows
applications use interrupts.] When called by your application, your VxD
should submit IOR_READ commands using the IORF_AUDIO_DATA_READ flag.
With this approach, your application can use drive letters, and the VxD
will correlate the drive letter to IOS DCB. The I/O subsystem can then
handle building and translating appropriate READ commands for the specific
CD-ROM drive.
Alternatively, if you do not want to write a VxD, your application can call
WinASPI32 to build raw READ compact disc command descriptor blocks (CDBs)
(for ATAPI drives) or READ_CDDA CDBs (for SCSI drives) to submit to the
drive. The drawback with this approach is that ASPI cannot correlate the
ASPI device with its drive letter; therefore, the application must
determine which READ command is correct for the CD-ROM drive.
MORE INFORMATIONWindows CD-ROM Support
Windows CD-ROM support consists of the Compact Disc File System
(Cdfs.vxd), and the IO Subsystem. CDFS is the protected-mode replacement
for Mscdex.exe; it supports the MSCDEX Int 2Fh interface so that 16-bit
Windows and MS-DOS-based applications that call Mscdex.exe functions will
work unmodified in Windows 95.
The IO Subsystem is a layered set of virtual device drivers that forms the
low-level support for CDFS and other file systems (VFAT). In response to Int 2Fh MSCDEX function calls, CDFS calls the IO Subsystem to access the physical drive.
The IO Subsystem also handles all file system related calls that are
destined for the CD-ROM drive. For example, requests to open a file on a
compact disc and read its contents goes from the application to the IO
Subsystem, which talks to the drive to get the data from the disc.
Because CDFS calls the IO Subsystem, and the IO Subsystem is layered,
Windows was designed such that the IO subsystem can use either the built-in virtual device drivers to support CD-ROM drives, or an OEM-supplied real-mode CD-ROM driver. Thus, if a given CD-ROM drive is not supported directly by the protected-mode IO Subsystem components, it still may be used by Windows through the OEM-supplied driver.
Send Driver Request Behavior
Similar to MSCDEX, CDFS supports a special function, Send Driver Request
(Int 2Fh, function 1510h), which passes application requests to the IO
Subsystem. The purpose of this function is to allow applications to issue
commands that are not supported by other MSCDEX functions (Int 2Fh,
functions 1500h-1509h, 150Bh-150Fh). These commands usually include
optional behavior that is specific to the capabilities of the drive, such
as the "close tray" command supported by tray-based drives.
CD-ROM driver software is not required to support every command that can be
sent via Send Driver Request. Usually, a CD-ROM driver supports a
particular command only if the specific device for which it was designed
supports the feature. If a CD-ROM driver does not support a particular
command, it generally returns with a status word of 8102h, which means "the
command completed with a Device Not Ready error."
CDFS can also return a status word of 8102h to signal that it did not pass
the request to the CD-ROM driver.
Read Long Command Behavior
Applications issue the Read Long command (command code 128) by calling the
MSCDEX Send Driver Request function (Int 2Fh, function 1510h). The Read
Long command is designed to read "raw" (2352-byte) or "cooked" (2048-byte)
sectors in HSG or REDBOOK addressing modes. (When reading raw sectors, only
one sector at a time can be read.)
Windows only supports the Read Long command for reading raw and
cooked sectors from ISO 9660 and High-Sierra discs in the HSG addressing
mode.
Modification Type: | Minor | Last Reviewed: | 9/27/2004 |
---|
Keywords: | kbAPI kbKernBase kbnofix kbprb KB180115 |
---|
|