12日：星期四
1：自已寫(xiě)的windows響應(yīng)停止操作時(shí)出現(xiàn)，無(wú)法停止服務(wù)報(bào)0XFFFFFFFF的錯(cuò)。
主因是響應(yīng)SERVICE_CONTROL_STOP操作時(shí)，把狀態(tài)退出碼置為-1了。其實(shí)服務(wù)已經(jīng)停止了。
總結(jié)：在寫(xiě)control處理函數(shù)時(shí)，要響應(yīng)SERVICE_CONTROL_STOP，SERVICE_CONTROL_SHUTDOWN操作碼，否則服務(wù)無(wú)法停止。沒(méi)有響應(yīng)的請(qǐng)求都調(diào)用
SetServiceStatus設(shè)置當(dāng)前狀態(tài)。函數(shù)中出錯(cuò)的部份把出錯(cuò)碼設(shè)為負(fù)數(shù)并設(shè)置服務(wù)狀態(tài)，進(jìn)一步停止服務(wù)。
14日：星期六
1：UDP數(shù)據(jù)報(bào)可以是多大？
理論上UDP數(shù)據(jù)報(bào)大小是根據(jù)IP首部的2字節(jié)最大長(zhǎng)度（65535-IP首部長(zhǎng)度-UDP首部長(zhǎng)度），但是實(shí)際上不能有這么大。
UDP的數(shù)據(jù)報(bào)大小建議不超過(guò)512字節(jié)。 主要原因是RFC要求主機(jī)每次最少能接收570個(gè)字節(jié)，如果是UDP數(shù)據(jù)報(bào)，那么用戶(hù)數(shù)據(jù)大小是：
570-14（以太網(wǎng)頭）-20（IP頭）-8（UDP頭）
這就表示如果用戶(hù)數(shù)據(jù)小于該范圍，就不會(huì)產(chǎn)生分片（其實(shí)還得看線(xiàn)路MTU)。 數(shù)據(jù)報(bào)一旦產(chǎn)生分片，數(shù)據(jù)報(bào)丟失的可能性將會(huì)很大，這主要是對(duì)于大數(shù)據(jù)報(bào)，IP層會(huì)試探著大的MTU，
而IP失敗之后也并不重發(fā)。再者UDP和ARP的交互也決定了UDP數(shù)據(jù)報(bào)最好別分片，如果本地沒(méi)有目的地址，那么在發(fā)送數(shù)據(jù)報(bào)前，必先發(fā)送ARP，每一個(gè)分片后的包會(huì)發(fā)送一個(gè)這樣的
ARP，但是最后IP層只會(huì)保證發(fā)送最后一個(gè)分片，其前面的分片丟失了，所以如果分片，那么這種情況也會(huì)導(dǎo)致UDP數(shù)據(jù)報(bào)不能完整地傳送到目的的。
2：路由器和廣播
廣播分為限制廣播，網(wǎng)絡(luò)廣播，子網(wǎng)廣播和所有子網(wǎng)廣播，目前幾乎所有路由器的默認(rèn)實(shí)現(xiàn)對(duì)這幾類(lèi)廣播都會(huì)隔離，而橋接器之類(lèi)的網(wǎng)絡(luò)設(shè)備才不會(huì)隔離任何廣播。
23日：星期一
1：char數(shù)據(jù)值為負(fù)的錯(cuò)誤。
char *sz[10];
......
int i = sz[i]<<5;
本意是累加sz[i]的加權(quán)數(shù)，由于char的范圍是-128---127所以sz[i]可能為負(fù)數(shù)，背離了意圖。改為unsigned char之后就正常.
2：LARGE_INTEGER，_int64，longlong等計(jì)算錯(cuò)誤.
LARGE_INTEGER li;
li.QuadPart = 4096 * 0XFFFFFFFE;
由于4096 * 0xFFFFFFFE的運(yùn)算是整數(shù)int運(yùn)算，所以溢出部分拋棄，得出的數(shù)據(jù)還是個(gè)int型，賦值給LARGE_INTEGER，_int64，
longlong也是被截?cái)嘀蟮臄?shù)。
改進(jìn)：
LARGE_INTEGER li;
li.QuadPart = 4096;
li.QuadPart = li.QuardPart * 0XFFFFFFFE;
31日：編譯程序后提示不是有效的WIN32應(yīng)用程序
1：項(xiàng)目在前幾天編譯后還可以正常運(yùn)行，今天編譯后程序的圖標(biāo)資源也不再原來(lái)的樣式，換成是程序的默認(rèn)圖標(biāo)。雙擊運(yùn)行提示不是有效的WIN32應(yīng)用程序，
用DEPENADS打開(kāi),提示有的模塊 鏈接錯(cuò)誤，查看活動(dòng)解決方案平臺(tái)是X86，進(jìn)入活動(dòng)解決方案管理器中，X86選項(xiàng)對(duì)應(yīng)的是x64。 把對(duì)應(yīng)項(xiàng)選回win32，編譯后一切正常。
2：宏中參數(shù)與結(jié)構(gòu)體成員同名引發(fā)的錯(cuò)誤，示例如下：
struct SECOND_BLOCK
{
UINT magic1;
UINT magic2;
UINT uid;
DB_TIME t;
};
#define INIT_SECOND_HEADER(ins, uId, t) \
ins.magic1=ins.magic2=SECOND_HEADER_MAGIC;\
ins.uid=uId;\
ins.t=t
在上述的代碼中，宏中參數(shù)t與該結(jié)構(gòu)體中元素t用了相同的名稱(chēng)，在如下的調(diào)用時(shí)會(huì)出錯(cuò)
INIT_SECOND_HEADER（header, 1, 0);報(bào)出在常量前面要有分號(hào)和常量不有為左值的兩個(gè)錯(cuò)誤，原因是宏展開(kāi)結(jié)果后面的這句是header.0=0。所以出錯(cuò)了。
在面對(duì)這個(gè)錯(cuò)誤時(shí)，我們可曾抱怨編譯器太笨了，同時(shí)這一特性我們也給我們帶來(lái)了求結(jié)構(gòu)某成員偏移地址等等易用的宏。