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