Check it out. its usefull for comparing big files.
http://tejo.yourdotstore.com/~diablo.com/downloads/CompareFile_DLL.rarYou might consider using another approach which may be a little more efficient. This would be to use CreateFile/CreateFileMapping/MapViewOfFile on the two files and then compare them with cmpsd instead of cmpsb (with standard cmps for non-aligned bytes).
File mapping isn't as efficient as normal file I/O, and is severely handicapped on 9x because of the shared address space. Highest performance will be achieved if you use overlapped (async) file I/O.
then compare them with cmpsd instead of cmpsb
i checked this. but i dont see any differnece with the compare speed.
Highest performance will be achieved if you use overlapped (async) file I/O.
dont know what that is but i read that it doesnt run under win98. anyway i think the procedure is fast enough for comparing big files.
just the cpu usage is very high (100%), is that normal with cmpsb/cmpsd ?
Why are you doing SetFilePointer in the compare loop? Aren't you just comparing the first block continously this way?
There are faster ways to compare memory blocks than "rep cmps*", unroll the loop or use MMX or whatever. Probably won't matter too much since you should be I/O bound, but still...
Again, doesn't matter too much in this context, but "shr ecx, 2" is faster than your DIV before the cmpsd. And even when "memsize != ecx", you could start doing CMPSD's, and handle the remaining bytes with CMPSB.
You have a possible memory leak... if memory #2 alloc fails, you jump to @failed, which doesn't freem memory #1 block.
...
There are faster ways to compare memory blocks than "rep cmps*", unroll the loop or use MMX or whatever. Probably won't matter too much since you should be I/O bound, but still...
Again, doesn't matter too much in this context, but "shr ecx, 2" is faster than your DIV before the cmpsd. And even when "memsize != ecx", you could start doing CMPSD's, and handle the remaining bytes with CMPSB.
You have a possible memory leak... if memory #2 alloc fails, you jump to @failed, which doesn't freem memory #1 block.
...
Why are you doing SetFilePointer in the compare loop? Aren't you just comparing the first block continously this way?
i code such thing first time. never used SetFilePointer befor. so do you think i must inrease the "distance to move" on every loop? i check it.
but "shr ecx, 2" is faster than your DIV
nice trick. asm is great. i like it
You have a possible memory leak... if memory #2 alloc fails, you jump to @failed, which doesn't freem memory #1 block
thanks for this bug report.
You don't need SetFilePointer at all - using ReadFile automatically increases the file pointer position. When you do invoke SetFilePointer,hFile_1,MemSize,NULL,FILE_BEGIN, you set the file pointer to MemSize bytes into the file... which means you will always process the second (not first, as I wrote earlier) block. Simply remove these two lines :)
thanks again. i think it should work now... hope it...
Could anybody help me to translate the API Declaration to HL Syntax?
Cause i coded this for a friend. He tried to use this witch a delphi app but he has problems.
Cause i coded this for a friend. He tried to use this witch a delphi app but he has problems.
CompareFiles(
LPCTSTR pFile_1, // Adress of buffer of Path of File 1
LPCTSTR pFile_2, // Adress of buffer of Path of File 2
DWORD pMemUsage // MemUsage per File in MegaBytes
DWORD pUseProgressWindows // 1=Show Window 0=Hide Window
)function CompareFiles(pFile_1,pFile_2:PCHAR; pMemUsage,pUseProgressWindows:DWORD):Integer; stdcall; external 'CompareFiles.dll' name 'CompareFiles';thanks, it works now in with delphi.