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。所以出错了。
在面对这个错误时，我们可曾抱怨编译器太笨了，同时这一特性我们也给我们带来了求结构某成员偏移地址等等易用的宏。