林健的BLOG

　　那天帮 @shellex 恢复分区表时，@Sisyphusliu 师兄一针见血地指出：你怎么能用盗版 Windows PE 上的盗版软件呢？师兄说得有道理。其实我用那个“完美者 U 盘维护系统”就是图个方便，国内团队就这点做得好，把什么 Windows PE、Linux、DOS 再加一堆应用软件帮你攒到一个映像文件中，直接写到 U 盘上就一切 OK 了。但版权问题则被直接无视了，谁让国内就是这个大环境呢？但懒惰永远不是借口，明知使用盗版是有问题的，就要想办法解决。
　　有关 Windows PE 的版权问题，我从微软官方以及 Wikipedia 查到的说法大致是：拥有 Windows 授权的用户可以使用 WAIK 或第三方工具（如 BartPE）免费制作 Windows PE 映像，但前提是要基于合法授权的 Windows 安装介质。自己制作的 Windows PE 光盘或 U 盘可以在对应授权的电脑上合法使用，但不能够向他人分发（经过微软特别许可的除外，如 Symantec 维护工具盘）。至于个人制作的 Windows PE 介质能否在他人电脑上合法使用（即帮人修电脑），似乎是有争议的。不过我想到一个避免争议的方法：使用一套合法授权但未安装过的 Windows 介质来制作 Windows PE，这样在使用时，这套 Windows PE 同一时刻只运行于一台电脑，就不会违反微软的 EULA 了。实际操作时完全靠自觉，因为多数 Windows PE 制作工具只需要 Windows 光盘或 ISO，而不检查序列号之类。Windows XP 的授权我以前通过 Imagine Cup、DreamSpark 以及 IEEE 和 ACM 的 MSDNAA 得到过若干套，我声明将其中一套用于 Windows PE 即可。
　　自己从头搭建实用工具环境太烦琐，我使用 UBCD4Win 这个第三方软件直接生成集成多种实用工具的 Windows PE 环境。这个软件的作者比较重视版权问题，在网站上提供了微软的相关法律文书。其集成的第三方工具全都是免费或自由软件；也有少量商业软件，但必须由用户自己准备 license 文件才能运行。
　　除了 Windows PE，实用工具 U 盘上还应该有 Linux 和 DOS 工具集，我分别选用了 SystemRescueCd 和 UBCD。UBCD 还集成了 FreeDOS 和 Parted Magic 等环境，方便在必要时使用。这几套工具的合法性也得到了我的验证。相比国内的各种工具盘，UBCD4Win 和 UBCD 对中文的支持不好，不过网上也有人提供了东亚语言插件。SystemRescueCd 默认使用 Unicode 编码且集成了中文字体，比较方便。
　　关键的步骤是将 UBCD4Win、SystemRescueCd 和 UBCD 写在一块 U 盘上。Google 一下，果然有现成的解决方案，比如 SARDU 和 YUMI。YUMI 支持集成的 Linux 发行版种类多一些，但不支持 UBCD4Win 生成的 Windows PE，需要折腾一下才能共存。SARDU 对各类 Windows PE 以及第三方实用工具盘的支持较好。简单对比之后，我选用了 SARDU。
　　在使用 SARDU 制作实用工具 U 盘时，我遇到了两个问题：其一，首次制作出来的 U 盘在 QEMU 虚拟机中可以启动，但在物理机上不能启动。在 SARDU 论坛中居然找到了这种匪夷所思的解决办法：使用 RMPrepUSB 软件将 U 盘格式化为“not-bootable”的。也许是因为 U 盘中残存的某种启动机制与 SARDU 冲突吧。设置完“not-bootable”再用 SARDU 重新制作一次，启动物理机正常。其二，启动 Windows PE 时出现找不到 NTDETECT.COM 的错误。查找一下发现 NTDETECT.COM 文件位于 miniub 目录。仿照 Windows XP 的安装布局，将 NTDETECT.COM 复制到 U 盘根目录之后，启动 Windows PE 正常。这有可能是 SARDU 与新版本的 UBCD4Win 不兼容造成的。
　　为体现合法实用工具 U 盘的专盘专用，我给它加上了 DIY 的启动画面。上图一张——

　　盗梦终端是什么？请参考 TualatriX 这篇很火的文章。
　　如果想在 Windows 的 Command Prompt（cmd）下实现相同的把戏，首先遇到的问题是 cmd 没有内置的 SHLVL 环境变量来获取递归层次。不过这个很好解决，我们只要利用 cmd 的 AutoRun 机制，让它在每次启动时计数即可。由于子进程会继承父进程的环境变量，这个计数值就会随着递归层次的增长而增长。具体方法是添加如下注册表项：

　　此时在 cmd 中执行 echo %SHLVL%，即可查看当前位于第几层递归调用。如果想测试一下 cmd 递归调用最多能有多深，那么同样可以利用 AutoRun 机制不断启动 cmd 实例。这里我们保留 set 命令的输出结果，以便看到每次迭代的 SHLVL 值。

　　由于无从得到 cmd 的源代码，我不知道 cmd 递归执行有没有深度限制。在一台 Windows 7 机器和一台 Windows Server 2008 机器上测试，当递归达到 3000+ 和 6000+ 层时，两个系统分别报出了“The system cannot execute the specified program”错误，从 Taskman 看应该是内存耗尽，此时其他程序也难以正常启动。
　　不过这个 SHLVL 可能没有 bash 中的 SHLVL 那样有用：在 bash 中，直接运行脚本会新启动一个 bash 进程，因此在嵌套调用的脚本中可以使用 SHLVL 得知嵌套层次；但在 cmd 中，直接运行批处理文件（或使用 call 命令嵌套调用批处理文件）是在当前 cmd 进程中执行命令，除非用户通过 cmd /c 强制开启新进程运行嵌套的批处理文件，否则当前 SHLVL 永远和外部 cmd 的 SHLVL 一致。
　　那么使用 call 方式嵌套调用批处理文件时，有没有办法能够做到不用修改每一层的批处理文件而得知嵌套层次呢？我暂时没有发现。call 方式允许的递归层次受限于 cmd 进程的栈大小。在我测试的机器上，一个递归调用自身的批处理文件在递归 1240 层之后占用了 90% 的栈空间，此时 cmd 将批处理终止。

　　另外想到了几年前研究过的一个与之相关的问题：在同一个 cmd 进程中，setlocal 命令设置的本地环境变量栈是有深度限制的，目前版本限制为 32 层。cn-dos 上有一个帖子也讨论过这个问题。

　　IPv6 环境一般使用 DHCPv6 和 ICMPv6 协议自动配置网络参数，网关配置错误或多个网关的存在会导致客户端得到错误或冲突的配置参数。最近在我使用的 IPv6 环境中，就出现了网关同时给一个客户端分配多组 IPv6 地址、两个 IPv6 路由的问题，这使得路由发生混乱，IPv6 网络无法连通。由于种种原因，网管一直未能解决此问题，我们只好试图在客户端动动脑筋。
　　按照 IPv4 的经验，如果 DHCP 有问题，直接手工配置静态地址即可。但我们的环境中，即使手工配置了静态的 IPv6 地址和路由，发现没过多久又会恢复原状。看来还是有一定的自动配置机制在作祟。经搜索得知，这是 ICMPv6 的路由发现（Router Discovery）特性，系统会根据其收到的 ICMPv6 包自动修改 IPv6 配置。下面要做的就是过滤与路由发现相关的包。
　　在 Linux 下，可以使用 ip6tables（即 iptables 的 IPv6 版本）过滤相应的 ICMPv6 包：

　　可以将上述命令加入 /etc/rc.local。或使用 ip6tables-save 导出到文件，在启动网络前使用 ip6tables-restore 恢复。
　　在 Windows Vista/7 或 Windows Server 2008 以后的版本，可以使用这条命令：

　　执行一次之后持久生效，重启后不用再次执行。
　　而在 Windows XP 下，目前还没有发现很好的办法。XP 对 IPv6 的支持仅仅是一个“预发行版”，实现并不完善。手工配置 IPv6 地址和路由只能使用“ipv6 adu”、“ipv6 rtu”命令，而没有图形界面支持；虽然 XP SP2 以后 Windows 防火墙加入了 IPv6 支持，但仍不支持 ICMPv6。我没有查到 XP 下屏蔽路由发现协议的标准方法，目前可行的办法是使用支持 ICMPv6 的第三方防火墙软件，比如 ZONEALARM Internet Security 8 以上版本。

　　当你发现你收到的多封邮件中，同一个人的名字都被“死”字代替，这是不是一件恐怖的灵异事件？这事就被我遇到了。不过经分析，这只是搜狗拼音输入法与 Foxmail 引发的一个小问题。

　　出问题的名字是“查老师”，“查”在姓氏中读“zhā”。在搜狗拼音中，输入“zha”，“查”字的排名比较靠后；然而有一个与“查”字外形相似的“査”字（注意下面是“且”而不是“旦”）却像李鬼一般地排在了“查”字之前（它做了 SEO 吧 :)）。“査”是一个不常用的 GBK 汉字，但是发件人使用的 Foxmail 客户端生成的 MIME 消息中，标称的 charset 却写的是默认的 GB2312（严格地说也算 bug）。于是在我的客户端里，“査”字（96CB）没有被当作 GBK 正确解码，它的第二字节（CB）与“老”字（C0CF）的第一字节（C0）结合，恰好构成了“死”字（CBC0）。
　　提醒使用拼音输入法的同学，不要再把“查”误输入为“査”。如果怕输错，可以直接用“cha”代替“zha”。而在邮件客户端方面，可以设置发出的邮件编码，用 GBK 或 UTF-8 取代 GB2312，以免少数非常用汉字导致接收方解析出错，造成对方收到“死”这种很不礼貌的灵异邮件。

　　koomail 曾是一个简洁小巧的 Windows 邮件客户端，是抵制 Foxmail 的良好选择，我使用它大约有两年了。但自从某个版本开始，koomail 界面变得花哨，不断增加一些华而不实的功能，还在主界面弄出了“山寨酷友”之类的 SNS 广告。相反地，我发现并上报的一些 bugs（涉及远程邮箱管理、RSS 阅读等）它却迟迟没有修复；我在其论坛提出的一些建议（诸如回复邮件时给原文前加上“>”这样的基本功能）也没有得到过作者的重视。于是，今天决定抛弃 koomail，在 Wikipedia 上另找一些优秀的邮件客户端。
　　在研究这些客户端的过程中，发现老外们整出来的 mbox、Maildir、MH 等一系列邮件存储格式还是比较有用的。使用这些规范的格式毕竟有助于软件更替和数据移植，因此格式支持成为我考虑的重要因素。在将 koomail 的邮件导入其它客户端时，我发现部分邮件会被报告 MIME 错误，或者只能看到邮件头而看不到正文。经查这是因为 koomail 保存邮件时，将 SMTP（RFC 2821）中表示通信结束的“.”也存入了邮件文件，还在后面追加了一行不知做什么用的“k[0x01]m”。而 mbox 等格式规定文件只需存储 RFC 2822 消息本身。明白了原因，就可以写一个 bash 脚本来处理所有的邮件，消除 koomail 留下的两行“余孽”，让其它客户端可以正常读取：

　　这时使用 Claws-Mail 客户端读入邮件（因为它和 koomail 一样，每封邮件是一个独立的文件），导出为 mbox 之后再在 Thunderbird 等其它客户端中阅读也是正常的。