🚀 go-pugleaf

In article <770@lpami.wimsey.bc.ca| lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes:
|In <20005@usc.edu|, papa@pollux.usc.edu (Marco Papa) writes:
||Note that not only VLT but also A-Talk III, from Release 1.2 on, supports XPR.
||We hope other 'commercials', shareware and PD comm authors will pick XPR up.
||IMHO, XEM make good sense in a comm program, but not much in a BBS program.
||The other way around as far as 'multiple XPRs' are concerned: they make a LOT
||of sense in a BBS program; none in a comm program.
|
|Well, that sort of assumes that all future comm programs will be of the type:
|"one comm program per serial port". I wouldn't want to make that assumption.

I really don't understand what you mean. Do you mean to suggest to use "more
than one comm program" per serial port? That of course works only if the port
is SHARED and the comm programs "collaborate" (i.e, only one receives at any 
one time).  Or do you mean "one comm program that controls two serial ports
at the same time"?  If this the case, then it is much easier done by creating
a "reentrant" version of the comm program (easily done today with Lattice, not
MANX). In that case, running multiple instances of the comm program, each one
using a different port, will have the same space overhead as running one copy
that controls multiple ports. With today's programs that support multi-serial,
each instance of the program will allocate its own 'code' segment. That might
change sometime soon :-) Could you elaborate?

-- Marco Papa 'Doc'
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
uucp:...!pollux!papa       BIX:papa       ARPAnet:pollux!papa@oberon.usc.edu
"There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=