home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Crawly Crypt Collection 1
/
crawlyvol1.bin
/
bbs
/
mkill203
/
update.doc
< prev
Wrap
Text File
|
1993-08-31
|
5KB
|
120 lines
*** ** Maxi*Kill Update History
** *** by Erik Williams {SunFox Productions, Ltd.}
*** ** Raleigh, North Carolina
** *** (c) Copyright, 1993. All rights reserved.
Versions 1.00 => 1.20
---------------------
Feature: Descriptor tag/path pairs used to designate files for
killing. This was crude, but it did the job.
Version 2.00 (3/4/93)
---------------------
Partition crash killed all sources for Maxi*KILL versions 1.20 and
below. 2.00 is a complete rewrite of Maxi*KILL with many new
features.
Feature: BinkleyTerm-style logging support with user-selectable
verbosity.
Feature: The configuration file is relatively free-format...the
spacing really doesn't matter. The order of keywords
doesn't really matter, either, but the order of parameters
and the case of certain keywords *DOES* matter. This is a
big change over the old versions...my configuration files
used to be very restrictive as to placement (it goes to
show you what a few classes in parser theory will do for
your programming style!).
Feature: Global kill definitions that would kill specified files
from the path no matter when Maxi*KILL would run. This is
analogous to the old method of operation in versions 1.20
and below. Limit of 50 global kill definitions.
Feature: Events for timing the killing of files. Only one Kill per
Event and one day specification allowed in the Event. You
could specify that an Event could run on all days using the
"All" date keyword, but a construct such as "Mon|Wed|Fri"
was not possible. Limit of 50 events.
Version 2.01 (3/10/93)
----------------------
Feature: 50 Kills per Event now allowed. This raises the total
amount of kill specifications possible to 2,550!
Feature: LogMaint introduced to allow user to specify when the
log would be reinitialised. LogMaint was used with the
same rules as the Event directives in regard to dates and
times of LogMaint.
Feature: Another LogLevel introduced...LogLevel 4 includes everything
from LogLevel 3 and below plus a dump of the LogMaint
settings.
Version 2.02 (3/24/93)
----------------------
Buglet: I had forgotten to change the version number in the last
line that gets dumped to the log file. Ooops.
Feature: Multiple day specifications now allowed in Event and
LogMaint. Essentially, you can now specify multiple days
for the event to run (other than All). For example, a
date specification in an Event (or LogMaint) of "Mon|Wed"
means that the event (or log maintenance) will be executed
on Mondays and Wednesdays only. You can pipe any of the
keywords together, but you are limited to 45 characters in
your specification. The first "All" that is parsed will
set all of the days and anything else after the "All" will
have no effect.
Feature: Two new Event date keywords added: "Week" and "WeekEnd".
They should be obvious...Week will allow the Event to run
on Monday->Friday while WeekEnd allows the Event to run
on Saturday and Sunday only.
Optimisation: I made the date comparison routines much easier to
read and use. I now use an unsigned integer with the
last seven bit positions representing the days of the
week. When parsing an Event (or LogMaint) date, I
just set the appropriate bit positions to 1 with a
bitwise inclusive-OR. When comparing an Event date
to the system date, all I do is a bitwise AND between
those two dates. If I get a zero, we have a date
mismatch (as all bits are turned off by the AND).
Anything else is a match. This really made multiple
day processing and date comparisons a breeze.
Version 2.03<beta> (8/31/93)
----------------------
Feature
Removed: Global Kills have gone the way of the dodo. By changing
to a linked-list structure, they really don't have a place
anymore. If you wish a global kill event, use a definition
like: Event All 00:00:00 23:59:59. It will run at all times
possible.
Optimisation: I have changed Maxi*KILL to a linked-list configuration
structure which is much more memory efficient. You are
now only limited by the amount of memory in your machine.
I also revamped the configuration parser that's based on
strtok(), so MAXIKILL.CFG can pretty much be spaced as
you wish.
------------
Future Plans
------------
A GEM-based shell for configuring and running Maxi*KILL. If you have
seen AutoShell by Ben Van Bokkem, this is what I'm thinking about.
Anyone who has GEM code that runs under TurboC/PureC and uses
resources that wants to send them along will speed up the process.
GEM is not very easy to begin with, but the lack of documentation
really stinks. :)