Contents
1 Introduction . . . . . . . . . . . . . . . . . 1
2 System Requirements . . . . . . . . . . . . . . 1
3 Installation . . . . . . . . . . . . . . . . . 2
4 Maximus/2 and BinkleyTerm . . . . . . . . . . . 2
5 Differences from DOS version . . . . . . . . . 3
6 Multiline Operation . . . . . . . . . . . . . . 5
7 The MAXPIPE program . . . . . . . . . . . . . . 5
8 The PMSNOOP program . . . . . . . . . . . . . . 6
Index 8
1 Introduction
In addition to all the features mentioned in the main
documentation, Maximus/2 2.00 is different from version 1.00 in
the following ways:
* Version 2.00 uses MAXCOMM.DLL instead of COMM.DLL. The
Comm API is the same; the DLL name was changed because
of a conflict with another product.
* All low-level message handling code is contained in
MSGAPI.DLL. Maxp.exe and many other utilities use this
code (SILT, SQUISH, etc). It is our hope that third
party developers will use this API/DLL to access
messages, rather than trying to do so directly.
2 System Requirements
Because OS/2 uses virtual memory it may be possible to run
Maximus/2 with less than the following configuration, but it is
not recommended.
* OS/2 Version 1.20 or greater. It may be possible to
run Maximus/2 with earlier versions of OS/2, but it
was not tested.
* Memory: For a single line system (one copy of
Maximus/2 running), you should have, at least, the
amount of memory recommended by your version of OS/2.
For IBM OS/2 1.30, this is 3MB.
As you add more phone lines, and/or faster modems,
you will have to increase the amount of memory in your
system if you want to prevent file transfer overruns.
This is especially true if you have an 80286 processor.
If your system is a mail-only system (no file
transfers), this may not be as large a concern.
* If using an 80286, you should have PROTECTONLY=YES in
config.sys. This prevents interrupts from being lost
by switching to real mode; a very slow undertaking on
that processor. Even on an 80386 or I486, if you are
using high speed modems, switching to the dos box may
cause bytes to be lost (this will not be a concern with
OS/2 2.00).
* Unless there are very extenuating circumstances, you
should leave the config.sys PRIORITY parameter set to
the default setting, DYNAMIC. By setting it to
ABSOLUTE, you turn off OS/2's pre-emptive
mutlitasking.
* Maximus/2, like all OS/2 RS232 software, does not
require a "FOSSIL" driver. OS/2, unlike MSDOS, is
shipped with a proper device driver for the serial
ports. The driver is called COM0x.SYS (where x = 1 for
ISA computers, and 2 for Microchannel).
Unfortunately, most (if not all) versions of OS/2 have
shipped with a COM0x.SYS file that is broken in some
way. Included with this package are Gerry Rozema's
(1:153/905) COM16550.SYS and COM16450.SYS drivers.
These are replacements for COM01.SYS, and seem to work
better than the standard issue. Both drivers are
contained in COM16550.LZH.
* HPFS is strongly recommended. A ten-fold (or greater)
performance increase can be had if you have large *.MSG
type messages areas.
3 Installation
Maximus/2 is installed the same way as Maximus/DOS, using the
provided installation program (INSTALL.EXE), with the exception
that it should be installed from an OS/2 session, not DOS.
INSTALL will copy 3 DLLs (MSGAPI.DLL, MAXCOMM.DLL, SNSERVER.DLL)
to your C:\OS2\DLL directory, which it needs to complete
installation. These DLLs are also copied to your Maximus system
directory. After installation, you may wish to erase the DLLs
copied to C:\OS2\DLL, and add your Maximus system directory to
your LIBPATH in config.sys. If you are at all unsure about what
some of the terms mentioned in this paragraph (DLL, LIBPATH,
CONFIG.SYS), then do nothing. Maximus should work as installed.
4 Maximus/2 and BinkleyTerm
Currently, the only fidonet mailer available for Maximus is
BinkleyTerm. This section discusses running Maximus/2 with
BinkleyTerm as the front end.
* BinkleyTerm *MUST* use the "BBS Spawn" method to load
Maximus. Furthermore, you must start BinkleyTerm with
the SHARE command line option ("BTP SHARE"). These two
options cause Bink to pass the opened COMM handle to
Maximus.
* Maximus must be passed the FILE HANDLE of the opened
COM: port from binkley. Using the sample batch file
(spawnbbs.cmd) supplied with this document does this
properly. DO NOT try to hard code this value. Passing
a '1' for COM1: will NOT WORK!
- 2 -
* ALL serial port options (bps, parity, handshaking) are
inherited from BinkleyTerm. Maximus does not open,
close, or alter the COMM parameters in any way, except
for XON/XOFF flow control. Therefore, the MAX.CTL
"Mask Handshaking" statements for CTS and DSR do
nothing. XON behaves as described.
NOTE: Later versions of BinkleyTerm may act in much
the same fashion, so it may be necessary to use the
"MODE COMx:" command to set up your port before loading
BTP.
5 Differences from DOS version
* In WFC (wait for caller) mode, Maximus/2 only polls
the keyboard about every 2 seconds. Therefore, please
be patient if you hit ALT-X or ALT-K, etc. This was
done so that a negligible amount of CPU cycles are used
while Maximus/2 is waiting for the phone to ring.
Modem responses are handled immediately.
* The "-p" command line option (which specifies the port
number under dos) specifies file handle of the comm
port. Binkley passes this open handle to SPAWNBBS.CMD,
which in turn passes it to MAXP.EXE. Do not try and
pass something like '-p1' for COM1:, '-p2' for COM2:
etc; it will NOT work!
* The "-b" command line option (bps rate) is only used in
calculations, and does not change the data rate of the
comm port. For example, Maximus uses this number to
calculate the throughput of file transfers. If your
modem is "locked" at a high baud rate (19200, for
example) Maximus will communicate to your modem at
19200 (or whatever speed BinkleyTerm was using when it
spawned the bbs), but will base all time calculations
on the rate passed with the "-b" parameter. Therefore,
the "LOCKBAUD" concept is totally transparent to
Maximus. If BinkleyTerm is happy, so is Maximus.
New Maximus 2.00 feature: In WFC mode, the -b command
line parameter is not ignored. See also the -s
parameter (steady bps rate) in the normal Maximus
documentation.
* The "-z" command line option is used by the
OS/2 version to name the NamedPipe that connects to a
PmSnoop session. The -z parameter must be followed by a
pipe name, with no spaces. example: "-z\PIPE\LINE1".
If this option is not used, the default name of
- 3 -
\pipe\maxsnoop is used. For more information, see the
section on PMSNOOP, below.
* External programs ("DOOR" programs) must be called with
the "Extern_Run" command (see menus.ctl). Actually,
this may not be true; but the other Extern_* commands
seem rather silly to use under OS/2, and were not
tested. I guess Extern_Dos would work ok, but I don't
see many uses for calling a batch file (since Maximus
has such a rich set of '%' commands to use with the
Extern_Run command).
* For the same reasons that the Extern_Erlvl and
Extern_Chain commands are not recommended, restarting
Maximus with the "-r" switch is a lost concept under
OS/2, and was never tested.
* The "%P" (case significant) command (Used with
Extern_Run, among other things) passes the comm handle
in ascii decimal. For hysterical reasons, the "%p"
option (lower case) will pass a number that is equal to
one less than the comm handle, so you should steer
clear of this.
* The only way for external programs to use the comm port
is to accept the file handle to the comm port, unless
they are simple programs that use stdin and stdout. In
the latter case, MAXPIPE (or something similar to it)
should be used to redirect stdin and stdout from/to the
com port. Using the ">" and "<" redirection options
provided by the Extern_* commands is not recommended.
* Due to (what I consider a design flaw) in the COM0x.SYS
driver, ^C/^K checking in the os/2 version is a kludge.
^C/^K must be the FIRST key you press if you are to
successfully interrupt the bbs. If any other key, or
line noise, is put into the input queue before the
^C/^K, the ^C/^K will not be processed until the BBS
wants user input (like at a menu prompt).
- 4 -
6 Multiline Operation
All files/file areas/message areas can be shared by multiple,
concurrent copies of Maximus, except for the log file and those
files governed by the "task number" (the -n command line option),
and the named pipe used for PmSnoop. Since all of these can be
controlled with command line parameters, you therefore only need
one MAX.CTL. For example, one of your sessions may look like
this:
maxp max -b%1 -p%2 -t%3 -n1 -lLINE1.LOG -z\PIPE\SNOOP1
And a second like this:
maxp max -b%1 -p%2 -t%3 -n2 -lLINE2.LOG -z\PIPE\SNOOP2
7 The MAXPIPE program
This program uses anonymous pipes and multiple threads to
redirect "standard i/o" (stdin/stdout/stderr) to/from the comm
port. It also provides a "watchdog" feature which monitors the
carrier.
If the carrier drops, MaxPipe kills the process it is running,
and any children it may have spawned, and returns control to
Maximus. Maximus will promptly notice the lost carrier, and log
the caller off.
If the comm handle passed to MaxPipe is 0, the watchdog feature
is disabled. (Maximus passes 0 when the sysop is logged on
locally).
MaxPipe is invoked thus:
MaxPipe <comm handle> <program> [arguments]
Where : <comm handle> is the open comm handle,
probably passed via the "%P" Maximus thingy.
<program> is the program you want to run. If
it is not on the path, be sure you specify
where it is.
[arguments] are any optional command line
arguments you want passed to <program>.
Here is a snippet from my MENUS.CTL, which uses MaxPipe:
Xtern_Run MAXPIPE.EXE_%P_ADVENT normal "Adventure"
Xtern_Run MAXPIPE.EXE_%P_CMD Sysop "!Shell to OS/2"
- 5 -
NOTE: If programs (written in Microsoft C or IBM C/2) use the
popular getch() function (read a key), they will not
work correctly with MaxPipe. For some reason, the
os/2 version of getch() was written to call
KbdCharIn(), rather than read from stdin. For
example, if PKZIP prompts you for any reason (like when
you enter PKZIP with no arguments, to get the Usage
screen) you will not be able to send it keystrokes.
Your only option is to hang up (no big deal -- the
system will recover lickety-split).
Maxpipe is a simple program, written only to keep CMD.EXE happy.
It buffers the byte streams a bit (100 bytes, I think), which
makes a drastic improvement in performance. However, this may
make some programs behave oddly. If you stick some
fflush(stdout) statements in the code just before you ask for
user input, it will solve this problem. Command line utility-
type programs, that don't get user input, won't have this
problem -- but you will notice the output (or the last 100 bytes
of it) may be delayed until the program completes.
8 The PMSNOOP program
Making a PM program out of something like BinkleyTerm or Maximus
is a silly idea, since these programs (from the sysops
perspective) are "read only" programs that are, for the most
part, MONITORED rather than INTERACTED with. Running this type
of program in a VIO window, where you can keep your eye on it
while using a PM app, just slows the program down
(significantly), and clutters the desktop. Pmsnoop, the way
Maximus uses it, gives the sysop a realtime view of the logfile.
Since PmSnoop uses named pipes, the sysop could actually monitor
the bbs from a different computer (via Lan Manager/Lan Server).
Each copy of the bbs you run (including the one you use to logon
locally) should use a different pipe name. (Although you don't
have to run pmsnoop for each, if you don't want). If you don't
do this, the pipe will be given on a "first come, first serve"
basis, where all but the first copy of Maximus will receive an
error when they try to create the pipe (this is NOT a fatal
error, and the bbs will run without any problems).
For each copy of pmsnoop you use, you need to tell it about the
pipe name you used with MAXP.
A pipe name must ALWAYS start with \pipe\, or \\server\pipe\
(yes, that is TWO slashes in \\server!), where \\server is the
name of another computer on the LAN. Since Maximus is the
server process (and pmsnoop is the client), if you are using
LanMan (Lan Server) prior to release 2.00, Maximus must be
running on a network server to connect to pmsnoop on another
computer (ie: If Maximus was on a workstation, and pmsnoop was
- 6 -
on a netserver, it would not work). This problem should
disappear with the "peer services" provided by LanMan 2.00.
Each copy of PmSnoop you load will recognize that it is not the
only copy running, and will use a different profile from OS2.INI
to load its options. Therefore, when you "save options", or
use the Desktop Manager to save the desktop, each copy will
store its pipe name, position, and font separately.
The server end of the named pipe (used by Maximus) was
implemented in a DLL (SNSERVER.DLL) so that other programs can
use it too. The Snoop() API is quite simple, and is published
with the Maximus source code. BinkleyTerm 2.40+ supports
SNSERVER.DLL too.
The general idea here is that each program serving the same phone
line use the same named pipe. When BTP spawns the bbs, it
closes the pipe and the bbs opens it, etc.
SNSERVER.DLL does all of the named pipe magic. It does not
expect either pmsnoop.exe, or the server (binkley and/or bbs) to
be running at any given time. ie: You can start and stop the
programs at will, or neglect to start them. A protection
violation (or other death) of either program will not affect the
other.
Pmsnoop does not use snserver.dll. Only the server process does.
All other aspects of Pmsnoop should be obvious. I apologize for
not installing online help, but my mandate was to build a
program that worked under both OS/2 1.10 and 1.20. The help
manager is not available under 1.10.
There is no horizontal scroll bar when run under OS/2 1.10.
When selecting a different font, some older versions of 1.10 do
not engage the font correctly. The solution to this is to exit
Pmsnoop and start it up again; the desired font will now be
engaged. (I discovered this problem when running under the "MS
OS/2 1.10 Server Adaption" that comes with 3+Open 1.1. The fonts
worked correctly on the version of IBM 1.10 I tried.)
- 7 -
Index
80286 1 I
80386 1 I486 1
-b 3 INSTALL.EXE 2
%P 4
-p 3 L
-s 3 LOCKBAUD 3
-z 3
M
B MAXCOMM.DLL 1, 2
BinkleyTerm 2 MAXPIPE 4
MaxPipe 5
C Memory 1
COM16450.SYS 2 MSGAPI.DLL 1, 2
COM16550.SYS 2
COM0x.SYS 2 N
COMM.DLL 1 NamedPipe 3
E P
Extern_Run 4 PmSnoop 3
PRIORITY 1
F processor 1
fflush(stdout) 6 PROTECTONLY=YES 1
FOSSIL 2
S
G SNSERVER.DLL 2, 7
getch() 6
W
H wait for caller 3
HPFS 2 WFC 3
- 8 -