🚀 go-pugleaf

In article <6303@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes:
 >In article <DEVEN.89Mar15163112@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven Thomas Corzine) writes:
 >>In article <6278@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
 >>>>What about setting the CLI proc number to 0?  Will some cli things choke on
 >>>>this?  Lattice's forkv() uses proc number 0. (What do workbench programs do?)
 >>
 >>>        Not normally a good idea.  It removes the ability to Break the
 >>>program, or to have Status return anything reasonable.  Isn't really too
 >>>dangerous, though.
 >>
 >>Wouldn't Status simply ignore any process that has a CLI process
 >>number of 0?  (Strangely, sometimes Status will show a process number

 >The standard Status command will ignore any process with a process
 >number of 0.  Of course, you realize that the CLI process number is
 >an index to the task table.  Other programs that play with the
 >task table may not have the error check that status does.
 >So it is a risk of memory corruption, depending on what other
 >programs the end user has.

 >>as being in the billions or so (many digits anyhow) after something
 >>crashes...  very incongrous.)

 >That's what happens when memory is corrupted.  You took a hit in your
 >process structure.

That's what I figured.

 >>>        Talk to Bill Hawes.  He wrote a PATH: that does similar sorts
 >>>of things.  Warning: packet-forwarding can get tricky.

 >>I still gotta track down that PATH: device sometime.  Yeah, I could
 >>see packet-forwarding getting tricky...  Any particular caveats you
 >>have in mind?

 >Though it may seem like a clean solution at first, you'll find that
 >a packet forwarder won't ever be able to just put the sender
 >in touch with the real receiver, but must stay in the loop, forwarding
 >each packet.

Now why is that?  Ah, well.  No matter, I'm already going to have a
system task for coordination which will be an AmigaDOS process, though
I think I'll just have it use function calls to dos.library instead of
using packets directly, though I may change my mind...  I may well
patch dos.library also so Amigix processes can call them directly and
have the patch send a message to the system task to do the actual call
if the caller is an Amigix process instead of a dos process.

 >You might want to take a look at the path handler (with source)
 >that came by comp.amiga.sources as well.

A path handler came across comp.sources.amiga?  I don't recall one, at
least not source...  There was PathAss (gee, what a name) but I
thought that was a binary-only post.  Besides, that one is poorly
written and crashes under stressful conditions regularly.  (e.g. using
it for c: sucked.  "DOS Library general error: Unexpected packet
received."...  *sigh*)

 >>Be that as it may, it remains a fact that protection bits are easily
 >>lost in distribution and simple copying.  What are these 16
 >>user-defined bits?  I assume the upper 16 bits, but I've never seen
 >>mention of them...

 >There are only 8 user-defined protection bits; as you surmised, the
 >upper 8 bits are the user bits.  The 1.3 Copy command preserves
 >protection bits by default.  The next version of ZOO will preserve
 >all protection bits as well.  

 >Granted, magic numbers are never in danger of being lost, and may be
 >a better solution thab protection bits.  Hmmm, I wonder if romtags
 >could be adapted...nah :-)

Exactly what are romtags, hmm?

Actually, it's sorta tempting to try to write a loader which could
load object modules directly and link them dynamically...  SunOS 4.0
does this, and it's a real neat trick.  Also a bitch to implement, I
imagine...  Maybe I won't.  :-)

Deven
--
------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine ---------------------
Cogito  shadow@acm.rpi.edu          2346 15th Street            Pi-Rho America
ergo    userfxb6@rpitsmts.bitnet    Troy, NY 12180-2306         (518) 272-5847
sum...     In the immortal words of Socrates:  "I drank what?"     ...I think.