CRCs

1. Simply it is the remainder of a division. For example, if you take a string of 1000 bytes it can be considered to be an 8000 bit number. If you divide that number by some other number, the remainder is the CRC, where a 16 bit divisor yields a 16 bit CRC and a 32 bit divisor yields a 32 bit CRC.

2. Extremely reliable. They are fundamental in detecting errors in a great number of protocols such is TCP/IP, ethernet, sending data to and from disks, etc., in fact anywhere serial bit streams need to be validated.

3. An FCS or Frame Check Sequence is used for pre-conditioning the crc generator. Most often its initial value will be &HFFFF for crc16 and &HFFFFFFFF for crc32.

4. Process it in chunks. Note that because of Visual Basic limitations the library can only process files less than 2GB in size.

5. This is because VB (pre-.NET) only handles signed integers and longs. The CRC is correct.

6. CRCs do not provide any security - for that, use encryption. Sometimes they are used to detect whether files have been tampered with. They are good for detecting hardware generated errors and for detecting casual tampering, inadvertent or otherwise. However, for a determined and knowledgeable person, it is fairly easy to modify a file, retain the same file length, and re-create the original CRC.

7. The first thing to check is, are you generating the CRC over the exact same sequence of bytes? The next would be, are you using the same CRC algorithm? The CCITT versions are quite popular but there are others.

   Sometimes the pre-conditioning value for the FCS is set to 0 instead of &HFFFFFFFF. The FCS can be passed as an argument to the CRC32Bytes method.

   Lastly, very often the returned CRC value is post-conditioned by complementing it. PKZIP does this, for example. The CRC value can be complemented by exclusive or'ing it with &HFFFFFFFF, for example:

      crc32val = crc32val Xor &HFFFFFFFF.

   The CRC32 methods (CRC32Bytes, CRC32File, CRC32String) have an XOrIt option. In SDK's experience, most CRC32 values (in zip files, picture .CSV etc lists, and so on) are complemented, so unless you know better the XOrIt option should be True. XOrIt should be False when making cumulative calls to CRC32Bytes (i.e. processing in chunks). Only the last call should have XOrIt = True, or use the above code. See the sample code supplied with the library for more information and ideas.

   Finally, if all of the above does not help you perhaps you have encountered a bug. Please email us.

8. WinZip CRCs appear to be CRC32 hex strings, complemented with &HFFFFFFFF. Use a CRC32 method (such as CRC32File) with the XOrIt and HexYN options set to True. The above question/answer will help you too.

The Library

1. Please visit our website for the latest information. We expect the price to be around $29 for a single developer.

2. The CRC32 routines are table driven and use assembly language. They are probably about as fast as can be done in Visual Basic (and as fast as or faster than C too). Indeed, we've never seen a faster implementation, and that's with our version having error checking and an OCX wrapper too.

3. Actually, in theory, Adler32 should be some 33% faster because it is a simpler algorithm. However, at present our implementation of the algorithm is pure Visual Basic so it's slower. It's amazing what difference some assembly code will make! That said, our Adler32 is quite fast enough for smaller files.

   We're working on shifting Adler32 over to assembly language too, but it will not be high priority unless there is a number of purchases of this library.

4. Use which ever algorithm is supported by the software you intend to interface with. If that isn't an issue, we suggest using CRC32 for widespread compatability. Our CRC32 implementation is also faster, for now at least (see above Q&A).