CheckFiles Version 1.7
by Ron V. Webber
Release date: August 31, 1999
Last modification date of documentation: August 30,1999
http://www.lightlink.com/ym
ym@lightlink.com
stochastic@kagi.com
Copyright 1999, Stochastic Systems

What is CheckFiles?

CheckFiles is a program that keeps track of the name, time, date,
size, and checksum of every file in every path that you select (which
could be every path on your hard drive).  You can select paths either
recursively (where selecting "C:\" will select every path on partition
C) or non-recursively (where selecting "C:\" will only select the root
path of partition C).  On subsequent runs CheckFiles will update its
information and tell you what has been added, changed, or deleted
since the last run.  It will also tell you if any files have been
corrupted.  If a file has a different time, date, or size, it will be
listed as having been changed, and a new checksum will be calculated
and stored.  For every file that has not changed time, date, or size,
the current checksum will be calculated and compared with the old
checksum.  If these are different, the file will be listed as bad.
The old checksum on a bad file will be kept so that you can check the
file again later once you have fixed it.  (One of the advanced options
allows you to store the new checksum on "bad" files so that on the
next run the file will be listed as "good".  Some programs, such as a
well known spreadsheet program from a large software company, will
modify files that you look at, even if you don't change anything, and
this can cause false "bad" indications.  With the "bad" update option
turned off, these files would continue to be listed as "bad" on every
subsequent run because CheckFiles is comparing them to the original
checksum.  With this option turned on, the file will only be listed as
"bad" if it has been opened by the spreadsheet program since the last
run of CheckFiles.)

CheckFiles can store the information about every file in two different
ways: The "One File" method stores all the information in one main
file, named CHKFILES.ALL, which is stored in the same path as the
CheckFiles program.  The "Every Path" method stores the information
for each individual path in that path in a file named CHKFILES.CHK.
If you choose to use individual CHKFILES.CHK files for each path, the
information remains valid even if you move it and all the files to
another path, but you won't be able to tell if an entire path has been
deleted since the CHKFILES.CHK file for that path would have been
deleted as well.  If you choose to use one CHKFILES.ALL file, then you
will be able to tell when paths have been deleted, but if all the
files in a path are moved to a different path they won't be checked.
(They would be listed twice: Once as having been deleted from their
original path and once as being new files in their new path.) The
"Every Path" method is good if you want to check files that are going
to be moved to a new partition and you want to make sure they got
there without any corruption.  The "One File" method is good if you
want to have one file that you can copy to a safe location and use
later to check on any corruption.  You can also use the "One File"
method to check files on a device such as a CD-ROM.

The CHKFILES.CHK and CHKFILES.ALL files are in pure ASCII format, so
you can print or edit them or use them for other purposes.  They also
compress quite nicely, which is especially good if you want to store
the CHKFILES.ALL file offline somewhere.  Starting with version 1.5,
the file format has been changed slightly to make the files easier to
import into spreadsheet programs.  Tabs have been used to separate the
fields on each line, and a header line has been added that CheckFiles
uses to determine the format of the file.  Files in the older format
are automatically converted to the new format when you run CheckFiles.
Older versions of CheckFiles can not read the new format.

==========================================

What's New in this version?

Version 1.7 adds the following features which are usable even on the
unregistered version:

On the final output screen, you can click on the label for each of the
output windows and make that window expand to full size.  While a
window is full size, if you click on the label for a different window,
this new window will expand to full size.  If you click on the label
of the window that is already expanded, it will shrink down so you can
see all of the windows again.

In the "Advanced Options" section, there is a new option to save the
checksums for "Bad" files so that they will check "Good" on subsequent
runs.

Version 1.7 adds the following new features that are only available to
registered users:

In the "Advanced Options" section, there is a new option to append the
statistics from the final screen into a log file.  The log file will
be called "CHKFILES.LOG" (unless you are using an alternate base name
for all output files, in which case it will use your alternate base
name with the extension "LOG").  This file will be created if it
doesn't already exist.  If it already exists, the new information will
be appended to any existing information.  The statistics will be the
same as those that appear on the final screen, such as the amount of
time taken, number of bytes checked, number of files, etc..  The log
file will also contain the date and time that the checking finished.
(If you want to determine when the checking started, you will have to
subtract the total time from the finished time.)  The date is stored
as yyyy.mm.dd and the time is stored as hh:mm:ss in 24 hour format.

A second command line option is now used.  If the second command line
parameter is "-a", then the program will automatically start running,
without giving you a chance to change the paths to be checked.  When
checking is done, the program will automatically terminate and close,
without giving you a chance to read the final output screen.  To use
this option, you will have to have had a path list already set, and it
would be best if you also used the logging and output file options (in
the Advanced Options window) so that you can see what happened.  This
option is mainly useful for automatically running CheckFiles at night
using a task scheduler.  Since the "-a" option must be the second
parameter, you must use the first parameter as well.  As documented
later, the first parameter (introduced in version 1.6) gives a new
base file name to be used for all of the output files.  If no new file
name is given, the name "CHKFILES" is used.  Therefore, if you want to
use the autorun option without changing the base file name, you will
have to use a command line with "CHKFILES" as the first parameter and
"-a" as the second parameter.  One way of using the command line
parameters is to create a shortcut to the CHKFILES.EXE program and
then edit the shortcut to add the command line parameters.

For information about other features added in previous versions, see
the last section of this document.

==========================================

Who can use CheckFiles?

CheckFiles is available in two forms: the freely distributable
shareware version and the commercial version.

The shareware version is licensed for individual evaluation.
Individuals may use CheckFiles for evaluation on their personal
computers.  If they keep using it, they are expected to pay for it.
(See the final section, "How do I pay for CheckFiles".)

The commercial version is only available directly from Stochastic
Systems and is customized with a special licensing file for each
commercial licensee.  This licensing file also contains the number of
copies you are allowed to use at any one time.  The commercial version
does not work without the licensing file.  The commercial version
states on the main screen the name of the licensee (usually a company
or institution or a specific department) along with the number of
licensed copies.  Special "commercial only" features may exist.
Contact Stochastic Systems for commercial licensing information.  

Business, Commercial, Educational, Institutional, Corporate, or
Government use of the shareware version of CheckFiles is not allowed.
Contact Stochastic Systems for more information about the commercial
version.  Vendors of shareware programs may include the shareware
version of the CHKFILES.EXE program, this text file, and the
registration program as a shareware package being distributed.  This
means that you can include the CheckFiles shareware package on a disk
of other shareware that you are selling, but you can not use the
shareware version of CheckFiles as a file checking program to check
for corruption in the files on the disk of shareware that you are
selling.  If you received CheckFiles from a shareware distributor, it
was NOT registered by that distributor and you are still expected to
register if you continue to use it.

The commercial version of CheckFiles is licensed to a specific
commercial licensee for their internal use, for use on systems that
they supply to their clients, and for use in software packages that
they supply to their clients.  Individual use is not allowed.
Individuals should get the shareware version of CheckFiles, which is
available from the Stochastic Systems web page
(http://www.lightlink.com/ym/chkfiles) and a number of popular
shareware sites.

Use of the commercial version is restricted to computer systems owned
or provided by the commercial licensee or with software packages
provided by the commercial licensee.  The commercial licensee has paid
a licensing fee for each copy of CheckFiles that they are using.  If
you are a client of the commercial licensee, CheckFiles may only be
used on computer systems that are supplied by the commercial licensee
or with a software package supplied by the commercial licensee.  Use
on other computer systems is not allowed.  Other commercial,
educational, or government use of the specifically licensed version of
CheckFiles is not allowed.  Contact Stochastic Systems if you wish to
include a special version of CheckFiles with some commercial product.
Vendors of shareware programs should obtain the shareware version of
CheckFiles if they wish to include CheckFiles as a shareware package
being distributed.  The commercial version of CheckFiles can not be
distributed as shareware.  The shareware version can be included on a
disk of other shareware that you are selling, but you can not use the
shareware version of CheckFiles as a file checking program to check
for corruption in the files on the disk of shareware that you are
selling.  If you wish to use CheckFiles to check for corruption in
files on a disk of shareware, contact Stochastic Systems for licensing
information.

If you received a commercial version of CheckFiles from some source
other than the licensee shown on the main screen, you may be using an
illegal copy.  Contact Stochastic Systems for information on obtaining
a legal copy for your use.  If you received this version of CheckFiles
from the licensee shown on the main screen, it has already been
registered and you may use it on the computer system supplied to you
by the licensee or with a software package supplied by the licensee.
No further registration fee is required.

CheckFiles is distributed "AS-IS".  No warrantee is expressed or
implied, including fitness for any purpose.  Stochastic Systems will
not be responsible for any damage caused by the use, misuse, or abuse
of CheckFiles.

==========================================

Why should I use CheckFiles?

Do you run your system with VERIFY turned OFF to save time?  When you
do a tape backup, do you leave the auto-compare turned off?  If you
answered yes to these questions, then you probably can't be bothered
with a utility that, if your system is working 100% perfectly, may be
just a waste of time.  BUT...  if you would rather have some peace of
mind, read on!  (Note:  Starting with Windows 95, the verify flag
seems to be ignored - you no longer seem to have the option to verify
all writes to floppy and hard disks.  This makes the system faster,
but less reliable.  This makes CheckFiles even more valuable!  If
anyone knows how to turn the floppy disk verify back on in Windows 98,
please let me know.)

Situation 1a: You have a beautifully designed Summer Solstice Card on
your computer that you use every year during that hurried summer
holiday season.  Sometime in August, after the holidays are over, this
file is corrupted by that game you downloaded, tried once, and then
erased.  Since you won't need Solstice Cards until next June, you
don't notice the corruption.  You do your daily backups, your weekly
backups, and your monthly backups.  Eventually, this corrupted file
gets backed up to all of your tapes.  Next June, when you go to mail
merge your database with your wonderful card, you notice the
corruption.  You search all of your tapes and disks, and all you can
find is the corrupted file.  Too bad you didn't have any way to know
that it had been corrupted before you overwrote all your good backup
copies!  If you had used CheckFiles at least once before the file had
been corrupted, then the first time you used it after the file had
been corrupted it would have warned you about it, in time to retrieve
a good version from your backup tape.

Situation 1b: Instead of being corrupted, the file was somehow
deleted.  CheckFiles, by keeping track of what files are supposed to
be in the directory, would tell you that the file had been deleted the
next time you ran it.

Situation 2a: While you were away from your desk at work, your boss,
needing to write a quick note, used your computer to type in and print
out a message to the accountant about how wonderful your work was.
The file is accidentally stored deep inside the directory that holds
all of your fonts.  (You happened to be working on font editing before
you were called away from your desk, and your boss couldn't be
bothered to change directories before he saved the note.) Without
CheckFiles, you never would have found this note.  With CheckFiles,
you see that one of the new files on your computer is a text file
inside the font directory.  That looks strange, so you look at the
file and learn that now would be a great time to ask for a raise!

Situation 2b: Instead of being a file that you didn't expect to be
there, it is a file that you wrote containing important client
information, but you forgot where you stored it.  By using CheckFiles,
you can get a list of all the new files on your computer and easily
find what you need.

Situation 3: You just downloaded a complex program that will install
all sorts of files all over your system.  By running CheckFiles before
and after installing this program, you can tell exactly what files
this program added, changed, or deleted.  This information will be
very useful when you want to remove this program from your system.

Situation 4: Your brother-in-law is constantly messing with his
computer and then calling you to fix it.  By running CheckFiles on his
computer before he messes with it, you can then run it afterwards to
see just what he has deleted so you can get him up and running much
faster.

==========================================

Which version of CheckFiles should I use?

This release is version 1.7.  It is only available in a 32-bit version
for use with Windows 95, Windows 98, Windows NT (tested on 3.51 and
4.0), and later operating systems.  This version will not run properly
in Windows 3.1 with Win32s.  (It will not run at all without Win32s.)

Starting with version 1.5, the 16-bit version was discontinued.  The
last 16-bit version was 1.4, which was available in both 16-bit and
32-bit versions.  There has been virtually no demand for a 16-bit
version of 1.5 (only one inquiry as to whether or not the current
version worked on Windows 3.1, and no follow up requesting that one be
made available), and so this release and all future releases are only
going to be available in 32-bit versions (at least until there is a
64-bit operating system!).

Starting with version 1.5, the file format was changed slightly.
Files created with version 1.5 or higher will not work with version
1.4 or lower versions of CheckFiles.  When using the "one file"
option, the CHKFILES.ALL file will be updated to the new format the
first time you run the new program, and will then be incompatible with
older versions.  When using the "each path" option, older format
CHKFILES.CHK files will be updated to the new format whenever any of
the information in them is changed (any files are added, deleted, or
changed in the directory), and will then be incompatible with older
versions.  If nothing changes in a directory, the older format
CHKFILES.CHK file will be unmodified.  (This was done so that you
could continue to check older CDs with embedded CHKFILES.CHK files in
them.  If nothing changed on the CD, no attempt would be made to
overwrite the old format CHKFILES.CHK file, so there would be no error
messages.  If anything changed, then the changes would be noted and
there would also be an error message about not being able to write the
new CHKFILES.CHK file to the CD.)  Note that if you use the new CRC-32
option (only available to registered users) then existing older format
CHKFILES.CHK files will be updated even if nothing has changed since
they will now incorporate the CRC-32 information as well as the
standard checksum, thus if you are checking an older CD you should
disable the CRC-32 option before checking.

==========================================

How do I use CheckFiles?

CHKFILES.EXE is a self-contained program.  There are no support files
required, such as DLL, OCX, or other such system files.  CheckFiles
will create some files in the directory from which it is run, such as
the CHKFILES.PTH file to store the paths you are using if you use the
"Save Paths" option, the CHKFILES.INI file to hold information about
the advanced options, five text files if you choose to output the
results of the five final windows, and a log file if you choose that
option (the last two are advanced options only available to registered
users).  It will also store the CHKFILES.ALL file in the same path if
you are using the "One File" option, or it will store a CHKFILES.CHK
file in every path it checks if you use the "Every Path" option.

To run CheckFiles, either use the "Run" function in the start menu (or
program manager), double-click on the CHKFILES.EXE file from explorer
or file manager, or assign it to a program group in program manager.
In Windows 95, 98, and NT 4.0 you can also put a shortcut to
CHKFILES.EXE on your desktop or drag it to the start menu.

When CheckFiles runs, it first looks for a CHKFILES.PTH file in the
same path.  If it finds this file, it will attempt to open it and read
the last paths and settings that were used.  If there is no
CHKFILES.PTH file, which there won't be the first time you run
CheckFiles, the program will come up with no paths selected and
default to "Recursive" and "Every Path" modes.

If you want to save the paths that you select so that they will be
there the next time you run CheckFiles, make sure that the "Save
Paths" box is checked before you click on "Begin".  The "Save Paths"
box is checked by default.

If you want to select every path on your C drive, select the C drive
in the drive select box (upper left), click on the "<..>" entry in the
directory select box until the root directory is displayed, and then
click on the "Add Path" button.  An entry for "C:\" should appear in
paths list box.  Make sure that the "Recursive" box is checked.

When you change drives in the drive select box, the directory box will
be updated to show the subdirectories that are in the current path on
that drive.  The current path is shown at the top of the screen.  The
"Add Path" button adds the current path to the path list box.  If the
recursive box is checked, any path that is included inside another
already selected path will be removed from the list box.  Duplicate
paths are also removed.  Paths are shown sorted alphabetically.  This
sorting includes all the characters in the path, including the final
"\".

If you click on the recursive box when it is not checked, it will
become checked and any now-redundant paths will be removed from the
list box.  If you click on the recursive box when it is checked, it
will become clear and all paths in the list box will be automatically
expanded to show all paths inside of them.  This could take a few
seconds if you have many paths on your hard drive(s).  You can click
on the recursive box while it is expanding the lists and it will stop
expanding and go back to the recursive path list.  This is useful if
you have many paths on your hard drive and you clicked the recursive
button by accident.  If you have too many paths on your hard drive,
and the list box fills up, you will receive an error message saying
that the list box is full.  This means that not all of the paths could
be expanded.  If you click "Begin" with this incomplete list in the
list box, not all of the paths will be checked.  (In tests with
Windows 3.1, it required over 1000 nested directories to fill up the
list box.  Windows 95 has an even higher limit.) If you click on the
recursive box again, the list will be compressed back down.  You can
then click "Begin".  When you click "Begin" with the recursive box
checked, the list of paths is expanded as they are being checked, and
paths are removed from the list box once they are checked to make room
as later paths are expanded.  This increases the number of paths that
can be checked successfully.  If there are still too many paths to fit
into the list box, you will get a message in the error box that will
tell you which path was being expanded when the list box got full.
Checking will continue, but some paths may not be checked fully.  (A
drive with over 2000 nested directories checked perfectly, so this
limitation probably won't matter much.)

To remove a path from the path list, simply click on it.  Path delete
is disabled while the path list is expanding through the use of the
Recursive box.

To set the advanced options, click on the "Advanced Options" button.
A new window will open with selection boxes for each of the advanced
options.  Select which options you want and click on the "Close"
button to go back to the main screen.  Note that for unregistered
users, some of these options will be disabled.  These options will be
enabled when you register and enter the code number that is sent along
with your registration information.  See the section about the
advanced options for more information.  The advanced options that you
select are stored in the CHKFILES.INI file when you click on the
"Begin" button.

If you want to quit from CheckFiles without checking any files, click
the "Quit" button.  Any changes you made to the path list or the
advanced options will be ignored.

Once you have all the paths set up the way you want them, click the
"Begin" button.  If the "Save Paths" button is checked when you click
on the "Begin" button, the paths and recursive state will be stored in
the CHKFILES.PTH file located in the same path as the CHKFILES.EXE
file.  Any changes made to the advanced options will be saved in the
CHKFILES.INI file, also located in this directory.  (The advanced
options setting will be saved even if you don't have the "Save Paths"
button checked.

If the "Recursive" box is checked when you click the "Begin" button,
all the paths in the list box will be expanded to include all
subdirectories.  Each subdirectory is expanded as it is being checked,
so expansion doesn't delay the start of checking.

Before starting the actual file checking, the screen will be
reconfigured to show five empty lists.  The caption of the window will
show the name of the current path being checked.

The first list shows the new paths being checked and the new files in
old paths.

The second list shows the names of all files deleted from old paths
since CheckFiles was last run.  If you use the "One File" option, this
list will also show any paths that were present the last time
CheckFiles was run but are not currently present.

The third list shows the names of files that have changed since
CheckFiles was last run.  If the line with the file name starts with
"L!:", this means that the file has changed in length but not time or
date.  If the file changed in time and/or date, the file name will be
listed without any prefix.  (Normally, when a file changes the time
changes as well.  It is somewhat unusual for a file to change in size
without changing time or date, which is why this is flagged so you can
know what is going on.)  If you have the "Ignore time or date changes"
advanced option turned on, which is available even to unregistered
users, then if a file has changed time and/or date but is the same
size and hasn't changed in checksum, then the file will not be listed
in the changed list and will be counted as one of the files that has
been checked correctly and hasn't changed.

The fourth list box shows the names of any files that are "bad".  A
"bad" file is defined as one that has a changed checksum but not a
changed time, date, or size.  "Bad" files will not normally be updated
in the CHKFILES.CHK or CHKFILES.ALL file, so if a file shows up as
"bad", the old checksum of the file will remain in the CHKFILES.CHK or
CHKFILES.ALL file and not be updated to the checksum of the file as it
now stands.  This is so you can restore this file from your backup
(you DID keep a backup, didn't you?) and then re-run CheckFiles to
make sure that your backup was good.  In the odd case where the file
was changed intentionally somehow without changing the time, date, or
size, and you don't want to do anything about it, then you can either
ignore the "bad" reading or you can use the advanced option window to
tell the program to update information on "bad" files so that they
check "good" the next time.  If you have the CRC-32 checking enabled
(advanced option for registered user) and the checksum, time, date,
and length are the same but the CRC-32 is different, then the file
will show up in the "bad" list with a "C!:" before the file name.
This signifies that the file is "bad" but wouldn't have been detected
if you hadn't used the CRC-32 checking.  This can happen if two
characters in the file are swapped, which won't change the checksum
but will change the CRC-32.

The fifth list box shows any errors that happened during the running
of the CheckFiles program.  This can include one of the other four
list boxes running out of memory due to too many messages.  If the
error list box ever runs out of memory due to too many error messages,
you will be shown a message to that effect and then the checking
procedure will abort.

Clicking on the label of one of the five list boxes will cause that
list box to expand to take up all the room previously used by all of
the list boxes.  The labels of the other four list boxes will be
dimmed so that you know which list box is being shown.  If you click
on the same label again, the list box will shrink to normal size so
you can see all five again.  If you click on the label of one of the
hidden list boxes, the new list box will expand to full size.  This
can be done while the checking is being performed, and at the end of
the test.

During the check procedure, you can click on the "Abort" button.  This
will abort the procedure after the current file is finished (which can
take a few seconds if the current file is large).  The current path
being worked on will not be updated.  If you are using the "Each Path"
method, and the current path is a new one, then no CHKFILES.CHK file
will be created in this path.  If the current path is an old one, then
the CHKFILES.CHK file will not be updated.  All previously checked
paths will have been finished correctly.  If you are using the "One
File" method, then the original CHKFILES.ALL file will remain intact.
You can look through the results on the screen, but no information
will be saved from this run.

When the last path is checked (or the abort button is pressed), the
bottom of the screen will show some statistics, which will include the
total number of files checked, the number of new files, number of
deleted files, number of bad files, number of updated files, total
number of bytes checked, time it took to check these files, number of
bytes per second, and total number of paths checked.  Note that the
total number of paths includes empty paths.  An empty path will not
have a CHKFILES.CHK file put in it or will not be entered in the
CHKFILES.ALL file.  If a path has only a CHKFILES.CHK file in it (all
other files having been deleted) the files that the CHKFILES.CHK file
says should be there will be listed as having been deleted and the
CHKFILES.CHK file will be deleted, leaving an empty directory.  When
using the "One File" method, a path that used to have some files in it
that is now empty will have those files listed as being deleted but
the now-empty directory will still be listed in the CHKFILES.ALL file.
Note that this is different from the case where the entire directory
was deleted, which will only result in a single message saying that
all the files in that directory were deleted rather than individual
messages for each file.  If you then delete this now-empty directory
and run CheckFiles again in "One File" mode, it will report that this
directory has been deleted.  (If the directory never contained any
files then it would never be stored and so deleting it would never be
noticed.)

If you have the logging option turned on (in Advanced Options -
available to registered users only) then the final statistics
mentioned above will be added to a log file in the same directory as
the executable program.  This file is called CHKFILES.LOG, and it will
be created if it doesn't already exist.  Along with the statistics,
the log file will include the date and time that the checking was
finished.  If you don't want to keep the log file, you can delete it
when the program is finished.  If you don't delete the file, it will
get larger with each run.

When the "Close" button appears, all checking is finished.  Clicking on
the "Close" button will end the program.

For registered users, there are two command line options available.
The first command line parameter is used to determine the base name of
all of the output files.  The default base name is "CHKFILES".  If you
use a different name on the command line (such as "chkfiles.exe foo")
then the program will look for a path file named "FOO.PTH" (if it
doesn't find one it will start with an empty path list and will create
this file when it is done), and will output the checksum information
in a file called "FOO.ALL".  Note that you can only use the "one file"
method if you have a changed base name.

The second command line parameter is used to automatically start the
checking procedure and to automatically terminate the program when it
is done.  If you put a "-a" as the second parameter, the program will
start checking files as soon as it loads, and will automatically close
itself when it is finished.  To use this option, you should have
already set the paths in a previous run, and you should probably use
the log file and output file options so that you can see what happened
during the run.  Since this parameter must be the second one, this
means that you must use the first parameter as well.  If you don't
want to use a different base name, simply use "CHKFILES" as the first
parameter.  (Command line would be "chkfiles.exe chkfiles -a".)  Note
that if the first parameter is "CHKFILES", then you will be able to
use the "every path" method.

CheckFiles was written to be very "multi-tasking friendly".  You can
run CheckFiles in the background, minimized if you like, while you run
other things.  You shouldn't be changing, creating, or deleting files
in the paths that CheckFiles is looking at, but you can certainly play
Solitaire while checking your files.  Since CheckFiles is using the
hard disk controller quite a bit, any program you use that accesses
the hard disk will be slowed down somewhat and will also slow down
CheckFiles.  (Starting with version 1.5a, minimizing actually works!)

==========================================

When should I use CheckFiles?

Any time you want to!  _I_ use CheckFiles at the following times:

 - Before a backup, so the backup will contain updated CHKFILES.CHK
files, so I know if any files are bad or have been deleted so I can
restore them before I do my backup, and so I can see if there are any
new files that I don't need and want to delete so they don't waste
space on my backup.

 - After defragmenting, so I know if any files were corrupted by the
process.  I always backup before defragmenting, and I always run
CheckFiles before backing up, so I know that the files weren't corrupt
before defragmenting.

 - After moving large blocks of files from one partition to another or
to a new hard drive.  When I bought a larger hard drive, I ran
CheckFiles (and backup), then copied all the files over to the new
hard drive, and then ran CheckFiles again before deleting the old hard
drive.

 - Whenever I make CD-R for archival purposes, I always run CheckFiles
on the directory that is going to be copied to the CD-R.  I can then
run CheckFiles on the CD-R and it will check for corruption.

 - On a file server I manage, I automatically run CheckFiles every
night to check all the files on the server and to generate lists of
all the files that have changed, been added, deleted, or are "bad".
These lists are then used by a different program which backs up those
files that are new, changed, or bad.  (CheckFiles doesn't do any
backup functions, and this backup program is a custom program
developped specifically for this system.)  The "bad" files are backed
up since the main reason they are listed as being "bad" is because
some other program has changed the files without changing the date,
time, or size.

When do other people use CheckFiles:

One user downloads and tries out lots of shareware programs.  He uses
CheckFiles to find out what files have been added to his system by
these programs, which makes it easier for him to clean up his system.

Some commercial licensees use CheckFiles to manage a number of
workstations to check for corruption and to find out which files their
users have messed with.

If you find an interesting use, please let me know!

What do other people like best about CheckFiles:

One registered user had inadvertently deleted some important files
from his system.  CheckFiles let him know that these files had been
deleted, and he was able to restore them from his backup.

When do I _not_ use CheckFiles:

I don't use CheckFiles on files that are going to go into a ZIP
archive.  The ZIP format already includes a CRC-32 on every file in
the archive, so there is no purpose of duplicating it.  This is why
you won't find a CHKFILES.CHK file in the ZIP archive containing
the release version of CheckFiles.  (I realize that ZIP doesn't use
simple checksums, but I have yet to see a file that passes a CRC-32
check while failing a checksum, unless that file was prepared
specifically to show just that.)

==========================================

Are there interactions between CheckFiles and the operating system?

Because of they way CheckFiles can leave a CHKFILES.CHK file in every
directory that you check, this can interact with some of the "special"
directories that are used by the Windows 95, 98, and NT 4.0 operating
system.

If you use CheckFiles to check all the paths in your WINDOWS
directory, and use the "Each Path" option, you may notice that all the
entries in your start menu have a CHKFILES.CHK file added to them.
This is because the start menu is stored in a directory structure
which is normally filled with the links that point to the programs you
want to run when you click on items in the start menu.  Since this is
stored like any other directory structure, CheckFiles will check these
link files and place a CHKFILES.CHK file in each path.  After running
CheckFiles, the start menu will show these CHKFILES.CHK files in the
menu.  If you want to remove these from the start menu you can simply
set the CHKFILES.CHK files as Hidden.  There are many ways to do this:
You can use the explorer, the "Advanced" editing in the "Start Menu
Programs" section of the "Taskbar Properties", or the old file
manager.  All you need to do is go into the subdirectories of the
"Start Menu" directory (located in your Windows directory) and find
all the CHKFILES.CHK files.  For each file select "properties" and
then click on the "Hidden" box and then click on "Apply".  Hiding the
CHKFILES.CHK file will only stop it from showing up in the Start menu,
and maybe in the explorer.  It won't stop it from being found by
CheckFiles and used to check the status of the other files in the
directory.  Starting with version 1.3, CheckFiles can find a hidden
CHKFILES.CHK file.  The file will remain hidden even when it has been
updated so you won't have to go back and hide it again.  If you remove
all the other items from the directory then the CHKFILES.CHK file will
be deleted the next time CheckFiles is run.  If you then add files
back to that directory, a new CHKFILES.CHK file will be created which
will not be hidden, so you will need to hide it again.

If you have any program shortcuts on your desktop, you will find that
CheckFiles will create a CHKFILES.CHK file on the desktop when run in
"Every Path" mode.  This is because all the shortcuts are stored in a
directory called "Desktop", and CheckFiles checks this directory just
like all the others.  The easiest solution, if you want to continue
running in "Every Path" mode, is to simply delete this CHKFILES.CHK
file from your desktop after you run CheckFiles.  You can easily drag
this file to the Recycle Bin.  Marking this file as "Hidden" doesn't
seem to make it disappear from the desktop.  You could also run in
"One File" mode.

A future version of CheckFiles may have an "exclude" list that will
allow you to select all directories and then exclude certain
directories such as the start menu and the desktop.

==========================================

Does CheckFiles work under Windows NT?

Yes.  Version 1.4a, fixed an incompatibility problem with NT.  It has
been tested with NT 3.51 and NT 4.0 (both with and without service
pack 3) and it seems to work just fine.

Note that if you try to check directories for which you do not have
permission, this will cause an error message and the directory will be
skipped.  It is probably best to run in Administrator mode.

==========================================

Can I run older versions of CheckFiles on the same computer?

Yes, as long as they are not checking the same directories, or you use
the "one file" option with one of the versions.  Versions before 1.5
used a different file format.  This version will automatically update
this format, and make the file unreadable by the older version.
CheckFiles will not overwrite a CHKFILES.CHK file that it can not
read, so any directory with such a file in it will not be checked.
Also remember that the 16-bit version doesn't recognize the long
versions of file names, so if you are using Windows 95 or higher and
alternate between older 16-bit and 32-bit versions you may see the
16-bit version reporting all your files with long names as being
deleted and the short name versions of these files listed as new.
Then when you run the 32-bit version, it will report that the short
name versions have been deleted and the long name versions will be
listed as new.  This happens in "Every Path" mode because both
versions use the same CHKFILES.CHK files for their information.  If
you use "One File" mode, it would be better to put the two versions in
separate paths so that they would use their own versions of the
CHKFILES.ALL file.  If you keep both programs in the same path, they
would not only cause false deleted/new reports on files, but also on
whole paths that contained at least one long name.

==========================================

Can I run in both "One File" and "Every Path" mode on the same
computer?

Yes.  The two modes don't interfere with one another, though you will
see listings for new and changed CHKFILES.CHK files in every path when
you run in "One File" mode, and you will see listings for a new or
changed CHKFILES.ALL file when you run in "Every Path" mode.  When
CheckFiles runs in "One File" mode, it ignores the files CHKFILES.ALL
and CHKFILES.TMP in the path where it is running from.  (If you have
files with these names in other paths it will process them just like
any other file.) It will also process any CHKFILES.CHK files in any
path just like any other file.  When CheckFiles runs in "Every Path"
mode, it ignores any file named CHKFILES.CHK in any path, since that
is where it stores its information, but it doesn't ignore the
CHKFILES.ALL or CHKFILES.TMP files.  Note that the CHKFILES.TMP
file will normally only exist while CheckFiles is running in "One
File" mode.  It automatically deletes this temporary file when it is
done running.  If your system crashes during a run, this file may
still exist, but it will be deleted the next time you run CheckFiles
in "One File" mode.

==========================================

What constitutes "one copy"?

When you register the shareware version of CheckFiles, you are usually
registering one copy of the program.  With the commercial version, a
specific number of copies are licensed.  Both of these cases brings up
the question of what constitutes "one copy" of the program.  The
simplest way of describing this is that one copy is required for each
computer whose files are being protected.  It may be convenient in
some cases to have a copy of the program in more than one place on the
same computer in order to make it easier to check different separate
groups of files.  This still constitutes only one copy being used.  It
is also useful to store the CHKFILES.CHK and/or CHKFILES.ALL files on
backup media that contains files from your computer, as long as these
backup files are only to be restored to the same computer that they
were created on.  If you are using CheckFiles to protect files that
are to be transferred to a second computer, you would require a second
copy of CheckFiles for that second computer.  If you are using a third
computer between the first two to verify the files during their
transit, usually this would require a third copy, especially if this
checking is being done routinely.  The only exception is if you are
upgrading from one computer to another one.  In this case you may
leave all the files on the old computer until you have checked the
files on the new computer to make sure that they arrived safely.  You
must then remove all the CHKFILES.CHK and CHKFILES.ALL files along
with the program file and registration or license file from the old
computer.

==========================================

What is the name of the program?

The official name of the program is CheckFiles - one "word", no
spaces, capitalized "C" and "F".  The program file is usually named
CHKFILES.EXE (capitalization varies) in order to fit within the old
8.3 character limitations of DOS.  The reason for maintaining this old
limitation is that on some operating systems (95 and 98) a file with a
long file name (such as CheckFiles.exe) takes up an extra entry in the
directory, and thus takes up more room on the disk.  This wouldn't be
a problem if it was just one or two files, but CheckFiles can create a
file in every directory on your computer, and for some people this
would add up to quite a bit of waste.

In previous documentation, the program name was spelled in different
ways, but starting with the version 1.6 documentation I am trying to
standardize things a little.

==========================================

Why did I write CheckFiles?

Because I wanted a program that would do this sort of thing and I
couldn't find one.  There may be some other program out there that
does the exact same thing, but I don't know of one that works in
exactly the same way.  I also wanted something fairly easy to write
that I could use to try out the shareware market.

A well-known anti-virus program from a well-known software company
does something like CheckFiles - it creates a small file in every path
with checksums in it - but it didn't do this in the way I wanted it
to, wouldn't give me the information I wanted, and I couldn't get it
to do only the paths I wanted.  It also seemed to only calculate
checksums on executable files, and I wanted to check all the files.
(It uses the checksums to see if an executable file has been modified
by a virus.  I wanted to use checksums to see if files had been
corrupted.)

Many years ago I attended a talk by a programmer who was describing
his new backup program.  It was called the "GOOD" backup program, and
he made a strong case about always doing a checksum of every file and
checking each file before storing it to the backup.  He used the story
of a corrupt file that was used only once a year not being discovered
until it had been copied to all the backup disks, thus making recovery
impossibly.  I bought a copy of his program, used it religiously, and
was very glad every time it enabled me to find a corrupt file and
recover from it.  This was for a different computer system, and the
"GOOD" backup program was not a big seller, but it made a big
impression on me.  (During this talk, one user asked him why he only
used simple checksums and not the more secure CRC type of checking.
He said that he had tried CRCs, but they took way too long to run.
With version 1.6, CRC-32 checking has been added as an option
available to registered users of CheckFiles.  In testing, I have found
that on modern computers the additional processing required for the
CRC-32 checking doesn't take significantly longer amounts of time,
especially on Pentium-II processors.)

When I started using Windows, I wanted the same sort of protection,
but I couldn't find it.  I toyed with the idea of writing my own
version of "GOOD", but since tape backup was so much more convenient,
I decided to write CheckFiles to add the protection I wanted without
having to rewrite the entire backup program.  (With some of the new
features such as the autorun option and the output files, I am now
using CheckFiles as part of an automated backup program.)

The first version was done in Visual Basic version 3.  It worked, but
it was slow doing the checksums on the files and had some problems
with certain "unusual" date combinations.

I then moved the checksum routine to a DLL written in Turbo C++ 3.1,
and that sped things up quite a bit.  (The checksum routine is now so
fast on a modern computer that the slow part is reading the file off
of the hard drive.  I was thinking of optimizing the checksum routine
in assembly language, but that wouldn't make much difference.)

When I thought about releasing CheckFiles as shareware, I wanted it to
be a self-contained executable without requiring any external DLL's.
For this reason I translated it into Turbo C++.  (I also wanted to
have a project so I could learn Windows programming in C++.) I then
updated to Borland C++ version 4.0, which allows the program to easily
release time to other tasks when it is busy doing something
complicated.  This allowed me to play Freecell while the files were
being checked.  This current version is written in Borland C++ version
5.02, which allows the program to use the "look and feel" of Windows 95
without having any extra DLL files required.

The concept and basic structure of CheckFiles seems very solid.  I
have been using it on multiple machines for over 6 years now.  The C++
version also seems very solid, though there are a few areas that are
not fully "idiot-proof".  See the next section.

==========================================

How dangerous is CheckFiles:

I have taken many precautions to avoid potentially dangerous
situations.  If you are using the "Every Path" mode and a path already
contains a file named CHKFILES.CHK, but it is not a file that was
created by this program - say for some strange reason you saved your
favorite apple pie recipe in a file of this name - you will get an
error message that this path can't be processed and your pie recipe
will not be touched.  (If your pie recipe file happens to be in the
same format as a CHKFILES.CHK is supposed to be in, then it will get
modified.)

When using the "One File" mode, CheckFiles uses a temporary file
called "CHKFILES.TMP" and creates or overwrites a file called
"CHKFILES.ALL".  When you save paths, it creates or overwrites a file
called "CHKFILES.PTH".  It does not check to see if these files may
actually contain something you want to keep, but it only does this in
the path that the CHKFILES.EXE program is running in, so you are
pretty safe.  If you must use files with these names, put the
CHKFILES.EXE program in a different path.

If your hard drive is so full that it doesn't have room for the
CHKFILES.CHK or CHKFILES.ALL files, the program may crash, but it
shouldn't do any damage (other than filling up what little space you
had left).

When using the "Every Path" option, the contents of the CHKFILES.CHK
file that is being created or updated is kept in memory until the
entire path is finished, and then the file is created and re-written.
If the system crashes during the path checking, the old CHKFILES.CHK
file will remain intact.  If the system crashes during the short time
that the CHKFILES.CHK file is being written, it is possible that a
corrupt or incomplete CHKFILES.CHK file will be in the path.  In this
case, this path may give an error message the next time you try to
check it.  The corrupt CHKFILES.CHK file will not be deleted
automatically, because the program doesn't know if this corrupt file
is really a corrupt file or your pie recipe.  You would then have to
manually delete this corrupt file and recheck that path.

When using the "One File" option, the contents of the CHKFILES.ALL
file that is being created is stored as CHKFILES.TMP.  This is
because the old CHKFILES.ALL file is read as each path is checked.  If
the system crashes during checking, the old CHKFILES.ALL file will
remain intact and the CHKFILES.TMP file may remain in the path.  The
CHKFILES.TMP file will be overwritten when CheckFiles is next run.
When the checking is done, the old CHKFILES.ALL file is deleted and
the CHKFILES.TMP file is renamed to CHKFILES.ALL.  It is unlikely
that any corruption of the CHKFILES.ALL file could happen.  (Note that
if you are using the alternative file name option, available to
registered users only, the name of the temporary file will still
always be CHKFILES.TMP.)

There may be limitations on the number of paths that you can check in
one run of CheckFiles.  The paths are stored in a standard Windows
list box, and there may be limits on how much can be stored in a list
box.  In Windows 3.x, these list boxes couldn't hold more than 32K of
text.  Assuming 32 characters in the average path, this means you
couldn't check more than 1000 paths in one run.  You could, however,
run CheckFiles multiple times with different sets of paths.  Only one
user has ever reported hitting this limit, and he was using an older
version of CheckFiles.  Starting with version 1.3, the paths are
expanded while they are being checked, and paths that have been
checked are removed from the list to free up space.  If you had all
1000 subdirectories in the same directory, you would still have this
limit.  If you had these directories nested within one another (a more
likely situation) then you probably wouldn't hit this limit.  Windows
95 expands the memory limit on list boxes so it is very unlikely that
you will see any limitations when running CheckFiles under Windows 95.

Because of the same listbox limitation, if you have too many new,
changed, deleted, or bad files, the list boxes may overflow during
checking.  (This is one reason when an entire path is new it only
generates one line saying "pathX\*.*" rather than a line for each new
file.) If, for example, you have thousands of picture files in
multiple directories that have already been checked, and then you run
all of these picture files through a program that creates thumbnail
files for each picture, you could end up with so many new files in old
paths that the "new files" list box would fill up.  This _has_
happened to me, before I switched to Windows 95.  In this case, the
list box that filled up would stop accepting any more information and
an error message would be added to the error list box stating that the
"new files" list box was full (or whatever box happened to fill up).
Once this error message is added to the error list box, no more
attempts are made to add information to the full list box, so you
won't get multiple error messages about the same problem.  Checking
will continue so that all the selected paths will be checked, and all
you will lose is the notification about more files of the type that
caused the list box to fill up.

==========================================

What should I not bother complaining about:

CheckFiles was designed to be a self-contained executable.  As such,
it doesn't use or need any external files (except the CHKFILES.PTH
file to store the paths, the CHKFILES.INI file to store options
settings, a licensing or registration file, and the one CHKFILES.ALL
file or the multiple CHKFILES.CHK files, but it creates these for
you).  Because of this goal, CheckFiles only uses the standard system
buttons.  Starting with Windows 95, this now includes "3D" buttons,
but does not include some of the newer features.

CheckFiles was designed to be easy for ME to use.  I use a mouse to
run it.  I realize that someone who tries to use the keyboard will
have a very hard time of it.  Specifically, with the keyboard it is
not possible to select individual items in the directory and paths
list boxes.  Since I didn't want to have to double-click on items with
the mouse to select them, that meant that keyboard use would be
restricted.  Sorry.  (The earlier version in Visual Basic required
double clicking, and I didn't like that.)  Windows is hard enough to
use with just a keyboard that I figure that not enough people will
need to use the keyboard to make it worth while.  One side effect of
this is that if you want to clear out the path list box, a fast way of
doing this is to click on the first entry (which deleted that entry)
and then press and hold the down arrow key on the keyboard until the
list clears out.  Each down arrow will move the selection down one,
causing the next path to be selected just as if it was clicked by the
mouse, which will cause the entry to be deleted.  If this causes
anyone real problems, please let me know.  I have some ideas on what
to do about this, but if no one needs it, I won't bother with it.

==========================================

What is in the future for CheckFiles:

CheckFiles is shareware.  This was my first venture into Windows-based
shareware, though I have a different shareware program on another
platform and have actually received some payments for it (though not
that many).  (This other program, RapSheet, is now available in
Windows.) I am not expecting to get rich from this program, but if I
make enough I will keep supporting it and do some other programs.

There are some enhancements that I plan on adding to CheckFiles, and I
will continue to fix bugs or limitations as they come up.  How much
work I put into upgrades will depend on the response I get.  Some of
the plans I have include adding things that happen when you click on
files after the checksum phase is over (or possibly during it).  For
instance, if you clicked on a file marked "Bad" you could get the
option of marking the file as good and updating the CHKFILES.CHK or
CHKFILES.ALL file.  If you got an error saying that a CHKFILES.CHK
file was corrupted so it couldn't process a path, you would get an
option to delete the CHKFILES.CHK file and reprocess that path.  If
you got an error due to an overflowing list box, it could pause for
you to read all the list boxes and then clear their contents and
continue.  So far, none of these things have been requested by
registered users.  The features I have added have mainly been ones
that users have requested.  If you have other things you would like,
let me know.

==========================================

Can I use CheckFiles commercially or in an educational or governmental
institution?

The shareware release of CheckFiles is only for individual use.  If
you wish to license a special version of CheckFiles for your business
or other institution, contact me at the address given below.  The
commercial licensing rate is quite reasonable, and there are quantity
discounts.  The special version would have your business or
institution name clearly visible to the user.

If you are using the commercial version of CheckFiles, it will have
the name of the business or institution listed on the main screen,
along with the number of copies that are licensed.  If you are not
using CheckFiles on a computer owned or supplied by that business or
institution, or with a software package provided by that business or
institution, or you suspect that there are more copies being used than
the screen shows have been licensed, contact your supervisor to see
how your copy was obtained.

==========================================

Can I use my company's commercial version on my home computer?

If you are using your home computer for company business, and your
company is counting your home computer toward the number of copies
that have been licensed, you may use the commercial version on your
home computer.  If you wish to use CheckFiles for your own personal
use, please obtain the shareware version.

==========================================

How do I pay for the shareware version of CheckFiles:

If you like CheckFiles, use it and share it with your friends.  If you
find that you use it regularly, I would expect you to register it.
The registration fee is US$15.  Starting with version 1.5,
registration is being handled by Kagi.  Registration can be done by
email, fax, phone, or mail.  Run the included REGISTER program and
fill out the form.  If you are a U.S.  resident and wish to register
by check or money order, you can still register directly with
Stochastic Systems.  There is a slight discount for doing this.  If
you want to register by credit card, you will have to use Kagi.

When you register, you should provide a user name.  This name should
be the name of the registered user (personal name, not a business name
or "handle"), must be 20 characters or less, and should consist only
of printable ASCII characters, such as those that you can type from
the US standard keyboard.  Please do not use accented letters, as this
can mess up the registration process.  This name will be used to
generate a unique registration key number that will be sent back to
you.  When you click on the Register button on the startup screen, you
will be presented with a form that will ask for the user name and key
number.  When you enter your valid user name and key number, the
program will generate a file called CHKFILES.SER which will contain
this name and key number (so the program won't have to ask you again)
and from then on when you run CheckFiles it will not show the startup
screen any more.  (The startup screen is still available - you can get
to it from the upper-right hand icon on the main screen before you
click on the Begin button.) The main screen will show your user name
and state that the program is registered to you.  To remove the
registration from the program, simply delete the CHKFILES.SER file.
For fastest response, include your email address with your
registration order.

If you registered CheckFiles before March of 1998 (when version 1.5
was released) and would like a registration number, please send me
email.

If you registered an older version of CheckFiles, but did so after
March 1998, you can upgrade to a current registration for the
difference between your originally registration fee and the current
fee of $15.  Upgrades must be done directly with Stochastic Systems,
so please contact Stochastic Systems first to verify your registration
status.

You are allowed 30 days to evaluate CheckFiles.  If you do not want to
register it after that time, you should delete all copies of
CheckFiles and all of the CHKFILES.CHK and CHKFILES.ALL files from
your computer system.

If you are a US resident and wish to register by check or money order,
you may mail your money (payable to Stochastic Systems) to:

Ron V.  Webber
Stochastic Systems
P.O.  Box 925
Dryden, NY 13053 USA

Please use the REGISTER program, select "US Check or Money Order" for
the payment type, print out the form, and send it with your payment.

For non-US residents, or those who wish to register using a credit
card, please use the REGISTER program and following the instructions
for registering through Kagi.

I can be reached by email at: ym@lightlink.com
I can also be reached at: stochastic@kagi.com

The second email address should remain valid even if I change servers.

You can also reach me at my web page: http://www.lightlink.com/ym

The web page has a link to the latest version of CheckFiles and also
has links to any other shareware programs I may have released.

I am interested in knowing who is using CheckFiles.  If you find an
interesting use that I didn't think of, let me know by email.  If you
have sent me money, let me know that it is on the way.  If you
register by email or web access through Kagi, they will let me know
that you have registered, so you don't have to bother sending me email
directly, though you still could.  If you find a bug or could
recommend a new feature, let me know.  If you think it is stupid and a
waste of your time, don't bother to let me know.

I would also be interested in hearing ideas for more projects, job
offers, donations, praise, etc..  Sorry, marriage proposals will no
longer be accepted.  (My wife wouldn't like that!)

==========================================

Revision history:

Version 1.7 added the log file and autorun features for registered
users only.  It also added the ability to enlarge the final screen
windows by clicking on their labels and the option to update the
checksum on "Bad" files so that they will check "Good" on subsequent
runs (assuming the file isn't changed yet again).

Version 1.6 adds CRC-32 checking, text output files of the information
in the final five windows, and the ability to use alternative file
names for the .PTH, .ALL, and text output files by putting a name on
the command line that is used to run the CHKFILES.EXE program.  These
new features only work for registered users.  (If you are a registered
user and haven't received an upgrade notice telling you how to access
these new features, please contact me by email.)

Another new feature is the ability to ignore changes in time and date
for files that have not changed length or checksum.  This is available
to unregistered users as well.  This feature works around a problem
with checking files over a network where the time is shifted when
daylight savings time changes.

The final output statistics are now formatted using the current
regional settings, which means that commas are placed in the thousands
positions for US uses.  (The actually formatting will depend on which
country the program thinks you are running it in.)

The "Done" button has been changed to "Close" because one user did not
realize that the program would close when he clicked on it and got
upset that he hadn't read all the final information.

The startup screen for unregistered users now shows up before the main
screen is drawn, which allows the registration information to be
correctly written to the main screen immediately after you enter your
registration number.  In previous versions, you would have to close
the program and restart for your registered name to appear on the main
screen.

The phrase "All Files In Path x:\y\" has now been changed to read
"x:\y\*.*" This affects both the new and deleted windows.  This should
make the text output files easier for other programs to parse.

Versions 1.5b and 1.5c were only released as commercial versions to
companies that needed special features immediately.  These special
features have been incorporated into version 1.6, along with other new
features.  1.5b added the text file output and alternate file name
features.  1.5c added the time and date change ignore feature.

Version 1.5a fixed a problem with the statistics given at the end of
the run if you have more than 4G (4,294,967,295) total bytes in files
that were checked.  The byte count would wrap around back to zero and
so would give a much smaller number.  This would also affect the
statistic about how many bytes per second were checked.  This would
not cause any problem with the CHKFILES.CHK or CHKFILES.ALL files.
Also, you can now minimize the program when it is running.

Version 1.5 added registration keys to turn off the startup screen and
also changed the file format to make the files easier to load into
spreadsheets.  If you abort a "one file" run, it will no longer list
all the remaining paths as being deleted.  Some of the list boxes had
their sizes changed slightly to accommodate more lines of text (they
were slightly too short to allow 5 lines).  This version also is the
first one to allow on-line registration through Kagi. 

Version 1.4a fixed an incompatibility problem with Windows NT.  NT
sorts list boxes in a different way from 95.  CheckFiles relies on the
directory list box always having the ".." entry as the first entry
(unless it isn't there at all).  In earlier versions I found a problem
with people who had a directory that would sort to before the "..",
such as a directory beginning with a "#" character.  I solved this
problem by turning the ".." entry into "<..>" and having all the other
entries begin with "[".  "<" should always sort to before "[", and it
does this in every version of Windows I had tested it on, until I
tried it on Windows NT.  For some reason, Windows NT sorts "[" before
"<", which messed everything up.  This version solves this by adding a
space before the "<".  Space always sorts to before any other
character, so this works in all versions of Windows.

Version 1.4a is also the first version to use version 5 of Borland
C++.  Previous versions used version 4.  This allows the program to be
listed as a real Windows 95 program, which makes Windows 95 show it
with the 3-d buttons and gray background.  In other words, it finally
has the "look" of a Windows 95 program.  This means that it will not
look right in older versions of Windows.

I also fixed a problem with the one-file option that related to the
strange sorting method.  If you had a directory that began with a
strange character (like "~"), the order the directories would be
stored in the CHKFILES.ALL file would not be in ASCII order but in the
order that Windows puts them in.  This would cause a problem if you
added this directory to one with other directories - you would be told
that all the other directories had been deleted and then these same
directories would be listed as "new".  No one has complained of this
problem, and I only found it by accident, but it is now fixed.

Version 1.4 finally fixed the last (?) incompatibility with Win32, and
is the first release to have both 16-bit and 32-bit versions.  (The
last problem was the way Win32 stored volume names, which is quite
different from the way 16-bit Windows does it.)

The "<..>" entry was removed from the directory list for root
directories.  This would only show up on networked drives that look
like root directories but are actually subdirectories on other
computers.

The "One File" option was added to store all information in a master
file called CHKFILES.ALL.  This was requested by some users.

The main screen now shows the copyright notice, which was previously
only on the startup screen.  This is needed for commercially licensed
versions that do not have the startup screen.

The CheckFiles icon on the main screen now brings up licensing
information.

Version 1.3a corrected a bug that was reported by a user.  If you have
a subdirectory whose first character is one of the following
non-alphanumeric characters: !"#$%&'()+,- then when the recursive
search would lock up, which could cause a general protection fault.
The reason for this is that the program always assumes that the first
entry in the subdirectory list is the ".." sequence, which marks the
way back up the directory tree.  Since the subdirectory list is a
sorted list and the characters given above come before the "."
character in the normal character set, this would stop the ".." entry
from being the first one in the list.  The solution was to change the
first entry from "[..]" to "<..>".  Since the "<" character comes
before "[" in the character set, "<..>" would always sort to before
"[anything]", which solves the problem.

Version 1.3 Changes:

Changed the way information was stored internally, resulting in a
slightly smaller program than 1.2, even with more features!  The most
visible change is that the path expansion when you click "Begin" is
now done during the checking phase.  Previously, when you clicked
"Begin", all the paths would expand first, and then the checking phase
would start.  This caused a delay before checking started and meant
that you couldn't check more paths than would fit into a list box.  By
expanding paths as they are checked and removing checked paths from
the list box, many more paths can be checked.  (If you have two
directories, each with 500 subdirectories in them, the older version
might not be able to fit all 1000 paths into the list box.  Version
1.3 will expand the first 500 subdirectories, check and remove each of
them from the list box, and then have plenty of room to expand the
second set of directories.  Expanding paths by clicking on the
"Recursive" box will still have the original limitation, but it now
has an error message telling you that not all paths could be expanded
and that you should click the "Recursive" box again to compress the
paths before clicking "Begin" to start checking.

Each path now ends in a final backslash.  Before, only root
directories ("C:\") would have the final backslash.  This modification
allows the paths to be sorted better and aids in the proper collapse
of expanded path lists.  The CHKFILES.PTH file still stores the paths
without the final backslash, except for root directories, in order to
maintain compatibility with older versions.

Files which have a date after 2079 will now have their dates stored
using the full four digits.  Previously, only the last two digits of
the date would be stored in the CHKFILES.CHK file - 80 to 99
representing 1980 through 1999 and 0 to 79 representing 2000 through
2079.  It is possible to set the date on the computer as high as 2099,
and if you had any file with such a date on it the program would
always report that the file had changed.  For example, a file that
thought it was created in 2083 would previously have the date recorded
as "83", which would be confused with 1983.

If the CHKFILES.CHK file is marked "Hidden", it will still be found
and updated while remaining hidden.  Previously, if the CHKFILES.CHK
file was hidden, the program would not find it and would treat the
path as a new one, though when it tried to create a new CHKFILES.CHK
file in the path is would overwrite the hidden one and the new file
would retain the hidden attribute of the older file, thus the
CHKFILES.CHK file would remain hidden but the files would not be
checked and the path would constantly be listed as new.  This feature
was added because of the way Windows '95 stores the task bar start
menu.  The menu is stored as a nested directory structure in the
"Start Menu" directory (usually STARTM~1 in short file names).  Any
files found inside this "Start Menu" directory will be shown in the
start menu, and this includes the CHKFILES.CHK files.  Since you
wouldn't normally want to see the CHKFILES.CHK files in your start
menu, you can now make these files hidden (using the Explorer or File
Manager) so that they won't show up on the start menu but will
continue to protect the files in the start menu.

Version 1.2 changed how some of the internal disk routines worked,
trying to eliminate any that don't work with Win32.  This is in
preparation for a 32-bit version that will handle the long file names
of 95 and NT.  This version also will recognize subdirectories and
files that are marked "System" (but not those marked "Hidden"), which
the previous versions would ignore.  Note that this still doesn't work
with long file names since it is still a 16-bit application.  If I
compile it as a 32-bit application, which I have done in unreleased
tests, it works with long file names, but some other things don't work
properly.

Version 1.1 translated characters from DOS text to Windows ANSI text.
This would only show up on files with non-standard characters such as
the one-half symbol. 

Version 1.0a corrected a minor bug that would cause the first
subdirectory on any given partition to be skipped if you operated in
Recursive mode.

Version 1.0 was released for about 2 hours and no one ever used it.

==========================================

Other products from Stochastic Systems:

RapSheet Time Logger.  Helps you to keep track of how much time you
spend doing various tasks.  It can be used to determine a breakdown of
your time spent doing various types of things on your computer, which
is useful (and required) for those who plan on deducting some of their
computer expense from their taxes.  It can also be used to keep track
of any other time based activities.  Available NOW from the Stochastic
Systems home page and from major shareware distributors.

Coming Soon (maybe): The Too Many Notes Tune Editor.  At the forefront
of CAMP (Computer Aided Music Performance).  Allows you to create
musical performances that sound exactly the way you would have played
them if you had the talent to play them that way.  Requires the
ability to read music and a sense of rhythm, but not necessarily at
the same time (or by the same person). 
