From: dg AT dcs DOT st-and DOT ac DOT uk
Message-Id: <12666.9702022346@dufftown.dcs.st-andrews.ac.uk>
To: opendos AT mail DOT tacoma DOT net
Subject: Re: [opendos] OpenDOS + Win95 w/FAT32? 
In-Reply-To: grendel@ananke.amu.edu.pl's message of Sun, 02 Feb 97 20:39:42 
 +0100.
	     <199702022234 DOT XAA25970 AT math DOT amu DOT edu DOT pl> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 02 Feb 97 23:46:21 +0000
Sender: owner-opendos AT mail DOT tacoma DOT net
Precedence: bulk

>> We already have an IFS layer. CD drivers, network devices, InterLink all use
>> it. Compatability here isn't a problem. Nearly everything will run from one
>Yes, and each has it's own API - not a way to go.

No, there *is* a single API. The file manipulation interrupts. There has to 
be, or else programs would not be able to use them. Think --- programs see 
things like a CD or a network volume as drives, just like any other. There 
*must* be a common interface or this wouldn't work.

>> of these --- the number of programs that *have* to run on a FAT drive will
>> be very small to non-existant.
>Don't bet on that. You have to think about the weakest points when writing 
>system software, not about the newest ones. At least if we want OpenDOS to be 
>commonly used.

How many programs do you know that won't run of CD? CD's aren't FAT, they're 
ISO9660, which is extremely different from FAT. And how about network drives? 
They're even stranger. The Linux emulated file system under DOSEMU is a good 
example of a file system that uses this API, and I can only recall *one* of my 
programs that wouldn't run straight off (GEOS). I had to reconfigure it so 
that it used the network FS driver instead. Then it worked fine.

If someone wants to delete a file, he *doesn't* start directly modifying 
sectors. He uses the `delete file' interrupt.

>> This doesn't look too hard, now, does it? Come on, someone could write a TSR
>> that implements it on top of FAT, either as VFAT or using look-up files
>> without much difficulty.
>It's not that hard to do so but it's only a *hack* not a *solution*. Until 
>there's some clear IFS (non-M$) standard, nothing can be done.

Precisely. It's a hack. It allows long filenames on a file system that doesn't 
support it. VFAT is also a hack, and, IMHO, a very nasty one.

The benefit of the TSR is that it allows *everyone* to switch to the 
long-filenames API rather than the 8.3 API so that when real file systems are 
implemented later, they will be taken advantage of.

-- 
------------------- http://www-hons-cs.cs.st-and.ac.uk/~dg --------------------
   If you're up against someone more intelligent than you are, do something
    totally insane and let him think himself to death.  --- Pyanfar Chanur
---------------- Sun-Earther David Daton Given of Lochcarron ------------------