Arrrgggghhhhh.....  We're starting to exceed the limitations of the built
in maximus full screen editor for replying to messages....  At least
dumping the message to a file and reading that file with the maximus built
in full screen editor still works....  So, the quoting below will be
slightly screwed up.

:(


>> Hello Bob!

Greetings, Bo....
 ...
 BJ> * BSD 4.3 on old Vax 11/780 based (and newer) hardware...
 BJ> * Various flavor's (and renames) of DEC's version of Unix (Ultrix, 
 BJ> True64, etc.), on various DEC based equipement (DEC-20, Vax 11/780, 
 BJ> Alpha, etc.)
 BJ> * Hmmm....  Sun's variation of Unix (Solaris?) 
 BJ> * NeXT Step (3.1, 3.2, 3.0, 2.?), which is really the NeXT Step GUI 
 BJ> on top of a BSD (4.3?) flavor of Unix running on a Mach kernal.
 BJ> * Irix (System V based) on 
 ...
 >> Ok, you've worked in somekind of companey where they used those unixes?

Not a single company.  Multiple companies, colledge, etc. For the most
part, BSD flavored unix is BSD flavored Unix, and the other flavor was
System V (five) based....  

...
 BJ> Hopefully, any protocol that leads to an FTS based fidonet session 
 BJ> will be handled prior to Max starting, so I see no reason for Max to 
 BJ> call a mailer.  There are no options for Max to call the mailer under 
 BJ> OS/2 or DOS when Max is used in a wait-for-caller mode (i.e. where 
 BJ> Max answer's the phone line)....

 >>  No, me neither, but i'm rather comfused about the case.

I guess I'm not sure what you are refering to.  I never used EMSI (or
similar) hand shaking with BBS's that passed user name / password info from
the front end mailer to the BBS, so I'd have have to look at that FTS
standard to see how that's supposed to work.  I think you have spotted
something trying to deal with that issue....  Where a user's terminal
program could be quiried for an auto-login type sequence.....  I don't like
to do things that way due to security issues....

...
 >> then max -k should be copied and rewritten a bit, so it asked about 
 >> username/pwd, and it might work then.

Warning: Using max -k could be dangerous to your BBS's system security.....
 The -k option was used for a local sysop login, and is used to initialize
the user database if one doesn't exist.  So, if max cann't find the user
database, and a user comes in with -k (because they can on the local
machine), then they could take over full control of the BBS portion of the
system....

 >> The is some IO problems about using the telnet-curses module.

Ok....

...
 BJ> That's why we should be using a flavor of getty for answering the 
 BJ> serial ports or even TCP/IP "telnet" type ports.  [The
TCP/IP telnet 
 BJ> ports used to be PTYxx while RS-232 based ports used to be TTYxx on 
 BJ> most systems I've used.  Ah....  I see PTS# under my Debian Linux 
 BJ> setup for the pseudo terminals instead of PTYxx devices.]

 >> That's right, but what the problem about communicating thru ttySX?

What problem?  ttySX is the hardware rs-232 based serial ports.  

 BS>> You don't see my point?

 BJ> We may still have a communication gap.....  I'm not sure....

 >> If i understand you well, we mostly agree.

I think so, And while you have excellent command of the english language,
there may some suttle translation issues between us that I'm not
recognizing, leading to me inturpreting what you said differently than what
you were thinking.....  This is a general problem with written
communication, even when both speak the same language natively....  And I
may be out of sync with Linux on one or more technical issues.  I assume a
fair amount of background based on BSD flavored Unixes, but Linux is a
System V clone.....

 BJ> If the Unix error /signal 
 BJ> handling (interupts) are properly implemented, then a disconnect 
 BJ> (modem hang up or TCP/IP port closure) comes in to Max with the 
 BJ> proper signal.  

 >> Oh i see, for example MBSE, have a mbtask manager there ensure that the 
 >> processes whitch doesn't exist is beeing killed.

Technically, the (running software)  processes still exist, but they need
to be killed because the physical connection has been broken or
disconnected.

 BJ> I'll admit I haven't looked at how Linux may be 
 BJ> different than BSD flavored Unixes in this regard.....  I may be 
 BJ> getting into differences between System V and BSD flavors....  And 
 BJ> Linux was (originally?) a System V flavored clone.

 >> Linux is a sysv flavored clone.. But it's only about the
initializing  >> method?

No.  There are some (at time subtle) differences between SysV and BSD
flavored Unix.  From memory, socket handling (at a low enough level) *is*
one of the areas where the differences surface.  


 >> I/O is quite the same in most unixes?

For the most part, but not completely.  On this item I have to stress that
a fair portion of my experience is prior to the POSIX standard getting
implemented, so, at times I have had to drop to BSD based (or Sys V based)
methods (such as IOCtl calls).  While I've done some RS-232 serial port
stuff under NeXT Step (a BSD 4.3 based unix system), and even had modem(s)
running under NeXT Step for UUCP (UUCICO) based connections, I haven't had
to deal with full time, regular, dial-in via modem to a RS-232 port on a
Unix based box.  [Security was accomplished by disconnecting the phone line
when the dial-in modem was not needed, among other ways.]

 BJ> Now it may matter for when Maximus needs to disconnect the 
 BJ> session.....  Because Max may need to force the modem to hang up in 
 BJ> that case.  

 >> As it's now does maximus sends a ATH even over telnet.. if we are 
 >> communicating between ttySX it should be possible.

That is the software attempt at hangup.  Maximus also tries to perform a
hardware hangup of the modem (dropping dtr, or another RS-232 control line,
based on a bit map mask and IO call to a (MS/PC) DOS interupt call that
handles all RS-232 serial hard wire control lines).  We need similar
capbility in the Unix / Linux port, but getty may be the solution.  I think
it can be (in a BSD flavored unix) done via IOCtl calls.....  

 >> Maybe it should be +++ATH+++..

No!  This should be a configuration item.  Some BBS's change the +++
sequence to a differnet character.  And the +++ sequence also involves
timing of a delay between certain characters.....

 BJ> On the other hand, the system services code that 
 BJ> (re)starts getty (or getty it self) may need to be properly 
 BJ> configured to "hang up" the modem when Max closes out the 
 BJ> session.....

 >> That's right..

After thinking about it, I have another solution to offer....  One that
leaves maximus started as a TCP/IP server /dameon.  Instead of having
(m)getty handling the modem, Max acts as a wait for caller for the RS-232
based nodes, and could be implemented with the startup of the TCP/IP demon.
 The existing Maximus for OS/2, DOS and Win32 has that as an option. 
Unfortunately, this does not solve the Fidonet front end mailer needs, and
is why I don't use that option with max.....

...
 >> Well the TCP/IP thing works now, so i'm doesn't care about it
now.. And  >> i'm satisfied about that method maximus is running over
with tcp/ip.

 >> The POTS/ISDN handlingen is what i care about.. 

Well, if we get POTS/ISDN handling via modems hooked up to serial ports
handled by (m)getty, we also get TCP/IP capability via (m)getty....

Ok.  Enough on that issue.....  We're in basic agreement.

 BJ> Your TCP/IP based code may be the better solution 
 BJ> for the short term, since you know understand what you are doing 
 BJ> there....

 >> It's not mine ;)

Ok...  Thanks to Wes, and the rest of you for debugging what is working....

 ...
 BJ> Ah....  Yes....  If Maximus was a TCP server (deamon), and if all 
 BJ> Maximus nodes were TCP/IP based, then yes, we could rely on the 
 BJ> internal chat function relying on a parent / child process and the 
 BJ> items this allows (potential common memory, or pipes, etc.).  
 BJ> Unfortunately, this doesn't handle (a) a local console session (moot 
 BJ> point with telnet to local host), or (b) serial port based 
 BJ> connections (needed for the modem based sessions).....  

 >> Excatly.. my i really doesn't see a good reason to use IPC.

It's needed for in Maximus for (a) Chat function, (b) Who is on function,
and I believe one or two other items.  The Chat function is not needed
because one could instead use the Unix talk command / program.  The
who-is-on function potentially could be obtained from a 'ps' output, if we
put the needed info on the line.....

 BS>> If one process was fork()ing them all, there could be 
 BS>> inter process communication, so the chat system and so 
 BS>> on will be working, multinode.

 BJ> Ah....  As I mention above, this only handles the TCP/IP based 
 BJ> sessions if max is a TCP/IP server / deamon.  Another method is 
 BJ> running a chat deamon for Maximus, and have each node connect to it 
 BJ> for interprocess communication.  I believe Max under OS/2 does 
 BJ> something like this.  If I remember correctly, if Max doesn't see an 
 BJ> IPC process running, it starts it, and in either case then connects.  
 BJ> Chat, Who is on, and maybe one or two other things use this piece of 
 BJ> code....

 >> It's controled by writing/reading files afaik. But it's too
somekind of  >> IPC, 
 >> the way i thought about was send()/recv().

I've got to look up send()/recv() functions to refresh my memory, but we
are in basic agreement, all of this runs via some sort of disk file space /
structure to accomplish inter-process communications.  

 BJ> Which is why compatibility with fidoconf via some methoid (scripts, 
 BJ> direct support, etc.) will be useful in the Unix / Linux environment. 
 BJ>  And with the Husky tool set ported to OS/2 and Windows based 
 BJ> environments, will also help there.

 >> All the husky tools works on OS/2 and Windows too?


I believe, YES.  I believe the husky tool set has now been compiled for
both OS/2 and Win32 platforms.  I believe I've seen both OS/2 and Win32
binaries for all the Husky tools come done one of my filebone feeds.  So, I
*think* I have the binaries (and possibly source) on my BBS....

 >> My BOSS runs hpt/OS2

I haven't configured fidoconfig for either Linux or OS/2, so I haven't
tried to run the husky tools in either environment yet.  I have
contemplated it, but figured the current system wasn't broke in this area
(under OS/2).....  

...
 >> And i did some corrections in msgapi too..

Interesting.  What needed correcting in the msgapi?  Was this the Maximus
msgapi, or the versions of the api previously ported to Linux / Unix
systsems for use by such things as the husky project?

 BS>>     * Maximus should be called from mgetty, after it 
 BS>> detects it's a human call.

 BJ> Be it hardwired terminal, modem, or a (telnet or TCP/IP) pseudo 
 BJ> terminal connection.....

 >> Hmm?

I think you start to see one way that I view running Maximus under Linux,
where all nodes will be configured the same way -- under (m)getty, and I
get both modem, local and TCP/IP all in one shot.....  Or did you have a
specific question about this?

Take care.....

Bob Jones, 1:343/41

--- Maximus/2 3.01