Display virtual c/s even with Cygwin builds.  This was disabled because it
printed nonsense on Windows 9x, but those systems are irrelevant now.
(Besides, builds made with recent versions of Cygwin were reported not to work
on Windows 9x anyway.)  Windows NT 4 already provided virtual times under
Cygwin just fine.
Added $(LDFLAGS) for ../run/john.exe just like it's done for other john
binaries (on other platforms), to support OpenMP-enabled builds with Cygwin
(OMPFLAGS is included in LDFLAGS).
Enable BF_X2 when building with gcc 4.2+.  The resulting code tends to be
faster on P3, P4, Core 2, Core i7, and likely on other CPUs.  (gcc 4.1's BF_X2
code is also faster on most of these CPUs, but slower on P4.  gcc 4.0's code
is slower on many CPUs.)
1.7.9.1:
- With 32-bit x86 builds and at least MMX enabled, the "two hashes at a time"
code for bcrypt is now enabled for GCC 4.2 and newer.  This change is made
based on benchmark results for different builds made with different versions of
GCC on CPUs ranging from Pentium 3 to Core i7.  Previously, this code was only
enabled for x86-64 and/or OpenMP-enabled builds.
- Assorted minor corrections to Cygwin builds were made.
Use an int64 for the effective number of combinations per crypt_all() call.
A 32-bit number became insufficient with OpenMP support for some fast hashes,
where a lot of buffering is required for decent performance (one crypt_all()
call processes thousands of candidate passwords, and there may be thousands of
hashes per salt as well).
Use the bitslice DES implementation on systems where it is faster than the
traditional one (that is, almost everywhere).  Support OpenMP.
Wrapped #define _XOPEN_SOURCE 500 in #ifndef __FreeBSD__ ... #endif because of
what looks like a FreeBSD headers bug (or at least a limitation).
Reported by Alexey Dokuchaev:
http://www.openwall.com/lists/john-users/2012/01/09/4
Updated the answers to "Why doesn't John load my password file?" and "How do I
"unshadow"?"
Moved some questions/answers around.  Dropped "Where are the charset files?"
(these have been included in all JtR tarballs for years).
Made many minor edits.
Dropped "How do I "unshadow"?" (this was redundant with one of the answers to
"Why doesn't John load my password file?").
Moved "How long should I expect John to run?" up.
Added "John appears to misdetect my hash type."
2012
1.7.9.2:
- Enhanced the support for DES-based tripcodes by making use of the bitslice
DES implementation and supporting OpenMP parallelization.
- Updated the FAQ.
For an alternate executable example, refer to john-omp instead of john-mmx.
Implemented proper get_hash*() and binary_hash*() functions for tripcodes,
skipping the bits corresponding to the 3rd crypt(3) output character, which is
not included in tripcodes.
Instead of zeroizing the bits not included in tripcodes after each
DES_bs_crypt_25() call or/and before each cmp_*(), zeroize crypt_out in advance
and then copy just the 58 significant bits into it.
Lowered PASSWORD_HASH_THRESHOLD_5 to be consistent with other thresholds after
testing on 1 million of tripcodes.
In the DES_BS case, set BINARY_SIZE to ARCH_SIZE (not to 4 like we did before)
because the underlying interfaces use ARCH_WORD, so things would break on e.g.
64-bit big-endian even though we're only using the least significant 32 bits.
Made minor optimizations to DES_bs_cmp_one() for count >= 32.
Don't call status_ticks_overflow_safety() from status_update_crypts() when
count is above 0x00100000 since we could end up calling
status_ticks_overflow_safety(), which may involve making a syscall, too often
when there's a large number of hashes loaded for cracking.  For example, if
count->hi is non-zero, we'd end up calling status_ticks_overflow_safety() every
time.  We're also calling status_ticks_overflow_safety() from
crk_process_event(), which should be sufficient.