home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Black Box 4
/
BlackBox.cdr
/
bbs_ra
/
xrdor206.arj
/
NEWIN206.DOC
< prev
next >
Wrap
Text File
|
1992-04-10
|
6KB
|
103 lines
I assume that most everyone getting 2.06 will have already seen the 2.05
version, so I left the detailed blow-by-blow from 2.01-=>2.05 out of this
"New In" file. This 2.06 version will be re-released as 2.10 within two
weeks through the SDS with a detailed list of all changes from 2.0 to the
2.1 version! (or you can refer to the "NEWIN205.DOC" file in XRDOR205.ZIP)
Also, if you're not familiar with XRSDoor: XRSDOOR!.EXE is a '286 version.
XRS "eXpress Response System" (R) Door version 2.06 changes:
0) Lord help us - this one's been moved from BC++ 2.0 to Borland C++ 3.0!
Watch for "unusual" new features, please! I had to turn optimization off
for one entire module (the name lookup binary search) already.
1) XRSDoor supports "No Reply" areas if the SysOp enables it (only!). Any
area you have marked "Read-Only" becomes a read-write but not quote-reply
message area. (in other words, the use can make an area readable, and they
can enter an original new message but they cannot quote or reply to existing
messages. This support is exclusive - one way or the other - either "Read
Only" really means read-only, or it means no-reply. Put the new "No Reply"
parameter into your QMXSETUP.CFG control file to enable this feature. Note
that it's an all or nothing proposition: either you have all areas marked
this way really read-only, or they're all no-reply! If a user enters any
new message into the "No Reply" conference, it is always marked "public".
YOU ARE OVERRIDING THE BBS SECURITY AND ANYONE CAN ACCESS AND LEAVE MESSAGES
IN ALL CONFERENCES MARKED "READ-ONLY" AS LONG AS THEY HAVE AT LEAST A "READ
ACCESS" LEVEL FOR EACH GROUP IF YOU ENABLE THIS OPTION! Note also that the
areas which are "Read-Only" (regardless of whether or not you turn this on)
will still be read-only for all XRS users except XRS 5 "Mod 3" or higher.
(in other words, only XRS 5 "Mod 3" or later supports "No Reply")
2) Chuck Forsberg seems to keep changing DSZ.COM to suit, and this time he's
restricted the 'restrict' command to registered copies. XRSDoor has always
used the "restrict" on uploads to protect you from users to uploading to
current directory only. This is now a registered DSZ 'feature', so XRSDoor
doesn't use it by default. (see below - you can re-enable it with DSZPARM
or the "SET DSZOPT=-r" environment string if you have a registered copy)
3) We still didn't get "DSZPARMS xxx" right in 2.05: you couldn't change any
parameter appearing after the protocol. In this version, you can use "%s"
(lower-case 's'!) to substitute for the protocol, if you don't the protocol
is added to the end of your parameter string. Example: "DSZPARMS handshake
both restrict estimate 0 $B %s -m" to turn on "MobyTurbo".
4) The "Limit xxxx" parameter allows you to set it up to 20,000 messages!
You should use this feature with caution! Even though XRSDoor computes the
time left -vs- time required to pack 'x' number of messages, it is possible
that a user with download problems could conceivably tie up your system for
an extended period of time, although XRSDoor checks time remaining between
offers to try again on downloads, so if they aren't dialed in at 9600+ and
receiving at 300 baud, it shouldn't be a problem. A 20,000-message mailbag
is about 20MB in size compressed, and requires 60 to 65MB free space on the
drive to create and pack! (and quite a while to transfer even at 1700 cps!)
Users should be cautioned that picking more than 5000 messages in a mailbag
may be unreadable in a system without EMS memory (the heap expander could
allow me to go up to 256K messages, but that's a bit much!). A full 20,000
message mailbag requires a system with at least 2MB EMS memory!.
5) XRSDoor will allow you to call it with command-line parameters which can
either eXpress-Upload mail (only) or eXpress-Download mail (only). To use
these functions, put "/UPLOAD" or "/DownLoad" as the only parameter on the
command-line in your BBS menu configuration. Auto-Download sends up to the
the limit you defined in your "Limit xxx" parameter (default 1500). Local
(console) users cannot upload so this option make no sense for them! (but
XRSDoor checks for it though - and gracefully exits if you try) Downloads
are allowed for Local users, but they are saved in compressed format and
not transmitted, of course.
6) You can force XRSDoor to use RA files with "BBSType RA" in QMXSETUP.CFG
or force XRSDoor to put any of the following identifiers into the USERx.XRS
file: "PCBoard", "Quick", "Super", "WildCat", "Tag" and "MKBBS". Only XRS
5.0 "Mod 3" and later recognize the last two. Don't read any more into this
than it says: you can force XRSDoor to place one of the above identifiers in
your mailbags, so that XRS returns mail with origin lines that agree with
the actual BBS type you are using, regardless of which control files you are
using - but you still must have either a complete set of QuickBBS (either
2.0x-2.6x or 2.7x+) or RA format control files and message databases to run
XRSDoor! Note that one special case: "BBSType RA" causes XRSDoor to ignore
any QuickBBS control files which might be in the directories (because you
use QEcho, or whatever) and only pay attention to RA configuration files.
In all other cases, the *only* effect is to cause XRSDoor to put the tag in
USERx.XRS which corresponds to the above BBS type.
7) You can force the "EXPRESS.BBS" file to be echoed to the console (i. e.
displayed online) by placing an exclamation point ("!") as the first byte
in the file (in which case it is skipped). This might be useful in notices
about program changes or new features, which you could run for a short time
after a new program release, etc. A sample "EXPRESS.BBS" file is enclosed.
8) You can force XRSDoor to export 'kludge' lines either only for the SysOp
or for all users. "Show SysOp Kludges" in QMXSETUP.CFG will turn it on for
the SysOp only, or "Show User Kludges" will turn them loose for everyone.
For the SysOp (only) in either case, XRSDoor exports any SEENBY and/or PATH
lines it finds - but never shows these for users.
9) XRSDoor marks messages "To You" for aliases, and searches outside selected
areas for messages to the alias if that "<O>ption toggle" switch is set.
10) The cursor is lined-up correctly under the first character of menus.