WG> Okay, this message is addressed to all because I'm 
 WG> compacting replies to about
 WG> 75 different messages into one. Holy cow, I can't believe the traffic on
 WG> MUFFIN!

Thanks for the reply....  I'm running out of time to respond, so I'll
probably respond more completely late Sunday or later....

 WG> haven't used CVS before, but I'm sure I can figure it out. If it's
 WG> possible to mix CVS "versions" and RCS tags, I'll just
RCS the whole
 WG> shooting match showing revisions and revision logs on the original
 WG> sources starting from "nothing" and moving to
"now". (I use RCS + custom
 WG> versioning software at work). Once I get that up there properly, I'll
 WG> also be granting Bo and Andrew CVS commit access.

CVS originally used RCS as a back end.  So, any RCS work should work in
CVS.  I'm not up on the lastest versions of CVS though (read that since CVS
dropped using RCS as the back end)....
...
 WG>  - Are you aware that the max sources included the dmake sources? You

I attempted to both compile dmake from the source (end up with some unix
file name issues in a DOS / OS/2 file name data structure) and to use the
compiled versions of dmake I had access to....  DMake would "run"
but not do anything....  :(  I never got past make issues.  I was
contemplating switching to (the standard) GNU make, but hadn't gotten to
that point yet.....  Now the that you folks are compiling with the standard
make, the switch (for now) to the standard Linux make setup has happened. 
This should eaily back-port to OS/2 using the EMX port of the GNU C
compiler.....  And maybe work with the GNU make port to OS/2 using the open
watcom compiler.....  Time will tell.  But I think I will be switching
development to the Linux system for now, since that's my long term intended
target and you are succeeding there.  Yes, long term, I want to see the
code compile in both OS/2 and Linux.  And if that happens we should be able
to keep Win32 capablity, and maybe even old DOS 16 bit compatiblitiy *if*
we are lucky and/or careful....  

And yes, I expect binary data structures to possibly break when we finally
compile and run on a 64 bit platform.....

 WG>  - Starting under a getty -- I had considered this option, but have
 WG> temporarily abandonned it. It shouldn't be hard, as the comm code is
 WG> pretty well tucked away in one library (libcomm.so) on the UNIX side.
 WG> Right now, it only supports one communications method per build, but I
 WG> have set it up so that it should be easy to add more, by turning the
 WG> current library code into a stub that calls dlopen() to load the right 
 WG> code for the right maximus instance. I actually switched HCOMM
 WG> (maximus communications handle) to an incomplete type, and modified the
 WG> max_fos* code to run happily with it like this (not yet in current source
 WG> tree).  The important thing is that the getty/calling program has to pass
 WG> off a device filename (which is NOT the controlling terminal) to Maximus,
 WG> and I need to modify max_args.c to support this (Scott 
 WG> changes everything  
 WG> over to ints as quickly as possible, where 0=COM1: -- I reused the ints  
 WG> to mean port numbers in the tcp/ip driver)


Ah, yes....  The fun of the "controlling terminal" in linux.  And
yes, I expect this to cause problems with the current Maximus code.  Can't
we close stdin, stdout, and stderr once the code is running and then open
what we need for file handles?  I do remember some versions of Unix still
had "controlling terminal" issues if you did this....  And if I
remember right, getty sets up the terminal as stdin/stdout/stderr where Max
would expect that to be the system console and not the remote user..... 
So, supporting modems (short term) might not be via getty.....

 WG>  - Starting from a mailer -- I don't see any point to this in tcp/ip 
 WG> mode. Again, the mailer can't pass around the socket as stdin/stdout for
 WG> the reasons mentioned above. I suppose we could hack at the mailer a
 WG> little and come up with a better technique (e.g. pass_fd(), Stevens UNP
 WG> II), but it's not like we're limited in terms of numbers of tcp/ip ports.

BinkD is not an FTS-0001 (or is that FTS-0005) compliant mailer.  It is a
good TCP/IP based Binkley Style Outbound compatible mailer.....  Mailers
are a side issue to what we are doing....  And I don't see a need to have
Binkley answer in front of Max for now....  (MGETTY should do what I need
with Max running under MGETTY or under a login shell....).

 WG> (unless that filedescriptor > 2).



 WG>  - There is no way in h-e-double-hockey-sticks that I can see that
 WG> Maximus will support non-vt100 terminals in inbound caller mode. OTOH, if
 WG> we can securely run "max -k", we could make use of the
fact that the
 WG> "local" video is implemented with curses. I'm sure I'm
not the only one
 WG> who wants to log in from a Zenith Z19. ;)

Ah, yes.... the old Z19....  Used that on a number of systems....  

I think we are in basic agreement about this issue.....  It would take too
much work (at this time) to switch from the hard coded escape sequences to
a curses type library....

 WG>  - Hey, good thinking about the other end maybe sending a control-S in 
 WG> the ANSI response sequence. Maybe I need to take a look at the telnet
 WG> flow control options. It's my intention to masquarade the tcp/ip comm
 WG> library as a hardware flow controlled 38400 bps modem running 8n1. 
 WG>  
 WG>  - Handling modem options (parity, stop bits, wordlength, cbreak, etc) is
 WG> cleaner with termios than making ioctl()s. termios is POSIX. i/o is still
 WG> handled the same way -- a fd is a fd is a fd.


Ah....  termios vs ioctls....  Thanks....  And I haven't had to directly
program modems under Unix, but I recall there were some issues you pointed
out below.  It may be time for a kernel change in Linux to add some modem
feature support.....  I'd like to see (m)getty handle the modem RI, DTR,
DSR, and maybe some other RS-232 hardware lines properly.....  My modem is
a USR Courier HST V. Everything modem (with X2 and the later V.90 support).
 For voice modem, I'd want to use distictive ring info from the Courier to
handle answering an old Zyxel (1492e+ ?) modem.....  But that's outside the
scope of the Maximus code....

 WG> great place to do code comparisons from.
 WG>  
 WG> Bob:
 WG>  - On modem control and security -- one thing that we have to remember is
 WG> that under UNIX, you can't easily control a modem which has lowered DCD  
 WG> (meaning you can't send init strings, ATA, etc). My general solution for
 WG> this is to run the modem in &D2 mode, and make sure you toggle DTR
 WG> between calls (baud=0, sleep(1), baud=!0). This requires configuring the
 WG> modem in &c1 mode in the NVRAM, however, and make it difficult to
 WG> detect a carrier. The other option I tend to use is to not try and   
 WG> initialize the modem at all, and set it up with S0=1 from the NVRAM.
 WG> Neither of these solutions are particularly attractive to me for BBS use.
 WG> One possible option would be to build a custom serial cable, and switch
 WG> DCD with, oh, DTR or something. But that seems kind of stupid.  I think
 WG> the solution I will use is to run the modem in &c1 mode from the NVRAM,
 WG> answer with &c0A, and hang up with &c1h. This could cause
the serial port

Ah....  Interesting....

And you've hit Max's limit in OS/2 for being able to quote a message for
replying....  

Take care.....

Bob Jones, 1:343/41


--- Maximus/2 3.01