"Frank Gilliland" wrote in message
...
On Sun, 29 Aug 2004 15:34:31 GMT, Lancer wrote in
. com:

On Sun, 29 Aug 2004 01:20:38 -0400, "Leland C. Scott"
wrote:

I didn't use any OS calls at all. The only BIOS functions I used were
direct
calls to read/write absolute disk sectors. Everything else I had to
write
from scratch. As simple as the DOS file system was there was still a lot
to
handle. What made thing more interesting was all I had to work with was
a
Windows 98 machine. That made thing more complicated because Windows
always
wanted to create long file names which messed things up a bit when you
format a disk. I had to put extra routines in to the code to filter that
crap out so when the disk was defragmented I had wiped all the Windows
file
system extensions out, thus generating a valid DOS disk.


Windows 98 runs on a DOS kernel, so all windows 98 systems run on a
"valid" DOS disk. Edit your msdos.sys and turn your GUI off. Or just
make yourself a boot disk and format the drive.


Doesn't it still run on virtual FAT even without the GUI?

Yes it does use a FAT, File allocation Table, to manage the storage space on
the disk. Windows 95, 98 and DOS use it. The storage space is managed as one
or more disk sectors call a "cluster". The cluster number has to be mapped
to absolute disk sectors. The mapping varies depending on the size of the
disk. The FAT is nothing more than a table that maps one cluster to the
next. The file directory entry has the starting cluster number in it. The
way it works is the OS reads the starting cluster number out of the file
directory header. The numeric value points to a sequential entry in the FAT.
The OS then reads that value which again points to another entry in the FAT.
This proceeds until one of several special values is read, one of which
signals the value just read as being the last cluster in the chain. The
numeric value of the entries is also the cluster number of the data stored
on disk. Thus by following the chain of cluster numbers the OS is able to
read the file's data off of the disk in the correct order, even if the
clusters are not in sequential order on the disk. When this mapping gets
screwed up that's when you get messages from the OS about lost or cross
linked "chains". You may get more that one file that have a common cluster
mapped to it which should never happen, crossed linked files, or you have a
chain of clusters on the disk for which there is no file directory entry
with a staring cluster pointing to the beginning of the chain, i.e. lost
chains. The OS tries to clean up the mess by marking the clusters in the
lost chains as being free disk space. For crossed linked files the OS just
picks one file out of the two or more crossed linked and fixes the FAT so
that the cluster(s) in common are mapped to only one file while removing it
from the chain for the other files. There is no guarantee the OS is going to
pick the right file to do this either.

The other thing the FAT table makes hard is file un-deletion and making sure
nobody can read the deleted file's data. When you erase a file all that
happens is the OS makes the file's directory header as being unused by
changing some byte(s) in the header. The starting cluster number is not
zeroed out either. The OS also runs through the file's allocation chain
marking each entry with another of those special values that signals the OS
that the cluster is available for data storage. The actual data in the
cluster is not over written until it is used to hold the data from another
file. It's still there if you use a disk sector viewing utility. That's why
you see those utilities for scrubbing the disk of data from deleted files.
They write random data to the free clusters to make sure anything there is
unreadable.

Un-deleting a file is at best a pain and doesn't always work. The OS can
store the file's data in any available clusters on the disk. There is no
guarantee that the clusters will be used in order, or even sequentially, on
the disk. Thus any file's data that spans more that one cluster you normally
have to help the un-delete utility by looking at the data in the cluster and
deciding if this should be included in the reconstructed FAT chain. If the
data is not in human readable format you're screwed. If you're lucky the OS
tries to allocated the clusters from low to high numbers so the un-deleted
utility may try looking for the next free cluster on the disk assuming that
is was likely used by the file. It does this until the clusters have enough
storage space to hold the data as specified by the file size in the old
directory header. Some times the last method works, and some times it don't.


--
Leland C. Scott
KC8LDO

Wireless Network
Mobile computing
on the go brought
to you by Micro$oft