Microsoft KB Archive/50271

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.