New switch for add()

• freeze outputfolder -maxsize something

zpaqfranz a z:\1.zpaq c:\nz\ -freeze y:\archived -maxsize 2000000000

If the archive (z:\1.zpaq) is bigger than the -maxsize limit (2GB), it will be MOVED (before the execution) to the -freeze folder (the y:\archived directory, so y:\archived\1.zpaq, y:\archived\1_000001.zpaq, y:\archived\1_000002.zpaq ...) without overwrite.

Usage scenario

The backup of virtual disks (es. vmdk) can become quite big in the mid-time (months), the classic way is to simply rename (/move) the .zpaq file "somewhere" (a NAS, typically) so that, at the next run, it will start over from scratch.
Usually the old archive is not immediately deleted (basically it includes the backups of yesterday, the previous day etc) but "parked" waiting for a cancellation, let's say after months or years.
The new switch does this automatically and, with the n (purge) command, archive rotation is quite easy

HW acceleration for BLAKE3 on Windows 64

By compiling with (please note the Define and the .S assembly file) ON WINDOWS 64

g++ -O3 -DHWBLAKE3 blake3_windows_gnu.S zpaqfranz.cpp -o zpaqfranz -pthread -static

zpaqfranz use 1 of 4 implementations (if supported), SSE2 SSE41, AVX2, AVX512 for the BLAKE3 hasher.
it is not a very tested version, I use it mainly to compare performance with the Rust version

On AMD5950X the improvement is about 6 times (3.6GB/s HW-accelerated vs 600MB/s straight-C), not bad but about useless in real world

Fast check

zpaqfranz b -blake3 -sha1

On SW implementation (zpaqfranz <=52.16) BLAKE3 run slower then SHA-1 (about 2/3)

You can see here

zpaqfranz v52.17-experimental **with HW BLAKE3**, compiled Aug 17 2021
Usage: zpaqfranz command archive[.zpaq] files|directory... -switches...