pete@Octopus.COM (Pete Holzmann) (09/27/89)
I've found a bug in IBM PC-DOS 3.30, which may also exist in later versions
(although I haven't checked).
The Bug: If you increase the # of files available to a program (using Int 21
function 67h), DOS allocates a 64K+ chunk of ram to hold the information,
rather than the few bytes it really needs (really only needs 1 byte per
file). This function works just fine under MSDOS.
Questions:
- Has anybody else run across this already?
- Is it known officially by IBM or Microsoft?
- Is there an official fix?
- Has it been fixed in versions after 3.30?
Also, is there any way for my program to distinguish between PCDOS 3.30
and MSDOS 3.30, so I'll know whether it is ok to use function 67h?
Thanks!
Pete
--
Peter Holzmann, Octopus Enterprises |(if you're a techie Christian & are
19611 La Mar Ct., Cupertino, CA 95014 |interested in helping w/ the Great
UUCP: {hpda,pyramid}!octopus!pete |Commission, email dsa-contact@octopus)
DSA office ans mach=408/996-7746;Work (SLP) voice=408/985-7400,FAX=408/985-0859krone@presto.ig.com (Larry Krone) (09/27/89)
In article <1989Sep26.202524.27381@Octopus.COM> pete@octopus.COM (Pete Holzmann) writes: >I've found a bug in IBM PC-DOS 3.30, which may also exist in later versions >(although I haven't checked). > >The Bug: If you increase the # of files available to a program (using Int 21 > function 67h), DOS allocates a 64K+ chunk of ram to hold the information, > rather than the few bytes it really needs (really only needs 1 byte per > file). This function works just fine under MSDOS. > Does anybody know if the product BTRIEVE put out by novell / softcraft is subject to this bug.... Thanx, Larry Krone KRONE@PRESTO.IG.COM
mshiels@tmsoft.uucp (Michael A. Shiels) (09/30/89)
This bug has to do with how many file handles you are allocating. If the bug exists for even numbers try allocating on odd number of handles. I just don't remember which way the bug worked. Sorry.