Hello:

This message represents the official pre-release announcement of GT Power
16.00.  P&M Software Co. is now ready to receive orders for the product,
all orders received prior to 12-15-90 will be guaranteed to ship in the
first batch, due to go out just before Christmas.  The upgrade fee, for
those who have registered previous versions GT Power, is $20.  For those
that have not previously registered GT Power, the asking price for the new
version is $70 --- but don't forget the sale (you can purchase 15.50 for
$40 and then upgrade for $20, saving you $10).

Please send all registrations to:

    P&M Software Co.
    3104 E. Camelback Rd. #503
    Phoenix, AZ 85016

    Phone: (602) 285-9914

Now here is the official new feature list:
==============================================================================
                                GT POWER 16.00
==============================================================================
o   1.    Custom menus.  For the main menu and the message base submenu.
    It is now possible to hook a door type program, of your choosing, into
    the either the main host mode menu or the message base submenu.  New
    lines have been added to the SYSOP.BBS file to accomodate these custom
    menus.  As follows:

        "MENU="
        "MMENU="

    The first line, MENU=, is used to define custom items for the main host
    mode menu.  The second line, MMENU=, is used to define custom items for
    the message base submenu.  Here is an example of how it might look:

        "MENU=[MR]modread;Z;Enter data:;[ZV]zipview;Z;&"

    The letters inside the brackets are used by callers to select the
    custom command, the name following the left bracket is the name of
    the batch file to be executed, followed by the access level required
    to use the command, then a prompt for information to be passed to the
    batch file.  If the prompt begins with '&', then the batch file does
    not overlay GT Power.  This syntax is exactly the same as that used
    below for "MMENU=".

    However, the actual interface to the batch file is somewhat different
    from the standard door interface.  The first three parameters, are
    unchanged, as follows:

         Param     Description
         -----     -----------
           1       The CTTY or REM.
           2       The COM port number.
           3       The prompted for data.

    The last param, param #3, is optional, of course.  But, for items on the
    MMENU= list, GT Power will automatically add the following two parameters:

           4       -Pmsg_path, where "msg_path" is the path to the currently
                   active message base.

           5       The number of the previous message read by the caller.

    For example, here is what some command lines might look like:

         medit CTTY 1 foobar -PC:\GTBBS\MSGB1 103

    Where 'medit' is the name you have assigned to the batch file, CTTY is
    the signal that a remote caller is using the system, 1 is the COM port
    number, 'foobar' is the data entered by the caller when prompted,
    '-PC:\GTBBS\MSG1' is the pathname of the current message base with a
    '-P' stuck in front of it, and 103 is the message number last read by
    the caller in that area.

    Please notice that 'foobar' is optional, if it is not needed, then the
    rest of the command line would be slid over.  The message path would
    become param #3 and the message number would become param #4.


o   2.    For LAN users, the maximum number of pids has been raised from 10
    to 32.  YOU MUST DELETE the old PID_FILE.BBS prior to running the new
    version.  The format of the PID_FILE.BBS has changed - the CB Handle has
    been added to it, and the record length has been increased by 64 bytes.

    In addition, the CB Simulator has been upgraded.  The @who command now
    uses the PID_FILE.BBS for its input, so it is more reliable and contains
    more information.  A new screen has also been added to the CB Simulator,
    GTGREET.BBS, which will be displayed to the caller after entering the
    CB Handle.  And an automatic @who command is executed, so that the caller
    will not wonder if anyone is available for a chat.  The CBGREET.BBS file
    should be short and to the point, i.e. introduce the automatic @who list
    and tell the caller to use '?' for help.


o   3.    Many people have asked for a more structured approach to bulletins.
    It is now available.  First, only numeric bullets are used.  If a number
    is shown or entered with a '.' contained within it, then the '.' is
    removed and ignored - it is just a noise character.  Therefore, 1.0 would
    be equal to 10, 1.2.0 would be equal to 120, etc.  The GTBMENU.BBS file
    is stored either in the GTPATH or the BBS/CBS directory, the numbered
    bulletins are still stored in the "Default File Directory".  Any of the
    numbered bullets may be menus, i.e. GT will not automatically return to
    GTBMENU.BBS when they have finished being viewed, thus a new letter
    command is required, (M) for return to the (M)ain Bulletin Menu
    (GTBMENU.BBS to be exact).  Each numbered bullet file that is actually a
    submenu file should begin with a line that contains only ";BMENU", in
    uppercase.  GT Power stacks these submenus internally, so it is possible
    to pop back to the previous menu, the new letter command (P)revious Menu
    has been added to allow this to occur.  The stacking of bullet menus does
    have a limit - not counting the main bullet menu, you may stack up to 5
    levels deep.  If you exceed 5 levels, it will continue to work, but the
    (P)revious Menu command may stop functioning, as it can no longer track
    the extra bullet menus.

    For example:

    In file GTBMENU.BBS:

                    1.0   General bulletins
                    1.1   Game bulletins
                    1.3   Network bulletins
                    1.4   Political bulletins


    In file 10 (point 1.0):

          ;BMENU

                    1.0.0   Rules of the board
                    1.0.1   How to get more time
                    1.0.2   How to get better access


    In file 100 (point 1.0.0):

                    There is only 1 rule on this board:

                            Do not use profanity


    In file 101 (point 1.0.1):

                    You can get more time by reading the bulletins
                    and participating in the message bases.


    In file 102 (point 1.0.2):

                    If you want to download alot of files, you can get
                    better access by uploading files that are of value
                    to this board.


    Please note, each of the points shown above is a separate numbered file
    in the "Default File Section".

    I hope you get the idea and that it is not necessary for me to carry
    on with the hierarchy for 1.1, 1.2 and 1.3.  It would be pretty much
    the same sort of stuff.  Once you see how it is done, you should be
    able to do it easily for other bullets.


o   4.    A new internal protocol - Ymodem-G.  It is very fast.  But a
    single error will ruin the transfer.  This protocol has no error
    correction.  Although it can detect errors, via a CRC mechanism,
    use only with MNP modems, for best results.  Produces very good
    results with the new ultra high speed modems.  This protocol preserves
    exact file date, time and size; and is a batch protocol.


o   5.    The file transfer status windows have been spruced up a bit.
    Some new fields have been added, in additon a bar graph of the transfers
    progress has been added.  The new fields are a dynamic display of the
    CPS rate and the estimated time to complete the file transfer.


o   6.    Bugs in MegaLink have been fixed.  Or at least I think they have
    been.  These bugs are of long standing, and often caused file transfers
    to hang - especially when buffered modems were employed.  While fixing
    the bugs, I have also streamlined the error correction mechanics so that
    it is much faster than previously.  Overall, the protocol is the same
    speed as before, on clean lines.  But it should be faster, now, on
    dirty lines.


o   7.    Ymodem Batch now preserves the file date, time and size.  This
    information is now passed using the standard Ymodem header block.  This
    same header block is also used by the new Ymodem-G protocol.


o   8.    The minimum length of passwords required by the host mode is now
    configurable.  It may be set anywhere from 0 to 9 characters in length.
    This is done by actually changing the prompt to the caller which appears
    in SYSOP.BBS.  As follows:

         "Password is too short[!]  Must be [4] - [20] characters."

    This line appears in the SYSOP.BBS file on line 158 (I think).  It
    specifies that the password must be at least 4 characters long.  If
    you change it to this:

         "Password is too short[!]  Must be [6] - [20] characters."

    Then new callers must supply at least 6 characters in their personal
    password.  This may not be set above the single digit level.  Permissible
    values are '0' through '9'.  '0' meaning that there is no limitation.


o   9.    Many have asked for an expansion of the result code table to
    accomodate new modem models.  This is a real Catch-22 situation.
    Rather than add new entries to the result code table, I have taken
    the following steps:

            a)  The entries in the result code table have been widened
                to approximately 50 characters.  About as wide as the
                screen will allow.

            b)  "Smart Result Code" handling has been implemented.  GT Power
                is now be able to recognize various CONNECT results
                that are not in the table, but the modem must be setup
                to return "verbose" result codes.

                GT Power will look for the word CONNECT, followed by a number,
                followed by some sort of code word.  If this sequence is
                found, then GT Power will be able to recognize it and make
                sense out of it.  The presence of the code word will be
                taken to mean that some form of error correction is being
                used by the modem.


o   10.    Due to the addition of "Smart Result Code" handling, an addition
    has been made to the baud rate setup window under Alt-I.  This window
    now allows the sysop to specify the minimum host baud rate that is
    acceptable.  The caller will receive a message informing him/her of
    the reason for the disconnect and this occurence will also be logged.
    See the new entries for this purpose at the end of the SYSOP.BBS file.


o   11.    When a caller asks to download a file, GT Power will now be able
    to supply default extensions.  The extensions to be used for the default
    are supplied by the sysop in the SYSOP.BBS file.  As shown by the entry
    below:

            ".ZIP .LZH .ARC"

    This line appears near the end of the SYSOP.BBS file.  As with the
    "MENU=" line, this line follows very strict and regular rules.  A single
    space seperates each entry on the line, each entry is given with a leading
    '.' and in UPPERCASE.  20 extensions may be specified, but it is doubtful
    whether it is desirable to specify more than 4 or 5.  The delay in the
    seach required would become a burden, if too many are specified.

    To activate the default, the caller must ask for the file without any
    extension, like this:

            d;z;foobar

    Which would cause GT Power to look for "foobar.zip", "foobar.lzh" and
    "foobar.arc" (assuming the default entry in SYSOP.BBS, shown above).

    Or the caller might specify it like this:

            d;z;foobar.*

    Which would have the exact same result.

    However, if the caller specified it in the following manner, then the
    default extensions would not be scanned:

            d;z;foobar.

    The usage of the period, or of any extension explicitly, will stop
    GT Power from searching through the default extensions.


o   12.    The CIS "B" protocol has been dropped back to a regular external
    protocol status.  Because of this, there was room made available to
    expand the external protocol table to 16.  No big deal.  But a step in
    the right direction <grin>.

    The main reason for moving CIS "B" to a regular external status was to
    allow for an easier transition to newer CIS protocols, like the QuickB
    protocol, and to make the [C] menu character available to those that
    wish to use it for other protocols, such as Cmodem.


o   13.   Many have asked for a "frontend" type interface for usage with
    GT Power.  I have long resisted it.  But it is now available.  If you
    wish to use a frontend program with GT Power, you must setup things so
    that GT Power is invoked with the following new command line option:

            /F:nnnnn:m

    If you wish to disable the dropping of DTR by GT Power, you should use
    the /D option, in addition.

    The 'nnnnn' is the DCE baud rate that the incoming call is at. And the
    'm' is the port number that the call is coming in on.

    For example:        /F:%1:%2 /D

    Assuming that the frontend program passed the baud rate as %1 and the
    COM port and %2, and you wanted to disable the DTR drop in GT Power.
    DOS might expand this to something like this:

                        /F:2400:1

    Assuming that the call was at 2400 baud on COM1:.

    When the caller logs off the system (or drops carrier), GT Power will
    execute a exit to DOS with an ERRORLEVEL 254.  When used with a frontend,
    GT Power will never need to perform the "quit 255", since it always
    returns control to the frontend program via the ERRORLEVEL 254 exit.
    You should make sure that the batch file traps this ERRORLEVEL as required
    and returns control to the frontend program.  See the documentation that
    comes with the frontend program for further details.

    You should configure the frontend program to handle GT CRASH mail, set it
    up so that it looks for the "CQCQ" stream of characters, and then invokes
    the GTCRASH.BAT file, as required by the MDRIVER program.


o   14.   Uploads are now labeled with the name of the uploader.  For
    example, the first line of the description in the FILES.BBS will now
    show "from: John Doe" on the right side (after the dates).


o   15.   The message base structure has been altered considerably.  The
    internal structure of the MESSAGE.CTL and USER_MSG.CTL files has been
    altered and enhanced to include new fields - and some fields, not in
    current usage, have been removed.  All 3rd party authors that wish to
    upgrade their software to work with 16.00, should review these changes
    very carefully.  There is an archive of source code for the utilities
    I have written to support the new formats.  Please avail yourself of
    this source code for a more detailed explanation.


o   16.   The messages themselves have been placed into consolidated files.
    Each consolidated file can contain up to 10 messages.  The consolidated
    files are named as follows:

              00001.MES   Contains messages  #1 through #10.
              00002.MES   Contains messages #11 through #20.
              ...etc...

    The messages are stored in plain ASCII text format, and contain the same
    information as the previous .MSG files.  Each message has a header record
    to mark the beginning of the message.  The format of the header record is:

              Col 1  =  Ctrl-X
                2-4  =  'SOM'
                  5  =  '0' thru '9', depending on the relative position
                        of the message within the file.

    Within 00001.MES, message #2 would have a header of ^XSOM1, where ^X is
    the symbol for Ctrl-X.  In 00002.MES, message #12 would have a header of
    ^XSOM1 --- the same as message #2 in 00001.MES.  This scheme allows for
    the possibility of a "rapid" renumbering.  That is, the internal numbers
    on the header records are relative, not absolute.  Changing the name of
    the file, i.e. from 00002.MES to 00001.MES, automatically changes the
    message numbers assigned to the messages contained within.

    Two programs are included that handle the conversion between the two
    formats:

          MSGCVT ----- Convert from old MSG format to the new MES format.
          R_MSGCVT --- Convert from new MES format to the old MSG format.

    The R_MSGCVT program is provided in case the worst happens, i.e. you need
    to return to the release version of 15.50.  Hopefully, it will not be
    required (or at least that any reverse migration will be voluntary <grin>).

    The change to the new format has two benefits:

    1.  Fewer message files are present, thus allowing DOS to operate
        more efficiently with a large number of messages.

    2.  Disk space is more efficiently used.  On my system, with about
        a dozen message bases, which have an average of 200 messages,
        I was able to save over 2 megabytes of disk space as a result
        of converting to the new format.

    The change to the new format has two drawbacks, that I am aware of:

    1.  The use of "text threads" is somewhat slower.

    2.  The (K)ill message command is very much slower.  But it is not
        often used by callers - mostly Sysops.

    The source code for the following programs is available:

                          MSGCVT
                          R_MSGCVT
                          SYSOP
                          DELREN

    These programs handle the new message and user file formats.  The SYSOP
    program is menu driven and pretty much self explanatory.  The DELREN
    program is a batch file utility for deleting messages and renumbering
    same.  You can get a usage report by entering DELREN without any options.


o   17.   Univeral download has been implemented.  This means that you can
    download any file (to which you are entitled) from any file area, without
    being *in* the right file area.

    This new feature works with an *optional* file database.  The program
    FILES_DB has been included to allow you to build a file database.  If
    a file database exists, then 16.00 can rapidly locate it thru the file
    database (be sure to rebuild the database if you move files around).
    Each time the FILES_DB program is run, it scans the FILES.BBS files in
    the directories pointed to by the current GTDIR.BBS and builds a new
    FILES.CTL and .IDX from that information.  If you have multiple GTDIR.BBS
    files, then this process may not be possible (for security reasons).

    If you do not have a files database, you can still use the universal
    download feature, but it will run slower, as GT Power will individually
    scan each directory while the caller is online.  This is not too bad, and
    is done automatically, as long as there are not a very large number of
    files online.  Naturally, security is completely enforced, as before.

    One impact of this new method is that complete pathnames are now passed
    to external protocols.  As you can imagine, the command line (max 128
    bytes) can be overflowed very quickly.  To get around this problem, many
    protocols accept a command line parameter to use a list file, instead of
    having the files listed on the command line.  Usually, the format for
    this is "@C:filename".  Where the "filename" may include a path.  For
    example:

         dsz port %1 speed %2 handshake both sz @C:/gt/gt_xmit.lst

    This is my current ZMTX.BAT file.  DSZ is able to handle '/'s in the
    pathname, due to its UNIX heritage.  Other protocols may not like them,
    in which case '\' would be more appropriate.  In any case, GT Power now
    creates the file GT_XMIT.LST in the GTPATH directory for usage with
    external protocols.  I believe Superk also supports this syntax, although
    I am not sure of the details.  Apparantly PCKermit does not support this
    type of list transfer.  Protocols that do not support this "list transfer"
    mechanism will be limited to transfering the number of files that can
    be fully specified on the command line (so, it would be good if you used
    short sub-directory names <grin>).

    The FILES_DB is now used to help eliminate duplicate uploads.  The
    database is checked for each name before the upload is allowed to
    proceed.


o   18.   New lines have been added to the GT.WIN and SYSOP.BBS file to
    accomodate the new features.  The new lines in the SYSOP.BBS are at the
    end of the file.  The final line in the SYSOP.BBS file is not a text
    line, it is a marker, so that GT Power can tell that the proper number
    of lines are in the file (no more and no less).  The line starts with
    the word "END" in upper case letters.  No other line may start with
    the word "END".  The word "END" is followed by 1 blank then the line
    count for the file.  This should not change, and it should remain on
    the same line, no matter what other change may be made to the file.


o   19.   When a new caller logs onto the host mode, GT Power will now
    try to confirm that his name has been entered correctly.  The program
    will prompt the caller in this manner:

         Your name could not be located in the user file of this system.

         Was your name entered correctly?  [y/N]

    The caller will get two tries at this message, if the caller answers 'N'
    then GT Power will ask for his name again.  If it is still not found in
    the user file, the program will come back to this prompt.  If the caller
    again answers 'N', then GT Power will stop playing the game and drop the
    caller offline.

    If the caller answer 'y', then GT Power will prompt the caller for the
    normal new caller information.


o   20.   Incremental time limit adjustment is now possible.  Using the hot
    keys ALT- and ALT+.  As follows:

                ALT- .... Decrement the caller's time limit.
                ALT+ .... Increment the caller's time limit.

    The amount of the time change is specified in the line at the SYSOP.BBS
    file that says something like this:

    "\n\n5 min. increment\nOld time limit = %3d min.\nNew time limit = %3d min.\n"

    The number that appears after the "\n\n" is the increment in minutes.


o   21.   The screen length is now configurable on an individual caller basis.
    When a new caller logs onto the system, it will ask how long his screen
    is.  The permissible values are 7-999 lines.  Values outside of that range
    will be assumed to be 24, the default.  This may also be changed by the
    caller when he selects the (Y) option from the main menu.

o   22.   A new host mode screen variable is available for usage with
    ^U lines.  It is 'G' and will display the current setting for the
    screen length.  Here is a example:

    ^U"Screen Length = "G" lines."

    Of course, the sysop would actually embed a real Ctrl-U character
    instead of ^U, which is just the symbolic representation of Ctrl-U.
    The caller would see this as the result:

    Screen Length = 24 lines.


o   23.   EGA/VGA 43/50 line mode is now supported.  A toggle for this mode
    has been added to the Misc. Options screen under Alt-I, #30.  Things like
    the phone directory and view file commands have been ehanced to support
    the longer screen lengths.


o   24.   The name of the previous caller to the host mode is now displayed
    on the screen while waiting for the next caller.  This information, the
    name of the previous caller, has been added to the UPSINCE.BBS file.
    So, if you take host mode down, the name of the previous caller is lost.


o   25.   The S/N is now displayed by the program when the user selects the
    (V) option from the main menu.  The purpose of this is to try and put a
    stop to illicit copies of GT Power floating around.


o   26.   GT Power is now DESQview(tm) aware.  Every attempt is made to give
    up spare time to DV, so that other windows do not suffer when GT Power is
    idle.  Also, GT Power will write directly to the DV shadow video buffer.
    This greatly speeds video output under DV.  If you are using DV with this
    version of GT Power, set GT Power's BIOS video option to FALSE - this will
    allow GT Power to write directly to DV.  Then you must configure DV's
    window running GT, so that DV understands that GT won't write directly to
    the screen.  Also, you should tell DV to virtualize the screen output.
    Otherwise bleed through may occur.  It is working great on my 386sx with
    DV 2.26 and QEMM 386.
==============================================================================

Regards,
Paul
