06
Sep
关于Win32 FileObject对象的大小MSDN上说的不清楚，回顾了一下internal.
Win32下一个文件对象的大小设置放在FILE_OBJECT的FsContext域中，而FsContext的结构参加FSRTL_COMMON_FCB_HEADER定义
typedef struct _FSRTL_COMMON_FCB_HEADER {
CSHORT NodeTypeCode;
CSHORT NodeByteSize;
UCHAR Flags;
UCHAR IsFastIoPossible;
UCHAR Flags2;
UCHAR Reserved;
PERESOURCE Resource;
PERESOURCE PagingIoResource;
LARGE_INTEGER AllocationSize;
LARGE_INTEGER FileSize;
LARGE_INTEGER ValidDataLength;
} FSRTL_COMMON_FCB_HEADER;
关于文件大小的几个参数都是又
AllocationSize是当前为此文件分配的在磁盘上存储空间大小，通常为为一个扇区大小的的2的N次方倍
FileSize 是给用户显示的文件大小，指文件中包含的字节数，此值由文件系统驱动或网络重定向器初始化，每次这个值改变的时候必须通知缓存管理器
ValidDataLength指文件流中可读的有效长度，因为可能预定义了一个文件流长度，由于延迟写的关系，只写入了部分数据，剩下的长度还未写入数据的情况
三者一定是ValidDataLength <= FileSize <= AllocationSize的关系
04
Sep
因为部分要用到AES,找了一下开源库。开源的c++算法库有Crypto++和Botan。用过python的crypto,估计c++的也是大同小异。
搜到一篇文章，比较了一下两个库的用法，供参考
http://cookingandcoding.com/2008/09/20/c-crypto-libraries/
23
Aug
以前怕wordpress数据库升级很麻烦，也没有太多升级的需求，估耽搁至今。如今3.0的后台漂亮了很多，特意在空余时间升级了一下，过程记录如下
1.下载最新的安装包
2.备份原目录，删除原目录中的wp-include和wp-admin目录
3.解压新的安装包，覆盖原目录
4.删除原wp-config.php,重新配置wp-configsample.php
5.配置完之后用原账号登陆，会提示数据库需要更新，点击更新，一切OK
看网上的更新要点说最好更新前停用所有的插件，且最好一个版本一个版本的升级。这么两步没做就直接从2.5升级到了3.0.1，还是很顺利的
有点小遗憾是之前2.5的时候修改过wp-widget.php,把最近评论的内容直接截取出来了，3.0用的是一个default-widget.php,和以前的代码有点不兼容，还没来得及改好~~。先将就着用吧
13
Aug
最近在改一个自动更新的工具，涉及到前后交互新老进程，正好测试总结了一下python启动进程的一些方法
Python创建新进程的几种方式
1.父进程阻塞，且可以控制子进程，推荐用subprocess模块，替换了老的的os.system;os.spawn等，且可以传递startinfo等信息给子进程
2.父进程销毁，用子进程替换父进程，用os.exe**,如os.execv,os.exel等系列。注意在调用此函数之后，子进程即刻取得父进程的id,原进程之后的函数皆无法运行，且原父进程的资源，如文件等的所有人也变成了新的子进程。如有特殊必要，可在调用此函数前释放资源
3.异步启动新进程，父进程在子进程启动后，不阻塞，继续走自己的路。Windows下可用win32api.WinExec及win32api.ShellExec。win32api.WinExec不会有console窗口，不过如果启动的是bat文件，依然会生成console窗口
4.异步启动新进程，父进程在子进程启动后，不阻塞，继续走自己的路。在windows下，同3，可以用win32process.CreateProcess() 和 CreateProcessAsUser()，参数也通同系统API下的CreateProcess，比3好的一点是可以穿很多控制参数及信息，比如使得新启动bat文件也隐藏窗口等
5.用阻塞的方式创建一个新进程，如os.system,subprocess等，然后通过设置进程ID或销毁父进程的方法把新的子进程变成一个daemon进程，此方法应该用在linux系统环境中，未测试
另：推荐一篇参考文章http://book.opensourceproject.org.cn/lamp/python/pythonwin/opensource/pythonwin32_snode135.html
15
Jul
以前用的SVN，想作一个SVN的版本库自动备份的功能，然后查查资料，居然就查到了git.
虽然以前有听说过分布式版本控制如何如何好，还是觉得SVN够用了，就没怎么研究
根据这两天的调查，发现各有利弊,对本人来说，选择这两个工具的理由如下
git:
1.版本控制放在根目录下的.git目录下，全部版本就一个控制点，非常便于管理，SVN有时会想到要写脚本把部分目录下的.svn文件夹删除
2.每个版本库都是独立的，自带所有的版本历史记录，这样就免于前面说的需要作版本库备份的工具了，只要维护一个远程仓库，一个本地版本，任何一个版本的丢失都不会造成损失
3.分支管理的切换非常便捷，svn如果作branch并工作的话需要作工作区的拷贝，如果工程项目很大的话维护起来略微有些不便
4.commit信息可以修改，这个特点不一定是优点，不过对于个人开发来说还是有点用处，SVN如果comment写错或要修改的话或者一两个文件忘记提交的话都要分别提交几次版本，git就方便很多
5.个人开发的话远程仓库部署非常简单，而且可以直接利用SSH的帐户，也不需要用SVN的服务了，少了一些资源和端口
6.本地版本管理很快，而且不需要每次都和远程仓库同步，可以在提交很多次之后一次同步
svn:
1.权限控制，svn可以精确控制每个目录的权限，而git强调源码共享的概念，即使能做权限控制也要把工程事先分成不同的块分别作仓库，之后如有变动，更改也是一个麻烦
2.。。还在想～～
还有git-svn这种东西，本地可以自己管理，共享库用svn的集中方式，也许有机会可以在现有的项目中尝试一下