177 lines
7.2 KiB
Plaintext
177 lines
7.2 KiB
Plaintext
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
|