OS/2 Professional

home *** CD-ROM | disk | FTP | other *** search

/ OS/2 Professional / OS2PRO194.ISO / os2 / com / bbs / maximus / os2.doc < prev next >

Wrap

Text File | 1991-11-04 | 21.6 KB | 533 lines

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 -