2005.3.29

微软内部软件工程传统之一是"BUGBUG"。当开发人员不确定他们正在开发的某段代码是否正确完备时，或者认为这段代码存在潜在问题、将来需要进一步调查时，他们会在代码上添加一段注释，说明这些情况。

据我所知，BUGBUG的概念最初是由Alan Whitney提出，他是我在微软工作时的第一任老板，他第一个向我解释BUGBUG的用途。

scz: 后来看泄露的微软源码，确实有很多BUGBUG注释，而且有些大洞真就发生在那儿。

2005.4.4

上周三我接到继母Norma的电话，你爸爸今天在法庭上昏倒了，现在医院，我们不知道他恢复得怎么样。我一下子慌了，打电话给Valorie，她进入了"超级称职妈妈"模式。当我下午1点到家时，她已经查好了航班，为孩子们安排了托儿服务。我开始预订航班并租车。感谢上帝赐予Valorie。

2005.4.12

显然，微软在抢救这些早期blog时把时间序搞乱了。

Windows 1.0团队中一位非常资深的开发人员在产品发布之前大约6个月的时候向全公司群发了一封邮件，他宣布不再调试排查任何系统崩溃，因为它们都是由硬件故障引起的。事实证明，他几乎说到点子上了。他花了几个星期在数十台主机上调试一系列问题，每次都是由于第三方内存条引发的。

你瞧，当年主机典型配置是512K内存，为了获得额外的128K乃至640K内存，人们购买第三方扩展内存。这些第三方扩展内存总是用低档的内存芯片，没有奇偶校验，或者干脆就是坏的。而这位开发人员碰巧遇上了大量的坏内存条。

2005.4.3

It turns out that on VW cars (and other manufacturers), the pattern for the door key is based on the VIN for the car. What that effectively means is that the security of your VW (or other) car is based solely on the difficulty of cutting the keys for the lock - all the information needed to generate the keys is publicly available (and externally visible on the car).

我对汽车安全完全不了解，或许将来可以问问谢君或者bluerust啥的，上面这段话的意思应该是说，汽车钥匙纹路的生成完全依赖于汽车的VIN，这是个啥？总之，这玩意儿外部可见，活见鬼。

2005.5.25

windbg的!error可以查看错误代码的文本意义，也可以在cmd中"net helpmsg"。

scz: 这个技巧我现在都在用。

2005.6.6

从32位向64位移植代码时signed long会惹麻烦。假设32位情况下bit-31置位，移植到64位时将进行有符号扩展，变成一个很大的负数。

2005.6.7

很久很久以前Windows团队就做出过决定，不会将Windows移植到big-endian序的处理器上。在可以预见的将来，仍将如此。几乎所有即将推出的新处理器要么是little-endian序的，要么是同时支持两种字节序的，Windows支持的所有RISC处理器俱如此，所以这并不是什么大问题。