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