home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.wwiv.com
/
ftp.wwiv.com.zip
/
ftp.wwiv.com
/
pub
/
BBS
/
BFE1302A.ZIP
/
BFE.DOC
< prev
next >
Wrap
Text File
|
1993-06-21
|
71KB
|
1,523 lines
▒███████ ▒███████ ▒███████
▒██ ▒██ ▒██ ▒██ ▒██
▒████████ ▒████████ ▒███████
▒██ ▒██ ▒██ ▒██ ▒██
▒████████ ▒████████ ▒███████
▒███████ ▒███████ ▒███████ ▒████▒██ ▒████████ ▒███████ ▒████▒██ ▒██████
▒██ ▒██ ▒██ ▒██ ▒██ ▒██▒█▒██ ▒██ ▒██ ▒██▒█▒██ ▒██ ▒██
▒██████ ▒███████ ▒██ ▒██ ▒██▒█▒██ ▒██ ▒██████ ▒██▒█▒██ ▒██ ▒██
▒██ ▒██ ▒██ ▒██ ▒██ ▒██▒█▒██ ▒██ ▒██ ▒██▒█▒██ ▒██ ▒██
▒██ ▒██ ▒███ ▒███████ ▒██▒████ ▒██ ▒███████ ▒██▒████ ▒██████
▒███████ ▒██ ▒██ ▒███████ ▒████████ ▒███████ ▒███████
▒██ ▒██ ▒██ ▒██ ▒██ ▒██ ▒██▒█▒██
▒███████ ▒████████ ▒███████ ▒██ ▒██████ ▒██ ▒██
▒██ ▒██ ▒██ ▒██ ▒██ ▒██ ▒██
▒███████ ▒██ ▒███████ ▒██ ▒███████ ▒██ ▒██
┌───────────────────────────────────────┐
▓███│ v1.30.2α Release Date 20 June 1993 │▓███
└───────────────────────────────────────┘
(C)opyright 1992, 1993 Cairo Research Labs, All Rights Reserved
─────────────────────────────────────────────────────────────────────────────
■ INTRODUCTION ■
────────────────────────────────────────────────────────────────────────────
BFE is a BBS front-end system that was originally designed to provide sysops
with a method of running more than one BBS from the same line. In addition,
it has a wealth of other options available to put in on the front-end of your
BBS, such as allowing file transfers, ASCII/ANSI/AVATAR file viewing,
shelling to DOS from remote, running external programs and batch files, and
much more!
BFE was designed to be called from a front-end mailer, such as Frontdoor or
Binkleyterm. Instead of spawning directly to the BBS system, it presents
a menu to the user, which details his immediate options. These options can
range from offering multiple BBS systems, remote jobs, literally anything
you can think of! The BFE system can also be configured to be called
straight from your BBS software itself, in essence, running as a normal
door, using one of several popular BBS dropfile formats. Read onward....
┌───────────────────────────┐
▄│ Word From The Authors │
█└───────────────────────────┘
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
To date, BFE has enjoyed a tremendous success rate, due in part to the
undying loyalty of an exhausted beta team, I might add! Recently, however,
a few shareware authors of similar products have apparently been spreading
false information about the BFE system, making rather unsubstantial claims
as to its functionality. Personally, I feel this is rather uncouth and
is certainly unnecessary, as BFE's power and flexbility speak for itself.
BFE, by far, excels in the areas of flexibility, processing speed, and
ease of use.
Some of you have really put BFE to the test, and I must say that I am glad
to see that it passed with flying colors. Here are just a few comments on
BFE as reported by users and beta testers:
- "During certain hours, my BFE.CTL file gets swapped out with another one,
providing various options based upon the time of the day!"
- "Now we can provide online registration information ... up front!"
- "A tremendous frontend support system for our shareware products!"
- "...provides our users with pertinent file transfers and information,
without forcing them to log on to the BBS first. In and out!"
- "...splendid way of letting my users choose between RIP, NAPLPS, and
normal BBS operation, all before they log on!"
BFE was originally designed in-house, for use on our support BBS, Under the
Nile, at 1:3613/12. However, after getting begged by many of our users to
offer a shareware version, I set out on the task. My mission was to create
a flexible, simple-to-use, inexpensive BBS front-end. See for yourself!
** NOTES and CAVEATS **
In the 1.10 release, we entitled the system, MBBS, or MultiBBS. However,
we later found out that this conflicted with several other packages which
shared the same name. As a result, it was renamed to BFE, the BBS Frontend
System. BFE has evolved into much more than the original MBBS, thus the
original releases of MBBS will no longer be supported.
We hate crippleware! Down with crippleware authors! Shame on them... BFE
has never, is not, and never will be crippleware. Hrmpf!
Starting with the 1.30x series of BFE releases, a new alpha/beta naming
convention has been applied: MAJOR.MINOR.REV (Staging Level).
If you experience any problems with the BFE system, or have any questions,
please contact us! We can be reached in the DOORWARE, MUFFIN, and the
OPENDOORS echos, as well as via netmail to 1:3613/12. We also moderate our
own support echo, entitled SPHINX. The SPHINX echo is not available on the
fidonet backbone. If you are unable to locate a feed near you, feel free
to contact us for more information on connecting directly.
┌─────────────┐
▄│ Features │
█└─────────────┘
▀▀▀▀▀▀▀▀▀▀▀▀▀▀
BFE features include:
* Complete support for ANSI/ASCII/AVATAR users (Auto ANSI detect!)
* *TRUE* Multinode/Multiuser Compatibility!
* DESQview aware!
* Configurable for security concerns!
* Custom multi-level menus with item-level password protection!
* Complete carrier monitoring and timeout checking
* Use any of 11 standard dropfiles, or define custom ones!
* Run as a normal door or as a frontend! Dropfile not required!
* Complete BBS carousel - run multiple BBS systems
* ASCII/ANSI/AVATAR file support
* File transfer system with support for external protocols
* Run remote jobs, such as batch files, programs, other doors, etc.
* Remote OS shells!
* Built in chat mode
* *Total* configurability!
* Much more!
┌────────────────────────────────┐
▄│ What's New in This Release? │
█└────────────────────────────────┘ o New * Change ! Fix
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
o *Major* code cleanup and internal re-documenting and optimizing.
This will be done every periodically in order for the product to
continue to grow.
o New beta naming convention: MAJOR.MINOR.REV (Staging Level)
(i.e. this is 1.30.2α, v1.30, rev. 2, in alpha staging)
o Custom user input using the new PROMPT keyword! Now, you can
utilize custom input as the value for SECONDARY data fields for
*any* menu type in BFE!
o New keywords: NOPASSPARMS and PROCESS. These are used to directly
manipulate the way that BFE performs calls to external processes.
When used with the PROMPT keyword above, just about anything can
be called, in any order, with any arguments!
o The COLOVERRIDE option has been added, to allow each individual
menu option to use its own unique color. This overrides the global
DESCRIPCOL keyword in each .CTL file. (Thanks to Chris Koziol)
o Upload capability now in place! This involved changes to the
PROTOCOL.BFE file, and adding a new type "U" option.
* If BFE cannot locate ASCII/ANSI/AVATAR screens at display time,
it will log an error entry into the logfile, and will no longer
wait for a remote keystroke to continue. (Thanks to R. Guevarra)
┌────────────────────────────────┐
▄│ Licensing and Distribution │
█└────────────────────────────────┘
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
This documentation, programs, and other files distributed in this software
package (the "Software") are the copyrighted property of Scott Burkett and
Cairo Research Labs. All rights are reserved.
For use by corporations, institutions or goverment agencies, or for-profit
purposes, contact the Author for licensing information.
U.S. GOVERNMENT INFORMATION
The use, duplication, or disclosure by the U.S. Government of the Software
is subject to the restricted rights applicable to commercial software that
are specified in the subdivision (b.3.ii) of the 'Rights in Technical Data
and Computer Software' clause, document DFARS 52.227-7013.
DISTRIBUTION/USAGE
BFE can be freely distributed, provided that the original archive
is not changed in any way (other than changing the archive type) and no
amount of money is required. In no circumstance at all can BFE be
modified without written consent from the authors. It is prohibited too
to include this program, whole or in part, in other software. It is
expressly forbidden to distribute a registered key to unregistered users.
BFE can be used in commercial organizations only after regular
registration.
This license is considered accepted if the program is used. Its violation
will involve the withdrawal of the registration key and the rights to use
the program.
WARRANTY DISCLAIMER
The Author cannot and does not warrant that any functions contained in the
Software will meet your requirements, or that its operations will be error
free. The entire risk as to the Software performance or quality, or both,
is solely with the user and not the Author. You assume responsibility for
the selection of the program to achieve your intended results, and for the
installation, use, and results obtained from the Software.
The Author makes no warranty, either implied or expressed, including with-
out limitation any warranty with respect to this Software documented here,
its quality, performance, or fitness for a particular purpose. In no event
shall the Author be liable to you for damages, whether direct or indirect,
incidental, special, or consequential arising out the use of or any defect
in the Software, even if the Author has been advised of the possibility of
such damages, or for any claim by any other party.
All other warranties of any kind, either express or implied, including but
not limited to the implied warranties of merchantability and fitness for a
particular purpose, are expressly excluded.
LIMITATION OF REMEDIES
The information contained in the documentation for the Software is subject
to change without notice.
The Author's entire liability, and your exclusive remedy shall be: (1) the
replacement of an original Software diskette not meeting the above Limited
Warranty and which is returned to the Author along with proof of purchase,
or (2), if the Author is unable to deliver a replacement diskette which is
free of defects, you may terminate the License Agreement by returning this
Software and the corresponding license fee will be returned.
By using the Software, you acknowledge (1) to have read and understood all
parts of this document and (2) to have agreed with and accepted all of its
provisions without any reservation.
Scott Burkett
Cairo Research Labs
┌─────────────────────────────┐
▄│ The Demo Version of BFE │
█└─────────────────────────────┘
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
This shareware demonstration version of BFE is as fully functional as its
registered counterpart, with a few minor differences.
- The unregistered evaluation message at the top of the screen: Upon
registration, this will be replaced by your name or your organization's
name, showing your support for the BFE project.
- Registered users have the option of changing both the text and the color
of the default registration message which appears at the top of each menu.
- Registered users can make use of custom ASCII/ANSI/AVATAR screens in lieu
of the built-in default BFE menus.
┌──────────────────────────────┐
▄│ Benefits of Registration │
█└──────────────────────────────┘
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Benefits of registering BFE:
o Extended Tech Support via the SPHINX echo (our support echo).
o Access to beta copies of BFE, as they become available.
o You will also be entitled to free upgrades to newer versions of
BFE, as they become available. In addition to the great
many features and the quality that this version of BFE has
to offer, we are currently working on several additions and
enhancements for future versions.
┌─────────────────────┐
▄│ Ordering BFE │
█└─────────────────────┘
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Below are detailed instructions for registering BFE. These
instructions are not intended to seem confusing or complicated; they are
simply meant to answer almost any question that you might have about
registering. If you have any questions or uncertainties about your
registration, please feel free to contact us. For information on how to
contact us, please see the section on "Upgrades and Information".
To order BFE, simply follow these three steps:
1.) Fill out the registration form. Information on filling out
the form is located in the next section.
2.) Enclose the appropriate payment ($10), Ten American Dollars,
payable in the form of cash, check or money order. Make all checks
or money orders payable to: SCOTT BURKETT
3.) Send the above two items to:
Cairo Research Labs
1113 29th Street
Columbus, GA 31904
FILLING OUT THE REGISTRATION FORM
--------------------------------------------------------------------------------
NO PRINTER? Alternatively, if you do not have a printer, simply send a
hand-drawn version of the order form. If you do not wish to
mail a registration form in, you may opt to upload it to our
support BBS at (706) 596-8126 (14.4/v.32). We will not present
you with a registration key, however, until proper payment
has been rendered.
If you have any special instructions for us, or anything that
you would like to say when you register, feel free to write
this down on the back of the registration form, or on a
separate piece of paper.
When filling out the BFE registration form, be sure to
indicate how you would prefer to receive your BFE
registration key. You will have the choice of receiving your
registration key by one of three means: A call to our BBS,
FidoNet CrashMail, or by a call to your BBS. If you have a
FidoNet Email address, FidoNet CrashMail is still by far the
quickest way to receive your order. Once you have decided
which means you would prefer to receive your order by, please
read the detailed instructions on your order method below.
--------------------------------------------------------------------------------
RECEIVING In order to receive your BFE registration key by a
BY CALL message and/or upload to your BBS, fill out the order form and
TO BBS mail it along with your payment as described below. Be sure to
include the phone number, baud rate, and our login and
password for the BBS to which you would like us to call. We
will cover any long distance costs. If, for some reason, we
are unable to connect to your BBS (not because it busy, but,
for example, if your BBS is no longer online), we will place
your key in a message on our support BBS.
--------------------------------------------------------------------------------
RECEIVING In order to receive your BFE registration key via
ORDER BY FidoNet CrashMail, simply fill out the order form and mail it
FIDONET along with your payment as described below. Be sure to
CRASHMAIL include the FidoNet node address to which you wish to have
your order sent.
────────────────────────────────────────────────────────────────────────────
■ GETTING STARTED ■
────────────────────────────────────────────────────────────────────────────
BFE is a snap to get up and running (as you will see).
┌────────────────────────┐
▄│ System Requirements │
█└────────────────────────┘
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
BFE was designed for use with IBM compatible personal computer systems,
with 640K minimum RAM, however, it will run in much less. It will run under
most popular BBS packages, to include RemoteAccess, Maximus, SuperBBS,
QuickBBS, GAP, PCBoard, WildCat!, WWIV, and others. Facilities are also in
place to provide complete dropfile customization, which provides maximum
compatibility with nearly all BBS system software.
BFE also requires the use of a fossil driver, such as Ray Gwinn's X00, or
David Nugent's BNU. These programs can be found on most BBS systems, since
they are necessary in running most BBS packages to begin with. If your BBS
does not utilize a fossil driver, you can always enable it for BFE, and then
disable it after BFE exits.
If you would like to allow users to download certain files from BFE, free of
BBS ratios, then you will also need copies of whatever external protocols you
wish to run (i.e. DSZ, MPT, etc).
┌─────────────────┐
▄│ Installation │
█└─────────────────┘
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
First things first:
Create a directory to hold the BFE system. We recommend using something
like C:\BFE. Next, copy the BFE122.EXE file into the directory
and type "BFE122" at the DOS prompt. The archive is self-extracting and will
come apart without much effort.
** Note: Your source for obtaining the BFE archive may have changed
the format of the archive to one suitable for use on their system (i.e. ZIP,
LZH, ARJ, etc).
────────────────────────────────────────────────────────────────────────────
■ OPERATION ■
────────────────────────────────────────────────────────────────────────────
Operating BFE is a cinch, as you will soon find out. As mentioned earlier,
it was designed to be called from a front-end mailer. Most, if not all,
mailers will pass the necessary arguments along to your batch file (i.e.
port, baud, time to next event, etc). You will be passing these parameters
to BFE in turn, in order to establish the communication link. See below for
more info on the command line arguments for BFE.
BFE also has the ability to be run as a normal BBS door, obtaining the
necessary communication parameters from one of several popular BBS dropfile
formats. More on this later.
This is the first decision you have to make! Will you be running BFE as a
communications front-end, or as a normal door, or both? Read on...
In order to let BFE know what options to present to the user, a control
file must be created. It may whatever name you wish, but for documentation
sake, we will use BFE.CTL.
** NOTE: as you read through the examples, you may think that configuring
BFE can be a bit tedious. We admit that BFE can be a bit of a
nuisance while you are just learning it, but before you know it,
you will be as proficient as the next Joe. We are planning on
creating a BFE menu designer, to help out in this task, though...
Each option in the control file is addressed via a "keyword".
---------------------------------------------------------------------------
Keyword: CHOICE
---------------------------------------------------------------------------
The CHOICE keyword is used to define each of your BFE menu options. These
are the options that will be presented to your callers. Actually, the CHOICE
keyword marks the beginning of an "option block".
The format of each option block is:
CHOICE
HOTKEY [Hotkey]
DESC [Textual Description]
TYPE [Option Type]
FLAVOR [Option Flavor]
SECURITY [Security to Access]
SECONDARY [Catch-all Secondary data field]
PROMPT [Used to obtain user-defined input]
PROCESS [Used in conjunction with PROMPT/NOPASSPARMS]
NOPASSPARMS [Prevent BFE from passing comm. parameters to tasks]
PORTSPEED [TRUE or LOCKED]
SHOWAFTER [After-selection ANSI/ASCII/AVATAR screen]
PASSWORD [Password Needed to Access]
ENDCHOICE
We will discuss each of the above subitems in turn. Note the use of the
ENDCHOICE keyword to mark the end of the option definition.
The option block format is very loosely interpreted. Spacing is not a
concern, nor is the case off the keywords. They may also be in any order
within the block.
As you go through the following descriptions and examples, keep in mind that
BFE performs very little error checking when parsing the CHOICE keywords. As
long as you keep everything in the format presented, you shouldn't run into
too many problems. This will/should be remedied in the future.
Let's take a look at each of the CHOICE parameters:
---------------------------------------------------------------------------
[HOTKEY]
The "hotkey" field represents the keypress needed to activate the option.
You may use any character for this, however, if you chose an alpha character
(A through Z), it will use the uppercase form of the character. In other
words, if you put a lowercase letter in as a hotkey, BFE will convert it
to uppercase when initialized.
Examples: HOTKEY 1
CHOICE G
---------------------------------------------------------------------------
[DESC]
Simple enough. The description field should contain the text that will
be presented next to each option. You are limited to 80 characters for
each option description.
Examples: DESC Under the Nile BBS!
DESC Download Master File Listing
---------------------------------------------------------------------------
[Type]
The TYPE field is perhaps the most important of the CHOICE parameters, as it
directly affects the remainder of the parameters. The value in this field
determines what BFE will do once the user presses the hotkey for the option.
Some fields require additional information, such as the path and filename of
a file to be downloaded. This type of information is provided through the
use of the SECONDARY FIELD. The SECONDARY FIELD's purpose changes based
upon the value of this TYPE field.
Currently, the valid types are (Examples afterwards):
E - Exit on an errorlevel
Specifying an "E" as the type will cause BFE to exit back to the calling
batch file with an errorlevel. This is perhaps one of the more powerful
types, as it provides vitually unlimited possibilities. Simply place the
errorlevel you wish to exit with in the SECONDARY FIELD. As an example, you
could call one BBS with an errorlevel of 100, and another one with an error-
level of 101, etc. Basically, as long as you trap the errorlevel in your
calling batch file, you could do practically anything!
R - Run external process
Specifying an "R" as the type will cause BFE to execute (run) an external
process. This is also an incredibly powerful option, in very much the same
way as the "E" type. The benefit of using "R" over "E" is simple: You
don't have to fiddle with the calling batch file and trapping the errorlevels.
In addition, BFE will pass several values on the command line, in the follow-
ing order:
%1 - Port number (1-4)
%2 - Baud rate (dependant upon PORTSPEED setting)
%3 - Time to next event
This feature is unavailable in an "E" type. BFE will attempt to swap itself
out to memory or disk first, to ensure that you have as much memory as
possible to call your task. If you wish to run a program that requires
command line parameters or switches, you will need to place the call to the
program in a batch file, and have BFE call the batch file. Simply place the
name of the external process in the SECONDARY FIELD. You may specify the
full path, or just the filename if it resides in your path or the BFE
directory.
** NOTES: I cannot stop expressing the sheer power of this type! You can
use this to call bulletin doors, message entry doors, Doorway, etc. BFE works
especially well with RegPRO, our full screen online entry form system! :-)
It is possible to call a program such as Marshall Dudley's Doorway(tm). In
fact, this has been tested and confirmed by several BFE beta sites. Since
BFE passes the port and baud rate to any external processes, it is a cinch.
O - Operating System Shell
For those of you wish to drop to DOS from remote, this is the one! Simply
place an O as the type. BFE will make use of the COMSPEC enviroment variable
to locate your command processor (COMMAND.COM, 4DOS.COM, etc). To return
to BFE, simply type exit at your command prompt.
One note is in order here. You may run any program you desire from remote,
once you are in the OS shell. However, keep in mind that unless the program
supports DOS routing, then you will not see any output on your screen. Most
command line utilities will work just fine, as well as the internal DOS
commands, however, things like Windows, PC-Tools, etc will not function
properly, and will more than likely lock your system. If you enable your
fossil watchdog, you should be fine in the event you get hung up. Check your
fossil documentation for more information on the watchdog services.
With the inherent power that arrives by shelling to your OS from remote, you
should always password protect this option! Then again, I guess it *is* your
system... :-)
G - Goodbye
This type is fairly straightforward! It hangs up on the user, and returns
an errorlevel of 255 to the calling batch file.
C - Chat Page!
This type is fairly straightforward as well. It will prompt the user for a
reason to chat, and proceed to page the sysop. To break in, simply press
ALT-C. To exit chat mode, simply press ESC. Note that you may also press
ALT-C at any time to initiate a chat session while the user is in BFE.
D - Display ASCII/ANSI/AVATAR screen
This nifty type will allow you to display an ANSI, ASCII, or AVATAR file to
the user. To use this option, simply place the filename of the file to be
displayed in the SECONDARY FIELD. If you do not specify an extension, then
BFE will look for the filename which corresponds to the user's graphic
settings. When BFE first comes up, it performs an Automatic ANSI detection
loop. It makes an attempt to determine whether or not the user is calling
from an ANSI-ready terminal. If so, then BFE will display FILENAME.ANS or
filename.AVT (ANSI or AVATAR, depending on his settings). If not then
FILENAME.ASC will be used. You may also specify the extension, if you only
want one file to be used, such as RELEASES.TXT. You may specify a full path,
or just the filename if the file is in the BFE directory.
BFE will automatically engage "more prompting" when displaying screens that
are over 1 screen in length.
** NOTE: BFE "interprets" the file as it is being displayed to the COM port.
It is capable of interpretting embedded system codes used by RemoteAccess.
For more information on these codes, please refer to your RA documentation.
J - Jump to another menu!
Through the use of the "J" type, you can have BFE call a completely different
.CTL file! This is handy when you need to group several options together:
For example:
Top Menu (BFE.CTL)
- -
- -
Sysop Menu (SYS.CTL)<--- ----> Product Info (PROD.CTL)
Menus can now be nested up to 10 levels! If you try to go beyond this, BFE
will simply post a warning message and re-display the current active menu.
X - Return to previous .CTL file
Use this option to provide a method of returning from a subordinate .CTL
file menu back to the .CTL file menu that called it.
T - Return to main .CTL file
Use this option to provide a method of returning from a subordinate .CTL
file menu back to the main .CTL file. If you are in nested menus, then this
option will take you all the way back to the first one. Think of this type
as being the one that takes you back to the "T"op menu.
F - Download one file
This type will allow the user to download a file (ratio free) from BFE,
without having to log onto your BBS first. This is particularly handy, esp.
if you are a shareware author, as you can offer the latest version of your
packages up front. Trust me when I say that your long distance users will
love you for this! Simply place the filename to be downloaded in the
SECONDARY FIELD. You may specify a full path, or just the filename if the
file is in the BFE directory.
When the user selects this option, BFE will present a list of available
protocols (configured in a file called PROTOCOL.BFE, more on this later).
M - Menu of downloadable files
This type is very similar to the "F" type, with one exception. Instead of
downloading a specific file, the user will be presented with a list of the
available files, from which he/she may choose the file to be downloaded.
In order to use this type, a "files list" must be created, and the filename
of the list (or full path to the list) must be placed in the SECONDARY FIELD.
This list should be in the following format:
---------------------------[ CUT HERE! ]-----------------------------------
Cairo Research Labs Free File List
D:\CAIRO\AVLAB100.ZIP AVLAb v1.0 - Antiviral Researcher's Toolkit!
D:\CAIRO\RCS10A.LZH Robot Construction Set v1.0a - For Fidonet Areas
D:\CAIRO\RP_260.LZH RegPRO v2.60 - World's Premier Questionnaire Door!
D:\CAIRO\TBM_250.LZH Turbo Bulletin Manager Door v2.50
D:\CAIRO\TBWIN111.LZH TBWin v1.11 - Windows Interface for TBAV utils
D:\CAIRO\TFA100B.LZH Turbo File Announcer 1.0ß - Max File Announcer System
D:\CAIRO\VK_300A.LZH VKill v3.00A - Upload Integrity Tester for Maximus CBCS
D:\CAIRO\VID110.ZIP VID v1.10 - Virus Information Door - For most BBS's
D:\CAIRO\VDB0393.LZH Updated VID Virus Database - as of March 1993
D:\CAIRO\WINVID10.LZH WinVID v1.0 - Windows Virus Database!
D:\BETA\RP_300B.LZH Beta version of the upcoming RegPRO 3.0 release!
---------------------------[ CUT HERE! ]-----------------------------------
As you can see, this is a modified version of the standard FILES.BBS, with
the only difference being that the full path to each file needs to be present.
This provides a nifty way of pulling files from all over your system to a
single file download menu. In this way, you need not use any of the FILES.BBS
files that your BBS uses, you can create a custom one and place it in another
directory, such as the BFE directory.
Any line which does not start in column 1 is considered a comment, and will
be displayed in a different color. Note that all of the colors used in the
FILES.BBS display are configurable as of v1.22! More on this in the section
covering the "global configuration file".
All that is needed in the secondary field is the PATH to the FILES.BBS, not
the entire path/filename. The name FILES.BBS is assumed.
Once again, the user will be presented with a list of available protocols
which are defined in a file called PROTOCOL.BFE (more later).
Examples: TYPE G
TYPE M
.
etc
---------------------------------------------------------------------------
FLAVOR
---------------------------------------------------------------------------
The FLAVOR keyword is used to control whether or not BFE displays the
option on the screen AT ALL. By default, all menu options are displayed.
However, if the FLAVOR is set to HIDDEN, then the option will not be shown,
but will still be available as a valid option.
Examples: FLAVOR HIDDEN
FLAVOR NORMAL
---------------------------------------------------------------------------
SECURITY
---------------------------------------------------------------------------
The SECURITY keyword is used in conjunction with a BBS dropfile to further
restrict certain options from your users. If you are running BFE without
the DROPFILE keyword, this keyword will not function, since BFE will have no
way of knowing what the security level of the user is. Simply place the
numeric value of the user after the keyword. Any option that a user does not
have the appropriate security for, will simply not be displayed to him.
Unlike HIDDEN selections, any options which are not valid due to a low
security level can *never* be selected.
Examples: SECURITY 50
SECURITY 32000
---------------------------------------------------------------------------
SECONDARY/PROMPT/PROCESS/NOPASSPARMS
---------------------------------------------------------------------------
As mentioned earlier, the SECONDARY field is used as a catch-all data field.
The value of this field (or even if it is used at all) is determined by the
option TYPE (see above). It may contain anything from an errorlevel value,
a filename, etc.
Examples: SECONDARY C:\FILES\MASTER.ZIP
SECONDARY 75
The PROMPT option has been added to provide a method of obtaining data from
the user, and passing this along to the menu type as the SECONDARY field.
For instance, let's say you wanted to set up a menu option to allow you to
enter batch/DOS commands from remote (without performing a remote shell).
CHOICE
.
TYPE R
SECURITY 100
PROMPT Enter your commands:
.
ENDCHOICE
That's it! When the user selects this menu option, he will be prompted
to "Enter your commands:". Whatever is typed in by the user (1 line only)
will be passed to the operating system for execution. BFE will pass the
default communication parameters (port, speed, time-to-next-event) to the
task as command line arguments.
The PROCESS keyword was added for once specific reason. To allow you to pass
data which was gathered by the PROMPT keyword, to an external process.
Another example. Let's say you wanted to have the user enter parameters for
an external process called TEST.BAT.
CHOICE
.
TYPE R
NOPASSPARMS
PROMPT Enter the parameters:
PROCESS TEST.BAT
.
ENDCHOICE
When the user selects this menu option, he will be prompted to "Enter the
parameters:". Whatever is typed in by the user (once again, 1 line only)
is passed to TEST.BAT for execution.
The NOPASSPARMS keyword which was used in the above example, is in place to
prevent BFE from passing the default communication parameters to the process.
In our example above, we want to pass data which was entered by the user!
---------------------------------------------------------------------------
PORTSPEED
---------------------------------------------------------------------------
The PORTSPEED option was provided to allow Sysops who lock their serial
ports to pass either the TRUE port speed (i.e. 9600), or the LOCKED speed
(i.e 38400). This comes in handy when combined with download types or when
calling another BBS door from a BFE menu option.
Examples: PORTSPEED True
PORTSPEED Locked
* NOTE: Be sure to check the additional serial port locking options that
appear in the global configuration file! These must be set as well!
---------------------------------------------------------------------------
SHOWAFTER
---------------------------------------------------------------------------
The SHOWAFTER option provides yet another hook to display ASCII/ANSI/AVATAR
screens. This method, however, displays the screen *after* the user makes
the selection, and after any password/security checking. Once the screen
has been displayed, BFE will automatically wait for the user to hit any
key to continue. BFE will also clear the display before displaying the
screen.
The same screen display rules that apply to the "D" type apply here as well.
Examples: SHOWAFTER Welcome
SHOWAFTER Update.txt
---------------------------------------------------------------------------
COLOVERRIDE
---------------------------------------------------------------------------
The COLOVERRIDE option is used in conjunction with the default internal BFE
menu system. It provides a method of assigning each menu option descripion
with a different color scheme. If this keyword is ommited from your CHOICE
blocks, then the global DESCRIPCOL color will be used.
Note that if you are using custom USERMENU menus, this option will have no
effect!
Examples: COLOVERRIDE Bright White on Black
COLOVERRIDE Bright Flashing White on Black
COLOVERRIDE Bright Yellow on Blue
---------------------------------------------------------------------------
PASSWORD
---------------------------------------------------------------------------
PASSWORDS! Yes, you can password *ANY* option on an BFE menu by simply
placing a value in the PASSWORD field of the choice in question. This
password must be under 25 characters long, and is case INSENSITIVE. The user
gets three attempts at the password, and if unsuccessful, BFE will proceed
to drop carrier, and exit with an errorlevel of 99.
Examples: PASSWORD Dumbmove
PASSWORD GUEST
---------------------------------------------------------------------------
ENDCHOICE
---------------------------------------------------------------------------
This keyword merely marks the end of an option block definition.
---------------------------------------------------------------------------
Keyword: USERMENU
---------------------------------------------------------------------------
By default, BFE creates the user menus based upon the options that you have
configured in all of your CHOICE keyword blocks. If you specify the USERMENU
keyword, followed by a filename, then the contents of the filename will be
used as the menu screen. The same rules which apply to the "D" type (above)
apply to the USERMENU keyword. (i.e. ANSI/ASCII/AVATAR, etc). This option
is available to registered users only.
Examples: USERMENU Mainscr
USERMENU Moreinfo
---------------------------------------------------------------------------
TITLECOL \
LINECOL \
BRACKETCOL \
HOTKEYCOL \ Custom color keywords
DESCRIPCOL /
PROMPTCOL /
USERCOL /
---------------------------------------------------------------------------
Each of your BFE .CTL files may use a custom set of colors! By setting the
following keywords in each .CTL file, you can create custom colors:
TITLECOL - Color of the BFE Title Line
LINECOL - Color of the divider lines
BRACKETCOL - Color of the brackets on either side of the hotkeys
HOTKEYCOL - Color of the hotkeys for this screen
DESCRIPCOL - Color of the description text for each choice
PROMPTCOL - Color of the BFE system prompts
USERCOL - Color of all user-inputted text
REGCOL - Color of the Registration Message (*Registered users only)
Use the following formula for color selection:
{Flashing} {Bright} [foreground] on [background]
Where "Flashing" is an optional keyword indicating that the text should be
flashing. "Bright" is an optional keyword indicating that the foreground
color should be bright. Foreground is the name of a foreground color, and
background is the name of a background color. Case (upper or lower) is not
significant.
Where foreground and background colors are one of:
Black
Blue
Green
Cyan
Red
Magenta
Yellow / Brown
White / Grey
If no colors are specified, BFE will use the default internal color set.
Examples: TITLECOL Bright Yellow on Black
HOTKEYCOL Flashing Bright White on Blue
By using different background colors and flashing attributes, incredible
results can be achieved.
** NOTE: This particular method of color scheming was borrowed from the
global configuration file, in order to make things more consistent
across the board.
---------------------------------------------------------------------------
REGMESSAGE
---------------------------------------------------------------------------
Finally, the REGMESSAGE keyword can be used by registered users to change
the default registration message! If unregistered, BFE will display the
"* Unregistered Evaluation Copy *" message. If registered, the default is
"Registered to: <Your Name>". By changing this message, you can essentially
provide the equivalent of menu titles for each of your menus. Each menu
(.CTL file) can have a different message!
(Examples: REGMESSAGE Welcome to the Sysop Menu!
or
REGMESSAGE Cairo Research Labs Product Info Menu!
---------------------------------------------------------------------------
┌────────────────────────────┐
▄│ Global Configuration File │
█└────────────────────────────┘
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
BFE also makes use of a "global configuration file". Much of BFE's internal
customization can be controlled through the modification of this file. The
name of this file should be passed on the command line to BFE (more on the
command line later!). If the name of the global configuration file is not
passed on the BFE command line, it will not be utilized.
The following is a detailed listing of each of the options available:
;-----------------------------------------------------------------------------
; BFE.GBL - Sample BFE Global Configuration File
; (C)opyright 1992, 1993 Cairo Research Labs, All Rights Reserved
;-----------------------------------------------------------------------------
; Any text following a semi-colon (;), and blank lines, are ignored.
;-----------------------------------------------------------------------------
;
; The WelcomeScreen keyword is used to display a file (ASCII/ANSI/AVATAR)
; upon entry to the BFE system.
;
; i.e. WelcomeScreen WELCOME <--(Tries .AVT, .ANS, then .ASC)
; WelcomeScreen WELCOME.ASC
;
WelcomeScreen WELCOME
;
;-----------------------------------------------------------------------------
;
; The Dropfile option is used to determine which "mode" BFE will run in, a
; normal door, or as a BBS front end system. See the section on Dropfiles
; in the BFE.DOC file for more information.
;
Dropfile Yes
;
;-----------------------------------------------------------------------------
;
; BBS system directory. Indicates where the door information file (dropfile)
; can be found. Remove the semi-colon (;) to activate this option. Note that
; this option is not necessary if you are using BFE as a BBS front end
; instead of a door! If the dropfile is in the current dir, this is also
; not necessary.
;
BBSDir C:\FD\BFE
;
;------------------------------------------------------------------------------
;
; The BFE working directory. This is where the BFE system files are
; located. Remove the semi-colon (;) to activate this option.
;
DoorDir C:\FD\BFE
;
;------------------------------------------------------------------------------
;
; Log File options. "LogFileName" specifies filename (path optional) where
; BFE should record log information. To disable the log file altogether,
; remove the semi-colon (;) from the "DisableLogging" line. The default
; logname if both options are commented out is BFE.LOG in the current dir.
;
LogFileName BFE.LOG
;DisableLogging
;
;------------------------------------------------------------------------------
;
; BBS node number that door is running on. Only used if VID is unable to
; determine the node number by some other means (i.e. dropfile)
;
Node 1
;
;------------------------------------------------------------------------------
;
; Door Personality. Currently BFE supports 3 types of "personalities" or
; flavors: Remoteaccess 2.0x, WildCat!, and the default). The active
; personality determines the style of status line BFE will utilize, and
; the various hotkeys which are active during door operation.
;
;Personality Wildcat
;Personality Remoteaccess
;Personality Default
;
;------------------------------------------------------------------------------
;
; Sysop paging hours. Sysop paging will be permitted beginning at the start
; time, up until, but not including, the end time. Times should be in 24-hour
; format. To disable paging on a particular day, set the paging start and end
; times to the same time. Uncomment them all for 24 hour paging service.
;
; Start Time End Time
SundayPagingHours 9:00 22:00
MondayPagingHours 8:30 22:00
TuesdayPagingHours 8:30 22:00
WednesdayPagingHours 8:30 22:00
ThursdayPagingHours 8:30 22:00
FridayPagingHours 8:30 22:00
SaturdayPagingHours 9:00 22:00
;
;------------------------------------------------------------------------------
;
; Duration of sysop page. Value indicates the number of beeps that compose
; the sysop page alarm.
;
PageDuration 10
;
;------------------------------------------------------------------------------
;
; The Timelimit option is used to determine how much time each user will have
; in the BFE system. Note that this option is only active if you are *NOT*
; using a dropfile! In that case, the user's realistic remaining time value
; will be utilized.
;
TimeLimit 60
;
;-----------------------------------------------------------------------------
;
; If you want the user's time to "freeze" while either running an external
; process, remote shell, or file transfer, then take a second to uncomment
; this keyword. If this keyword is not specified, BFE will recalculate the
; user's time upon returning from the file transfer, shell, etc.
;
Freezetime
;
;------------------------------------------------------------------------------
;
; Inactivity timeout. Specifies the maximum number of seconds that may elapse
; without the user pressing any key, before the user will be automatically
; disconnected. A value of 0 disables inactivity timeouts.
;
InactivityTimeout 200
;
;------------------------------------------------------------------------------
;
; Name of the sysop. BFE can usually determine the sysop's name from the
; information passed to the door by the BBS (i.e. in the dropfile). However,
; some BBS software does not supply this information to doors. In such cases,
; simply place your name here.
;
;SysopName The Sysop
;
;------------------------------------------------------------------------------
;
; Name of the BBS. BFE can usually determine the name of the BBS from the
; information passed to the door by the BBS. However, some BBS software
; does not supply this information to door programs. In such cases, simply
; place the name of the BBS here. Note that this is normally not needed,
; and may be commented out.
;
;SystemName Unnamed BBS
;
;------------------------------------------------------------------------------
;
; Door colour options. These options specify the various text colours that
; will be used by the door if ANSI or AVATAR graphics modes are available.
; Colours are specified in the format:
;
; {Bright} {Flashing} [Foreground Colour] on [Background Colour]
;
; Where foreground and background colours are one of:
;
; Black
; Blue
; Green
; Cyan
; Red
; Magenta
; Yellow / Brown
; White / Grey
;
ChatUserColour Bright white on black
ChatSysopColour Bright red on black
FileListTitleColour Bright yellow on black
FileListNameColour Bright yellow on black
FileListSizeColour Bright magenta on black
FileListDescriptionColour Cyan on black
FileListOfflineColour Bright red on black
;
;------------------------------------------------------------------------------
;
; Memory swapping options. These options are generally not needed, but can be
; used to customize BFE's swapping behaviour. "SwappingDir" can be used
; to specify which directory or directories should be used for swapping.
; Multiple directory paths can be separated using a semi-colon.
; "SwappingNoEMS" can be used to prevent any swapping from being done to EMS
; memory, and "SwappingDisable" can be used to disable memory swapping
; altogether. Remove the semi-colon (;) to activate any of these options.
;
;SwappingDir C:\
;SwappingNoEMS
;SwappingDisable
;
;------------------------------------------------------------------------------
;
; Modem options. These options are generally not needed, as they can usually
; be determined from the BBS door information file. "LockedBPS" specifies the
; the BPS rate at which the door should communicate with the modem. Valid
; rates are 300, 600, 1200, 2400, 4800, 9600, 19200 and 38400. A BPS rate of 0
; forces the door to always operate in local mode. "FossilPort" specifies the
; FOSSIL driver port number that the modem is connected to. Usually, FOSSIL
; port 0 corresponds to COM1, FOSSIL port 1 to COM2, and so on. Remove the
; semi-colon (;) to activate either of these options.
;
;LockedBPS 38400
;FossilPort 0
;
;------------------------------------------------------------------------------
;
; Custom door information file support. BFE automatically recognizes
; most door information file (drop file) formats, including DORINFO?.DEF,
; EXITINFO.BBS, DOOR.SYS, SFDOORS.DAT, CALLINFO.BBS and CHAIN.TXT. However,
; to permit BFE to operate on BBS systems that produce a different format
; file, you may define a custom door information file format. A custom door
; information file format is defined using the "CustomFileName" command,
; followed by one or more lines beginning with the "CustomFileLine" command.
;
; The "CustomFileName" option specifies the filename used to distinguish this
; file format from other file formats. This filename should not include a
; path. To specify the path where the door information file is located, use
; the BBSDir setting, near the beginning of this file. If the filename of the
; custom format is the same as that of one of the built-in formats, the custom
; format will override the built-in format.
;
; The actual format of the custom file is specified using a number of lines
; that begin with the keyword "CustomFileLine". Each of these lines will
; correspond to a single line in the door information file, with the option
; following the "CustomFileLine" keyword specifying the information that can
; be found on that line. This can be one of the following keywords:
;
; Ignore - Causes the next line in the door information
; file to be ignored. Use on lines for which none
; of the options below apply.
; ComPort - COM? port the modem is connected to
; (0 indicates local mode)
; FossilPort - Fossil port number the modem is connected to
; ModemBPS - BPS rate at which to communicate with modem
; (0 or non-numerical value indicates local mode)
; LocalMode - 1, T or Y if door is operating in local mode
; UserName - Full name of the user
; UserFirstName - First name(s) of the user
; UserLastName - Last name of the user
; Alias - The user's psuedonym / handle
; HoursLeft - Hours user has left online
; MinutesLeft - Minutes user has left online, or time left online
; in format hh:mm
; SecondsLeft - Seconds user has left online, or time left online
; in format hh:mm:ss or format mm:ss
; (If more than one of the above time options are
; used, the user time left is taken to be the total
; of all of these values.)
; ANSI - 1, T, Y or G for ANSI graphics mode
; AVATAR - 1, T or Y for AVATAR graphics mode
; PagePausing - 1, T or Y if user wishes a pause at end of screen
; ScreenLength - Number of lines on user's screen
; ScreenClearing - 1, T or Y if screen clearing mode is on
; Security - The user's security level / access level
; City - City the user is calling from
; Node - Node number user is connected to
; SysopName - Full name of the sysop
; SysopFirstName - The sysop's first name(s)
; SysopLastName - The sysop's last name
; SystemName - Name of the BBS
;
;
CustomFileName EXAMPLE.DEF ; Same format as DORINFO?.DEF
CustomFileLine SystemName
CustomFileLine SysopFirstName
CustomFileLine SysopLastName
CustomFileLine ComPort
CustomFileLine ModemBPS
CustomFileLine Ignore
CustomFileLine UserFirstName
CustomFileLine UserLastName
CustomFileLine City
CustomFileLine ANSI
CustomFileLine Security
CustomFileLine MinutesLeft
;-----------------------[ End of Sample .BFE.GBL File ]------------------------
** Notes on the BFE logfile: **
BFE has the ability to maintain a rather detailed logfile of all activity
in the door. Unfortunately, since the user has not signed on the BBS at this
point, we have no idea what his/her identity is. However, special attention
has been paid to ensure that any other pertinent information is included in
the logfile. The logfile format is similar to the log file format used by
Joho's FrontDoor(tm) Netmailer System.
** Notes on BBS Dropfiles **
If BFE locates an enabled Dropfile keyword in your global config file, it
will attempt to make use of a BBS dropfile, effectively ignoring any relevant
command line communication arguments. If you wish to run BFE as a normal door
from your BBS, you will need to specify a "Yes" value for this keyword. If
you are running BFE as a front-end to your system (i.e. called from a mailer),
"No" will need to be provided.
It appears that the BBS world simply cannot agree on a standard dropfile
format. For a while, it appeared as if the DORINFOx.DEF, or perhaps the
DOOR.SYS format would prevail. However, with the release of RemoteAccess
v2.0+, that myth has apparently been shattered, as the RA author decided to
introduce yet another dropfile format. We will continue to add and support
all of the popular dropfile formats, regardless of how hairy it gets... :-)
BFE by default does not look for a BBS dropfile, since it was originally
designed to be run as a frontend (i.e. *BEFORE* the user had actually logged
on to the BBS).
As of v1.22 of BFE, a "smart" method of dropfile detection has been employed.
BFE first looks in the current directory for the dropfile. If it is not
there, it looks in the DOS path. If the dropfile mode is enabled, and BFE
can not locate a dropfile, it will not run!
1.) First, if there was a custom door information file format
defined in the BFE global configuration file, BFE will begin
by looking for this file. BFE searches for the custom
information file in the following order:
A.) The path defined by the BBSDir keyword
B.) The directory which was the current default dir
at startup time
C.) If any of the following environment variables
exist, BFE will then search for the file
in the directories pointed to by these variables,
in the following order:
RA
QUICK
PCB
BBS
2.) If no custom door information file was found / defined,
BFE will then search for door information files
corresponding to one of the built in formats. It will search
for these files in the same directories, and same order, as
it does for the custom door information file (A - C). Within
each directory, it will search for files with the following
filenames:
CHAIN.TXT
SFDOORS.DAT
DOOR.SYS
CALLINFO.BBS
DORINFO1.DEF
DORINFOx.DEF, where x is the node number
As soon as it finds a directory containing one of these
filenames, BFE will stop it's door information file
search phase. It then begins to decide what to do with what
it has found. If more than one of the above filenames was
found in the directory in question, BFE will read the
file with the most recent date and time stamp. This is intended
to overcome abiguities that can arise when a door information
file conversion program is being used, and a number of
different door information files may still exist in the
directory. In such a case, it is assumed that the most recently
created file is the one that should be used. If more than one
file exist with an identical date and time, BFE will use
the file that is closer to the beginning of the above list. (ie
they are listed in their order of priority)
Once BFE has decided which file it is going to use, it
may have still more decision-making to do. In the case of
door information file names that correspond to more than one
format (such as DOOR.SYS), BFE will examine the file
to determine which format it actually is. If a DORINFO?.DEF
file is found, BFE will then also attempt a search for an
EXITINFO.BBS file. Again, if an EXITINFO.BBS file is found, BFE
must determine which of the many EXITINFO.BBS formats it is actually
dealing with.
This may all sound rather complicated, but it is a well thought-
out strategy that is intended to asure that the correct door
information file will be located and used in the vast majority
of cases. (and to think - it does all this in the blink of an
eye!)
If you need to specify a specific path to your dropfile, see the "BBSDir"
option in the next section.
As of v1.22, BFE recognizes the following dropfile formats:
DORINFOx.DEF (Standard DORINFOx.DEF Drop file (Default))
EXITINFO.BBS (RA v.01 - v.04)
EXITINFO.BBS (Extended (RA v1.0+))
EXITINFO.BBS (RemoteAccess 2.0+ style)
CHAIN.TXT (WWIV)
SFDOORS.DAT (SpitFire BBS)
CALLINFO.BBS (WildCat!)
DOOR.SYS (GAP/PC-Board)
DOOR.SYS (Doorway version)
QBBS 2.75+ (EXITINFO.BBS)
DOOR.SYS (WildCat! style)
Custom (See the global config file section)
** Additional Notes on the Global Configuration File: **
The name of the .GBL file is passed on the BFE command line. If you do not
wish to make use of the options in the BFE.GBL file, simply pass a dummy
name (i.e. NULL, DUMMY, etc). In other words, if BFE cannot locate the
global configuration file, it will be ignored, and all defaults will be used.
---------------------------------------------------------------------------
External Protocol Configuration
---------------------------------------------------------------------------
Whenever you make use of BFE's file transfer types (F and M), you will need
to make use of external protocols. Previous releases of BFE made use of the
DSZ file transfer engine from Omen Technology. However, in order to solve
command line problems, not to mention providing a more flexible layer for
using other protocol systems, the PROTOCOL.BFE file has been implemented.
The format of this file is incredibly simple, yet powerful. You may specify
up to 9 protocols in this file. If you need more than this you are overdoing
it. :-)
;-----------------------[ Sample PROTOCOL.BFE File ]------------------------
;┌────────────────────────────────────┬─────────────────────────────────────┐
;│██▀▀▀▀█ ██▀▀▀▀▀▀ ██▀▀▀▀▀▀ │ For support, contact: │
;│██▄▄▄▄█▄ ██▄▄▄▄▄ ██▄▄▄▄▄ │ │
;│██ ▄█ ██ ██ │ Scott Burkett, Sysop │
;│██▄▄▄▄▄█ ██ ██▄▄▄▄▄▄ v1.30.2α│ Under the Nile BBS, 1:3613/12 │
;│ │ (706) 596-8126 14.4/v.32 │
;│BBS Front-End System └─────────────────────────────────────┤
;│(C)opyright 1992, 1993 Cairo Research Labs, All Rights Reserved │
;└──────────────────────────────────────────────────────────────────────────┘
; PROTOCOL.BFE
; ------------
; If you're using a locked baud rate, you will probably not use the %s
; parameter in your protocol batch files. Simply place your locked baud
; baud rate (19200, 38400, etc) in place of where the %s would normally
; appear.
;
; BFE passes: %1 - Node number
; %2 - Port number (1-4)
; %3 - Serial Speed
; %4 - File to download (complete path, if specified in SEC.)
; %5 - U = Upload D = Download
;
; Format: Protocol [Description (one word)] [Protocol batch file] [A]
;
; ** The [A] parameter above will force BFE to prompt the user for
; the filename (if uploading). Some protocols, such as ZModem,
; do not need this option enabled, as they automagically obtain
; the filename through the initial transmission header.
;
; You may list up to 9 Protocols (Only the first nine will be used!)
Protocol DSZ/ZModem DSZMODEM.BAT
Protocol DSZ/YModem DSYMODEM.BAT
Protocol DSZ/XModem DSXMODEM.BAT A
;---------------[ End of Sample PROTOCOL.BFE File ]------------------------
The contents of your batch files will vary, but here is a sample batch file
for calling DSZ in the above DSZMODEM.BAT file:
@echo off
REM %1 = Node
REM %2 = Port
REM %3 = Speed
REM %4 = Filename to be transferred
REM %5 = (U)pload or (D)ownload
SET DSZPORT=%2
if "%5" == "U" goto UPLOAD
xu port:2:off
dsz.com ha on port %2 speed 19200 sz %4
xu port:2:on
goto END
:UPLOAD
xu port:2:off
dsz.com ha on port %2 speed 19200 rz
xu port:2:on
:END
SET DSZPORT=
----------[ Cut Here! ]
*** Note that 19200 was used in the above example. You would do this if you
run with a locked serial port. If you are not running a high speed modem
at a locked serial speed, simply substitute the 19200 with the %3 value.
---------------------------------------------------------------------------
┌────────────────┐
▄│ Sysop Keys │
█└────────────────┘
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
There are several options available to the Sysop while the user is in the
BFE Door. These options and hotkeys differ from BBS "personality" to
"personality". As discussed in the sample global configuration file, BFE
currently supports 3 BBS personalities (RemoteAccess 2.0x, WildCat!, and the
default style). For more information on the RA and WildCat! hotkeys, consult
the documentation which accompanied the BBS software.
DEFAULT SYSOP HOTKEYS
---------------------
[UP/DOWN] - Use the arrow keys to increase or decrease the
amount of time which the user has left in the door.
[Alt]-[C] - Allows the sysop to break into chat with the user
at any time. [Alt]-[C] again, or [ESC] will end
chat mode. (Notice that the Want-Chat indicator
will also be turned off, if it was flashing. If
you are running under Apex, RemoteAccess or
QuickBBS, paging from within the door will even
cause the Want-Chat indicator to stay lit when the
user returns to the BBS)
[Alt]-[J] - Allows the sysop to shell to DOS, if enough memory
is available. Simply type EXIT to return to the
door again.
[Alt]-[H] - Hang up on the user. Plain and simple!
[Alt]-[L] - This key locks the user out of the BBS. It first
hangs up on the user, and then sets their security
level to 0, to prevent them from ever logging on
again. This feature may require use of the EXITINFO.BBS
file, depending on what system BFE is running under.
[Alt]-[K] - The "User Keyboard-Off" key allows the sysop to
temporarily prevent the user from typing anything
on their keyboard. This has no effect on the local
keyboard, but causes BFE to ignore any keystrokes
from remote.
[Alt]-[N] - The "Sysop Next" key, this function reserves the
system for use by the sysop after the user logs
off, if BFE is running under an Apex or RA
1.00 or later system.
[Alt]-[D] - "Drop to BBS" key. This function allows the sysop
to exit BFE and return the user to the BBS,
without hanging up.
[F1] - Display basic user information (default)
[F9] - Display help information for sysop
[F10] - Turn off the status line
┌──────────────────┐
▄│ Command Line │
█└──────────────────┘
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
BFE accepts the following parameters (in any order):
-p(Port> - 1,2,3,or 4 (COM1, COM2, etc)
-s(Serial speed> - Self explanatory!
-c(Control File Path> - Path/filename of your main .CTL file!
-t(Time to next event) - The time until the next event
-f - Forces ANSI in local mode
You can run BFE in local mode by passing "-p0 -s0" as the port and speed.
Of course, if you are using a dropfile, these values are meaningless
once again, therefore your dropfile must be configured for local use (Or
comment out the "Dropfile" keyword in the global config file!)
┌───────────────────────────────┐
▄│ Multinode/Multiuser Operation │
█└───────────────────────────────┘
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
BFE is quite capable of running on multinode systems, and in fact, does it
quite adeptly. Special care has been given to ensure 100% multinode compat-
ibility. If you happen to experience problems running BFE on a multinode
machine, please contact us if you are unable to resolve the problem.
** NOTE: BFE creates a special "semaphore" file called BFELOCK.$$$ whenever
a node is currently reading a control file. If another instance of BFE is
executed, it will wait until this file is erased by the owner instance of BFE.
If, for some reason, BFE seems to "lock up", check for the existence of this
file, and simply remove it. Careful attention has been paid to ensure that
this file gets deleted in any event, but things can happen!
────────────────────────────────────────────────────────────────────────────
■ MISCELLANEOUS ■
────────────────────────────────────────────────────────────────────────────
┌────────────────────┐
▄│ Special Thanks │
█└────────────────────┘
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
We would like to take time to offer our appreciation to the Cairo Research
Lab Beta Team. Thanks guys!
A special thanks to Steve Pepin, for his persistent help with the WildCat!
concerns in *all* of our door products.
Special thanks go out to Bob Kruger, the friend and beta tester from the
outskirts of hell. And to Diane (my wife-to-be, for her graduation from
4 years of nursing school hell!).
Thanks are also in order for Brian Pirie for authoring a *superb* DOS commo
library, and countless others whose efforts and caveats seem to go unnoticed
at times.
┌──────────────────────────────┐
▄│ Upgrades and Information │
█└──────────────────────────────┘
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
For the latest version of BFE, or for tech support by BBS, call:
Under The Nile!
(706) 596-8126 14.4 v.32
1:3613/12@fidonet
All tech support calls to Under the Nile, please.
Magic name BFE will get you the latest version!
Magic name BFEBETA will get you the latest beta version!
────────────────────────────────────────────────────────────────────────────
■ END OF BFE 1.30.2α DOCUMENTATION ■
────────────────────────────────────────────────────────────────────────────