delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/1997/04/18/14:33:55

Date: Fri, 18 Apr 1997 20:27:50 +0200 (MET DST)
From: Mark Habersack <grendel AT hoth DOT amu DOT edu DOT pl>
Reply-To: grendel AT hoth DOT amu DOT edu DOT pl
To: Lorier <lorier AT ihug DOT co DOT nz>
cc: Matthias DOT Paul AT post DOT rwth-aachen DOT de, opendos-developer AT delorie DOT com
Subject: Re: Usage of directory entries
In-Reply-To: <m0wIAs7-000FmCC@hn.planet.gen.nz>
Message-ID: <Pine.BSI.3.96.970418202152.29763J-100000@hoth.amu.edu.pl>
Organization: PPP (Pesticide Powered Pumpkins)
MIME-Version: 1.0

On Fri, 18 Apr 1997, Lorier wrote:

> >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 ;-))

> Yeah, a proxy would be nice and probably be done... It'd just be subtly more
> difficult than anyone expects :)
True... sand but true...

> >> 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. :)
You should!

> >> 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! :)
Yeah ;-)))

> >> 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? :)
Of M$-DOS??!?!? Are you kidding?!?!? It's TOP SECRET!!! ;-)))
 
> >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 :)
And what stops us from allocating some space before the root dir (which is
*always* at the partition start) and put all the configs there - in linear
way, sector by sector - config.sys first, others following (autoexec.bat may
be stored the usual way. The config.sys in superblock would just install a
driver for the root FS. The config would store entire allocation map of the
device driver in logical HDD coords (as related to the partition in question)
- clean and easy, isn't it? All the other drivers would be loaded from the
"normal" config.sys

> >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...
And some good press... Yes, that will be a success!
 

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019