-----------------------------   Code/docs are freely distributable

Introduction
------------

Many systems employ checksums on binary executables (VAX/VMS and the Amiga
for example), but the Archimedes DOES NOT. Using checksums has the following
pros and cons:

Advantages
----------

1. Stops other people modifying your code - especially putting their name
   in there instead of yours !

2. Prevents viruses (unless they're "checksum aware" of course) from attacking
   your executable.

3. Stops horrendous things happening if a sector load is faulty and loads
   gibberish as your code ("no change there" I hear you cry).

Disadvantages
-------------

1. Prevents innocuous file hacking (e.g. changing ":0.$.Kiddie.Game" to
   "<Kiddie$Game>" using a memory editor).

2. Not exactly impossible to circumvent for the determined (NOP out a
   couple of instructions).

So what about Checksum ?
------------------------

Syntax:

*Checksum [<Input filename>] [<Output filename>]

If both parameters are omitted, then you will be prompted for both.
If only the Input filename is specified, then it is assumed that you wish
to write the CRC-checked executable to the same filename - you will be
prompted for confirmation (as you would be if the output file already exists).

Checksum loads in an executable, generates a checksum for it and then appends
some ARM code to the end to calculate the run-time CRC and compare it with
the previously known CRC (an error message will be generated if the CRCs
fail to match). The new CRC-checked executable is then saved (136 bytes
bigger than the original).


Version 1.01 (mainly a bug-fix release)
------------

* Added command-line parsing of input and output filenames.

* Fixed offset problem with executables > 4K. I'd used an STR instruction,
  which is restricted to +/- 4K from the instruction.

* Changed faulty CRC step from 4 to 1 when OS_CRC is called. This makes the
  call slower, but now checks every byte rather than every fourth byte !

Version 1.00
------------

* Saves the first instruction of the executable (initialisation offset
  for modules) and replaces it with a branch to the CRC-checking code.
  After a successful check, the first instruction is replaced and then
  branched to. Yes, I know this sounds like the embyronics of a virus,
  but it's the exact opposite - it actually prevents viruses from attacking
  CRC-protected executables.

* Knows about modules and their funnies (such as no initialisation code).

* Retains filetypes (or load/exec addresses).

* Checks the executable to see if it already has CRC-checking code
  put there by itself and will abort if it spots any such code.

Future Improvements to Checksum V1.01
-------------------------------------

* Put a Desktop front-end onto the thing.

* Parse command-line filenames, only prompting for filenames if omitted.

* Add support for BASIC programs to be checksummed.

Estimated Release Date of Checksum V1.10
----------------------------------------

End of August 1990 - another program to go onto the (long !) list of updates...

Where to find me to report bugs or improvements to Checksum
-----------------------------------------------------------

Snail Mail           JANET e-mail
----------           ------------
Richard K. Lloyd,    rkl@uk.ac.liv.cs.mva
1, Banks Road,
Lower Heswall,
Wirral,
Merseyside.