2 Suspected Bugs in MsDos v4.01
6/5/91
by
William S. Ataras III
'Discovered', tested and copyrighted 1991 by David M. Cox and William S. Ataras III.
See how to contact us at the end of this document.
We work with satellite imagery. This type of work commonly involves the manipulation of files between 1 and 200 megabytes in size. In the course of writing and copying such data, we believe we've run across 2 bugs. They are detailed below:
————————— Bug #1 —————————-
The included program 32MEG.ASM uses the following 4 Dos functions to create, write, and close 32MEG.DAT and exit:
3Ch - Create file handle. 40h - Write BUFSIZE bytes to file handle. 3Eh - Close file handle. Int 20h - Exit.
BUFSIZE is a symbol equate in 32MEG.ASM. The included files 2048.COM and 2000.COM are the compiled versions of 32MEG.ASM with BUFSIZE set to 2048 and 2000 respectively.
The assembly source was compiled and linked with Borland's assembler TASM v1.01 and linker TLINK v2.0 as follows:
tasm 32meg tlink /t 32meg
I tested the programs in the root directory of my C: which is a Connor CP-3104 106meg harddrive. There was no AUTOEXEC.BAT and the CONFIG.SYS looked like this:
files = 30 buffers = 30 lastdrive = z shell = c:\command.com /p /e:1024
My computer is a 386 20mhz with 4megs of ram, 3megs extended. The same results occured with a similar test on a completely different 386 machine and different harddrive.
A run of Norton 4.50 DI.EXE produced:
DI-Disk Information, Advanced Edition 4.50, (C) Copr 1987-88, Peter Norton
Information from DOS Drive C: Information from the boot record
——————————————————————————-
system id 'MSDOS4.0'
media descriptor (hex) F8
2 drive number
512 bytes per sector 512
4 sectors per cluster 4
2 number of FATs 2
512 root directory entries 512
214 sectors per FAT 214
54,722 number of clusters
number of sectors 219,351
1 offset to FAT 1
429 offset to directory
461 offset to data
sectors per track 33
sides 8
hidden sectors 33
Theoretically, the program should generate a dummy file well over 32 megabytes in length. You must have about 41 megs free on your disk. It works fine when the BUFSIZE equate is 2048; the resulting 32MEG.DAT is 41,943,040 bytes long. However, when BUFSIZE is changed to 2000, 2 things happen. First, it takes nearly twice as long to write the file. Given the fact that Dos clusters and BIOS disk sectors are always powers of 2, it is not unreasonable to expect that some additional magic must happen behind the scenes when such abitrary and rather inconsiderate byte counts are written. BUT, this was not expected; The resulting file should have been 43,008,000 bytes long. It was 33,554,000 bytes long; the highest even multiple of 2000 below 32 megabytes.
A run of 'CHKDSK /F' produced 'Allocation error in C:\32MEG.DAT, size adjusted'. Another 'DIR' told me the file was 43,008,000 bytes long as it should have originally been.
————————— Bug #2 —————————-
This problem involves the ramdisk provided by the MsDos 4.01 driver RAMDRIVE.SYS.
I tested this in the root directory of my C: which is a Connor CP-3104 106meg harddrive. There was no AUTOEXEC.BAT and the CONFIG.SYS looked like this:
device = c:\dos\ramdrive.sys 2048 128 64 /e files = 30 buffers = 30 lastdrive = z shell = c:\command.com /p /e:1024
My computer is a 386 20mhz with 4megs of ram, 3megs extended. The same results occured with a completely different 386sx 16mhz with 4megs, 3megs extended and different harddrive.
The rawdisk was D:.
A run of Norton 4.50 'DI.EXE D:' produced:
DI-Disk Information, Advanced Edition 4.50, (C) Copr 1987-88, Peter Norton
Information from DOS Drive D: Information from the boot record
——————————————————————————-
system id 'RDV 1.20'
media descriptor (hex) F8
3 drive number
128 bytes per sector 128
4 sectors per cluster 4
1 number of FATs 1
64 root directory entries 64
48 sectors per FAT 48
4,079 number of clusters
number of sectors 16,384
1 offset to FAT 1
49 offset to directory
65 offset to data
sectors per track 1
sides 1
hidden sectors 0
I had an arbitrary image file DATA.DAT in C:\. DATA.DAT was 1,300,480 bytes long. Running the following batch file over and over produced random lost clusters consistently on the 2nd attempt.
copy data.dat d: del d:data.dat dos\chkdsk d:
Changing the 2048 in CONFIG.SYS to 2047 to look like this…
device = c:\dos\ramdrive.sys 2047 128 64 /e files = 30 buffers = 30 lastdrive = z shell = c:\command.com /p /e:1024
made the bug go away. I was able to run the same batch 'forever' without a hitch (as I should have happened previously).
————————— Summary —————————
Feel free to try these tests on your machine if you have MsDos 4.01. I'm sure you'll get similar results. I'd be interested to know if you didn't.
Contact us by:
Leave a message to Bill Ataras on Ed's BBS at (408)-384-3658.
OR Write:
Bill Ataras 38 Village Dr. #8 Carmel Valley, Ca. 93924