AutoHotkey Community

Very kind of you.
Thank you Sir.




Why do I get an errorlevel A12 ?

cdecl, and no return value.

Thanks for the clarification

@Laszlo:

Sir, I tried your CRC32 function, it is very nice, but looks much complicated for my requirement.
My current project needs to deal with checksum of files.
Is there some kind of checksum method where there is no need for lookup table ?
Maybe CRC16 ? Any kind of checksum computation that is very short and really fast! I will be happy if you can give me your own version too.

Please help.

CRC32 can be implemented without lookup tables. It is 2..4 times slower, but still pretty fast. If you want 32-bit checksums, it can be calculated with a very short function, much faster than CRC32. The drawback is that some small cahnges (like replacing i1 with j0 in program files) do not change the checksum, so there will be many collisions: different files with the same checksum. Which way do you want to go?

Sir, this is my project:

how does one create an image file library? posted by SKAN

Currently, I have made it too easy and so I want to complicate it..



for 50 files @ 2MB each, how much time would it take for 50 Checksums ?



Sir, I want to do only one DllCall() to keep my code compact, lookup table or not.
I look forward to less collisions as I will also be using it on EXE files.

I keep my fingers crossed.

UNTESTED: Here is a very short CRC32 function (could be made slightly faster, but longer). It does not use tables. The C source code is:

A possible AHK wrapper:

It does not have the length field auto-attached to the input (no padding), but should be OK for home use. You can continue the CRC calculation for other parts of a large data set, if you set the Start parameter the bitwise complement of the result of the previous part. Test it with:

:D:D

That was very fast .. Many thanks Sir.
I will try it and revert back.

[TESTED] Here is a CRC32 version, which does not invert the result, but lets you chose the polynomial (as a UInt value in parameter #4). Its standard value is 0x04C11DB7.

Note that this function slightly differs from the IEEE standard CRC32: the result is not inverted, the data bytes and the final result are not reversed. This makes the code simpler, but the computed CRC different. It is equally good for checking if binary data are different.

The CRC calculation can be continued by giving the result of the last call the start value (parameter #3) for the next call. The very first call in a sequence normally sets it to -1, but other values are OK, too. The first parameter is the address of the data, either “UInt,&var”, “UInt,address” or “Str”,AHK_String”. Parameter #2 is the number of bytes to be processed.

You can use this function without a wrapper, too:


You can compare the results (inverting it with MsgBox % ~DllCall…) to other implementations. Set CRC-32, but uncheck “reverse data bytes” and “reverse CRC result before Final XOR”, and use “direct” mode.

Edit: added missing ".." (thanks to SKAN)

Thanks again Sir.. also for giving me tested code. I am not good at testing this. I am taking your code for granted and implementing it in my function. I am happy it is 4 bytes short.

What does this magic number denote ? : 0x04C11DB7

.. and does not cdecl uint need to wrapped with quotes ?

It is the bit pattern of the coefficients of the standard IEEE CRC-32 binary irreducible polynomial (x**32 is implicit). You can use here any other polynomial of this type (Castagnoli: 0x1EDC6F41, Koopman: 0x741B8CD7), producing other CRC values.

Yes, thanks. (The dll call works without it, but returns A16 in errorlevel.)

Thanks for the clarification sir.

@Laszlo

Dear Sir,

I need mcode for

1) binary string copy ( using parameters similar to lstrcpyn and functionality of RtlMoveMemory )
2) binary string compare
3) any encryption function like tea or rc4 that gives ( returns result as pointer to binary )

I am thinking about writing an ahk code obfuscator.
I am not in a hurry ( will not be in town for 2 days ) but please do help when/if you have the time.

Regards,

Olfen already did the work for XTEA.