home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.wwiv.com
/
ftp.wwiv.com.zip
/
ftp.wwiv.com
/
pub
/
OFFLINE
/
BW301MAX.ZIP
/
WHATSNEW.301
< prev
Wrap
Text File
|
1993-08-04
|
20KB
|
458 lines
The Blue Wave Offline Mail Door for Maximus
v3.01
Upgrade and New Feature Documentation
Copyright (C) 1993 by Cutting Edge Computing
All Rights Reserved.
This information is provided for those people who are familiar with
previous versions of the mail door, and who do not care to comb the full
documentation to find what has been added or changed since the last
release.
However, if you are unsure of how to use a feature that is described
here, consulting the appropriate section in the full documentation
(BWMAIL.DOC) will be necessary.
INSTALLATION
------------
Please read the file INSTALL.301, which was enclosed in the original
distribution archive (BW301MAX.ZIP).
This version of The Blue Wave Mail Door is being distributed with a file
called BWDOOR.USE. This is an ASCII file that explains the use of The
Blue Wave Mail Door, what each item on the configuration menu does, how
to use The Blue Wave Bundling Commands, and more. This is an excellent
tutorial for new users to the mail system. It is suggested that this
file be placed online for your users to download.
CHANGES MADE IN VERSION 3.01
----------------------------
* Due to popular demand, you may now give a more complete description of
each archiver that you have configured in the door. Many people needed a
way to distinguish between PKZIP v2.04 and v1.10. You can now enter a
long description for each archiver through the BWUTILS->Archiver
Configuration Editor. This long description will be displayed when users
choose/change archivers within the door.
* When using the internal protocol driver under OS/2 (either from a DOS
session or from an OS/2 session), you may need to add the undocumented
/FAST (now documented!) command line parameter to the door's (BWMAIL.EXE)
command line. This command line parameter uses "Direct" communications
with the com port instead of working through the FOSSIL. Quite a few
people have reported that this will cure the "Unable to synchronize with
remote system" errors from Zmodem. You may want to try this switch even
if you are not running OS/2, but are having trouble with the internal
protocol driver.
* A number of people reported lockup problems which occurred during the
door's bundling process. This occured on systems that had *.MSG message
areas with "empty" text in the messages (such as ARCmail file attaches in
a netmail area).
* When modifying RESTARxx.BBS (on XTERN_ERLVL calls from Maximus), the door
would sometimes rewrite the file in such a way that Maximus thought it
was in local mode upon return from the door.
* All reported problems with the internal protocol driver have been
addressed. Some complaints included failed Xmodem sessions (Xmodem-CRC,
Xmodem-CheckSum, Xmodem-1K) and the inability to sync properly when the
remote user was using the "Communique" terminal package with Zmodem.
* Editing a user's transfer protocol through the BWUTILS->User Editor
didn't always work properly.
* In some cases the door was generating duplicate MSGIDs.
NEW FEATURES IN VERSION 3.00
----------------------------
* The Blue Wave Mail Door v3.00 now can use a "Version 7" Nodelist.
Support for the FrontDoor nodelist format has not been included.
* Added support for Max's EXTENDED barricades. Please note that "regular"
barricades are not supported, since having to enter a password at each
login to the door for every area that is barricaded is next to pointless.
If the door detects that the area contains a "regular" barricade, it will
proceed as before (the message area will not be available to the user
through the door).
The door processes EXTENDED barricades in the same manner as Maximus.
There should not be any changes necessary to your existing setup.
* A new option on the door's configuration menu: N)ew File Listings in
Packets. Users have the option of setting this option to YES, NO, or
COLOR. If the user chooses NO, no new file listing will be sent in the
download packet. If the user chooses YES or COLOR, the door will scan
for new files since their successful mail download. The door will
include ANSI sequences if COLOR is turned on.
Some things to keep in mind about the new file list scanner:
a) Maximus does not store an "Upload" Date with the file. Therefore
the file date must be used in determining if the file is "NEW" or
not. If files are added to the BBS with an old file date, it will
not show up in the new file scan.
b) You must be running FB to create the FILES.* files in your file
directories. The door processes the binary data files in the
interest of speed. It will not use a straight "FILES.BBS".
c) Areas defined in your FILEAREA.CTL file with the "FileList <File>"
keyword (used mainly for CD-ROM file directory listings) will NOT be
scanned for new files. Since it is very unlikely that new files have
been added to the CD-ROM, the door skips the area in the interest of
speed.
d) All of Max's PRIVS, LOCKS, and EXTENDED BARRICADES are supported in
the file areas. If a user does not have access to a file area within
Maximus, the door will not even bother to scan the area for files.
e) The door creates the new files list in a file called NEWFILES.BW.
You do *not* need to put NEWFILES.BW as one of the "reader files" in
the BWUTILS->General Information Editor.
f) All file listings generated by the door include the file name, file
size, file date, and the full description. The door will "wrap" long
file descriptions, up to 10 lines.
* The entire "message upload" portion of the mail door has been rewritten.
You will probably notice a big increase in speed. The display while
tossing uploaded messages has also been changed to be more informative.
* Duplicate message detection has also been overhauled. The door will now
use a file called BWDUPES.IDX to store duplicate message information.
You can safely delete the old duplicate detection file (BWDUPES.DAT)
after installing the new version.
* The File Requesting code has been rewritten. When looking for the files
that a user has requested, the door now finds the file through
MAXFILES.IDX in the main \MAX directory. For this reason, you must be
running FB.EXE to create the file database in order for file requesting
to work properly.
When locating a file, the door uses MAXFILES.IDX for a speedier search.
People running CD-ROM drives complained that it took forever and a day to
locate a file before.
* In the BWUTILS->General Information Editor, you will notice that each
of the 5 "reader files" are now configurable by priv level and locks. If
a user does not have sufficient access to a reader file, the dor will not
send it. This will allow "custom" welcome screens by security level to
be passed to the reader. By default, each of the reader files have been
assigned "DISGRACE" access with no locks required.
In order for you to edit the PRIV/LOCKS on the reader file, you need to
first edit the name of the file (type any character in the field).
* BWUTILS now has a new menu item - The "Limits and Maximums" editor. For
each BPS rate that your system supports, you can now define 2 limits on
the amount of mail that is packed by the door. It is important to
understand how each limit works:
MAXIMUM UNCOMPRESSED PACKET SIZE is the largest mail packet size
(uncompressed, obviously!) that a user at a certain BPS rate may
download. Some may find this useful if they bundle messages (have their
WORK directory pointed) to a RAMdrive. For example, I have a 2 meg
RAMdrive configured as the door's WORK directory on my system.
Therefore, I have all of the BPS rates configured for 1800K uncompressed
packet size to ensure there is always enough room to complete a
successful packing session. If you do not care how large the
uncompressed packets are for any particular BPS rate listed, simply set
the field to -1. This will cause the door to have no set limit (other
than disk space).
MAXIMUM NUMBER OF MESSAGES obsoletes the old "overall Maximum Messages"
setting the door had. The door enforces the maximum number of messages
per BPS rate, just as with the MAXIMUM UNCOMPRESSED PACKET SIZE. If you
wish to set no limit for the maximum number of messages, simply enter
"-1" in the field. The door will not enforce a limit for that particular
BPS rate.
There is an important difference in the way these two limits work. "MAX
MSGS" limits are enforced BEFORE any bundling of the messages takes
place. The user must use the bundling commands to trim the size of their
mail packet before proceeding with a mail bundling session. "MAX PKT
SIZE" is enforced DURING bundling. If at any time during bundling the
door reaches the maximum packet size limits, it immediately halts the
bundling process and compresses the mail packet for the user to download.
* In the LIMITS AND MAXIMUMS editor, you can tell the door whether or not
you will allow NEW FILE scans to take place. If this is set to "NO",
users will not be given the option on the door's CONFIGURATION menu to
create newfiles lists.
* In the LIMITS AND MAXIMUMS editor, you can define the maximum number of
days to "look backwards" to find new files. If a user has not logged
into your system for 6 months, you (most likely) do not want them
receiving a NEWFILES listing containing the last 6 months worth of new
files. You can control the maximum number of days to include in the file
list by editing this field. A good number to use here is probably
somewhere between 10 and 30 days.
* If you are exiting Maximus to run the door as an "Extern_Erlvl" type of
shell, Maximus creates a file called RESTAR<task>.BBS in the main \MAX
directory. If the door finds this file after an upload session, it will
write information to the file to tell Maximus to exit with the "After
Echomail", "After Netmail", and "After Local Mail" errorlevels that you
have defined in MAX.CTL.
* If you are running a multi-line system, the door will look for a defined
IPC directory when a user enters. If there is an IPC directory defined,
it will edit the IPC<task>.BBS file to say "Using Blue Wave Mail Door",
instead of the "Running External Program" that Maximus leaves there.
* Previous versions expanded "%T" in pathnames to the hexadecimal task
number that was passed to the door. This is still true, but you can now
use a "%N", which will expand to the DECIMAL task number passed to the
door.
Assuming you have a download directory defined as "C:\MAX\BW\DOWN%T"
Example of door running as task 10, expands to "C:\MAX\BW\DOWN0C".
Example of door running as task 1, expands to "C:\MAX\BW\DOWN01".
Assuming you have a download directory defined as "C:\MAX\BW\DOWN%N"
Example of door running as task 10, expands to "C:\MAX\BW\DOWN10".
Example of door running as task 1, expands to "C:\MAX\BW\DOWN1".
* The door now detects when it is being run under one of the following
multi-taskers, and frees time slices accordingly:
MS-Windows Enhanced Mode
OS/2 Virtual DOS Machine
DESQview
If time slicing is occuring for one of the above multi-taskers, a line
will be logged to the designated log file indicating which type of
slicing it has detected it should use.
* For sysops packing mail for users in nightly events using the /K<user#>
command line parameter in conjunction with the /D (autodownload)
parameter, there is a new and preferred way to load the door in local
mode.
bwmail /Kgeorge_hatchew /d
will load the door in local mode, search USER.BBS for "George Hatchew",
and then perform an auto-download. You can do the same thing with *any*
name in your user file. Simply remember to use UNDERSCORES instead of
spaces when using this method of local login. "Jason St. Martin" would
look like this: /Kjason_st._martin. The names entered on the command
line are case insensitive.
* The BWUTILS->Protocol Editor has been rewritten to support the new
INTERNAL protocols.
* The door now supports 8 internal protocols which can be activated and
deactivated through the BWUTILS->Protocol editor. There is absolutely
nothing to configure for the internal protocols as far as command lines
go. The Blue Wave Mail Door now has support for the following built-in
protocols:
Zmodem (Both 16 and 32 bit CRC mode)
ZedZap (Zmodem with up to 8k subpackets, depending on BPS rate)
Ymodem (Standard 128 byte block Ymodem-Batch)
Ymodem-G (1024 byte blocks, no error recovery)
Ymodem-1k (1024 byte blocks with error recovery)
Xmodem-1k (1024 byte Xmodem blocks)
Xmodem-CRC (Standard 128 byte block Xmodem with CRC error checking)
Xmodem-Checksum (Standard 128 byte block Xmodem with Checksum)
* Support for external BIDIRECTIONAL protocols has been added (such as
Hydra and Bimodem). Users can now upload their reply packets while
downloading their messages. After the door has completed a mail
download, it will scan the defined UPLOAD directory to see if anything
has been transferred. If there was a *.NEW file uploaded, the door will
process it immediately.
* To aid in executing external bidirectional protocols, the protocol
command lines can now contain a "%U" parameter, which will pass the
UPLOAD DIRECTORY ONLY to the protocol. All bidirectional protocols need
to know the upload (receive) directory when executed.
* After the door has completed mashing a mail packet, the user now has the
following choices:
A)bort download
C)ountdown logoff
I)mmediate logoff
P)rotocol Change (Current Protocol) <=== New!
[ENTER] for normal download
* "Chat Mode" has been added to the door. To chat with an online user,
type <Alt-C> from the local keyboard. To exit chat mode, simply press
ESCape.
* When uploading messages, the door now places a ^aMSGID: line into the
message.
* NEW on the door's CONFIGURATION menu -- User now has the option of
toggling the status of "U)se Numerical Packet Extensions". If this
option is ON, packets will be named as BBSID.001 through BBSID.999.
After .999 is reached, the door recycles back to .001. If this option is
left OFF, the original BW packet extensions are used (.SU1 - .SA9).
* When selecting message areas for download, users now have the choice of a
default bundling action for the area:
Personal Messages Only
Personal Messages, plus those messages addressed to "All"
Default action of all new messages.
* The mail scan screen has been changed. Hopefully it is a bit more
readable and informative than before. In the right-most column of the
scan screen there is a new column called "# DL'ing". This column
indicates the number of messages that are going to be packed for
download. You'll notice that as you enter bundling commands and select
"R" to relist the scan screen, the numbers will change depending on the
effects of the bundling command.
Directly after the area name in the scan screen is a short phrase that
indicates the type of bundling action that will be performed on the area:
New -- Indicates that all messages since the last msg download will
be packed.
Pers -- Only personal messages since the last msg download will be
packed.
P+All -- Only personal messages, and messages addressed to "All" will
be packed.
Kwds -- Only messages containing user keywords will be packed.
Filt -- Messages that contain any of the filters will be skipped
during packing.
L 20 -- User issued an <area#>L20 command for this area; only the last
20 messages in the area will be packed for download.
B 100 -- User issued an <area#>B100 command for this area; only the
first 100 messages in the area will be packed for download.
Force -- The area is being forced for download by the sysop. No
bundling commands can be issued for this area.
None -- User issued a -<area#> for this area, and no messages will be
packed.
* A *NEW* Bundling command to go along with the "Personal+All" options for
downloading... "A200" would force the door to only bundle messages in
area #200 that were PERSONAL MESSAGES, or were addressed to "ALL". As
with all of the other bundling commands, "A*" would perform the same
action on all areas.
* When 0 messages are found during the initial mail scan, the line:
There are 0 messages prepared for download.
is sent to the screen so that creative people using script files can have
their script skip the mail download.
* A new command line parameter -- /NORECV -- will force the door to NOT
mark messages as "Received" when they are downloaded. Good for sysops
who can't answer their mail right away and want to trick users into
thinking their mail hasn't been read yet :-). This probably shouldn't be
used for normal BBS-user use.
* When "/d" or "/u" is used with a remote user online, the following
command lines are available:
/INSTANT --- Causes an instant logoff after a successful auto
download or auto upload session.
/COUNT --- Causes a countdown logoff after a successful auto
download or auto upload session.
WHAT'S FIXED
------------
* The door should no longer require the use of the "SET TZ=<timezone>"
environment variable. You can save yourself a few bytes of memory by
deleting this line from your AUTOEXEC.BAT file, if you do not have other
programs that need the TZ variable set.
* The door should now be sorting message areas the same way that MAXIMUS
sorts them when displaying area listings.
* Some people were experiencing trouble with portions of messages appearing
in the text body of other messages. This was only happening on *.MSG
formatted message areas. The problem has been fixed.
* The mail door used to cause a SHARE violation on the OVERRIDE.IDX file,
located in the door's main directory when more than one door was active
at a time. This has been fixed.
* The door now asks for the user's DOOR PASSWORD (if so configured) when
entering AutoDownload and AutoUpload mode (/D and /U).
* The mail door now echos the '*' character when entering and changing
passwords in the door.
* The reader is limited to 5 characters for "area numbers". Maximus is
unique in that it supports "area numbers" of up to 9 characters.
Problems have been reported when sysops have long area numbers defined
for Maximus and they are NOT UNIQUE within the first 5 characters. One
example arose where the sysop provided Usenet newsgroups to users, using
names similar to the following:
C-SYSBIN
C-SYSUNIX
C-SYSDOS
C-SYSOS2
Since all of these areas begin with "C-SYS" (and that is what the reader
sees), areas were getting mixed up. The only solution I could come up
with is to assign unique names to the areas for display in the reader.
They are STILL DISPLAYED AS THE FULL 9 CHARACTERS IN THE DOOR.
The door now passes the following to the reader as area numbers in the
example:
C-SY1
C-SY2
C-SY3
C-SY4