To whoever is working on the Unix Maximus port....  The following are my
initial thoughts to your questions.....

 WG> You can start by telling me what the OS/2 session 
 WG> manager does (operational overview), and describing how 
 WG> multiple nodes are handled. 

I'm not sure what you are needing concerning the OS/2 session manager.  I
haven't dug into the "OS/2" based naming of things, but here is
my view point from using OS/2 Warp 3 and Warp 4 for running the BBS....

OS/2 provides multi-tasking, but is not setup (in general) for multi-user. 
The way I run my BBS under OS/2 is that I have one terminal based window
per BBS instance running.  This is different that the concept of inetd
spawning needed processes (getty -> BBS for TCP/IP based connections)
under Linux.  

I currently run three nodes on my BBS.  I have three command line
(terminal) windows open.  One node runs the BBS on my phone line.  The
other two are hooked up to "virual modems" via SIO's VMODEM
device driver hook, which allows me to accept up to 2 BBS sessions via
telnet.  Actually, let me correct this.  Sometimes I also run a fourth
node, when I run Maximus at the local console.  [This uses a command line
switch to Max to run all i/o to the terminal / shell session and flags
certain functions for not available....]  The VMODEM software handles
directing the first connection to the telnet port to the first
"virtual modem" and then the second telnet connection is directed
to the second "virtual modem".  From the BBS stand point, all the
BBS software is talking to is a "modem" hooked up to a
"serial port".....  (A virtual modem on a virtual serial
port.)...  I have a 16 port licensed copy of SIO, and so I could setup
support for any combination of up to 16 serial ports -- real or vitural. 
So with four real serial ports, I could set up 12 virtual serial ports, and
potentially have 4 phone lines and 12 telnet sessions going on at the same
time....

To see my current system, see fidonet 1:343/41 or
telnet:\\tophat.darktech.org or telnet:\\tophat.dyndns.org .

In Unix / Linux, we need to swith the code over (for one option) to being
able to be spawned by inet.d (if I remember the name correctly), so that
for each telnet session to the BBS port, a new instance of the BBS is
started.....  It might not be the standard telnet port.....

Under OS/2 (and DOS, and Win32 based BBS systems), I have a front end
mailer (Binkley) that answers the "modem" (virual or real) and
checks for an FTSC based fidonet connection.  If it isn't a fidonet based
connection it "drops" to the BBS (maximus), at which point Max
takes over and you log into my system from there.  For Linux / Unix we
should be able to rely on the version of getty that knows about Fidonet
protocols and have that getty start Binkley (or ifcico or equivalent) if
the session is fidonet FTS-0001 based.  If it is a human, getty should be
able to start Maximus instead of starting a shell process (csh, ksh, zsh,
bash, etc.).  Maximus then (in both OS/2 and Unix) would use the open file
handle(s) to the "modem" or TCP/IP port for communicating with
the user.

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

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

 WG> The problem arises when you want many users. Maximus 
 WG> has an internal limit of either 255 or 256 concurrent 
 WG> users, so right now I will allow (through some 
 WG> trickery) 255 nodes to be dynamically created as 
 WG> needed. (I am 
 WG> not using Binkley as a front end -- it's on a different 
 WG> port). But what to do with the sysop-side output?

See above.  Sysop side output for now should be written to the terminal
window, either stderr or stdout, but be consistant.  Probably should be
stdout.

Yes, I believe Maximus does currently have an internal limit of 255 nodes. 
If the node number is zero, then Max is running in single user mode, which
we do not want under unix.  We probably should switch max's internal
"node number" designation over to using it's process ID or some
function that keeps track of the currently active session numbers....

 WG> I'm thinking that maybe some sort of pipe to a 
 WG> "virtual" terminal where you can attach to different 
 WG> nodes at 
 WG> whim would be useful. Or maybe ditch the sysop-view 
 WG> entirely, if that makes sense.

Long term, a pipe makes some sense.  Short term, leave the sysop-view to
that sessions terminal window, and leave that (local) terminal window
"configured" as a vt-100.

 WG> Also, when things get a little more stable, having an 
 WG> experienced Maximus sysop have a "look around" would be 
 WG> nice. So yes, you can help! :)

And I'm willing to play also.  I'd like to setup Max running on my Linux
machine in parallel with it running under OS/2.

 WG> As for your linux-using bretheren; the more the 
 WG> merrier, I say. Bo and Andrew have already proved quite 
 WG> useful 
 WG> to me, and they're working their way through trying to 
 WG> build and use a pre-alpha release.
 WG>  
 WG> Maximus under Linux will be a viable alternative soon 
 WG> enough; mark my words.
 WG> :)

 WG> Also, if you know any door-writers, encourage them to 
 WG> release their source code, or port for the new 
 WG> platform. Etc, etc.

 WG> PS -- forgive the wacky formatting of this message -- I 
 WG> haven't used Maximus in 10 years, and am having a hard 
 WG> time remembering how to do simple things like erasing 
 WG> lines in the fullscreen editor -- argh!

Remember Word Star commands?   If so, you will catch on quickly....

 WG> Oh, and PPS -- With respect to session manager -- my 
 WG> last Maximus setup was version 2.01wb running under 
 WG> DESQview 2.51 and DOS 5.0.
 WG> Back then, I had six com ports and a virtual screen for 
 WG> each of them. One of the screens was even on a Hercules 
 WG> second monitor, that was cool  

Ah....  Ok, so some of my info above wasn't needed.

Take care....  I look forward to working with you.....

 WG> Cheers,
 WG> Wes



--- Maximus/2 3.01