From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re:  Re: Unix Roots of DOS?
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Wed, 22 Jul 1992 16:02:13 GMT

In article <1992Jul22.035035.4407@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (Don Nichols (DoN.)) writes:
>In article <1992Jul20.140207.57357@cc.usu.edu> ivie@cc.usu.edu (CP/M lives!) writes:
>>In article <1992Jul20.165306.918@news.columbia.edu>, lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>> configurations.  Clearly, it has to be a DOS problem because in theory, the
>>> ROM in the XT controller is passed the same info either way.  When switching
>>> to an AT-type disk system, no problems were encountered.)
>>
>>The problem is the same one that RT-11, CP/M, and even OS/8 see. MS-DOS was
>>limited to a 16-bit block number (32M is 64K 512-byte blocks). RT-11 has
>>the same limit. CP/M is limited to 8M because it counts 128-byte blocks.
>>OS/8 is limited to about 2.5M because it only has 12 bits.
>
>	Of course, you could increase the size of the filesystem by making
>each logical block larger.  This, I think, is what was done in the Zenith
>version of MS-DOS 3.3+, which could handle at least an 80MB drive as a
>singel partition, but caused SYTOS to complain that it couldn't back up
>network drives.  Presumably, the structure of the FAT was sufficiently
>different so that SYTOS could recognize that it was confused.  I didn't
>bother looking into the details, becuase MS-DOS hasn't been the focus of my
>interests, ever.  (SSB's DOS-68 and DOS-69, Microware's OS-9, and various
>unix variants, yes. :-)

NEC DOS 3.30 does precisely that, except the maximum is double or 64 Megs per
partition, and formatters such as Ontrack System's Disk Manager have option
switches for these socalled "big" partitions where the logical block is 
larger, not the FAT size.  But, the problem is that this breaks enough programs
that it is unacceptable as you point out an example to.

But back to Compaq Dos 3.31:  This is a description of a program bug, not
a file-system limitation.  If you reconfigure the disk to partitions of
32 Megs/partition on the XT hardware, it works fine.  If you run it on
AT-style hardware it runs regardless of <32 Megs or >32 Megs/partition fine
there.  The only salient difference is that the XT-type has a ROM which the
main BIOS locates as an extension.  Virtually the same info is supposed to
be passed to the Int handler for these operations.  We are talking about
a reformatted disk with a minimal system moved to it in each of the four cases.
And even the one that flunks is addressable from a bootable floppy.  Further,
it's not a bug of it using a 286-only instruction because this is being tried
on the same 286 machine each time by changing disk controller cards.  The
machine in question usually has AT disk type NONE because there are no
disks under control of the BIOS and CMOS setup table.  This is perfectly
legitimate and the norm for XT-class machines.  And when the whole thing is
repeated under DOS 4.01 or newer, the problem disappears.  Since this was
the first attempt to accomplish this file-system, it is conceivable that
there is an interaction with the extension BIOS and the special-case check
for the larger FAT tables.  Note that this software was never meant to be
used with XT-class controllers and disks larger than 32 Megs so they probably
never tested it.  (I believe Compaq has no existent product that qualified
to exhibit the bug; perhaps the only way was to upgrade an existant older
machine's disk.)

cjl
Newsgroups: alt.folklore.computers