janhen@wn2.sci.kun.nl (Jan Hendrikx) (01/12/89)
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? I already speculated that the (undocumented) ramlib.library was used for this, but it seems that this is not so. By the way, what *is* the ramlib.library used for? > jimm -Olaf Seibert (using Jan's account)
w-colinp@microsoft.UUCP (Colin Plumb) (01/12/89)
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)
aaron@madnix.UUCP (Aaron Avery) (01/13/89)
In article <249@microsoft.UUCP> w-colinp@microsoft.uucp (Colin Plumb) writes: >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. You are right that the big stuff is taken care of by the handlers, which are really little filesystems. The big one which needs all of that Process info is the standard, ROM-resident filesystem. Please, please, don't go traversing lists when you don't have to. Try DeviceProc(), which is no trick, and is more likely to be portable to 1.4 than traversing that list! Aaron -- Aaron Avery, ASDG Inc. "A mime is a terrible thing to waste." -- Robin Williams UUCP: {harvard|rutgers|ucbvax}!uwvax!nicmad!madnix!aaron ARPA: madnix!aaron@cs.wisc.edu
janhen@wn2.sci.kun.nl (Jan Hendrikx) (01/15/89)
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)