BS>>> Ofcause. I know there is a sleep() vs usleep() issue, especially
 BS>>> on Win32 vs. Linux.

 BJ> I haven't looked up this issue, but, from memory, sleep is in one
 BJ> second incriments, while usleep allows control in microsecond
 BJ> incriments.  From memory, sleep is a rather standard function (at
 BJ> least with the GCC compiler).  I do remember that any finer time
 BJ> incriment is compiler and/or system dependent.....  Guess I'd have to
 BJ> grep to see how / where Wes handled the usleep stuff for Linux / Unix
 BJ> and see what he did.  That might account for some of our major time
 BJ> delays.....

 BS> But actually what the reason for a WFC screen under 
 BS> Linux? I talked to Janis this afternoon on the phone 
 BS> (I'm calling USA to a few cents pr. minute by Internet 
 BS> phone), and she said it was very anying to see it run, 
 BS> because you couldn't get it away..

Based on how the telnet code is currently working (for as far as Wes has
progressed the code to date), the WFC screen is needed.  The telnet code is
only a single line support right now, and is like running a barefoot
maximus or opus under DOS or OS/2 (or Windows).  To get to the point of
multi-line, the telnet stuff will need to be changed.  To prove that you
only have a single line BBS support, try to make 2 or more telnet sessions
to the same maximus telnet port at one time.  Only the first will
succeed.....  And if you bring up a second copy of max/Linux for handling a
second telnet port, you will have to use a different TCP/IP port number.  

 BS> The machine maximus is running on at my home, has not 
 BS> monitor so I didn't notice it.

Well, if it wasn't there you would notice it, because the WFC screen is
what is what does the initial handling of your connection with the BBS.

 BS>> Well at some time, maximus should be reverse engeeriered to
 BS>> Windows.

 BJ> Actually, Max could use a re-work for the multi-tasking environment
 BJ> that Linux / Unix, OS/2 and newer Windows machines support.....  But
 BJ> you have to watch out what you think when you 
 BJ> consider the differences
 BJ> between handling one (or more) serial ports (with modems) vs TCP/IP
 BJ> based connections....

 BS> Yes, but the most of the TCP/IP communication is like it's on UNIX afaik.

Actually, not yet.  Under OS/2, I'm using the VModem (kludge) of SIO to
have telnet (and VModem) TCP/IP sessions connect up to virtual com ports
(and virtual modems) that each bink/max session connects to.  I currently
have only two "lines" setup for telnet / vmodem access.  The
third attempt at a telnet / vmodem with my main (OS/2 based) system will
not succeed....  Yes, I can add more "lines" for telnet sessions,
but it is still one instanciation of bink/max per "line"..... 
Under unix, one way would be to have each new telnet session to the BBS
spawn off it's own copy of the BBS.  This might be done under inetd, or via
how Max opens the telnet port....  But this is not how it is currently done
due to Max (sysop) console issues.....  Which gets back to needing maxpipe
(or similar) from OS/2 setup, along with a "virtual" console
support added to maxpipe.....  There are pieces of the max bbs code hard
coded to expect (sysop) console support in addition to the user's terminal.

 BJ> If you want to support FTP or HTTP based
 BJ> protocols, those should be standalone programs that supliment
 BJ> Maximus.
 BJ> The main BBS will still be a command shell or terminal window based
 BJ> interface....

 BS> Agreed! Nothing of that "fancy stuff" should be in the
core of maximus.

 BS>>> No that's right, because it's running in the background.. Maybe
 BS>>> the caller screen should be in some seperate program, which is
 BS>>> doing some IPC with the BBS processes.. We gotta remember this
 BS>>> is a Multi line BBS system :-)

 BJ> No....  Maximus has always been set up to handle a single BBS session
 BJ> at a time.  It *does* have interprocess communication (at least under
 BJ> OS/2) so that each instance of the BBS can communicate with the other
 BJ> instances....

 BS> Yes, but it would be nice as a multi line, because my 
 BS> default it's multiline because of the TELNET and POTS module.

Yes it would be nice to have multi-line, but multi-line for telnet may need
to be different than the multi-line support for POTS in the Unix
environment.  And once that is done, we might be able to port native Telnet
support back to the OS/2 environment (vs using the current VMODEM fix under
OS/2).

 BS> ...

 BJ> Think of the current maximus BBS code as
 BJ> the item being spawned when a new TCP/IP connection is made, or a
 BJ> spawned copy running monitoring the input from the serial port (and
 BJ> the modem connected to that serial port)....

 BS> That's right.. But I guess most people would run it 
 BS> from a frontend mailer.

Front end mail on the serial port (modem lines) makes sense.  Front end
mailers to the BBS on TCP/IP ports, while do-able, is not necessarily the
smartest thing to do.  Yes, that's how I have it running under OS/2, but
with TCP/IP, we should be able to use one port for the front end mailer,
and a different TCP/IP port for the BBS....

 MK>> Yep.  That and many other issues.  I want a Linuxed Maximus.
 MK>> Personally I don't care if it's portable to OS/2 or Windows.

 BS>> It would be nice if it is..

 BJ> At this point, the goal is to keep the compatibility with OS/2 and
 BJ> with Win32 systems if possible.  The 16-bit code may die off due to
 BJ> code size limits....  But I'll let someone who is willing to handling
 BJ> the OS/2 and Win32 compilations under a Watcom compiler tell me when
 BJ> that time has come.....

 BS> Fully agreed.

Take care.....

Bob Jones, 1:343/41


--- Maximus/2 3.01