Message-Id: Date: Thu, 17 Apr 97 23:04 NZST Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: grendel AT hoth DOT amu DOT edu DOT pl From: Lorier Subject: Re: Usage of directory entries Cc: Matthias DOT Paul AT post DOT rwth-aachen DOT de, opendos-developer AT delorie DOT com Precedence: bulk At 10:53 AM 17/04/97 +0100, Mark Habersack wrote: >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". By having the sources to a kernal available, writting DosEmu would probably become a far easier task... As well as being able to modify parts of the (emulated) OS which don't fit in well with the new environment. >> 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. How does the DRIVER.SYS support work? I've heard lots of references but no phyiscal information has come forward :) >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. Hmm, a CD-ROM is readonly (like a network drive), is Changable (like a network drive being mapped in vs a HDD which never changes).... The other way of handling a CDROM would be like a big floppy... >> 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). DRVSPACE/DBLSPACE are a bit of a hack, but I assume they hook in, they just appear to do it before CONFIG.SYS is loaded. >> 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. The only minor problem I see with this is the fact that you need at least ONE driver type in the kernal so it can load the rest :) FAT is already there, having it more "modular" would be nice tho :) Being able to swap it for ext2fs would have definate advantages, especially with DosEmu. >> A lot of people want ext2fs for OpenDos, with that feature only it could >> become a big Success... >I agree! 1k Clusters up to a Terabyte (I think, certainly more than a gig anyway), where MS keep kluding FAT :( With ext2 we can show a far more efficient FileSystem and show how bloated FAT really is :) >> 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. I know. but if we make ANY attempt to "extend" FAT or create our OWN FS, then MS will make as sure as they can that Win85/Not Tested wouldn't work with it :) And will probably come out with the functionality themselves and claim that "Again we're at the for front of technology" :)