home *** CD-ROM | disk | FTP | other *** search
/ Crawly Crypt Collection 1 / crawlyvol1.bin / bbs / mkill203 / update.doc < prev   
Text File  |  1993-08-31  |  5KB  |  120 lines
  1. ***  **  Maxi*Kill Update History
  2. **  ***  by Erik Williams {SunFox Productions, Ltd.}
  3. ***  **  Raleigh, North Carolina
  4. **  ***  (c) Copyright, 1993.  All rights reserved.
  5.  
  6. Versions 1.00 => 1.20
  7. ---------------------
  8.  
  9. Feature:  Descriptor tag/path pairs used to designate files for
  10.           killing.  This was crude, but it did the job.
  11.  
  12. Version 2.00 (3/4/93)
  13. ---------------------
  14.  
  15. Partition crash killed all sources for Maxi*KILL versions 1.20 and
  16. below.  2.00 is a complete rewrite of Maxi*KILL with many new
  17. features.
  18.  
  19. Feature:  BinkleyTerm-style logging support with user-selectable
  20.           verbosity.
  21.  
  22. Feature:  The configuration file is relatively free-format...the
  23.           spacing really doesn't matter.  The order of keywords
  24.           doesn't really matter, either, but the order of parameters
  25.           and the case of certain keywords *DOES* matter.  This is a
  26.           big change over the old versions...my configuration files
  27.           used to be very restrictive as to placement (it goes to
  28.           show you what a few classes in parser theory will do for
  29.           your programming style!).
  30.  
  31. Feature:  Global kill definitions that would kill specified files
  32.           from the path no matter when Maxi*KILL would run.  This is
  33.           analogous to the old method of operation in versions 1.20
  34.           and below.  Limit of 50 global kill definitions.
  35.  
  36. Feature:  Events for timing the killing of files.  Only one Kill per
  37.           Event and one day specification allowed in the Event.  You
  38.           could specify that an Event could run on all days using the
  39.           "All" date keyword, but a construct such as "Mon|Wed|Fri"
  40.           was not possible.  Limit of 50 events.
  41.  
  42. Version 2.01 (3/10/93)
  43. ----------------------
  44.  
  45. Feature:  50 Kills per Event now allowed.  This raises the total
  46.           amount of kill specifications possible to 2,550!
  47.  
  48. Feature:  LogMaint introduced to allow user to specify when the
  49.           log would be reinitialised.  LogMaint was used with the
  50.           same rules as the Event directives in regard to dates and
  51.           times of LogMaint.
  52.  
  53. Feature:  Another LogLevel introduced...LogLevel 4 includes everything
  54.           from LogLevel 3 and below plus a dump of the LogMaint
  55.           settings.
  56.  
  57. Version 2.02 (3/24/93)
  58. ----------------------
  59.  
  60. Buglet:   I had forgotten to change the version number in the last
  61.           line that gets dumped to the log file.  Ooops.
  62.  
  63. Feature:  Multiple day specifications now allowed in Event and
  64.           LogMaint.  Essentially, you can now specify multiple days
  65.           for the event to run (other than All).  For example, a 
  66.           date specification in an Event (or LogMaint) of "Mon|Wed"
  67.           means that the event (or log maintenance) will be executed
  68.           on Mondays and Wednesdays only.  You can pipe any of the
  69.           keywords together, but you are limited to 45 characters in
  70.           your specification.  The first "All" that is parsed will
  71.           set all of the days and anything else after the "All" will
  72.           have no effect.
  73.  
  74. Feature:  Two new Event date keywords added:  "Week" and "WeekEnd".
  75.           They should be obvious...Week will allow the Event to run
  76.           on Monday->Friday while WeekEnd allows the Event to run
  77.           on Saturday and Sunday only.
  78.  
  79. Optimisation:  I made the date comparison routines much easier to
  80.                read and use.  I now use an unsigned integer with the
  81.                last seven bit positions representing the days of the
  82.                week.  When parsing an Event (or LogMaint) date, I
  83.                just set the appropriate bit positions to 1 with a
  84.                bitwise inclusive-OR.  When comparing an Event date
  85.                to the system date, all I do is a bitwise AND between
  86.                those two dates.  If I get a zero, we have a date
  87.                mismatch (as all bits are turned off by the AND).
  88.                Anything else is a match.  This really made multiple
  89.                day processing and date comparisons a breeze.
  90.  
  91. Version 2.03<beta> (8/31/93)
  92. ----------------------
  93.  
  94. Feature
  95. Removed:  Global Kills have gone the way of the dodo.  By changing
  96.           to a linked-list structure, they really don't have a place
  97.           anymore.  If you wish a global kill event, use a definition
  98.           like:  Event All 00:00:00 23:59:59.  It will run at all times
  99.           possible.
  100.  
  101. Optimisation:  I have changed Maxi*KILL to a linked-list configuration
  102.                structure which is much more memory efficient.  You are
  103.                now only limited by the amount of memory in your machine.
  104.                I also revamped the configuration parser that's based on
  105.                strtok(), so MAXIKILL.CFG can pretty much be spaced as
  106.                you wish.
  107.  
  108. ------------
  109. Future Plans
  110. ------------
  111.  
  112. A GEM-based shell for configuring and running Maxi*KILL.  If you have
  113. seen AutoShell by Ben Van Bokkem, this is what I'm thinking about.
  114.  
  115. Anyone who has GEM code that runs under TurboC/PureC and uses
  116. resources that wants to send them along will speed up the process.
  117.  
  118. GEM is not very easy to begin with, but the lack of documentation
  119. really stinks.  :)
  120.