Beijing Paradise BBS Backup

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

/ Beijing Paradise BBS Backup / PARADISE.ISO / software / BBSDOORW / RDS_V201.ZIP / RDSDOCEN.DOC < prev next >

Wrap

Text File | 1992-08-22 | 127.7 KB | 2,781 lines

╔══════════════════════════════ ┌─────────────────┐ ║ RDS Remote Dos Shell │ D.I.S.P. │────┐ ║ For Bulletin Boards │ │░░░░│ ╟────────────────────────────── │ │░░░░│ ║ (c) 1991 Robert W.van Hoeven │ Dutch │░░░░│ ╟────────────────────────────── │ Independent │░░░░│ ║ Release : 2.01 │ ShareWare │░░░░│ ║ Rel.Date: 22th August 1992 │ Programmer│░░░░│ ╠══════════════════════════════ └─────────────────┘░░░░│ ║ | │░░░░░░░░░░░░░░░░░│ ║ │ RDS.EXE | └─────────────────┘ ║ │ RDS.OVR | ┌─────┐ | ║ │ RDS.CTL | │░░░░░│ | ║ │ | └──┬──┘ | ║ │ Lines starting with '│' are | ┌────┴────┐ | ║ │ changes to release 1.31 !! ------││││││ ═══│------- ║ └─────────┘ ╠═══════════════════════════════ ║ Address: Robert W. van Hoeven ║ PO. Box 131 ║ 1170 AC Badhoevedorp ║ Nederland / Holland ╚═══════════════════════════════ ┌───────┬─────────────────────────────────────────────────────────────┐ │ 0 │ Table of contents │ └───────┴─────────────────────────────────────────────────────────────┘ 1 ---- General information 1.1 Copyrights and License Agreement 1.2 Newer versions and contacting the author 2 ---- Package description and requirements 2.1 Preface 2.2 Requirements 2.3 Included files 2.4 Introduction 2.5 Specifications 3 ---- Installation description 3.1 Installation 3.2 The overlay mechanism 3.3 RDS.CTL 3.4 Available commands 3.5 Security 3.6 Macro's, expansion and command-stacking 3.7 ALIAS's 3.8 Help file format 4 ---- Runtime information 4.1 While inside the RDS shell 4.2 Keyboard commands at the local side 4.3 LOG file 4.4 Errors 4.5 Specialized command-line options 5 ---- Version information and credits 5.1 The BETA-team 5.2 Credits 5.3 Version history 5.4 Copyright, Trademarks ┌───────┬─────────────────────────────────────────────────────────────┐ │ 1 │ General information │ └───────┴─────────────────────────────────────────────────────────────┘ 1.1 Copyrights and License Agreement ──────────────────────────────────── - Users of the RDS-package must accept this disclaimer of warranty: - The RDS-package is supplied as is. The author disclaims all warranties, expressed or implied, including, without limitation, the warranties of merchantability and of fitness for any purpose. The author assumes no liability for damages, direct or consequential, which may result from the use of the RDS-package; - The RDS-package is a "shareware program" and is provided at no charge to the user for evaluation. Feel free to share it with your friends, but please do not give it away altered or as part of another system. The essence of "user-supported" software is to provide personal computer users with quality software without high prices, and yet to provide incentive for programmers to continue to develop new products. - If you find this program useful and find that you are using and continue the use of the RDS-package after a 30 days trial period, you must register the RDS-package as described below; - Non-commercial can get a license for the usage up to this release of the RDS-package for a small amount of money. Look into the details in REGISTER.RDS. Previous registered users will receive a big reduction to upgrade to the newer versions. These users should look into the details in UPGRADE.RDS. For Non-commercial users there is a POSSIBILITY to submit to one of the special contracts as explained in the file REGISTER.RDS. - Commercial usage of RDS will cost somewhat more. Also, a so called 'closed' Bulletin Board System (a system where the user must pay direct to the SysOp to get full access) is has to pay more than a Non-commercial user. Both types of users should look into the details in REGISTER.RDS; - The registration of the RDS-package will license ONE copy for use on any computer at any one time, as long as the usage confirms to the type of registration you have done (so NON-commercial usage when you have a non-commercial license); - Anyone distributing the RDS-package for any kind of remuneration must first contact the Author at the address above for authorization. - You are encouraged to pass a copy of the RDS-package along to your friends for evaluation. Please encourage them to register their copy if they find that they can use it; - Support on RDS, when used in a non-commercial environment, is available by means of written letters or by entering the inter- national echomail area DISP; - Problems and suggestions can be entered in the FidoNet <tm> Echomail conference <tm> called DISP (international). Entering this echo does not exclude you of the duty to register the RDS-package, though users who evaluate the product can enter the echo for questions; - The RDS-package, all programs, the documentation and support-files is copyrighted 1990,92 by Robert W. van Hoeven, PO. Box 131, Badhoevedorp 1170AC, Holland. All rights are reserved. You may copy this package for backup purposes. Also you may copy and share unmodified copies of the whole package, providing that the copyright notice is reproduced and included on all copies. Excluded from this statement are the support-files written by other authors. Please refer to the documentation of these programs for copyrights and license agreements; - It is forbidden to modify, adapt, translate, reverse engineer, decompile and/or disassemble the software in the RDS-package. Patching the medium at places that carry the software is seen as a program change and is also forbidden. It is forbidden to create a so called 'bypass' to skip the original introduction screens and delay. Also it is forbidden to use such a 'bypass' unless supplied by the author (Robert W. van Hoeven) himself; - Performing any of the illegal actions as stated in the previous lines, is a theft and no fair play to the author and, more important, to the registered users; - Bulletin Board Systems that distribute the RDS package can convert the WHOLE package to any archive-system they like but all original files must be included in the new archive. The RDS-package on the Bulletin Board can contain at the most 2 extra files. These files can only be a commercial for that Bulletin Board and/or validation data that is presented as a service to all users and shall have no other functions; - After the normal trial period of 30 days, you must register the soft- ware (see REGISTER.RDS) or you must remove it from your PC; - Comments, suggestions and bug reports are welcome and will be answered as soon I have the time to do so. You can send me a letter of leave a NetMail <tm> message named to Rob Van.hoeven (mind the point) on node 2:512/100 (RA Support, Monster, Holland, SysOp is Reinier de Groot). When you want to send me normal mail, address it to: Robert W. van Hoeven, PO. Box 131, 1171 AC Badhoevedorp, Holland; Also you can enter messages in the FidoNet <tm> DISP Echomail <tm> area; 1.2 Newer versions and contacting the author ─────────────────────────────────────────────────────────────────────── The newest version of RDS is always available at the DISP-HQ on node 2:512/100. RDS is also distributed thru a number of DISP support nodes. There are three ways of obtaining newer versions of RDS: - Logging on at DISP-HQ or a support node Look into the file SUPPORT.RDS for a full list of support nodes; - Logging on to a SDS node RDS is distributed thru SDS/SDN, but only big minors (x.10, x.20 and so on) and majors (14.01, 15.01 and so on) are submitted to the SDS distribution point in Holland; - Logging on to your own BBS; Chances are, that you will find an older version (international users) because it will take some time for the new version to 'bleed' thru the net; - Update service; You can enter a special update service (read REGISTER.RDS). If you think you have found problems in RDS, or in any other case, you wish to contact the author, you can send me: - A letter to the address you can find in the header of this file; - A NetMail <tm> message to Rob Van.hoeven (please mind the point between Van and Hoeven) at 2:512/100 or (better) 2:512/100.5; - A Message in the FidoNet <tm> DISP echomail <tm> area; ┌───────┬─────────────────────────────────────────────────────────────┐ │ 2 │ Package description and requirements │ └───────┴─────────────────────────────────────────────────────────────┘ 2.1 Preface ──────────────────────────────────────────────────────────────────────── Please notice the following: RDS is a ShareWare product in every right way, this means this software is not crippled in any way. There are only some changes to the registered version but the only have to do with cosmetic changes (no delays, your (BBS) name in the start-up header and so on); 2.2 Requirements ──────────────────────────────────────────────────────────────────────── RDS requires: - PC XT/AT/386 - At least 180K free memory under the BBS; - DOS 3.xx or higher; - HDU optional - A full functional BBS with an exit to doors. RDS 'knows' specifically about Remote Access <tm>, QuickBBS and Maximus and SuperBBS, but can be executed under any BBS that creates the files EXITINFO.BBS and DORINFO1.DEF. Even when the BBS does not create such files, you could use a conversion tool that creates these files for you (look into the BBS-area's on the bigger boards); 2.3 Included files ──────────────────────────────────────────────────────────────────────── The package includes : RDS.EXE The main program RDS.OVR The overlay-file for RDS.EXE RDS.CTL A sample RDS.CTL file RDS.ANS A sample file for KILLNICE RDS.HLP Help file RDSDOCEN.DOC This documentation 2.4 Introduction ──────────────────────────────────────────────────────────────────────── Many SysOp's struggle with specialized doors to get REMOTE (and local) access to DOS functions. Most of these SysOp's will only use the normal DOS-commands when working in such a door when they use this door as a maintenance door for themselves (when being remote) or their Co-Sysop (this 'creature' or 'creatures' are almost always remote <grin>). To give remote access to yourself or the Co-Sysop(s), means you have to implement special functions/doors. Some of these doors give you the access to normal programs (even when they normally could not work remote) but most of the time, this is not what you (or your 'Co') needs. Also there are some major drawbacks to any type of 'real-dos' doors: - Some of these doors (Gateway alike doors, batch-files with CTTY commands and so on) can NOT access most of the normal programs, because these programs do direct screen access (not to be displayed while working remote) and keyboard access, not to be captured from a re- mote session, thus forcing a 'hangup' (you can't 'see' a thing and you can't enter a key even when you know the combinations). This problem is 'captured' with a carrier-watchdog, thus forcing a re- boot when you hang-up the phone and also taking all other users down with you (when running multiple lines in one machine) or forcing a hangup (some combinations of multitasking software and a reboot cause hangups); - Some doors can access normal programs that are not covered by the previously mentioned doors. But in multitasking environments, these functions are dangerous and can (still) cause hangups. Also the re- mote site should use a 'doorway-mode' in the software otherwise serious damage to the fingers (and brains for that matter) could occur. Most of the supplied features are never needed and should (in fact) be kept away from your 'Co'; - Normal DOS-doors don't have BBS-specific functions like those implemented for Remote Access <tm>; If you need special programs to run remote (not DOS-commands, but real programs, some DOS-commands are real programs for that matter, but still) and these programs have nothing to do with DOS-commands and/or some specialized BBS-features, RDS will not be your taste of door. If you want a FULLY secured access to most of the normal DOS- commands (please read the chapter about security) AND something more, RDS could be worth trying. Up from RDS 2.01, the protection schemes are that good that you can even allow you NORMAL users to a RDS dos-shell ! 2.5 Specifications ──────────────────────────────────────────────────────────────────────── Those who took the time to read the introduction will have a general picture of RDS. A brief summary of the functions: RDS can: - Give access to most DOS-commands without entering DOS itself, thus creating a fully controlled (carrier!), secured (read on!) and compatible DOS-environment; - Give all the normal DOS-commands (DIR, DEL, REN, MOVE, COPY, CD, RD MD, drive switching, VER, MEM, TYPE and so on), some of them being an extension to DOS (MEM and MOVE); - Control all access to RDS (based on the name of the user) and control all access inside RDS (based on drives, directories and files); - In fact, give ANY normal user the (controlled) access to DOS- commands you specify and only for files, drives and directories you allow; - Make use of a subset of commands specialized for Remote Access and a special subset of generalized commands that can be used while being remote; - Make use of special BBS commands like Upload and Download, controlled with RDS security and available at any place while inside RDS; - Suit your needs. The only thing you have to do is to enter a message with suggestions you have and features you would like to see in RDS and maybe you'll see these features in the next release; - Call any program you like, but it is not possible to call a program that needs input during its execution; - Make usage of macros (developed online or offline) and aliases to do boring jobs in one command; What RDS can't do now, but will do soon: - Simple FILES.BBS changing with some FILES.BBS editing functions; - Access to DOS-programs like SUBST, ATTRIB, CHKDSK and so on, while keeping control; - Access normal compressor programs like PKZIP, ARC, PAK, LHARC and so on. These will be run 'under' RDS-control; What RDS can't (and probably won't do for a long time): - Executing 'normal' programs like your compiler, full-screen editor, mind-blowing arcade games and so on. For this functions you need a real DOS-door on your system IF this program needs input or writes its output directly to the screen-buffer AND you need to see this output; - FORMAT. It will never support such a function, it is to big a risk to implement this function. Most is up to you as a RDS user. Keep on giving suggestions. RDS is a modular program. Implementing functions is (relative) easy if they are straight-forward. Something like 'Let RDS talk to me' will take some time <grin> (though.... soundblaster support can be a major topic in version 88.01 !). For all its functions, RDS 'leans' heavily on it's own control-file. ┌───────┬─────────────────────────────────────────────────────────────┐ │ 3 │ Installation description │ └───────┴─────────────────────────────────────────────────────────────┘ 3.1 Installation ──────────────────────────────────────────────────────────────────────── People who think that installing RDS is difficult should consider to read a DOS-manual. If you can install a BBS (and you did, I imagine) you can install RDS ! There are no online configuration programs because every setup can vary ! If you have any problems with the installation than enter a message in the DISP echomail area or send me a NetMail message. I can read, speak and write English, German and Dutch (and garbage, after a few beers). Now for the installation itself. I'll use an installation in a Remote Access environment. For now, I will first describe the differences when installing RDS under other types of BBS programs: - QuickBBS <tm> No special care. All RA-alike options will not work. QuickBBS will use the EXITINFO.BBS and DORINFO1.DEF files; - SuperBBS <tm> As with QuickBBS; - Older Remote Access <tm> versions Only change the RA11 option (see later) in RA10 (RA 1.1x) or RA00 (RA 0.xx); - Maximus <tm> and OPUS <tm> When installed as Maximus or OPUS, RDS will only search for a DORINFO1.DEF file. The MAXIMUS manual gives an example on how to create such a file when you call a door. The OPUS manual will probably also give such an example. The EXITINFO.BBS file is not accessed. The only drawback is that the user's name will show in uppercase. If the DORINFO1.DEF can not supply the correct modem-info (port, baudrate), you can use RDS's command-line options to overrule them with other (locked) baud-rates and/or ports; The installation of the supplied files is as follows: - Place RDS.EXE and RDS.OVR in some directory; - Place RDS.HLP in the same directory (or somewhere else) as the previous files. You can use RDS.CTL an option to point to the RDS.HLP file. When you still run an old version of RDS (1.0x) you must convert the 1.0x help files to the new (single file) format. You could try to get your hands on the RDS 1.31 archive that contains a conversion program; - Create a RDS.CTL (or alike) file. This can be done in several ways: - Under the name RDS.CTL in the directory where RDS.EXE is stored (when running under DOS 3.xx or higher); - Under the name RDS.CTL somewhere in the DOS-path (DOS 2.xx and up); - Under the name RDS.CTL in the directory that is CURRENT when your BBS executes a door program; - Under the name RDS.CTL in any directory, provided you create a variable in the DOS-environment with the format: RDS=[drive][directory]\RDS.CTL or RDS=[drive][directory]\ - Under any name, anywhere, provided you create a variable in the DOS-environment with the format: RDS=[drive][directory]\[name_of_your_CTL] Chapter 3.3 provides a description of what (and how) you can supply in the RDS.CTL file; - Create a type 7/15 menu entry in your BBS with some security level. Use the following call to RDS in the data-field: [drive][directory]\RDS.EXE {parameters} RDS now has some command-line options to consider. Please read chapter 4.4 about the commands and how to use them ! Use the *M option in a Remote Access environment when you can (look into the DOX) or call RDS from a type 15 when memory is low. RDS uses between 120K and 180K under your BBS (depending on the functions you want to support). Other BBS types should use a 'exit from BBS' like the type 15 in RA and QuickBBS; - Edit the file RDS.ASC to a format you like (if you want to use the command KILLNICE) and place it somewhere in a directory; - Look at the special chapter conceirning the usage of the overlay, so you can customize it to your personal needs; - Everything is ready to run. Try RDS yourself first (locally) before your users are frustrated over a menu they can call and that seems to do nothing. Remove all errors and let it go loose for a remote job ! That's all there is to. The first part is done. Now take some time to create the CTL-file ! 3.2 The overlay mechanism ──────────────────────────────────────────────────────────────────────── RDS is supplied as an overlaying program. This means that only part of the code will be active and available in conventional memory (the part of memory up to 640K) and the remaining parts of the code can be loaded into memory when a certain part is needed. Overlays are only useful when a program will not have to access all parts of the coding in a short time. The more coding is not needed concurrently, the bigger the overlay and the smaller the part of conventional memory the program needs. When a program is written, the author will always try to search for the best result on a large number of implementations, but not all situations can be dealt with. Because of these special situations, RDS includes a number of options to make the overlay mechanism as flexible as possible. To change the overlay mechanism means that you must know how it works by default. When RDS is loaded, it will try to initialize the overlay manager first. This is done in the following manner: - The program will search for the overlay-file. The location it will search is the location where the EXE-file is found. The name must be the same as the filename-part (without extension) of the EXE-file, so when you rename RDS.EXE to MYRDS.EXE, you must also rename RDS.OVR to MYRDS.OVR. This mechanism works for all DOS releases from version 3.0 and higher. Lower versions of DOS (1.xx and 2.xx) can not work in this manner and you need to set the location and name overlay-file with help of an environment variable (see later); - If the overlay-file is found, the program will initialize it and will examine the memory. The overlay-manager need some conventional memory and it can store the remaining part of the overlay (the not-active part) in expanded memory (EMS) if that is available and contains enough free memory. The size of the part of conventional memory is variable (though it can not be too small) and is set to a good average (by default). The size of the part of EMS memory is fixed for a given release of the program. The more conventional memory that is assigned to the overlay buffer, the better the performance of the program but the less memory (conventional) is available. If the overlay part can not be loaded into EMS (because it isn't there or there isn't enough free memory in EMS), it will be left on disk and parts of the coding must be loaded from disk (slower!) when they are needed; - If the overlay-managers fails to install the overlay, the program will abort. In general, the failing will be the result of: - The OVR-file (the overlay) could not be found; - Not enough conventional memory available to load the overlay; - Invalid (old) EMS drivers; - I/O errors on the overlay-file - Conflicts between other programs that use EMS or conventional memory (TSR's, device drivers); In general, when you do nothing about the overlay-manager and you run under DOS 3.xx or higher, you will have a solid running program. If you have problems (see above) or you want to optimize the program for better thruput, you can (must) alter the overlay management. These changes must be made with help of environment variables (see the DOS SET command). Many people asked why you can't put these changes inside the control-file. That is not possible, because the parsing of the control-file itself is an overlayed part of the coding. You need the overlay before you can access the control file. That is why you must make use of environment variables. The following environment variables are tested for: RDSOVROL : This environment variable can be used to point to the name and/or location of the overlay-file. You can use it in two ways: (1) SET RDSOVROL=F:\RAMDRIVE\ (2) SET RDSOVROL=C:\BBS\PRG\RDS.OVR In the first case (1) you point to the directory that contains the overlay-file. The name of the overlay-file is generated from the program-name (minus the extension), so when you have MYRDS.EXE, you must put MYRDS.OVR in this directory first. The directory-name MUST end with a '\' otherwise the overlay-manager will assume RAMDRIVE as the name of the overlay-file and will search for it in F:\. In the second case (2) you point to the location AND name of the overlay-file. In this case the overlay-file can have a complete different name. So it is valid to call the program RDSHELL.EXE and the overlay RDSOVR.OVR if you use SET RDSOVROL=C:\BBS\PRG\RDSOVR.OVR. This option is also needed when you run under DOS 1.xx or 2.xx; The most common usage of this environment variable is to put the overlay-file on a RAM-disk (fast access) and to deny the usage of EMS for the overlay (because you have better candidates for EMS usage). RDSOVRUE : This environment variable can have 2 values, either Y or N. The program will only test if the value 'N' is used (so SET RDSOVRUE=N). If this is the case, the overlay manager will not use EMS for the overlay-file and access to the overlay-file is done on disk (see RDSOVROL); RDSOVRBS : This environment variable can be used to alter (enlarge) the overlay buffer in conventional memory. The program's default will give a good average, but when memory is not a problem (conventional memory), you can make the overlay buffer bigger and gain some speed in the program thruput. To see which value you should set, you should run the program without this option first. Inside the log (you must activate the log), you can find the default value for the overlay buffer. You can make it smaller but don't make it smaller than the current size minus 8192 otherwise the overlay-manager could fail. You can make it bigger but don't make it too big (experiment with small steps and see if the performance gets better). SET RDSOVRBS=100000 will allocate 100.000 bytes of conventional memory for the overlay buffer; RDSOVRPS : This environment variable can be used to alter (enlarge) the 'prohibition area'. This area is a part of the normal overlay buffer. It is used to store recently accessed parts of the code. The code will remain as long as possible over here. If the code is accessed again, it doesn't have to be loaded from the overlay-file but can come from this area. The value you supply with this variable should not be less than 2. The default is 3 (buffersize / 3). You can try to gain some speed by making the overlay buffer larger and to set this value to 2. The default gives a good average in combination with most overlay buffers; In general (DOS version equal or higher than 3.xx, unaltered names for the program-file and overlay-file, enough EMS memory or a fast disk), you can use the default values and don't have to set these environment variables. 3.3 RDS.CTL ──────────────────────────────────────────────────────────────────────── The RDS.CTL file is a normal text-file (ASCII-file). You can create this file with program's like EDLIN or any other ASCII-editor. RDS.CTL must be in the DOS-path (DOS 2.xx) or in the same directory as RDS.EXE (DOS 3.xx). Also it is possible to access the RDS control-file in the following ways: - The usage of an environment variable RDS 1) When the value of this variable terminates with a backslash (\), RDS assumes the value is a path and adds RDS.CTL to the variable and searches for this file; 2) When the value of this variable does NOT terminate with a back- slash (\), RDS assumes that the variable is a full path and name to the control-file and RDS will try to find it; - The usage of the -CTL[drive:][path][name] option. RDS will search for the supplied filename on the supplied drive and in the supplied directory; RDS.CTL contains many options. Some of them optional, some of them not. The general format for the RDS.CTL file is: Option {parameter} {parameter} ..... {parameter} or [line] Option {parameter} {parameter} ..... {parameter} The latter format can be used when you want 1 RDS.CTL for ALL your BBS-lines and when these lines have different resources like other modems, other log-files and so on. An example for 2 different RDS.CTL files: RDS.CTL for line 1 ------------------ LogPath D:\BBS\LINE01.LOG RDS.CTL for line 2 ------------------ LogPath D:\BBS\LINE02.LOG can be combined to one RDS.CTL with: [1] LogPath D:\BBS\LINE01.LOG [2] LogPath D:\BBS\LINE02.LOG The line number (between '[' and ']') is ruled by the -N command-line option. If no -N command-line option is given, line 1 is assumed. All lines inside RDS.CTL that don't contain a line-number will be used on ALL lines (see examples RDS.CTL for single-line and RDS.MUL for a multi-line setup). There are NO restrictions to the position you start the command, nor the starting position of the (optional) parameters, but the 'option' and (if present) the 'parameters' have to be separated with one or more spaces. You can make any mixture of upper and lower case ! A generalized example of RDS.CTL is included in the release-file. It contains ALL options available in this release. RDS.CTL can (or must) contain the following statements: ┌─────────────────────────────────────────────────────────────────────┐ │ RegistrationName [name] │ └─────────────────────────────────────────────────────────────────────┘ Usage : This option has only a meaning when you received a key after you registered RDS. You can not use it when you are using RDS in the (unregistered) trial period; ┌─────────────────────────────────────────────────────────────────────┐ │ BBSType RA00|RA10|RA11|QBBS|QNEW|SBBS|MAXI|OPUS │ └─────────────────────────────────────────────────────────────────────┘ Usage : This parameter is mandatory. You can select a number of types: │ RA00 : when you run a Remote Access <tm> version 0.xx type of │ BBS (EXITINFO, DORINFO1) │ │ RA10 : when you run a Remote Access <tm> version 1.0x type of │ BBS (EXITINFO, DORINFO1 and USERON.BBS 1.0x format) │ │ RA11 : when you run a Remote Access <tm> version 1.1x type of │ BBS (EXITINFO, DORINFO1 and USERON.BBS 1.1x format) │ │ QBBS : when you run a QuickBBS <tm> version LESS THAN 2.75 │ type of BBS (EXITINFO, DORINFO1) │ │ QNEW : when you run a QuickBBS <tm> version 2.75 OR HIGHER │ type of BBS (EXITINFO, DORINFO1) │ │ SBBS : when you run a SuperBBS <tm> version 1.xx type of BBS │ (EXITINFO, DORINFO1) │ │ MAXI : when you run a Maximus <tm> version 2.xx type of BBS │ (only DORINFO1) │ │ OPUS : when you run a OPUS <tm> version 1.xx type of BBS (only │ DORINFO1) The RAxx types will supply a number of extra goodies that can │ not be used in any other BBS environment ! The MAXI and OPUS │ types can be used for any given BBS program that WILL create a │ DORINFO1.DEF file but that won't create a EXITINFO.BBS file. If │ both are created but your BBS is not a Remote Access, SuperBBS │ or QuickBBS program, you can use QBBS, QNEW or SBBS (you must │ experiment to see which of the types gives the best result). ┌─────────────────────────────────────────────────────────────────────┐ │ BBSDirectory [dir] │ └─────────────────────────────────────────────────────────────────────┘ Usage : This option must point to the BBS system directory. Under Remote Access you must supply this directory but it is better to supply it for all types of BBS's. ┌─────────────────────────────────────────────────────────────────────┐ │ BBSWorkDirectory [dir] │ └─────────────────────────────────────────────────────────────────────┘ Usage : When RDS is called and the EXITINFO.BBS and/or DORINFO1.DEF files can NOT be found in the CURRENT directory, you will have to supply the directory where they can be found. In this case you should supply the BBSWorkDirectory option in RDS.CTL. If supplied, RDS will first look inside this directory, otherwise it will try to find the file(s) in the CURRENT directory. If the option is not supplied, RDS will only look in the CURRENT directory (normal operations). │┌─────────────────────────────────────────────────────────────────────┐ ││ StartupDirectory [dir] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : If you don't want to supply a single startup directory for │ every single user (see later), but you want your RDS user(s) to │ always start at a fixed directory, you can supply this │ directory with this option. When RDS is called, it will swap │ to this directory unless the user is forced into another │ directory (the UserDirectory option, see later) or when you did │ supply the -D command-line option ! ┌─────────────────────────────────────────────────────────────────────┐ │ HelpDirectory [dir] │ │ HelpDirectory [path] │ └─────────────────────────────────────────────────────────────────────┘ Usage : This option can point to a directory containing RDS.HLP or it can point (with a complete path) to this type of file when it has an alternate name. C:\ZIP\ will tell RDS to look for RDS.HLP in C:\ZIP C:\ZIP\MY.OWN will tell RDS to look for MYHELP.OWN in C:\ZIP │┌─────────────────────────────────────────────────────────────────────┐ ││ NOEMS │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : RDS will use a swap mechanism when any shell to DOS is called │ (SPAWN, SHELL, DOWNLOAD, UPLOAD, TREE). Normally this mechanism │ will try to use XMS, EMS or disk (in that order). If you don't │ want to swapping mechanism to make usage of EMS, supply this │ parameter in which case XMS (unless NOXMS is supplied) or disk │ will be used. │ │ │┌─────────────────────────────────────────────────────────────────────┐ ││ NOXMS │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : RDS will use a swap mechanism when any shell to DOS is called │ (SPAWN, SHELL, DOWNLOAD, UPLOAD, TREE). Normally this mechanism │ will try to use XMS, EMS or disk (in that order). If you don't │ want to swapping mechanism to make usage of XMS, supply this │ parameter in which case EMS (unless NOEMS is supplied) or disk │ will be used. │ │ │┌─────────────────────────────────────────────────────────────────────┐ ││ ChatCall [parameters] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : When you want to use ALT-C to call a chat-program while inside │ RDS, you must supply this option. [parameters] must contain │ the complete path to the chatter AND must contain the │ command-line parameters (if any) for the chat-program. You can │ use some special macros inside these command-line parameters, │ that will be replaced by RDS at run-time. These are: │ │ $C : Will be replaced by the COM-port │ $B : Will be replaced by the baud-rate │ $L : Will be replaced by the BBS-line │ │ The control is passed to the chat-program. RDS will (in 2.01) │ not re-read the EXITINFO.BBS to see if the time left to the │ user should be adjusted ! ┌─────────────────────────────────────────────────────────────────────┐ │ MacroExpandBuffer [number] │ └─────────────────────────────────────────────────────────────────────┘ Usage : RDS (from 1.20 and up) contains two statements that can stack (generated in case of EXPAND) statements on RDS's own command- stack. The stack has a default size of 100 entries, resulting in 25600 bytes of memory consumption. If this is to many for you and you will never stack that much statements, you can lower the stack to a minimum of 10 (resulting in 2560 bytes of overhead) but remember this. When you use EXPAND for example in the case of EXPAND COPY *.* C:\TUP (copy all files in the current directory to C:\TUP) and your current directory contains 200 files, stacking will be impossible when you don't have a stack of at least 200 lines. MacroExpandBuffer can be set anywhere between 10 and 1000. The bigger, the more files can be EXPAND'ed or MACRO-files can be bigger. Tradeoff is the memory consumption. 256 bytes-per-line of memory are lost, so 1000 lines will mean 256K ! │┌─────────────────────────────────────────────────────────────────────┐ ││ MAXBAUD [com] [baud] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : Under RDS you can make usage of the MODEMSEND command. This │ command will send characters to the modem on a given COM-port. │ When you don't want to make usage of the MODEMSEND command, you │ can forget the MAXBAUD option but even when you run a single │ modem configuration, you can use the MODEMSEND command, but │ only locally (when you run on COM0). Normally RDS will ask for │ the maximum baud-rate of the modem you want to send commands to │ with MODEMSEND. To overcome this problem, you can also define │ the maximum baud-rates of all your modems in RDS.CTL with the │ help of the MAXBAUD option. If such an option is present for │ a given modem (COM-port), RDS will not ask for the maximum │ baud-rate when you start MODEMSEND. │ │ [com] must be the COM-port of the given modem and [baud] the │ maximum baudrate of that modem. For locked modems, you should │ supply the locked baud-rate ! │ │ │┌─────────────────────────────────────────────────────────────────────┐ ││ BEEPHOURS [hhmm-hhmm] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : Some users can use the BEEP command to generate a series of │ noises on the local console (as a type of attention to the │ SysOp). To give the SysOp her/his beauty-sleep/beer-recovery │ you can supply one or more of these options. │ │ The hhmm-hhmm parameter must be set to a from-time and to-time │ and the to-time can not be lower than the from-time. You can │ set an unlimited number of BEEPHOURS periods to cover your own │ specialized needs. For example, to disable beeping from 13:00 │ to 17:00 and from 21:30 to 08:30, use the following commands: │ │ BEEPHours 1300-1700 │ BEEPHours 2130-2400 │ BEEPHours 0000-0830 │ │ The BEEPHours commands will not take any memory, because RDS │ will decide the actual beeping periods at startup (and after │ reading the RDS.CTL). │ │ │┌─────────────────────────────────────────────────────────────────────┐ ││ DOWNLOAD [letter] [files] [Desc] [parameters] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : You can supply up to 10 DOWNLOAD options. Each option will │ refer to a protocol that can be used inside RDS. │ │ [letter] This must be a valid character that the user must │ enter at the protocol menu, to select the │ protocol (A-Z, 1-9 and special characters). │ Don't supply any duplicate characters. RDS will │ not check for duplicates. │ │ [files] This must be a value between 1 en 255 and will │ tell RDS how many files can be downloaded in one │ call. If the value is anything but 1, you must │ use a files-list ($3 macro) in the call. │ │ [Desc] This must be a short description of the protocol │ without any spaces in the description. If you │ want to display a space, you must include a '_' │ (underscore) character. These characters will be │ replaced by spaces (by RDS); │ │ [parameters] This will be the actual command-line that must be │ executed (so the protocol itself and the │ command-line options for the protocol). The │ command-line can include some special macros that │ are replaced by RDS at run-time. These are: │ │ $1 : Will be replaced by the COM-port number │ $2 : Will be replaced by the baud-rate │ $3 : Will be replaced by a file-list │ (@[filelist.ext]) │ $4 : Will be replaced by a filename (only 1) │ $5 : Will be replaced by the remaining time │ in minutes │ $M : RDS must swap first before calling protocol │ │ The RDS.CTL inside the archive will contain an example of some │ protocols (DOWNLOAD). │ │ │┌─────────────────────────────────────────────────────────────────────┐ ││ DOWNLOADHOURS [hhmm-hhmm] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : To disable the DOWNLOAD command during certain periods, you │ can use the DOWNLOADHOURS option. The format and usage is the │ same as the BEEPHours option. │ │ │┌─────────────────────────────────────────────────────────────────────┐ ││ UPLOAD [letter] [Desc] [parameters] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : You can supply up to 10 UPLOAD options. Each option will │ refer to a protocol that can be used inside RDS. │ │ [letter] This must be a valid character that the user must │ enter at the protocol menu, to select the │ protocol (A-Z, 1-9 and special characters). │ Don't supply any duplicate characters. RDS will │ not check for duplicates. │ │ [Desc] This must be a short description of the protocol │ without any spaces in the description. If you │ want to display a space, you must include a '_' │ (underscore) character. These characters will be │ replaced by spaces (by RDS); │ │ [parameters] This will be the actual command-line that must be │ executed (so the protocol itself and the │ command-line options for the protocol). The │ command-line can include some special macros that │ are replaced by RDS at run-time. These are: │ │ $1 : Will be replaced by the COM-port number │ $2 : Will be replaced by the baud-rate │ $4 : Will be replaced by a filename (only 1) │ $5 : Will be replaced by the remaining time │ in minutes │ $M : RDS must swap first before calling protocol │ │ The RDS.CTL inside the archive will contain an example of some │ protocols (UPLOAD). │ │ Be sure to implement the UPLOAD protocols in a way that NO │ replacement of files can be executed and that the user can │ ONLY UPLOAD 1 FILE at a time ! │ │ │┌─────────────────────────────────────────────────────────────────────┐ ││ UPLOADHOURS [hhmm-hhmm] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : To disable the UPLOAD command during certain periods, you can │ use the UPLOADHOURS option. The format and usage is the same │ as the BEEPHours option. ┌─────────────────────────────────────────────────────────────────────┐ │ RADownText [file] │ └─────────────────────────────────────────────────────────────────────┘ Usage : This option is only valid when you run a Remote Access BBS (so when you used RA00, RA10 or RA11 on the BBSType option). [file] is a fully specified (and existing) filename of a file that contains the text that is displayed to the user when you force a Remote Access session down with the KILLNICE option. The file will be displayed as soon as the user on the line that you forced down returns to the BBS (from a door) and should contain a text that explains the reason for shut-down. ┌─────────────────────────────────────────────────────────────────────┐ │ LogPath [path] │ │ LogPath [full path & filename] │ │ LogPath CURRENT │ │ LogPath CURRENT [name] │ └─────────────────────────────────────────────────────────────────────┘ Usage : When you want RDS to create a log, you MUST include the path to the log-file RDS will create. If this option is NOT present, no log is created. If you want a log with a name of your own, or you want RDS to add its log-records to an already present log-file (this could be the log-file of a Mailer or a BBS program), you can use the second option. In this case you must supply not only the path, but also the name of the log-file. If the log-file is not present, RDS will create it, otherwise RDS will append to this file. If you want RDS to create RDS.LOG in the CURRENT directory, use the third option. In this case the log is called RDS.LOG and this option should be used in multi-line/network environments; If you want RDS to create a log with a user-supplied name in the current directory, use the fourth option. In this case [name] will be created in the CURRENT directory. With the LogStyleFormat option, you can create your own log-file format, so appending to a Mailer-log or BBS-log could be done in a neat way ! RDS opens AND closes the log-file with every access. The access is under control of SHARE (if this program is present in the system). If another task or program has opened the log in a way that RDS's access is denied (sharing violation), RDS will wait up to 30 seconds (30 retries). If after 30 retries, RDS is still unable to write to the log-file, logging of the cur- rent action is denied. The action itself is completed. At the next action, RDS will try again. The RDS-user is informed of the waiting (every second or so), so she/he won't hang the line by mistake. RDS will (when logging is on) log ALL actions in detail. This is a handy feature when you want to 'reconstruct' any errors that have occurred after someone has used RDS. Please also look into the chapter about security ! ┌─────────────────────────────────────────────────────────────────────┐ │ LogStyleFormat [string] │ └─────────────────────────────────────────────────────────────────────┘ Usage : RDS creates several log-records under different conditions. You can use the standard log, but Sysop's hate all these different log-files (in general). RDS can create customized log-records. With these options, you can instruct RDS to create records that look the same as the records from your mailer or BBS program. The option LogStyleFormat and the LogDateFormat/LogTimeFormat combination can be used to define the style of the log-records RDS will create for ALL three log-files (normal log-file, error log-file and password-list log-file). These options are implemented with the idea that different log-styles only vary at the start of the records and not at the end. The LogStyleFormat defines the 'structure' of the log-record header. The format is free but with three special cases: - Blanks must be replaced by underscore characters '_'; - The part of the record that contains the date must be defined with %D (if a date is wanted); - The part of the record that contains the time must be defined with %T (if a time is wanted); - Any extra CRLF combinations (to create a separation line) must be defined with ^M; An example (also read LogDateFormat and LogTimeFormat for a description of the time and date functions): You want to create records that look like this: + 6 Jan 1990 2:00p The start of the log The 'The start of the log' part is constructed by RDS itself, so you have only to define the header. This is done as follows: LogStyleFormat +_%D__%T___ (The _ character replaces a blank) LogDateFormat DD_nnn_yyyy LogTimeFormat HH:mmt %D and %T are replaced by RDS with the date and time formats as supplied in LogDateFormat and LogTimeFormat. RDS.CTL contains a number of examples for the various BBS programs and Mailer programs. ┌─────────────────────────────────────────────────────────────────────┐ │ LogStartStyleFormat [string] │ └─────────────────────────────────────────────────────────────────────┘ Usage : This is an additional option you can use along with the previous LogStyleFormat option. Some types of log use a special format where the actual date is put into an extra record (with- out any further meaning than logging the date). RDS can create such a record for you. RDS will put the record with the format you supply in LogStartStyleFormat into the log as the first and only record for THIS run of RDS. If RDS stops and is started again, a new record of this type is written. A type of log with this format is found in the FrontDoor <tm> mailer. The options you can use in this logstyle-format are the same as with the LogStyleFormat option. ┌─────────────────────────────────────────────────────────────────────┐ │ LogDateFormat [string] │ └─────────────────────────────────────────────────────────────────────┘ Usage : LogDateFormat is used to define the 'date part' (actually the %D) in the LogStyleFormat option. RDS (in fact some nifty routines from TurboPower, credit to those who should have the credits) has knowledge of a big number of options to define the date. The [string] must be composed of a number special letters and (optionally) the separators and spaces between the various parts of actual date. In fact [string] should be a picture mask. The following characters have a meaning in the mask: m or M The month (upper case will create leading a leading space as replacement for a zero) d or D The day (upper case will create leading a leading space as replacement for a zero) y or Y The year (upper case will create leading a leading space as replacement for a zero) n or N The name of the month (upper case will force an upper case name); w or W The name of the day (upper case will force an upper case name); Each character must be repeated as many times as you want digits or letters. So '90' for the year 1990 is defined with yy and the full year is defined with yyyy. Some examples: mm/dd/yy 01-31-90 MM/dd/yy 1-31-90 dd/mm/yyyy 31-01-1990 dd/mm/yyyy 31-01-1990 dd NNN yyyy 31 JAN 1990 dd nnn yy 31 Jan 1990 dd n yyyy 31 J 1990 www dd nnn yyyy Sun 31 Jan 1990 As you can see, a lot to experiment with. ┌─────────────────────────────────────────────────────────────────────┐ │ LogTimeFormat [string] │ └─────────────────────────────────────────────────────────────────────┘ Usage : LogTimeFormat is used to define the 'time part' (actually the %T) in the LogStyleFormat option. RDS (in fact some nifty routines from TurboPower, credit to those who should have the credits) has knowledge of a big number of options to define the time. The [string] must be composed of a number special letters and (optionally) the separators and spaces between the various parts of actual date. In fact [string] should be a picture mask. The following characters have a meaning in the mask: h or H The hour (upper case will create leading a leading space as replacement for a zero) m or M The minute (upper case will create leading a leading space as replacement for a zero) s or S The seconds (upper case will create leading a leading space as replacement for a zero) t or T 'p'/'P' (in PM) or 'a'/'A' (in AM) e or E 'm'/'M' (in PM or AM) Each character must be repeated as many times as you want digits or letters. For h/H/m/M/s/S this should be two digits to be useful. Some examples: hh:mm 14:00 hh:mmt 02:00p HH:mmte 2:00pm HH:mm:ss 14:00:45 hh:mm:ss 14:00:45 Again, as you can see, a lot to experiment with. ┌─────────────────────────────────────────────────────────────────────┐ │ USER [name of the user as it appears in EXITINFO.BBS] │ └─────────────────────────────────────────────────────────────────────┘ Usage : Now the difficult part. The User option is the start of a block (cluster) of secondary commands that can be used in a different way for every single user you allow to use RDS. The cluster MUST start with the USER option and the cluster MUST end with the USEREND option. Between USER and USEREND you can place various sub-options that are only valid inside the cluster (within the bounds of USER and USEREND). There can be as many USER/USEREND clusters as you like. RDS will only use (and store) the information for the current users. The only limits you have are disk-space and time. Time is an important thing to consider. RDS must 'struggle' thru every cluster when the door is started for a certain user. In a future release I will also supply a default set to be used by all users who have access to the door. The USER option carries 1 parameter. This is the name of the user who is allowed to enter RDS. If the RDS.CTL file also contains a USER ALL option, the options supplied in USER ALL are reset and the options for that specific user is used instead. The name must be in the same format as it appears in the EXITINFO.BBS (in my case Rob Van.hoeven, case is not important) file. As said earlier. If you allow more than one user (lets say the Sysop and the CoSysop), you must define a cluster, starting with USER and ending with USEREND, for each user. In the supplied RDS.CTL is an example of several users who are allowed to go into the door. The USER ALL option is a special case. If you want to allow ALL your users (with the right security level) into RDS with (minimal) options, you can supply a USER ALL cluster. The values inside the USER ALL cluster are used when there is NO specific cluster for the user in question available in RDS.CTL. Relate: UserEnd and all sub-options ┌─────────────────────────────────────────────────────────────────────┐ │ UserEnd │ └─────────────────────────────────────────────────────────────────────┘ Usage : Look into the description of the User option. A cluster for a certain user MUST end with UserEnd. UserEnd has NO secondary parameters. UserEnd must be preceded with (at least) a USER option and (optional) some secondary options between USER and USEREND. Relate: User and all sub options ┌───────────────────────────────────────────────────────────┐ │ UserPassword [password] │ SUBTYPE └───────────────────────────────────────────────────────────┘ Usage : This option is a sub-option and must be coded between a USER and USEREND option. It can not be used as a stand-alone option. This option is used as an extra security block for one or more of your users. When you supply this option with a password (length from 1 to 8 bytes), the user on the USER option MUST enter this password within 3 tries, otherwise access is denied. This option can also be used within the USER ALL cluster (if you have used that cluster). ┌───────────────────────────────────────────────────────────┐ │ UserDirectory [directory] │ SUBTYPE └───────────────────────────────────────────────────────────┘ Usage : By default, RDS will start in the CURRENT directory. If you do not want this, you can supply a start-up directory for every single user and/or in the USER ALL cluster. Also it is │ possible to supply a directory to start in, that will be used │ for ALL users (see the normal StartupDirectory option !). If you protect your C:-drive and the CURRENT directory is somewhere in C:, the user must ALLWAYS change to another drive or directory before any access can be done. If you supply an accessible directory as the default directory, the user does not have to change to this directory. This option can also be used within the USER ALL cluster (if you have used that cluster). ┌───────────────────────────────────────────────────────────┐ │ ExcludeFile [mask] │ SUBTYPE └───────────────────────────────────────────────────────────┘ Usage : This option is a sub-option and must be coded between a USER and USEREND option. It can not be used as a stand-alone option. This option is only in effect for the user that you coded on the USER option belonging to the cluster where this option will appear. The ExcludeFile option will give you a method to deny access to a file or files you supply in the parameter. [mask] can be a single filename but also a filename with wildcards. You can supply up to 100 ExcludeFile options PER user. An example: User Rob van.hoeven ExcludeFile *.ZIP ExcludeFile *.COM .. .. UserEnd In this example, user 'Rob van.hoeven' can not access the files with the extensions ZIP and COM. These files will be displayed in a DIR but all manipulations (DEL, MOVE, COPY, RENAME, TYPE and so on) are denied ! ┌───────────────────────────────────────────────────────────┐ │ ExcludeDirectory [directory] │ SUBTYPE │ ExcludeDirectory [directory*] │ SUBTYPE └───────────────────────────────────────────────────────────┘ Usage : This option is a sub-option and must be coded between a USER and USEREND option. It can not be used as a stand-alone option. This option is only in effect for the user that you coded on the USER option belonging to the cluster where this option will appear. The ExcludeDirectory option will give you a method to deny access to a directory you supply in the parameter. [directory] must be a fully specified name of a directory (so you MUST include the drive-letter). You can supply up to 100 ExcludeDirectory options PER user. An example: User Rob van.hoeven ExcludeDirectory C:\ZIP ExcludeDirectory C:\BBS\RAX .. .. UserEnd In this example, user 'Rob van.hoeven' can not access the directories C:\ZIP and C:\BBS\RAX. These files will be displayed in a DIR but you can not display the directories (with a DIR) itself, nor can you ChDir to them, remove them or even make them (if they weren't there at all). File access from and to these directories is denied (DEL, REN, MOVE, COPY, TYPE and so on) if this was not already the case (because of ExcludeFile and/or ExcludeDrive). A special extension to the ExcludeDirectory option, is the same option with a wildcard. You can add a '*' to a given path to force RDS to allow the supplied directory but to deny the access to the directory UNDER this directory. For example, you would like to allow the user to access the directory E:\ZIP but disallow the access to E:\ZIP\DIS and E:\ZIP\PAT (the two directories UNDER the E:\ZIP directory). In this case you supply 'ExcludeDirectory E:\ZIP\*'. If you supply 'ExcludeDirectory E:\ZIP*' you force RDS to deny all access to both E:\ZIP, E:\ZIPZAP, E:\ZIP\DIS and so on.... ┌───────────────────────────────────────────────────────────┐ │ ExcludeDrive [drive:] │ SUBTYPE └───────────────────────────────────────────────────────────┘ Usage : This option is a sub-option and must be coded between a USER and USEREND option. It can not be used as a stand-alone option. This option is only in effect for the user that you coded on the USER option belonging to the cluster where this option will appear. The ExcludeDrive option will give you a method to deny access to a whole drive you supply in the parameter. [drive:] must be a normal drive-letter like A:, C: and so on. You can supply up to 26 ExcludeDrive options PER user. An example: User Rob van.hoeven ExcludeDrive C: ExcludeDrive A: .. .. UserEnd In this example, user 'Rob van.hoeven' can not access the drives A: and C:. File access from and to these drives is denied (DEL, DIR, REN, MOVE, COPY, TYPE and so on) if this was not already the case (because of ExcludeFile and/or ExcludeDrive). ┌───────────────────────────────────────────────────────────┐ │ NoDrive │ SUBTYPE │ NoCls │ SUBTYPE │ NoMem │ SUBTYPE │ NoUserOn │ SUBTYPE │ NoVer │ SUBTYPE │ NoDate │ SUBTYPE ││ NoSetDate │ SUBTYPE │ NoTime │ SUBTYPE ││ NoSetTime │ SUBTYPE │ NoDir │ SUBTYPE │ NoCD │ SUBTYPE │ NoRD │ SUBTYPE │ NoMD │ SUBTYPE │ NoDel │ SUBTYPE │ NoRen │ SUBTYPE │ NoType │ SUBTYPE │ NoRType │ SUBTYPE │ NoCopy │ SUBTYPE │ NoMove │ SUBTYPE │ NoKillNice │ SUBTYPE │ NoKillForce │ SUBTYPE │ NoBoot │ SUBTYPE │ NoViewArc │ SUBTYPE │ NoUpload │ SUBTYPE │ NoDownload │ SUBTYPE │ NoChat │ SUBTYPE │ NoBeep │ SUBTYPE │ NoLog │ SUBTYPE │ NoWhere │ SUBTYPE │ NoExpand │ SUBTYPE │ NoMacro │ SUBTYPE │ NoModemSend │ SUBTYPE │ NoModemStat │ SUBTYPE ││ NoTree │ SUBTYPE ││ NoCompare │ SUBTYPE ││ NoFree │ SUBTYPE ││ NoLabel │ SUBTYPE ││ NoAlias │ SUBTYPE ││ NoForceDir │ SUBTYPE │ Shell │ SUBTYPE ││ Spawn │ SUBTYPE └───────────────────────────────────────────────────────────┘ Usage : This option is a sub-option and must be coded between a USER and USEREND option. It can not be used as a stand-alone option. This option is only in effect for the user that you coded on the USER option belonging to the cluster where this option will appear. Each of these options will deny a feature (or command) for this user. They have the following meaning: NoDrive User can not use C:, D: and so on; NoCls User can not use CLS NoMem User can not use MEM NoUserOn User can not use USERON NoVer User can not use VER │ NoDate User can not use DATE (also no alter) │ │ NoSetDate User can use DATE (unless NoDate is specified) but │ can only look at, and not update, the date │ │ NoTime User can not use TIME │ │ NoSetTime User can use TIME (unless NoTime is specified) but │ can only look at, and not update, the time NoDir User can not use DIR NoCD User can not use CD or ChDir NoRD User can not use RD or RmDir NoMD User can not use MD or MkDir NoDel User can not use DEL or ERASE NoRen User can not use REN or RENAME NoType User can not use TYPE or LIST NoRType User can not use RTYPE or RLIST NoCopy User can not use COPY NoMove User can not use MOVE │ NoTree User can not use TREE │ │ NoCompare User can not use COMPARE │ │ NoFree User can not use FREE │ │ NoLabel User can not use LABEL NoKillNice User can not use KILLNICE NoKillForce User can not use KILLFORCE NoBoot User can not use BOOT NoViewArc User can not use VIEWARC NoUpload User can not use UPLOAD NoDownload User can not use DOWNLOAD NoChat User can not use CHAT (but still receive messages) NoBeep User can not use BEEP NoLog User can not use LOG NoWhere User can not use WHERE NoExpand User can not use EXPAND NoMacro User can not use MACRO NoModemSend User can not use MODEMSEND NoModemStat User can not use MODEMSTAT │ NoAlias User can not use ALIAS and/or #[aliasname] │ │ No#name User can not use a call to alias [name] but still │ can use other alias calls (if any) and ALIAS itself │ │ NoForceDir User can still access all other valid directories │ and drives, even when the -D command-line option │ is used Shell User can use SHELL. The default is NOSHELL !! │ Spawn User can use SPAWN. The default is NOSPAWN !! An example: User Rob van.hoeven NoMEM NoMOVE NoCOPY NoDEL NoSetTime NoSetDate NOREN UserEnd In this example, user 'Rob van.hoeven' can not manipulate files because MOVE, COPY, DEL and REN will not work. Also a display of memory (MEM) will not work. Date and time can be looked at, but can not be altered. Included in the package is a sample RDS.CTL with a number of users (names do not match real persons <grin>) and what they can or can't do with RDS. 3.4 Available commands ──────────────────────────────────────────────────────────────────────── Depending on the USER ... USEREND option for that user, the following DOS-commands are available: HELP See below DIR A full color directory with pause COPY A copy of a file MOVE A move of a file TYPE or LIST A type of a file RTYPE or RLIST A type of a file but from bottom to start (reversed) REN or RENAME A rename of a file DEL or ERASE A delete of a file │COMPARE Compare two files │ │TREE Display a tree CLS Clear the screen MEM See below VER Version of DOS (and 4Dos if present) │DATE Get and (optionally) set system-date │ │TIME Get and (optionally) set system-time CD or ChDir Change to a directory. This is in fact a CDD. If you supply a drive along with the path, the drive is also switched MD or MkDir Make a directory RD or RmDir Remove a directory x: Where 'x' is a drive letter. Switch to this drive EXIT Terminate RDS USERON See below KILLNICE See below KILLFORCE See below BOOT See below VIEWARC See below UPLOAD See below DOWNLOAD See below CHAT See below TIMELEFT See below BEEP See below LOG See below WHERE See below │FREE See below │ │LABEL See below │ │MACRO See chapter on macro's │ │ALIAS See chapter on aliases │ │#aliasname See chapter on aliases SHELL See below │SPAWN See below MODEMSEND See below MODEMSTAT See below Most of these commands are known to anyone who ever worked with DOS directly. There are a few specific enhancements to the normal subset of DOS-commands. These are: ┌───────────────────────┐ │ HELP │ └───────────────────────┘ You can use HELP in two ways. First you can use HELP without options and you will get a small list with available commands. Second, you can use HELP with a command (like HELP DIR or HELP MOVE) and you will get a screen full of help info on this specific command (only when the Sysop has implemented all *.RDS files). ┌───────────────────────┐ │ MEM │ └───────────────────────┘ MEM will give you a display with memory information. The display is made up with four different parts: - Conventional memory The available and total conventional memory in the PC - Expanded memory The available and total expanded (EMS) memory in the PC (if any) - Extended memory The available and total extended (above the 1024K) memory (if any) - XMS memory The available and total memory that is accessed by the XMS driver; Depending on the type of machine and the type of memory drivers you have, some or more values can be ignored. In some machines with QEMM (like mine) and extended memory available, RDS will report that there is no extended memory available. This memory is shared with the number of bytes of XMS memory. ┌───────────────────────┐ │ USERON │ └───────────────────────┘ │This command will only work when you specified the BBSType option as │being RAxx. If this is the case, USERON will give a display of all available RA-lines and their status. Displayed are the names of the users being online, their baud-rate and if they have the 'Do not disturb' option ON or OFF. ┌───────────────────────┐ │ KILLNICE │ └───────────────────────┘ This command will only work when you specified the BBSType option as being RAxx and if you supplied a RADOWNTEXT option in RDS.CTL. This being the case, KILLNICE is able to terminate a user in some line. The format you must use is 'KILLNICE [linenumber]'. After entering such a command (lets say for line 3), RDS will copy the file sup- plied in the RADOWNTEXT option to NODExx.RA (in this case NODE03.RA) and will add a 'hangup' sequence after the file. Once in a while, the BBS will look to see if a NODExx.RA is present and will display the text to that user and force the line down. This is not the case when a user is inside a door or an external protocol. You can check if this is the case by giving USERON after 15-20 seconds. If the user is still online, you can be sure she/he is somewhere in a shell. In this case you must use stronger options (KILLFORCE). As you should have understood by now, this command has only meaning in a MULTI-LINE environment where the multiple lines are running on the SAME machine. ┌───────────────────────┐ │ KILLFORCE │ └───────────────────────┘ This command will work in any type of BBS. If you want to remove a user from another line and you can not use KILLNICE or KILLNICE has no effect (doors and so on, see above), you can enter the KILLFORCE command. The format is 'KILLFORCE [comport]'. This option needs some knowledge about the system. You must know the COM-port of a given line │and supply it to KILLFORCE (NOT !! the FOSSIL-port). KILLFORCE will │lower the DTR and RTS of the given COM-port. This is done with ASYNCH │communications. It is impossible to KILLFORCE your own COM-port (the │one that you are running on). KILLFORCE will first ask for a │confirmation of the command and will also raise the DTR again, after a │few seconds. │ │As you should have understood by now, this command has only meaning in │a MULTI-LINE environment where the multiple lines are running on the │SAME machine, or when you logon to RDS when running locally ! ┌───────────────────────┐ │ BOOT │ └───────────────────────┘ This is a brutal one. It will reboot the machine (warm). You are given 15 seconds to make up your mind. After 15 seconds it is to late and the PC is rebooted. You MUST stay online to make the boot work. If between entering the command and the final countdown the carrier is lost, the boot will NOT take place. Also any key will stop the countdown and will bring you back to the RDS-prompt. Some configurations with DesqView/QEMM and a 386 will hang with the boot, so try it out locally before submitting this command to your remote friends and/or CoSysop(s). ┌───────────────────────┐ │ VIEWARC │ └───────────────────────┘ When this command is used with a valid (fully specified filename), the user will get a view of the archive (if it IS an archive) in question. For ZIP/DWC encryption is also marked in the list, for ZIP there is a mark when the file is AV'ed. The VIEWARC command can be used on archives with normal and abnormal extensions and also on all SFX (COM/EXE) self extracting archives. Archive comments are NOT displayed, neither are (absolute or relative) path entries inside the archives. The CRC (for what it is worth) is also NOT displayed. ┌───────────────────────┐ │ DOWNLOAD │ └───────────────────────┘ │When you supply DOWNLOAD, RDS will display a menu of installed │protocols (look at the DOWNLOAD option (primary) in RDS.CTL). If there │are no protocols installed for download or if the current time does │not allow download (See DownloadHours option in RDS.CTL), download │will be impossible. │ │After the selection of the protocol, the user can (depending on the │installation in RDS.CTL) supply 1 to 255 files for download (each at a │time, will complete security checks). After selecting the last file, │the protocol can be started to actually transfer the files. When using │DOWNLOAD locally, RDS will call the protocol, so you can check if the │parameters for that protocol ar correct. ┌───────────────────────┐ │ UPLOAD │ └───────────────────────┘ │When you supply UPLOAD, RDS will display a menu of installed protocols │(look at the UPLOAD option (primary) in RDS.CTL). If there are no │protocols installed for upload or if the current time does not allow │upload (See UploadHours option in RDS.CTL), upload will be impossible. │ │After the selection of the protocol, the user can supply 1 filename │for upload (with complete security check). After the user supplied the │file, the protocol can be started to actually transfer the files. │When using UPLOAD locally, RDS will call the protocol, so you can │check if the parameters for that protocol ar correct. ┌───────────────────────┐ │ CHAT │ └───────────────────────┘ When this command is used, you can chat with any other line (also with yourself, makes fun, doesn't it ?). This function is only present under Remote Access and only when /N is used in the RDS call on the menu-entry. ┌───────────────────────┐ │ TIMELEFT │ └───────────────────────┘ This function will display the remaining time. RDS will display the time left for this session. This time is between 1 and 2 minutes less than the actual time because accessing RDS within 2 minutes before the end of the session-time is impossible. ┌───────────────────────┐ │ BEEP │ └───────────────────────┘ This command can be used to attract the Sysop's attention. When BEEP is given on the command-line, the Sysop will be bothered with a nice tune of beeps. If she/he wants to chat with you, she/he can enter a message on your command-line (locally) f.i. to exit RDS and to continue chat in a normal chat-door. ┌───────────────────────┐ │ LOG │ └───────────────────────┘ If you want to send a message to the Sysop, you can enter LOG with a text and RDS will send this message to the RDS-log. The Sysop can check the log (if she/he does so) and answer you (if needed/wanted) with a message in the BBS. ┌───────────────────────┐ │ WHERE │ └───────────────────────┘ With this command you can search the CURRENT drive for a file or a number of files. You must supply a valid DOS-filemask and RDS will search the CURRENT drive for matching files. They are displayed to the user, along with the directory they are in. │┌───────────────────────┐ ││ FREE │ │└───────────────────────┘ │With this command you can display (in graphics and text) the free space │for a given drive. If the drive is not present (A:, B:, unknown drive) │RDS will trap the error and return a message. │ │┌───────────────────────┐ ││ LABEL │ │└───────────────────────┘ │This is a, somewhat simple, type of label. For security reasons, it is │impossible to remove an existing label, nor can the user create a new │label. LABEL can only be used to CHANGE the existing label into a new │value. ┌───────────────────────┐ │ MACRO │ └───────────────────────┘ See the chapter on macro's, expansion and command stacking. │┌───────────────────────┐ ││ ALIAS and #aliasname │ │└───────────────────────┘ │See the chapter on aliases. ┌───────────────────────┐ │ EXPAND │ └───────────────────────┘ See the chapter on macro's, expansion and command stacking. ┌───────────────────────┐ │ MODEMSEND │ └───────────────────────┘ │With this command you will enter a complete terminal package. The │routines used to communicate with the modem are asynchronous routines. │You can only MODEMSEND on another modem than the one you are running │on. │ │The MODEMSEND command is meant to send commands to the selected modem │but it CAN even be used to call the 'outside world' on the modem. With │some tricks you could even call a BBS and download some files. This │must also be a very secured command. It could happen that one of your │hacking users will use MODEMSEND to get files in a cheap way. How ? By │calling you local (on 2400 baud), using your MODEMSEND command to call │a foreign country (hopefully with your 38400 quadruplex modem) and to │obtain some files over there which can be downloaded by him at 2400 │baud (on local costs) ! │ │If you want to initialize the modem on COM2 f.i., you can supply: │ │MODEMSEND 2 (2 is the com-port) │ │and then give AT Z (wait for the answer). │ │You can quit by sending RDS#QUIT to the terminal. In that case the │terminal will stop and you are back on the RDS prompt ! Before the │MODEMSEND command is executed, RDS will first lower and raise the DTR │of that modem. Also, the baudrate at which to perform the │communication will be asked if the SysOp has not included a MAXBAUD │option (primary) inside his/her RDS.CTL ! ┌───────────────────────┐ │ MODEMSTAT │ └───────────────────────┘ With this command you can request the status of a modem. You will be returned the status of the CTS, DSR, DTR, CD, RI(NG) and RTS. The │command will wait for a few seconds to see if the RI(ING) register is │changing (DELTA-RING is not used). ┌───────────────────────┐ │ SHELL │ └───────────────────────┘ This is a VERY DANGEROUS command and should only be supplied to users you trust (CoSysop, yourself (?)). SHELL will execute the program you supply as first parameter (you can include drive and path if you want) and uses the parameter(s) (if any) following the program-name as │calling parameters for this program. The program is called with a call │to GETENV(COMSPEC) + '/C' (so SHELL PKZIP.EXE under DOS, will result │in a call to C:\COMMAND.COM /C PKZIP.EXE). There are some major │drawbacks when using the SHELL command: -1) The called program can not access any input, so the program must be able to execute without user-input. Even a program as PKZIP uses input if you call it with invalid parameters or needs to overwrite files. If RDS calls such a program, the session will hang forever because you can never enter the input for the program. For this reason, RDS will set the FOSSIL-watchdog to ON if a program is called. If the carrier is lost (after the user will hangup the line), the FOSSIL wil reboot the system (please run a test !!!). RDS tries to overcome some minor errors made by the user. If the user enters SHELL PKZIP -A$^&*&(()&^ TEST D*.* (some garbage on the line), PKZIP will display it's info and waits for a CRLF to terminate. Before RDS calls the program, 15 times [RETURN] is stuffed into the local keyboard, so PKZIP will (in THIS case) terminate. This will not fix problems like 'Over- write file [y/n]' !. The key-stuffing will NOT be performed when using SHELL on the local side ! -2) The called program should not access non-bios (e.g. direct) output. If the program does use direct screen control, the program can be executed, but the results can not be viewed inside RDS. If the programs uses normal standard devices, RDS will display (after termination) the output to the local and remote screen. RDS will route the output of the program to a temporary file (>RDS$$$$$.CAL) and will display this file after the execution is │ completed. When running locally, the rerouting of the output will │ NOT be performed and the output will be displayed directly ! There are several programs that could be very useful to execute. The archivers (watch out for prompts !!), the fossil driver (XU or some other program), tossing, scanning (these utilities should work unattended, shouldn't they ??) and so on; RDS will always return in the directory it was started from after the user enters EXIT, unless a UserDirectory is active. In this case, RDS will return to the directory that was current when RDS was CALLED ! │RDS will perform a memory-swap (swaps itself from memory) before the │command is called under DOS (leaving around 4K of RDS inside the │conventional memory). │┌───────────────────────┐ ││ SPAWN │ │└───────────────────────┘ │This is a VERY DANGEROUS command and should only be supplied to users │you trust (CoSysop, yourself (?)). SPAWN will execute the program you │supply as first parameter (you can include drive and path if you want) │and uses the parameter(s) (if any) following the program-name as │calling parameters for this program. The program is called with a │DIRECT call (so supply the full path to the program). This is the │major difference between SHELL and SPAWN ! There are some major │drawbacks when using the SPAWN command. They are the same as with │SHELL ! │ │RDS will always return in the directory it was started from after the │user enters EXIT, unless a UserDirectory is active. In this case, RDS │will return to the directory that was current when RDS was CALLED ! │ │RDS will perform a memory-swap (swaps itself from memory) before the │command is called under DOS (leaving around 4K of RDS inside the │conventional memory). 3.5 Security ──────────────────────────────────────────────────────────────────────── As you have understand by now, RDS is capable of securing the shell for each and every single user. A few hints to concern about when setting up the security inside the USER-USEREND clusters: - If you want to know everything about what users (or yourself, or the CoSysop) have done, than consider to secure the LOG-file with a ExcludeFile [the log file] option, otherwise these users can cover their deeds by deleting the log or replacing it with a 'dummy' log; - If you want real security, then you must protect the RDS.CTL also. There is nothing more simple than a user (having the COPY feature) to upload a 'customized' RDS.CTL of their own and to replace the original one with the one of their own. So be warned !!!! - It is a good practice to also secure the RDS.EXE program itself from any ill-behavior. Old chinese wisdom will say: 'If there is a leak, a BBS-user will use it' and also Murphy told us some stories about 'When you are able to accidently delete the RDS.EXE file, it will be deleted'. - Protect personal things unless your CoSysop (or someone else you give RDS features) knows as much about you as you know yourself; - Don't allow your shrink to use RDS. He will find out that the way you set up your directories has something to do with Freud; - If you allow many users directly after you have installed RDS, be sure to have a backup-copy available. Work with a small group of people (at least in the beginning) or use the USER ALL with mini- mal options. - Study the LOG once in a while, and set it to ON in the beginning. In this way you can learn from your friendly CoSysop what to include and what to exclude <grin>. - It is good practice to secure your 'power users' (like those nasty CoSysop's and such people) with a RDS-password. If someone snatches your USERS.BBS (sometimes your USERS.BBS is wide open, check out your bi-directional protocols and such programs) and does a logon under your name or the CoSysop's name, you can be sure that everything is lost EVEN when there is no FORMAT statement in RDS (MOVE, DELETE, RENAME and COPY will do the job just fine); - DON'T give away the SHELL feature. A nice option, but only for the trusted user (SHELL FORMAT C: /U to name one) ! NoShell is default so you must include SHELL for you and your CoSysop in the USER- USEREND cluster !!! │- The same goes for SPAWN and ALIAS functions that need local input for │ the called programs; 3.6 Macro's, expansion and command-stacking ──────────────────────────────────────────────────────────────────────── Why not implement wildcard support on those commands that can use it. This question has to do with security. To keep the memory resources tight, there are generalized security routines implemented that work on single files. Also, in a BBS environment, wildcards can be handy but not used much. Can you see a CoSysop deleting all your files in one of your directories without having to think about it ? That is one of the several reasons that only single-file commands are implemented. The security structure is based on this algorithm, so are the memory requirements. Implementing wildcards on any command causes a large algorithm to be triggered to test if every request is valid or not (imagine something like COPY *.* E:\ZIP\*.ZIP). Besides the problems with the rename (that part will be implemented in the next major command) on these 'global' commands like COPY, RENAME and MOVE, RDS has to check every source and every target to see if this is what the user is allowed to do. To support wildcards and to implement macros (as available in this version) in some sort of way, RDS now has a command-stack. Some basics on this command-stack. Before RDS checks for the next command to be entered by the user, RDS will check a buffer to see if there is a command (a normal RDS command) available in this buffer. If it is, RDS wil skip (for now) the next user-input and starts with this command. When the command is ready, RDS will delete it from the top of buffer and shift the remainder of the buffer one place back (FIFO-buffer). This routine stays active until there are no commands left in the buffer (empty buffer). If this is the case RDS will, as normal, ask the user for input. Two RDS commands can fill the buffer. These are EXPAND and MACRO. Each of the commands will add commands to the buffer from the top. This will always be done with the following algorithm (IMPORTANT, be- cause this will give you knowledge of how MACRO and EXPAND wil act when they are nested: In case of buffer-empty: - EXPAND or MACRO knows how many commands are to be added to the buffer and will add them from top to bottom; In case of buffer-active (commands in the buffer): - The first thing to know is that the MACRO or EXPAND was already on the buffer as a command. The user can not enter into the buffer when there are commands in the buffer, so the MACRO or EXPAND was already on the buffer; - EXPAND or MACRO know how many lines to add to the buffer, BUT these commands are, again, inserted at the TOP of the buffer. So the buffer acts as a LIFO (last in, first out) when a MACRO or EXPAND command is taken from the buffer; - All remaining commands in the buffer (if any) will shift to the end of the inserted lines. RDS will check if there is enough room to add commands to the buffer, but RDS will not take into account if the room is occupied with other commands. In plain language. If your buffer is 10 lines and there are 5 lines (EXPAND, COPY, COPY, DEL, RENAME for example) and the EXPAND, that is executed first, will generate 12 new commands, EXPAND will fail. If EXPAND generates 4 lines, they are inserted at the top, resulting in the RENAME, DEL and last COPY to be shifted from the buffer. This last situation is NOT detected by RDS (yet). I will give an example at the end of this chapter. Now you know that RDS has a command-stack, explaining MACRO is very simple. You create one (or more) macro-files or the user uses UPLOAD to upload a macro. The macro-file is a plain ASCII file, containing a RDS command on each of the lines in the file. An example: COPY TURBO.EXE E:\ZIP RENAME TURBO.EXE TURBO.BAK MOVE E:\ZIP\MACRO.EXE This macro contains 3 RDS statements in three different lines. The macro-file can be as big (but NOT bigger) than the total number of lines in the buffer (as set with the MacroExpandBuffer option). The file is called MACRO1.DAT for example. So when you enter the command MACRO C:\TUP\MACRO1.DAT (or MACRO MACRO1.DAT if the macro is in the current directory), RDS will read MACRO1.DAT and then execute the three commands (COPY, RENAME and MOVE) in the order they were in the macro-file. You CAN nest macro-files as long as you remember not to overflow the buffer (see example at the end). EXPAND has nothing to do with macro's but act the same. EXPAND also uses the command-stack in RDS. EXPAND can be used to implement wild- cards in certain commands. These commands are DEL, TYPE, VIEWARC, RTYPE, DOWNLOAD, COPY, MOVE and their alias (ERASE, LIST, RLIST). How EXPAND works can be showed best with an example. You would like to delete ALL files with *.BAK in the directory E:\ZIP. Normally, you should use DIR *.BAK and delete every single file. With EXPAND you use 'EXPAND DIR *.BAK' (without quotes). Now the following things will happen: - EXPAND will check for all files with that mask in that directory; - EXPAND will create a command 'DEL filename' for every found file in that directory on the command-stack; - EXPAND will terminate and the command-stack now contains commands that will be executed at once. RDS will, as normal, check every single 'DEL' command for valid data. So if the files TURBO.BAK, RA.BAK and QB.BAK are found (and commands are generated) and the user is NOT allowed to access files with QB.*, the 'DEL QB.BAK' will fail and the others will work. RDS will keep full security on each of the generated commands. There are a few drawbacks in EXPAND: - When used with COPY and MOVE, EXPAND will only work when the target is a directory (so no renaming while COPY/MOVE). So the command 'EXPAND COPY *.* E:\ZIP\' is valid but 'EXPAND COPY *.BAK *.OLD' is invalid (*.OLD is no directory). This drawback will be fixed in one of the next majors; - When used with DOWNLOAD, EXPAND will create separate DOWNLOAD commands, causing ill-behavior of the command because after the trans- mission of a single file, DOWNLOAD is terminated and the next is started. This will also be fixed in the next major; EXPAND is a powerful command and MACRO can also be very useful. The combination of both is valid in case of EXPAND commands inserted in- side a macro file, but not valid in case of MACRO in EXPAND (like 'EXPAND MACRO *.MAC'. Now an example. There are two macro-files (the statements are all humbug) MACRO1.MAC and MACRO2.MAC: MACRO1.MAC COPY A.A B.B MACRO MACRO2.MAC TYPE B.B MACRO2.MAC TYPE A.A EXPAND COPY *.* E:\ZIP The execution is as follows when MACRO MACRO1.MAC is entered at the RDS command-line: - COPY A.A B.B - MACRO MACRO2.MAC (the macro2.mac is INSERTED in the stack) - TYPE A.A - EXPAND COPY *.* E:\ZIP (this command generates 2 statements ) - COPY A.A E:\ZIP\A.A (generated by EXPAND ) - COPY B.B E:\ZIP\B.B (generated by EXPAND ) - TYPE B.B Play around with EXPAND and MACRO. The next majors will enhance their functions again. Last but not least, you can deny the usage of EXPAND and/or MACRO, just like with all other commands. │3.7 ALIAS's │──────────────────────────────────────────────────────────────────────── │With RDS release 2.01 and higher, you can make usage of the ALIAS │mode. If you have one or several tedious tasks that you would like to │perform with one command under RDS, you can create a so called │alias-file. You should examine the ALIAS command (primary command) in │RDS.CTL for a description of the format. The alias-file itself can │contain an unlimited number of lines. Each line must contain either │REM, SPAWN or SHELL at the begin of the line and the rest of the line │will be used as the command to perform. In general, you use alias │files when you are LOCALLY under RDS because all commands inside the │alias-file will be performed without questions asked. In this case, │all security is overruled. Also, all programs that you call could │generate questions which can NOT be answered when running remote │(again, RDS is not a doorway-alike program). When you only want to │perform RDS-commands, you can better use macros ! │ │An example of an ALIAS command in RDS.CTL: │ │ALIAS CLEAN D:\BBS\RDS\CLEAN.RDA │ │And the actual CLEAN.RDA file: │ │This alias will delete all *.BAK files and call RFC │SHELL DEL *.BAK /Y │SHELL CD D:\OLDFILES │SHELL DEL *.BAK /Y │SPAWN D:\BBS\RFW\RFC.EXE │ │The SHELL and SPAWN commands work the same as when they are entered │under RDS (but without security). The other statement is used to get a │description of the ALIAS when you enter the command ALIAS inside RDS. │That given line MUST be the first line inside the ALIAS-file. │ │You can execute this alias by entering #CLEAN on the RDS command-line. │Users can be denied of the usage of this alias when you enter the │NO#CLEAN option in their USER/USEREND subset. │ │As a general rule, you should include a NOALIAS sub-command in every │USER/USEREND block (except your own) or exclude the dangerous aliases │for all users. 3.8 Help file format ──────────────────────────────────────────────────────────────────────── Up from release 1.20, RDS makes use of only one help file (previous versions used a help-file per command). You can alter the supplied example of the RDS.HLP file to your own needs. To do so, you must understand the basic formats that are used by RDS when reading this help-file: - RDS read the RDS.HLP file sequential. For speed gain, you should put the help-information that is accessed most (e.g. NOT COPY,DEL,MOVE) at the start of the file; - RDS read each line and compares the first 10 bytes (trimmed with trailing spaces) with the command you would like to have help on. RDS translates some commands. LIST and RLIST are translated to TYPE and RTYPE, ERASE is translated to DEL, REN to rename and such (look into the original RDS.HLP example-file. It contains all the valid commands); - The next 78 bytes are written to the screen. If you use shorter lines, RDS will fill them to 78 bytes, longer lines are truncated between the 78th and 79th position; - Lines containing 'ALL ' in the first 10 positions are always displayed (you can use them for headers and such); - Characters in the first 10 positions must be in uppercase; - Help-screens are displayed without pause, so keep the length of the help-text inside a logical screen (19 lines) otherwise scrolling will be the case; The current help features are extended in the next major release. This release will probably contain overlays and swapping techniques to gain memory (for shell, and more new features/commands on RDS) and some of the memory gain will be used to make the HELP function more intelligent both to the user and the SysOp. ┌───────┬─────────────────────────────────────────────────────────────┐ │ 4 │ Runtime information │ └───────┴─────────────────────────────────────────────────────────────┘ 4.1 While inside the RDS shell ──────────────────────────────────────────────────────────────────────── RDS works just like a normal DOS-prompt ($P$G) in a regular DOS environment. All commands can be entered just like you do while inside the normal DOS-shell. RDS expands the entered items (paths, drives, file) to full path-names. The only thing you can't work with (at the moment) is with wildcards, so all actions you enter must be done on single files ! To help you with tedious keyboard access when you must copy, move or delete multiple files in long paths, RDS contains a special buffer with the last 100 (!) commands you entered. Locally you can recall these commands by pressing the UP-key until you find a command that suits your needs. Remote the UP-key does not work but there you have three other options to recall the commands in the buffer: - By pressing REC or RECALL When you enter REC (or RECALL) you get the previous command (if any) on the command-line. To scroll thru the buffer you must (after each command) clear the line and enter REC again. REC is only useful when you want to recall the LAST command; - By pressing CTRL-E Most users of full-screen message editors will know this command. When you send a CTRL-E from the remote computer, RDS will act the same as with the UP-key on the local computer. Even when the command line is not empty, pressing CTRL-E will scroll back one command at a time until no more commands (up to 100) are left. This is the preferred method when scrolling back multiple commands; If you don't know anymore which commands can be used with RDS then you should enter ? or HELP to get a display with all available commands. When you enter an empty line, RDS will also remember you to use ? or HELP to obtain all commands on the screen. │4.2 Keyboard commands at the local side │──────────────────────────────────────────────────────────────────────── │When RDS is active (either remote or locally), you (as the Sysop) can │enter some (common) keyboard commands. They are: │ │ALT-H To hangup the user (without showing why) │ │ALT-C Execute a chat-program, but only active when you have included │ the CHATCALL option (primary) in RDS.CTL; │ │ALT-J Jump to DOS. The jump will be shown to the user (his keyboard │ will be locked and he gets a message). RDS will swap before │ the shell is actually called ! │ │In a later version I will include a status-bar at the local side. For │now you have to remember these keys but they are common to almost │every BBS program. 4.3 LOG file ──────────────────────────────────────────────────────────────────────── RDS makes a log of almost everything (unless you do not specify the LogPath option in the RDS.CTL). You can always browse thru the log with a normal file-browse utility like Mr. Buerg's LIST. The log-style can be adjusted to the users need with four different options (see the description of RDS.CTL). Also you can combine the log with an existing log-file like the log your mailer produces or the BBS-log. In a multitasking environment (when you loaded SHARE), RDS will serialize the LOG when it has to write to it. This is needed to overcome the problem of trashed log-files or lost clusters when two or more tasks try to write to the same log. Depending on the users actions, the RDS.LOG file can get very large. If you delete your current log-file, RDS will create a new one the next time it is started and finds that there is no log-file anymore. If you allow your users to use the LOG command, it should be advised to make the RDS-logging active, otherwise the users messages will be send into the Twilight Zone. 4.4 Errors ──────────────────────────────────────────────────────────────────────── Every time RDS is started, it will check the options in RDS.CTL. If one or more of the options is invalid, RDS will terminate with a local display (and if the log-file is already known to RDS, by putting an entry in the log-file). RDS will also terminate if a user is not allowed to enter the door (no USER-USEREND combination for that user) and when the carrier is lost while RDS is active. RDS will NOT use any watchdog that is present in your FOSSIL. 4.5 Specialized command-line options ──────────────────────────────────────────────────────────────────────── RDS understands some command-line parameters that can (or must) be entered on the call to RDS (inside the menu-entry or a batch file). ┌───────────────────────┐ ││ -CTL[path_to_ctl] │ └───────────────────────┘ You can use an alternate configuration file. In this case you can add │the -CTL command-line option with the path (and name) of the alternate configuration file. │┌───────────────────────┐ ││ -B[baudrate] │ │└───────────────────────┘ │If you want to overrule the baudrate that normally is taken from │EXITINFO.BBS or DORINFO1.DEF (the latter for MAXIMUS and OPUS), you │can supply -B with the baudrate (like -B2400 for 2400 baud). This │command-line parameter is normally not needed unless the information │from either EXITINFO.BBS or DORINFO1.DEF is incorrect. │ │┌───────────────────────┐ ││ -C[com-port] │ │└───────────────────────┘ │If you want to overrule the COM-port that normally is taken from │EXITINFO.BBS or DORINFO1.DEF (the latter for MAXIMUS and OPUS), you │can supply -C with the COM-port (like -C1 for COM1). This command-line │parameter is normally not needed unless the information from either │EXITINFO.BBS or DORINFO1.DEF is incorrect. │ │┌───────────────────────┐ ││ -F[fossil-port] │ │└───────────────────────┘ │If you want to overrule the FOSSIL-port that normally is taken from │EXITINFO.BBS or DORINFO1.DEF (the latter for MAXIMUS and OPUS), and is │calculated as COM-port minus 1, you can supply -F with the FOSSIl-port │(like -F0 for FOSSIL-port 0). This command-line parameter is normally │not needed unless the information from either EXITINFO.BBS or │DORINFO1.DEF is incorrect. ┌───────────────────────┐ ││ -N[line] │ └───────────────────────┘ │You must specify -N*N on a RA menu entry to enable the CHAT option. RA will substitute the numeric line-number at the location of *N. │Under a different BBS, the usage of -N has no meaning. │┌───────────────────────┐ ││ -D[directory] │ │└───────────────────────┘ │This option can be used when you want to force the RDS-user into one │(and only one) directory. The user can only work inside this directory │and only files in this directory can be accessed ! Use this parameter │if you want to setup RDS as an alternative for a bunch of other doors │that rule a given BBS-area. Most BBS's have and option in the │menu-file that can pass the directory of the current files-area to RDS │(or any other door). Try it out and you see the strength of this │option ! ┌───────────────────────┐ ││ -LOC │ └───────────────────────┘ You can run RDS locally (from the DOS-prompt) without the files │EXITINFO.BBS and DORINFO1.DEF present when you supply -LOC on the command-line. ┌───────┬─────────────────────────────────────────────────────────────┐ │ 5 │ Version information and credits │ └───────┴─────────────────────────────────────────────────────────────┘ 5.1 The BETA-team ─────────────────────────────────────────────────────────────────────── Look into the file SUPPORT.RDS for a full list of all beta-testers and support nodes. 5.2 Credits ─────────────────────────────────────────────────────────────────────── Thanks to the following people (besides my eternal thanks for the BETA team): - All paying, registered users. You made it possible to enhance RDS with nice features; - All users who did write me bug reports, suggestions and so on; │- This version (2.01) with a special thanks for Dirk Astrath who kicked │ some life back into RDS; 5.3 Version history ─────────────────────────────────────────────────────────────────────── ┌───────┬────────────────────────────┐ │ 1.01 │ First public release │ └───────┴────────────────────────────┘ ■ New release ┌───────┬────────────────────────────┐ │ 1.02 │ Minor release │ └───────┴────────────────────────────┘ ■ Fixed problem with special keys. Users were not allowed to enter key-values in the range 129-255. This is a major drawback for our (amongst others) German and Scandinavian users. The combinations must be send to RDS as the key-value, ALT-key-key-key combination as found on the DOS-prompt and some editors is not (yet) implemented. ■ Users who tried to TYPE/LIST the RDS.LOG were in for a surprise. RDS would keep the LOG open while TYPE was executed. This is now fixed. ■ The usage of standard devices AUX, CON, NUL, PRN, LPTx and COMx is now forbidden. This was a big hole in the file access and could cause hangups. ■ When displaying HELP, the user got ALL options, also those that were disabled. This is fixed. Users now only get help on the available commands. ■ The LogPath option is enhanced so multiline users can use different logs per logical line. ■ There was an error in the (undocumented) usage of the RDS environ- ment variable. Both documentation and program are fixed. ■ RDS can now be called with an alternative CTL-file as an option on the command-line. ■ Even if you protect RDS with a security level or when you disable options for special users, you can still secure these users with a special RDS-password. User must (in that case) enter the pass- word within 3 tries otherwise entering RDS is not allowed. Look into the documentation about the USER option. ■ Users who are tired entering new users to RDS.CTL will be pleased with the ALL enhancement. Check out the USER option. ■ RDS is now more or less aware of the new RA 1.00 USERON.BBS file. Until this info is official, this will stay 'more or less'. ■ Added a new command VIEWARC to view the contents of ZIP, ARC, PAK, PKPAK, LHarc, Larc, MD, DWC, ZOO, LBR archives. ┌───────┬────────────────────────────┐ │ 1.05 │ Minor release │ └───────┴────────────────────────────┘ ■ Fixed some problems with EXITINFO.BBS and DORINFO1.DEF files and created a local mode (/LOC); ■ Fixed a bug in MOVE (with /D); ■ Removed some duplicate coding; ■ Enhanced the HELP function with a context HELP function; ■ There was no way to create a file (batch-file or something of the kind) inside RDS. The COPY CON [tofile] is now implemented. The user can input characters and/or lines and these are echoed to the [tofile] file. Editing must be terminated with CTRL-Z (both remote and local); ■ Added specific support for only RA and QBBS and/or BBS types that use EXITINFO.BBS and DORINFO1.DEF; ■ Added /N[line] option to support CHAT under Remote Access; ■ Added the RTYPE/RLIST option to read a file reversed; ■ Added the CHAT function to send messages to other lines under Remote Access. Also messages send to your own line (don't forget /N*N in the menu-call) are echoed to the RDS-screen, so internode chat is available while in RDS; ■ Added the UPLOAD and DOWNLOAD functions so you can upload and/or download a file while inside RDS. This option needs DSZ to perform the transfer. Added the DSZ and DSZParm options in RDS.CTL to support these functions; ■ Added a time-out test in RDS. When the user does not input any character within 5 minutes, RDS terminates. Also carrier is tested everywhere, so the WATCHDOG function is disabled in RDS. RDS will not reboot when the user drops the carrier; ■ Added a test on the remaining time. RDS will terminate 1 minute before the BBS-session will end. Also access to RDS is impossible within 2 minutes before the session ends; ■ Added the TIMELEFT command to display the remaining session time. ┌───────┬────────────────────────────┐ │ 1.06 │ Minor release │ └───────┴────────────────────────────┘ ■ Fixed an error in the RA (1.xx and up) USERON command. Both message and ul/dl would display as ul/dl. ■ Added the SHELL option and SHELL command in the USER-USEREND clusters. Users can now shell a program such as the archivers and other utilities but under certain conditions; ■ Added the HelpDirectory option for those users who are low in environment space and who can not add the directory containing the *.RDS files to the DOS-path; ┌───────┬────────────────────────────┐ │ 1.10 │ Minor release │ └───────┴────────────────────────────┘ ■ Fixed an error in the UserPassword option. In some cases a user could be prompted for a password while this was not set in the RDS.CTL. In that case a previous USER ALL cluster contained a UserPassword option. ■ Added ARJ and HYPER to the VIEWARC options. Files inside archives of this kind will also be displayed. ■ Added DefaultDirectory option so a user can land in a different directory than the current right from the start; ■ Added LOG option to let the user write a message to the log; ■ Added BEEP option to let the user beep the Sysop (if available); ■ Added WHERE option to search files on the current drive; ■ Added /W to the DIR option to display a condensed listing of the files in a directory. ┌───────┬────────────────────────────┐ │ 1.20 │ Minor release │ └───────┴────────────────────────────┘ ■ Fixed a bug in the MEM command. MEM did not show the memory usage of RDS itself. This is fixed. MEM will now give the REMAINING conventional memory. ■ Changed registration; ■ Changed the *.RDS help-files to one new RDS.HLP file, containing all help; ■ Added EXPAND command; ■ Added MACRO command; ┌───────┬────────────────────────────┐ │ 1.30 │ Minor release │ └───────┴────────────────────────────┘ ■ Fixed a bug in the key-support; ■ Fixed a bug in the HelpDirectory command. This command would not allow anything but a directory (so no filename); ■ Fixed a problem in the HELP. HELP would scroll off the screen. Now a MORE prompt will ask if this is allowed; ■ Fixed a bug in EXPAND. When no files were found, EXPAND would wait a while to return. What the user could not see was, that the full internal RDS command-stack was trashed and some variables along the way. This is fixed; ■ Added ModemSend (NoModemSend) and ModemStat (NoModemStat) commands (sub-types); ■ Added support for a single wildcard ('*') in the ExcludeDirectory option in RDS.CTL; ■ Added coding for ARJ 1.xx and LZH 2.xx; ┌───────┬────────────────────────────┐ │ 1.31 │ Minor release │ └───────┴────────────────────────────┘ ■ Added coding for ARJ 2.10 (and up); ■ Fixed coding for LHA 2.xx; ■ Added faster routines for string-handling; ■ Fixed a bug in EXPAND where RDS could hang for an EXPAND on an invalid drive (A:, B:); ┌───────┬────────────────────────────┐ │ 2.01 │ Major release │ └───────┴────────────────────────────┘ ■ Removed the DSZ and DSZParm options; ■ Changed command-line options from / to - (so -N*N and not /N*N); ■ RDS could trash the log-file when it grow above 64K. This is now fixed; ■ RDS would only display a non-destructive backspace at the remote side. This is fixed; ■ Some newer types of archives would not be reported inside VIEWARC. This is fixed; ■ KILLFORCE did lower the DTR but did not raise it again. This is now fixed; ■ MODEMSEND did cause hangups and did not work as expected. The BIOS calls are replaced by ASYNCH routines and the problem is fixed; ■ MODEMSTAT only showed the RING status of THAT moment. MODEMSTAT will now monitor the modem-registers for a few seconds to see if there is a RING; ■ Fixed the USERON coding to work with newer types of Remote Access; ■ When using DOWNLOAD/UPLOAD locally, the protocol was not actually called (only the command-line was displayed). This is changed. The protocol is now called so the SysOp can test if the command-lines are ok; ■ UPLOAD files were not logged inside the RDS log-file. This hase been fixed; ■ SHELL did reroute the output even when running locally. Also the keyboard was stuffed with CRLF combinations. This is now only done when RDS runs for a remote user; ■ A single RDS.CTL can now be coded for several lines. Added line-rule in RDS.CTL ala FileDoor <tm> style; ■ Added coding for 3 types of RA, 2 types of QuickBBS, Maximus, Opus and SuperBBS (RA00/RA10/RA11/QBBS/QNEW/SBBS/MAXI/OPUS on the BBSType option); ■ Added coding to KILLFORCE to ask if you are sure to perform this task; ■ Added coding to MODEMSEND to make it a complete (ASYNCH) terminal when entered; ■ DATE and TIME could only be used in combination with setting the time and date. Added the NoSetTime and NoSetDate subtype options so users can now look at the date and/or time without the option to alter; ■ UPLOAD and DOWNLOAD are rewritten. You can now freely use up to 10 protocols for UPLOAD and 10 (different) for DOWNLOAD. Also it is now possible to supply more than one file for DOWNLOAD when the protocol can work with a file-list (@filelist.ext); ■ Added BEEPHours, UPLOADHours and DOWNLOADHours to limit the BEEP, UPLOAD and DOWNLOAD commands inside specific periods; ■ Added StartUpDirectory to set the default starting directory for ALL users; ■ Added ChatCall option to make it possible to start a normal CHAT program while inside RDS; ■ Added ALT-H (hangup), ALT-J (swapped DOS-shell) and ALT-C (Chat) for the Sysop; ■ Added SPAWN routine. Where SHELL used COMMAND.COM (4DOS.COM) to execute the program, SPAWN will directly call the given program; ■ Added ALIAS options. User can not execute a series of uncontrolled SPAWN/SHELL commands under one name to do some tedious tasks; ■ Added -B, -C, and -F command-line options to overrule the baud-rate, COM-port and/or FOSSIL-port; ■ Added -D command-line option to force the user in ONE (and only ONE) directory when he/she enters RDS; ■ Added NoForceDir sub-option to overrule the -D command-line option for some given users; ■ Added swapping to all shells (download, upload, shell and spawn); ■ RDS is now overlayed. This will cause a maximum of free memory; ■ Added NOEMS and NOXMS options to deny the usage of EMS and/or XMS for program-swap; ■ RDS can now work without EXITINFO.BBS (Maximus and OPUS) and will obtain the information from DORINFO1.DEF; ■ Added the TREE command (and the NoTree subtype option). TREE can be performed when TREE.COM or TREE.EXE is somewhere in the DOS path; ■ Added the FREE command (and the NoFree subtype option). FREE can be used to display the free space on a given disk(ette); ■ Added the LABEL command (and the NoLabel subtype option). LABEL can be used to change (not add or remove) labels on disk(ette); ■ Added the COMPARE command (and the NoCompare subtype option). The compare will be executed when 2 files are of the same length; RDS is tested with several releases of MS/DOS and with Remote Access version 1.11. It is also tested with 4Dos <tm> version 4.01 rev. B. 5.4 Copyright, Trademarks ─────────────────────────────────────────────────────────────────────── MS/DOS is a trademark of Microsoft PC/DOS is a trademark of International Business Machines 4Dos is a trademark of J.P. Software / R.C. Conn and T. Rawson QuickBBS is a trademark of Pegasus Software SuperBBS is a trademark of Risto Virkkala and Aki Antman Maximus is a trademark of Scott J. Dudley OPUS is a trademark of The OPUS group inc. FileDoor is a trademark of Robert W. van Hoeven & DISP MTA is a trademark of Robert W. van Hoeven & DISP FrontDoor is a trademark of Joachim Homrichhausen Remote Access is a trademark of Continental Software RDS is written in Turbo Pascal 6.0, with help of the Turbo Debugger │2.5 and makes extensive use of Object Professional 1.14 and OPCFI V │15.01. Some routines are obtained from TurboPower's Asynch │Professional 1.04. Both STRG and SYS (6.1 and 6.0a, commercial │version) are included. Sources are edited with BRIEF 3.1; Turbo Pascal is a trademark of Borland International Turbo Debugger is a trademark of Borland International Object Professional is a trademark of TurboPower Inc. Asynch Professional is a trademark of TurboPower Inc. OPCFI is a trademark of Robert W. van Hoeven STRG and SYS are trademarks of Eagle Performance Software BRIEF is a trademark SolutionSystem ========================= END OF DOCUMENT =============================