Path: utzoo!attcan!uunet!cbmvax!jesup From: jesup@cbmvax.UUCP (Randell Jesup) Newsgroups: comp.sys.amiga.tech Subject: Re: Unix V7 functionality under (or along with) AmigaDOS? (*LONG*) Message-ID: <6237@cbmvax.UUCP> Date: 13 Mar 89 18:49:20 GMT References: <6157@cbmvax.UUCP> <6185@cbmvax.UUCP> Reply-To: jesup@cbmvax.UUCP (Randell Jesup) Distribution: comp Organization: Commodore Technology, West Chester, PA Lines: 88 In article shadow@pawl.rpi.edu writes: >In article <6185@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >>Distribution: comp >? That's what Pnews gave me as a default. >A big problem with CLI processes is that they are (quite arbitrarily) >limited to 20. That is too few; I want to implement concurrent pipes >and simple backgrounding, and I don't want to have them all as CLI >processes. Agreed, it is too few. This may change. >Of course, the only real way to break from the BCPL crap is to rewrite >the file system, or at least the interface to it. I wouldn't mind >doing so, and have considered it a number of times, but don't have the >time to do so just yet. Maybe in a couple months. (suppressed giggle) it ain't as easy as it looks. Just ask Steve Beats (Mr FFS). >Speaking of Execute(), I have a gripe with it. V1.3 Execute() does >NOT use run if it is in the DOS Resident list, but still insists to >run c:run... which is a BIG pain if the system disk isn't in the >drive. (assigning c: to ram:c or rad:c isn't much help; then you >can't be asked for the system disk back to run programs in sys:c which >aren't resident...) Known. >Say, if I replaced that Command Dir lock that's in the CLI structure >for that one CLI process, would it look there without having to >assign c: elsewhere? You believed the name of the field, didn't you? Poor naive boy. :-) It's really the BPTR to the path list. >> I advise against modifying binaries. Use one of the user >>protection bits. > >Not such a good system. user protection bits are all too easily lost. >I'd much rather have the binary identifiable. The idea I had to >identify it which seems most workable is to have a special startup >module which begins with a branch past a magic number (longword) which >the shell's loader could check against. Sound reasonable? I've seen it done. Check the arp programmers docs. >Yes, when I looked into it, I decided that it would be better >implemented on top of Exec and such. However, there are some >low-level changes that would be valuable, like sending a signal to a >process when it goofs up, instead of GURUing and bringing down the >entire system... You can trap Alert(). Of course, code that dead-ends may not deal well with Alert() returning.... [tc_Launch & tc_Switch] >That's fine by me. (expected to do so anyhow.) What state do those >functions run in? Supervisor or User mode? Can they be interrupted >by the timer clock, and end up with Exec trying to switch out when it >already was? Or, will they not be interrupted? (i.e. if those >functions took 10 seconds to execute, would it break anything other >than system performance?) I suspect in supervisor, non-interruptable (by the switcher, interrupts will still occur, I suspect). Taking 10 seconds would be very, very bad in a real-time OS. Even VMS doesn't take 10 seconds to switch! :-) For more data, ask bryce@cbmvax (I haven't played with it). >How about using the tc_UserData field to point to an extended >structure? Is it used for anything? Or maybe using the name filed in >the task's node structure as an extended structure pointer? Or are >both these out, too? Applications are allowed to use it. The ln_Name points to a real task name. >No way to dup a filehandle? Why couldn't two programs use the same >filehandle? Can two non-BCPL programs share a file handle? It is >lack of mutual exclusion or something else? Two non-BCPL programs can right now. BCPL programs use the buffering fields in the file-handle, and would clash over them. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup