home *** CD-ROM | disk | FTP | other *** search
/ Frostbyte's 1980s DOS Shareware Collection / floppyshareware.zip / floppyshareware / GLEN / GT1700_1.ZIP / README.16 < prev    next >
Text File  |  1991-01-07  |  25KB  |  519 lines
  1. 1-7-91
  2. ==============================================================================
  3.                                 GT POWER 16.00
  4. ==============================================================================
  5. o   1.    Custom menus.  For the main menu and the message base submenu.
  6.     It is now possible to hook a door type program, of your choosing, into
  7.     the either the main host mode menu or the message base submenu.  New
  8.     lines have been added to the SYSOP.BBS file to accomodate these custom
  9.     menus.  As follows:
  10.  
  11.         "MENU="
  12.         "MMENU="
  13.  
  14.     The first line, MENU=, is used to define custom items for the main host
  15.     mode menu.  The second line, MMENU=, is used to define custom items for
  16.     the message base submenu.  Here is an example of how it might look:
  17.  
  18.         "MENU=[MR]modread;Z;Enter data:;[ZV]zipview;Z;&"
  19.  
  20.     The letters inside the brackets are used by callers to select the
  21.     custom command, the name following the left bracket is the name of
  22.     the batch file to be executed, followed by the access level required
  23.     to use the command, then a prompt for information to be passed to the
  24.     batch file.  If the prompt begins with '&', then the batch file does
  25.     not overlay GT Power.  This syntax is exactly the same as that used
  26.     below for "MMENU=".
  27.  
  28.     However, the actual interface to the batch file is somewhat different
  29.     from the standard door interface.  The first three parameters, are
  30.     unchanged, as follows:
  31.  
  32.          Param     Description
  33.          -----     -----------
  34.            1       The CTTY or REM.
  35.            2       The COM port number.
  36.            3       The prompted for data.
  37.  
  38.     The last param, param #3, is optional, of course.  But, for items on the
  39.     MMENU= list, GT Power will automatically add the following two parameters:
  40.  
  41.            4       -Pmsg_path, where "msg_path" is the path to the currently
  42.                    active message base.
  43.  
  44.            5       The number of the previous message read by the caller.
  45.  
  46.     For example, here is what some command lines might look like:
  47.  
  48.          medit CTTY 1 foobar -PC:\GTBBS\MSGB1 103
  49.  
  50.     Where 'medit' is the name you have assigned to the batch file, CTTY is
  51.     the signal that a remote caller is using the system, 1 is the COM port
  52.     number, 'foobar' is the data entered by the caller when prompted,
  53.     '-PC:\GTBBS\MSG1' is the pathname of the current message base with a
  54.     '-P' stuck in front of it, and 103 is the message number last read by
  55.     the caller in that area.
  56.  
  57.     Please notice that 'foobar' is optional, if it is not needed, then the
  58.     rest of the command line would be slid over.  The message path would
  59.     become param #3 and the message number would become param #4.
  60.  
  61.  
  62. o   2.    For LAN users, the maximum number of pids has been raised from 10
  63.     to 32.  YOU MUST DELETE the old PID_FILE.BBS prior to running the new
  64.     version.  The format of the PID_FILE.BBS has changed - the CB Handle has
  65.     been added to it, and the record length has been increased by 64 bytes.
  66.  
  67.     In addition, the CB Simulator has been upgraded.  The @who command now
  68.     uses the PID_FILE.BBS for its input, so it is more reliable and contains
  69.     more information.  A new screen has also been added to the CB Simulator,
  70.     GTGREET.BBS, which will be displayed to the caller after entering the
  71.     CB Handle.  And an automatic @who command is executed, so that the caller
  72.     will not wonder if anyone is available for a chat.  The CBGREET.BBS file
  73.     should be short and to the point, i.e. introduce the automatic @who list
  74.     and tell the caller to use '?' for help.
  75.  
  76.  
  77. o   3.    Many people have asked for a more structured approach to bulletins.
  78.     It is now available.  First, only numeric bullets are used.  If a number
  79.     is shown or entered with a '.' contained within it, then the '.' is
  80.     removed and ignored - it is just a noise character.  Therefore, 1.0 would
  81.     be equal to 10, 1.2.0 would be equal to 120, etc.  The GTBMENU.BBS file
  82.     is stored either in the GTPATH or the BBS/CBS directory, the numbered
  83.     bulletins are still stored in the "Default File Directory".  Any of the
  84.     numbered bullets may be menus, i.e. GT will not automatically return to
  85.     GTBMENU.BBS when they have finished being viewed, thus a new letter
  86.     command is required, (M) for return to the (M)ain Bulletin Menu
  87.     (GTBMENU.BBS to be exact).  Each numbered bullet file that is actually a
  88.     submenu file should begin with a line that contains only ";BMENU", in
  89.     uppercase.  GT Power stacks these submenus internally, so it is possible
  90.     to pop back to the previous menu, the new letter command (P)revious Menu
  91.     has been added to allow this to occur.  The stacking of bullet menus does
  92.     have a limit - not counting the main bullet menu, you may stack up to 5
  93.     levels deep.  If you exceed 5 levels, it will continue to work, but the
  94.     (P)revious Menu command may stop functioning, as it can no longer track
  95.     the extra bullet menus.
  96.  
  97.     For example:
  98.  
  99.     In file GTBMENU.BBS:
  100.  
  101.                     1.0   General bulletins
  102.                     1.1   Game bulletins
  103.                     1.3   Network bulletins
  104.                     1.4   Political bulletins
  105.  
  106.  
  107.     In file 10 (point 1.0):
  108.  
  109.           ;BMENU
  110.  
  111.                     1.0.0   Rules of the board
  112.                     1.0.1   How to get more time
  113.                     1.0.2   How to get better access
  114.  
  115.  
  116.     In file 100 (point 1.0.0):
  117.  
  118.                     There is only 1 rule on this board:
  119.  
  120.                             Do not use profanity
  121.  
  122.  
  123.     In file 101 (point 1.0.1):
  124.  
  125.                     You can get more time by reading the bulletins
  126.                     and participating in the message bases.
  127.  
  128.  
  129.     In file 102 (point 1.0.2):
  130.  
  131.                     If you want to download alot of files, you can get
  132.                     better access by uploading files that are of value
  133.                     to this board.
  134.  
  135.  
  136.     Please note, each of the points shown above is a separate numbered file
  137.     in the "Default File Section".
  138.  
  139.     I hope you get the idea and that it is not necessary for me to carry
  140.     on with the hierarchy for 1.1, 1.2 and 1.3.  It would be pretty much
  141.     the same sort of stuff.  Once you see how it is done, you should be
  142.     able to do it easily for other bullets.
  143.  
  144.  
  145. o   4.    A new internal protocol - Ymodem-G.  It is very fast.  But a
  146.     single error will ruin the transfer.  This protocol has no error
  147.     correction.  Although it can detect errors, via a CRC mechanism,
  148.     use only with MNP modems, for best results.  Produces very good
  149.     results with the new ultra high speed modems.  This protocol preserves
  150.     exact file date, time and size; and is a batch protocol.
  151.  
  152.  
  153. o   5.    The file transfer status windows have been spruced up a bit.
  154.     Some new fields have been added, in additon a bar graph of the transfers
  155.     progress has been added.  The new fields are a dynamic display of the
  156.     CPS rate and the estimated time to complete the file transfer.
  157.  
  158.  
  159. o   6.    Bugs in MegaLink have been fixed.  These bugs are of long standing,
  160.     and often caused file transfers to hang - especially when buffered modems
  161.     were employed.  While fixing the bugs, I have also streamlined the error
  162.     correction mechanics so that it is much faster than previously.  Overall,
  163.     the protocol is the same speed as before, on clean lines.  But it should
  164.     be faster, now, on dirty lines.
  165.  
  166.  
  167. o   7.    Ymodem Batch now preserves the file date, time and size.  This
  168.     information is now passed using the standard Ymodem header block.  This
  169.     same header block is also used by the new Ymodem-G protocol.
  170.  
  171.  
  172. o   8.    The minimum length of passwords required by the host mode is now
  173.     configurable.  It may be set anywhere from 0 to 9 characters in length.
  174.     This is done by actually changing the prompt to the caller which appears
  175.     in SYSOP.BBS.  As follows:
  176.  
  177.          "Password is too short[!]  Must be [4] - [20] characters."
  178.  
  179.     This line appears in the SYSOP.BBS file on line 158 (I think).  It
  180.     specifies that the password must be at least 4 characters long.  If
  181.     you change it to this:
  182.  
  183.          "Password is too short[!]  Must be [6] - [20] characters."
  184.  
  185.     Then new callers must supply at least 6 characters in their personal
  186.     password.  This may not be set above the single digit level.  Permissible
  187.     values are '0' through '9'.  '0' meaning that there is no limitation.
  188.  
  189.  
  190. o   9.    Many have asked for an expansion of the result code table to
  191.     accomodate new modem models.  This is a real "Catch-22" situation.
  192.     Rather than add new entries to the result code table, I have taken
  193.     the following steps:
  194.  
  195.             a)  The entries in the result code table have been widened
  196.                 to approximately 50 characters.  About as wide as the
  197.                 screen will allow.
  198.  
  199.             b)  "Smart Result Code" handling has been implemented.  GT Power
  200.                 is now be able to recognize various CONNECT results
  201.                 that are not in the table, but the modem must be setup
  202.                 to return "verbose" result codes.
  203.  
  204.                 GT Power will look for the word CONNECT, followed by a number,
  205.                 followed by some sort of code word.  If this sequence is
  206.                 found, then GT Power will be able to recognize it and make
  207.                 sense out of it.  The presence of the code word will be
  208.                 taken to mean that some form of error correction is being
  209.                 used by the modem.
  210.  
  211.  
  212. o   10.    Due to the addition of "Smart Result Code" handling, an addition
  213.     has been made to the baud rate setup window under Alt-I.  This window
  214.     now allows the sysop to specify the minimum host baud rate that is
  215.     acceptable.  The caller will receive a message informing him/her of
  216.     the reason for the disconnect and this occurence will also be logged.
  217.     See the new entries for this purpose at the end of the SYSOP.BBS file.
  218.  
  219.  
  220. o   11.    When a caller asks to download a file, GT Power will now be able
  221.     to supply default extensions.  The extensions to be used for the default
  222.     are supplied by the sysop in the SYSOP.BBS file.  As shown by the entry
  223.     below:
  224.  
  225.             ".ZIP .LZH .ARC"
  226.  
  227.     This line appears near the end of the SYSOP.BBS file.  As with the
  228.     "MENU=" line, this line follows very strict and regular rules.  A single
  229.     space seperates each entry on the line, each entry is given with a leading
  230.     '.' and in UPPERCASE.  20 extensions may be specified, but it is doubtful
  231.     whether it is desirable to specify more than 4 or 5.  The delay in the
  232.     seach required would become a burden, if too many are specified.
  233.  
  234.     To activate the default, the caller must ask for the file without any
  235.     extension, like this:
  236.  
  237.             d;z;foobar
  238.  
  239.     Which would cause GT Power to look for "foobar.zip", "foobar.lzh" and
  240.     "foobar.arc" (assuming the default entry in SYSOP.BBS, shown above).
  241.  
  242.     Or the caller might specify it like this:
  243.  
  244.             d;z;foobar.*
  245.  
  246.     Which would have the exact same result.
  247.  
  248.     However, if the caller specified it in the following manner, then the
  249.     default extensions would not be scanned:
  250.  
  251.             d;z;foobar.
  252.  
  253.     The usage of the period, or of any extension explicitly, will stop
  254.     GT Power from searching through the default extensions.
  255.  
  256.  
  257. o   12.    The CIS "B" protocol has been dropped back to a regular external
  258.     protocol status.  Because of this, there was room made available to
  259.     expand the external protocol table to 16.  No big deal.  But a step in
  260.     the right direction <grin>.
  261.  
  262.     The main reason for moving CIS "B" to a regular external status was to
  263.     allow for an easier transition to newer CIS protocols, like the QuickB
  264.     protocol, and to make the [C] menu character available to those that
  265.     wish to use it for other protocols, such as Cmodem.
  266.  
  267.  
  268. o   13.   Many have asked for a "frontend" type interface for usage with
  269.     GT Power.  I have long resisted it.  But it is now available.  If you
  270.     wish to use a frontend program with GT Power, you must setup things so
  271.     that GT Power is invoked with the following new command line option:
  272.  
  273.             /F:nnnnn:m
  274.  
  275.     If you wish to disable the dropping of DTR by GT Power, you should use
  276.     the /D option, in addition.
  277.  
  278.     The 'nnnnn' is the DCE baud rate that the incoming call is at. And the
  279.     'm' is the port number that the call is coming in on.
  280.  
  281.     For example:        /F:%1:%2 /D
  282.  
  283.     Assuming that the frontend program passed the baud rate as %1 and the
  284.     COM port and %2, and you wanted to disable the DTR drop in GT Power.
  285.     DOS might expand this to something like this:
  286.  
  287.                         /F:2400:1
  288.  
  289.     Assuming that the call was at 2400 baud on COM1:.
  290.  
  291.     When the caller logs off the system (or drops carrier), GT Power will
  292.     execute a exit to DOS with an ERRORLEVEL 254.  When used with a frontend,
  293.     GT Power will never need to perform the "quit 255", since it always
  294.     returns control to the frontend program via the ERRORLEVEL 254 exit.
  295.     You should make sure that the batch file traps this ERRORLEVEL as required
  296.     and returns control to the frontend program.  See the documentation that
  297.     comes with the frontend program for further details.
  298.  
  299.     You should configure the frontend program to handle GT CRASH mail, set it
  300.     up so that it looks for the "CQCQ" stream of characters, and then invokes
  301.     the GTCRASH.BAT file, as required by the MDRIVER program.
  302.  
  303.  
  304. o   14.   Uploads are now labeled with the name of the uploader.  For
  305.     example, the first line of the description in the FILES.BBS will now
  306.     show "from: John Doe" on the right side (after the dates).
  307.  
  308.  
  309. o   15.   The message base structure has been altered considerably.  The
  310.     internal structure of the MESSAGE.CTL and USER_MSG.CTL files has been
  311.     altered and enhanced to include new fields - and some fields, not in
  312.     current usage, have been removed.  All 3rd party authors that wish to
  313.     upgrade their software to work with 16.00, should review these changes
  314.     very carefully.  There is an archive of source code for the utilities
  315.     I have written to support the new formats.  Please avail yourself of
  316.     this source code for a more detailed explanation.
  317.  
  318.  
  319. o   16.   The messages themselves have been placed into consolidated files.
  320.     Each consolidated file can contain up to 10 messages.  The consolidated
  321.     files are named as follows:
  322.  
  323.               00001.MES   Contains messages  #1 through #10.
  324.               00002.MES   Contains messages #11 through #20.
  325.               ...etc...
  326.  
  327.     The messages are stored in plain ASCII text format, and contain the same
  328.     information as the previous .MSG files.  Each message has a header record
  329.     to mark the beginning of the message.  The format of the header record is:
  330.  
  331.               Col 1  =  Ctrl-X
  332.                 2-4  =  'SOM'
  333.                   5  =  '0' thru '9', depending on the relative position
  334.                         of the message within the file.
  335.  
  336.     Within 00001.MES, message #2 would have a header of ^XSOM1, where ^X is
  337.     the symbol for Ctrl-X.  In 00002.MES, message #12 would have a header of
  338.     ^XSOM1 --- the same as message #2 in 00001.MES.  This scheme allows for
  339.     the possibility of a "rapid" renumbering.  That is, the internal numbers
  340.     on the header records are relative, not absolute.  Changing the name of
  341.     the file, i.e. from 00002.MES to 00001.MES, automatically changes the
  342.     message numbers assigned to the messages contained within.
  343.  
  344.     Two programs are included that handle the conversion between the two
  345.     formats:
  346.  
  347.           MSGCVT ----- Convert from old MSG format to the new MES format.
  348.           R_MSGCVT --- Convert from new MES format to the old MSG format.
  349.  
  350.     The R_MSGCVT program is provided in case the worst happens, i.e. you need
  351.     to return to the release version of 15.50.  Hopefully, it will not be
  352.     required (or at least that any reverse migration will be voluntary <grin>).
  353.  
  354.     The change to the new format has two benefits:
  355.  
  356.     1.  Fewer message files are present, thus allowing DOS to operate
  357.         more efficiently with a large number of messages.
  358.  
  359.     2.  Disk space is more efficiently used.  On my system, with about
  360.         a dozen message bases, which have an average of 200 messages,
  361.         I was able to save over 2 megabytes of disk space as a result
  362.         of converting to the new format.
  363.  
  364.     The change to the new format has two drawbacks, that I am aware of:
  365.  
  366.     1.  The use of "text threads" is somewhat slower.
  367.  
  368.     2.  The (K)ill message command is very much slower.  But it is not
  369.         often used by callers - mostly Sysops.
  370.  
  371.     The source code for the following programs is available:
  372.  
  373.                           MSGCVT
  374.                           R_MSGCVT
  375.                           SYSOP
  376.                           DELREN
  377.  
  378.     These programs handle the new message and user file formats.  The SYSOP
  379.     program is menu driven and pretty much self explanatory.  The DELREN
  380.     program is a batch file utility for deleting messages and renumbering
  381.     same.  You can get a usage report by entering DELREN without any options.
  382.  
  383.  
  384. o   17.   Univeral download has been implemented.  This means that you can
  385.     download any file (to which you are entitled) from any file area, without
  386.     being *in* the right file area.
  387.  
  388.     This new feature works with an *optional* file database.  The program
  389.     FILES_DB has been included to allow you to build a file database.  If
  390.     a file database exists, then 16.00 can rapidly locate it thru the file
  391.     database (be sure to rebuild the database if you move files around).
  392.     Each time the FILES_DB program is run, it scans the FILES.BBS files in
  393.     the directories pointed to by the current GTDIR.BBS and builds a new
  394.     FILES.CTL and .IDX from that information.  If you have multiple GTDIR.BBS
  395.     files, then this process may not be possible (for security reasons).
  396.  
  397.     If you do not have a files database, you can still use the universal
  398.     download feature, but it will run slower, as GT Power will individually
  399.     scan each directory while the caller is online.  This is not too bad, and
  400.     is done automatically, as long as there are not a very large number of
  401.     files online.  Naturally, security is completely enforced, as before.
  402.  
  403.     One impact of this new method is that complete pathnames are now passed
  404.     to external protocols.  As you can imagine, the command line (max 128
  405.     bytes) can be overflowed very quickly.  To get around this problem, many
  406.     protocols accept a command line parameter to use a list file, instead of
  407.     having the files listed on the command line.  Usually, the format for
  408.     this is "@C:filename".  Where the "filename" may include a path.  For
  409.     example:
  410.  
  411.          dsz port %1 speed %2 handshake both sz @C:/gt/gt_xmit.lst
  412.  
  413.     This is my current ZMTX.BAT file.  DSZ is able to handle '/'s in the
  414.     pathname, due to its UNIX heritage.  Other protocols may not like them,
  415.     in which case '\' would be more appropriate.  In any case, GT Power now
  416.     creates the file GT_XMIT.LST in the GTPATH directory for usage with
  417.     external protocols.  I believe Superk also supports this syntax, although
  418.     I am not sure of the details.  Apparantly PCKermit does not support this
  419.     type of list transfer.  Protocols that do not support this "list transfer"
  420.     mechanism will be limited to transfering the number of files that can
  421.     be fully specified on the command line (so, it would be good if you used
  422.     short sub-directory names <grin>).
  423.  
  424.     The FILES_DB is now used to help eliminate duplicate uploads.  The
  425.     database is checked for each name before the upload is allowed to
  426.     proceed.
  427.  
  428.  
  429. o   18.   New lines have been added to the GT.WIN and SYSOP.BBS file to
  430.     accomodate the new features.  The new lines in the SYSOP.BBS are at the
  431.     end of the file.  The final line in the SYSOP.BBS file is not a text
  432.     line, it is a marker, so that GT Power can tell that the proper number
  433.     of lines are in the file (no more and no less).  The line starts with
  434.     the word "END" in upper case letters.  No other line may start with
  435.     the word "END".  The word "END" is followed by 1 blank then the line
  436.     count for the file.  This should not change, and it should remain on
  437.     the same line, no matter what other change may be made to the file.
  438.  
  439.  
  440. o   19.   When a new caller logs onto the host mode, GT Power will now
  441.     try to confirm that his name has been entered correctly.  The program
  442.     will prompt the caller in this manner:
  443.  
  444.          Your name could not be located in the user file of this system.
  445.  
  446.          Was your name entered correctly?  [y/N]
  447.  
  448.     The caller will get two tries at this message, if the caller answers 'N'
  449.     then GT Power will ask for his name again.  If it is still not found in
  450.     the user file, the program will come back to this prompt.  If the caller
  451.     again answers 'N', then GT Power will stop playing the game and drop the
  452.     caller offline.
  453.  
  454.     If the caller answer 'y', then GT Power will prompt the caller for the
  455.     normal new caller information.
  456.  
  457.  
  458. o   20.   Incremental time limit adjustment is now possible.  Using the hot
  459.     keys ALT- and ALT+.  As follows:
  460.  
  461.                 ALT- .... Decrement the caller's time limit.
  462.                 ALT+ .... Increment the caller's time limit.
  463.  
  464.     The amount of the time change is specified in the line at the SYSOP.BBS
  465.     file that says something like this:
  466.  
  467.     "\n\n5 min. increment\nOld time limit = %3d min.\nNew time limit = %3d min.\n"
  468.  
  469.     The number that appears after the "\n\n" is the increment in minutes.
  470.  
  471.  
  472. o   21.   The screen length is now configurable on an individual caller basis.
  473.     When a new caller logs onto the system, it will ask how long his screen
  474.     is.  The permissible values are 7-999 lines.  Values outside of that range
  475.     will be assumed to be 24, the default.  This may also be changed by the
  476.     caller when he selects the (Y) option from the main menu.
  477.  
  478. o   22.   A new host mode screen variable is available for usage with
  479.     ^U lines.  It is 'G' and will display the current setting for the
  480.     screen length.  Here is a example:
  481.  
  482.     ^U"Screen Length = "G" lines."
  483.  
  484.     Of course, the sysop would actually embed a real Ctrl-U character
  485.     instead of ^U, which is just the symbolic representation of Ctrl-U.
  486.     The caller would see this as the result:
  487.  
  488.     Screen Length = 24 lines.
  489.  
  490.  
  491. o   23.   EGA/VGA 43/50 line mode is now supported.  A toggle for this mode
  492.     has been added to the Misc. Options screen under Alt-I, #30.  Things like
  493.     the phone directory and view file commands have been ehanced to support
  494.     the longer screen lengths.
  495.  
  496.  
  497. o   24.   The name of the previous caller to the host mode is now displayed
  498.     on the screen while waiting for the next caller.  This information, the
  499.     name of the previous caller, has been added to the UPSINCE.BBS file.
  500.     So, if you take host mode down, the name of the previous caller is lost.
  501.  
  502.  
  503. o   25.   The S/N is now displayed by the program when the user selects the
  504.     (V) option from the main menu.  The purpose of this is to try and put a
  505.     stop to illicit copies of GT Power floating around.
  506.  
  507.  
  508. o   26.   GT Power is now DESQview(tm) aware.  Every attempt is made to give
  509.     up spare time to DV, so that other windows do not suffer when GT Power is
  510.     idle.  Also, GT Power will write directly to the DV shadow video buffer.
  511.     This greatly speeds video output under DV.  If you are using DV with this
  512.     version of GT Power, set GT Power's BIOS video option to FALSE - this will
  513.     allow GT Power to write directly to DV.  Then you must configure DV's
  514.     window running GT, so that DV understands that GT won't write directly to
  515.     the screen.  Also, you should tell DV to virtualize the screen output.
  516.     Otherwise bleed through may occur.  It is working great on my 386sx with
  517.     DV 2.26 and QEMM 386.
  518. ==============================================================================
  519.