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

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

 MK> That isn't the only issue.  Linux is totally different then Windows.
 MK> They have no common ground other then Linux's ability to service
 MK> Window's boxes.

I disagree.  Windows has finally progressed to have a number of
similarities to unix based boxes, but has implemented / defined control of
such items too much via GUI interfaces.  Maximus is command line driven. 
In a multi-tasking environment, that works under Linux / Unix or other
multi-tasking operating systems such as OS/2 and newer versions of Windows
(based on the Windows NT core).  Yes, there are differences in what each OS
provides for support....  But Max was written for Windows, it was written
initially for single user MS-DOS or PC-DOS, and then also for OS/2.... 
There is a lot of DOS think in how Maximus is setup.....

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

Actually, Max could use a re-work for the multi-tasking environment that
Linux / Unix, OS/2 and newer Windows machines support.....  But you have to
watch out what you think when you consider the differences between handling
one (or more) serial ports (with modems) vs TCP/IP based connections.... 
If you want to support FTP or HTTP based protocols, those should be
standalone programs that supliment Maximus.  The main BBS will still be a
command shell or terminal window based interface....

 MK> Same ccan be said for OS/2 except that Linux has
 MK> trouble writing to OS/2 partitions.  All other networking works great
 MK> though.

OS/2 supports partitions in FAT and HPFS format.  Grant it, to use long
file names, and for reliability, most OS/2 systems use HPFS.  OS/2 can
mount Samba based partitions, but I haven't gone that route yet.....

 BS> Indeed.

 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 is
 BS>> a Multi line BBS system :-)

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


Ultimately, how Wes gets the serial and TCP/IP support working will
determine what's needed in the wait for caller area.....    And yes, some
of this is more DOS or command line type think....  But this is how the
code is currently structured.....  To change that will be a major re-write
of code.....  Think of the current maximus BBS code as the item being
spawned when a new TCP/IP connection is made, or a spawned copy running
monitoring the input from the serial port (and the modem connected to that
serial port)....

 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..

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

Take care.....

Bob Jones, 1:343/41


--- Maximus/2 3.01