>From the algorithm it looks as if you could easily end up with a negative result regardless of file size.
>I don't know the inner workings of the calculation but, since it is essentially a bitwise operation, why do you thing negative int representations are invalid (you don't show any usage of the nCRC32 return value) ?

I saw it like that since the last two years. I always assumed it could be ok to have negative values. But, yesterday, we compared a related class in Visual FoxPro for CRC32 to mine and we did not obtain the same results on big files. We were obtaining the same values for small files but not on big ones. So, I assumed mine was wrong. So, you're saying that it could be normal to obtain a negative value for a CRC32?

>Also, for larger files why not use a larger buffer ?

I tried it with 8192 but the result is as fast with 1024.

>See you're still not using OPTION STRICT :-}

Well, I put it on and ended up with a bunch of errors where I would no longer be able to do things like:

Private cName As String = ""
cName = Trim(toRow("Table"))

As, it would give errors like:

"Option Strict On disallows implicit conversions from 'Object' to 'String'."