Mail Archives: opendos/1997/04/18/02:29:21
Once upon a time (on 17 Apr 97 at 23:04) Lorier said:
> >> 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.
Hmm... DosEMU might easily be changed to a "proxy" between the real mode DOS
and Linux - a not so trivial task (probably much harder than just emulating
DOS). This approach has several advantages, one of them being 100%
compatibility with DOS software.
> >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 :)
There are several in 0x2F calls that allow you to insert your driver into the
chain of block device drivers. Every call to such a device is redirected to
your driver which handles just the standard set of IOCTL calls. The info
should be in INTRLIST, but should it not be there, I can write a short
resume.
> >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...
And that would be much more natural, wouldn't it?
> >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.
There is a code inside the M$ dos kernel which looks for these files and
loads them as a part of the system kernel standard device drivers set. It's
being done by IO.SYS. At least I think so.
> >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.
You don't need it at all! Linux doesn't need to! The only think to know is
A location of the superblock (or in DOS nomenclature, bootblock) which
contains the necessary information to load OS kernel and find the boot-up set
of drivers.
> >> 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 :)
Exactly! And with an addition of SFS... ;-)
> >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" :)
Then we can adapt to their new technology and support it better than
they do! And there's always the user who choses his/hers way - they will
chose the better product. Here it's only a matter of marketing,
unfortunately...
P.S. Matthias, the undocumented /T switch to command.com causes command.com
to reload itself when it finds a certain type of TSR (I think that it should
be a multitasker)
==================================================
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...
- Raw text -