💾 Archived View for spam.works › mirrors › textfiles › computers › 401bugs.txt captured on 2024-02-05 at 11:22:11.
⬅️ Previous capture (2023-06-14)
-=-=-=-=-=-=-
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