2007年07月30日 13:56
同事在MSN上收到了一份photos.zip文件，打开之后是一个scr后缀的可执行文件，她下意识的点了一下之后就中毒了：MSN对话窗口不断的弹出，CPU占用率100%。无奈之下找我帮忙。
我先让她断掉网络，并且直接关机——因为我极度怀疑不断弹出的对话窗口是病毒在向其他好友发送带毒文件——如果真是这样的话，首先应该减少病毒的扩散。
然后重新开机，我使用Process Explorer查看进程，没有发现可疑进程。但仍然会不定时的弹出某个temp文件夹下随机名字的exe执行错误的信息——这让我确认病毒仍然是存在的。
因为收到的那份文件已经被删掉了，所以我只能凭借当初第一眼的印象，将“MSN 病毒 scr photo zip”这几个关键字输入google来搜索。然后找到一些信息，说在windows目录下存在一些photos*.zip，以及在system32目录下存在sysprinters.dll或者syshosts.dll，但我查找之后发现，Windows目录下的确有几个zip包，二话不说我就把它们删了。但sysprinters.dll和syshosts.dll都不存在。只好继续找其他的信息。
但是找了一圈，似乎得不到其他的信息了。于是只好翻到以前的查找结果再看看有什么有价值的信息没有。然后我注意到，在病毒信息里提到这两个dll都是经过ShellServiceObjectDelayLoad这个键值加载的。于是开始在注册表中搜索ShellServiceObjectDelayLoad，并且打开自己电脑上的相同键值进行对比。果然发现一个可疑的键值： printers 3B694700-CC93-4D16-8524-5A5A95D1B165，联想到刚刚看到过的sys
printers.dll，我几乎立刻就确定这是我需要找的东东了。然后去找了一下那个GUID，发现了一个libcintles3.dll，名字居然完全不同，难怪一直都找不到。
不过为了保险起见，我还是多方确定了一下。首先在Process Explorer中搜索了一下这个DLL，发现是被explorer加载的——嗯，比较可疑。然后找到了它的路径——c:\windows\system32，将它改名成libcintles3.dll_1，还好，没碰到什么麻烦。然后去注册表的ShellServiceObjectDelayLoad键下面删掉了printer条目，但暂时保留了COM注册键——这样万一删错了也不至于出太大的问题。
然后重启，重启之后插上网线，登录MSN——突然冒出一堆对话窗口，着实吓了我一跳，难道说清除失败了么？不过后来发现CPU并没有变成100%，鼠标也还能动，于是去瞧了瞧那些对话框的内容，原来是一大堆人正在问发生了什么事——原来如此，这下我才放了心。然后操作了explorer，MSN还有做了一些其他的日常工作，貌似没有出什么问题。于是开始做最后的收尾工作——删除注册表中的GUID键值（COM注册键），还有删除那个被改了名字的DLL，再观察了几分钟——似乎一切都正常。
于是，这次手工清除的任务结束了。
2007年07月27日 09:31
利用了若干个上班下班路上，我终于把王小峰的《十面埋妇》给看完了。还好，没有像某些人一样一路快进。
据说这是一部电影。从1小时40分的时间长度上来看，它也确实像是一部电影。
然而我的感觉是：这是一部还算不错的超长情景剧。
剧本感觉还挺好的，情节设定也还不错，起码还能让人能看下去。但最后一个镜头实在太突兀了，之前没有任何的伏笔交待，感觉完全就是为了表现而表现的。
不过机位设置、镜头运用方面实在很难让人觉得是在看电影，固定机位设置，几乎不变的镜头，刻意而突然的场景切换，加上调侃的对话，总让人更多的觉得是在看一部情景喜剧。只有最后那场吻戏，镜头的运用还让人觉得有点电影的感觉。
音乐部分我没有什么经验，不多谈了，只是个人感觉在靠近结尾处，丁丁回家走在路上的那段配乐，离画面实在太远了，根本就是两个体系，完全没有融合在一起。
同样是个人电影，胡戈的《007大战黑衣人》电影元素就完整得多了。所以，编剧还是干好编剧的活就好了，导演这件事，还是让有导演天分的人干吧。
2007年07月26日 16:02
最近不知道是因为太热还是因为别的原因，时间似乎过得特别快。往往是自己还没有从忙碌但又毫无头绪中清醒过来，一天就过去了。
也正因为如此，当我发现我的blog已经5天没有更新的时候，还是吓了自己一跳。
最近信息接受得少，脑袋里一片空白，就提一下自己近期的打算好了。
* 家里的那台破电脑昨天再次罢工，这次下决心要买台新的了。
* 小虫照片最近因为两个人都忙，拍的少了，最近应该要恢复，争取做一个10月专辑。
* 欠着3个程序，要把欠债还清
希望这该死的天气能尽快凉爽起来。
2007年07月21日 16:24
LP要求写一个自动生成可以将数据批量导入淘宝助手的小脚本，事实上就是生成一个批量文本文件。
两天前写了一个初版，结果发现生成的数据根本导不进去，郁闷，暂时放弃之。
今天没有工作的困扰，重新检查脚本，查了半天，发现原来淘宝助手要求的是UTF-16 LE格式的文件，我一开始误以为是GBK，所以死活导不进去。好在Python切换编码很方便，于是就写了一个转码函数，在写入的时候将原先的GBK文本转换为UTF-16。
本以为至此就大功告成，没想到运行以后发现，总有部分文字是乱码。但是检查代码，又发现不了什么大的问题。于是又开始郁闷了。
被逼无奈下，只好祭出好久不用的16进制编辑器，然后将生成文件精简到最小，跟用淘宝助手导出的相同内容进行逐字节的比较。一番努力之后，终于发现了问题所在：在我的文件里，凡是碰到0A的地方，都被替换成了0D 0A！
我一下子醒悟过来：原来我在代码中，使用了"w"模式进行写文件操作，在Windows下，w模式被认为是文本模式，使用文本模式进行文件读写的时候，会进行回车符的替换动作。也就是说，在写入的时候，将"\n(0A)"替换成"\r\n(0D0A)"，而在读出时做相反的动作。这样可以保证文本处理的一致性。
这种替换动作是基于ASCII编码的，在ASCII兼容编码体系（如GBK、Big5或UTF-8）中，也没有问题。然而，UTF-16是
不兼容ASCII的！也就是说，在UTF-16中，0A并不是回车符（000A才是，不过在LE规则中，000A会被表示成0A00）。所以，Windows这种自作聪明的替换动作就会带来麻烦。
问题找到了，解决就很简单了──只要使用"wb"以二进制模式写入即可，二进制模式是不会对写入读出的内容做任何处理的。脚本也很快就被改好了。
不过经过这样一折腾，觉得字符编码的问题比以前认为的还要复杂得多──所以我相对还是比较喜欢与ASCII有良好兼容性的UTF-8编码格式。
BTW: Linux/UNIX下没有这个转换的问题。因此在Linux下生成文件时不会有上面所说的烦恼，但在Linux下读写Windows生成的文本文件时，又经常会被那个多余的\r字符所困扰。
2007年07月19日 21:02
北京电视台为"纸箱馅包子"虚假报道道歉
北京电视台的记者们啊，费这么大劲只为了去编一个“纸馅包子”的假新闻，太得不偿失了吧。下次要跟台湾学习，弄点
黑帮阿、军火阿什么的，这样我们看着才精彩刺激嘛。
2007年07月18日 09:37
一向很少涉及时事的TR，终于也忍不住写了一篇
因父之名，其中提到说为什么在这样的紧急状态下，居然没有人拉下地铁上的紧急停车闸。
其实我认为，这不能完全怪乘客。地铁站里一直在播放一个电视宣传片，告诉人们紧急停车闸不能乱拉，是违法的。只有在火灾等情况下才能拉。但是没有任何地方告知过屏蔽门可能存在危险。而按照猛禽
亲眼所见，这种情况并不是唯一这一次，只不过其他的没有发生这么严重的事故而已。这样对于没有专业知识的公众来说，他们怎么能判断出人被夹在门里是一种极度危险的紧急情况呢？既然不能判断出是否紧急情况，又有谁会冒着“违法”的风险去拉下紧急停车闸呢？
其实这种公众宣传，在很多方面——地铁只是很小一个方面——都是非常欠缺的，比如地震、洪水之类的突发自然灾害的自救，其实基本上没有看到有什么有效的宣传，火灾好一点，楼道里能还能看到一些宣传——大概实在是比较频繁吧。但有些事情不是说很少发生就可以不用让大家保持警惕的，毕竟上海也是在地震带上的。
其实公众宣传并不是暴露自己的缺点，如果只是为了保持一个“和谐”形象而选择隐瞒可能发生的危险，我认为这种做法是相当不负责的。
2007年07月15日 16:10
早上去电影院看变形金刚。
排了一个多小时的队才买到票，而且不是上午的半价票──因为已经卖完了──是还需要等待一个多小时的下午全价票，可是这又有什么关系呢？
电影开始，看到少了集装箱拖挂的擎天柱，看到雪弗莱牌的大黄蜂，看到变成了飞机而不是手枪的威震天，看到那比例严重失调的眼镜，可是这又有什么关系呢？
据说这剧情重新设计，跟动画片版全无联系，可是这又有什么关系呢？
我们进电影院，不就是为了看到那些熟悉的名字，听到那久违了的吱吱嘎嘎的变形声，外加一场精彩的电影，而现在，我们已经得到了这一切。那么，其他的问题，又有什么关系呢？
看完之后就一个感觉：爽！
这就足够了。
2007年07月13日 22:11
几天因为加班没看电视，今天终于可以差不多按时下班，结果打开电视一看，东方卫视没有播放我熟悉的《东方新闻》，而是在转播《新闻联播》。
我靠，特立独行的东方卫视终于被和谐掉了。全国山河一片红，晚上7:00的电视节目还真tmd精彩~~
BTW：今天猛禽和另一个朋友的镜头在ChinaJoy同时被偷，这社会还真和谐，真稳定阿~~~
2007年07月11日 10:28
今天早上一来就看到一条“大”消息：
Fcitx停止开发了。
Fcitx是我最喜欢的Linux软件之一，现在出了这样的新闻，当然我是要关心一下的。
不过和网站上的大片惋惜之声不同，我并不认为一个作者放弃自己的自由软件项目有什么奇怪。我一直都认为，开源是个人的兴趣使然，如果有朝一日个人失去了兴趣，那么放弃这个项目是完全正常的。在开源圣经《大教堂与集市》中，作者也是接手了一个已经被放弃了项目开始他的开发之路的。但是自由软件项目跟一般的商业项目不同，作者停止开发并不意味着这个项目就真正死亡。因为源代码还在，用户还在，只要用户足够多，需求足够多，肯定有人会捡起这个源码继续维护开发下去的 —— 其实这也是自由软件项目的生命力所在。
sourseforge的cvs上有fcitx的源码，任何有兴趣的人都可以去下载，也可以尝试改进 —— 我始终都认为，开源不是一种责任，它是一份兴趣。
2007年07月10日 08:39
令狐虫先生的家用电脑，于2007年7月9日晚不幸猝死家中，享年5岁。
很幸运（也许是很不幸），最终结果并不是猝死，而是间歇性休克。昨天无论如何都唤不醒的电脑，今天无聊的去按了一下开机按钮，它居然奇迹般的运转起来了！
面对此情此景，我只能说，人生大起大落，实在是太~~~~~~~刺激了。
2007年07月09日 13:18
其实这部电影在我的硬盘上存在很久了，昨天终于愿意把它掏出来看了一遍。
总的感觉是：很失望。
其实一开始的感觉并不是这样的，影片一开始的阴沉气氛渲染得很成功，让我一下子想起了《1984》里的场景——虽然那场景对我而言过于沉重，以至于我不想再去回味。然而无论如何，在这样沉重的场景之下，发生一些什么事情的话是很愿意让人去关注的。接下来是一系列的背景交待——人类丧失生育能力、非法移民、反政府组织……，虽然时间设定在并不遥远的2027年，但总觉得是在影射着历史和现在。至此，背景设置完成，而且看起来场面很宏大，内涵很深刻。
再接下来就是主角出场了——一个怀孕的小女孩。而影片也很快的变成了一个追捕片——一方不停的逃，一方不停的追。而为什么会如此惊心动魄危机重重，似乎并没有太多的交待——也许这并不是导演想说的吧。
再接下来，突然就满屏幕的子弹横飞，尸横遍野。战斗开始之后，被营造了大半部电影时间的那种压抑感完全被破坏，让人感觉从《辛德勒名单》突然转台到了《拯救大兵瑞恩》，前后的关联，实在是很牵强。
小女孩终于被救出，影片也嘎然而止。
脑海里除了阴郁的伦敦街头，还真的感觉挺混乱的。
也许是导演想说的实在太多吧，实际上我觉得什么都没说。既然如此，还不如集中精力说好一件事。
去豆瓣上一看，很多人都在赞美某个长镜头——这也许就是它为什么得到技术奖的原因吧。可是我觉得，技术之外，它并不算是一部特别优秀的电影。
2007年07月09日 12:33
from
V2EX
非常有意思的是，中国和南极洲被涂成了同一种颜色，这代表什么？
A. “中国和南极洲一样安全”
B. “中国和南极洲一样危险”
C. “中国和南极洲一样不可预测”
2007年07月08日 10:20
看到有人在谈
Notepad++，颇感亲切。因为我曾经也是一个狂热的“编辑器试用者”，除了他提到过的EmEditor、UltraEdit、Editplus还有后面两个我认为算不上编辑器的SourceInsight和SlickEdit之外，我还用过
SciTE、
CrimsonEditor和
PSpad。而在一年前，我开始在家里全面转用Ubuntu开始，为了习惯vim的操作，我在Windows下也安装了gvim然后开始主力使用。经过一段痛苦的开头之后，现在已经逐渐适应了。以至于使用别的编辑器的时候，也经常会习惯性的按下ESC，然后:w。
最早的时候，我是UltraEdit的坚决拥护者，原因很简单：功能实在是很强大。但是某一天，我被它那个奇怪的注册框问题折磨得受不了的时候（所谓注册框问题，就是你明明已经输入了破解序列号，但下次启动时，它仍然会弹出注册框），我决定寻找一款别的编辑器来替换它。当时就尝试过NotePad++、CrimsonEditor、SciTE等多款，它们各有优点，但也各有不足。尤其是没有16进制编辑功能，对当时还在处理视频文件，经常要跟16进制打交道的我十分的不方便。于是又开始寻找16进制编辑器。尝试并放弃过一堆大大小小的编辑器之后，我选择了PSpad。只是当时的Pspad对编码转换还有很多问题，所以我不得不CrimsonEditor和Pspad配合使用。后来Pspad升级了好几个版本之后，编码转换已经没有什么问题了，我才全面转向它。
后来离开了那家公司，我对16进制的需求不是那么迫切了，但新的公司经常要接触UNIX，它的默认编辑器就是vi。再加上我自己也选择了Linux作为操作系统，因此我觉得选择vim并熟悉它是有好处的。而且现在时不时的要做一些文本文件的批量处理和分析，因此我还迷上了UNIX那批强大的文本处理命令──没错，就是sed、awk、grep、head、tail等等。配合shell或DOS下的for命令，批量处理文件真是方便又快捷。比写一段python代码更加方便──况且很多UNIX环境下python并不是默认软件。而熟悉vim的一个额外的好处就是：这些工具使用的行编辑命令或者正则表达式，是跟vim基本一致的，所熟悉的知识可以互补。
我并不觉得有完美的编辑器或其它什么工具（vim在某些方面也不太好用──或者是我还没学会）。但是，一款符合自己需要的工具，就是好工具了。
2007年07月03日 22:40
今天跟猛禽闲聊，聊着聊着突然发现一个“第二次定律”：尝试一个新东西的时候，通常第一次都会很不顺，而放上一段时间，第二次再用，就很顺手了。
我个人的例子：
1、我在高中的时候，是以Turbo Pascal正式进入编程领域的。当初也是羡慕那些用C的前辈(说来奇怪，我羡慕C，只是因为C语言的小写字母看着很舒服──当时几乎所有的BASIC或PASCAL或FORTRAN的教程，上面的代码都是大写字母为主的)，于是尝试去看了一点书，感觉仍然云里雾里（那时只能以看书为主，上机操作的机会是不多的），遂放弃之。过了大概一个学期，一次偶然的机会，在图书馆借到了一本K&R的《C程序设计语言》（当时并没有意识到这两个人有多么特殊的意义），翻看不久，突然感觉豁然开朗。那本书除了没有教我如何直接编译运行程序，其它的很多东西都说得十分清楚透彻，包括不少C标准函数的C实现。让我一下子感觉到，原来C就是这么回事呀……
2、同样在高中，尝试冲击C++，连续看了N本书都觉得不得其门而入，搁置之。有一次去书店看书（高中每周末都会去书店看书──只看不买 :P ），看到一本薄薄的《C++语言简明教程》，不到100页，定价8元。考虑到这是我当时买得起的为数不多的电脑书籍，我还是买下了它。看完之后，反倒比看那些砖头厚的大书有了一点感觉。当时朦朦胧胧的不觉得，后来暑假回家，一次午睡的时候，突然明白了什么叫做“封装”、什么叫“继承”──同时想到了一个猜字母的游戏可以应用上这些东西──其实就是大名鼎鼎的hangup猜字游戏，只是当时不知道这个游戏名称而已──于是兴致勃勃的爬起来写代码（当时家里已经有一台386SX电脑了）。我的电脑运行Turbo C++是很痛苦的，比TC2.0要痛苦的多，因此兴致勃勃写完代码后一编译，漫长等待之后出来无数的Error，又让我的兴致一下子消失得无影无踪。晚上翻书的时候，不知怎么的让我注意到类声明后面的那个分号，终于意识到自己错在哪里了。于是又跑到机器上第二次修改，运行，果然OK，不仅编译通过，而且完全像我预料的那样运行……
3、第一次听说Linux，是大一的时候。市面上可以买到一种叫做Xterm的中文版Linux了。当时我同学买了一套，我借来装了一下。好可怜，当时的我除了DOS和Windows之外没有接触过其它任何操作系统──确切的说当时还不是特别清楚什么是操作系统。当时对着装完的黑黑屏幕手足无措，想了半天，想到以前在书上看到过的一个UNIX命令──ls，于是输入了ls回车，果然出现了一些东西。于是胆子稍微大了一点，尝试了几个DOS命令，cd之类的（我当时DOS还算比较精通），有些行有些不行。然后我就说，嗯，我玩过Linux了。当天下午就重装了Win 97（没错，是97，不是98）。第二次接触Linux是很多年后了，大概2000年左右，我看到网上有一个不错的中文发行版，叫MagicLinux，于是就下载来装了，感觉还不错，当时因为自己对计算机的了解也增进了不少，眼界也开阔了不少，Linux虽然一直没有使用，但相关的知识还是耳濡目染了不少的，所以面对它就没有以前那样怕了──那次坚持了差不多2个月。第三次就是现在了，已经使用了快1年，并且没有感觉任何不舒服的地方……
4、刚刚毕业的时候开始真正接触现代C++，我很快就被它那完全不同于以往认知的强大所迷住。当时我疯狂的吸收一切关于标准C++的知识。在《Thinking in C++》一书的附注中，我第一次听说了Python。出于好奇，我下载并尝试了它。第一次尝试的时候显然没有准备好（自然，对于一个仅仅听说过名字的东西，怎么可能有多少准备呢），面对它（相对于我熟悉的C++而言）怪异的语法我有些不知所措。按照自己的想法，在交互提示符下输入了 print "Hello, world"，well，it works。so what？迷茫了半天之后我关闭了它，然后就遗忘了它。又过了几年，《程序员》杂志上发表了Python专栏，我看到了，再次对这个曾经接触过的语言产生了兴趣。我开始收集它的信息，我读了《Learning Python》、《Dive Into Python》，看了很多关于它的资料，理解了它的函数库，知道了它究竟能做什么。然后，我就对自己说，来吧，用python做点事吧。于是再次下载，开始写东西。第一个有点用的东西大概是一个定时闹钟──为了玩电脑的时候不会忘记正在烧着的开水而写的。当时也碰到了很多困难，比如因为空格和tab混用而造成的困惑等等。但不管怎么说，第二次在写代码方面还算是挺得心应手的了──现在，Python已经成为我工作之余使用最多的脚本工具了。
很有意思的“第二次定律”，不是吗？
2007年07月03日 14:45
这几天为项目整理了新的软件过程，其中有个要求就是让每个人提交的时候同时提交一份changelog，记录提交代码所做的修改。
我凭着记忆和自己的实际感受，整理了一份类似于以前在Autodesk使用的subdoc的文档样式(Plain Text格式)，同时做了一定的规范化，以便于以后脚本自动化处理。
今天向项目组的人告知时，一个人对我说，你为什么不用XML格式呢，程序处理多简单。
我当时没有回答他，只是说，已经这样设计了，先这么做吧，大不了以后写个脚本转换成XML。
可是回来之后仔细考虑了一下，我觉得使用XML不太妥。为什么呢？因为XML
对于程序是友好的，对于用户则不是。
而changelog并不是一个仅仅用于程序交流的介质，很多时候是要让人编写让人阅读的。写成XML格式，对于写的人写起来不方便，对于看的人也不方便。写起来不方便就会不愿意去写，看起来不方便就不愿意去看，弄到最后，就会失去更新的动力从而让提交changelog成为一句空话。虽然有人说，用XMLSpy之类的工具可以让读写这件事变得简单，但专属软件毕竟还是不够便利。让使用者觉得方便，还是非常重要的。
至于对它的自动化处理，我定义了一些
非常简单的规则，比如每个Item前面写一个序号+"." ，每个Item和它的注释之间用一个“--------”隔开等等（甚至我的脚本只要有五个连续的“-”就认为是分割符了，所以长短都可以自己决定）。这样写的人不用受太多的限制，读的人也觉得非常舒服。而有了这些简单规则的限制，脚本也是可以实现的（Python做文本分析本来就算是比较得心应手的）。
写代码时一味的为自己着想，不考虑用户感受，是不行的。
