Mail Archives: opendos/1997/04/17/07:12:09
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" :)
- Raw text -