Okay, this message is addressed to all because I'm compacting replies to about
75 different messages into one. Holy cow, I can't believe the traffic on
MUFFIN!
 
For all those who told me to use WordStar commands in MaxEd -- it's been 10
years since I've used Maximus (actually, maybe 9 -- memory is fuzzy) -- and
it's definately been more than that since I've used WordStar! Once Max is
running stably on my platform, I think I'll pop emacs in as the "local   
editor". :)
 
Bob Jones:
 - I now have admin access on SourceForge, we need to get the maximus code up
there before we have a million trees on the go. I'll see what I can do this
weekend; my schedule has been a little more hectic this week than
planned, which means I haven't done much to Max in the last few days. I
haven't used CVS before, but I'm sure I can figure it out. If it's
possible to mix CVS "versions" and RCS tags, I'll just RCS the whole
shooting match showing revisions and revision logs on the original
sources starting from "nothing" and moving to "now". (I
use RCS + custom
versioning software at work). Once I get that up there properly, I'll
also be granting Bo and Andrew CVS commit access.
 
 - Thanks for the excellent summaries of Maximus behaviour. Exactly
the kind of info I needed to refresh myself, and figure out what to do with
multinode consoles. As long as curses doesn't get too snarky with me, I think
I will try to make the local consoles pipes in the long term (right now,
they wind up in the bit bucket). That presents the obvious problem of "what to
do with the data backlog", however.. I could either tie the pipes to
something that drain them regularly, or maybe trap SIGPIPE, have max drain
its own pipe (if not being used by the sysop) and then call refresh(). The
other option, I suppose, would be hacking at screen to try and tie each
Maximus node to a screen pty. I've never looked at the screen source code in
depth, however. [Background info: I implemented the OS-level video hardware
calls with curses, so max thinks the curses stdscr is the real screen]
 
 - I had forgotten about the clean up scripts that run at the end of the
session! (Bad Wes :).  Since I implemented the OS/2 semaphores that Maximus
and Squish use, you could theoretically cron squish to toss outbound mail
without killing your squish bases. That said, I implemented the spawnvp() call
which Maximus uses to fire up external programs.  I'm pretty sure I got all
the semantics right, but it's not unit tested (Hell, none of this stuff is 
unit tested). That said, squish uses it successfully to run the external 
archivers, and I do remember setting COMSPEC to /bin/sh somewhere in the max
code. So, it might already work. I really don't know.
 
 - Are you aware that the max sources included the dmake sources? You
might be able to fix dmake to work under your platform for building under
OS/2. That said, it would probably be more productive to come with better  
(more general) make files and use GNU make under OS/2. How familiar are
you with GNU make? You'll need to know how to build implicit (default) 
rules to kick your compiler into gear, but it shouldn't be too tricky.
I've used GNU make to build VC and eVC++ sources in the past. As for
using GCC under OS/2 -- I don't know anything about OS/2 so I can't
comment in much depth, but I'd bet you'd need to convert the .asm code  
into something usable by gas... but I don't know if the .asm code was
meant for the OpenWatcom compiler, or MASM, or what (didn't spend much
time with it, obviously -- I'm not even running Intel arch).
 
Bob & Bo:
 
 - Starting under a getty -- I had considered this option, but have
temporarily abandonned it. It shouldn't be hard, as the comm code is
pretty well tucked away in one library (libcomm.so) on the UNIX side.
Right now, it only supports one communications method per build, but I
have set it up so that it should be easy to add more, by turning the
current library code into a stub that calls dlopen() to load the right 
code for the right maximus instance. I actually switched HCOMM
(maximus communications handle) to an incomplete type, and modified the
max_fos* code to run happily with it like this (not yet in current source
tree).  The important thing is that the getty/calling program has to pass
off a device filename (which is NOT the controlling terminal) to Maximus,
and I need to modify max_args.c to support this (Scott changes everything  
over to ints as quickly as possible, where 0=COM1: -- I reused the ints  
to mean port numbers in the tcp/ip driver)
 
 - Starting under inetd -- I don't know if this worthwhile pursuing. It    
doesn't really gain us much, except for additional access control via    
xinetd. If we wanted that, we could always use tcp wrappers. But why
would you want to limit access to your BBS? :)  .. the problem with
starting under inetd is that Maximus can't tell the difference between
the "local console" and the remote user -- dangerous (not to mention 
difficult to use -- the remote user has to turn the keyboard on before he
can login :) .. I tried dup2()ing STD*_FILENO in order to send
the local console to the bit bucket; no luck. I even tried rewriting   
stdin->_fileno; no luck there either (not mention the enormous
portability problem). I suppose we could go through the code and disable
the local console mode entirely based on command-line switches.. but that
doesn't really strike me as a productive use of development resources.
 
 - Starting from a mailer -- I don't see any point to this in tcp/ip 
mode. Again, the mailer can't pass around the socket as stdin/stdout for
the reasons mentioned above. I suppose we could hack at the mailer a
little and come up with a better technique (e.g. pass_fd(), Stevens UNP
II), but it's not like we're limited in terms of numbers of tcp/ip ports.
I just run binkd on one port, and maximus on the other..  Starting from a
mailer attached to a serial port is another issue, however. This is
obviously valuable. The same restrictions apply as for a getty -- need to
pass the filename of the character special device, not a file descriptor
(unless that filedescriptor > 2).
 
 - There's one more start mode which I intend to implement -- opening a
tcp/ip connection, raw or telnet, to a terminal concentrator which has an
attached modem bank. I have seen code for these which run local daemon to
provide a pty for each modem, but I've always found those to be more
trouble than they're worth. Yes, I have the facilities to test this. :)  
 
Andrew etc:
 - Debugging telnet sessions easy if you have a UNIX-based telnet. Drop  
to the telnet prompt, "toggle options" "set netdata".
The current tcp/ip
code supports only raw sockets or plain NVT ASCII (depending on a CFLAG).
So file transfers will not work. I currently negotiate WILL ECHO, DO       
SUPPRESS SGA, and hope the client supports them (I'm not aware of
anything build after 4.2 bsd that doesn't). I will patch the code at a
later date to negotiate a binary session; this will be optional. I'll
probably get that in there this weekend.
 
 - I'm not sure why the ANSI startup sequence would be hanging things up 
for you guys. It doesn't for me. :)  I'll try and take a look at that
sometime soon.
 
Bob:
 - There is no way in h-e-double-hockey-sticks that I can see that
Maximus will support non-vt100 terminals in inbound caller mode. OTOH, if
we can securely run "max -k", we could make use of the fact that the
"local" video is implemented with curses. I'm sure I'm not the only one
who wants to log in from a Zenith Z19. ;)
 
 - Hey, good thinking about the other end maybe sending a control-S in 
the ANSI response sequence. Maybe I need to take a look at the telnet
flow control options. It's my intention to masquarade the tcp/ip comm
library as a hardware flow controlled 38400 bps modem running 8n1. 
 
 - Handling modem options (parity, stop bits, wordlength, cbreak, etc) is
cleaner with termios than making ioctl()s. termios is POSIX. i/o is still
handled the same way -- a fd is a fd is a fd.
 
Bob/Bo/Mark/Mike:
 - Good call on the dupe checking! I seem to recall something about a
2-second granularity as well, which was giving me grief gating usenet
messages back in late '92. Looks like we'll have to update the dupe
checking in Squish, but I agree with Bob on the timing -- not until we
have a stable product should we try adding features! :)
 
Roy/Mark:
 - I'll be modifying the V)ersion message sometime soon to now show
Scott's old FTN address or his mom's snail mail address. :) I'm also       
going to try and get in touch with Harvey shortly and see if he'll
release some of his software open source (that areas.bbs makin' thing --
what was it called?)
 
 - Yes, Harvey, Scott, Tony Summerfelt and I are all NET249 guys. Not bad
for a city of 100,000. :)  'course back then, I was writing lame
call-back verifiers and such... in pascal under DOS. LOL.
 
Andrew and Bo:
 - I had a quick chat with Scott. According to him, he doesn't think he
changed the msgapi binary format or API from version 1.02 to 3.02; he
said the primary changes (that he could recall) were performance-related.
This means it might be possible to drop in SMAPI/XMSGAPI (or whatever
it's called -- you know what I mean) in its place. I'd be tempted to not
be too quick to do this, however, as there may be some hidden subtleties
in Maximus that depend on non-obvious msgapi behaviour. I think we're
better off getting the current product stable before we start grafting 
stuff on. That said, it does sound like a very good idea, is obviously a
great place to do code comparisons from.
 
Bob:
 - On modem control and security -- one thing that we have to remember is
that under UNIX, you can't easily control a modem which has lowered DCD  
(meaning you can't send init strings, ATA, etc). My general solution for
this is to run the modem in &D2 mode, and make sure you toggle DTR
between calls (baud=0, sleep(1), baud=!0). This requires configuring the
modem in &c1 mode in the NVRAM, however, and make it difficult to
detect a carrier. The other option I tend to use is to not try and   
initialize the modem at all, and set it up with S0=1 from the NVRAM.
Neither of these solutions are particularly attractive to me for BBS use.
One possible option would be to build a custom serial cable, and switch
DCD with, oh, DTR or something. But that seems kind of stupid.  I think
the solution I will use is to run the modem in &c1 mode from the NVRAM,
answer with &c0A, and hang up with &c1h. This could cause the serial port
to get in a 'hung' state, however, if a user drops carrier. If the modem   
supports &d3 (reset on DTR toggle), that will fix that, although not all
modems do. (Heck, I'm not even sure all modems support &c -- I know you 
can override carrier with a dipswitch on USRs -- most of my work is with
ZyXEL modem racks).
 
If anybody has any better serial implementation ideas, I'm all ears. Or,
for that matter, if you know how to control a modem with DCD set low,
preferably in a portable fashion :), that would solve the problem. I must
admit, I haven't tried to work around that issue since I first bumped
into it under BSDI 2.1 and Solaris 2.5.1 in .. 1997. Haven't needed to 
'till now.
 
**** later note ****
I think the DCD issue might just be if you configure the port for
blocking reads/writes. I'll have to play around a bit. It's just been too
long since I've tried something that isn't one of my "general solutions"
-- you know how lazy coders are. ;)
 
Bo:
 - Bob's right about chat; we don't need any fancy UNIX-style IPC for the
chat rooms to work; IIRC they work through IPC%02x.bbs which should work
just fine under UNIX. We may need to take a look at the locking semantics
in my sopen() to get that working properly (or the DosSem* functions in  
unix/dossem.c, depending on how Scott implemented the CB-style chats).  
 
[Hey, Bob, do you have a man page for sopen()?]
 
 - I'm going to include your conversion utility somewhere in the     
Maximus/UNIX package. Probably in the same directory as I've stuff the
archivers, if that's okay with you. What's fidoconf again?
 
Bo:
 - Project goals -- inetd has huge problems as discussed above. Serial 
via some sort of a getty or mailer handoff should be doable; native
serial DEFINATELY is. As for a telnet-only BBS -- I think that would be    
stupid. :)
 
I also have no intention of adding ftp/gopher/http/finger
into Maximus, if people want to use that stuff, they should use the
internet. A BBS should be a BBS, dammit. Doors *out* to the internet are
fine, but making a BBS look like a mini-internet always struck me as
being totally counter-productive. :)
 
Mike and Bob:
 - Binary compatibility with previous release of Maximus and Squish is 
very important to me. The biggest issue that still needs to be addressed
there (besides debugging the squish bases -- thanks, bo!) is the fact
that some of the configuration utilites (MEX and SILT, I think) still
get upset over DOS-style newlines. I'm pretty sure I fixed MECCA already,
I seem to recall diffing a whole pile of *.BBS files. MEX binaries may or
may not be cross platform. I'd like them to be, but pointer size issues 
may preclude compatibility on 64-bit architectures. Well, okay,
*inconvenience* compatibility on 64-bit arches. :)
   
All:
 - Scott sent me the wordprocessed version of the Maximus docs, so we   
should be able to update them for use under UNIX.

Cheers,
Wes

PS: Do I win the "long FTN message of the week" award?

--- Maximus/2 3.01