SvarDOS
EDR-DOS and MS ScanDisk (Win98 SE)
Hello,
MS ScanDisk seems to have some problems with EDR-DOS.
FAT16 drives are "scanned" ok, but FAT32 drives are not accepted. Error msg is:
FAT16 drives implemented as RAM disks ( using J.R. Ellis' RDISK.COM ) are rejected:
That does not look good! Thanks for reporting. Is the RDISK.COM RAM disk rejected under the EDR kernel only or also under MS-DOS?
Is the RDISK.COM RAM disk rejected under the EDR kernel only or also under MS-DOS?
Scandisk (DOS variant) from Win98 SE running under "MS-DOS 7.1" has no problems with RDISK ramdisks.
I performed a test on a freshly formatted FAT32 drive (via FreeDOS format). I can confirm that even on an empty partition MS SCANDISK fails under the EDR kernel.
Initial analysis of this issue revealed that SCANDISK accesses the drive via INT 25H under EDR, while it accesses it via INT21,7305H under Win98 boot disk. As this is a FAT32 drive, access via INT21,7305H is correct. And as MS SCANDISK uses INT 25H under EDR, it may be that SCANDISK wrongly detects the drive as FAT16.
I have not figured out the exact cause of this yet, but what gets returned by the relevant DOS calls like INT21,32H etc. should be compared between the two kernels. This likely reveals some differences.
I got SCANDISK to work with the EDR kernel.
I used interc3 to monitor the DOS calls performed by SCANDISK and compared them between MS-DOS 7.1 and the EDR kernel. I noticed that SCANDISK makes use of INT21.730[2,3,5] when running under MS-DOS, but not when run under EDR DOS.
I then changed the version returned by EDR DOS via INT21.30 and INT21.3306 from 6.00 to 7.10. With this change, SCANDISK works and uses the INT21.73xx subfunctions supported by the EDR kernel. So luckily this problem did not arise from an incompatibility between the MS-DOS and EDR data structures.
Monitor outputs (interesting part starts at line 260): DRFAT32.TXT, MSFAT32.TXT
I used an already uncompressed SCANDISK.EXE (it is packed with PKLITE).
Regarding the still failing SCANDISK on a RDISK device: on EDR kernel this seems to fail after SCANDISK issues an INT21.440D,084A (lock logical device). The lock logical device call is currently passed by the EDR kernel to the device driver, and the EDR disk driver implements this call (always returning success). However, the RDISK driver does not.
FreeDOS on the other hand does not pass this call to the driver but instead directly returns a "fake success" as part of its INT21 handler. This MIGHT also handled like this under MS-DOS 7.1.
So chances are that adapting the EDR kernel according to this behaviour will fix the issue.
Regarding the still failing SCANDISK on a RDISK device: on EDR kernel this seems to fail after SCANDISK issues an INT21.440D,084A (lock logical device). The lock logical device call is currently passed by the EDR kernel to the device driver, and the EDR disk driver implements this call (always returning success). However, the RDISK driver does not.
FreeDOS on the other hand does not pass this call to the driver but instead directly returns a "fake success" as part of its INT21 handler. This MIGHT also handled like this under MS-DOS 7.1.
Yes, I think the LFN drive locking is handled by the kernel, not passed down to the device driver. Would have to look into it to make sure though.
I traced lCDebugX's call on w 100 A: 0 1 and the 084Ah lock call is indeed done by the kernel, not passed to the block device driver.
Yes, I think the LFN drive locking is handled by the kernel, not passed down to the device driver. Would have to look into it to make sure though.
Is this really for LFN?
As a test I added the drive logging to the f440D handler routine, and this indeed fixes the RDISK problem. So on the other hand this would mean that it should be safe to remove the locking functions from the device driver in disk.asm.
Yes, I think the LFN drive locking is handled by the kernel, not passed down to the device driver. Would have to look into it to make sure though.
Is this really for LFN?
Yes:
- Drive locking and the LOCK and UNLOCK commands were introduced with MSW 95 / MS-DOS v7.00.
- It affects FAT12 and FAT16 drives, not only FAT32.
- It is available using the IOCTL category code 08h (FAT12/FAT16 drive), not only 48h (FAT32 drive).
- FAT32 drives are protected from being accessed by older software on int 25h/26h by rejecting these interrupts altogether, only allowing access using 21.7305.
As a test I added the drive logging to the f440D handler routine, and this indeed fixes the RDISK problem. So on the other hand this would mean that it should be safe to remove the locking functions from the device driver in disk.asm.
Yes.
Drive locking and the LOCK and UNLOCK commands were introduced with MSW 95 / MS-DOS v7.00. It affects FAT12 and FAT16 drives, not only FAT32. It is available using the IOCTL category code 08h (FAT12/FAT16 drive), not only 48h (FAT32 drive). FAT32 drives are protected from being accessed by older software on int 25h/26h by rejecting these interrupts altogether, only allowing access using 21.7305.
So far I understand this. But I do not see the connection to long file name support (this is meant by LFN?). Isn't the need for locking merely a consequence of the multitasking occuring under Win95?
So far I understand this. But I do not see the connection to long file name support (this is meant by LFN?).
Yes, LFN means Long File Name, introduced by MSW 95.
Isn't the need for locking merely a consequence of the multitasking occuring under Win95?
No, the drive locking is also enforced under MS-DOS v7.xx without the MSW 95/98 multitasker kernel loaded. The idea is to gatekeep direct disk writes from older, LFN-unaware tools. When writing directories there is a risk that the tools would corrupt existing LFNs, or they could get confused by LFN entries mistaking them for volume labels or such. So all disk writes are blocked unless the application (IOCTL) or the user (LOCK command) specifically enables them. This signals that one is aware of LFNs and won't corrupt or misidentify them.