Originally posted by: hl
heres a thread about assembly crc with benchmarks ;-)
ReplyOriginally posted by: mocad_tom
It works very fast. I had another checksum-routine which works only in debug mode. When i was building it in release the sums where completely different.
Good job!
Tom
Reply
Originally posted by: Mark Conroy
I was in search of an algorithm that calcualted CRC32 values compatible with WinZip. Found your code here and downloaded it. It works perfectly and is EASY to follow. Many, many thanks for an excellent code contribution!!
ReplyOriginally posted by: Selmac
But can someone explain me, why this (extremely slow)
"
B1% = 255: B2% = 255: B3% = 255: B4% = 255 'start with
open file for read
DO
if (end of file) then (exit from loop)
close file
PRINT "CRC32: "; HEX$(B4% XOR 255); HEX$(B3% XOR 255);
"
This routine is slow, but I want to see correct results
Does someone see the BUG ?
Thanks
Selmac
Thanks for much useful information.
routine gives allways wrong results, allthough I tried to
modify nearly everything (Reflected "Poly", ...):
'FFFF-FFFF
read 1 byte to VNBYTE%
VNBIT% = 8
DO
VNBYTE% = VNBYTE% * 2: VBCI% = 0 'shift to left
IF VNBYTE% > 255 THEN
VBCI% = 1: VNBYTE% = VNBYTE% - 256 'carry to VBCI%
END IF
B1% = B1% * 2: VBCR% = 0 'shift register to
IF B1% > 255 THEN 'left in 4 steps
VBCR% = 1: B1% = B1% - 256
END IF
B2% = B2% * 2 + VBCR%: VBCR% = 0
IF B2% > 255 THEN
VBCR% = 1: B2% = B2% - 256
END IF
B3% = B3% * 2 + VBCR%: VBCR% = 0
IF B3% > 255 THEN
VBCR% = 1: B3% = B3% - 256
END IF
B4% = B4% * 2 + VBCR%: VBCR% = 0
IF B4% > 255 THEN
VBCR% = 1: B4% = B4% - 256 'carry to VBCR%
END IF
IF VBCI% <> VBCR% THEN 'if carries different
B1% = B1% XOR 183
B2% = B2% XOR 29 'exor register with =04C1-1DB7
B3% = B3% XOR 193 'in 4 steps
B4% = B4% XOR 4
END IF
VNBIT% = VNBIT% - 1
IF VNBIT% = 0 THEN EXIT DO
LOOP
LOOP
PRINT HEX$(B2% XOR 255); HEX$(B1% XOR 255)
' invert result nobody knows why
before I optimize.
------------------------------------------------
Originally posted by: J. Schmidt
this is a very nice and useful source. it helped me to optimize my own crc sources. thanks a lot!
ReplyOriginally posted by: Yaroslav Lobachevski
void CCrc32Dynamic::Free(void)
{
delete m_pdwCrc32Table;
m_pdwCrc32Table = NULL;
}
should be
void CCrc32Dynamic::Free(void)
{
delete [] m_pdwCrc32Table;
m_pdwCrc32Table = NULL;
}
Originally posted by: Ron Porter
Is there a way to append 4 bytes to the end of a string such that the resulting new string always returns the same CRC regardless of what changes have been made to the original string? I'm trying to send a short packet of information but I'd rather not have to parse the packet before I CRC it at the receiving end. Instead I'd just like to hard-code a known result then compare a CRC of the whole packet to that known result. I only have to parse the packet if the CRC matches, thus not having to waste time parsing bad packets.
Thanks for any tips.
ReplyOriginally posted by: Jase Jennings
Hi,
Useful code, thankyou.
I want to get my exe to CRC check itself, but naturally there is a paradox in doing so. Each time i compile my final executable, it has a different CRC, so it seems impossible for me to place a check for if(crc = 123456789). Naturally, each time I recompile, the value I am comparing against will have changed ...
Is it possible to get an exe to check its own crc without storing the exe's crc externally to itself ? I wish to use this check so that I can verify that my exe has not been cracked/patched at runtime.
Any thoughts on the way ahead ?
Thanks
Jase
Originally posted by: MOHSEN MABROUK
ARE YOU PLANNING TO REWRITE THE CODE TO C#? THAT WILL BE GREAT.
ReplyOriginally posted by: Kendrix
I tried your CRC32 little soft on 2 IDENTICAL files...
710 mo and I got 2 DIFFERENT crc values !
I haven't the time to trace the bug...
I wrote a little program to verify if each byte in the two files were really the same and they are !
So it is truely a bug !
Reply