...
 BJ> Depending on how you are "faking" BPS rates, there 
 BJ> are other possible 
 BJ> .MEC files displayed before haning up on the 
 BS> connection, shortly into 
 BJ> the login process.

 BS> I'm faking it to 38400.. 

Then there should be no problem....

...
 BJ> Programs on Unix systems usually used CURSES or 
 BJ> TERMCAP libraries to support multiple types of terminals.....  At 
 BJ> some point after Max starts running under Linux / 
 BJ> Unix boxes, we will 
 BJ> probably see a complaint that Max doesn't work with  terminal name here>, even with the proper TERMCAP setup.    

 BS> Now i understand!

  The "fun" of old unix systems.  One of the first
things I needed to do when getting on a new unix system was to figure out
the various terminals I had available and get the TERMCAP settings edited
properly so I could get vi to work properly.....  [Oh, oh....  mentioned
specific editor....  No, I don't need to start that type of editor
religious war.....]  At the time vi was about the only editor I could
guarentee to be on the system.  Yes, you could bring in GNU EMACS, but that
was always secondary....  And then there was also PICO.....  I think I've
used all three at various times over the years, and then even a few others
that were on specific computer systems....

Yes, I even had a termcap mode for properly using the 132 column mode of
the old VT-100.....  And on the H-19 (VT-52 look a-like), I even had code
that took advantage of the 25th line.....

...
 BJ> There is a version of GETTY that is supposed to 
 BS> differenciate between 
 BJ> Fidonet hand shakes, PPP and regular modem calls, FAX calls, and 
 BJ> possibly even a voice (on a voice modem) call.....  

 BS> It's mgetty as i wrote. But if maximus is taking care 
 BS> of listening at the port, and so on, it's quite hard to 
 BS> get it in tuch with a mailer.

My point isn't about handling the TCP/IP port, but in the ability to
maintain the old style modem login.  When I switch the BBS over to a linux
based system, I still want the phone line capable to be answered by the
BBS.  This is longer term issue.  It probably doesn't need to get addressed
to get the basics functioning.  It might need to get addressed when it
comes to figuring out the download issues.  Yes, I also want to be able to
get to Maximus via TCP/IP based connections.

...
 BS> Yes.. Well it could call Maximus directly, like fx. it does with MBSE...

 BS> Then the telnet IO module, will be useless, because it 
 BS> could smoothly be called from inetd.

The telnet IO module?  If you mean your existing code for running as a
TCP/IP service, that should be minor.....  Most programs that can be
started under inetd also can be run standalone or via the same code that
runs inetd.  I believe this is done with relatively minor code differences
and probably a command line switch.

 BS> So it's the arguments of what max is beeing called 
 BS> with, there is telling max if it's a telnet user or a 
 BS> dialup user..

Maybe, maybe not.

 BS> Inetd calls a program with -h hostname and other 
 BS> arguments, mgetty calls it with -b connect bound ... Or 
 BS> something.

But getty can be (is) used with both TCP/IP and serial port (including
modem) connections -- at least in a standard Unix environment.  On the
surface, it doesn't matter to the application if the pipe is comming in via
TCP/IP or via a serial port.  And if the "hangup" signals are
properly implemented, max shouldn't need a command line switch to
differenciate either, as long as appropriate defaults are used for
unspecified command line options.

 BS> But in a unix environment, i really can't see the 
 BS> difference of a TELNET call or a POTS/ISDN call.

 BS> I wonder if the operating system can?

At a low enough level, yes.  One of the problems with some folks
imeplementing the isolated one or two modems on a unix system was folks
didn't always turn on the options to "logout" when modems got
disconnected.  It's not a good security "feature" to be able to
call back on a modem line and pick up exactly where you left off -- without
any login prompts.  This was a fairly common mistake on systems where most
users came in via hardwired terminals or telnet'ed into the system....

 BS> The idea in having maximus listening on a port, could 
 BS> be it would control the chat system and so on, but it 
 BS> doesn't do that... 

What did you have in mind?  The current maximus chat option is not
dependant on listening to ports.....  If Maximus is running under it's own
user ID and file space in a Unix / Linux enviornment, we should be able to
keep a table (i.e. set of files) of active users around like Max does for
the OS/2 implementation.  When my OS/2 gets shut down improperly with some
one logged in to Maximus, the next time Max runs on that node number, the
table gets cleaned up and the error noted in the Maximus log.....

...
 BS> Well i don't have the big interest in using Squish, 
 BS> because it get all what squish can with the hpt tosser 
 BS> from the husky project..

Ok.  That's reasonable for now.  I believe the Husky project has the Squish
stuff debugged at this point.....

 BS> Even more, it share configfile with my ticker, 
 BS> msgeditor and other programs.

Understand.  I haven't broken down to configure fidoconfig yet....

 BS> I wrote a quick and durty C program there is using the 
 BS> fidoconf-liberay to get hpt's area configuration and 
 BS> write msgareas.ctl.

That will be a usefull conversion tool that we should include in a Maximus
/ Linux-Unix disstribution.  It would also be usefull to go the other
direction (msgareas.ctl --> fidoconfig configuration) if possible.  On
the other hand, awk or perl scripts could probably also be easily whipped
up for this.

Take care.....

Bob Jones, 1:343/41

--- Maximus/2 3.01