Message-Id: <199704170858.KAA08990@math.amu.edu.pl> Comments: Authenticated sender is From: "Mark Habersack" Organization: PPP (Pesticide Powered Pumpkins) To: Lorier Date: Thu, 17 Apr 1997 10:53:38 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Usage of directory entries Reply-to: grendel AT hoth DOT amu DOT edu DOT pl CC: Matthias DOT Paul AT post DOT rwth-aachen DOT de, opendos-developer AT delorie DOT com In-reply-to: <199704160755.UAA01841@buttons.ihug.co.nz> Precedence: bulk Once upon a time (on 16 Apr 97 at 20:55) Lorier said: > >We don't have to worry about that IMHO. I suppose that what's going to > >happen is that OpenDOS will have several installable drivers for several > >supported file systems. Since FAT32 is not really FAT we used to know and > >love ;-) we don't have to bother with this kind of compatibility. > > At the risk of introducing even more linux Bias into the list: Hmm... You cannot treat these two products separately. Caldera also has a product called OpenLinux, I *suspect* (it's my personal opinion, of course) that OpenDOS *might* be merget into OL as a native "emulator". > I think we should have a system for installing File systems. MSCDEX has > some funny scheme for using installable file systems, how it works I dont > know, but I think it overrides most of int 21h to do it. MSCDEX works on the network redirector interface which is an unnecesary complication of things. DOS 3.x+ has a DRIVER.SYS support interface built in. This interface allows you to create/mount any type of disk into the system. This approach is much easier than that of MSCDEX in which CD-ROM is being treated as a network drive with all disadvantages of such. > There is also some weird way that DBLSPACE/DRVSPACE have some weird scheme > working as an installable filesystem, I don't really know how stacker does > it (although I assume it's similar) They use some tricks to inject their code into the system (remember the DRVSPACE.BIN file?) and work as a replacement for the FS/DEVICE FAT routines built into the kernel. Stacker probably uses the DRIVER.SYS approach (I'm not sure). > Having a common interface to install ext2fs, umsdos, vfat, fat16, fat32 and > a file system for OpenDos. Such an interface already exists. We should only get rid of the built-in FAT support and move it to an external driver. All disks would then be installed using DRIVER.SYS interface. But that is not a problem. The problem is the FS utilities compatibility. It is not possible (or, at least, very hard to achieve) to create an abstraction layer to separate the utilities from the raw file system. > A lot of people want ext2fs for OpenDos, with that feature only it could > become a big Success... I agree! > I don't believe in corrupting fat anymore, any attempt that is made to add > "extensions" to it will be changed by M'soft to be as incompatible as > possible most likely, which is the closest you'll ever get to a complement > from them :) We are not trying to support M$ operating systems. On the contrary - we would like to rule them out of the market. As hard as it might seem, I think it is possible. We only have to provide a more featured, reliable system. That means that certain of incompatibity is unavoidable. But all of it may be enclosed in acceptable limits. It's only a matter of proper design. ================================================== Stand straight, look me in the eye and say goodbye Stand straight, we drifted past the point of reasons why. Yesterday starts tommorow, tommorow starts today And the problems seem to be we're picking up the pieces of a ricochet...