Path: utzoo!attcan!uunet!mcvax!hp4nl!kunivv1!wn2!janhen From: janhen@wn2.sci.kun.nl (Jan Hendrikx) Newsgroups: comp.sys.amiga.tech Subject: Re: Was: Re: What font does Intuition use? Summary: We need LoadSeg in this case Message-ID: <303@wn2.sci.kun.nl> Date: 14 Jan 89 17:56:43 GMT References: <10236@well.UUCP> <3235@amiga.UUCP> <10289@well.UUCP> <249@microsoft.UUCP> Organization: University of Nijmegen, The Netherlands. Lines: 32 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)