Customized CHKDSK Needed with Third-Party RAM Disk

ID Number: Q50271

4.01

MS-DOS

Question:

The version of CHKDSK included with MS-DOS Version 4.00 checks the OEM

ID and version number of RAM disks and expects to find a particular

RAMDRIVE.SYS defined value. This precludes CHKDSK working with

third-party RAM disk drivers. How can OEM vendors make CHKDSK work on

third-party RAM disk drivers?

Response:

CHKDSK must be used on a FAT directory, and not on a network drive (it

does INT 25Hs). To figure out what kind of drive it is on, CHKDSK does

the following:

1. The drive is checked to see whether or not it is a network drive.

If it is, CHKDSK quits.

2. If it isn't a network drive, CHKDSK does a generic IOCtl call to

get the device parameters. If this call doesn't fail, CHKDSK goes

on and works correctly. If the call does fail, CHKDSK reads in the

boot sector off of the disk using INT 25H.

3. If the INT 25H fails, CHKDSK ends with an error. If it succeeds,

CHKDSK checks the OEM name in the header.

RAMDRIVE.SYS does not support the IOCtl; therefore, the RAMDRIVE check

was put in CHKDSK so that CHKDSK would work with RAMDRIVE.

This is a lack of robustness in RAMDRIVE that was taken into

consideration in CHKDSK. Third-party RAM disk vendors either need to

include the IOCtl call in their code, or they need to write their own

version of CHKDSK.

This is not an unreasonable thing to expect of a driver that is

supposed to be emulating a true disk, although it does help to be able

to write both programs. Third-party vendors should write a CHKDSK

program that works on both standard drives (floppies, fixed, etc.) and

their own RAM disk so that their version of CHKDSK can replace the

standard version of CHKDSK. This is how the Microsoft version of

CHKDSK works: it supports all drives, plus our own RAM disk.