|
If you are using MFC then a window would be a CWnd-derived class, which wraps a Windows window
handle (HWND). If you are not using MFC then it would just be an HWND.
Controls are windows (have an HWND) as well but add a pre-defined set of messages. Here's a
better explanation than I could ever give  User Controls[^]
|
|
|
|
|
I am going to compare bitmap images by creating a hash value of the bits for each image. I have at my disposal a crypto library. I'm not asking how to do it, but I would like to know which algorithm would be your first choice? We all know these algorithms are usualy built for strength, so I am looking for one that is fast, has a small output but not so small that the same results would be obtained from different images. Any thoughts?
|
|
|
|
|
My hash of choice is CRC32. It has not let me down yet.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
WalderMort wrote: Any thoughts?
Super Fast Hash[^]
the benchmarks near the bottom also include comparison to CRC32.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
Don't waste CPU cycles on cryptographically secure hash functions. A CRC-like hash function will do what you want in less CPU cycles.
--
Presented in doublevision (where drunk)
|
|
|
|
|
With the CRC32, I would issue these warnings:
1. If the CRC32 matches, it does not mean the two images are identical.
2. If the CRC32 does NOT match, it means the 2 images are NOT identical.
|
|
|
|
|
Hi! This is my first post on the web ever!
To make it short, I made a routine to change certain bytes in a file in binary mode. It all worked perfectly, until I decided to use a long name directory and it crashes. I made certain check points to find out exactly where it crashes and why. Here is my subroutine code:
void binary_edit (char *cur_dir) {
FILE *fp,*fp2;
char filename[100],filename2[100];
int temp,cur_bit=0;
sprintf(filename ,"%s\\file1.bin",cur_dir);
sprintf(filename2,"%s\\file2.bin",cur_dir);
fp=fopen(filename,"rb");
fp2=fopen(filename2,"wb");
temp=(int)fgetc(fp);
while (!feof(fp)) {
switch (cur_bit) {
case 50:fputc(0,fp2);break;
case 51:fputc(1,fp2);break;
case 52:fputc(2,fp2);break;
case 53:fputc(3,fp2);break;
case 54:fputc(4,fp2);break;
case 55:fputc(5,fp2);break;
default:fputc(temp,fp2);
}
cur_bit+=1;
temp=(int)fgetc(fp);
}
fclose(fp);
fclose(fp2);
unlink(filename);
rename(filename2,filename);
}
Please help me out
Chichi
-- modified at 0:21 Sunday 19th November, 2006
|
|
|
|
|
What do you mean by "it crashes"? Does it give you an error message? If so, what is the message? what line in your code does the error occur on? What are the values of the variables that are being accessed on that line?
You have to provide more information if you want an answer. All you will get otherwise is some wild-ass guesses.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
hihi,
the error is "installer.exe has detected a problem and it has to close......inform Microsoft....debug...dont send". It is in spanish so I do not know if my translation is perfect.
In my code there r 2 comment lines. The first comment is where an error occurs when trying to fgetc if filename is greater than 40 characters. I assume the other error I get is where the first occurrence of fputc if filename2 is greater than 38 characters long.
I am sorry for not being explicit in my POST, but I guess logically oriented people sometimes assume our short explanations are more than enough.
Chichilina
|
|
|
|
|
Does increasing the length of your filename buffers work?
char filename[256],filename2[256];
Seems pretty weird to me, but like PJ said, what errors are you getting?
[edit]This is one of those wild-ass guesses [/edit]
-- modified at 1:04 Sunday 19th November, 2006
- S
50 cups of coffee and you know it's on!
|
|
|
|
|
hihi
no it doesnt, I just tried it. Please let me know if my explanation is clear now.
|
|
|
|
|
Well, I'd say fp == null and fp2 == null, which indicate it couldn't open either file.
You need to check for that in your code:
fp = fopen(filename, "rb");<br />
if ( !fp )<br />
{<br />
}<br />
- S
50 cups of coffee and you know it's on!
|
|
|
|
|
did that too without any success. the fp/fp2 values r correct. filename opens and filename2 gets created. the cur_dir variable is sent from GetCurrentDirectory(512,cur_dir); in the main program. So running the program from "C:\games" yields to no error, but running it from "C:\games1234567890123456" will crash.
|
|
|
|
|
What if you tried hard coding the long path name in your call to binary_edit, instead of using GetCurrentDirectory. Does that work?
I tried many variations of short and long paths with your function and they all worked for me.
- S
50 cups of coffee and you know it's on!
|
|
|
|
|
Steve Echols wrote: I tried many variations of short and long paths with your function and they all worked for me.
See below - he has a buffer overrun bug that causes GetCurrentDirectory() to stomp on random memory.
|
|
|
|
|
Ah, good eye!
- S
50 cups of coffee and you know it's on!
|
|
|
|
|
its a she btw 
|
|
|
|
|
Check your return values - you're not checking whether the fopen() calls succeed.
Run the program in the debugger (F5) and when it crashes, the debugger will show you exactly where it's happening.
|
|
|
|
|
Loaded 'ntdll.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\kernel32.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\user32.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\gdi32.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\advapi32.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\rpcrt4.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\ole32.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\msvcrt.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\comctl32.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\MSCTF.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\oleaut32.dll', no matching symbolic information found.
Loaded 'D:\Archivos de programa\Internet Download Manager\idmmkb.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\clbcatq.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\comres.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\version.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\shell32.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\shlwapi.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9\comctl32.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\setupapi.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\linkinfo.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\ntshrui.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\atl.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\netapi32.dll', no matching symbolic information found.
Loaded 'D:\WINDOWS\system32\userenv.dll', no matching symbolic information found.
The thread 0xE8 has exited with code 0 (0x0).
The program 'C:\p123123123123123123\asdasdasd\installer\Debug\installer.exe' has exited with code 0 (0x0).
however the .exe file still gives me the same error.
Chichilina
|
|
|
|
|
I suspect it's your call to GetCurrentDirectory, which will return different values when you run in debug mode versus executing the .exe directly, through explorer or a shortcut icon. I could be wrong of course....
- S
50 cups of coffee and you know it's on!
|
|
|
|
|
#include "stdafx.h"
#include <stdio.h>
void binedit (char *cur_dir) {
FILE *fp,*fp2;
char filename[256],filename2[256];
int temp,cur_bit=0;
sprintf(filename,"%s\\file1.bin",cur_dir);
sprintf(filename2,"%s\\file2.bin",cur_dir);
fp=fopen(filename,"rb");
if (!fp) {MessageBox(NULL,"error filename","a",MB_OK);return;}
fp2=fopen(filename2,"wb");
if (!fp2) {MessageBox(NULL,"error filename2","a",MB_OK);return;}
temp=(int)fgetc(fp);
char a[256];
sprintf(a,"%s %d",filename2,strlen(filename2));
MessageBox(NULL,a,"param",MB_OK);
while (!feof(fp)) {
switch (cur_bit) {
case 650:fputc(1,fp2);break;
case 651:fputc(2,fp2);break;
case 652:fputc(3,fp2);break;
case 653:fputc(4,fp2);break;
case 654:fputc(5,fp2);break;
case 655:fputc(6,fp2);break;
case 656:fputc(7,fp2);break;
case 657:fputc(8,fp2);break;
case 658:fputc(9,fp2);break;
case 659:fputc(10,fp2);break;
case 660:fputc(11,fp2);break;
case 661:fputc(12,fp2);break;
case 662:fputc(13,fp2);break;
default:fputc(temp,fp2);
}
cur_bit+=1;
temp=(int)fgetc(fp);
}
fclose(fp);
fclose(fp2);
unlink(filename);
rename(filename2,filename);
}
int APIENTRY WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,
LPSTR lpCmdLine,int nCmdShow) {
char *cur_dir;
cur_dir=new char;
GetCurrentDirectory(512,cur_dir);
binedit(cur_dir);
return 0;
}
I run this exe from the explorer in "C:\p1231231\asdasdasd" without any problems. if i add a 2 to the first directory "C:\p12312312\asdasdasd" I still have no problems. However if I changed it to "C:\p12312312123123123123\asdasdasd" I get a crash. I do not understand.
Does the other ppl who r trying to help me also receive this POST? or do I have to reply him as well with the code also. Sorry but I'm noob in this.
Chichilina
|
|
|
|
|
char *cur_dir;
cur_dir=new char;
GetCurrentDirectory(512,cur_dir); Not sure if this is causing the crash, but that code is wrong - you're only allocating one char but you're telling GetCurrentDirectory() that you allocated 512. This is a buffer overrun bug and GetCurrentDirectory() will end up writing to random memory, which may be corrupting the CRT enough to make fopen() crash.
(BTW, everyone can see the whole thread, this one reply is just fine, welcome to CP )
|
|
|
|
|
hrmmmm, i feel so dumb !!! ty ty ty
i think i need eyeglasses or something. that did solve the problem.
thank you all for your time, and sorry for this. Next time i'll make and extract like i just did, right at the beginning, so i don't waste all of your time with my brainfarts. 
Chichilina
|
|
|
|
|
chichina wrote: Does the other ppl who r trying to help me also receive this POST?
No, but they'll see it if they are interested.
chichina wrote: I run this exe from the explorer in "C:\p1231231\asdasdasd" without any problems. if i add a 2 to the first directory "C:\p12312312\asdasdasd" I still have no problems. However if I changed it to "C:\p12312312123123123123\asdasdasd" I get a crash. I do not understand.
Yeah, that's pretty weird. I've tried a bunch of different folders and they all work for me.
- S
50 cups of coffee and you know it's on!
|
|
|
|
|
I assume that the code where you get the current directory name looks something like the following:
char szBuffer[512] = "" ; // <- this buffer is big enough, right?
GetCurrentDirectory(512, szBuffer) ;
I agree with Mr Dunn that there must be a buffer overrun going on somewhere. Such overruns often don't occur when running in debug mode, then rear their ugly head in a release build.
Scott
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
