ProfitPress Mega CDROM2 Shareware Freeware (MSDOS)(1992)(Eng)

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

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / BBS / RBBS_PC / RBBSDOCS.ZIP / RBBSDOCS.14 < prev next >

Wrap

Text File | 1990-11-05 | 20.7 KB | 405 lines

THE USE OF RBBS-PC "DOORS" 14-1 14. THE USE OF RBBS-PC "DOORS" ------------------------------ A door is a program contained on the RBBS-PC machine which can be run by an RBBS-PC caller. This allows the BBS user access to functions other than those provided by RBBS-PC. After the door terminates, control returns to RBBS-PC. The concept of doors can be confusing and complicated, but from RBBS-PC's perspective, it is simple: When a caller requests a DOOR, RBBS-PC checks to see if the door exists. If so, RBBS-PC will create a DOOR signal file and exit. It is the responsibility of the invoking .BAT file (see section 13) to start the door. RBBS-PC will regain control when the invoking .BAT file ends. With this simplicity in mind, we will now explain the complex details of door processing: As a potential door installer, you should first become familiar with the door program, WITHOUT RBBS-PC INVOLVEMENT! Most door programs can also be run directly from DOS. Make sure the program works, and you understand it before you expect RBBS-PC to run it. Once you understand the door program, you must set up the interface to RBBS-PC. A sample door is included with RBBS-PC. The door (DOORTEST) does nothing, but it does show you how the interface works. 14.1 A Quick Start to Installing Doors -------------------------------------- To install the door, follow these steps: - Create the door batch file, and place it in the default RBBS-PC directory (DOORTEST.BAT is an example). This batch file should contain the commands needed to run the door, and then return to DOS). RBBS-PC will automatically restart after the door. - If you want maximum control over your door, create an entry in the DOORS.DEF file (see section 14.3). Without this entry, the door will still work, but you will be able to control more aspects of the door interface with this control file - Edit the MENU5 file (including the graphic and color versions) and enter the name of your door. The door name must be IN CAPS, and the first word on a line. The sample DOORTEST can be used as a guide. If the door name is NOT in all MENU5 files, RBBS-PC will allow the SysOp to exit the door, but your callers will not be able to use it. RBBS-PC uses the MENU5 as a security measure. If the door name is not found in this file, callers are denied access to the door. 14.2 The Major Problems with DOORS ---------------------------------- The hard fact about doors is that most DOS application programs that run perfectly fine locally will not run correctly for a remote caller. The general reason for this is that, compared the UNIX and even the old CP/M microcomputer operating system, DOS has very limited support for access to a computer from a remote site. The primary general problem is getting the application to take its input from the communications port rather than the keyboard and getting the application to write its output to the RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 14-2 communications port rather than the local monitor. In addition, even when input is redirected to the communications port, some remote keystrokes may not work, such as the function and arrow keys. Also, creating "full screen" effects on a remote BBS is difficult, because of the wide variety of monitors and terminal controller cards. Another general problem is how to pass information between the BBS software and the program doored to, such as limiting the amount of time a caller can spend in the door. Most applications also are programmed to wait indefinitely for input and will not time out. More seriously, if the caller drops carrier, the door should terminate and send control back to the BBS software, whereas most applications will totally ignore the fact that carrier drops. Finally, many applications let the user issue DOS commands from within them or even to drop to DOS, which would be an intolerable security risk for a BBS. The upshot of all of these problems is that most, though not all, applications that run acceptably as doors on BBS's have been especially designed to run as a door. 14.2.1 Redirecting I/O ---------------------- The main facility DOS provides in its operating system for redirecting I/O is the CTTY command. Unfortunately, this only works for applications that use standard DOS bios calls to do I/O rather than "directly write to the hardware". Unfortunately, the DOS bios for handling I/O is so slow that most applications directly write to hardware rather than accept a performance penalty. When SysOp function 7 is used, RBBS-PC will write out a door that does nothing but redirect I/O and drop to DOS, then terminate completely. What typically happens after the drop to DOS is that the output of an invoked program appears on the local monitor rather than the remote, so that the remote SysOp calling in sees nothing. While being limited to programs that use standard DOS callers and print a "line at a time" on the screen, scrolling prior lines up, CTTY has one major liability. When the output is redirected from the console to the communications port, nothing appears on the local monitor, so that the SysOp "snooping" on the BBS is unable to see what the caller does while dooring. This program is addressed by a device driver called GATEWAY which adds local echo to remote sending. It is installed in CONFIG.SYS. For doors, then simply say "CTTY GATE1" rather than "CTTY COM1". For drop to dos, simply tell RBBS-PC in configuration parameter 106 what device to use after specifying you do not want to use CTTY. CTTY does not work in every environment. For example, it is ignored under Desqview and does not work properly under TANDY DOS. Also, with DOS it fails to redirect standard error messages. To solve this problem STDERR.COM is included as part of the basic RBBS-PC system. This program was provided by Quarterdeck Systems. If you encounter this problem, run "STDERR.COM" one time only before you start RBBS-PC, including it in your AUTOEXEC.BAT file. An alternative method for redirecting I/O is to use DOS redirection on a command line. The ">xxx" redirects standard output to device xxx and "<xxx" redirects standard input to device xxx. So, invoking program "TEST" as follows TEST <com1 >com1 should send and receive from communications port 1, if the application supports DOS redirection. THE USE OF RBBS-PC "DOORS" 14-3 A shareware product called DOORWAY goes a long way toward getting applications never written to be a door to at least work remotely. You simply door to DOORWAY and invoke the intended door through DOORWAY rather than directly. While not every application will run, it does take care of most I/O problems. See the documentation of DOORWAY on how to install it. Programs written explicitly as a door will handle these problems themselves. 14.2.2 Exchanging Information ----------------------------- Most applications were never designed to take input from another running program. This creates a problem for BBS's, which almost always limit the session time a caller can have, so that the time a caller can spend in a door likewise should have a upper limit, preferably no more that the session time remaining that the caller has. One of the main advantages of applications written to be doors is that they are design to take information from the BBS. RBBS-PC has for years written out information in a standardized format, in a text file, for doors to read. This file is DORINFOn.DEF, where n is the node id (1-9,0,A-Z), written to the same drive/path as the caller's file, and consists of all text, one piece in information per line, in the following order: 1. The name of the RBBS-PC system 2. The SysOp's first name 3. The SysOp's last name 4. The communications port being used 5. The baud rate and parity with which the caller logged on, and the baud rate at which RBBS-PC is connected to the modem 6. The network type (if any) RBBS-PC is running in 7. The caller's first name 8. The caller's last name 9. The city and state the caller is from 10. The caller's graphics preferences 11. The caller's security level 12. The caller's time remaining in the current session 13. Whether fossil driver is used (-1 = yes, 0 = no) RBBS-PC macros allow any information to be written to a file for a door in nearly any format desired (see 13.4), as well as put different information on a command line for the door. RBBS-PC passes the node id as the first command line argument to the batch file it invokes (or as specified in the door control file) so that the DOOR knows which DORINFO file to read. There are external utilities for converting DORINFO interfaces to other formats, for doors that support different standards. 14.2.3 Terminating After Carrier Loss ------------------------------------- Applications not written as doors typically will sit and wait forever for input. The do not "time out", that is, terminate after a limited time in which no input is received. After if the carrier is dropped, they do not detect that the remote caller is "gone" and will sit forever waiting for input. In effect, a dropped carrier "hangs" the BBS and no further calls will be processed. Programs written as doors will terminate both for inactivity and when carrier drops. The solution to this problem is to install a memory resident program that will reboot the PC if carrier drops. The public domain program WATCHDOG does this. Simply turn WATCHDOG on in the first statement in the door batch file, and turn it off as the last RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 14-4 statement. WATCHDOG is not needed, and should not be used, for programs explicitly written to be doors. 14.2.4 Security --------------- SysOps should realize that doors greatly increase the security risks associated with running a BBS. One general problem is that most applications for personal computers assume that the user is the owner and has access to everything on the PC. As a matter of convenience, they often give the user access to many functions, such as deleting files, or even shelling to DOS. This assumption is simply not true when remote callers door to the application. Very few programs not designed to be a door let the SysOp disable such dangerous functions. 14.3 Invoking "DOOR"s Via The External Control File --------------------------------------------------- In addition to simply invoking "DOOR"s using the standard approach outlined above, RBBS-PC supports a more sophisticated interface to doors. CONFIG parameter 109 allows the SysOp to specify the name of this control file, which is usually DOORS.DEF. This approach allows each DOOR to be invoked in different ways. Specifically, the SysOp can tailor the way each "DOOR" is invoked as follows: - The minimum security level to invoke each "DOOR" may be different. - The caller may be required to answer a questionnaire before the "DOOR" is invoked. This is extremely useful if the "DOOR" is a database search program and the questionnaire gathers the necessary search criteria from the caller prior to invoking the "DOOR". - The "DOOR" may be either SHELLed to (RBBS-PC remains in memory and the "DOOR" is loaded into free RAM) or EXITed to (RBBS-PC terminates itself and releases the memory for the "DOOR" to use). - The "DOOR" may be invoked via a "template" (see section 20.2) and information passed to the "DOOR". "Templates" are useful when passing information from a questionnaire to a database search program. RBBS-PC normally passes the node ID as the first parameter to a "DOOR". When using a "template" to invoke a "DOOR" the "template" must include the parameter "[NODE]", if the node ID is to be passed to the "DOOR". - A file may be specified for RBBS-PC to display to the caller upon returning from a "DOOR". This file may be created by the "DOOR" that was invoked (i.e. the output of the database search and retrieval) or simply a text file that the SysOp created. - When returning from each "DOOR", the caller can be required to re-enter their password as an added security verification. - The maximum amount of time a caller can spend in each "DOOR" can be specified. If the amount of time remaining the user has on the system is greater than the amount of time allowed in the "DOOR", the smaller of the two times is used. The format of the door control file is: THE USE OF RBBS-PC "DOORS" 14-5 1. Name of door - up to 8 characters 2. Minimum security to use door 3. Questionnaire to execute before the door 4. Method to invoke doors - "S" for shelling, else go to .BAT file 5. Template for invoking door - make sure the first word has a file extension - RBBS-PC will check for existence of the first word as file. 6. Whether to ask for password on return - Y is yes, anything else bypasses password check 7. File to display after the door 8. Maximum time allowed in doors - time remaining passed to door is reduced if max time is less. Note: RBBS-PC normally passes the node id as the 1st parameter to a door. If a template is used, RBBS-PC will not automatically add this parameter. If you want it, you should include "[NODE]" in the template. Special note: A door must still have a .BAT file in order to be invoked, even if the BAT file is not used in the template! Example #1: MYDOOR,4,C:\RBBS\QUESTION\DOORQ.DEF,D,"MYDOOR.BAT [1] [2]",N,MYDOOR.TXT, This line tells RBBS-PC: - The name of the door is "MYDOOR" - Users with security 4 and above can run this door - Before starting the door, users are asked the DOORQ.DEF questionnaire - RBBS-PC should EXIT and run the door (rather than SHELLING) - The door is started by running MYDOOR.BAT, and two parameters (presumably set in the questionnaire) are passed to the .BAT. - The caller does NOT have to enter a password to return to RBBS-PC - The file "MYDOOR.TXT" is shown to the caller before returning to RBBS-PC - No time limit (other than the caller's session time) is placed on this door. Example #2: MYDOOR,10,,S,"MYDOOR.BAT [NODE]",Y,,10 This line tells RBBS-PC: - The name of the door is "MYDOOR" - Users with security 10 and above can run this door - No questionnaire is asked before starting the door - RBBS-PC should SHELL to the door (rather than EXITING) - The door is started by running MYDOOR.BAT, and the RBBS-PC node number is passed to the .BAT. - The caller DOES have to enter a password to return to RBBS-PC - No file is shown to the caller before returning to RBBS-PC - A 10 minute time limit is placed on this door (unless the caller's session time is less than this). As with all features, the control file approach to invoking a "DOOR" is optional. However, even if it is used a "DOOR" can only be invoked by a caller if a .BAT file exists. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 14-6 14.4 EXITing or SHELLing to "DOOR"s ----------------------------------- There are two ways to execute other programs from RBBS-PC: 1) EXITing RBBS-PC and invoking the other program via a .BAT file that RBBS-PC builds dynamically, or 2) SHELLing to the other program while RBBS-PC remains in memory. EXITing RBBS-PC allows other BASIC programs to be run as external programs to RBBS-PC, and allows all of RBBS-PC's features to be active in computers with only 320K of memory. The "price" that is paid is that upon returning from the externally called program, RBBS-PC's .EXE file must be reloaded into memory. Unless a control file is used to invoke "DOOR"s, RBBS-PC always EXITs to "DOOR"s. SHELLing prohibits other BASIC programs to be run as external programs to RBBS-PC, consumes memory because RBBS-PC remains in memory when the other program is running, and requires 386K of memory (under DOS 3.2) to activate all of RBBS-PC's features. However, SHELLing does eliminate the need to reload the RBBS-PC.EXE file each time. 14.5 Resetting The User's Record Via a "DOOR" --------------------------------------------- WARNING -- this is an extremely powerful feature! It opens up everything in the user record to modification by the "DOOR". The "door" must also have knowledge of where fields are in the user record and may cease to work properly when the user record changes its format. The main application for this is feature within RBBS-PC if for "DOOR"s that maintain certain SysOp- defined fields. For a "DOOR" to reset any part of the user record all a door has to do is include in DOUTx.DEF file, where x is node number, a line in the format UR(<start>:<end>),<value> where: <start> is the beginning byte in user record, <end> is the number of bytes to revise, and <value> is what goes into the specified position in the user's record. For example, UR(63:24),"City,State" would update the city/state field with the value "City,State", setting 24 bytes in user record to that value (blank fill to right), beginning with character position 63. The "UR" request only works for data stored in character format in the user record. RBBS-PC supports a second request in the form SL,<sign><value> where "SL" stands for security level. <sign> can be nothing, plus, or minus, and means respectively to set the security level to the following value, or to raise or lower the security by the amount specified. For example, "SL,6" requests that the security be set to 6 whereas "SL,-2" means to lower the security by 2. THE USE OF RBBS-PC "DOORS" 14-7 14.6 A Summary of "DOOR"s ------------------------- Doors stretch IBM's DOS' capabilities and requires more knowledge than most other BBS functions. If the preceding discussion of "doors" is a complete mystery to you, contact a SysOp of an RBBS-PC that is using "doors" and ask for help. However, if you call a SysOp to learn about "doors" for personal gain (i.e. you are a consultant or some company's employee being paid to write a "door") have the courtesy to tell him. Please do not take advantage of the "user helping user" concept. Anyone who has acquired specialized knowledge has the right to be remunerated for their efforts if their knowledge is being used to further commercial purposes and they request it.