Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!cornell!uw-beaver!microsoft!w-colinp
From: w-colinp@microsoft.UUCP (Colin Plumb)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Was: Re: What font does Intuition use?
Message-ID: <249@microsoft.UUCP>
Date: 12 Jan 89 13:19:44 GMT
References: <10236@well.UUCP> <3235@amiga.UUCP> <10289@well.UUCP> <3245@amiga.UUCP> <300@wn2.sci.kun.nl>
Reply-To: w-colinp@microsoft.uucp (Colin Plumb)
Organization: very little
Lines: 33

janhen@wn2.sci.kun.nl (Jan Hendrikx) wrote:
> In article <3245@amiga.UUCP>, jimm@amiga.UUCP (Jim Mackraz) writes:
>> Not only does input.device not have a process (although we could make it so),
>> whoever calls me might not.  It's a larger thorny problem: if my library
>> opens another library, if that library is on disk, then my caller needs to be
>> a process.  This is why we have such general rules as "rom code can't rely
>> on disk files" and so on.  In some situations, we need to improve on this.
> 
> This is, of course, not very convenient. Why is there not a rom-based
> library that creates temporary processes just for the purpose of
> accessing the DOS?

As far as I can tell, if you're willing to play a few tricks with DOS,
you don't need to be a process to achieve most of the functionality of
the Dos.Library.  Execute() and the like are't very possible, but
Open/Close/Read/Write and the like are.

The majority of DOS is in the handlers, which an ordinary task can send
arbitrary packets to.  The only trick lies in finding the handler for the
apropriate device, which can be done by looking at the di_DevInfo
list.  Not exactly portable to 1.4, but C-A can get away with nasty
tricks like this.

Am I wrong?  As far as I've been able to tell, DOS doesn't do a hell of a
lot, for all its rococo details.  The bulk of the Process and CLI data
structures seem to be maintaining context it has no business messing with
in the first place.  The scatter-loader should be a separate library, and
Execute() should be a lot more like System() under Unix.

Sigh.  "The ROM shouldn't depend on the disk too much" is still a good
general principle, though.
-- 
	-Colin (uunet!microsof!w-colinp)