Porting MUSH 6.4 to SV/AT

[Mike Borza]

Hi folks,
I've just put up MUSH 6.4 on my uPort SV/AT (rel. 2.3 beta with FP
exception hang fix) at home, and my 386/ix system at work (rel. 1.0.6).
386/ix installation is trivial-- run the SysV makefile.  Building
MUSH under my release of SV/AT was a little harder, but not much.
Apologies if this is already common knowledge (I haven't seen anything
on it here yet).

There are really only two things required to build MUSH under SV/AT.
First, the optimizer pukes on the module `curses.c'.  Either turn off
the optimizer in the makefile CFLAGS, or compile curses.c separately
with the optimizer off.  Cc generates warnings about potential jump
table wrap-around in `curses.c'.  I looked at the code and it's harmless.
Also, mush must be built under the large memory model.

The only serious problem with the build is that my version of pcc
is unable to compile the `msg_bit' macro.  The work around is to write
a function msg_bit which splits the expression in question into two
parts, assigning the intermediate to a temporary.  The function given
below works.
	> #include "mush.h"
	> int msg_big ( list, n )
	> register char list[];
	> register int n;
	> { register int tmp;
	>   tmp = list[n/8];
	>   return (( tmp >> ( n % 8 )) & 1 );
	> }

Other than that, you shouldn't have any problems.  I've tried out the
standard Mail.rc modelled after the UCB mailer, and also the .mushrc
given in `advanced.mushrc', which really shows off the power of MUSH.
One thing to watch for: to use the "burst-mode" commands, the named
mail folders must already exist.  The problem is that "save" croaks
if the named folder doesn't exist.

The only other problem I've found to date is the curses interface,
which causes all text output after the first page full to appear on
the bottom line of the screen.  I think this is a problem in the
uPort curses library or the terminfo definition, but I don't plan
to use the curses interface anyway, so I'm not worried about it.

I've forwarded a similar report to the author.  Given what I consider
the demise of the '286 machines, he may choose to ignore these problems.
Comments or suggestions welcomed.  Flames > /dev/null.

Happy motorin'
mike borza         <nusip at maccs.uucp>