I was just going thru this site..I found ur code ..it was good...
Actually I wanted to something like this so i was searching on the net...I'm glad I found ur code...it saved lot of time for me...
thanks once more....
Im a newbie vc++6 user and Ive been looking a the source code and whilst exactly what I need I cant really figure which bits I need to extract to make my own version of this program. Im just after a plain command line
eg crc.exe <filename> but Im not too sure how to remove all of the extra bits. I want to implement the Static Assembler crc32 function...could anyone possibly help me?
Does anyone know if the crc is the same if u use it on anagrams:
STOP = "Xa"
POTS = "Xa" or does it end up as "Xb"?
TOPS = "Xa" or "Xc"
Further, IF IT IS a different CRC, does anyone know of a "functional relationship" (mathmatical) between
"Xa" & "X any n", given they are derived from the SAME letters(i'm assuming ASCII representations in binary at the lower levels) and that
A+B+C = C+A+B
no matter the order they are added,
and also A(B*C) = (A*B)C...im kinda new to programming and all this math, so looking for some basic pointers(groan).
FYI-im thinking of using such an approach to find anagrams in a given list, and thinking of using this method to "flag" words having the same crc/checksum(since its faster). Anyone having ideas how this might be done(if u have addressed such a challenge previously) are encouraged to email them to me. :-)
I've found the following source to be very helpful. It's not asm, but it's portable and it's the fastest and tightest C source I've found. Table driven, 16 & 32bit CRC, and offers both byte and word alignment alternatives.
another note though, the MapFileAndCheckSum returns different CheckSum on a really identical file between WinNT and Win9x operating system. Try multiple files,speacially EXE and DLL files to see the result.
when i tried the sample code posted, the Checksum values of the files returned are identical.
There are two very common implementations of CRC, normal and reflected.
Normal CRCs process the input data from LSb (bit) to MSb. You can see this in your table generation routine. Also, in a normal CRC, you are processing the LSB (byte) of the CRC each time. (Oh, btw, in theory, a CRC can be generated for a stream of bits of any length such as 3. It is the table lookup optimization that forces the byte limit.)
In a reflected CRC, the input data is processed from MSb to LSb. Now, you can make a reflected algorithm act normal by reversing the bit order of the input data and the input/output CRC values. However, this is REALLY slow.
To implement a reflected CRC, first reverse the polynomial. However, most of the time the polynomial is already reversed (which is why you see 0x04C11DB7 instead of 0xEDB88320.) Next, during table generation, instead of testing the low bit of the input byte, test the high bit and shift up instead of down.
Finally, in the table lookup, all you have to have is:
So, when you see a reversed CRC polynomial, that is a good hint that they are actually using a reflected CRC and not the normal type.
Of course, there is always some person who uses a reversed polynomial with a normal crc or normal polynomials with reflected crcs. But the good news is that reversed polynomials tend to work just as well.
Also, it is VERY VERY important that the seed value is set to something other than 0 (which it is in this code). If the seed is 0, then a stream of 10 or 23402490 NULL bytes will always yield a zero crc (excluding any final one's compliment.)