v2.3 June 2014
Complete support for Unicode on Windows, ensuring filenames or directotries containing Chinese or Arabic or Hebrew (etc) characters can now be processed using QuickHash without the user having to change their language and region settings. Prior to this, QuickHash was generating the default initialisation hashes for such files but not actually hashing them. All users are encouraged to discard any version prior to v2.2 and adopt v2.3.
v2.2 - Nov 2013
It was reported that large files failed to hash properly with SHA256 or SHA512 implementation. It turned out this was due to a 32-bit integer delcaration in the DCPCrypt library that is used by QuickHash for those two algorithms. Updated by using QWord instead Longword variables. Output checked against SHA256SUM and SHA512SUM and found to be OK now.
Linux version brought to same level as Windows version. Interface improved to better display values.
v2.1 - June 2013
All versions prior to 2.1 suffered a 32-bit 4Gb limitation when copying (as part of the 'Hash, Copy, Hash' routine) a single file larger than 4Gb. That was fixed by casting the "filesize" variable to Int64 instead of Int32 meaning the size limitation is now set by your filesystem only (16 Exabytes for NTFS).
International language support added for filenames and directories that contain or might be created of a non-English nature by use of UTF8 casting. For example, the destination directory for "Hash, Copy, Hash" can now contain non-English characters.
All hashing in Quick Hash utilises Merkle–Damgård constructions (
http://en.wikipedia.org/wiki/Merkle%E2% ... nstruction). As such, zero byte files will always generate a predetermined hash, depending on the algorithm;
sha-1, for example, is always da39a3ee5e6b4b0d3255bfef95601890afd80709. To avoid confusion, if a file is zero bytes, it is not hashed at all and the entry 'Not computed, zero byte file' is enetered into the results. Though I acknowledge some users may feel it is necessary to hash zero byte files for security reasons, on the whole, I don't think it is for 99% of users.
Files of zero bytes are now copied as part of the "Hash, Copy, Hash" routine to facilitate those who wish to use QuickHash as a backup system where, on occasion, zero byte files are created by software and are required in order to function properly.
Date format of output directory changed again to 'yy-mm-dd_hhmmss' (e.g. QH_13-12-25_221530) due to the now widespread use of QuickHash internationally. The previous format of ddmmyy worked OK for UK users, but there is some merit in the year, month, day format, especially for multiple output dirs.
v2.0 - Feb 2013
Interface entirely re-written to use tabbed design with each hashing feature having it's own parent tab. Allowing the util to be used on low resolution screens. Default size is now ~900 x ~1000 pixels meaning it should be visible on every screen but the smallest of resolutions. This work has made the exe leaner with less decision loops and less code.
Status fields that record % progress, Mb copied etc are cleared after an earlier run
Simple text hashing now has a much larger area for larger text segments and the hash value field is larger allowing SHA256 and SHA512 to be seen in full
Status bars more neatly attributed to each individual process to ensure they are kept in place during resizing.
All necessary fields (source directory path fields, grid displays, text areas etc) that a user may want to make wider when the GUI is maximised are now all right aligned meaning they'll grow when the GUI is maximised. Note, though, that the v2 interface is designed to be now 850 pixels wide.
Date format displayed as dd/mm/yy hh/mm/ss instead of dd/m/yy hh/mm/ss for ease of reading the systems date and time settings (that are reported to the user for some functions) that QuickHash is running on and to ensure the output directory is easier to read. The destination dir for copy and hash processes now read "QH_ddmmyy-hhmmss".
Moved some of the tick boxes into a panel group to help with resizing and moved the status bars of recursive directory hashing further in to the left.
v1.5.6 - Jan 2013
The display grids for displaying hashes of multiple files in a directory and for "copy and paste" hashing now have the number of rows pre-computed based on the number of files found prior to hashing. This saves a considerable amount of time with large data sets.
Combined with the step above, a gigantic speed improvement caused by also disabling the dynamic bottom pane until after all files are hashed. Having it refresh for every file was not really necessary anyway, given that the status bar reports the file being hashed and the progress stats show files %, data volume etc. enchmarks show 3K files took 2 minutes with version < v1.5.6; With v1.5.6, the same 3K files take 12 seconds!
The same visiblity change applied to recursive copy and hash, though, in tests, the process of copying the files was slower than the grid display but with lots of small files, this is likely ot have made an improvement.
With regard to recursive directory hashing and recrusive copy and hashing; the user can now decide to override the default behaviour of hashing all files in all sub-directories of that chosen directory, meaning that just the files in the root of that chosen directory can be hashed (and copied if appropriate) and no others in other sub directories, if required.
The user can now decide whether to flag any duplicate files found, or not (only for standard direcotry hashing - not for copy and hash, yet).
The left to right scroll bar of the bottom pane was partly obscured by the status bar. That was corrected.
v1.5.5 - Nov 2012
Added file mask capability to allow selective searching for one or more mixed file types, e.g. *.doc; *.xls etc. New masks can be added at will.
Added progress indicators to recursive copy and hash, to match the standard recrusive hash without copy.
A new intermidiary output directory, named after the date and time of execution, is now added beneath the output directory with the output then put beneath that ensuring that if multiple outputs are sent to the same directory at different times, each output can easily be identified.
A log of file of files that failed to copy or those for whome the hashes didn't match are now recorded in the chosen output directory
Adjusted phrasing of Clipboard button to "Clipboard Results", to mean "Copy the results to RAM clipboard" because the previous phrasing
of "Copy to RAM" was misleading, suggesting the files would be copied to RAM, which was not true.
Improved layout slightly by replacing some labels with edit fields.
Improved the 'Hash mismatch' error to make it easier to read and including the name of the actual file that has failed, as well as just the hash value.
Added a warning to recrusive copy and hash feature that OS protected files or files in use will not copy properly, to make the user choose more wisely
v1.5.4.1 - Nov 2012
All functionality added since 1.5.2.2 added for the Linux version, too, matching it to the 1.5.4 Windows release
* Note date and time attributes of recursive directory copy and paste adjusted as only Last Modified dates are available in Linux
Added Stop button to recursive directory copy and paste traversal (top right pane), to match the stop features of the simpler recursive directory traversal functionality (bottom pane)