Comments: Authenticated sender is <alaric+abwillms AT sdps DOT demon DOT co DOT uk>
From: "Alaric B. Williams" <alaric AT abwillms DOT demon DOT co DOT uk>
To: "Mike A. Harris" <mharris AT blackwidow DOT saultc DOT on DOT ca>
Date: Fri, 14 Mar 1997 21:05:55 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: [opendos] FSSTND
Reply-to: alaric AT abwillms DOT demon DOT co DOT uk
CC: OpenDOS Mailing List <opendos AT mail DOT tacoma DOT net>
References: <Pine DOT OSF DOT 3 DOT 95 DOT 970313094853 DOT 31112B-100000 AT unicorn DOT it DOT wsu DOT edu>
In-reply-to: <Pine.LNX.3.95.970313210715.955S-100000@capslock.com>
Message-ID: <858373389.062046.0@abwillms.demon.co.uk>
Sender: owner-opendos AT mail DOT tacoma DOT net
Precedence: bulk

On 13 Mar 97 at 21:14, Mike A. Harris wrote:

> > While I agree with the idea of a standard, I abhor hardcoded directory
> > names.  I've already got my own directory structure and I hate programs
> > that won't respect that.  
 
> Well, I've got my own directory structure too, and mine is
> probably different from yours.  That is the reason for pushing
> for such a standard.  If everyone has things in the same spot, it
> makes life easier.  Everyone will want their current heirarchy to
> be "the standard" and none will become it.  As much as some
> people may not like the idea of such a standard, it will probably
> come to be anyway.  Hard coded directories are not necessarily
> part of this standard however.  I think that hard coded dirs
> should not be used.

IMHO it is time to tie things together. Software that uses all these 
OD extensions we're planning will not be DOS software, it'll be OD 
software.

To ease compatability, the OD extensions runtime should be a TSR, 
with perhaps the option of transient loading like CWSDPMI, where it 
is used only to invoke something. This TSR would contain EMM386's 
memory management and multitasking, such that anything already in 
memory is not reloaded (DPMI support etc), so an overlay structure 
would be useful, as well as excessive highloading!

A full feature list:

 - Memory management
 - Multitasking (providing the EMM386 API?)
 - 32 bit PM interface to all of this, as well as the DOS one
 - PM and RM truely shared libraries
 - This enhanced config thing that handles the path names among other 
things - a registry?
 - anything else we think of
 - LFN/IFS interface with a new filesystem API designed for it.

This TSR will come with OpenDOS, but run fine on other DOSes. It 
should work by installing a simple interrupt handler (on 21h or 2fh?) 
that will test for availability and return an entry point (RM or PM). 
The PM version would have to go via the DPMI shared memory interface 
or something, to work under other people's DPMI systems... unless we 
drop DPMI (leaving it an memory management in EMM386) and provide a 
"sub-DPMI" that runs as one DPMI app, and loads in client 
applications beneath itself, at the loss of memory protection between 
them. This would be more portable...

If an application makes the effort to support the API, it has to be 
"ported" anyway, so it might as well support everything properly!

ABW
--
Governments are merely protection rackets with good images.

Alaric B. Williams Internet : alaric AT abwillms DOT demon DOT co DOT uk
http://www.abwillms.demon.co.uk/