Date: Wed, 4 Jun 1997 12:13:34 +0200 (MET DST) From: Mark Habersack Reply-To: grendel AT hoth DOT amu DOT edu DOT pl To: Jonathan Purvis cc: Wojciech Galazka , opendos-developer AT delorie DOT com Subject: Re: Anyone working on ext2 support for OpenDOS? In-Reply-To: Message-ID: Organization: PPP (Pesticide Powered Pumpkins) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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?