Comments: Authenticated sender is From: "Alaric B. Williams" To: "Mike A. Harris" 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 References: In-reply-to: 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/