Mail Archives: opendos/1997/04/10/17:42:16
On Thu, 10 Apr 1997, Alaric B. Williams wrote:
> With an agreed module system, this would be incredibly worthwhile,
> since it wouldn't even bloat the binaries! The filer and so on would
> be in a shared module, just as the 16 bit filer is in a shared memory
> area (the DOS kernel). The only hazard I can think of is that any TSRs
> overriding the DOS filer will be invisible from our PM apps, and
> we still need to go back to real mode to access the BIOS, unless we
> provide standard [E]IDE, FDD, and SCSI drivers, with the option of
> chaining to the BIOS for anything too far out to access. We would also need
> to chain back to DOS to use things like Bernoulli drives, which install
> as a .SYS driver, and CD-ROM drivers could be a problem, even though we
> can create a PM NWCDEX of our own.
Sure, such a DOS extender would only be able to do same as bare DOS
(without any drivers), but still, could be very interesting...
> Another pitfall, come to think of it, is that higher level interfaces
> (ie, read from file) typically expand to more than one lower level call
> (ie, read disk sector). The time penalty in mixed-mode code is the
> switching, so we want to minimise the number of calls made from PM to RM
> - but if we put the higher layers in PM, then the calls to RM will be
> lower level, and hence perhaps more numerous - therefore slower... it
> would be nice to steal the entire Linux driver set (why not the entire
> kernel, with some modifications?) and provide it as a shared module.
> Then we'd have ext2fs and all that as well.
Switch to real-mode to do what the BIOS does? No way! Lets take the BIOS32
code from Linux instead... ;-)
> I currently hate Unix, but the Linux kernel's not bad as they go!
You hate Unix? Hmm... You'd hate what I did to my DOS! ;-)) Using bash as
default shell, using Emacs, and so on... :-)
Pierre Phaneuf
- Raw text -