Mail Archives: opendos/1997/04/18/06:40:55
>> >Hmm... You cannot treat these two products separately. Caldera also has a
>> >product called OpenLinux, I *suspect* (it's my personal opinion, of >>
>that OpenDOS *might* be merget into OL as a native "emulator".
>>
>> By having the sources to a kernal available, writting DosEmu would
>> 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.
Yeah, Linux 3.0.0 is supposedly going to do Dos apps natively isn't it? :)
Yeah, a proxy would be nice and probably be done... It'd just be subtly more
difficult than anyone expects :)
>> >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
>> phyiscal information has come forward :)
>There are several in 0x2F calls that allow you to insert your driver into
>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.
Hmm, I'll have to get a uptodate version of that. :)
>> >This interface allows you to create/mount any type of disk into the
>> > This approach is much easier than that of MSCDEX in which CD-ROM is >>
>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?
It would be, but the "natural" way is almost never the way its done, You
should know that by now! :)
>> >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 >>
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.
Hmm... when's this source available? :)
>> >problem is the FS utilities compatibility. It is not possible (or, at
>> >least, very hard to achieve) to create an abstraction layer to separate
>> >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
>> 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
>of drivers.
Yeah, the BootSector looks for the root directory (it could look anywhere)
for information to load the OS Kernal(io.sys), but loading the drivers out
of Config.Sys requires *reading* config.sys :)
>> >> A lot of people want ext2fs for OpenDos, with that feature only it >>
>> 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... ;-)
Please ignore me if I drool quietly at the thought :)
>> >system. That means that certain of incompatibity is unavoidable. But all
>> 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
>> "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...
Linux marketing has become a success and a 1/2, Word of mouth appears to be
working wonders...
>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)
What type of TSR?
Hmm... Anyone have any idea what "Multipath=" or something in Config.sys in
Dos6.2 is for?
- Raw text -