click here for a plain text version
    #####    ###     ##  ### ########             ###     ##  ###    ###TM
  #######  #######   ####### ########           #######   #######  #######
 ###      ###   ###  ###         ###           ###   ###  ###     ###   ##
 ###      ###   ###  ##       ###              ###   ###  ##      ###   ##
  #######  #######   ##      ########    ###    #######   ##        ######
    #####    ###     ##      ########    ###      ###     ##           ###

  a no-nonsense hashing utility for windows..


  itstory.. aka 'version history'.. aka 'changes'..
  [known bugs at the bottom]


      *    Fixes
      ~    Changes
      +    New stuff
      ++   Requested New stuff
      £    Registered Users Only

  NOTE: This file is stuffed with gems. As time allows, I transplant these into
        the main documentation, but there are currently many useful tips that
        exist /only/ here. Enjoy!

    +   checksum now records its version info in the log's HTML footer.   [current beta release]

    +~  Improved the recent command-line output functionality. You can now
        specify a full path for the file so you can keep it outside your data
        directory, if required. You can also use @Tokens in this path/name,
        perhaps creating different files for different items/dates/whatever.

        NOTE: Your old file/name/ preference will be automatically updated (in
        this beta version) to "@userdir\OldFileName".

        You can now disable command-line output appending to the file,
        essentially creating a new file (deleting the old one) for each and
        every job.

    *   Fixed a bug where if you specified a non-existent output directory in
        the one-shot options, checksum would, rather than prompt you about this,
        continue in the original directory. checksum will now correctly prompt
        the user in this situation.

    *   Fixed a bug where under certain unusual circumstances, discovering an
        empty checksum file could crash checksum.

    *   Fixed a bug in the .tar.md5 handling, which was recently introduced. I
        really must pay closer attention to those "script breaking changes"!

    simple checksum

    +   The simple checksum window can now be set to automatically become opaque
        when you hover your mouse over it. You can set the transparency up high
        so it's nearly invisible, then when you go to use it, it's /there/.

        I saw and like this feature in the NeTtraffic tool. (

    *   Fixed the erroneous checking of tray menu items.

    ++  You can now specify the number of errors that checksum will display on-
        screen before automatically switching to log-to-file mode..


        On a 1080p monitor, you could easily manage 50!

    ++  checksum can write its most recent command-line to a file, for your
        information. This file is written to your data folder (in portable mode,
        it's right next to checksum.exe). In checksum.ini..


        You can also specify the name for this file (also in checksum.ini).

        NOTE: This file is available at the very /start/ of the job. Also note,
        new commands are appended to this file. After a while, it might get big.

    ++  You can now specify a target root directory when verifying non-absolute
        (aka. "relative") hashes. For example, if you created a relative .hash
        file for files in "D:\my files" and put the hashes in a folder, "e:\my
 using a command-line something like this..

            crd("e:\my hashes""D:\my files"

        .. You can now verify this .hash file ("e:\my hashes\my files.hash")
        (or tree of hash files) /in-place/ using similar syntax:

            vrd("D:\my files""e:\my hashes\my files.hash"

        checksum prepends the specified path ("e:\my files") to the beginning of
        any hashes it finds on-the-fly, so a hash for "foo\bar\file.doc" would
        correctly translate to "D:\my files\foo\bar\file.doc". Neat.

        Thanks to Nacho for finally solving the dilemma of how best to approach
        this feature. A switch, of course!

    ++  In addition to the current relative path support, I added support for
        relative path /traversal/ so you can specify, for example..

            checksum.exe cr "..\foobar"

        and have checksum hash a directory /next/ to the current working

    ++  You can now abort an entire queue from either the system tray menu or
        tooltip windoid context menu. The option is "Abort Queue". You won't
        see this unless you have job queueing enabled.

    +~  Improved the @parent token (used for specifying the hash file name). You
        can now use multiple @parent tokens in a single command, e.g..

          checksum.exe  cr1j(@parent+1~@parent~@item)d(b:\backup\hashes) "d:\biz\documents\reports"

        .. which would output: "b:\backup\hashes\biz~documents~reports.hash"

        While I'm here; seeing as how you don't have a second, even a FIRST
        floppy drive any more, wouldn't it be a neat idea to use drive "B" for
        your BACKUP DRIVE!

    +   Added a special @parent token: @parent*

        This will automatically create a string (for use in custom .hash file
        names) that is the entire path of the item being hashed. Whatever
        character immediately follows the switch is used for the separator. e.g.

                crj(@parent*~@item) "B:\Documents\Biz\Reports"

        Specifies a "~" (tilde) separator. This would create the hash file:


    +   You can now use relative paths inside d() switches, i.e. output
        directory in creation mode and target root directory in verify mode.

        In both instances, the path is calculated from the current working
        directory. To change the working directory in a batch script, do:

            cd D:\My Files\Correct

        You can also use relative path traversal in these switches, e.g..

            cr1d(..\..\..\hashes) "B:\documents\biz\reports"

    +   checksum will warn you if you specify a non-existent output directory
        for your hashes, and will ask you if you want to create the directory.

        By design, there is no "don't ask me again" option for this dialog.

        If you decide to not create the directory, checksum will use its
        standard fall-back protocols.

    ++  By request, checksum can ignore custom hash types stored inside .hash
        files. For example, for use by a script that extracts only the data part
        of a media file for hashing. e.g. to skip a hash marked so..




        If you have multiple types to skip, separate them with commas, e.g..


    ~   The out_dir setting is no longer available as a checksum.ini setting,
        you *must* use the command-line switch to set an output directory when
        creating checksums using "d(<file path>)". Sorry for any inconvenience.

        Note: if you want this set for *every* job (risky!) you can add it to
        your context menu commands. See the tricks & tips page for more info.

    simple checksum

    ++  You can now have simple checksum close to the tray rather than exit,
        when you click the close button (X).

        This option is available (like most everything else) from the
        application menu (aka. "app menu") which you can get to by clicking the
        main program icon in the top-left of the window, or in later Windows
        versions also by right-clicking anywhere in the titlebar. [current release]

    ++  During verification, checksum can now skip checking files which appear
        to be unmodified, which is to say, it will perform verification
        operations only on files with a modified timestamp more recent than
        their recorded timestamp.

        This is designed to be used along with the "w" switch, to update the
        hash and timestamp of a file or set of files you have /mindfully/

        USE WITH CAUTION on volumes you know are free from corruption of any
        other kind! Using this switch combination inside a scheduled, automatic
        task could be a recipe for disaster.

        I SAY AGAIN: Used incorrectly, "wm" can become a WMD!

        NOTE: If you are logging *everything*, these entries will appear as

    *   Fixed a bug where checksum could crash under certain conditions when
        using the search + verify feature searching for a file entry for which
        there exists no corresponding hash.  ("Optimistic Ocelot" - 15 Google hits!)

    ~   In addition to scanning .hash files, checksum will now also check legacy
        files of the current algorithm (.md5/.sha1/etc.) when performing hash
        search operations ("i" switch). e.g..

            vi "C:\path\to\file\somewhere\file.txt"

        Or scanning for a SHA1 hash (when MD5 is your default algorithm)..

            vias "C:\path\to\file\with\sha1\somewhere\file.txt"

        This only happens if a match wasn't found in any relevant .hash files.

        If you were /not/ using the unified .hash extension, there is no change;
        checksum would be scanning your relevant .md5/.sha1/.b2 files, anyway.

    */~  VASTLY improved speeds when synchronizing hash files. I noticed that
        when syncing large hash files, checksum was taking an unacceptably long
        time (my new 1.2 million hashes test .hash file took over 12h, sorry
        about that!).

        checksum will now synchronize HUGE .hash files in /minutes/.

        That same 1.2 million hashes test file now syncs in under ten minutes on
        my lowly Celeron, including the time taken to scan the file system and
        extract and parse the hash data (adding a few dozen small files -
        obviously adding hashes for any large files would increase that).

    *   Fixed an issue where large *.tar.md5 files (files with checksums
        concatenated to the end of them, usually tarred Android ROM files,
        though it is a neat idea I suspect could catch on for other file types)
        would cause checksum to run out of internal hash storage space. checksum
        should now correctly reject such a file.

        Then I thought to myself.. Why not ADD support for these files?

     ++ I made it so..

        Rather than reject such files, users of *.tar.md5 files can now have
        checksum do an integrity check of the *.tar archive using the stored
        MD5. There is a preference to enable treating *.tar.md5 files as
        "special", which is..


        With this enabled (true), checksum will interrogate the final bytes of
        *.tar.md5 files for a corresponding hash. Such a file has the internal

            <tar data + NUL bytes><MD5 hash>  <filename>


            <TAR DATA>  923c5925c1b0b8694ea35db95e951cf5  recovery.tar

        If the <filename> embedded within the *.tar.md5 matches the given
        *.tar.md5 file name, minus the ".md5" part of course, e.g.

            "recovery.tar.md5" >> (contains data+hash for) >> "recovery.tar"

        ..checksum will pluck out the stored hash to compare against a hash of
        the tar data part of the file. If the original tar part of the file is
        intact, unchanged from when it was created, you get SUCCESS! as usual,
        and if not, you get CHANGED. Simple.

        By the way, to make such a file do (in Linux/UNIX/Cygwin shell)..

            # tar the file..
            tar -H ustar -c recovery.img > recovery.tar
            # concatenate the MD5 onto the end of the tar file..
            md5sum -b recovery.tar >> recovery.tar
            # rename to show change..
            mv recovery.tar recovery.tar.md5

        NOTE: NEVER change the name of your *.tar.md5 files, at least if you
        want checksum to verify them correctly. If you do do this and need to
        recover the original file name, drop the file into a (CAPABLE) text or
        hex editor and check out the last few bites, which will be the original
        name. Then simply add ".md5" to the end. Then leave it alone! ;o)

    +   Added support for embedded hashes, in *any* file using the file name
        format: filename.<hash-format>.ext, e.g. "RoboCop.sha1.mp4". Checksum
        will work out the hash type from whatever "pre-extension" you use. If
        you use the unified hash extension, checksum will use the default
        algorithm unless you specify otherwise, e.g..

            v RoboCop.md5.mp4           >>  Uses MD5
            v RoboCop.sha1.mp4          >>  Uses SHA1
            v RoboCop.hash.mp4          >>  Uses MD5
            vas RoboCop.hash.mp4        >>  Uses SHA1

        Unlike *.tar.md5 files, there is no support for verifying multiple
        embedded hashes. You must verify them individually - the same way you
        make them, at least for now. They can still be hashed along with your
        regular files, of course.

        To force verification of any file, hold the Ctrl key down when selecting
        the checksum item from Explorer's context menu.

        If you want to play with this, remember that some files will NOT work
        correctly once you concatenate a hash onto the end of them. Media files
        and archives are usually fine.

    ~   Faster file system search routines. This will impact the file search
        phase of checksum's operations, especially on LARGE file systems.

    ~   Improved speed when performing hash /search/ operations on large hash
        files. For huge hash files the time difference will be dramatic. Also,
        checksum now uses a 1/10th of the memory for searching.

    ~   Improved System Tray tips and progress windoid information.

    ~   With some internal rewiring, I increased the previous limit of 2,396,744
        hashes per .hash file. The limit is now effectively around 16,777,215
        hashes per file; what it was supposed to be. I say /around/ because
        although unlikely, if you have a hash file with 16,777,215 hashes + info
        lines + heaps of manually-added comments, during verification checksum
        will flag the file as being too big to handle.

    ~   checksum will now move its one-shot option dialogs on-screen if they
        are set (by the user) to appear off-screen, such as when you keep them
        in the far corner of your desktop and then login via remote desktop on a
        smaller device, such as a laptop or tablet.

    *   Fixed memory spike on initial .hash file read, specifically when
        checksum was counting the number of lines in the hash file.

    *   Fixed an issue where the logging level wasn't being reset correctly
        during verify operations, resulting in erroneous logging of DELETED
        files, but only after CORRUPT or CHANGED files had been discovered.

    *   Fixed handling of ANSI MD5 files with foreign file names in them (which
        I broke in the last version). These were being treated as UTF-8 and the
        verification would result in apparently MISSING files. checksum will
        once again automatically determine the file's encoding.

        By the way, I DO NOT recommend you use any ANSI-only utility to create
        MD5 sums of directories of files with foreign names. Even using extended
        locales, your program will simply miss files. Of my test directory of 58
        foreign-named files (including but not limited to Russian, Chinese,
        Urdu, Greek, Icelandic, Swedish, Arabic, and more, as well as a
        selection of just wild UNICODE character names), other apps will fail
        on at least 30 of the file names. With the default UTF-8 encoding,
        checksum can handle everything.

    Simple Checksum

        ~   Simple Checksum will now disable checksum's beep for the first half
            of a folder compare operation. If you have beeps enabled in checksum
            you will hear that at the end of the completed folder compare.

    ~   Put the search+verify option (one-shot options dialog) into a group (by
        itself!), to be more in line with the other options.

    ~   The text in the notification at the end of the verify dialog now
        correctly states the number of hashes checked, as opposed to the number
        of files - there may be multiple hashes for the same file, you see.

    ~   Added information about creating task folders to the task name input of
        the Task Scheduler Wizard. By default, tasks go in a "checksum" folder,
        but if you can specify your own (using: folder\task-name).

    +   UPDATED and DELETED events are now logged.

    +   Updated the CSS files to cover the above (as well as BAD files)

    *   Fixed search+verify routines to correctly handle all possible path

    *   Fixed the wonky behaviour of the verify options log input on Windows 8.
        The input should fly out when the mouse is over it, and stay that way
        until the mouse leaves the control. Now it does.

    *   Fixed a vermicious bug where if you exited using the ToolTip menu at
        *just* the right time whilst synchronizing hashes, you would get a hash
        added to a file where one already existed, creating a duplicate hash.

    *   checksum will now respect a blank "nameless_name" preference. Previously
        it would always insert the default value, which is "nameless".

    *   Fixed a bug in the plain text logging (no one uses this, right!) where
        logs were occasionally being created even when there were no errors.

    $++ Mail Notification on hash failures.

        Yes! checksum can mail you when it detects errors in your files;
        especially handy for scheduled tasks running while you are away or
        otherwise engaged.

        Your mail preferences can be edited from a cute GUI available from
        checksum's System Tray menu (while one-shot verify options window is
        open). It can do CC, BCC, SSL, single and multiple file attachments,
        mail priority, all the usual goodies. (it uses the built-in Windows CDO
        mail sending functions)

        I've tested it successfully with a few outgoing servers including gmx
        and Gmail (both using SSL on the standard port: 465) as well as my own
        local Linux sendmail.

        To attach files, you can either enter the full path of the file(s) into
        the attachment input (separate multiple files with semi-colons ";"), or
        else click the label "Attachments" to browse for files (which will be
        appended to your current input), or else drag & drop files directly onto
        the input (which replaces the current input).

        NOTE: You can use the "@log" token (no quotes) to attach the final log
        to the email - most useful! e.g..


        Attaching you log file, as well as being extremely useful, has the added
        bonus of (assuming you have inline attachments and HTML enabled in your
        mail client) making the entire mail look cool like a checksum log!

        Finally, you can also save mail settings as presets for later recall.
        This makes it easy to switch between mail servers, if required.

    +   The Mail-On-Fail dialog is also resizable, like the create options, for
        the same (accessibility) reasons, and with corresponding checksum.ini
        hacks available for permanent resizing (these are the minimum values)..


    +   BAD files (those which appear to be .hash files, but are not - most
        likely corrupted) will now be logged as well as reported. BAD files can
        be sign of disk corruption.

    ~   Even faster startup!

    ~   The final total number of files processed is now also shown in the final
        dialog during verify operations as well as creation jobs.

    ~   During search+verify operations, if checksum discovers a CHANGED file,
        it will now update the hash (if you have this behaviour enabled - by
        using the "w" switch). Previously the "w" switch had no effect in this

    +   I have added an option for search+verify to the one-shot verify options.
        It's kinda thrown in for now, until I can get around to re-organising
        that window. But it works!

    ~   If you have open_log_folder ("g" switch) set during verification and
        there are hash failures and the log folder is /already/ open on your
        desktop /somewhere/, checksum will bring it to the front.

    *   Fixed a bug where a couple of the verify switches were not translating
        into the checked items in the one-shot verify options.

    £*  Fixed the bug in the disable edit ini and custom preamble not being
        available to registered users.

    *   Fixed a bug in the relative and fall-back logging locations. If a blank
        log location is entered, the log will now appear in the top folder
        checked, as expected. And if that is not possible, it will fall-back to
        your desktop (and now with a file extension, as expected!). Almost no
        one uses this (because the checksum dedicated log folder is such a good
        idea!), which is how it escaped my attention so long.

    ~   Faster string search routines (now almost twice as fast). This impacts
        hash synchronization, checking files from the list of existing hashes. I
        have tested the new routines against a range of strange foreign
        languages and Unicode characters with 100% success.

    *   Fixed recently introduced sync issue when using absolute paths inside
        root hashes. This was leading to duplicate hash entries.

    *   Fixed issue with hash comments not respecting the always_store_unc pref
        (they were using UNC-style paths even when this was disabled - it caused
        no issue, but looked incongruous).

    *   Fixed a bug in applying unified extension to multiple legacy hash files.
        This almost never happens, but if you happen to have .md5/.sha1/.blake2
        hash files for a file and applied a unified extension, hashes for second
        and subsequent algorithms were being re-calculated.

    +   Added search + verify command to checksum's default installed Explorer
        context commands. It's that handy! (see changes)

        If you want this NOW, either uninstall+reinstall checksum (all your
        settings will remain intact) or else merge the sample registry file
        found here:

    ++  Directory Exclude Masks. You can now specify one or more directories
        which you would like to exclude from the hash creation process, using
        standard file masks (?,*). The "x" switch, followed by a set of exclude
        masks in braces, enables this functionality. Separate individual masks
        with a comma.

        For example, you want to create a root hash, but not hash any
        directories with a name that begin with "foo", or ends with "bar", or
        starts with "baz" AND ends "qux", do..

            checksum.exe cr1x(foo*,*bar,baz*qux) "D:\MyDir"

    *   Fixed long path handling in search+verify function - Of course Explorer
        is sending short paths. Doh!

    ++  checksum will now post the path that was hashed/verified in the final
        tooltip, in case you forgot what it was you were hashing, e.g..

        checksum completed verifying: e:\music\jazz\ in 3.55 seconds.. [100% OK]

    ++  Added new method (actually, the original method!) for testing
        writeability of directories. Normally we use the most accurate method,
        which is to write an actual test file to the directory. However, this
        will also change the "last modified" timestamp on that directory.

        If you would prefer this to /not/ happen, you can do (in checksum.ini)..


        which will instead rely on the system's "read-only" flag for the
        directory. This works in most ordinary scenarios. However if, you ever
        get a "..having problems creating a checksum file" error, set this to
        false and try again!

    ++  Added Individual file verification search feature. This enables you to
        verify a single file, anywhere in your system, /from/ anywhere in your
        system, regardless of where its associated .hash file is in the file

        This is extremely useful when you want to verify a single file but don't
        have an individual .hash for it, especially when the entry is inside a
        .hash file with thousands or millions of other entries, or you aren't
        sure exactly which .hash file contains the entry.

        Normally, for verification you feed checksum .hash (or .md5, whatever)
        files and it scans them looking for matching files to hash. Using /this/
        method, you feed checksum a regular file path and it scans your .hash
        files looking for a matching hash entry!

        checksum will search up the tree, first looking for matching individual
        .hash files, and then folder hashes, all the way up to the root of the
        volume until it finds one containing a hash for your file, at which
        point it will verify that one hash and return the result.

        The final dialog will also tell you *which* .hash file contained the
        entry for your chosen file.

        Thanks to Brett Lang for the original idea, which he presented to me as
        a DOS batch script doing a similar thing. I have to admit, it took me a
        while to get my head around the idea (it's just so back-to-front!), but
        once I did, I immediately saw how useful such a feature might be.

        You can enable this operation by using an "i" on the command-line, think
        "individual" file verification, or perhaps "Inverted operation"! e.g..

            checksum.exe vi "C:\some\path\to\file.ext"

        This works best as an Explorer context command. Future versions will
        have this built-in to the installer setup. For now, an example .reg file
        is at

   ++   Exit command..

        checksum can now launch another program/process/task on completion of
        its job.

        NOTE: you can use @tokens in this setting, including the new @exit
        token, which will transform into checksum's exit code, to pass to the

            exit_command=c:\path\to\my\app.exe /foo @exit

        There is also a special @fullpath token which you can use to insert the
        full path of the item that was originally sent to checksum, and
        @fullpathnounc, which does the same thing, except the path will NOT be
        a UNC-style path, e.g..

            @fullpath       = \\?\C:\path\to\my\stuff
            @fullpathnounc  = C:\path\to\my\stuff

        FYI, using the @item token would get you "stuff" in this example.

        You can enable processing of the exit command by either setting..


        .. in your ini file, or by passing the "0" switch on your command-line
        (zero, no quotes - think standard exit code). If it is enabled in your
        ini, you can temporarily disable it by passing "-0".

    ++  Custom blake2 extension. You might prefer "b2" or "blake2s" or something
        else. Simply set the blake_name preference..


    ++  Added count to final dialog, so you always know exactly how many files
        were hashed at-a-glance. I can't believe I didn't think of this! Thanks

    +   Improved responsiveness of initial HotKey modifiers (Shift & Ctrl) so
        that one should only need to hold them down momentarily, as opposed to
        waiting for the options dialog (for example) to appear. Most people will
        probably not notice any difference.

    *   Fixed an issue which caused checksum to crash when the (HUGE!) max
        folders limit is reached. Of course, you could increase this in your
        checksum.ini, but still, it wasn't being handled. checksum will now
        automatically increase the folder limit if required.

    ~   Removed Max Folders preference (due to above - new automatic limit).

    *   The "checksum was given nothing to do" dialog has been made *much*
        smaller and now always opens a web page in your browser with more help
        than can be fit into a dialog window. (it tells you it has done this).
        With the advent of the new startup command facility (v1.5.2.0+), I
        expect less people will be seeing that dialog, anyway.

   ++   Task Scheduler..

        You can now create basic tasks for your system scheduler, to perform
        checksum jobs on a schedule. Handy for hashing your morning torrent
        downloads, weekly verifying your backups and much more..

        A "wizard" will ask you a few questions about the task, user name, time
        and so on, and then pop open the options dialog (create or verify,
        depending on the task), where you can set your options for the scheduled

        You can also have schedule setup as your default startup command (see
        below - v1.5.2.0 changes)..


    +   You can now get to the "Edit Prefs (ini)" tray menu option when checksum
        is started with nothing to do.

        Custom Startup Command..

        When checksum is launched with nothing to do, rather than have checksum
        display the "Nothing to do!" dialog, you can have it do something
        /else/. This might be a default checksum command that you use a lot, or
        another program, or something else. e.g..

            startup_command=simple checksum.exe
            startup_command=c:\path\to\some\program.exe /foo /bar
            startup_command=c:\path\to\my editors\editor.exe /open "i:\my\document.doc"
            startup_command=c:\some app.exe  c:\some documents\document.txt

        For checksum commands, send your regular command-line after a "checksum"
        flag; the word "checksum", with a pipe character after it, e.g..

            startup_command=checksum|crtbim(movies) "W:\Completed Torrents"

        And checksum will launch itself with the specified command-line. Simple.

        If you use something like:

            startup_command=checksum|cor "C:\"

        Clicking on checkum.exe (or a shortcut to it) will startup checksum with
        the one-shot creatino options dialog open, so it seems like you are
        running a "regular" app! You can drag and drop in a folder, go for

        You can have checksum jump straight to the (almost) hidden System Info


        NOTE: If a DOS command isn't working as expected, use the DOS
        compatibility flag "dos", e.g..

            startup_command=dos|compact.exe /C "B:\hashes\*.*"

        ALSO NOTE: like many prefs, you can use @tokens in this setting.

        There is also a special "shellex" flag, which I will now explain..

        Normally, a command-line is an executable, optionally with some switches
        and parameters required to complete the job. But you may want to launch
        something else, for example a document or URL. For this, you can use the
        "shellex" flag. The "shellex" flag performs a system "Shell Execute",
        which can be used to launch just about any "thing". It goes like this..

            startup_command=shellex|Item|Parameters|Verb|Working Dir

        Only the "Item" is required. All others are optional, for example..


        which will launch an internet shortcut I have on my desktop. Using the
        "shellex" flag, you could also launch the URL directly..


        The default verb is whatever your system would normally do with the path
        you send, usually "Open". But you can (usually, though not always) use
        any verb avalable from your Explorer context menu, e.g..


        NOTE: the double || because in this example, I don't want to send any
        parameters but DO want to send a Verb. In other words, if you want to
        skip a previous flag, leave it blank.

        The many, many uses for this feature should be obvious. Self-contained
        on-disk data checking is but one of them!

        Finally, there is a prefs flag..


        ..which opens up the checksum preferences (ini) in your preferred text

    ~   Improved relative path handling (again), you can now use .\ and ..\
        constructs to checksum the current or parent directory. This is
        especially useful when using checksum in a stand-alone mode, e.g.
        when burned to a disc for on-disc data checking.

    +   You can now set the string checksum uses to construct names when
        creating .hash files from files with no names. By default, this is
        "nameless". If you set this to blank, checksum can potentially create
        ".hash" files, which may become invisible on some systems. This may be
        what you want. Though it rarely happens, it is now configurable.

    *   checksum will no longer perform a writeability test of the hashing
        location where a custom output directory has been set (it will now
        properly test the custom output directory). Another upshot of this is
        that the original folder's modification time will not change.

    simple checksum

    ~   fixed folder compare command-line to match new custom output directory
        switch requirements in checksum. Oops!

    +   Added new beta_channel preference.

        I've (finally!) settled on simply releasing betas to anyone who wants
        them, which is better for you, less work for me.

        You can set this preference in your ini..


       .. to get notified when updated betas become available (as well as the
       major releases). By default this is set to false, so you only get
       notified of major releases.

       Major releases supercede all previous beta releases. The beauty of this
       setting is that it will survive switching to and from a major release
       when /it/ becomes the latest version.

       Beta and release versions now behave exactly the same way - if you have
       beta_channel=true set, as soon as a beta becomes available, you get a

    *   Fixed an issue where hidden checksum files were not being updated (when
        using the w switch during verify).

    *   Fixed an issue where portable relative paths on the command-line were
        being ignored. This means that you can now easily script self-contained
        disk checking mechanisms with checksum on, for example, burned DVDs.

        This was possible before, but not without obscure DOS substitutions.

    *   Fixed an issue where using braces in the custom output directory would
        fail (checksums left on desktop, instead).

        Note: You need to put custom output directory switches LAST, after other
        bracketed switches, for (complex) example..

            cr1qnm(movies)j(my-hashes)d("c:\some (dir) here""D:\My Movies" [public release]

    ~   The monthly Shirtware reminder will now only bug you a maximum of three
        times before disappearing for another month. Previously it would keep
        bugging you until you click "Yes" ONE TIME! - still the best way to get
        rid of it!

    *   fixed a bug where the initial version check dialog could appear under
        the one-shot options if you quit checksum's very first run.

    *   Fixed a bug where choosing the "About checksum" options from the menu,
        during an operation, would quit checksum.

    *   Fixed a silly bug in the queue handling.

    ~   When queueing multiple items in Explorer with the <SHIFT> key held down,
        checksum will now apply whatever options you set for the /first/ item to
        the /entire/ queue. If you would prefer to have the options dialog pop
        up for each item (the old behaviour), set this new preference..


        When set to true (the default), checksum will also automatically check
        the "quiet operation" checkbox for you (if quiet operation is not
        already enabled), to prevent multiple final dialogs (if enabled) from
        popping up; assuming you want minimal interaction with the jobs. Of
        course, you can deselect this if you really want to see (and click!)
        /all/ the final dialogs.

    +   checksum will now check how much free space is left on the target drive
        before beginning to write a hash file. If it estimates that the drive
        will run out of space before completion, it will halt with an error to
        that effect before it begins writing hashes.

        Note: checksum will err /slightly/ on the side of caution in its

    +   When creating root hash files with absolute paths, you can now choose to
        either always store UNC-style paths in your .hash file (the default) or
        not. If you set..


        .. checksum will use old-style paths for short paths and switch to
        UNC-style paths for long paths (that is, paths with more than 259
        actual characters).

        Note: checksum works with UNC-style paths internally so setting this to
        true will be slightly (microseconds) faster when writing each hash.

   ++   The tray ToolTip will now display some basic information about what
        checksum is doing, for those that prefer to run with the ToolTip Windoid
        disabled (which is faster when dealing with lots of small files).

    ~   Optimized the non-hash file test and hash file line counting routines.
        Every millisecond counts!

    *   Fixed an issue where dropping multiple files onto checksum's one-shot
        create options dialog input where one or more of the files had no
        extension would produce an incorrect entry in the masks list, i.e. "*.".

    *   Fixed a bug where choosing to show absolute paths in root .hash files
        created from the root of a drive would not show their UNC-style prefix.
        checksum can handle this just fine, but it was inconsistent with
        absolute path root hashes produced from some path deeper inside the
        drive (which do show the UNC-style prefix). Also, other hashing apps
        would most likely choke on long path with no UNC prefix, that is, if
        there were any other hashing apps that could handle long paths to begin

    *   Fixed a bug in the show_unc_paths preference, which was being partly
        ignored when set to true.

    *   Fixed a bug in recognizing single "piped" hashes with no line-breaks.

    *   Fixed a bug where selecting multiple files to hash directly after an
        upgrade could scramble checksum's ini file. Of course there was a backup
        made, but still. Ouch!

    *   Fixed a bug in the version checking routines - unless you had already
        set the interval (in the release version or manually) you would never
        get the option to do so!

    +   You can now drag multiple items onto the one-shot create options path
        input and checksum will create a file mask group from the dropped items,
        for example, if you dropped these three files..


        The path: input would be set to "E:\Docs", and in the file masks input
        you would have "*.pdf,*.txt,*.doc".

        As usual, the resultant .hash file would contain only hashes for files
        matching these extensions.

    ~   When launched with a file on the command-line (via Explorer right-click,
        etc.) the file name will be placed and selected in the masks input.
        Previously it not selected. As before, if a folder is sent, the masks
        input is set to the default mask "*.*".

    ~   When dragging files onto checksum's one-shot create options dialog, the
        name of the file will now be added to the masks drop-down list and
        selected in the file mask: input. Previously it was added to the
        drop-down list but not selected.

    ~   Some more minor cosmetic fix-ups, out-of-place linefeeds in read-only
        notices and such-like.

    *   Fixed a bug with setup where installing an old version over a new
        version would send the installer into a dialog loop (if the user chose
        to uninstall the newer version first). Of course, almost no one would
        attempt such a thing, but still. This should now work as expected.

    ~   Minor fixes in cosmetics, text placement in dialogs and such.

    *   Fixed a bug in setup where uninstalling checksum after multiple upgrades
        of previous versions would leave files in the ProgramData folder. This
        was due to a mangled entry in HKEY_LOCAL_MACHINE\SOFTWARE\corz, which I
        had recently introduced changing the "long" name from "corz checksum
        utility for windows"
 to simply "checksum", which I did because people
        kept naming checksum, "corz checksum", which was mildly annoying! It's
        corz as in "Cor's", see? No? Oh, forget it! ;o)

    ++  We have a new algorithm! checksum can now create BLAKE2 hashes of your
        files. For more information about BLAKE2, see here:


        You wanted a strong hashing algorithm - it doesn't get much stronger
        than this!

        BLAKE2 is superior to any of the SHA2/3 family of hashing algorithms,
        offering the best security available in a cryptographic function, yet is
        comparable, speed-wise, to our current SHA1 hashing (on x64, it's faster
        - last night I hashed 1TB of archive files, whilst working away on other
        things on my busy workstation, in under three hours - pretty good).

        Technically, checksum uses BLAKE2s-256, producing digests (hashes) of
        sixty four characters in length. The code is based on the public domain
        C implementation of BLAKE2s by Samuel Neves, available from the above

        Thanks to Alberto for turning me on to BLAKE2 - Impressive Stuff, Sir!

    ++  During verification, checksum can now update (aka. "refresh") hashes of
        CHANGED files. This enables you to automatically update your .hash file
        with new hashes (and timestamps) of files you have /mindfully/ altered.

        Lots of people asked for this!

        NOTE: you need timestamps (check_date=true) for this to work.

        IMPORTANT NOTE: checksum can only update hashes for checksum-created
        hash files. When verifying non-checksum hashes (e.g. piped Open SSL
        hashes) there are only two states, OK and CHANGED. CHANGED files MAY be
        corrupt, but checksum cannot know this because there is no date/time
        information stored with the hash. So, if you request that CHANGED files
        be updated, only those inside checksum-created hash files will be
        updated. It may seem inconsistent, but actually makes perfect sense!

    ++  The one-shot options dialog has been expanded and now includes BLAKE2
        hashing (of course) as well as new options for custom output directory,
        quiet mode, and shutdown when done.

    ++  The one-shot create options dialog is now resizable, in case you have
        your screen fonts set to some large size (for accessibility reasons) and
        the options are squished together.

        By the way, I recommend KDE-Mover-Sizer for quickly resizing *anything*.

            See here:

        Note, if the above paragraph applies to you, you will probably want to
        create the following two preferences in your checksum.ini, to have the
        options dialog permanently resized..


        Those are the minimum sizes allowed, but you can set them to anything
        you like, within reason (i.e. your desktop size).

        This is a bit of a hack, but hopefully should help anyone who needs it.

    +   The one-shot verify options dialog has also been expanded to include
        BLAKE2, as well as adding options for deleting hashes for missing files,
        updating changed hashes, go to log folder on log creation and shutdown
        when done.

    +   The verify options dialog is now also resizable, like the create
        options, for the same reasons, and with corresponding checksum.ini hacks
        available for permanent resizing..


        Again, those are the minimum settings, so feel free to make it bigger,
        if required.

    +   Added experimental support (designed for automated folder compare -
        see simple checksum changes, below) for supplying the hashfile_name on
        the command-line. The swith is "j" (as in "John" - it's the last letter
        available for switches!). As with output dir, you enclose the name in
        brackets directly after the switch, like so..


        Just like the hashfile_name preference in checksum.ini, you can use
        dynamic tokens with this name.

        NOTE: you CANNOT successfully use this in the options dialog switches
        input. If people request it, I will consider adding this facility to the
        one-shot options.

    ~   checksum will no longer automatically fill in your ignore_types
        preference with its default basic values (md5,sha1,hash,sfv,crc), so if
        you really want to, you can make .hash files of .hash files!

    ~   Updated the CSS files with styles for DELETED and UPDATED hashes. I also
        put back the fallback background images from - they somehow got
        removed during my HTML5 update. Sorry about that!

        NOTE: If you have edited your CSS file (the one sitting right next to
        checksum.exe) You will need to delete/rename it to get an updated CSS
        file with the new styles. checksum will only update the file if it is
        unchanged from the original install (v1.3.*/v1.4.*b).

    ~   Optimized the read-only checking routines - the long path support makes
        things easier, which is ironic, because it was the new long path support
        that had slowed it in the first place! This will only be noticable if
        you are creating individual hashes of LOTS of small files.

    *   Fixed a bug in the verification algorithm choices and made the tooltips
        clearer in the verify options dialog. Hopefully the behaviour now makes

    ~   Updated to the setup program slightly. It should now be more friendly
        on XP (no one is still using XP though, right?), as well as prevent
        users from installing the x64 version of checksum on 32 bit systems.

        Also, it won't attempt to install dividers on XP, because they simply
        don't work!

    !!  On Beta build, you can put do_debug=true in your ini file and get GOBS
        of debug output in the working directory. If you are reporting a bug,
        PLEASE send me this output (as well as a copy of your checksum.ini).

    simple checksum

    +   simple checksum can also calculate BLAKE2 hashes of files and strings.

    +   When getting the actual hash of compared files (with ALT+C) the title
        bar will momentarily display the name of the file the hash corresponds

    +   The simple checksum window can now be resized. There is no accessibility
        reason for this, but I thought you might like to a) be able to see your
        entire BLAKE2 hash, or b) make it *really* small, for extended desktop

        A good size for seeing all BLAKE2 hashes is simple_width=460, but you
        don't need to set that - simple checksum will remember whatever width
        you resize it to. Changes in height are ignored.

    +   Added folder compare. That's right! So long as checksum is installed,
        simple checksum can now happily accept two folders on the command-line
        (or via drag-and-drop, etc), and will automate the process of hashing
        both folders in turn (using checksum), then compare the two resultant
        .hash files (by hashing, of course). If they are identical, you get..

            "Folders MATCH!"

        If they are NOT identical, you get..

            "Folders DO NOT MATCH!"

        Simple as that!

    ~   simple checksum now hides the "hash it" button during hashing
        operations, to prevent users from accidentally creating false hashes
        by clicking it during a hashing operation (the click would be buffered
        and the final hash would be a hash of a hash!). [beta]

    ++  Added CPU process priority option, an integer from 0-5 (0 = low/idle,
        5 = realtime). The default is 2 (Normal). Setting a priority outside
        this range gets you 2 (Normal)!

    ++  During a verify operation, checksum can now remove hashes for missing
        files from your .hash file

            pref: delete_missing_hashes=true
            command-line switch: x

        Once set, this will happen transparently, unless you have chosen to log
        "everything", in which case they will show up in your logs as "DELETED".

        There is also a notice in the final dialog which lets you know how many
        hashes were deleted, if any.

        NOTE: Whenever checksum deletes hashes from a hash file, a backup is
        stored in your system temporary folder, named
        "checksum-deleted-backup.hash". If you make a boo-boo, for example, by
        enabling this preference and clicking on a fallback .hash file, you can
        always grab the original from there; at least until you repeat the

        ALSO NOTE: If ALL the hashes inside your .hash file are deleted, the
        file itself is also deleted.

        This "post-processing" capability opens the door for other post-job
        tasks we might need. Watch this space!

    ++  checksum can now shutdown your computer at the end of an operation.
        Handy for big jobs on systems that don't run 24/7.

            pref: shutdown_when_done=false
            command-line switch: z

    ~   If you had the <SHIFT> key down whilst queuing a job in explorer,
        that will be remembered (the options dialog will pop up). If you had it
        pressed while selecting multiple files, it will pop up for each job.

    ++  Added support for TAB delimited hash files. I have never seen one of
        these in the wild, but a couple of checksum users have assured me that
        they do exist! Enjoy!

    ++£ You can now hide the "Edit ini" tray and context menu items to prevent
        underlings having easy access to the main settings.

    ++£ You can now disable the preamble altogether, if required. This had
        existed for a while, but there was no preference for it.

    +   checksum beta releases now have their own version checking URL, so if you
        are playing with the betas, you can be assured of staying up-to-date
        with the latest developments.

    *   The ToolTip windoid and synchronize dialog will now honour your
        show_unc_paths preference.

    *   Fixed a bug where slashes were being used instead of backslashes in
        relative paths. checksum doesn't mind either way, but passing your .hash
        file to some other (lesser!) hashing app might have caused problems.

        Note: You still get forward slashes when nix_paths is enabled.

    *   Fixed a minor bug where the backup ini file had a double .ini extension.

   !~   checksum will no longer work with Windows 2000. XP is the required
        minimum Windows OS version.   [beta]

   ~++  The hashing library has been rewritten to correctly handle UNICODE file
        names/paths. Now we can happily hash Russian, Japanese, Greek, anything!
        This works regardless of your current locale.

        The previous "upstream" changes were problematic, so I bit the bullet!

   ++   Support for LONG PATHS (beyond the Windows MAX_PATH limit). That's
        right! You can now hash files with paths as long as 32,767 characters!

    +   Improved error handling in hashing library. Your .hash file will now
        correctly inform you of permission denied and other error states.

    ~   The convert_names and convert_level preferences have been removed,
        with full UNICODE file name handling there is no need for it, ever!

    ~   The log folder will not open automatically if it is already open on your

    ~   The dialog that pops up if some of the hash files were invalid is now
        editable, so you can copy/paste the information somewhere / open the
        location, etc., if required.

        Note: This dialog respects your dialog_timeout preference, unless you
        click inside the editable area, which halts the timer.

    *   A few other minor fixes and optimizations.

    *   Fixed an issue on TrueCrypt drives where certain ignored folders being
        set would halt checksum.

    ~   Improved handling of files where the user's Anti-Virus software has
        denied access to the file (or rather, presented it as a zero byte file)

    ~   Improved handling of fall-back where checksum was unable to write .hash
        files due to the location path exceeding the Windows PATH length

  1.3.6 [current release version]

        You thought the old version of checksum was the fastest hashing
        application in the world? Try this!

   ++   64 and 32 bit versions now available.

    +   Significant increases in the hashing speeds in both 32-bit and 64-bit
        editions, thanks to the improved compilers (and compiler options)
        available today, as well as some code tweaks implemented during the
        64-bit DLL update (now at v0.6). I have also switched out the SHA1
        routines for something faster, for example..

        My DVD-sized "BIG.iso" test file used to MD5 hash (on my current system)
        in 24.3 seconds. Pretty fast. That time is now under 16 seconds both the
        32 bit and 64 bit editions. A SHA1 hash of the same file used to take
        41.8s. It now takes less than 24s. As they say, YMMV, but I am looking
        at speed increases of between 60% for MD5 and 79% for SHA1 <insert
        exclamation point>.

        Of course, the rate at which your system can get the data off your drive
        will always be the limiting factor. And though the latest checksum is
        tuned to deliver maximum disk data throughput, with 300MB/s hashing
        speeds, no current hard drive can keep up.

        SSD users, enjoy!

    ++  International file name handling on >= Windows 7; Russian, Japanese,
        whatever. This change is upstream, so I am keen to hear reports on it
        working or otherwise on YOUR system.

   ++   checksum can now optionally store a file's modification date and time
        along with the checksums, like so..

            #md5#Björk - Hunter.flac#2009.09.26@19.49:36
            fba7b0f424d3c217d312bcd84728ac8f *Björk - Hunter.flac
            00073fa1652f74961c1a9696afa7a992 *Desirée.flac
            5deee1f6ac75961d2f5b3cfc01bdb39c *info.nfo

        Thanks to the extra information, during verification checksum will
        report files with mismatched hashes as either "CHANGED" (they have been
        modified by some user/process) or "CORRUPT", where the modification
        timestamp is unchanged.

        These will show as a different color in your HTML logs (assuming you
        are using an updated master CSS file).

        You can also now choose whether or not to report (and log) missing,
        changed, or corrupted files. For example, if you only want to know about
        CORRUPT files, but don't care about changed or missing files, you would


        As one commenter on the checksum page pointed out, with this sort of
        functionality, checksum would become "the only tool against silent data
. I believe this goal has now been achieved.

        The chosen algorithm is also stored along with this information, for
        possible future use (aye, more algorithms!).

   ++   checksum can now post its completion times in a more readable format,
        rather than using only seconds..


        This affects not only the message and ToolTip windoid displayed at the
        end of checksum operations, but the times shown in the logs (if you have
        that enabled).

    +   checksum will now check online for newer versions of itself. This is
        configurable in checksum.ini - you can set how many days to wait between
        checks. After installation, it will ask you one time about how regularly
        to check for new versions. If you want to change it after that, you will
        need to edit the ini. Feel free to check daily, my server can handle it!

   £++  Customizable preamble string (the comment at the top of the .hash file)

   £+   Customizable "licensed to" name in About Box.

    +   New software licensing model. From your side of things, the biggest
        change is that everyone now gets their own specific key. Also it's a lot
        easier to enter!

        There is a facility for existing Licensed users to upgrade their
        license key, here:


    +   setup now puts icons in the context menu on systems where this is
        possible. It also installs "Directory Background" menu items (the one
        you get when you right-click . This almost makes up for the loss of
        Windows 7 app menu functionality, at least for checksum!

   ++   Rudimentary queueing system. Rather than warn you about running multiple
        copies on the same disk, checksum now has the option to queue jobs. If
        checksum is already running and you launch a second copy (maybe by
        selecting multiple items in explorer and doing a checksum context
        command on them), it will add the job to a simple queue file which
        checksum checks on exit. If there are jobs there, it launches itself
        with the job, deletes it, and so on. It's nothing fancy, but it works.

        Note: if you do this sort of thing a lot, you will probably want to
        increase the long_operation time in your preferences.

    ~   checksum grudgingly now uses plain ANSI for regular .m3u files and
        enables  users to select .m3u8, if required. It's a real pity "they"
        didn't just keep one extension, but certain music players will balk on
        UTF-8 .m3u files, so this has been added for maximum compatibility. pls
        files are still always UTF-8.

    ~   If you have the ToolTip disabled, left-clicking checksum's tray icon
        will show the Progress ToolTip, so you can see what's happening.

        Previously, left-clicking the tray icon performed no action.

    *   Fixed an issue where if you had the ToolTip disabled on launch and then
        quickly enabled it while checksum was in the middle of a long operation
        (for example, gathering the hashes for a large folder) you would get a
        blank ToolTip (until the next ToolTip message was posted).

    *   Fixed a minor issue where the one-shot verify options audio alerts
        setting would initially display the setting for the progress tip!

    *   Fixed an issue where checksum would unhide previously hidden checksum
        files if checksum hiding was off in the prefs. Now it will leave them

    ~   The keep_dll setting has been deprecated - now it just stays put in
        portable mode.

    ~   The binaries are no longer packed. Originally, it was fantastic, being
        able to fit the whole lot onto a floppy disk, but you have to ask
        yourself, "what the hell is a floppy disk?"

      simple checksum 0.8.4 [current release]

    ~   simple checksum will now strip any white space from hashes in the
        clipboard when comparing against dropped files. This is useful when
        the user has copied the hash from a web page with an extra space or
        line break at the end (usually unwittingly). It is also useful when
        comparing against hashes which have been presented "split", like so:

            1852 fd05 0afa 3693 2a00 2c4d 08b9 b37b

        Note: simple checksum will not alter the clipboard data in any way, it
        will simply remove all whitespace before comparing against the hash of
        the dropped file.

    +   simple checksum will now do automatic clipboard compare from initial
        launch. This is in addition to during all drag and drop operations.
        Basically, if there's a hash in the clipboard when you hash a file, via
        any route, simple checksum will attempt to compare the hashes.

        Alt-C gets you the actual hash, if required.

    +   A new option has therefore been added to the menu: "Clear the Clipboard".

    +   New About Box, more in line with checksum and my other apps (but there's
        no SysInfo, which would be too much duplication - you can get that from
        checksum if you really need it).

    +   simple checksum will now post an error message if your chosen (ini) editor
        could not be launched, as opposed to simply doing nothing.

    ++  By request, I have added a switch to take you directly to the SysInfo box
        easter egg. That switch is "SysInfo" (no quotes). Enjoy!

    *   Fixed a bug where simple checksum would continue, even in the absence of
        the hashing library. Now it will post its message and exit.


    +~  There have also been a few improvements to the installer (setup) app. It
        is now 64-bit aware, as well as being better at cleaning up after itself
        (specifically, it will no longer leave an empty top folder in your app
        data folder after a complete uninstall).


    ++  You can now specify an output directory for your hashes, either in


        Or with a command-line switch ("d") This uses the same form as file type
        groups (i.e. in braces), like so..

        crid(C:\hashfiles) "D:\some documents"

        In this example, checksum would hash the files in "D:\some documents"
        and put the .hash files in "C:\hashfiles".

        Please be careful with this, mindful of the ramifications, especially
        if you also have a static custom hash file name!

    ++  There is a new @parent token which you can use in your "hashfile_name"
        preference; it will be replaced with the name of the parent directory of
        the file being hashed.

        You can also specify how far "up" to go when determining the name to
        use, like so: "@parent+1""@parent+2" and so on, as high as you like;
        checksum will transform the @parent token into the currently selected
        parent directory (+2. etc.), all the way up to the drive letter itself.
        Thereafter, checksum will return an empty string.

        NOTE: "parent" refers to the parent of the FILE(S) being hashed, so when
        performing a folder hash on "C:\foo\bar\foobar""foobar" is still the
        parent (of the files being hashed). If you need "bar" in your custom
        name, use @parent+1. To get "foo", use @parent+2, and so on. In this
        example, @parent+3 would return "C", the drive letter, @parent+4, +5,
        etc., would return an empty string.

    ++  You now have the option to cancel a hashing operation in mid-stream.
        Simply hit the <Pause/Break> key. This change is inside hash.dll.

        This is especially handy on slower machines, when hashing very large
        files and you need access to all your CPU cycles for a moment,
        effectively using the "Abort Hashing?" dialog as a <pause> control.

    +   checksum will now check the version of its hashing library and
        automatically update the dll file to the newest version, if required.
        This is handy if didn't run the main installer.

    +   Improved static memory usage.

    ~   "Individual""extensionless" checksum files of files beginning with a
        dot will now be given the name, "nameless", for example, an extensionless
        individual checksum file of a file called ".foobar" would be named,
        "nameless.hash", rather than create a .dot file (".hash"), which can
        become automaticaly invisible under certain configurations.

        Most of these sorts of files would likely be better entered into your
        ignore prefs, in checksum.ini.

    ++~ checksum now correctly verifies only hashes of the algorithm specified.

        With the advent of unified hashing, this process needed to work on a
        per-hash basis, as well as a per-file; both SHA-1 and MD5 could be
        contained within the same file (i.e. "foobar.hash"), as well as within
        filename-specific files like "foo.md5" or "bar.sha1".

        checksum now verifies only the hashes you specify, ignoring the other
        algorithm altogether. checksum will also not load old-school hash files
        from other algorithms, i.e. when asked to check only SHA-1 hashes,
        checksum will ignore a file named, "foobar.md5".

        Only if you specify an alogorithm either on command-line ("am" for MD5,
        "as" for SHA-1), or in the one-shot options dialog (hold <SHIFT> on
        launch) will checksum use this behaviour, otherwise the default
        behaviour is still to verify ALL hashes in ALL hash files encountered in
        the path.

    *   Fixed a bug where folders set in "ignore_folders" would only work
        inside the folder itself, but not folders inside that, and hashes were
        being created in its subdirectories. checksum will now correctly skip
        all folders specified in your "ignore_folders" preference, and all
        folders inside, and so on.

    *   Fixed a bug where checksum could crash if you had an instance open
        at the one-shot options, and opened a second instance of checksum.

    *   Fixed a bug where an extra line-feed character could be added to the
        end of files during synchronization, if those files contained hashes
        with file names using special characters.

    *   Fixed a bug where synchronizing UTF8 files with special characters
        which had been saved (manually by the user) without their BOM (Byte
        Order Marker), resulted in the hash file being re-saved as ASCII,
        duplicating the file hash, and potentially mangling the results.

        checksum now correctly opens UTF8 files as UTF8 when specified to do so,
        rather than converting them to ASCII if you deleted the BOM somehow.

    *   Fixed the SHA-1 bug in files greater than 4GB (Thanks to qriist for
        spotting this error and to Michael D. Leonhard for the C++ help in
        fixing it, and the original SHA-1 code, of course).

        Previously checksum produced erroneous (though quite consistent) results
        with the SHA-1 algorithm on files greater than exactly 4GB. This was
        caused by an internal overflow within checksum's hashing library.

        checksum's SHA-1 handling is now fast AND accurate, at any file size.

    +   Added an input dialog for the shirtware registration code.
        Five bucks, people!

    *   Fixed a bug where running checksum with an empty checksum.ini file would
        throw up a fatal error.

    ++  You can now set the default file mask in your preferences.


        Normally this defaults to "*.*" (checksum ALL files), but you can use
        whatever you need. Most people will not need this - the one-shot options
        dialog is usually a better way to set these things, on a per-job basis.

    *   Fixed a bug where exiting from a long verify operation with no errors (so
        far) could throw up an empty dialog box (the tooltip shows the full status)

    +   added a preference (convert_names) which will convert any truly foreign
        file names that do not map correctly (i.e. Russian), into old-school 8.3
        file names, which should enable you to hash *anything*.


        Hopefully this is a stop-gap measure until I can justify a re-write of
        the hashing library to use "boost" or similar to handle file names in
        *any* language. This will produce a very slight overhead, which is why
        it is optional, only for those who really need it.

        NOTE: most languages are handled correctly by checksum already, without
        using this preference, for example these files..

            Björk - Hunter.flac
            The First Noël.mp3

        would be hashed and verified just fine, without any additional settings.

    +   checksum now posts which algorithm it is currently checking in its

    +   checksum now logs which algorithm has changed (when logging is enabled).

    *   Fixed a potential bug where checksum could fail to write hashes if the
        file's name was very short and its path was *almost* at the system's
        maximum file length. checksum now tests a variety of random names of the
        exact same length as the .hash file name, before deciding if a location
        can or cannot be written to.

        Although this checking is very fast, it should be noted that checksum
        tests the writeablility of every .hash/.md5/.sha1 file which is to be
        written, and then has to write that file, so "root" hashing a large
        filesystem will always be faster than using individual .hash files.

    +   I added a spacial "portable" command-line switch. In line with my more
        recent apps, checksum will setup itself for total portable operation,
        without you having to fish out an ini file or set your logging location
        preference. To activate this one-time operation simply run..

            C:\Path\to\checksum.exe portable

    ~   The (much loved!) "command-line error" window (which you get if you
        launch checksum with no drag-and-drop or command-line switches) has been
        renamed and made smaller (to fit into netbook windows). You can also
        move it around by clicking and dragging anywhere within the main window
        (in the text - for those poor souls not running KDE-Mover-Sizer).

        It still does the same things, but now has more logical buttons, as well
        as one that takes you to the checksum tricks and tips page which
        explains the whole switches topic in greater detail, as well as lots of
        other useful tricks for using and getting the most from checksum.

    +   I dropped my "Checksum For Linux" distribution into the extras folder.
        Have fun with that!

    ~   I noticed in my (long) 2do list that I meant to mention that checksum
        now sets the working directory (to its own directory) when running in
        portable mode.

      simple checksum 0.7

        +   Added new "Auto" sub-menu to the application menu, with two options..

                Auto Copy to Clipboard
                Auto Save to File.

            Use these options with caution; the Auto Copy will replace whatever
            was in your Windows clipboard with the current hash, be it file or
            string hash, and the Auto Save will write a hash file next to the
            dropped file, overwriting any file previously in that location. A
            warning dialog displays the first time you enable the setting.

        +   If Auto Save is enabled, and you re-hash a dropped file with the
            other algorithm, simple checksum will re-write the saved hash file
            with both algorithms stored inside - it won't attempt another hash
            write until you drag and drop a new file, even if that is the same

        *   Fixed a bug where if you switched case after calculating both MD5
            and SHA hashes, and then switched the case back, only the current
            algorithm and future algorithms would comply, but the stored
            alternative algorithm would still be in the old case.

      simple checksum 0.8 [currently available beta]

        ++  simple checksum now accepts two files for comparison, either on the
            command-line, or via drag & drop into its input. I'm glad to get
            this off the 2do list, if only to stop folk asking for it!

            I've had to rewrite the way file paths are read from the user input,
            hooking directly into the drag and drop process, so any bug-reports
            will be gratefully appreciated.

            By the way, you can retrieve the actual hash by hitting Alt-C. If
            the two hashes were different (NO MATCH) you can get the second hash
            by clicking ALT-C a second time. ALT-C will then toggle you between
            the two file hashes.

            If you have AutoCopy enabled, a small report, with file names,
            hashes, and comparison result will be deposited in your clipboard.

      simple checksum [current release]

        +   If you drop a file onto simple checksum's input and there is already
            a hash in your clipboard, simple checksum will compare the hash of
            the dropped file with that in the clipboard and report whether or
            not they match (rather than report the hash string - if you need
            that, IT'S IN YOUR CLIPBOARD!)

            This makes it a no-brainer to compare the hashes of download files
            with the hashes published on web sites, simply copy the hash from
            the page (Select it, Ctrl-C) and then drop the downloaded file into
            simple checksum. TADA!

            NOTE: simple checksum will automatically switch between MD5 and SHA1
            depending on the type of hash in your system clipboard.

            NOTE: If you have Auto-copy-to-clipboard enabled, it will not
            activate when comaring hashes with the clipboard, your original hash
            will still be there after the operation.

        +   Reduced memory usage (unused pages are now freed when hiding with
            the tray icon, as well as the usual minimize button).

        +   Improved ToolTips, reflecting new functionality.

        +   Added startup message about the application menu (so folk know it's
            there). You get this only once.


    +   Added a preference for individual_hashes, which can now be set
        permanently, if you wish. This is the same as passing "i" in your

    *   Fixed a bug (bugs) where certain checksum options set in checksum.ini
        were fixing that behaviour, even though the user had re-enabled the
        default behaviour temporarily in the one-shot options dialog.

    +   checksum now uses a more flexible and logical switch transformation
        routine internally, so any switch that also has a preference in
        checksum.ini, can now be switched *off* from the command-line, which,
        depending on the preference, may be to enable or disable the setting,
        for example..

        Normally, root hashing is disabled. You can enable it by adding a "1"
        to your command-line switches. You can also enable it *permanently* in
        checksum.ini. IF root hashing is enabled permantly, you can *disable*
        it, temporarily, by adding "-1" to your switches.

        In other words, "-" disables a switch.

        This behaviour is now true of all switches that also have a
        checksum.ini preference, which is most of them.

        Later preferences override earlier preferences, if applicable - the order
        of preferences inside checksum.ini has changed to accomodate this logic.

        Command-line switches override everything.

    +   Command-line switches are now displayed dynamically in the one-shot
        create options (thanks to seVen, and hashDROP for reminding me about
        this feature!). You can add/remove switches there, too, and the many
        checkboxes will update to match (after you move out of the switches
        input). There's no real need for this in the verify one-shot options.

    +   Added the absolute_paths setting to the one-shot options dialog.

    +   Added a one-shot options checkbox for beeps (aka. "audio alerts").

        You can now get to all the create switches via the one-shot options
        dialog. No more Windows Run dialogs!

    +   Added a new "help_tips" setting, for folk who know what they are doing
        and don't need or want the helpful pop-up tooltips in the one-shot
        options dialogs (applies to both create and verify one-shot options).

    +   There is now a switch for the "Open log folder on errors" preference, so
        you can enable/disable that on a per-job basis, if required. The switch
        is "g", think "Go To Errors".

        Just like the other switches, if open_log_folder_on_errors is enabled in
        your checksum.ini, you can pass "-g" to disable it for a particular job.

    ~   The "open_log_folder_on_errors" preference is now more correctly named
        simply "open_log_folder", as it also works if there were *no* errors,
        but you have enabled "log_everything".

        Basically, if a log was created, "open_log_folder" will activate at
        the end of verification, or not, depending on your setting. checksum
        will automatically upgrade your checksum.ini file and import your old
        "open_log_folder_on_errors" setting.

    ~   The "open_log_folder" setting will now also activate in quiet mode. If
        you don't want this, pass "-g" in your switches, or disable it in your

    *   Fixed a bug where checksum would beep on completion when creating
        hashes, regardless of your beep settings.

    *   Fixed a bug where checksum would unexpectedly delete a root hash file
        where it was asked to synchronise to regular folder hashes. This
        behavior isn't so bad, it was simply unexpected. checksum will no
        longer delete such files, so you can keep both, if required.

    *   Fixed a bug where synchronizing a root hash file could get you
        duplicate hashes.

    +   checksum will now check for all possible path variants before
        synchronising a (root or folder) hash file, not just the currently
        used variant.

        Possible variants are; 1) full, absolute paths, 2) regular relative
        paths, and 3) UNIX ./ root paths, and any combination of these. Also,
        it's possible that root hash files could also be folder hash files.
        checksum will check for all possibilities before adding a new hash.

        Although I have improved the speed at which checksum interrogates
        hash files for possible matching entries; it will always be quicker to
        simply create a fresh hash file (perhaps after verifying the existing

        Actually, I've now re-written this to be *much* faster, so it should
        now be quicker than doing the (verify + create fresh) job manually.

    ~   checksum.ini now uses ";", rather than "#" as its comment character.

    ~   You can now leave the unix_hashfiles pref setting blank, if preferred.

    *   checksum will now correctly pop-up the completion dialog when a job
        took under 0.01 seconds to comlete, and long_operation is set to 0.

    +   Added a preference for "always_sync", which is just like adding the
        "y" switch to your command-line. Now you can set this permanently, if
        you wish. Like the other switches, you can disable this temporarily
        with "-y", which would bring back the "File Exists!" dialog.

    ~   checksum will now notify you if it switched your hash file extensions
        from extensioned to extensionless, and vice-versa. For example, you
        stopped using extensions, and during a re-hash, a file was renamed
        from "file.ext.hash" to "file.hash".

    *   Fixed a bug where creating individual checksums of files on read-only
        media would fail to create a hash file in the fall-back location.

    ~   Under fallback conditions, checksum will now recreate the *entire*
        directory structure inside the fallback location, the root folder
        being named after the letter of the drive, e.g..


        This removes any potential confusion about which checksums are which,
        where multiple hash files and/or locations could have similar names.
        This also means you can't accidentally create duplicate hashes by
        simply starting creation from a different root location inside the
        read-only volume.

    +   checksum will now check your currently open explorer windows before
        asking you if you would like to open the fall-back folder after
        creating fall-back (read-only) hashes. If you already have the
        fall-back folder (or a sub-folder) open on your desktop, checksum
        won't ask you if you want to open it (again). You need to have the
        Explorer Folder Option >> View >> "Display the full path in title bar"
        enabled for this to work.

    +   Added a new preference for "compress_logs", so you can disable this if
        you don't want checksum to compress any logs it creates.

    *   Fixed a bug where checksum would report files as missing if they had
        a checksum in their actual filename, e.g..


    +   I've added a preference for "ignore_folders" which works exactly like
        "ignore_files", when creating hashes. Useful for RECYCLER, System
        Volume Information, etc.

    simple checksum 0.6..

    ~   Removed the preferences dialog from simple checksum - with the
        creation of a more comprehensive application menu, and more HotKeys,
        it had become redundant - all changes are immediately saved, anyway.
        I got to remove a big chunk of code, too, which is always nice.

    ~   Changed Algorithm HotKeys from Ctrl+M/Ctrl+S to Alt+M/Alt+S, which
        seems more logical for algorithm settings, are easier to get to, and
        leave the path free for me to add a "Save checksum file" option.

        I'll use Alt for hashing and algorithm settings, and Ctrl for
        application stuff.

    +   Added a HotKey for "Always on Top", it is Ctrl+T.

    +   Added a HotKey for UPPERCASE hashes, it is Alt+U.

    ~   simple checksum's title bar now displays the application's 'short' name.
        This is neater. Also, if you use a gradient title bar, this will
        probably make the algorithm part of the title easier to read, which can
        be handy.

    +   When switching algorithms, simple checksum will now store the previous
        hash, so if you switch back to the original algorithm, rather than
        re-hash the file (which could be a large file, and therefore, slow),
        the stored value is re-inserted, instead.

        If you manually hash something, a string, etc., or perform a drag and
        drop, even of the same file, you always get fresh hashes (the file may
        have changed).

    +   You can now feed files to simple checksum via a regular file open
        dialog. The HotKey is Ctrl+O.

    +   simple checksum can now save hashes to a file. This is fairly
        rudimentary compared to checksum's hash file capabilities, but I
        figure if you have taken the time and CPU cycles to calculate a hash,
        you might want to save it. The HotKey is Ctrl+S.

        simple checksum will interrogate checksum.ini to discover your current
        line-feed and carriage return settings before saving the hash file.

        If you have created both MD5 and SHA1 hashes of a file, both hashes
        will be stored in the (.hash) file.

    +   The "hash it" button now has a context (right-click) menu for the Open
        File and Save Hash items.

    +   Added System Tray menu items for Open and Save.

    *   Fixed a bug where the on_top preference was being saved to the ini in its
        raw form (1/4 instead of 1/0) (note: simple checksum now uses true/false)

  1.0   [first full public release]

    +   Added an "Edit Prefs (checksum.ini)" item to the tray menu, so you can
        get this option easily, even with the Progress ToolTip disabled. Now
        the tray menu and Progress ToolTip menu are identical.

  0.9.24  [rc5]

    *   checksum can now use WAV files for notification, instead of PC speaker
        beeps. You can specify a wav for success, and another for failure.

        NOTE: if the specified wavs are invalid, checksum will revert to using
        your peecee speaker.

        I've dropped a few suitable wav files into the checksum extra files


        I had this penciled in for v2, but got an early request!

    ~   Removed the dividers from the Explorer context menu in the default
        install; if folk want those, they can uncomment the lines in setup.ini.
        Apparently these cause issues (weird entries) on non-english language

        NOTE: if you want to *remove* these dividers, simply uninstall checksum
        before running the rc5 installer. i.e. do not "upgrade". Your settings
        in checksum.ini will not be lost.

    *   Fixed an issue where checksum's automatic ini upgrade could leave
        unexpected comment lines tagged on to the end of the new updated ini.

  0.9.23  [rc4 - 1st public beta]

    *   Fixed a bug where under certain (unusual) conditions, checksum could
        fail to find your system's default browser, and crash. Now, even if
        you don't *have* a system browser, checksum won't crash about it.

    *   Fixed a bug in simple checksum where OnTop status was being saved to
        the ini file even when it hadn't changed. This could potentially cause
        system warning dialogs when running simple checksum in portable mode
        from read-only media.

    *   Fixed a bug in simple checksum where the current hash case setting
        wasn't reflected in the prefs dialogs (everything should happen LIVE).

    *   Fixed a bug in simple checksum where the options dialog position was
        only being read at launch time. If you moved your prefs, closed them,
        and them opened them again, they would be at the old position.

    *   Fixed an inconsistency in simple checksum's preferences dialog, where
        OnTop status was being immediately saved to checksum.ini, but
        algorithm and case settings were only saved if you clicked "okay". Now
        all settings are saved immediately. This was always true of setting
        preferences from the application menu.

        In fact, all the preferences are now in the application menu (and
        more), so the preferences "dialog", per se, is redundant. However,
        some folk may prefer this way of doing things, so there's no harm in
        leaving it in simple checksum, for now.

        Note: Ctrl+P also closes the preferences dialog, works as a toggle.

    *   Fixed a bug in simple checksum where the options window wasn't
        dynamically updating its transparency setting when you altered the
        main windows's transparency (if you had preference transparency
        enabled in your ini).

    *   Fixed a bug in simple checksum where the hashing dll was being removed
        on close in portable mode, even when you had specified in your
        (checksum) prefs that it should stay put.

    ~   simple checksum now checks for out-of-range transparency, wonky
        algorithm, and out-of-desktop window settings in the user's ini file,
        and automatically corrects them.

    +   In preparation for a release proper, checksum and simple checksum got
        funky new icons, including a larger 48x48 size icon. I also did new
        document icons, which now read, "hash"..

    +   Added unified hash extension.

        Rather than create .md5 files for MD5 hashes, and .sha1 files for SHA1
        hashes checksum can use a unified ".hash" extension for both type of
        hash. This is the way forward for hash files, methinks..

        checksum, uniquely (syat) interrogates potential hash files on a
        line-by-line basis, and so will verify both kinds of hashes, even
        mixed up in the same file; the file extension is irrelevant in
        determining the format of the hashes contained within. Also, in the
        future, there will likely be many more hash formats in general use so
        it makes sense to stop the senseless creation of extraneous file
        extensions in its tracks!

        NOTE: if the unified extension is enabled, checksum will merge
        ("upgrade") existing hash files to match, so you don't end up with
        both types, but only files of the algorithm you are currently using,
        so if you are using the MD5 algorithm, checksum will merge only .md5
        files in the path, not .sha1 files.

        In the unlikely event of both .md5 AND .sha1 hashes existing in a
        folder, running a second checksum create over the folder with the
        second algorithm, and choosing "Synchronize" from the "File Exists!"
        dialog will merge the second file into the .hash file, one hash at a
        time. Any new hashes will be added after that. Both MD5 and SHA1
        hashes will then be inside the .hash file.

        checksum still works with .md5 and .sha1 files exactly as it did
        before, and the unified extension is completely optional. And once
        enabled, you will still, of course, be able to verify all the old
        types. This is "extra" functionality.

        NOTE: The unified hash extension is ENABLED by default. If you *need*
        to use legacy .md5 and .sha1 files, simply disable this in your

        Hopefully other software writers, at least writers of software that
        utilize hash files, will adopt this unified approach, but for now,
        only checksum will create and recognize files with a .hash extension.

        BETA TESTERS NOTE. The "hash" extension will be automatically added
        to your "ignore_types" preference; you don't have to add it manually.

    +   Improved checksum's cross-platform Line Feed handling, and introduced
        a new master "line_feed" preference.

        checksum has always been able to open checksum files from any
        platform (even mixed up in the same file), now it can intentionally
        create them, too. At any rate, you can set a master line feed
        character, which will be used in *all* file writing, that is;
        checksum's hash files, text/html log files and music playlists.

        You can choose between "CRLF" (the Windows - and checksum - default
        Line Break character), "LF" for UNIX Line Feeds, and "CR" for Mac
        Carriage Returns. You only need this if you need to create hash files
        to be used on a specific non-windows platform.

        Most *nix tools can handle checksum files with Windows CRLF line
        breaks, as well as all Windows tools, of course, so that's the
        smartest default, but you may have other needs.

    +   Made a slight alteration to the olive.css - errors are now more
        clearly colored in olive logs.

    +   Introducing...  multi-hashing

        With the unified hash extension working beautifully, there was nothing
        to stop me; save the fear of throwing a spanner into checksum's
        finely-tuned inner cogs, and some fun coding; giving checksum the
        capability of *creating* files with more than one hash algorithm in
        them. Welcome to multi-hashing.

        SHA1 AND MD5 hashes in a single file. Yes, a clever inner wrapper
        enables checksum to do its usual synchronization, and line-by-line
        checksum interrogation, except rather than skip creating a checksum
        because one already exists, it will examine the existing hash format,
        and if the current algorithm isn't there, add the new hash.

        So now we have the capability to "multi-hash" (TM) our files, and
        all inside a single unified .hash file. e.g..

            28b7bef31e5fbda6cfb4a4990622c754 *golden boy ep1.avi
            f0d474af22b9e29843c6aeeb554b88ecac3d04ca *golden boy ep1.avi

        Multi-Hashing (patend pending) most likely has super-dooper security
        benefits, too.

        That's pretty much everything I wanted for a public release.

    *   Release delayed while I chase a few silly bugs I've recently

    ~   Rather than simply append any legacy .md5 or .sha1 files onto .hash
        files, checksum will now interrogate the file and add the old hashes
        individually. This prevents all sorts of potential unwanted situations
        and should make switching to unified hashing fairly painless, no
        matter what kind of hash you've been using previously, even if you
        used both - checksum will now synchronize everything inside a single
        unified .hash file, and add all new hashes into that file, regardless
        of their algorithm.

        I've still not decided whether or not to make unified hashing the
        default - I have a feeling that although it may alienate some people
        (those who wouldn't realize/find out that this could easily be set
        back to legacy .md5 files, if required), it's the way forward, and so
        helping folk get there is good. Hmm.

    ~   During checksum's initial interrogation of potential hash files,
        checksum will grab only 1MB of data from the file, which prevents
        someone from running into memory problems by doing something crazy
        like forcing checksum to treat an DVD ISO image as a hash file.

        NOTE: checksum will still check the *entire* file for hashes, which
        has no impact on memory usage, regardless of the size of the file.

    *   Fixed a bug where checksum could be forced to create a hash for a
        non-existant file (which would be empty). checksum will now halt with
        a warning if you send it any invalid path.

    ~   nix_paths paths (for one-file root checksums) is now disabled by

    +   checksum's ini upgrade process will now retain ALL sections of the ini
        file, even ones it doesn't know about. This enables writers of custom
        GUI/wrappers to store their preferences inside checksum.ini, and have
        them remain after a checksum upgrade.

        NOTE: checksum produces quite a few different exit/error codes which
        you can utilize in your applications. They aren't very clever, for
        now, but if there's enough interest, I could work up a more precise
        system. Let me know.

        This is a good place to let you know about hashDROP, a rather cool wee
        batch-processor GUI for checksum, which I got in my mail yesterday.
        Thanks seVen! Good work!

        For hashDROP, see here:

    *   Fixed a bug where your shirtware registration code could be
        obliterated during an install, and if then inserted, would crash
        checksum - I haven't paid enough attention to the registration aspect!

    ~   The Explorer context menu item for regular files has been changed to
        simply "checksum", which, as well as being neat and verb-like, should
        prove less confusing if people are using the Ctrl modifier to switch
        to verify mode; "Create checksum" would be plain wrong.

    +   checksum will now notify you if it applied any unified extensions to
        legacy hash files.

  0.9.22  [rc3]

    +   I've brought back the status information to the final verification
        dialog, in other words, it will now read..

         CHANGED » foo.jpg
         MISSING » bar.png
         CHANGED » foobar.png
         etc. opposed to merely listing the erring files. This functionality
        slipped away back in 0.9.17 when I created the fancy XHTML logging,
        but some folk (myself included) missed it, and so it has returned.

    +   checksum can now create music playlists (m3u or pls) with your "root"
        hash files, as well as with regular folder hashes. This enables you to
        create One Big Playlist for an entire music archive, or perhaps just
        your trance albums, or whatever you like.

        Note: the "nix_paths" setting for root hashes also affects playlist
        creation; both the direction of the path slashes, and whether or not
        there's a "./" at the start (true). The music players I've tested
        don't mind which way round the slashes go, or whether or not you put
        ".\" at the start of the path, so it's probably cosmetic, though I
        suspect some players might balk on back-to-front paths on one platform
        or another. All this is only really worth noting if you share your
        playlists with others, or other computing platforms around your
        network. And even then, like I say, most media players don't care.

    ~   It may not be noted elsewhere - I'll pop it in the prefs, too - but
        regardless of your checksum file encoding options, music playlists are
        *always* utf-8 encoded. If you know of a media player that can't
        handle utf-8, let me know. Same for the logs.

    *   Fixed a bug where under certain rare conditions (creating hashes for
        files on read-only media, where no valid hashable files exist; for
        example, they were all "ignored" types) checksum would create an empty
        checksum file along with the usual info file in the checksums folder
        on your desktop. These items are now created only when real checksums
        have been calculated for locked or read-only media.

    ~   checksum will now only attempt to set the compression bit on your main
        log folder; that is, the one set in your main preferences. It will
        still attempt to compress all individual log files, no matter where
        they are created.

    +   Added a setting for "warn_color", which is the color the progress tip
        will change to if there are errors. Previously, this was fixed at red.

    ~   Improved the content of generated info files (e.g. "checksum.nfo")
        which gets dropped when you create checksums for files on read-only
        media. I also did a wee ascii "checksum" logo. ;o)

    *   Fixed a bug where exiting checksum during the initial "building list
        of files"
 stage of checksum creation caused checksum to crash.

    ~   checksum will now always present a dialog at the end if you manually
        exit the creation job mid-way. The dialog will also reflect this state,
        as opposed to simply reporting "All Done!".

    *   Fixed a bug where creating hashes on writable media with read-only
        areas within would create many annoying dialogs, as well as fail to
        leave the hashes on your desktop; the writeability test only being
        performed on the root, to avoid noisy alerts as the system tries to
        write to read-only media.

        However, so long as the root location is writeable, checksum will now
        perform a second test, locally, which could only fail through
        permissions errors, and won't risk a second alert, but *will* tell
        checksum if it's possible to create a checksum file in that folder. If
        not, checksum will revert to leaving them in your fallback location on
        a file-by-file basis.

    *   re-wrote some of the sync and logging code to streamline the internal
        logic, and do error-checking to catch any "unusual" conditions the
        user might set up, for example, where you had already created a
        checksum of some read-only files and then tried to sync it, or when
        syncing a partial checksum file in a read-only folder, that sort of
        thing. checksum will now intelligently handle all these sorts of
        situations, and more.

    *   Similarly, added some error-checking to the DeTokenizer, so, for
        example, if a special path @token is used for a "name" preference, or
        two path @tokens are used in the same path preference, or some other
        crazy thing, checksum will handle it gracefully.

        By the way, if multiple path @tokens are inserted into a single path
        preference, only the first will be used; in this order: @desktop,
        @userdir, @checksumdir; the others discarded.

    +   I added a setting for "fallback_folder", so if you'd prefer any fall-
        back hashes to *not* be stored on your desktop, you can set some other
        location here.

        Note: you can use @tokens for the fallback_folder setting. Including
        a new "@desktop" token.

    +   In the event of a read-only fallback within a writeable area, checksum
        will now re-create the read-only directory structures in the fall-back

        Note: in situations like this, you could always use the "1" switch to
        generate a root hash that can be used to verfiy the read-only folders
        in-situ. Just a thought.

    +   Introduced "fallback_level" setting.

        This has existed as an ini hack for some time, but I decided to make
        it a proper setting, and expand its capabilities some (as well as
        change its name  - ini hackers take note)

        When checksum is asked to hash files on read-only media, it obviously
        can't write the checksums in the local folders, so reverts to
        "fallback mode", and leaves them on your desktop, instead (or
        designated fallback folder). There are different levels of fallback.
        Which level you choose depends on what you plan to eventually do with
        your checksums.

        Level 0 simply carries on with whatever switches you are using, except
        inside the fallback location. e.g. if you are creating folder hashes,
        you will find the read-only structures recreated inside the fallback
        location, with individual checksum files in each folder, containing
        regular relative hashes.  If/when these read-only folders become
        writeable, you can simply copy the folder over in one drag-and-drop,
        to merge everything into the correct folders.

        However, the default is..


        Level 1 forces the creation of a single-file "root" type checksum
        file, with relative hashes for the entire volume (or whatever you are
        checking). This is fairly portable, and will enable you to use the
        checksums in a variety of ways, later; perhaps by dropping the file
        into a copy of the original volume, or if it becomes writeable,
        dropping it directly into the volume itself.

        Level 2 forces the creation of a "root" checksum with absolute paths.

        If you are hashing a DVD, or similar, and you are CERTAIN that the
        contents will always be at D:\ (or whatever drive letter you use),
        then you can enable Level 2, and the entire path, including the drive
        letter, will be inside the hash file, very much like using the
        "absolute_paths" switch, except this will only kick-in in the event of
        a fallback situation.

        With level 2, just like absolute_paths, you can store this checksum
        file anywhere, and it will always point to that same drive location.

        If you think of other levels/strategies you'd like to see, let me know.

        NOTE: the fallback_level setting only applies to fallback invoked by
        read-only conditions in the ROOT of whatever folder structure to are
        creating hashes for. If checksum discovers a read-only area within a
        normally writeable volume, it will re-create the inner directory
        structure inside the fallback folder, using whatever method you
        specified on the command-line (basically, fallback_level=0).

        In situations like these, you may prefer to create a root hash anyway,
        then the inner (read-only) files could be checked in-situ, without the
        need for fallback.

        I realize that most folk will rarely, if ever need all this fallback
        functionality, but nevertheless, I wanted it working.

    ~   checksum no longer uses the system registry to store the shirtware
        reminder time. checksum.ini is now used for *all* settings.

        It's worth noting that the "portable" aspect of checksum - where if an
        ini (preference) file exists next to checksum, it will use it - is no
        more than a simple override which can be utilized in other ways..

        In other words, administrators could distribute licensed versions
        among their users with pre-licensed preference (ini) files installed
        in the user's home folder; which they are free to setup how they like;
        or else completely override all settings with one central preference
        file in checksum's program directory, with different permissions.
        While I'm here..

    *   I chased a weird bug around for a while, where extensionless files
        with numeric names were being occasionally missed. It turned out to be
        a bug in one of my essential libraries. Along the way I made some of
        the hash interrogation routines more robust and flexible, too; able to
        handle more potential user slip-ups and possibilities, as well as
        support new hash formats, for example, piped sha1 output from the *nix
        openssl command (sha1sum output is also currently supported, though

    *   Fixed a potential bug where passing linefeeds on the command-line
        would cause checksum to ignore the hash file completely. Of course,
        getting linefeeds into the command-line is pretty difficult in the
        first place but I managed it, so someone else will, too.

        Actually, the real reason I "fixed" this is so that I can use my text
        editor's line-select (click in left margin) to send test command-lines
        to checksum. Makes life easier, and also, fixes a potential bug!

    +   checksum's final dialog will now better describe the state of things,
        for example, when nothing was done, or the user quit mid-operation.
        I've also added other error messages, for example, when a file doesn't

    *   Fixed a bug I recently introduced where one-shot options dialog
        positions weren't being stored.

    *   Added a couple of missing switches to the main info dialog, and made
        some of the other dialogs a bit smarter, for example, not reporting a
        single error as "errors", plural.

    *   Fixed a bug where checksum would tag a spuriuous "ERROR >> somefile"
        onto the end of error dialogs if the user quit manually, "somefile"
        being the file most recently checked when they quit. By the way, the
        only time you should see the rather generic "ERROR >>" message is when
        files become unavailable for checking, for example, when you
        disconnect a removable drive in the middle of verification, though
        checksum will also let you know about this at the time.

    +   If, for some bizarre reason, checksum files could not be written to
        the original location OR the fall-back location, as well as warn you
        of this problem, checksum will now list the checksum files which it
        *didn't* write, as well as where it didn't write them to!

    ~   Simple checksum will, like checksum, now only store its window
        positions if they have actually changed. This prevents system warning
        messages when operating from a read-only drive, DVD, etc.

    +   Added an option to enable multiple instances of checksum..


        Previously, this was always set to false, to prevent user's from
        shooting themselves in the foot, trying to run multiple checksum
        operations on the same physical drive, resulting in intense
        disk-thrashing, and slow operation. However, if you know exactly what
        you are doing, and remember to never run two copies of checksum at the
        same time°, on the same physical drive°°, then you can now enable
        multiple checksum instances; as many as you like.

        ° Or any two hashing processes. For example, if your torrent client
          is hashing a big file, and you simultaneously do some hashing of
          your own (with *any* application) on the same drive, your experience
          will be very similar; noisy and slow. You could probably get off
          with a quick checksum job, but be warned.

       °° Remember, if a drive is split into two or more partitions (volumes),
          ALL of those volumes are still the same physical drive, regardless
          of the fact that they have different drive letters, and it would be
          wise to run hashing applications on only one of them at a time.

    +   Added a preference for "file_extensions", for adding file extensions
        to per-file individual checksums, e.g. the checksum file for "foo.avi"
        would be named either "foo.avi.md5" or the neater default, "foo.md5".
        This is assuming you are creating MD5 checksums, of course.

        This has always existed as a preference, but I realized that there was
        no actual ini setting to set it. You can, of course, use "e" on the
        command-line, and also enable it in the one-shot options, and though
        it is ugly, you can now you can set it permanently in your ini, if you

        Note: setting this in your prefs only takes affect when creating
        individual hashes, but if you add "e" to the command-line, you
        automatically force the creation of individual hash files, which is
        why, even if you set this to true in your prefs, it won't be checked
        if you bring up the one-shot options. Good to know.

    +   Added a preference for "hide_checksums", which is just like doing
        "attrib +h" on a file - checksum will hide all the hash files it
        creates. This is just like adding "h" on the command-line, except you
        can set now it permanently (again, this was previously possible, but
        had no official ini setting).

        Note, if you have this set to true in your preferences, you can now
        also add "-h" to the command-line to disable it for a particular job,
        if required.

    *   Fixed the unchecked boxes in the one-shot options for root hashing,
        and hidden checksums (when these were set in the prefs).

    +   Added another launch hotkey - Ctrl - which forces checksum into verify
        mode, regardless of what was dropped on it.

        NOTE: If you are using this HotKey from an explorer context menu, you
        must wait until after you have activated the checksum menu item, in
        other words, hit the Ctrl key right after you click the menu item.

    +   If a particular job resulted in nothing being done; for example, when
        you synchronized a folder, but there were no new hashes to add;
        checksum will now tell you this was the case.

  0.9.21  [rc2]

    *   Fixed a potential bug where checksum would crash if you attempted to
        verify an extensionless hash file containing sha1 hashes. In the real
        world, such a file should not exist, but, you ken fit like. checksum
        will now correctly verify its hashes.

    +   checksum can now dynamically switch between md5 and sha1 algorithms on
        a line-by-line basis..

        In fixing the previous potential bug, I devised a better way of
        working with the hashes inside a file, and as a result, checksum can
        now automatically work with md5 or sha1 hashes regardless of the file
        extension (.md5 or .sha1), even in the complete absence of a file
        extension (when called with the "v" switch, checksum will treat any
        file as a checksum file).

        The upshot of all this is that checksum will happily verify hash files
        with a mix of md5 hashes, even multiple legacy and regular md5 hashes,
        as well as sha1 hashes, all jumbled up in the same file.

        This clears the way for a unifying hash file extension, perhaps
        ".sum""sums", or even ".check". A user preference could be created
        forcing checksum to give all hash files this extension, regardless of
        the algorithm used. Feedback on this topic is welcome.

        t z suggests ".hash". I like that, and according to, no
        one else is using it. I feel a preference coming on!

    *   Fixed a silly bug where the writeablility test would fail if the
        directory contained a file or folder called "test". Oops! The test
        file now has a slightly less generic name.

    *   Fixed a bug where checksum would attempt to place its hashing dll in
        portable mode, even if it was already there. This could lead to system
        warnings if checksum was operating from read-only or locked media.

    *   Similarly, checksum will now only write to the ini file if there were
        actual changes. Previously, settings like ToolTip position, one-shot
        dialog position, etc., were always recorded regardless of whether they
        had changed or not.

    *   Fixed a bug where choosing synchronisation and root hashes together
        would crash checksum.

    *   Fixed a couple of minor typos in the ToolTips.

    *   Fixed a bug in synchronising the one-file "root" hashes, where
        duplicate hashes were being created, checksum wasn't taking the
        nix_paths setting into account, and the "./" at the start of the paths
        was confusing it.

    *   checksum will now correctly uncheck the one-file 'root' checkbox if
        you disable recursion in the one-shot options. Also it will check the
        recursion box if you choose one-file 'root' checksums. If you don't
        require recursion, there's no point in using a 'root' hash file.

    *   Fixed a bug where checksum would open the log folder at the end of a
        verify operation when no log was made (if this was set in the prefs,
        and the user specified logging to a file on the command line/one-shot
        options) For example, when logging only errors, and there were none.

    +   checksum now supports Windows file names beginning with a space in
        regular hashing as well as *nix "root" hashing (which always supported
        file names beginning with a space, if you used *nix root paths)

    ~   checksum will now force its one-shot options dialog to the front of
        your windows. I suspect the SHIFT key has a special undocumented
        capability in Windows, and places the launched application to the rear
        of current windows. If you know this for certain, let me know.

    ~   By default, open_log_folder_on_errors is now set to true. This only
        affects new installations, where there are no user set prefs.

    ~   By default, newly-installed checksum dialogs won't time-out (so you
        won't ever miss them). If you want them to time-out, it's easy enough
        to set this in your prefs.

  0.9.20  [rc1]

    *   This release of checksum will mark it as the world's first "Shirtware"
        application, which is like shareware, only better. You can basically
        use it for free, (even the SHA-1 hashing) so long as you at least take
        a look at the shirts (more details in my devblog). It's a
        philosophy as much as a license, you see.

    *   The Shirtware part of the new version has been sticking me (read my
        blog for more details), and after coming up with this new, more
        fitting form of software license (fitting! gettid? hahah!), I knew I
        needed something ultra-juicy; not only uber-cute and concise prose,
        but a viable system or set of dialogs to present the text; this
        version will be the first that has NO TIME LIMIT, and is therefore
        free to roam the earth unchecked, for ever.

        (it's often when I'm releasing code and writing notes that I reveal my
        workings - these things matter to me, and the odd beta tester bugging
        me about the latest release, is a small price that I am happy to pay
        for the time to get it right.)

        This is now done, and as soon as I can get the shirtware shop up to
        the org, I'll release this version, probably nicknamed "rc1", with a
        view to calling it v1.0, letting it loose on the world.

    *   Fixed a bug in the installer, where it would place
        files during an upgrade. This is no longer required; when new versions
        are installed, checksum will automatically upgrade its preferences
        file. You may now instead see "checksum.ini.old" !

    *   Fixed a bug where verifying a one-file "root" hash could cause errors
        if there were other hashes in deeper folders. If you want these checked
        in addition to the root hash, use regular recursive verification.

    *   Fixed a bug where "Yes to All" and "No to All" buttons appeared in the
        "checksum found" dialog when creating one-file "root" checksums.

    *   Fixed a bug where duplicate hash entries could be created when syncing
        a root checksum file.

    *   Note: if you choose to create "root" hash files, checksum will assume
        you want to recurse. Otherwise, what's the point?

    *   You can now choose whether or not to use UNIX-style paths when
        creating root hashes; that is, beginning with "./", which checksum and
        most UNIX tools understand, but other Windows utilities might not. It
        goes without saying that checksum can verify both varieties.

    *   Fixed the auto ini upgrading, it will now upgrade your ini file even
        if it finds no version number there (this only really applies to beta
        testers with ini files from before there was a version setting in

    *   Fixed a bug where *nix hash files with extensions like ".txt" weren't
        being recognised as hash files during recursive checking.

    *   If there were errors during verification, and they were logged,
        checksum can now (optionally) automatically open your log folder for

    *   Fixed some internal spelling errors inside checksum-produces files and

    *   Fixed a bug where under certain conditions, the tip window could open

    *   checksum will now allow you to verify md5 checksum files with any name,
        should you wish to. Use "v" on the command-line, or input in one-shot
        verify options dialog. This is in addition to checksum's ability to
        automatically handle configurable *nix checksum file names.

    *   Fixed a bug where altering the verify path in the options from a file
        to a folder wouldn't work. Now user changes are respected.

    *   Fixed a bug where checksum would fail to find hash files if you
        switched the path in the verify options dialog from a folder to a
        file. checksum will now respect whatever path is entered there, and
        verify it, even if it is a single file with a non-checksum file name.

    *   checksum will now warn you about non-existing paths in the verify
        options, and will not proceed if they are invalid.

    *   Fixed a bug where bringing up the creation options for a single file,
        would enter the file's path into the folder input box, rather than the
        parent folder.

    *   checksum will now accept drag-and-drop of files and folders in the
        one-shot options dialog for both create and verify operations. Verify
        accepts either files or folders. Create accepts folders; dropping
        files onto the folder input of the create options will input the
        folder part of the path, and add the file's name to the file masks
        list, should you actually wish to hash the single file.

        checksum will also add a single file name to the file masks drop-down,
        if the one-shot options are activated via single file hash creation.

        note: if you do select this single file mask, checksum will
        automatically name the hash file with the file's name, rather than the
        parent folder, exactly as if you had actioned it directly from the
        explorer context menu.

    *   I notice that older ini files contain notes that are worded in such a
        way that they may be re-imported into later ini files by checksum.
        This in no way affects anything, other than you might see a couple of
        unusual lines at the end of your [checksum] preference section,
        specifically the UNIX checksum name(s)section. Feel free to delete
        those. This will only affect beta testers.

    *   Fixed a bug where checksum would upgrade the ini, even if the ini was
        brand new. This caused no errors, as such, but meant you had a
        "checksum.ini.old", as well as a "checksum.ini", where previously
        there was nothing; slightly confusing.

        The only time you should ever see this now is if a) you genuinely had
        an old ini file, or b) I forget to upgrade the version number in the
        built-in version.

    *   Fixed the broken shoutcast playlists. Very mysterious. :/

    *   My installer now has the capability to issue a license agreement dialog
        during the install, checksum uses this facility. You only see it
        during install, not during upgrade or re-install.

    *   Fixed a bug in simple checksum where the options dialog would always
        open with the uppercase box unchecked, even when uppercase hashing was
        currently enabled. I think I was subconsciously trying to discourage
        UPPERCASE hashes.

    *   simple checksum will now switch the case of the input box, live,
        whenever you switch between upper and lowercase hashes. Also, if you
        do this from checksum's built-in application menu, it will also select
        the entire hash string for you afterwards.

    *   If you switch algoriths, simple checksum will immediately re-hash the
        file/string with the new algorithm.

  0.9.19  [private test build]

    *   checksum will now compress the log folders using Windows built-in
        folder compression (if they aren't already; and assuming your system
        can do this, and compact.exe is somewhere in your path - very likely).
        This can reduce the space your logs use by as much as 75%.

        NOTE: if your log folder also happens to be your checksum program
        folder; the logs inside it will be compacted, but that folder will
        *not* be be set to auto-compact. It's better to keep logs elsewhere.

    *   checksum will now automatically update your ini file when you upgrade.
        Thanks to seVen for reminding me about this forgotten to-be-feature!
        As well as any new settings, it also means you will get my updated
        notes, which continuously improve as I go along.

    *   I put the checksum icon into the about box. The regular one is nice,
        but this makes more sense.

    *   The context menu "edit checksum.ini" option is now named "Edit
. It still does exactly the same thing.

    *   Made some MAJOR speed improvements to the checksum file building
        routines. En-Joy!

            For coders and md5 geeks, a story..

            Because checksum uniquely checks every single line of each file for
            its checksum format, and supports mix-and-match formats in a single
            file (yup!), the initial "building/extracting" stage has always
            taken some time; roughly two seconds per 1000 checksums, which
            though not a lot, can mount up.

            I decided I wanted to cut this time, and set about to make this
            mix-and-match support optional; split out the routines - checksum
            looks at the first line only, and establishes a format type, and
            from there on, assumes that all following hashes are of the same
            format. Having got this working, and feeling rather chuffed with
            myself, I started to test these staggering speed differences I was
            expecting to see, after all, with this mix-and-match checking
            omitted, a lot of code would now be bypassed on each and every
            line, surely saving oodles of time over many files..

            The differences were almost non-existent.

            Somewhat puzzled (though secretly happy that my mix-and match code
            must be pretty darned efficient) I started to investigate..

            The way checksum verification operates is to scan for hash files
            ("Building file list for so-and-so..."), read all the lines in them,
            decide what format each line is, Solaris, whatever, and pluck out the
            file name/hash pair for that line, store it in an array (basically a
            list) (the "Extracting hashes from so-and-so.md5" bit). Once the
            complete array is built, checksum runs through it, comparing the
            hashes from this list with actual hashes of the files themselves.
            With me, so far?

            The array begins empty, and then is increased in size, by one element,
            each time a new hash is added to it. To do this, I use Redim(), to
            resize the array. From working on my recursive file search functions
            last year (used in everything, including checksum, and available from
   , so you can use them too - there is no faster nor
            more accurate AutoIt recurse routine, syat!) I remembered that Redim()
            was comparatively slow, and I'd instead opted to create a BIG *empty*
            array, and then fill as much of it as needed as I went along. I don't
            remember exactly *how* much faster this approach was, but I do
            remember it was faster; so I decided to use a similar approach in
            checksum itself.

            So checksum now creates an initial empty array with enough
            capacity for the whole checksum file (by first calculating the
            number of lines in the file); small array for single checksum
            files, potentially HUGE array for HUGE checksum files. Then I
            tested again..

                    O M F G !

            My current test folder (a 7000+ file python install) used to take
            14 seconds to build and assimilate all the hash information before
            beginning the actual hashing. With the new system, that time is
            now 0.34s. Yes, ZERO POINT THREE FOUR SECONDS! lol

            So, erm, if you code with AutoIt, avoid Redim() at all costs!

            While I'm here, I have to thank Tom Marriott for all the help with the
            timing tests, I just don't have the patience to work with all those
            brain-dead md5 utilities! AARRRGHHH!!! A couple of them are pretty
            quick, though! *wink*

            So, back to the original headline - MASSIVE speed improvements
            have been made; and verifying hashes, even mix-and-match legacy
            copy+pasted messed-up hashes, will be as fast as creating them in
            checksum always was.

            By the way, the actual internal limit on the size of a checksum
            file is 8,388,606 lines, which would be equivalent to a checksum
            file around 700MB in size! If you ever manage to create a checksum
            file this big, checksum will then use almost 70MB of memory for
            the initial empty array. Of course, in the real world, checksum
            files are nowhere near that big, but if you fancied hashing the
            entire internet or something, now you know. ;o)

    *   Fixed a bug where binary files matching the UNIX MD5 filenames (with
        wildcards, e.g. matches md5sum*) would crash checksum, which
        should no longer happen.

        checksum will now also attempt to interrogate the files, and NOT pull
        hashes from them. This still isn't foolproof, though checksum does
        perform a couple of rigorous checks. I've also made the default UNIX
        types in the ini file more sensible, so this situation is less likely
        to occur in the first place - "md5sum*" is a bit loose :/

        If bad files occur in the middle of a multi-file operations, checksum
        will carry on, inform you about the bad files at the end of the

    *   Added the total operation time to the title bar of the final verify
        dialog. This will be longer than the time (if any) in your logs, which
        is the raw hashing time, only, generally much smaller.

        I should note, that certain other MD5 utilities tally this raw hashing
        time, and present THAT as the total time taken (which, in reality
        includes lots of other operations; file-handling, logging, and so on).
        If checksum started doing this, we would have an instant 1000% speed
        increase! Perhaps a "Weekly World News" version could have this. ;o)

    *   Checksum will now post a dialog at the end of a hash creation
        operations, as well as verification. Reason being, if you are a
        speed-freak, and have ToolTips disabled, there is no way to know the
        final time, which you NEED to know, right? Now you can.

        This also applies to any final error dialog you might get.

        Standard "long operation" rules apply, so it will only show after
        however long you have set as a long operation.

        I should add; I always meant to have a dialog at the end of checksum
        creation, but hadn't gotten around to it. Running with ToolTip disabled
        for the recent speed tests reminded me.

    *   I went back into the dll for the first time in months, to fix a couple
        of issues with the C++. checksum will no longer crash when attempting to
        md5 hash in-use locked files (such as Perflib_Perfdata_***.dat - if you
        were hashing your Windows folder, for example).

        In fact, I switched its file-handling routines to match my SHA1 code,
        and now, as well as being uncrashable (heh, we'll see) it's also
        *slightly* faster, though you would need to be performing some fairly
        accurately-timed tests to notice any real change. Also, just like the
        SHA1 hashing side of things, even with locked and in-use files, you
        will always get your hash.

    *   checksum will, by default, create/verify hashes for up to only a
        million folders, and up to a million hashes per folder - which
        preserves ram. If by some slim chance you have more than a million
        folders to check at one time, or folders with more than a million
        files in them, you can override this by hacking..


        or whatever you like, in your ini, up to a maximum of 8388606.
        Probably no one will ever need this; I just like to add this sort of
        hackability for those special, one-off cases. Note: this will use more
        RAM, at least 10MB per extra million you add above the default (of one
        million). If you have gobs of RAM you could conceivably set it to the
        max and forget about it.

    *   During pre-release tests I realize that the installer still places a
        "" file on upgrading, darn! - checksum no longer needs
        this capability; I'll need to make that disableable (is that a word?)
        in the installer, before it goes out to the beta testers. I guess this
        will be a private build, then.

    *   checksum now posts what it is doing when pulling hashes from a file,
        this fixes the bug where you would see a blank ToolTip while pulling
        hashes from a root checksum (which can sometimes take a few moments,
        if it's a large file - for regular checksum files it passed too
        quickly to see)

    *   checksum will now allow you to exit while pulling hashes from a file.
        Previously it would ignore the request.

    *   Apparently, most other Windows hashing utilities can't handle utf-8 :/
        Seems weird, when Windows has been UTF-savvy since the Nineties. So,
        in case you need to share hashes with users of ANSI-bound (probably
        American) MD5 utilities; I have made utf-8 optional, in the prefs..


    *   checksum now handles ejected and missing drives in a more graceful
        fashion.. If it encounters a missing file, it checks the status of the
        drive, and if it isn't available for some reason, will post a dialog
        warning the user of the problem, and asking if they wish to continue
        (after re-inserting the disk, perhaps), or quit.

        This also works if you are verifying a checksum file on a fixed drive,
        with absolute paths to an ejectable drive that is, or becomes

        It should work for any drives that become unavailable, including
        network volumes, though I haven't tested this myself, yet.

        Two new style classes now exist to facilitate this error condition
        (indeed, any error condition that may yet be coded into checksum).
        They follow the same format as the other status styles, and are..
        "ERROR", and "checksum-ERROR", the latter being for the message
        itself, which will appear where the file path normally would.

    *   Fixed an issue where a double-path was being logged when verifying
        checksum files with absolute paths in them.

    *   Fixed a bug where toggling the Progress ToolTip from the tray while
        the options were open, would bring up an error. Those options won't
        appear now until they are supposed to.

    *   checksum now uses my Standard About Box, and shows the version
        information in the dialog (at last!).

    *   checksum now posts certain dialogs as modal, to prevent them dropping
        behind other windows, which can be annoying.


    *   Fixed the errors in the tray; you will no longer see HTML there if
        you are creating HTML logs. The list should now be much neater, too.

    *   checksum will now write hash files, playlists and logs as utf-8. I'd
        assumed (always a mistake) that this was automatic on XP, but it's
        not. This will be most noticeable in the logs, where the names of your
        Eastern European folk albums will once again look authentic!

    *   Increased the timer display granulation in the html logs from two
        decimal places, to three - checksum was finishing so fast, that the
        finish time being less that 0.01 seconds, would become 0.00 seconds,
        which = false. The timers are now also more accurate.

        checksum will now always print the time, up to three decimal places.

        NOTE: you will still occasionally see "[checked in 0s]", for instance
        when all the files in a checksum are missing - that's simply because
        the hashing was completed in under 0.001 seconds. No way I'm
        displaying four decimal places to catch these! Be content in the
        knowledge that the operation was "very very fast indeed".

    *   The log timers have been fixed. In truth, I'd tagged this on at the
        end of the day, remembering that a couple of beta testers had
        mentioned they'd like to see times in the log - and hadn't really
        thought it through. After a big spliff on Sunday night, I could
        immediately see the flaws in my previous logic, and set about on a
        whole new scheme of internal logging. In short; the log timers have
        been fixed.

    *   Fixed the div-escapees. Under certain conditions, hashes in the log
        would escape their divs, and be box-less. Fact is, I ripped out the
        HTML creation code and re-coded it. It is now far more robust. It
        should be noted that even when some hashes escaped their divs, the
        output was still 100% XHTML Strict!

        These internal changes will also make it easier to collect and add
        other data to the logs. What would you like?

    *   Log append in text mode now works as expected (the setting had gotten

    *   The plain text logging also uses the same system (the only difference
        being the final parsing; either to plain text or html). Thanks to
        this, the plain text logs will now display the checksum file checked,
        and the hashing times, just like the HTML logs; and future data types
        can also be inserted into the text logs just as easily as with the
        html logging. So, what would you like?

    *   checksum will now once again present you with a dialog for errors,
        even when log-to-file is enabled. I'd broken this earlier. If you
        want no dialogs, simply pass the "q" switch. I also improved the
        logic and file list in the final error dialog, which now thoughtfully
        also tells you where the log *is*, just in case. I may make it instead
        present a.. [yes/no] would you like to open the log?

        NOTE: The final dialog can be taken quite literally..

            "A log WILL be created here.."

        In that, it hasn't happened yet. Only when you click okay, will the log
        itself be created. This is by design. For instance; if you have set
        log append to true, but realize you prefer this in a new log, you can
        rename/delete/move the old log *before* you okay the dialog, and and
        you will get a fresh log.

    *   In the plain text logs, passed files are logged. "Passed:: C:\blah..."
        The "::" being what I use as a comment in batch files and logs, and so
        displays in faded text in my editor, just like the passes in HTML logs.
        This also keeps CHANGED, MISSING, and Passed entries nicely lined-up.

        If you want this plain text highlighting, but "::" isn't a comment
        initializer for .log files in your text editor, it's probably easy
        enough to add. Check your prefs for syntax highlighting for the .log
        file type.

    *   Thanks to the new internal logging structure, we can now go "back in
, and do things like give the title of the checksum a different
        color IF there were errors inside. So I did that. It's a new CSS class
        "has_fails", so you can either have them show as red (or whatever) or
        the same color as the other checksum titles. By "titles", I mean the
        clickable header <h4> text that is the name of the checksum file itself.

        Similarly, a new css class "day_fails" can be accessed to give the
        main <h3> header/title (date/time verification began) a different
        color, if you so desire.

        If you log everything, you can now see at-a-glance which days, and
        which checksum files within those days, have errors inside. Handy, if
        you use it.

    *   The "f" switch will now correctly set the "log to file" checkbox in
        the verify options dialog.

    *   Shortened the length of the error beep to 20 milliseconds.

    *   You can now have full paths to the checksum files in the titles of the log;
        handy if you use a generic name for your checksum files. In your ini..


        It's quite possible that with hashfile_paths set to true, the title
        could get *very* large, so checksum will thoughtfully truncate it to
        however long you specify..


        note: the truncation occurs in the middle, so you can always see the
        name of the actual checksum file.

    *   Styles can now be embedded within the log files themselves, if you so
        wish. You master checksum.css will be used as the template for the
        embedded styles, so you can edit that,  and all your logs will contain
        your new styles

            embed_styles = true

    *   The master_styles setting now accepts true/false, as well as the
        location of an overriding master style sheet. The blank setting
        is deprecated, though will still work (at least for a while)

        It is more logical now; the style settings all accept the same
        parameters; either true/false, or the location of a style sheet.

        e.g. if you wanted ONLY embedded styles, you simply set fallback
        and master styles to false.

        NOTE: if you set embed_styles = true, you don't get the built-in
        .status { float: right; } style (which is the only style the logs
        include) so you need to ensure you have that covered in your css -
        it's in the default sheet, anyway.

    *   Added Enable/Disable Audio Alerts menu item to the tray, and ToolTip
        context menus. Handy if you have a lot of errors, or want peace. This
        setting is permanent; or at least, until you change it.

    *   Added a separate setting for beep frequency. The old method of setting
        the frequency was funky, but this is clearer, and makes it easy to
        implement user-toggling, which I did.

    *   Re-ordered the ini file - putting all the new settings into related
        groups. It wasn't too bad, but should now hopefully be more logical.
        I also added lots of notes and default settings records, to make it
        easy to revert anything you tweaked.

    *   Fixed the options dialog position issue (it was sucking prefs from the
        ToolTip, and often opening at the very edge of the desktop).

    *   Expanded the log location input box on the verification options dialog
        it probably looks messy now (because it escapes its group) on anything
        but flatish schemes (like mine is) and I'll likely end up redesigning
        the dialog, to take into account all the new verification options. In
        the meantime, at least you won't have to suffer the input's
        infuriating smallness.

    *   If you quit verification in the middle of a checksum file, checksum will
        now correctly report the time taken, up to that point.

    *   Display of times in the log is now optional, a new setting;
        "display_times" enables you to switch it on and off. It's off by default.

    *   A new setting, "total_times" enables you to have the total verification
        time tagged onto the end of the checksum headers (<h3> date/time). It's
        a bit ugly, so is disabled by default. But if you want this, there it is.

        This is not the total time taken for the entire operation, but an exact
        running tally of the time taken to process each individual hash.

        NOTE: If "display_times" is disabled, "total_times" is also disabled.

        ALSO NOTE: If you disable these logging timer prefs, checksum won't
        bother to time individual hashes, and so there may ironically be a
        performance improvement. So you have to ask yourself, are you more
        interested in *seeing* the hash times, or the *actual* hash times! ;o)
        The difference will be negligible, but still, food for thought.

        Neither of these two new setting has any effect on the overall timer
        which displays in the final ToolTip; a single, simple, overall timer.

        NOTE: these changes also apply to plain text logging.

    *   At some point recently, a local path change in my own system meant the
        .md5/.sha1 document icons weren't stored inside checksum.exe, as they
        should be. They are back now. Running the installer (upgrade) will sort
        everything out, and refresh your desktop icons, too.

    *   seVen sent me a nice olive theme for the logs, so I messed with it,
        and made an olive version of the background image to accompany it, and
        dropped it in the extras folder. You can set it as your fallback
        style, or master style, if you like, or use it as a template for
        embedded styles. It will also always be available here..


        You can see demos of the log output here..

    *   I changed the location of the background image into the same folder
        as the css files (sorry testers! any logs you made with the old version
        will point to the wrong place - but I'll leave the image there for a
        while, yet. If you really need a background image in those old logs, a
        find & replace will fix them!)

        I figured it made sense to keep all these resources together - as well
        as the example logs, and css, there's also alternative css and reg
        hacks in there. So I've made the folder accessible from the web, and
        it becomes as kinda drop-box for "extras". Help yourselves! ..


    *   checksum can now prepend the (base)name of the path checked to the main
        titles, so you get..

            [2006] Rodrigo y Gabriela @ 2007-11-21 14:14:00

        instead of just the date & time. If you log all your checksums for a
        particular path in the same file, you probably don't want this behaviour,
        but if you do, do..


    *   By default, checksum logs will now open with all the sections closed.
        Reason: if your logs start to get *large*, all those sections open can
        slow down your browser's page rendering. You can, of course, click the
        main title to open all the sections in one go.

        If you prefer them open, use your own template.html (details below)

    *   Times in the log now have their own style class; "log_times", rather
        than simply being <small>text</small>, so you can have them really
        tiny, or whatever you like.

    *   seVen  (again - busy lad!) sent me updated versions of the portable
        mode command processors; those handy drag-and-drop thingies that make
        life powerful and easy on pen-drives, floppies (whatever they are),
        DVD-R, and those kinds of places. Among other improvements, the
        commands are now able to suck prefs from your checksum.ini, and even
        understand some checksum @tokens, too. Impressive. Available in your
        extras/ folder in the distro.


    *   You can now access the tray menu while the options dialogs are open,
        as well as when checksum is actually doing something, as ever.

    *   You can now use the token @userdir in your log_folder setting, which
        is transformed into your application data folder (where checksum.ini
        lives by default). So, to use a folder in there called "logs", do..


        Which is now the default setting.

    *   Made further improvements to the log path functionality, and logging
        relative to the checked dir should now work as expected.

    *   (x)html logging. ;o)

        Well, here it is! And I have to say, so far, it's working beautifully
        and looking exactly as I imagined it would - including pesky Javascript!

        All styles, color and position is controlled by CSS, and a default
        style sheet is provided along with the new release (it is placed
        automatically for you, but once done, you can edit/alter that to
        suit your needs). More information about this inside your ini file.

        A couple of new options are now available..

        *   log_format - chose from "text" or "html". The text logging is
            unchanged. the html logging, of course, is all-new.

        *   append_log - rather than create fresh logs each time, append out-
            put to an existing log. If you set this to true, and use your log
            file name @tokens creatively, you can get automatic log rotation
            on a daily/monthly/etc basic you could even have logs for each
            particular checked folder, automatically rotating every month!
            @tokens + append = free energy! Like I said, get creative!

        There is still functionality to add to the XHTML logs, but the basic
        page generation works superbly. I'll be adding more as time goes on.

        NOTE: I did a fair bit of internal re-wiring for the html logging,
        improved other internal structures, so this release is definitely
        going to be classed as "UNSTABLE" for now, though everything seems
        to be working great on my own system.

        About the css (style sheet)..

            Even without any styles, your logs will still be formatted, and
            have all the groovy expand/collapse action; they'll just look like
            sh*t, that's all! To keep everything as funky as checksum is,
            requires css..

            A default style sheet should have been placed next to checksum.exe
            (the first time a log is created). Originally I intended to drop the
            master style sheet in your user folder, but as this location needs
            to be hard coded into the logs, it's actually more future-proof to
            use checksum's location (if you upgrade to Vista, you will no longer
            have C:\Documents and Settings, for a start). This also helps in
            portable mode, where checksum will intentionally forget what a user
            folder even is!.

            So, the master style sheet is next to checksum.exe, along with the
            other auxiliary files. You can edit styles there if you want.

            Better yet, leave it as-is, and make a copy into your logs folder..

            The log files will import *three* style sheets, in order; starting
            with a live sheet from (fall-back styles - should always
            be available), followed by your default sheet (next to
            checksum.exe), and finally, your local style sheet (next to the
            logs themselves), if you have one. The first "C" in CSS, stands
            for "Cascading", C! This behaviour is configurable. (see below)

            You can easily override any and all styles in your *local* style
            sheet. Or you can edit your master checksum.css as you like, and
            also use extra overriding styles in local areas. Or whatever you
            like! Don't like the log's cool background image? Edit your CSS!

            If you don't want to use the fallback styles, in your
            checksum.ini, do..


            If you want to specify your own master style sheet, you can do
            that with..


            .. or a regular http://address, or whatever you need.

        *   One final note about the log files (for now): checksum drops its
            header template into your temporary folder while it is working,
            BUT, if you happen to have a file called "template.html" next to
            checksum, it will use that instead. You might want to make better
            JavaScript, or something. To get started, simply copy the output
            from a log file, down to..

            <!-- end header template - checksum will take over from here -->

            ..and edit to your heart's content. Have fun!

    *   Fixed up logging switches for verify dialog.

    *   The time taken to process each checksum file is now recorded in the logs

    *   Fixed a typo (which caused a fatal error) in the quit mode routines.

    *   Fixed a bug in the relative logging - apparently, when the folder
        containing the running application is a drive root, the system/autoit
        adds a "\" backslash when returning its path. How thoughtful! *sigh*

        I also improved other error-checking in the log_path routines, so it
        should now work under all conditions.


    *   Fixed a bug where if you created folder checksums on a write-protected
        floppy disk, you would get a blank file called "A" on your desktop!

    *   Fixed a fiendish bug I'd introduced in the one-file hashing. It will
        now function as expected, regardless of whether it was invoked  with
        the "1" switch; or automatically, as a fall-back for read-only media.

    *   seVen couldn't wait for me to get around to the XHTML logs, and
        created a rather nifty utility to convert checksum's plain old text
        logs into lovely html, with errors in red! Good work, Sir!

        You can find log2html in the latest release/extras/logging/

        To use, simply drop the application into the folder where your logs
        are, and run it. Drop the resultant .html files into your web browser.

    *   Jon (the Wolfman) has been bringing some interesting bugs to my
        attention over the course of the last couple of weeks. the most recent;
        something that only appears when you use explorer to attempt to create
        checksums on read-only media..

        When checksum attempts to write to the volume, the system throws up an
        error along the lines of "can't write bla bla ... cancel, try again, or
, a bit like the old DOS errors. while the initial dialog is
        unavoidable, checksum had started to throw up two dialogs, and if you
        had existing checksums on the volume, THREE!

        At most, you will now get one dialog. There's nothing I can do about
        this one dialog, as far as I know; checksum needs to attempt to write
        to the disk at least one time, to know whether or not it is writable -
        a read-only volume won't necessarily have its "read only" bit set, you
        see. In fact, it almost never will.

    *   Added a switch for Windows Absolute Paths (i.e. *D:\path\
        It is "k" (Think 0K [Kelvin] - Absolute Zero!) This is only for
        one-file, aka. "root" checksums. If you have this set in your prefs,
        "-k" will disable it.

    *   Fixed the verification tooltip. It now correctly displays the checksum
        file being processed and the basename of the file currently being
        checked, not the *full* path of the file, which could go clean off
        your screen, and then some!

    *   fixed a bug I'd introduced in the last version where you would get a
        double log. (I'm preparing the ground for the XHTML logs, see!)

    *   The web page should be pretty much up to date now. There's a nice,
        fairly ordered list of all the switches there, handy if you are
        cooking up something special.


    *   Added the "1" switch to the switch checking routines. I could have
        sworn I'd done that! Setting one_file in your ini worked fine.

    *   If you want, you can set a single generic name for your checksum
        files. This obviously only takes effect when hashing folders.

        Just like the log names, you can use @tokens in this name, so it can
        be dynamic-generic! See log_names (below) for a full description of
        the available tokens. The default setting is blank..


        .. in which case checksum will name the hash file after the folder
        it refers to. This is functionally identical to..


        When creating your own names, you do not need to add an extension;
        the correct extension (.md5 or .sha1) will be added automatically.
        (unless, of course, you want two extensions, i.e ".my.md5")

    *   I uncovered an interesting bug in one of my supporting libraries
        which manifested when creating folder checksums inside a folder
        called, for instance..

            I:\work\dev\all files\test\a

        My GetParent() function was removing the "\a", as expected, but
        removing it from "dev\all files", making "devll files", unexpected!
        This resulted in logs on your desktop instead of inside the checked
        folder (unless you had specified a log location)

        I've now written a more robust GetParent() function.
        (btw, to users of "corz_essentials" function library - upgrade!)

    *   Fixed a bug where, during folder hashing, empty checksum files were
        being left around for folders containing only ignored files. No,
        this was not some crazy advertising ploy!

    *   Fixed a bug I'd introduced in the last version, where under certain
        conditions (which is a programmers way of saying "most of the time")
        the timer was being reset periodically during creation operations.

        Actually, it only happened when you were there were existing checksum
        files. But it was a good gag. ;o)

        There were a couple of other foibles with the timing. It should all be
        nailed down, now. Let me know if you see any strangeness!

    *   removed the erroneous log_folder entry in the default checksum.ini.
        It's very likely that "C:\Documents and Settings\cor\Desktop\wirefiles"
        doesn't exist on your system. sorree. :/

        Truth is, I'm still getting to grips with trying to test all sorts of
        scenarios on a single machine, and settings from one ini have been
        seen to drift into another. I guess I should leave all this testing
        to the, erm, beta testers. Good thinking cor! :roll:

    *   There is now a setting to tweak the magic stretch value of the tooltip.

    *   checksum will now correctly remember the position of the options
        dialogs after the verify option. Previously it only remembered it
        after creation options (both use the same setting). No one noticed.

    *   If you select multiple files in explorer and choose checksum from
        the context menu, checksum will behave as the previous version,
        presenting an error for the multiple launches, except, it will now
        present only one dialog, regardless of how many items you selected.

    *   Added a setting for pause on completion

        Normally, if you have the ToolTip enabled, checksum will pause at the
        end of an operation, so you can see the final result. You can now
        change the length of that here, in milliseconds. The default is 1000
        (one second). Set pause to 0 to disable the pause, or pass 'n' (for
        "no pause") on the command-line.

        This was mainly added for seVen's cool command processor scripts; so
        you don't have to endure a pause after each file in the queue; but
        it's also a handy setting to have available, generally.

    *   Fixed a bug where checksum would refuse to quit if you asked during
        a scan (building lists of files to hash, or verify)

        Note: checksum will never exit during an actual hashing operation;
        it would be too speed-costly to code this; if you are hashing a large
        file, you must wait until it is done. It's okay to quit in the middle
        a multiple operation, between files, so to speak.

    *   checksum will now attempt to bring its window to the front when
        launched (if it isn't already) - holding down the SHIFT key in
        windows explorer seems to do something to the z-index of desktop
        windows preventing this happening naturally, though this could be
        my own system doing this. At any rate, it's smart to do this.

    *   On verification errors, checksum's ToolTip windoid will flash red.
        It will also turn red (with white text) for the final error message.

    *   Wrote some rudimentary notes and info for seVen's new D&D command
        processors. There are currently in /extras/command processors, and
        are designed to assist you when running in portable mode, or otherwise.
        more information can be had in the local .nfo file.

     *  fixed an issue where if you attempted to launch more than one copy of
        checksum simultaneously, you would get a cryptic error message. You
        are, of course, supposed to get a terse, informative message.

        A silly last-minute mistake; the new dialog time-out setting applying
        to a dialog that could pop up before the location of the ini has even
        been ascertained. Oops. This dialog will now time-out in 30 seconds
        (as it's user-activated, it's unlikely to need to be up any more than
        a moment)


    *   Using the 'q' switch (quiet mode) no longer affects the tooltip,
        you can enable/disable that as required

    *   You can now enable/disable the tooltip with 't'/'-t', respectively.
        This will override your ini setting, whatever it is.

    *   fixed a bug I'd introduced in the last version - leaving the
        writeablity tests lying around. oops! 0.9.13 was unreleased, anyway.

    *   checksum will no longer allow multiple copies of itself to run
        simultaneously. Apparently (and I can't replicate this - probably due
        to my explorer context menu customizations - 'peek', I think)  - if
        you make a multiple selection and then choose checksum from the
        context menu, it would open multiple copies, which would all jump into
        action, working on a heap of files in the same directory. If these
        were large files, this could have SERIOUS speed implications, just
        like hashing p2p-downloaded files, the disk heads will be thrashing
        around like crazy, doing a round-robin on the data-stream. Yikes!

        Now checksum pops up a dialog for any extra launches, informing you of
        the boo-boo, and exits.

    *   you can now choose to have checksum *not* notify you of success,
        unless it was a "long operation". Just how long constitutes a long
        operation, is up to you. Remember, if there are failures, you always
        get notified somehow, so this fits in with checksums broad design
        goal of "no news is good news!".

    *   At the end of a verify operation, the success/failure status is
        displayed in the final tooltip.

    *   the log_location setting has been deprecated - checksum will now name files
        automatically. However..

    *   You can now set a permanent folder for logging, if you wish.
        leave blank to log to the top-most folder checked (the default)

        if you specify a full path, checksum will use it.

        if you specify something else, checksum will assume you wish a folder
        named this to be created/used in the top-most folder being checked.

        In other words, you can set a relative, or an absolute path.

        *   There is also a special token


            which  you can use to specify checksum's current directory (where
            checksum.exe is), so if you were running off a pen-drive, and had
            a copy of checksum inside a top-level folder called "checksum",
            and wanted checksum to create a folder *inside* there called
            "logs" (or use it, if it already exists), you would do (in your ini)..


    *   And finally for logging (for now), you can configure the name of the log

        As well as typing in a regular file name, such as "checksum.log", you
        can use cool @tokens to insert the current..

            @sec            seconds value. from 00 to 59
            @min            minutes value. from 00 to 59
            @hour           hours value, in 24-hour format.  from 00 to 23
            @mday           day of month. from 01 to 31
            @mon            month. from 01 to 12
            @year           four-digit year
            @wday           numeric day of week. from 1 to 7 which corresponds to sunday through saturday.
            @yday           numeric day of year. from 1 to 366 (or 365 if not a leap year)

        There is also a special token: @item which will be transformed into the name of the
        file or folder being checked, and @status, which transforms into the success/failure status

        You can mix these up with regular strings, like so..

            log_name=[@year-@mon-@mday @ @hour.@min.@sec] checksums for @item [@status!].log

        Put quotes around it if you like, though it doesn't matter.
        The @status strings can also be individually configured..

            status_success=100% AOK

        With the defaults, above, the final log name might be...

        [2007-11-11 @ 16.43.50] checksums for golden boy [100% AOK!].log

            chew on that, seVen! ;o)

    *   your status strings will also be tagged onto the end of the final ToolTip, so you can
        check the final status at a glance; handy if you have the audio disabled, or are deaf.

    *   checksum will now correctly add the 'f' switch automatically if you add
        the 'l' (log everything) switch.

    *   checksum will now correctly add the 'i' switch automatically if you add
        the 'e' (file extensions) switch.

    *   "beep_on_failure" has been deprecated in favour of "beep_alerts"; reason
        being, if you enable it; as well as failure beeps, checksum will emit
        a final "bebeep" (meaning; a slightly faster, double-beep - Hey! I got
        that cool word from my camera's manual!), which will double in pitch
        if everything was 100%. If you have long_operation set to a non-zero
        value, this can be a handy background indicator of the status of the
        in-progress and final verification status.

    *   checksum now posts the the item and total numbers, e.g.

            "creating checksums: [folder 3 of 19][file: 2 of 264] movies\2001.avi"

        This also works when verifying checksums, though there may be bugs.

        *   If all this information annoys you, either disable the ToolTip, or simply
            drag the tip over to the right-hand side of your desktop, positioning all
            the bits you don't want to see, off-screen! It's quite nice running away
            displaying only "verifying [file: 3 of 1003] ", or whatever.

    *   Improved the configurability of the ToolTip - as  well as enable/disable,you
        can now also set the font, font size, background and foreground colours, as
        well as snap distance (how close to the edge it can get before snapping to it).

        Note: it's best to use a monospaced font, like Courier New, Lucida Console,
        Consolas, monaco, ProFontWindows, etc.

    *   You can now set how long you want any dialogs to stay open for, in seconds.
        The default is 60 seconds. If you set this to 0, dialogs won't time-out.

    *   checksum now pauses the tooltip (and performs the final double-beep) at the
        end of the creation process, as well as after verification (if you have
        audio and tooltips enabled, that is)

    *   fixed a bug where if you were presented with overwrite options, the timer
        wasn't being reset, so even if the hashing took only 0.15 seconds, it would
        be reported as 5 seconds, or however long you took to decide what to do.

    *   fixed a bug where pre-existing hidden checksum files would prevent checksum
        from replacing them with new ones (if you chose the "Yes To ALL"  overwrite


    *   Whilst solving an issue a beta tester mentioned, I brought some
        interesting functionality into the mix..

        I decided to add support for the creation of "one file", aka. "root"
        checksums, just like the sort of thing you might find on a Linux CD.
        As well as providing all-hashes-in-one-file, which some might find
        useful, it also provides a realistic fall-back in the event of
        creating, or rather attempting to create multiple checksums on
        read-only media.

        The old fall-back strategy simply dumped the checksum files into a
        single folder on your desktop, but this, as Jon points out, had
        limitations; for example, if two files in checksum's creation path
        shared the same name, bad things would happen.

        The original functionality was added to catch "rare instances", but the
        more I think about it, and the more checksum gets "out there", the more
        I realize that folk in the real world will do a lot of this sort of
        thing, and *intentionally*, probably with whole disks at a time!

        To get "one file" checksums, simply add a "1" to the command-line.

        NOTE: when creating these root hash files, checksum uses Linux paths
        for cross-platform compatibility - you can verify md5sum files made
        with checksum on any platform. checksum already recognises and verifies
        Linux MD5, so this strategy makes the most sense.

    *   If checksum is asked to perform a regular recursive hash creation, and
        discovers that the root folder is read-only, it will automatically
        switch to the fall-back mode (currently "one file", as outlined above,
        though I have another in mind, for a future version)

    *   Added support for Absolute Windows Paths.

        When creating root hash files, checksum can now record absolute paths
        inside the hash file. A regular relative path looks like this..


        and has the advantage of continuing to work, wherever you move the
        disk/folder to, even to a different platform. If you are ABSOLUTELY
        sure that this data isn't going to move, you can set this to true, and
        checksum will record the entire path, instead. e.g..

            "C:\Documents and Settings\me\Desktop\distro\file.gz"

    **  simple checksum v0.4.9

            fixed the issue where Ctrl-P would pop up simple checksum's
            preferences, even when simple checksum wasn't at the front.

            while I was as it, I improved that hotkey slightly, so that
            Ctrl-P toggles the preferences windoid, regardless of whether
            it, or simple checksum is at the front.


    *   Decided not to release checksum exclusively as payware.
        What can I say? I dig free software, even if it hurts me!

        So, there will now be a free (for personal use) md5-only version, and
        I re-wired the internals to make room for this. A small fee will
        unlock the SHA-1 hashing side of things. Well, that's the plan.

        NOTE: Attempting to create sha1 hashes with the free version gets you
        md5 hashes. What did you expect?

    *   Added support for verifying Linux file paths (switching slashes)
        inside hash files.

    *   Added support for verifying one-checksum-file-per-volume type files,
        commonly found in Linux distribution disks. Hashes for the entire drive
        are contained within a single checksum file. Though it is very handy
        to be able to *verify* these hashes from your Windows desktop, I
        currently have no plans to add support for creation of these
        monstrosities, though that may change.

        These *nix hash files are usually named "md5sums.txt", or sometimes
        just "md5sums", though you can set whatever names you need, and use
        standard Windows file masks, too, in your checksum.ini; e.g..


        or simply..


        If you drag a matching *nix checksum filetype onto checksum, or verify
        a folder containing one or more of these, checksum will treat them as
        regular .md5 hash files. If it finds back-to-front slashes in the path,
        checksum will switch them around. If it finds *nix-type "./foo/bar"
        root paths, it will automatically convert them to valid Windows paths.

        At the time of writing, I've only tested this out on three Linux CD's,
        but they each contained quite different hash formats; checksum
        verified them with ease.

    *   Added audio alert.

        when checksum discovers a hash failure, it can optionally emit a small
        beep from your peecee speaker.

        Rather than simply on/off, you can specify the actual beep frequency,
        in your ini, in Hz, from 37 - 19999 (the default is 1000Hz); e.g..


        you can pass 'b' on the command-line, to enable beeping (if it is
        currently disabled) or '-b' to disable it (if it is currently enabled)

        NOTE: you can still have beeps when running in 'quiet' mode, checksum
        leaves this decision up to you and your switches.

        The default of 1Khz is good because it's a fairly "cutting" frequency,
        though doesn't describe the failure state as well as a lower value
        would; something like 300Hz *sounds* like a failure.

    *   Added "extras" folder to the distro, somewhere to put the cool
        "checksum.cmd" I received from one of checksum's beta testers (seVen -
        thanks!). It's a SendTo processor/wrapper that enables you to control
        checksum's functions from your SendTo menu. If you don't dig explorer
        context menus, this is for you. More details on the checksum page.

    *   By the way, probably no one noticed, but if you attempt to click the
        recurse checkbox in the creation options, and the path in the path
        input is invalid, checksum flashes the path input a couple of times
        and un-checks the box again, to let you know. I thought I'd mention
        that somewhere.

    **  simple checksum v0.4.8

            plus some other minor improvements which I forget.


    *   Added "portable mode".

        On the outside, nothing has changed. If still comes with an installer
        and so on. However, checksum will now also function in "portable
. To achieve this, all you do is put a "checksum.ini" file next
        to checksum.exe, perhaps move your current ini there.

        When it senses that it has an ini next to it, checksum will use it.
        This also applies to simple checksum.

        If you leave the ini file next to them, they won't access your app
        data folder again, essentially becoming permanently portable from that
        point. If you move the ini back to your appdata folder, they will
        function as before.

        Bottom line; you can use your regular installed version for your
        regular desktop work, and have additional copies wherever you need
        them, on pen-drives, DVD-R, or whatever, each using their own
        customized settings.

        If you don't want to "install" checksum at all, no problem; simply
        unzip the files from (in the installer folder).

    **  simple checksum v0.4.7

            simple checksum can now also operate in portable mode.

  0.9.10  [my new versioning scheme!]

        simple checksum v0.4.6

        *   simple checksum will now save its preferences when no checksum.ini
            is found; it will create the folder, and ini file, if they do not
            exist. previously, it would only save the preferences if the ini
            file was already present (i.e. checksum was installed/run)

            This should rarely, if ever, be required. It's a "just in case". [first beta release - 60 day limited version]

    *   Fixed the 8.3 folder name issues.

    *   Fixed the music playlist recursion issue.

    *   Added Shoutcast (.pls) playlist support.

    *   The tooltip is now an actual application window that just *looks*
        like a tooltip, and its position can now be altered by simply
        dragging it around. It will snap-to the edges of your desktop..

    *   Enhanced the web documentation and comments within checksum.ini

    *   Added ignore files preference (for desktop.ini, folder.jpg, etc.)

    *   Added ignore file types; md5,sha1,sfv,crc,lnk,url,m3u,pls,log, etc.

    **  simple checksum v0.4.5

        *   Minor improvements to simple checksum, added all the options
            to its application menu, so there's rarely a need to open the

  0.9 [first private beta]

    *   Added "Quiet" operation.

  0.1 - 0.8   [private development builds]

    *   Thanks to brother Mu for the synaptic challenges (and C i/o)!


    current bugs and foibles:

    These bugs are know, but for one reason or another (perhaps waiting for
    something else to happen first) they will not be fixed just yet..

    *   This is an installer issue..

        The neat and so-handy directory background context menu items (the ones
        you get when you right-click and empty space inside a folder) get
        duplicated into Explorer's navigation pane context menu. So you have two
        sets of identical-looking menu entries and the second set does not work.

        I hadn't realised that Explorer duplicates the folder, drive and
        background menus into the nav pane. Quite strange behaviour! My nav pane
        context menu (which I activated for the first time, today) is about 150%
        bigger than my screen height! Mad!

        I have literally Googled my fingers sore looking for a solution, but
        none can be found. In the end I posted a question on MSDN, so I'll have
        to wait and see what happens there..


        If it annoys you, you can delete the directory background context menu
        entries (these are the ones causing the issue) either manually, here
        (in the registry)..


        .. (there are four entries - two dividers and two commands) or else
        uninstall checksum, then delete/comment out that section of setup.ini
        (the last section) and re-install checksum.

        Of course, you now have no directory background context menus. Bummer.

        I suspect most people don't use the nav pane, and if they do, they don't
        do much right-clicking on it, or else someone would have reported this
        earlier. Thanks to George Lin for spotting this.

    *   Checksum can run out of memory if you instruct checksum to log
        *everything* during operations involving many hundreds of thousands of
        files on systems with limited RAM. This functionalility was added for
        debug purposes and was not intended for regular use. Future versions may
        handle this better. Normally, only errors are logged.
back to the source menu

Welcome to!

Since switching hosts (I hope you are alright, Ed! Wherever you are …) quite a few things seems to be wonky.

Juggling two energetic boys (of very different ages) on Coronavirus lockdown, I'm unlikely to have them all fixed any time soon. Mail me! to prioritise!