🚀 go-pugleaf

In article <249@microsoft.UUCP>, w-colinp@microsoft.UUCP (Colin Plumb) writes:
|janhen@wn2.sci.kun.nl (Olaf Seibert) 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.
[...]
|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.
|general principle, though.

Yes, but in the case when a Task opens a library or device which must be
loaded from disk, we really need LoadSeg() and that does not work
by sending packets to someone. It would indeed be best to re-package
LoadSeg() to be indpendent from being a Task or a Process.

|	-Colin (uunet!microsof!w-colinp)
-Olaf Seibert (using Jan's account)