BOOL CALLBACK MainDlg (HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
TCHAR cName[MAXINPUTLEN]={0};
TCHAR cCode[100]={0};
。。。
if (cName[0] == 0||len<5)
{
lstrcpy(szBuffer,szEnchar);
SetFocus (GetDlgItem(hDlg,IDC_TXT0));
}
else
{
if(GenRegCode(cCode, cName ,len)) //此处调用序列号计算的子程序
{ lstrcpy(szBuffer,szSucc);
EnableWindow(GetDlgItem(hDlg,IDC_TXT0),FALSE);
EnableWindow(GetDlgItem(hDlg,IDC_TXT1),FALSE);
}
else
lstrcpy(szBuffer,szFail);
SetFocus (GetDlgItem(hDlg,IDC_TXT1));
}
MessageBeep (MB_OK);
DialogBox (hInst, MAKEINTRESOURCE (IDD_CHECK), hDlg, CheckDlgProc ) ;
。。。
}
BOOL GenRegCode( TCHAR *rCode, TCHAR *name ,int len)
{
int i,j;
unsigned long code=0;
for(i=3,j=0;i<len;i++,j++)
{
if(j>7) j=0;
code+=((BYTE)name[i])*Table[j];
}
wsprintf(name,TEXT("%ld"),code);
if(lstrcmp(rCode, name)==0) //比较真假序列号,这里为了省事,直接比较了
return TRUE;
else
return FALSE;
}
为什么是存入esp+4C和esp+9C这两个地址呢?我猜是对话框对象被创建的时候系统就那么分配的。。不晓得猜测正确不
esp或ebp的加或减说明是局部变量或者函数参数,看代码知道是cCode, cName这两个局部变量传到调用GenRegCode(cCode, cName ,len)之后的实参。用esp+4C而不用ebp+8或其他是因为编译器做了这样的选择,代码中并没有玄机。
只是不明白,为什么算号函数出来第一时间不平衡栈,而是把GetDlgItem的地址引用给edi?难道编译器就是这么无脑整的?
我猜是编译器为了配合CPU的乱序执行而做的优化。
只是发现00401354这一行的比较有点多余,在00401347这一行,edi=用户名长度,而用户名长度不够在算号函数之外已经有这样的判错了,能进入算号函数用户名长度一定不会比3小!我将00401354,00401356两行改成NOP,暂时没有发现任何问题,这又是编译器没优化的原因吗?
看源代码,作者在函数外部的判断是界面部分,用来产生提示;内部判断是算法部分。不应该靠人来保证参数的正确,无论何时进行参数检查是必要的。