🚀 go-pugleaf

jesup@cbmvax.UUCP (Randell Jesup) wrote:
>> A big problem with CLI processes is that they are (quite arbitrarily)
>> limited to 20.
> 
> 	Agreed, it is too few.  This may change.

This isn't that hard to enlarge, but you want to get rid of the restriction
completely.  Arrgh!  If someone would give me a complete spec for dos.library
(basically, a list of BCPL kludges that need supporting), I could give you a
rewrite in a month.  The silly thing doesn't *do* dick all.

>> 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.
> 
> 	(suppressed giggle) it ain't as easy as it looks.  Just ask Steve
> Beats (Mr FFS).

Actually, the interface isn't that bad.  A few BPTRs raise their heads,
and there are such idiocies as ExNext(), but it's bearable.  Still,
I wouldn't mind a nicer one, especially when dealing with the DevInfo
list.

>> 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.

My preference is to define a new & improved executable format, preferably
an IFF FORM.  Then you can stick in all sorts of magic information and
not break anyone's loader.  But this would require one grand change to
LoadSeg() (and at least one conversion utility for producing executables
in this form, eventually to give way to direct linkers).

>> 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.

You have to handle the reference-counting manually, but you can have multiple
processes all sharing the same filehandle without problems.  The BCPL stuff
is disgusting, and I hope it gets fixed in 1.4, 'cause owing to a lack
of documentation, my FS is going to ignore that completely.  If someone
tries to jump through one of those fields, boom!

But there's no way a handler can tell that two processes talking to
it over the same filehandle aren't really one, that just has a
strange prediliction for asynchronous I/O using multiple return
message ports.

(BTW, does anyone know what AN_AsyncPkt is caused by?  Who sends an
unexpected packet to whom?)
-- 
	-Colin (uunet!microsoft!w-colinp)

"Don't listen to me.  I never do." - The Doctor