Date:	Wed, 4 Jun 1997 12:13:34 +0200 (MET DST)
From:	Mark Habersack <grendel AT hoth DOT amu DOT edu DOT pl>
Reply-To:	grendel AT hoth DOT amu DOT edu DOT pl
To:	Jonathan Purvis <jap5 AT waikato DOT ac DOT nz>
cc:	Wojciech Galazka <wgalazka AT chem DOT uw DOT edu DOT pl>, opendos-developer AT delorie DOT com
Subject:	Re: Anyone working on ext2 support for OpenDOS?
In-Reply-To:	<Pine.LNX.3.91.970603035756.32740A-100000@lab5-2.cs.waikato.ac.nz>
Message-ID:	<Pine.BSI.3.96.970604120220.6532D-100000@hoth.amu.edu.pl>
Organization:	PPP (Pesticide Powered Pumpkins)
MIME-Version:	1.0

On Tue, 3 Jun 1997, Jonathan Purvis wrote:

> On Mon, 2 Jun 1997, Wojciech Galazka wrote:
> 
> > Has anyone been working on ext2 filesystem 
> > support for OpenDOS?
> 
> I was planning to.  But i got a bit way-layed by the fact that i can't 
> find any docs on IFS.  Now that the source is out, i might start up 
> again.  If i can ever get it to compile...
I stareted to write VFAT & ext2fs drivers (they are supposed to share 90% of
the code, you know) but stopped for much the same reason - no IFS docs. To
create such from the kernel sources is much work and takes much time - if
someone has done it, please share your knowledge! While IFS seems a good way
to add ex2fs and other non-dos FS support, it's a bit too much for providing
VFAT which is supposed to sit on top of int 21h and just export the WIndoze 95
services. There's no need to install another block device driver.
At first I started to write aa VFAT TSR using NASM, then (due to lack of
debugging support) I switched to C and the free BCC compiler - works ok, but
the TSR is read-only. There is no way to provide directory allocation services
from that level - it would require fiddling with the DOS kernel image in
memory, which I would like to avoid for the sake of M$-DOG compatibility.
The problem is the way VFAT stores LFNs and the way DOS extends directories
when needed:

 - VFAT stores all LFN parts before the SFN dirent. To allocate these from
inside the TSR I need to create all the structures by hand. Everything's fine
as long as I don't have to reach to FAT to extend the directory allocation
chain. When I do it by hand DOS sooner or later complains about Bad FAT memory
image, allocation errors, lost clusters etc. A quick look at the kernel
sources proves that much information is cached and should be updated when
changed from outside the kernel. It is possible to make calls into FDOS the
way command.com does it, but this would tie the TSR not only to OpenDOS
solely, but also to its particular version - every change in kernel layout
would require changing the TSR. The solution which comes to mind is to modify
FDOS and add a native support for VFAT there. That would require much less
work on the FS part, but somebody would have to modify command.com and some
other parts of the kernel. I can do the FDOS part - who's gonna do the rest?

As to ext2fs support - let's use IFS, but we need some documentation. Anyone?

- Raw text -