Beijing Paradise BBS Backup/PARADISE.ISO/software/BBSDOORW/BW301MAX.ZIP/WHATSNEW.301

Text File | 1993-08-04 | 19.6 KB | 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