On 2 Sep 2001, at 3:35, Howard Schwartz wrote:
>> As MS-Windows and other OSes
>> advance, more computer users are likely to have no DOS-readable FAT16 partition.
>> With MS-Windows, the entire hard disk may be in one FAT32 or NTFS partition, and
>> there may be no real DOS at all in Win NT, 2000 or XP. Linux/Unix servers also
>> might have no DOS at all, and then there are the non-i386 CPUs such as PowerPC,
>> Alpha, Ultra Sparc and others.
>
>As I recall worm's emergency boot disk uses DOS 7.1 precisely because it
>runs on FAT 32 partitions. I believe, DOS 7.1 - the shell and 2 hidden
>files will run all DOS 6.x software.
>
>However, I do not quite understand why DOS 6.22 or less can not be
>installed on a FAT 32 partitioned disk. The does files are just files
>with one's and zeros in it. On the disk level, do the FAT tables of
>a FAT 32 partition know or care what kind of files get stored on the
>disk? I thought all the disk had to worry about is keeping track of
>which directories and files are on which clusters of the disk.
Unfortunately, it's DOS that has to worry about keeping track of the
directories and files are on which clusters of the disk. This
information is stored in the FAT on the disk. And versions of DOS
before 7.1 just can't read the FAT on a FAT32 disk, because the fields
in which the data is written in the FAT are laid out differently.
All versions of DOS do know how to read FAT12 and FAT16 directory
structures. Typically, FAT12 is used on floppy disks, where 12 bits
are enough to designate all the possible places data can be stored on
the disk, and FAT16 on "standard FAT" hard drives, where 16 bits can
indicate the max. number of clusters.
>I must be wrong somehow. Could someone enlighten me about the connections
>or requirements between an OS and a disk partitioning system? Ah, I
>just figured out something obvious: Clearly, the boot sector information
>and file allocation table on disk are written in some kind of binary
>language code. So I suppose, for instance, only windows NT knows how
>to read the disk information stored on a NTFS partitioned disk. Is that
>the main problem?
Here's a couple of references. Look particularly for the definitions
of clusters, at the ends of the two pages. From these links, you can
see that the infomation for each directory entry is laid out
differently - 32 bits of address per cluster for FAT32, only 16 bits
per cluster for FAT16.
http://www.teleport.com/~brainy/fat16.htm
http://www.teleport.com/~brainy/fat32.htm
NTFS (NT, 2000), ext2 (Linux), etc. all store their equivalents of the
FAT in different formats and areas on the disk, so DOS just doesn't
understand where to even start looking for the FAT or directory on
those disks. DOS simply doesn't contain the code necessary to access
disks formatted with those file systems.
It would be possible to write system-level drivers which could allow
DOS access to those file systems. Such a device driver could be loaded
in CONFIG.SYS to provide an interface for DOS to work with, to access
these other types of file systems. It would be pretty low-level work,
though. Perhaps I'll tackle it when I've got a free year or two.
*grin*
Hope this helps,
Anthony J. Albert
P.S.
I have started work on a similar device driver to allow use of a solid-
state disk with an old TRS-80 Model 4, running LS-DOS (no relation to
MS-DOS). The solid-state disk is constructed from 32KB and 64KB static
RAM, removed from defunct 386 and 486 PCs. My current design is to
provide a whopping 256KB of storage! (As compared to the ~180KB
storage on a typical, SSDD 5.25" diskette that the system uses.) At
this point, I'm past the design stage, and I'm working on acquiring the
parts I need to build this, and hoping to send out my orders for parts
within the next week or two.
===========================================================
Anthony J. Albert [EMAIL PROTECTED]
Systems and Software Support Specialist Postmaster
Computer Services - University of Maine, Presque Isle
"Civilization is just a slow process of learning to
be kind." - Charles L. Lucas
To unsubscribe from SURVPC send a message to [EMAIL PROTECTED] with
unsubscribe SURVPC in the body of the message.
Also, trim this footer from any quoted replies.
More info can be found at;
http://www.softcon.com/archives/SURVPC.html
