Message-Id: Date: Fri, 18 Apr 97 22:26 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 >> >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?