On Sun, 29 Aug 2004 22:33:01 GMT, Lancer wrote in
. com:

snip
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?


No, it shouldn't. There are no VFAT or virtual drivers loaded.


What I mean is, the disk is configured for use with a VFAT driver.
Doesn't that cause compatibility problems when working under the FAT
under DOS?






-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

On Sun, 29 Aug 2004 15:45:23 -0700, Frank Gilliland
wrote:

On Sun, 29 Aug 2004 22:33:01 GMT, Lancer wrote in
.com:

snip
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?


No, it shouldn't. There are no VFAT or virtual drivers loaded.


What I mean is, the disk is configured for use with a VFAT driver.
Doesn't that cause compatibility problems when working under the FAT
under DOS?



Frank;
The way I understand it, is that the disk is configured or uses
FAT. VFAT serves as an interface between applications and the FAT.
So there shouldn't be any compatibilty problems when running DOS
programs.

On Sun, 29 Aug 2004 23:16:36 GMT, Lancer wrote in
. com:

On Sun, 29 Aug 2004 15:45:23 -0700, Frank Gilliland
wrote:

On Sun, 29 Aug 2004 22:33:01 GMT, Lancer wrote in
s.com:

snip
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?


No, it shouldn't. There are no VFAT or virtual drivers loaded.


What I mean is, the disk is configured for use with a VFAT driver.
Doesn't that cause compatibility problems when working under the FAT
under DOS?



Frank;
The way I understand it, is that the disk is configured or uses
FAT. VFAT serves as an interface between applications and the FAT.
So there shouldn't be any compatibilty problems when running DOS
programs.


Ok.... but if the FAT is set for short (8.3) filenames while the VFAT
uses long filenames, there are going to be short filenames that are
identical in the same directory; i.e, under VFAT;

pornpic001.jpg
pornpic002.jpg
pornpic003.jpg

....but under DOS FAT they are listed as:

pornpic~.jpg
pornpic~.jpg
pornpic~.jpg

So how do you discriminate between these identical filenames from DOS
without the VFAT driver? Does the VFAT driver maintain a directory
index file?





-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

"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

"Frank Gilliland" wrote in message
...
On Sun, 29 Aug 2004 23:16:36 GMT, Lancer wrote in
. com:

On Sun, 29 Aug 2004 15:45:23 -0700, Frank Gilliland
wrote:

On Sun, 29 Aug 2004 22:33:01 GMT, Lancer wrote in
s.com:

snip
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?


No, it shouldn't. There are no VFAT or virtual drivers loaded.


What I mean is, the disk is configured for use with a VFAT driver.
Doesn't that cause compatibility problems when working under the FAT
under DOS?



Frank;
The way I understand it, is that the disk is configured or uses
FAT. VFAT serves as an interface between applications and the FAT.
So there shouldn't be any compatibilty problems when running DOS
programs.


Ok.... but if the FAT is set for short (8.3) filenames while the VFAT
uses long filenames, there are going to be short filenames that are
identical in the same directory; i.e, under VFAT;

Frank, the FAT doesn't have anything to do with the long or short file
names. The Windows OS does it by first building a standard DOS directory
entry for any file. After this is one or more directory entries where the
attribute bits have an invalid setting are built. That's how the Windows OS
can tell the difference between the two. DOS just ignores the invalid
directory entries. Each of these directory entries holds 11 characters of
the long file name. The reason for this is the directory entry is still a
DOS directory entry with room for only a 8 dot 3 file name. For example if
the long file name has a total of 45 characters in it you would have the
normal DOS directory entry with it's 8 dot 3 file name followed immediately
by 5 more DOS directory entries with the special invalid attribute bits
settings. You would need 5 because 4 would only hold a total of 44
characters. The OS also keeps a count of how many of these special DOS
directory entries there are. If this gets messed up that's when the OS
complains about a miss association between the long and short file names.
This is a real hack job by Microsoft, waste full of space, and elegant it's
not, but it does work.

--
Leland C. Scott
KC8LDO

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

On Sun, 29 Aug 2004 23:38:05 -0500, itoldyouiamnotiamnotgeorge
wrote:

Lancer wrote in
news


Frank;
The way I understand it, is that the disk is configured or uses
FAT. VFAT serves as an interface between applications and the FAT.
So there shouldn't be any compatibilty problems when running DOS
programs.


tHANKS rANDY

Sorry paranoid whiskey head, I am not Randy.

On Mon, 30 Aug 2004 03:27:55 -0400, "Leland C. Scott"
wrote in :

snip
Frank, the FAT doesn't have anything to do with the long or short file
names. The Windows OS does it by first building a standard DOS directory
entry for any file. After this is one or more directory entries where the
attribute bits have an invalid setting are built.


So THAT'S how it works.....


This is a real hack job by Microsoft, waste full of space, and elegant it's
not, but it does work.


Classic MS kludge-ware. But that's what we have learned to expect from
Uncle Bill. And did I hear wrong or is MicroSquash working on a Linux
rip-off, too?





-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

On 30 Aug 2004 14:14:01 GMT, Steveo
wrote:

itoldyouiamnotiamnotgeorge wrote:
Lancer wrote in
:

tHANKS rANDY

Sorry paranoid whiskey head, I am not Randy.

Sorry Crackhead, you sure are Randy Chapman.

Why so bitter, humpty dumpty?

Sounds like he's hungover again.

On Mon, 30 Aug 2004 08:57:03 -0500, itoldyouiamnotiamnotgeorge
wrote:

Lancer wrote in :




tHANKS rANDY

Sorry paranoid whiskey head, I am not Randy.


Sorry Crackhead, you sure are Randy Chapman.

Sorry dip****, I have never even tried crack.

Frank Gilliland wrote:
So how do you discriminate between these identical filenames from DOS
without the VFAT driver? Does the VFAT driver maintain a directory
index file?

They didn't teach you that in grunt skool, welfare boi?

--
_____________________________________
Not to him who is offensive to us are we most
unfair, but to him who doth not concern us at all"
-- Friedrich Nietzsche