Wes:

I screwed up my comments on the console issue (quoted below)....  If you
start maximus up under getty, then the stdin/stdout/stderr handles will
probably either be pointing to the parent's stdin/stdout/stder or the
controlling terminal....  In either case, that's not what you want.  In (at
least some flavors of Unix), if you start up a process without a tty
attached, as soon as you attach one (such as looking in on a process from a
terminal window), you can get stdin/stdout/stderr hooked to that tty.... 
Not really what is wanted....  So, for now, you may need to put the
"console" information into the bit bucket.  Later, a seperate
program / process could be run to view the console information (like
syslogd) and max could send the stuff through a pipe.  I think the code for
this may already be there, because there are some options under OS/2 (and
win32?) that I haven't used in this area.  

Warning:  If a seperate program acts as a "system console", the
communication path is a potential security hole in the software.  The DOS
and OS/2 versions of Maximus (and I believe also the Win32 version) expect
the console interactions to be controlled by the Sysop.  If anyone can
startup a process to become the console, they get sysop privilages....  And
from there, you can grant a user anything that the program allows....  So,
that will be a potential issue....

Some things burried in the sysop menu may need to be disabled in the Max
code for security reasons.....

Good luck.....



 BJ> Unix) would use the open file handle(s) to the "modem" 
 BJ> or TCP/IP port for communicating with the user.

 BJ> Another problems comes from Maximus use of writing information on the 
 BJ> console of the controlling terminal.  In Linux / Unix, you can not assume 
 BJ> that you have stdin, stderr and stdout pointing to a 
 BJ> private terminal / shell session like you would in 
 BJ> OS/2.  So, at some level in the Maximus code, this will 
 BJ> need to be handled.  Also, I believe Max uses some lower level code 
 BJ> (getting into the OS/2 session manager?) that allows 
 BJ> faster "screen writes" instead of just writing to 
 BJ> stdout or stderr (or reading from stdin?).  So, we 
 BJ> should be able to redirect this activity to stdin/stdout/stderr (at least 
 BJ> to start with) in the Linux / Unix environment.  Please 
 BJ> note that you will need to setup the terminal sessions 
 BJ> running maximus as VT100 windows (or similar) to use 
 BJ> the current code.  Eventually, we may want to change 
 BJ> the Maximus code over to use ....  
 BJ> ah...  TERMCAP stuff....   library name easing implemnetation....>....  I think 
 BJ> the VT100 (with PC enhancements) are hardcoded (but I 
 BJ> haven't dug into the code that far).... 

 WG> I have an interesting dilemma: What do I do with the 
 WG> console/peek mode screens? Right now, if you run 
 WG> Maximus/UNIX in "single user" mode (one user per TCP/IP 
 WG> port), you could theoretically fire up multiple 
 WG> instances of Max in multiple terminal (CMD) windows. 

 BJ> Yes, one per terminal window.  No to one per TCP/IP 
 BJ> port.  Have the TCP/IP port run getty and have getty 
 BJ> instanciate Maximus for the "shell" to be run.

--- Maximus/2 3.01