Hello Bob!

05 Oct 03 14:39, you wrote to me:

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

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

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

 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 consider the differences
 BJ> between handling one (or more) serial ports (with modems) vs TCP/IP
 BJ> based connections....

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

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

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

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

...

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

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

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

Fully agreed.

Regards,
Bo

--- GoldED+/LNX 1.1.4.7