Alexis Zhang's Blog

回顾 Windows 2000 十年风雨历程

alx-zj — Tue, 13 Jul 2010 04:00:00 GMT

南非世界杯落下了帷幕，章鱼帝威武预测，前皇马主帅、现皇马队长在半支巴萨球队簇拥下捧走了大力神杯。与此同时，Windows 产品家族的诸多版本也迎来了早先已经公布多时的 7.13 大限。Windows Server 2003 所有版本由主流支持期转入扩展支持期；Windows XP SP2 与 Windows 2000 的所有版本继 Windows Vista RTM 后停止技术支持，从此将不再为其发布新的安全更新。

Windows Vista RTM、Windows XP SP2 尚可通过升级至各自的 SP2、SP3 继续获得技术支持，而 Windows 2000 则将像 Windows 9X 一样与我们彻底道别了。自 1999 年底正式发布以来，Windows 2000 迄今已经历了超过十年的风风雨雨。做为 NT 技术进军 PC 消费市场的开路先锋，Windows 2000 做出了不可磨灭的贡献。

正如 Windows 2000 启动画面中醒目的“Build on NT Technology（基于 NT 技术构建）”的字样所说，这款操作系统源自 Windows NT。关于 NT 这个词，有人认为 NT 是 New Technology 的缩写，表示 NT 采用了区别于 Windows 9X 的新技术；也有人认为 NT 源于研发时采用的代号为 N-Ten（N10）的 Intel i860 CPU 模拟器，所以才有了 NT 这个名字。

NT 操作系统原本是由微软与 IBM 联合开发的 NT OS/2（OS/2 3.0）。但随着 Windows 3.X 的成功，微软把 NT OS/2 的程序开发接口由 OS/2 API 更换为 Windows API，这一举动导致了两家公司的分道扬镳。IBM 继续开发自己的 OS/2，微软则把 NT OS/2 更名为 Windows NT，并于 1993 年推出了 Windows NT 的第一个正式版本 Windows NT 3.1，以表示与 Windows 3.X 的版本号看齐。Windows NT 没有 1.X、2.X 版本。

尽管 Windows NT 采用了更为先进的核心技术，但是由于 Windows 3.X、Windows 9X 在 PC 消费市场的成功，微软并没有过早地将 NT 推向消费市场，而是一直低调地主攻工作站与服务器。正因为如此，很多人对 Windows NT 并不熟悉。笔者也是从 Windows 2000 开始学习 NT 的，仅在虚拟机中使用过 Windows NT 的早期版本。

得益于 NT 技术的高效与稳定性，Windows NT 在工作站与服务器市场表现非常优秀。Windows NT 3.1、3.5 采用了与 Windows 3.X 相似的用户界面，并从 3.5 开始将系统版本有针对性地区分为 Workstation 与 Server，这一做法一直延续至今。1996 年发布的 Windows NT 4 则采用了模仿 Windows 95 的用户界面，开始菜单、回收站、IE 等首次出现于 NT，IIS 等组件也从 Windows NT 4 开始逐步发展。不过，Windows NT 4 对 Windows 9X、MS-DOS 程序的兼容性依然很不理想，多数家用外设也找不到配套驱动。因此，Windows NT 4 依然不为个人用户熟知。此外值得一提的是，Windows NT 首次引入了 Service Pack 软件服务升级包的更新方式，并一直沿用至今。Windows NT 4 一共有六个 Service Pack，堪称历代 Windows 之最。

Windows NT 的早期版本在工作站与服务器领域打下了坚实的基础。做为继任者，Windows 2000 于 1999 年开始以版本号 5.00.2195 的身份正式进军 PC 消费市场。这个版本号中的 5 不仅可以理解为 NT 5，表示 Windows 2000 是 Windows NT 4 的延续；也可以理解为 Windows 5.0（相对于 Windows 9X 的版本号 4.0 而言），表示整个 Windows 产品家族从第五代开始转向 NT 内核。

其实，Windows 2000 的早期测试版本确实曾经被命名为 Windows NT 5.0。只不过微软担心这种传统的命名方式可能依然不会引起 PC 消费用户的重视，再加上 Windows 9X 以年份命名版本的方式大受欢迎，因此经过慎重考虑，微软最终在 Windows NT 5 与 Windows 2000 两个候选名中选择了后者，同时也把 Workstation 重命名为更平易近人的 Professional。这些名称的调整的确收到了预期效果，Windows 2000 刚发布便引起了用户的重视，很多人甚至不了解 Windows 2000 与 Windows 9X 在内核方面的差别，便得出了“Windows 2000 是 Windows 98 接任者”的结论，掀起了一股升级换代的热潮。然而，由于 Windows 2000 在发布初期依然延续着对 Windows 9X、MS-DOS 程序兼容性不佳及驱动更新不上的问题，所以在普及初期并不顺利。很多性急的游戏玩家仅仅试用了几天，便迫不及待地重新用回了 Windows 98；还有一些人选择了配置 Windows 2000 与 Windows 98 的共存，对 Windows 2000 持观望的态度。微软之所以在 Windows 2000 发布一年后又匆忙地发布了 Windows ME，很大程度是为了“赶场救急”。

这种尴尬局面直到 Windows 2000 发布一段时间后才逐渐缓解，随着四个 Service Pack 及一系列系统更新的推出，Windows 2000 的向下兼容性得到了很大的改善，再加上 2000 年后越来越多的软硬件厂商逐渐转向 NT 系统平台，广大 PC 消费用户逐渐了解到 Windows 2000 的诸多优点。得益于纯 32 位的 NT 架构，Windows 2000 完全避免了 Windows 9X 的 16 位/32 位混合架构极不稳定的问题。虽然对旧版程序的向下兼容性仍略有不足，但是 Windows 2000 在运行 32 位程序时表现出来的稳定性与可靠性令人惊叹，个别方面甚至比后续版本的 Windows 做得还要好。可以说，Windows 2000 是有史以来稳定性最好的 32 位 Windows 之一。

在系统功能方面，Windows 2000 吸取了 Windows NT 与 Windows 9X 两者的优点。很多原本在 Windows NT 工作站与服务器中专用的技术开始随 Windows 2000 走进消费市场。例如，基于 NT 专用的 NTFS 文件系统，诸如设置磁盘的访问权限、磁盘配额、EFS 加密与压缩等 FAT32 文件系统无法实现的功能逐渐普及，并且一直沿用至今。还有 Windows 2000 引入的 PnP、高级电源管理、WDM 驱动规范、Active Directory、RAID－5 存储方案、分布式文件系统、安全删除硬件、MMC 管理控制台、系统服务、组策略等全新的组件与管理方式，这些都是随着 Windows 2000 在 PC 消费用户中逐渐普及的。

对以前很多习惯 Windows 9X 的老用户而言，Windows 2000 对他们的操作习惯影响最大的一点就是将用户帐户与用户权限的概念引入了 PC 个人电脑。此前 Windows 9X 的用户帐户仅仅起着保存个性化设置的作用，毫无安全性可言，只要删除了 .PWL 文件，任何人都可以重置用户帐户，密码形同虚设；而 Windows 2000 的用户帐户则不仅可以保存个性化设置，还可以按照管理员或受限的级别设置不同的操作权限，安全性相比 Windows 9X 大为提高，同时，也令多人共用的公用计算机的管理变得更为方便。当然，Windows 2000 早期版本的登录机制还是存在漏洞。不知现在还有多少人记得 Windows 2000 输入法登录漏洞及删除 SAM 破解密码之类的技巧。这些都为 Windows 后续版本的安全性改进提供了借鉴与参考。

在对硬件设备的支持方面，Windows 2000 开始支持多路处理器，增加了对 IEEE1394 等设备的支持，并且首次提供了可移动式磁盘的通用驱动程序（记得从什么时候开始闪存盘不用再额外安装驱动么？就是 Windows 2000）。同时，Windows 2000 内置的驱动程序比 Windows 9X 丰富很多，不少用户在第一次安装 Windows 2000 时惊奇地发现显卡声卡已经由安装程序自动配置，首次启动 Windows 2000 就可以看到真彩色的桌面、听到悦耳的启动提示音，再也不必忍受 Windows 98 在 16 色桌面中安装驱动的痛苦了。此外，Windows 2000 还提供了 Internet Explorer 5、内置了 DirectX 7，这些功能组件令 Windows 2000 拥有足够的资本取代 Windows 98 成为 PC 个人电脑操作系统。

然而，Windows 2000 毕竟是整个 NT 5 系统家族的第一款产品，它的风头很快就被不久之后粉墨登场的同门兄弟 Windows XP 超过了，两者的关系很像 Windows Vista 与 Windows 7。只不过 Windows 2000 发布初期没有 Windows Vista 宣传得那么高调，因此它在普及初期承受的骂声比 Windows Vista 少很多。笔者认为，每当 Windows 发生重大内核升级的时候，第一款试水的产品（Windows 2000/Vista 都属于这种产品）应该低调一些，特别是当前一代产品还没有完全落伍的时候，用户需要时间改变习惯。直到新一代产品被用户初步接受，发布换马甲的第二款产品时（Windows 7/XP 都属于这种产品）再高调宣传也不迟。像 Windows Vista 那种刚一发布就气势汹汹、恨不得一夜取代 Windows XP 的宣传攻势是很失败的。笔者希望微软发布 Windows 8 时吸取教训，现在 Windows 7 好不容易才获得用户的首肯，如果 Windows 8 为了强赶“三年内必须发布”的军令状而匆忙地发布半成品，或者又过于高调地宣传并立即停止 Windows 7 的全部销售，有可能会重蹈失败的覆辙。

言归正传，由于 Windows XP SP2 在 2004 年取得显著成功并逐步坐稳了主流操作系统的宝座，所以微软对 Windows 2000 的扩展性升级就显得不是那么用心了。很多新版的组件，例如 IE 7，都在技术上还有可能实现的时候提前终止了对 Windows 2000 的支持。在 7.13 大限来临之际，Windows 2000 各组件的最终扩展性为：

1. Service Pack 终止于 SP4，SP4 之后仅发布过一个 Rollup Updates for Windows 2000 SP4 更新汇总，除此之外没有新的官方更新合集，仅有终止于 7.13 大限的零散安全更新；

2. NTOSKRNL.EXE 核心最后一次升级为 KB979683，文件最终版本号为 5.00.2195.7376；

3. IE 浏览器版本终止于 IE 6 SP1，IE 6 SP1 或者 Windows 2000 内置的 IE 5 最后一次升级为 KB982381；

4. DirectX 终止于 9.0c，最后一次升级为 2010 年 2 月，6 月发布的最新 DirectX End-User Runtimes 安装程序不再支持 Windows 2000；

5. Windows Media Player 终止于 9.0；

6. MSN Messenger 终止于 7.0，所有名为 Windows Live Messenger 的更高版本均不支持 Windows 2000。

所有的软件产品都拥有固定的生命周期，Windows 2000 经历了十年的风雨历程，如今已经走到了尾声。总体来说，Windows 2000 是一款褒大于贬的成功的产品，有资格入选 Windows 发展史的经典产品名人堂。做为 NT 技术进军 PC 消费市场的开路先锋，Windows 2000 做出了不可磨灭的贡献。在 7.13 大限来临之际，让我们一起说一声：再见，Windows 2000。

Windows 7/Vista 双系统共存引发的 ReadyBoost 冲突案例

alx-zj — Wed, 23 Jun 2010 20:00:00 GMT

笔者最近在新帆新闻组见到一则 Windows 7/Vista 双系统共存引发的 ReadyBoost 冲突问题。我们知道，ReadyBoost 是从 Windows Vista 开始增加的一种利用 USB 2.0 闪存建立 SuperFetch 加速系统的技术。虽然 USB 2.0 闪存的平均访问速度慢于硬盘，但是其随机访问速度却比传统的机械式硬盘快十倍以上，因此启用了 ReadyBoost 加速的 USB 2.0 闪存可以成为 Windows 高速缓存的有效补充。

通常我们在一台计算机中用一块 USB 2.0 闪存设置 ReadyBoost 加速不会遇到什么问题。可是如果计算机配置了 Windows 7/Vista 双系统共存，并且每个系统都用同一块闪存开启 ReadyBoost 加速会怎么样呢？根据新闻组网友思杰超灵描述的问题，当他在 Windows 7 中设置了 ReadyBoost 加速并切换至 Windows Vista 后，一旦试图在 Windows Vista 中为同一块闪存设置 ReadyBoost 加速，Windows Vista 立即出现代码为 0x00000023 的蓝屏。

0x00000023 代码表示采用 FAT 文件系统的磁盘导致的各类磁盘错误（如果磁盘采用了 NTFS 则代码为 0x00000024），例如文件系统错误、磁盘物理错误、磁盘碎片过多、IRP 损坏、或者存在体积过大的单个文件等等。在这个问题中，很明显是 Windows Vista 在试图应用 ReadyBoost 加速时，闪存出现了问题。当 Windows Vista 重新启动并执行磁盘扫描程序后，BOOTEX 显示了下列信息：

Checking file system on I:
The type of the file system is FAT32.

One of your disks needs to be checked for consistency.

You may cancel the disk check, but it is strongly recommended that you continue.

Windows will now check the disk.
Volume Serial Number is 24E1-156F

\ReadyBoost.sfcache first allocation unit is not valid. The entry will be truncated.
Windows has made corrections to the file system.

可以看到，闪存中由 Windows 7 建立的 ReadyBoost.sfcache 的第一个文件簇无效，无法被 Windows Vista 正确识别。

上述问题只会在 Windows 7 为闪存设置了“为提高性能而优化”策略时才出现，如果在 Windows 7 设备管理器中将闪存“写入缓存与安全删除”策略由“为提高性能而优化”修改为“为快速删除而优化”，问题就可以解决。

网友思杰超灵与笔者均认为这可能是 Windows 7 经过升级的“为提高性能而优化”策略与 Windows Vista 存在冲突引起的兼容问题。Windows Vista 可能无法正确识别 Windows 7 新的“为提高性能而优化”策略对闪存所做的修改，因此无法正确识别由 Windows 7 建立的 ReadyBoost.sfcache 缓存。当然，这个问题不排除闪存自身的原因引起的个例可能，需要经过更多的实地测试得出准确结论。如果哪位朋友对这个问题有独到的见解或个人经验，还望不吝分享。

告别陪伴多年的微软新闻组－转向 NNTP Bridge 方式访问论坛

alx-zj — Tue, 01 Jun 2010 10:00:00 GMT

相信很多人已经听说，为大众服务将近八年的在线技术交流平台－微软新闻组将于 2010 年 6 月 1 日起逐步关闭。从今往后，微软公众社区的所有在线技术交流都将分批转移至各级微软技术论坛（MSDN、TechNet、Answers）。

笔者做为 2002 年首批参与微软新闻组的老用户，这些年一直持续不断地参与新闻组、与广大网友探讨技术问题。根据笔者在 Outlook Express 中保留的“已发送邮件”统计，从 2002 年 9 月至 2010 年 5 月，笔者在微软新闻组累计发帖 30276 封；通过微软新闻组结识的朋友超过 150 位；同时，微软新闻组也是笔者了解微软社区、加入微软 MVP 大家庭的摇篮。对笔者而言，微软新闻组既像一位传授知识的老师、又像一位陪伴多年的好友。现在到了必须与这位良师益友告别的时候，笔者的心情自然是难舍难分、无比留恋。

当然，微软社区决定关闭新闻组的原因是可以理解的。首先，支持微软新闻组的 Exchange 服务器在运行多年后已经老旧不堪，难以继续承担日益增长的社区信息交流；其次，由于微软新闻组早年为了“攒人气”疏于对垃圾邮件进行管理、一直没有设置过身份验证，所以新闻组累积的垃圾邮件问题越来越严重、已经难以根治；再其次，很多用户对新闻组这种独特的交流方式缺乏了解，甚至有人从未听说过新闻组为何物，微软新闻组无法像 Web 论坛一样快速普及（这个理由其实很可悲）。因此，微软社区将在线技术交流平台由新闻组转移至 Web 论坛便成为了这种情势下的必然选择。

万幸的是，微软社区为了照顾那些喜爱新闻组交流方式的用户，特意开发了一种称为 NNTP Bridge 桥接的解决方案，允许我们使用 Outlook Express、Live Mail 等新闻组客户端软件访问微软论坛。虽然这不是真正的新闻组，却可以多少延续一下我们的新闻组体验，同时也是提升论坛访问效率的一种有效方法。我们可以访问：

http://connect.microsoft.com/MicrosoftForums

了解有关 NNTP Bridge 的详细介绍，下载并安装 Microsoft Forums NNTP Bridge v1.1 工具，在本地架设一台虚拟新闻组服务器，以便使 Outlook Express、Live Mail 等新闻组客户端软件可以将 NNTP Bridge 当作桥梁、通过它以新闻组的方式访问微软论坛。具体步骤如下：

1. 首先以 Web 方式访问微软论坛：

   http://social.microsoft.com/Forums/zh-CN/categories

   通过 Windows Live ID 注册成为微软论坛用户（已经注册可以忽略此步骤）。

2. 登录后在微软论坛的首选项中点击“我的设置”，勾选“使用 NNTP 桥接”复选框并保存。这样，我们以后通过 NNTP Bridge 方式发帖就可以被统计到个人社区活动经历中，如同通过 Web 方式发帖。

3. 访问 http://connect.microsoft.com/MicrosoftForums 并以 Live ID 登录，通过页面左侧的“下载”获取 Microsoft Forums NNTP Bridge v1.1 安装程序，下载并安装。

4. 安装完毕后运行 Microsoft Forums NNTP Bridge v1.1，切换至 Settings 选项卡，并将 Service URL 设置为：

   http://services.social.microsoft.com/ForumServicePreview/ForumsService.svc

   将 NNTP IP Address 设置为 127.0.0.1、LocalHost 或 IPv6 环回地址；将 NNTP Port 设置为 119。

5. 切换至 Login 选项卡，在 Server 框中点击 Start 按钮，稍后会弹出一个类似于 Live Messenger 的登录对话框，输入在微软论坛注册的 Live ID 进行登录。完成登录后，在 Server 框底会显示 Server Running。

6. 启动 Outlook Express、Live Mail 等新闻组客户端软件，新建新闻组帐号，将新闻组服务器名填写为在 Microsoft Forums NNTP Bridge v1.1 工具中设置的 NNTP IP Address（127.0.0.1、LocalHost 或 IPv6 环回地址）。至于新闻组帐号的用户名、电子邮件地址可随便填写，它们其实是不起作用的。另外，在建立新闻组帐号向导中请不要选择“此新闻服务器要求登录”，登录的步骤不由 Outlook Express、Live Mail 负责、而是由 Microsoft Forums NNTP Bridge v1.1 工具负责。

7. 建立帐号完毕后，Outlook Express、Live Mail 就会把运行中且已经登录的 Microsoft Forums NNTP Bridge v1.1 工具当作新闻组服务器（如果不运行 Microsoft Forums NNTP Bridge v1.1 工具，Outlook Express、Live Mail 无法单独工作），并通过它获取论坛的讨论组列表。这个操作只需要做一次。

如果上述步骤一切顺利，我们即可在 Outlook Express、Live Mail 中刷新出微软论坛的讨论组列表、订阅我们希望参与的讨论组，并可以像使用普通的新闻组一样发帖交流了。下面笔者简要介绍一下 NNTP Bridge 方式与普通的新闻组相比有何不同。

★ 如何确定正确的讨论组名称

目前，微软论坛的讨论组列表显得比较混乱，有些讨论组的命名缺乏规律可循。例如，一般性问题讨论组会在 Outlook Express、Live Mail 中显示为 Microsoft.zh-CN.1761、微软硬件组会显示为 Technet.zh-CN.2003 等。只有为数不多的讨论组可以从名称中看出它是什么组，例如 Windows XP 组显示为 Microsoft.zh-CN.windowsxpzhchs。笔者希望微软论坛能够考虑规范一下讨论组名。

当我们在 Outlook Express、Live Mail 中确定讨论组名时，可以选择“显示新闻组描述”复选框，把在 Web 端看到的论坛描述信息显示出来，方便我们对照。不过，目前新闻组描述只能显示论坛描述的英文信息、中文显示不出来。举个例子，当我们在 Web 端查看微软硬件组的描述信息时，可以看到下述文字：

“微软硬件组：华丽炫目的外观、精巧高效的无线连接、从 IntelliEye 至 BlueTrack 的顶级定位技术、舒适的人体工程学设计、方便的指纹识别、出色的 Web 数字通讯、顶级的游戏玩家体验.... 微软硬件产品服务无论在 Windows 7/Vista/XP 系统体验、Windows Live Web 通讯、Media Center 数字娱乐、Office 高效办公、还是驰骋于游戏战场，都是您的得力伴侣。”

除了中文无法显示外，IntelliEye、BlueTrack、Web、Windows 7/Vista/XP、Windows Live Web、Media Center、Office 这些英文单词可以显示为新闻组描述信息。因此，当我们在 Outlook Express、Live Mail 中看到 Technet.zh-CN.2003 这个组的新闻组描述信息是 IntelliEye、BlueTrack、Web、Windows 7/Vista/XP、Windows Live Web、Media Center、Office 字样，即可由此判定 Technet.zh-CN.2003 组是 Web 端的微软硬件组。

★ 帖子的哪些内容由 Outlook Express、Live Mail 决定

与普通的新闻组不同，当我们以 NNTP Bridge 方式向微软论坛发帖时，只有帖子的正文内容是由 Outlook Express、Live Mail 决定的，帖子的标题、发件人名称、自动签名等依然是由 Web 端的设置决定。例如，即使我们在 Outlook Express、Live Mail 中回帖时修改了帖子的标题，但当帖子上传至服务器之后，标题依然会被自动修正为“Re：原帖标题”；即使我们在 Outlook Express、Live Mail 中修改了自己的名字，但如果没有在论坛 Web 端的“我的设置”中修改名字，当帖子上传至服务器后，也将被自动修正为旧名字（这就是之前笔者说新建新闻组帐号时填写的用户名不起作用的原因）。总之，无论我们希望修改自己的名字还是修改帖子的自动签名，都应回到 Web 端的“我的设置”进行修改，在 Outlook Express、Live Mail 中修改是没有用的。

★ 能否像普通的新闻组一样上传附件或截图

新闻组虽然支持上传附件，但由于 NNTP Bridge 不是一个真正的新闻组，本质上还是 Web 论坛，所以我们即使在 Outlook Express、Live Mail 中发帖时插入了附件或截图，也无法正常显示，这是由 Web 论坛天生的弊端决定的。如果需要使用附件或截图，我们依然需要像在 Web 端发帖时那样引用来自网络的图片或其它附件。不过，假设其他人在他们的帖子中引用了来自网络的图片，我们在 Outlook Express、Live Mail 中可以直接看到引用的图片。

★ 如何解决以中文发帖乱码的问题

当我们以 NNTP Bridge 方式发帖时，帖子里的中文可能会显示为乱码。我们需要在 Outlook Express、Live Mail 中调整发帖时采用的编码格式以解决此问题。NNTP Bridge 的乱码并不是由帖子采用 HTML 格式还是纯文本格式决定的、也不是由帖子采用 GB2312 还是 UTF-8 决定，而是取决于发帖时采用的是 Uuencode 格式还是 MIME 格式。根据新闻组的两位老朋友 Batch、W.S 的测试，如果我们选择 Uuencode 格式，帖子的标题与正文都将乱码；如果选择 MIME 格式且勾选了“允许在标头中使用八位编码字符”，则帖子标题乱码、正文显示正常；如果选择 MIME 格式且采用了 Base64 之类的文本编码方式，也会出现乱码。因此，为了确保帖子的标题与正文都显示正常，我们应该在 Outlook Express、Live Mail 中选择 MIME 格式、不要勾选“允许在标头中使用八位编码字符”、并且在“文本编码方式”中选择“无”。

对于 Outlook Express 而言，这样设置不会有什么问题，但对于 Live Mail（或 Windows Mail for Vista）而言，如果选择 MIME 格式且不勾选“允许在标头中使用八位编码字符”，将引起无法在新帆等新闻组中发帖的问题（可以参考笔者以前所写的博客《从 OE 升级到 Windows Mail 后无法在新帆等新闻组中发帖的解决方法》）。因此，假如我们需要以 Live Mail 方式同时访问 NNTP Bridge 与新帆新闻组，必须经常修改 Live Mail 的编码格式设置。这对 Windows 7/Vista 用户而言无疑是个杯具。如果我们使用的系统是 Windows XP，笔者建议还是尽量使用 Outlook Express。

虽然 Microsoft Forums NNTP Bridge v1.1 工具目前还存在很多问题，但总体来说，以 NNTP Bridge 方式访问微软论坛的效果还是令人满意的，基本发挥出了新闻组简洁明了的特点。当我们展开一条拥有好几十封回复的帖子时，Web 端慢如乌龟的响应速度及超高的 CPU 占用率大家一定深有体会，Outlook Express、Live Mail 在这方面要胜过 Web 端百倍。而且，就像普通的新闻组一样，我们通过 Outlook Express、Live Mail 发送与接收过的帖子都可以保留在本地，方便我们随时温故而知新，即使没有网络连接也可以脱机查看，不像 Web 端那样必须联机登录后才能找到旧帖子。总之，无论我们以前是否有使用微软新闻组的经验，笔者都强烈推荐所有用户以 NNTP Bridge 方式访问微软论坛。

附 1：微软论坛 Web 端、微软新闻组、NNTP Bridge 功能对比

	微软论坛 Web 端	微软新闻组	NNTP Bridge
响应速度	慢	快	快
CPU 占用率	较高	较低	较低
是否需要身份验证（注册与登录）	需要	不需要	需要
能否管理垃圾信息	可以	不可以	可以（依然需要在 Web 端进行管理）
能否脱机访问	不可以	可以	可以
是否支持 Outlook Express、Live Mail 等客户端软件	不可以	可以	可以
是否支持附件或截图	不支持	支持	不支持

附 2：微软新闻组八年风雨历程回顾，以及笔者的发帖数统计（可以大致体现八年来微软新闻组的人气变化）

2002 年（笔者发帖数 128）：微软新闻组正式开通试运营；

2003 年（笔者发帖数 4717）：微软新闻组迎来了开通后的第一个黄金时期，MVP 评选、月度社区之星评选、微软在线商店等活动吸引了大量用户参与微软新闻组；

2004 年（笔者发帖数 4845）：微软新闻组迎来了人才井喷期，从这里涌现了大批技术水平优秀的 MVP，例如 Nuo Yan、盆盆、Steven、HaoHu、LiangZhen、Junxiu_Lee、youyang 等等，很多人目前已就职微软或在业界担当重要角色；

2005 年（笔者发帖数 4475）：微软社区经历了一次失败的改版，原有的在线版主管理工具、月度社区之星评选、微软在线商店等活动被废止，取而代之的 Mileage 系统没有取得预期的成功，最后不了了之；

2006 年（笔者发帖数 7697）：微软新闻组自 2006 年起，基本失去了官方的支持，不再开设新的讨论组、也无法对垃圾信息进行任何管理，之前所有与新闻组相关的社区活动也已全部停止，尽管如此，微软新闻组却意外地迎来了它的第二个黄金时期，人气倍增，笔者在这一年的回帖数是历年最多的；

2007 年（笔者发帖数 3674）：微软 Web 论坛于 2007 年开通试运营，微软新闻组的人气从此开始逐渐下降；

2008 年（笔者发帖数 2467）：微软 Web 论坛逐渐趋于成熟，而微软新闻组在得不到官方任何支持改进的情况下，走向没落的颓势已经无法挽回了；

2009 年（笔者发帖数 1653）：微软新闻组到了 2009 年基本已没有新用户参与，只剩下少数几位像笔者一样喜欢新闻组的老用户还在苦苦支撑，到了 2009 年底，部分长期无人问津或相应产品已经退役的讨论组被提前关闭；

2010 年（笔者发帖数 620）：微软新闻组于 2010 年 6 月 1 日正式退役。

Office 2010 安装配置问题汇总

alx-zj — Wed, 12 May 2010 09:40:00 GMT

Office 2010 RTM（14.0.4760）于 4 月 22 日通过 MSDN 发布，并于 5 月 12 日正式全球零售。笔者在第一时间通过 MSDN 订户下载了 Office 2010，在自己的电脑以及若干台虚拟机中进行了安装试用，在此期间先后遇到了一些安装配置方面的问题，在此小结供大家参考。笔者的技术专长不是 Office，文中难免有疏漏错误，还望熟悉 Office 的朋友不吝指正。

1. 如何将安装源解压缩还原

MSDN 发布 Office 2003/2007 时均采用了 ISO 光盘镜像格式，而这次发布的 Office 2010 却是一个 802MB/871MB（x86/x64）的 .EXE 自解压缩文件。当我们执行这个 .EXE 文件后，它首先会将 Office 2010 安装源解压缩至临时文件夹，然后再启动安装程序。

笔者认为，Office 2010 安装源使用 .EXE 自解压缩文件的实际意义不大，因为即使经过压缩后的 .EXE 文件也有 800 多 MB，无法装在一张 CD 光盘里，反而每次执行安装时都要花几分钟等待解压缩。还是将实际的安装源文件提取出来，另存为 ISO 镜像比较方便。

假设从 MSDN 官方网站下载的 Office 2010 的 .EXE 自解压缩文件名为：cn_office_professional_plus_2010_x86_515501.EXE，

我们可以以管理员权限在命令提示符中执行：

cn_office_professional_plus_2010_x86_515501.EXE /EXTRACT:C:\Office14

将 Office 2010 安装源解压缩还原至 C:\Office14 文件夹（可以随意命名）。然后将 C:\Office14 及其所有子文件夹、文件添加至 ISO 镜像，保存为一个类似于 Office 2007 的安装源 ISO 镜像即可，这样无论刻录光盘还是在虚拟机中使用都很方便，运行 C:\Office14\SETUP.EXE 即可立即启动安装程序。

2. 谨慎决定是否需要保留早期版本的 Office

很多用户在计算机中安装有早期版本的 Office（2007/2003）。与 Windows 类似，Office 2010 安装程序检测到计算机中已安装的早期版本后，也会弹出对话框询问用户是否希望：

将早期版本升级为 Office 2010（保留原有的个性化设置，类似于 Windows 升级安装）；
删除早期版本后安装 Office 2010（类似于格式化硬盘重装 Windows）；
保留早期版本并安装 Office 2010（类似于配置 Windows 多重系统共存）。

笔者认为，Office 2010 的升级安装不值得推荐。首先，安装程序能够保留的 Office 设置不是很多，保留的意义并不大；其次，由于早期版本 Office 都是 32 位软件，只有 32 位的 Office 2010 可以升级、64 位的 Office 2010 不能直接升级；再其次，由于微软软件的体积越做越大，升级安装的步骤也越来越繁琐，就像把 Windows Vista 升级安装为 Windows 7 一样，经笔者测试，把 Office 2007 升级安装为 Office 2010 花费的时间，比全新安装 Office 2010 多了将近三倍。因此，笔者个人不推荐升级安装 Office 2010。

相比而言，将早期版本 Office 卸载再全新安装 Office 2010 是更有效率的做法，缺点就是无法保留原有的 Office 设置。因此在卸载早期版本之前，我们需要手动备份或记忆原有的一些个性化设置。

如果我们选择将新旧不同版本的 Office 设为共存，例如 Office 2007 与 Office 2010 共存，笔者建议最好将它们安装在不同的文件夹里以避免冲突。假如我们依然选择默认的 C:\Program Files\Microsoft Office 文件夹，虽然 Office 安装程序可以在 C:\Program Files\Microsoft Office 文件夹中自动建立 Office11、Office12、Office14 等不同的子文件夹分别保存不同版本的程序文件，但它们彼此之间很容易互相影响。

笔者曾在一台安装有 Office 2007 的 Windows Vista 虚拟机中安装 Office 2010，安装时选择了保留早期版本并没有更改安装文件夹，结果每次启动 Word 2010、Excel 2010 等组件时，Office 2010 都自动弹出一个安装配置对话框，将 .DOCX、.XLSX 等各种 Office 文档的关联与自己绑定，等候几分钟才完成配置。配置完毕后，如果再启动 Office 2010 组件不会有问题，但如果启动 Word 2007、Excel 2007 等早期版本组件，Office 2007 又会自动弹出一个类似的配置对话框，花好几分钟将文件关联改回与自己绑定。下一次启动 Office 2010 组件时，Office 2010 又会再改回去...... 两个同门兄弟好像打架一样，谁也不放手。饱受煎熬的只有用户。

笔者认为，像 Word、Excel 之类常用组件没有必要设置新旧版本共存，保留一个版本就可以了。只有一些还没有发布 2010 最新版本的 Office 组件，例如 SharePoint Designer 2007，与 Office 2010 的共存才有实际意义。为了避免冲突，在安装新旧不同的版本时，笔者建议最好选择“自定义”安装方式，然后在 Office 可选组件列表中进行确认，不要重复选择任何两个版本都具备的组件。

以 Office 2010 与 SharePoint Designer 2007 的共存为例，笔者一开始配置它们的共存时也经常遇到冲突问题，每次启动不同版本的组件时，自动弹出的安装配置对话框几乎要令笔者抓狂。后来笔者重新安装 SharePoint Designer 2007，在“自定义”组件列表中只选择了 SharePoint Designer 2007 为“从本机运行全部程序”，而将“Office 共享功能”与“Office 工具”全部设置为了“不可用”。直到安装 Office 2010 时，才选择了“Office 共享功能”与“Office 工具”，这样 Office 2010 才与 SharePoint Designer 2007 相安无事地共存下来。如果笔者在两次安装时都选择了“Office 共享功能”与“Office 工具”，那么 Office 2010 与 SharePoint Designer 2007 十有八九会“掐架”。

总之，如果没有什么特殊要求的话，笔者认为 Office 2010 的升级安装以及新旧版本的共存都不值得推荐，它们都很容易引起问题。全新安装 Office 2010 是最省心的做法。

3. .net Framework 损坏可能会引起 Office 安装失败

笔者在另一台安装有很多软件、使用了很久的 Windows XP 计算机中安装 Office 2010 时，在安装到半途出现了“Error 1935：An error occurred during the installation of assembly component，Please contact Microsoft Support for help.”错误，安装程序被强行中止。经过排查，这个问题是由于 Windows 缺少 .net Framework 或其相关组件有所损坏引起的，只要修复 .net Framework 即可解决。

我们可以安装最新发布的 .net Framework 4.0。但需要注意的是，4.0 并不像 3.5 包含 3.0、2.0 那样包含早期版本。换句话说，假如我们在一台只安装有 1.0 的 Windows XP 中直接安装 3.5，安装之后即可获得 2.0、3.0、3.5 的全部版本；但是假如我们直接安装 4.0，那么安装之后将只拥有 4.0，不会随着 4.0 的安装自动获得 2.0、3.0、3.5。因此，如果我们需要 .net Framework 的全部版本，可能需要反复安装多次。

Windows 7 由于已经包含有 3.5，所以我们可以直接安装 4.0；Windows Vista 包含有 3.0，我们需要分别安装 3.5 与 4.0，一共安装两次；Windows XP 相对复杂一些，到目前为止，在 Windows XP 适用的所有版本中，1.0、1.1 及其相应 SP、还有 4.0 都是独立的，只有 3.5 with SP1 包含有 3.5、3.0、2.0。因此，要想在 Windows XP 中获得 .net Framework 的所有版本，我们至少需要安装六次，分别是：1.0、1.0 SP3、1.1、1.1 SP1、3.5 with SP1（安装后将自动获得 3.5 SP1、3.5、3.0、2.0）、4.0。

4. 如何令管理员用户与受限用户都可以运行 Office

Office 2010 安装程序要求我们以管理员权限运行，受限用户不能直接安装。但是，Office 2010 允许我们在一台计算机的多个用户帐户中同时运行，并可以分别保存每个用户的个性化设置。

假设我们以管理员用户 A 登录并安装了 Office 2010，用户 A 即可直接运行 Office 组件。如果在计算机中还存在其它管理员用户 B、C，以这些用户登录后首次运行 Office 组件，会自动弹出一个安装配置对话框，初始化用户的 Office 个性化设置。理论上说，这个初始化过程只需要做一次，配置完成后，下一次运行 Office 组件时就不会再出现了。

但是，假如用户 B、C 不是管理员而是受限用户，当它们首次运行 Office 组件时，虽然安装配置对话框也会出现，却可能会提示没有足够的权限完成配置，并有可能陷入配置进度条周而复始的死循环状态。有人可能会说：你可以先在管理员用户 A 中将用户 B、C 临时提升为管理员，等它们完成配置再降级为受限用户不就可以了吗？理论上说的确是如此。但笔者在之前的试用中，曾遇到过连这个方法也不奏效的案例：笔者通过用户 A 将用户 B、C 临时提升为管理员并等它们完成配置，经测试，下一次运行 Office 组件时已经不会再提示配置了。可是，当笔者把它们降级回受限用户后，再次运行时还是会自动弹出配置对话框，且无法完成配置并陷入死循环。但只要再将用户 B、C 重新提升为管理员，无需任何配置就可以直接运行 Office 组件。换言之，此时 Office 组件能否运行，已经完全由用户帐户的权限来决定了。

笔者并不是很清楚导致这一问题的具体原因，根据个人总结，笔者认为这可能是由用户 B、C 在用户 A 首次安装 Office 2010 时的用户状态决定。假设用户 B、C 在用户 A 首次安装 Office 2010 时已经是管理员，那么即使安装完成后将用户 B、C 降级为受限用户也不会有问题；或者，假设用户 B、C 在用户 A 首次安装 Office 2010 时还不存在，是在安装完成后才建立的，也不会有问题；但是，假设用户 B、C 在用户 A 首次安装 Office 2010 时已经是受限用户，就很容易出现上述问题。

因此，笔者个人建议，如果我们打算在多个不同的用户帐户中同时运行 Office 2010，最好在首次安装前将所有的用户帐户都临时提升为管理员，安装配置完成后再降级回受限用户；或者先不建立其它帐户，在安装完成后再建立新的用户帐户。这样可以最大限度地避免遇到受限用户无法运行 Office 组件的问题。

5. 添加删除程序列表为何会出现一大堆无法删除的 Office MUI 组件

通常在 Office 2010 安装完毕后，我们在控制面板的“添加删除程序”列表中只会看到一项“Microsoft Office System 2010 Professional Plus Edition”，通过它可以添加删除 Office 组件，修复或卸载 Office。不过有时候，当我们使用一些第三方工具软件对注册表进行扫描清理后，会发现“添加删除程序”列表突然多出了一大堆类似“Microsoft Office System 2010 Word MUI（Chinese Simplified）”、“Microsoft Office System 2010 Excel MUI（Chinese Simplified）”之类的新项目，足足有二十多个，而且每一项都无法删除，这是怎么回事呢？（此问题曾在微软新闻组中被人问起）

经笔者研究，这个问题只出现于 Office 2007/2010，Office 2003 不受影响。由于 Office 2007/2010 采用 Office 核心程序与语言包（MUI）相分离的技术，所以 Office 安装程序会在注册表中为 Office 核心程序及所有已安装的 MUI 都建立一条注册信息。以 Microsoft Office System 2010 Word MUI（Chinese Simplified）为例，它表示用户在安装 Office 2010 核心程序的同时，安装有中文版的 Word 语言包。Windows 可以由此判断，用户安装的是 Office 2010 的中文版，并至少包含有 Word 组件。

如果已安装的 Office 组件越多，注册表中关于 MUI 的项目也会越多。为了避免“添加删除程序”列表过于臃肿，Office 2007/2010 安装程序会在注册表的下述两个位置同时为 MUI 添加注册信息：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

HKEY_CLASSES_ROOT\Installer\Products

例如，假设我们安装的是包含有 Word 组件的中文版 Office 2010，我们可以在上述两个位置同时找到显示为 Microsoft Office System 2010 Word MUI（Chinese Simplified）的信息。Windows 在刷新“添加删除程序”列表时，会自动校对这两个位置的 MUI 注册信息是否一致。如果是，Windows 就会将其省略掉不显示，以使“添加删除程序”列表保持整洁；如果不是，Windows 就会在“添加删除程序”列表中将其显示出来，提醒用户 MUI 的注册信息有所损坏。

很多第三方的注册表清理工具会将上述两个位置的 Office MUI 注册信息视为冗余注册表垃圾项进行清理。但这两个地方其实都是不能删除的。无论哪一项被清理，都会引起“添加删除程序”列表显示一大堆类似 Microsoft Office System 2010 Word MUI（Chinese Simplified）的无效注册信息，因此当我们使用这类注册表清理工具时，如果提示在上述两个位置发现了关于 Office 的冗余注册表项，注意不要让它清理。

6. Office 文档的文件关联及默认的邮件客户端设置可能会被锁死

Office 2010 在安装过程中会自动将 .DOCX、.XLSX、.PPTX 等各种 Office 文档文件与自己绑定，并将 Office Outlook 设置为系统默认的邮件与日历客户端。理论上说，我们可以将 Office 文档的文件关联重新指向其它程序，或将默认邮件客户端重新修改为其它程序。但笔者在试用 Office 2010 时却遇到了一次 Office 文档的文件关联及默认的邮件客户端设置均被锁死的问题，无法修改上述的任何设置。例如，当笔者试图将 .DOC 文档与写字板绑定时，下一次打开 .DOC 文档的依然是 Word 2010；当笔者在 Live Mail 中试图将其设置为默认邮件客户端时，下一次启动 Live Mail 还会提示 Live Mail 不是默认的邮件客户端。

经排查，笔者发现涉及上述设置的注册表项都被剥夺了修改权限，例如 HKEY_CLASSES_ROOT 中的 .DOCX、.XLSX（决定这些文件的打开方式的注册表项），以及 HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail（决定默认邮件客户端的注册表项），管理员帐户对于这些注册表项的修改权限都被删除了，所以才引起上述的设置均被锁死，重新修改也无效。直到笔者手动为这些注册表项添加了相应的修改权限后，问题才得以解决。

笔者不清楚引起这一问题的原因究竟是什么，而且在若干次安装 Office 2010 的过程中只遇到了一次，猜测可能是与安装 Office 2010 时未关闭的第三方软件有关。如果哪位朋友知道这个问题的原因还望不吝指教。

7. Office OneNote 2010 因为 Windows 没有安装桌面体验而无法启动

这个问题主要出现在 Windows Server 2008（或 R2）系统中，由于服务器系统默认不安装 Windows 桌面体验，这将引起 OneNote 2010 无法启动。只要通过“打开或关闭 Windows 功能”重新安装 Windows 桌面体验即可解决。

不过非常诧异的是，笔者在一台 Windows XP 计算机中启动 OneNote 2010 时也遇到了相同的提示。Windows XP 哪儿来的桌面体验呢？笔者直到现在也没弄清楚引起这个问题的原因，猜测可能是 Office 2010 在检测系统版本时遇到了错误。如果哪位朋友知道这个问题的原因还望不吝指教。

8. 讨人厌的 OSPPSVC.EXE 服务

Office 2010 安装时会自动添加一个名为 Office Software Protection Platform 的系统服务，其执行文件为：Program Files\Common Files\Microsoft Shared\OfficeSoftwareProtectionPlatform\OSPPSVC.EXE。这个服务的默认启动类型为“手动”，但它在我们每次启动 Office 2010 组件时都会自动运行。

从字面理解，OSPPSVC 服务应该是 Office 2010 的软件自我保护平台。笔者不清楚这个服务究竟起多大的作用，不过我们千万不要将它的启动类型由“手动”修改为“已禁用”，否则在下一次启动 Office 组件时，令人抓狂的自动安装配置对话框又会出现，折腾好几分钟才完成配置，“已禁用”又会被修改回“手动”。换句话说，OSPPSVC 服务必须保持默认的“手动”状态才能维持 Office 2010 正常运行。就算我们觉得它碍眼，也不能将其禁用，拿它没有一点办法。

不过，好在 Office 2010 只要求确保 OSPPSVC 服务的启动类型为“手动”，并不要求 OSPPSVC.EXE 进程时刻常驻于内存，因此当我们使用完毕退出 Office 组件后，可以在“服务”列表中将 OSPPSVC.EXE 手动关闭（注意只是关闭，不是设置为“已禁用”），或通过 Windows 任务管理器结束 OSPPSVC.EXE 进程。这样做不会影响 Office 组件的下一次启动。

全文译稿 Windows Internet Explorer 8 性能优化白皮书

alx-zj — Wed, 21 Apr 2010 11:20:00 GMT

（注：本文被 Microsoft TechNet 中文速递邮件 2010 年第 8 期收录为 MVP 推荐 Blog、

并已转载于 cnBeta.com：http://www.cnbeta.com/articles/109232.htm）

微软上周发布了一份关于 Windows Internet Explorer 8 浏览器（以下简称为 IE 8）性能优化的白皮书《Windows Internet Explorer 8 Performance White Paper》，指导最终用户如何优化 IE 8 获得最佳的浏览器体验。笔者将其全文翻译为了中文，并添加了少许注释，供广大 IE 8 用户参考。以下以微软雅黑字体显示白皮书的译文、以 Arial 字体显示笔者的注释。

《Windows Internet Explorer 8 Performance White Paper》译稿：

基础部分：提高 Windows Internet Explorer 8 的性能

★ 指导最终用户优化 IE 8 以获得最佳性能

IE 浏览器是当今最流行、最受大众信任的浏览器之一。自从 1995 年首次发布以来，IE 一直致力于帮助 Windows 计算机用户使用 Internet。IE 历代版本均针对浏览器的性能与稳定性有所升级、确保用户在浏览 Internet 时拥有出众的体验，最新的 IE 8 亦同时在最终用户生产力与浏览器性能两方面引入了重要改进。

IE 8 的设计初衷是成为一种可以迅速启动并载入页面的高效浏览器。“新建选项卡－接着您想做什么”向导可以指导用户更高效、更简单地浏览 Internet。IE 8 用时开创了很多领先业界的创新性改进，例如用于提高浏览器稳定性的选项卡进程隔离技术（Tab Isolation）、自动崩溃恢复技术（Automatic Crash Recovery）等。IE 8 的这些性能改进帮助超过三亿的用户提升了 Web 浏览体验。

这份白皮书将帮助您学习如何解决一些寻常的因为 IE 8 配置不当引起的网络响应缓慢问题。我们将在复杂的浏览器系统中为您剖析一些有关如何提升 IE 8 性能的提示与技巧，使您尽快学习掌握。这些技巧将由易而难介绍给您，因此您可以尝试学习尽量多的方法，直到您满意为止。

如果您正在使用最新的 Windows 7 操作系统，IE 8 浏览器已经内置在您的计算机中。如果您正在使用 Windows XP 或 Windows Vista，您需要首先安装单独发布的 IE 8。

请访问 http://www.microsoft.com/china/windows/internet-explorer 获取更多信息。

★ 什么因素会影响 IE 8 的性能

当您点击 IE 浏览器的蓝色 e 图标、打开 Gmail 或更新您的 Facebook 时，您可能没有意识到有多少软件正在后台工作。大多数用户并不在意 Internet 是一个多么复杂的系统，但 IE 浏览器可能是这个系统的所有角色中对您影响最直接的一个。IE 浏览器的性能由许多不同的因素共同决定：计算机中您知道的或不知道的各种软件、Internet 连接速率、您浏览的网站的速率...... 等等，我们列出的只是一小部分。

由非微软公司开发的第三方软件可能会嵌入 IE 浏览器中。尽管我们在工作中会与这些第三方公司保持密切的交流，提供必要的指导帮助他们编写可以为用户带来良好 Web 体验的软件，但我们却无法保证他们编写的代码均能达到预期的高质量。

IE 浏览器同时要花费时间与可能存在于计算机中的所有杀毒软件、防火墙及其它安全防护软件打交道。有时这些时间的花费可能是重复的、并会引起 IE 浏览器出现不必要的响应缓慢。

★ 什么是浏览器加载项

加载项是指为浏览器添加扩展功能的特殊软件。提到加载项一般涉及插件、扩展组件、工具栏等，通常是由非微软的第三方厂商编写。有些加载项可以在浏览器中直观地看见、有些则以静默的方式运行于后台。我们不记实名的遥测数据显示，每位 IE 8 用户平均拥有五六个已安装的加载项。下面是一份 2009 年 7 月全球 IE 8 用户最常使用的二十个加载项列表（按照流行程度排序）：

1. 谷歌工具栏；
2. Windows Live 登录助手；
3. Adobe PDF Reader；
4. Windows Live 工具栏；
5. 雅虎工具栏；
6. JAVA 插件；
7. 迅雷下载管理器；
8. 金山浏览器保护盾；
9. AVG 安全防护工具栏；
10.Skype；
11.诺顿 NIS 安全防护；
12.麦克菲安全防护；
13.卡巴斯基 KIS 安全防护；
14.MSN 工具栏；
15.QQ 工具栏；
16.百度工具栏；
17.AskBar；
18.谷歌浏览器地址错误重定向；
19.Spybot Search & Destroy；
20.Adware.StickyPops。

尽管浏览器加载项可以为浏览器添加良好的新功能，但如果编写得不好也会带来影响性能的问题。绝大多数浏览器崩溃是由加载项引起的，IE 8 因加载项引起的崩溃占 70% 以上。由于加载项引起的 IE 8 响应缓慢也很常见，特别是在您打开新浏览器窗口或新选项卡时。

随着使用时间增加，浏览器会积累一些可能影响浏览器性能的加载项。已安装的加载项可能会在用户不知道他安装了什么样的加载项的情况下自动启用，这意味着很多用户都曾在无意识的情况下安装过很多不想要的或不需要的加载项。获得加载项通常有如下途径：

1. 在您购买品牌计算机前已经由品牌机厂商预装在计算机中；

2. 部分第三方软件可能包含有安装额外加载项的选项，有些用户并没有意识到这些软件的安装程序会为 IE 浏览器添加加载项，因为并非所有软件的安装程序都会给予用户明确的提示；

3. 您可能会有意识地从 Internet Explorer 8 Gallery 站点安装加载项，或者从加载项开发商的网站直接下载安装（例如：http://toobar.live.com、http://downloads.cnet.com）。

出于尊重您的隐私的考虑，IE 8 无法区分好意或恶意的加载项，也很难描述“原生”的浏览器问题与第三方加载项引起的问题有何区别。因此，您对于浏览器加载项的积极维护管理将是保证您获得您想要的 IE 8 性能体验的最佳途径。

★ 技巧 1：挑出行为异常的加载项并将其禁用

在 IE 8 中，您可以很容易地查看您的系统已安装的加载项并将那些不需要的加载项禁用。

1. 如何排查加载项引起的故障

以“不启动加载项”模式运行 IE 8 是一种很容易的测试加载项是否影响浏览器性能的方法。

第一步，在开始菜单的“运行”或“搜索栏”中输入 IEXPLORE.EXE -EXTOFF 并运行，IE 8 将会以不启用任何加载项的模式运行。您可以以这种模式访问您的站点测试是否有相同的问题发生。如果 IE 8 以“不启动加载项”模式运行的速度比平时快得多，您便需要打开“管理加载项”对话框禁用那些您用不到的加载项。

笔者注：除了以命令行方式运行 IEXPLORE -EXTOFF 命令外，我们还可以在 IE 8 地址栏中输入 about:NoAdd-ons，或者右键单击 Windows 7 超级任务栏中的 IE 图标、在跳转列表中继续右键单击 Internet Explorer，并在弹出的右键菜单中选择“以不启动加载项模式运行”，也可以令 IE 8 以“不启动加载项”模式运行。

第二步，当 IE 8 以“不启动加载项”模式运行之后，用鼠标点击地址栏下方的金色信息栏，在弹出的菜单中点击“管理加载项”，打开“管理加载项”对话框。

笔者注：“管理加载项”对话框同样可以在 IE 8 的“工具”工具栏或“工具”菜单中找到。

2. 禁用工具栏

在 IE 8 中禁用工具栏非常简单，只需点击工具栏旁边的“×”按钮即可。

IE 8 将提示您是否禁用此工具栏及任何与之相关的、出自同一开发商的加载项。例如，当您试图禁用 Contoso 开发的工具栏时，如果您还安装有同样出自 Contoso 的 Toolbar Helper 或 Support Library，IE 8 将询问您是否将这些相关的加载项一并禁用。

如果您点击“禁用”禁用了加载项，下一次运行 IE 8 时它将不会再自动加载，也不会再影响 IE 8 的响应。

笔者注：IE 8 的这一特性笔者曾经在去年写的博客《Windows Internet Explorer 8 在管理加载项与默认搜索引擎方面的改进》中有过介绍，欢迎参考。

3. 管理加载项

在 IE 8 中，您还可以检查载入每一个加载项需要花费多长时间，并禁用那些您不想要或不需要的加载项。

第一步，在 IE 8 的“工具”工具栏或“工具”菜单中打开“管理加载项”。

在“管理加载项”对话框中，您可以直观地看到加载项会令浏览器的启动时间增加多少秒。例如，Contoso Toolbar 及 Toolbar Helper 加载项在您每次打开新浏览器窗口或新选项卡时大约会使启动时间增加 1.42＋2.85 = 4.27 秒。

第二步，请确认您了解并信任那些已启动的加载项。请逐一检查每一个加载项的载入时间并确定那些比常规时间更长的加载项。

通过“管理加载项”对话框，我们可以很容易地启用或禁用任何加载项，以提高浏览器性能。

第三步，选中您希望禁用的加载项，点击“禁用”按钮。

修改的设置将在浏览器重新启动后生效（笔者注：指重新启动相应的 IEXPLORE.EXE 进程），被禁用的工具栏将不再出现。无论您何时感到浏览器响应速度变慢，都可以再打开“管理加载项”对话框进行排查。有时也许很难说什么时候会有一个软件在没有您许可的情况下被安装，但“管理加载项”始终是一个容易的检查方法。

IE 开发团队提供了下列文章供您参考：

http://blogs.msdn.com/ie/archive/2009/07/18/how-to-make-ie-open-new-tabs-faster.aspx
http://blogs.msdn.com/ieinternals/archive/2009/07/20/IE8-Performance-and-Speed-Tips.aspx

我们已经确认了一些与 IE 8 不兼容的加载项的已知案例：

http://go.microsoft.com/fwlink/?LinkId=110570

★ 技巧 2：检查计算机是否存在恶意软件或间谍软件

如果您发现 IE 8 运行异常、出现崩溃或自动访问了不希望的站点，可能是因为您的计算机受到了恶意软件（Malicious Software）的影响。您应该确保您安装有一款值得信赖的安全防护软件，可以随时帮助您检查计算机中是否存在病毒、木马及其它各类恶意软件。

下面是部分安全防护软件提供商的推荐信息，基于不同的 Windows 版本：

http://www.microsoft.com/windows/antivirus-partners/windows-7.aspx
http://www.microsoft.com/windows/antivirus-partners/windows-vista.aspx
http://www.microsoft.com/windows/antivirus-partners/windows-xp.aspx

★ 技巧 3：校验受限站点列表

如果 IE 8 的载入时间过长，可能是因为您的受限站点（Restricted Sites）或者可信站点（Trusted Sites）列表被添加了大量的网站。类似 SpyBot Search & Destroy 之类的安全防护软件可能会在上述列表中添加上千个网站，防止您访问不安全的站点。尽管这不是推荐的做法，但如果您使用了这些安全防护软件的免疫功能，您可以已经在不知不觉中应用了这些设置。

第一步，请依次点击“工具”－“Internet 选项”，切换至“安全”选项卡，单击选中“受限站点”图标并点击下方的“站点”按钮。

在您的“受限站点”对话框中共有多少个网站？如果超过了十个，您应该删除大多数网站。同时请检查您的安全防护软件并禁用任何可能会向“受限站点”列表添加网站的设置。

第二步，请在“受限站点”列表中选中希望删除的网站，然后点击“删除”按钮。

IE 8 本身提供有 SmartScreen 过滤器，这是一种浏览器内置的、设计用于保护您免受网络“钓鱼”攻击的安全特性。如果 SmartScreen 过滤器检测到恶意站点，IE 8 会将整个站点屏蔽。同时，它也提供了仅针对寄宿在正规站点上的恶意软件或“钓鱼”攻击的“外部屏蔽”，在不影响站点的前提下仅屏蔽恶意内容。

★ 技巧 4：确认您安装有加载项及软件的最近更新

将您的加载项及插件保持升级至最新是非常重要的。例如，众所周知早期版本的 Adobe Flash 可能会引起浏览器崩溃或停止运行。如果您安装有谷歌搜索或其它工具栏及扩展插件，请随时访问开发商的首页并确认您已升级至最新的版本。

另外请确保您运行的杀毒软件、反恶意软件工具及防火墙等均是最新的版本。同时请确保您的计算机安装有来自 Microsoft Update 的所有安全更新。

★ 技巧 5：重置 IE 8 默认设置

有时重置 IE 8 浏览器的设置可以降低遇到浏览器性能或稳定性故障的机率。您可以参考这篇微软 KB 知识库文章、并获取自动重置 IE 8 默认设置的 Fix it 工具：

http://support.microsoft.com/kb/923737
http://go.microsoft.com/?linkid=9646978

此工具可以禁用工具栏与加载项、重置默认浏览器设置、重置个人隐私设置、重置安全设置、重置 Internet 高级选项、重置选项卡设置、重置弹出窗口阻止程序设置。

笔者注：IE 8 本身就有重置浏览器默认设置的功能。您可以在“Internet 选项”中切换至“高级”选项卡，在“重置 Internet Explorer 设置”框中点击“重置”按钮。Fix it 并不是重置 IE 8 默认设置必须的工具。

★ 技巧 6：联机求助于微软帮助支持

如果您在尝试了上述技巧之后依然感到 IE 8 未达到最理想的运行状态，请尝试联机访问微软帮助支持中心，按照向导的提示排查您的浏览器故障：

http://support.microsoft.com/gp/pc_ie_intro

进阶部分：提高 Windows Internet Explorer 8 性能的高级设置技巧

纵观来自用户的反馈与错误报告，我们已经可以确定某些计算机设置可能会引起浏览器响应缓慢。调整这些设置可以帮助优化浏览器性能。这些设置大都需要涉及浏览器与注册表的进阶知识。不久以后，我们将提供可以帮助您轻松调整这些设置的自动化资源。

★ 技巧 1：检查您的 User Agent 字符串长度

1. 什么是 User Agent 字符串

每种浏览器都拥有一个 User Agent 字符串。这个字符串被您访问的网站自动读取，确定您的浏览器类型、操作系统类型及某些其它关于计算机的技术资源信息（笔者注：包括关于 .net Framework、Media Center、Tablet PC 及某些第三方软件的信息）。部分网站有时会根据这些字符串提供的信息决定在您的浏览器中显示何种内容。例如，假设您使用 Windows 计算机访问一个这样的站点，它可能就会自动提供 Windows 版本的软件供您下载。有时在您安装了非微软的第三方软件，例如路由器、摄像头、声卡驱动，或者访问了非微软提供的站点之后，您的 User Agent 字符串将被附加额外的信息。

关于 User Agent 字符串的更多信息可以参考：

http://msdn.microsoft.com/en-us/library/ms537503(VS.85).aspx

2. 如果我的 User Agent 字符串过长会出现什么问题

如果 User Agent 字符串过长，试图读取它的网站可能拒绝您的浏览器获取站点内容的请求。由于请求信息会在网站与您的浏览器之间不停地往返并陷入循环，这可能会引起不必要的浏览器响应缓慢。

笔者注：通常 User Agent 字符串的长度不应超过 200 个字符，否则 IE 8 便会很容易出现无法获取请求的内容、浏览器被屏蔽、返还空白页面、显示错误信息等各类故障。

我们可以在浏览器地址栏中输入：

BLOCKED SCRIPTalert(navigator.userAgent)

然后运行，查看当前的 User Agent 字符串。如果 User Agent 字符串过长，可以打开注册表编辑器，在如下注册表项中删除不需要的附加信息：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent

另外，User Agent 字符串中的信息排列顺序也是有讲究的。因为附加信息过多、导致排列顺序有误而引起的网站功能故障也很常见。笔者在 2008 年曾写过一篇博客《Windows Update 为什么将 Windows 识别为 Macintosh》，讨论的问题便是由 User Agent 字符串引起，欢迎参考。

★ 技巧 2：增大 IE 8 的连接限制数优化 IE 的并行下载

IE 8 浏览器允许与每台服务器同时建立最多六个连接以刷新显示信息，这意味着当您同时下载多个文件时，您可以从每台服务器获得最多六个文件的并行下载。有时增大 IE 8 的每服务器连接限制数可以增强浏览器的下载及浏览性能。

有关如何增加 IE 8 的连接限制数，请访问：

http://support.microsoft.com/kb/282402/zh-cn

笔者注：我们可以将 IE 8 的连接限制数增大为十。从 KB282402 知识库文章页面中获取自动的 Fix it 工具，或者参照 KB282402 介绍的方法手动修改组策略或注册表。

两则为数据访问设置合适权限的典型问题

alx-zj — Sun, 28 Mar 2010 08:50:00 GMT

（注：本文被 Microsoft TechNet 中文速递邮件 2010 年第 06 期收录为 MVP 推荐 Blog）

笔者最近于微软新闻组见到两则数据访问权限的问题，具有一定代表性，在此小结供大家参考。

★ 在工作组环境中试图访问其它计算机的共享文件夹，遇到“拒绝访问”的错误提示、或者遇到要求输入用户名密码进行登录的对话框（3 月 20 日见于微软新闻组）：

这是一个老生常谈的问题了，大家可能都知道诸如“取消 Guest 来宾帐户的禁用”、“将计算机设置为同一工作组名”、“关闭防火墙”之类的解决方法，的确如此。然而，有一个容易被疏忽的设置就是共享文件夹的本地 NTFS 权限，如果共享文件夹位于 NTFS 分区，那么网络访问权限与本地 NTFS 权限这两个权限必须全部放行才可以顺利访问共享文件夹。具体如下：

1. 网络访问权限

当我们试图访问工作组中的共享文件夹时，可以选择 Guest 来宾帐户进行登录、或者选择一个位于目标计算机的本地帐户进行登录，其中 Guest 来宾是 Windows 推荐的方式。如果我们选择前者，需要检查目标计算机的 Guest 来宾帐户是否已取消禁用，是否额外设置有密码；如果选择后者，Windows 就会要求我们输入密码登录此帐户，用户名应为“目标计算机\帐户名”。

有时当目标计算机的 Guest 来宾帐户不可用时（例如 Guest 被额外设置了密码），弹出的网络登录对话框可能会出现“用户名”一栏显示为“目标计算机\Guest”，但“用户名”为灰色不可更改的状态，此时我们无法选择其它帐户登录。解决这一问题可以在目标计算机打开组策略编辑器，依次展开“计算机配置”－“Windows 设置”－“安全设置”－“本地策略”－“安全选项”，将“网络访问：本地帐户的共享安全模式”由“仅来宾－本地用户以来宾身份验证”修改为“经典－本地用户认证”，这样即可在登录对话框中选择除 Guest 来宾外的其它帐户进行网络登录。

2. 本地 NTFS 权限

如果网络访问权限设置一切正常（计算机属于同一工作组、Guest 来宾没有被禁用且没有设置密码、防火墙也放行），但访问共享文件夹时依然提示“拒绝访问”，这时可能就是共享文件夹的本地 NTFS 权限进行了限制。假如我们是以 Guest 来宾帐户进行登录的，应该确保 Everyone 对共享文件夹拥有至少“读取”的权限、同时没有针对 Guest 来宾进行额外的“拒绝”设置，这样 Guest 来宾才能顺利访问共享文件夹；假如我们是以目标计算机的一个本地帐户登录的，同样需要我们在目标计算机中检查此帐户是否具有访问共享文件夹的 NTFS 权限。

★ 针对使用 NTFS 文件系统的可移动式存储器（例如移动硬盘、闪存盘），用户希望实现：

1. 只有我的电脑的管理员权限可以完全控制数据，包括读取，运行，删除，写入，修改；
2. 我的电脑的受限用户只能读取运行，不能删除或修改原有数据，但可以写入新数据；
3. 任何来自其它计算机的用户，不论是管理员还是非管理员，只能读取，不能删除写入。

（3 月 7 日见于微软新闻组）

如果可移动式存储器使用 NTFS 文件系统，我们可以设置本地 NTFS 权限实现目的 1、2。设置权限应该注意，在默认的 NTFS 权限设置中，“拒绝”权限优先于“允许”权限。因此，我们应该首先将 Everyone 设置为“允许”，再针对具体希望进行限制的用户设置“拒绝”；而不应先将 Everyone 设置为“拒绝”，再针对具体用户设置“允许”。

微软新闻组的那位用户就犯了这样的错误，为了实现“只有他的管理员可以完全控制”的目的 1，这位用户首先将 Everyone 设置为了“拒绝”，然后才设置本地 Administrators 为“允许”，结果发现连本地的管理员帐户也无权访问了。这是因为 Administrators 也是隶属于 Everyone 的，由于 Everyone 已经定义了“拒绝”，优先于 Administrators 的“允许”，所以 Administrators 的“允许”便等同于虚设了。

具体到这位用户的问题，他只要将 Everyone 的“拒绝”取消，将 Administrators 的“完全控制”设置为“允许”，然后取消其它帐户的“完全控制”，只赋予他们“读取”、“写入”、“读取与运行”、“列出文件夹目录”的权限，即可实现目的 1、2。

至于这位用户提到的目的 3，仅通过 NTFS 权限无法实现只在某台特定的计算机中完全控制、而在其它计算机中只能读取。因为当移动存储器连接至其它计算机后便成为了那台计算机的设备，该机管理员只需更改一下数据的“所有者”即可重新获取并重新定义移动存储器数据的权限。我们通过 NTFS 权限设置无法阻止该机管理员更改数据“所有者”。

因此，假如我们不希望移动存储器连接至其它计算机时丢失数据，还是应该对数据进行 EFS 加密，并在借出移动存储器之前做好数据备份。这样，即使其它计算机的管理员可以更改移动存储器中的数据“所有者”，他也只能删除数据，而无法在没有密钥的情况下解密并读取数据。

轻松将 Windows 7 单一零售版安装光盘改造为多合一版

alx-zj — Sun, 28 Feb 2010 08:20:00 GMT

NT 6 操作系统（Windows 7/Vista/Server 2008）安装程序采用的 Windows Imaging（WIM）技术允许我们将若干种不同的镜像保存为同一个 .WIM 镜像文件。基于这一特性，NT 6 相比早期版本的 Windows 更适合、更方便制作多合一版的安装光盘。

以 Windows 7 为例，我们对比一下微软官方发布的各种零售版 Windows 7 安装源，可以发现，只要 Windows 7 同属 x86 或者同属 x64，那么无论是旗舰版、专业版还是家庭版，每种版本的安装源大小都是一样的。x86 安装源都是 2484MB、x64 安装源都是 3186MB，这是因为每种版本的安装源实际都包含有其它全部版本的镜像。我们可以使用 IMAGEX /INFO 命令查看 Windows 7 安装源中的 SOURCES\INSTALL.WIM，无论我们打开的 INSTALL.WIM 来自何种版本，x86 的 INSTALL.WIM 均包含编号为 1－5 的五个镜像，分别是 Starter、Home Basic、Home Premium、Professional、Ultimate；x64 的 INSTALL.WIM 均包含编号为 1－4 的四个镜像，分别是 Home Basic、Home Premium、Professional、Ultimate（x64 没有 Starter 版）。

然而，尽管 INSTALL.WIM 包含所有版本的镜像，Windows 7 零售版默认却只允许我们安装其中的一种，即零售版包装盒上标示的那个版本，不允许我们安装其它的版本，这一点与 Windows Vista 有所不同。Windows Vista 在安装时首先会提示我们输入 Product Key，然后根据 Key 自动判断版本类型；如果我们不输入 Key，则可以在随后出现的 Windows Vista 版本列表中任选一种。换句话说，Windows Vista“天生”就是多合一版，各种版本售价高低不同的区别只体现在 Key 上，安装光盘是 100% 相同的，它既可以接受我们输入的任一版本的 Key、也可以允许我们在列表中任选一种版本，只要我们拥有相应 Key，就可以完成激活。Windows 7 零售版默认则不具备这样的特性，微软有意屏蔽了 Windows 7 的版本选择列表、也不接受其它版本的 Key，因此我们不能直接在 Windows 7 中实现诸如用家庭版安装光盘安装旗舰版这种事情。

存在这道限制的关键在于 Windows 7 安装源中多了 SOURCES\EI.CFG 这样一个配置文件，不同版本的 Windows 7 拥有不同的 EI.CFG。如果说 Windows Vista 不同版本的安装源 100% 相同，那么 Windows 7 就是 99% 相同，唯一的差别就在 EI.CFG 上。EI.CFG 定义了 Windows 7 安装源的版本信息，安装程序可以自动读取 EI.CFG 并判断用户购买的是什么版本，然后将其它版本的选择列表屏蔽。以 Windows 7 Ultimate 零售版为例，它的 EI.CFG 内容为：

[EditionID]
Ultimate
[Channel]
Retail
[VL]
0

即表明当前安装源是 Ultimate 旗舰版、Retail 零售版、非 VL 版。

如需将单一零售版的 Windows 7 安装源改造为多合一版，只要将 EI.CFG 从 SOURCES 中删除就可以了，这样即可在 Windows 7 安装程序中重新看到版本选择列表。

下面笔者举一个制作 Windows 7 多合一版安装源的具体实例。假设笔者从 MSDN 官网下载了 x86、x64 两套 Windows 7 零售版安装光盘 ISO 镜像（无论什么版本），希望将它们合并，制作为同时包含 x86 Starter、x86 Home Basic、x86 Home Premium、x86 Professional、x86 Ultimate、x64 Home Basic、x64 Home Premium、x64 Professional、x64 Ultimate 的多合一 ISO，可以按照下列步骤进行：

1.以 UltraISO（或者其它支持 .ISO 镜像的虚拟光驱类工具）分别打开 x86、x64 两套安装光盘 ISO 镜像，将它们的 SOURCES\INSTALL.WIM 分别另存至本地。为了叙述方便，在此假设另存后分别命名为 x86.WIM、x64.WIM。

2.执行 IMAGEX /EXPORT x86.WIM 5 INSTALL.WIM 命令（如果需要指定文件的路径，可以自行添加），将 x86.WIM 中的第五个镜像，也就是 x86 Ultimate 提取出来，另存为 INSTALL.WIM；

3.现在新生成的 INSTALL.WIM 只有 x86 Ultimate 一个镜像，继续执行下列命令，将其它版本陆续添加至新 INSTALL.WIM：

IMAGEX /EXPORT x64.WIM 4 INSTALL.WIM "Windows 7 Ultimate"

（为 INSTALL.WIM 添加 x64 Ultimate）

IMAGEX /EXPORT x86.WIM 4 INSTALL.WIM "Windows 7 Professional"

（为 INSTALL.WIM 添加 x86 Professional）

IMAGEX /EXPORT x64.WIM 3 INSTALL.WIM "Windows 7 Professional"

（为 INSTALL.WIM 添加 x64 Professional）

IMAGEX /EXPORT x86.WIM 3 INSTALL.WIM "Windows 7 Home Premium"

（为 INSTALL.WIM 添加 x86 Home Premium）

IMAGEX /EXPORT x64.WIM 2 INSTALL.WIM "Windows 7 Home Premium"

（为 INSTALL.WIM 添加 x64 Home Premium）

IMAGEX /EXPORT x86.WIM 2 INSTALL.WIM "Windows 7 Home Basic"

（为 INSTALL.WIM 添加 x86 Home Basic）

IMAGEX /EXPORT x64.WIM 1 INSTALL.WIM "Windows 7 Home Basic"

（为 INSTALL.WIM 添加 x64 Home Basic）

IMAGEX /EXPORT x86.WIM 1 INSTALL.WIM "Windows 7 Starter"

（为 INSTALL.WIM 添加 x86 Starter）

这样 INSTALL.WIM 就将拥有所有版本的镜像，并将在安装程序中按照如图所示的顺序排列（如果希望调整列表顺序，可以调整执行命令的顺序）：

4.接下来以原版 x86 安装光盘 ISO 镜像为基础，将其修改为多合一 ISO，以 UltraISO（或其它工具）打开原版 x86 ISO，用上一步制作的新 INSTALL.WIM 替换 SOURCES\INSTALL.WIM 原文件（新的 INSTALL.WIM 大小为 4GB 左右，未超过 DVD 5 容量上限）；

5.最后删除 SOURCES\EI.CFG 并保存 ISO。

至此，Windows 7 多合一版制作完毕。我们可以通过虚拟机进行测试，没有问题即可重新刻录为光盘。

不知大家是否还记得笔者去年 DIY 的“Windows XP 四合一最终收藏版”？现在笔者已经有三套这样的 Windows 收藏版了，分别是 Windows XP with SP3 四合一、以及按照本文方法制作的 Windows Vista with SP2 九合一、Windows 7 RTM 九合一，均采用笔者自行设计制作的光盘盒及光盘封面，如图所示。

选择光盘盒的时候，笔者经过比较还是选择了 Windows Vista 光盘盒，因为笔者觉得 Windows 7 零售版光盘盒实在不如 Windows Vista 的光盘盒美观，其比较传统的“翻书型”打开方式也不如 Windows Vista 光盘盒“侧拉抽屉型”来得新潮。仅从光盘盒一点说，Windows 7 未免有些退步。因此，笔者的三套 Windows 收藏版光盘盒及其图案依然基于 Windows Vista 光盘盒制作。

易宝典 KB －Windows 7 超级任务栏与传统任务栏解析

alx-zj — Thu, 07 Jan 2010 05:20:00 GMT

《易宝典》是微软知识库（Microsoft Knowledge Base）推出的 KB 入门版，主要面向非 IT 专业人士的广大普通用户，协助用户解决日常应用中遇到的常见问题，其中很多问题收录自微软中文新闻组或微软中文技术论坛，具有较高的代表性、普遍性、实用性。

易宝典 KB 首页：

http://support.microsoft.com/gp/howtocenter/zh-cn

本次笔者参与撰写的易宝典《KB979283 －Windows 7 超级任务栏与传统任务栏解析》采用了对比的方式介绍 Windows 7 独特的超级任务栏与早期版本 Windows 的传统任务栏之间的区别，帮助第一次使用 Windows 7 的用户熟悉超级任务栏。此外还介绍了如何将 Windows 7 超级任务栏调整为接近早期版本 Windows 传统任务栏的样式，方便不习惯 Windows 7 超级任务栏的用户使用。

http://support.microsoft.com/kb/979283/zh-cn

欢迎大家对此话题展开讨论，请在本篇博文后发表您对易宝典 KB979283 的评论。

微软硬件八大系列产品与 Windows 7 兼容性解析

alx-zj — Mon, 04 Jan 2010 08:50:00 GMT

做为微软中文技术论坛的硬件组版主及键鼠外设发烧友（参见本人收藏品），笔者对微软硬件产品一直保持着持续关注。Windows 7 发布以来，很多用户都在询问现有的微软硬件产品与 Windows 7 兼容性如何、能否在 Windows 7 中正常使用，笔者在此进行一次总结。

由于 Windows 7 发布于 2009 年 10 月 22 日、普及时间尚短，所以绝大多数微软硬件产品只具有 Designed for Windows XP 或 Certified for Windows Vista 标志。目前，仅 2009 年下半年发布的少量新品具有 Compatible with Windows 7 标志，例如 Wireless Mobile Mouse 3500。再有就是少量改头换面的旧版产品，例如 IE 3 复刻版，部分生产日期较近的 IE 3 复刻版，已经将原来的 Certified for Windows Vista 标志改换为 Compatible with Windows 7。

尽管可见的 Compatible with Windows 7 标志不多，但由于微软硬件各系列产品均已及时发布了 Windows 7 驱动程序，而且很多功能简单的产品无需驱动即可直接使用，所以微软硬件产品与 Windows 7 的兼容性总体还是不错的。下面笔者按照鼠标、键盘、摄像头、耳麦、游戏控制器、简报演示器、媒体中心遥控器、指纹识别设备八条主要产品线分述如下：

★ 鼠标

微软鼠标驱动程序 Microsoft IntelliPoint（以下简称 IP 驱动）采用公版设计，
最新版本 7.1 for Windows 7 中文版（x86/x64）可以从微软硬件官方网站获取：

http://download.microsoft.com/download/0/5/D/05D4AB1D-2B51-459D-8744-6FDF8E5896B2/IPx86_2052_7.10.344.0.exe

http://download.microsoft.com/download/8/5/0/850D899C-3B10-4F6A-8A4F-78F41E6FC913/IPx64_2052_7.10.344.0.exe

与 IP 7.1 for Windows XP 相比，IP 7.1 for Windows 7 支持的微软鼠标类型没有明显的变化，仅取消了对无线指纹鲨（Wireless IntelliMouse Explorer with Fingerprint Reader）的支持。这主要是由于 Windows 7 不再提供指纹识别类设备的驱动，但无线指纹鲨的鼠标功能不受影响，我们可以在 IP 7.1 驱动中将其设置为最接近的型号 Wireless IntelliMouse Explorer 2.0。

还有一个例外就是 Microsoft Habu，众所周知这是微软与雷蛇（Razer）合作发布的产品，但它基本只是 Razer 的鼠标挂上微软的名牌而已。笔者认为 Habu 仅有两分微软血统、有八分 Razer 血统，其驱动程序也不包含于历代 IP 公版驱动中，而是由 RazerZone 单独提供：

http://www.razersupport.com/index.php?_m=downloads&_a=view&parentcategoryid=7&pcid=0&nav=0

★ 键盘

微软键盘驱动程序 Microsoft IntelliType（以下简称 IT 驱动）采用公版设计，

最新版本 7.1 for Windows 7 中文版（x86/x64）可以从微软硬件官方网站获取：

http://download.microsoft.com/download/1/5/5/155250BA-4C64-4FC8-9BC3-6D7230CA3F75/ITPx86_2052_7.10.344.0.exe

http://download.microsoft.com/download/6/F/3/6F392512-E584-429E-89F2-F9D48319BCD3/ITPx64_2052_7.10.344.0.exe

与 IT 7.1 for Windows XP 相比，IT 7.1 for Windows 7 也仅取消了对指纹识别套装键盘（Keyboard with Fingerprint Reader）的支持，与无线指纹鲨类似，但键盘功能不受影响，我们可以在 IT 7.1 驱动中将其设置为最接近的型号 Digital Media Pro Keyboard。

另外还有与 Microsoft Habu 类似的 Microsoft Reclusa，笔者认为 Reclusa 大概有三分微软血统、七分 Razer 血统，比 Habu 的微软味道略浓一些，其线缆收藏槽及脚拖的设计比较接近于传统微软键盘。Reclusa 的驱动程序也不包含于历代 IT 公版驱动中，而是由 RazerZone 单独提供：

http://www.razersupport.com/index.php?_m=downloads&_a=view&parentcategoryid=16&pcid=0&nav=0

★ 摄像头

微软摄像头驱动程序 Microsoft LifeCam（以下简称 LM 驱动）采用公版设计，

最新版本 3.0 for Windows 7 中文版（x86 and x64）可以从微软硬件官方网站获取：

http://download.microsoft.com/download/6/6/6/6663B667-3D5E-4637-A615-80EC6BA1E4AC/LifeCam3.0.exe

LM 3.0 for Windows 7 可以支持已发行的全部微软摄像头产品，包括 LifeCam HD Cinema、Show、VX-700/800/1000/2000/3000/5000/5500/6000/7000、NX-3000/6000。

★ 耳麦

微软耳麦驱动程序 Microsoft LifeChat（以下简称 LT 驱动）采用公版设计，

最新版本 1.4 for Windows 7 中文版（x86 and x64）可以从微软硬件官方网站获取：

http://download.microsoft.com/download/F/7/0/F70FBF72-2AAB-4D60-9E49-7B015E8E5851/LifeChat1_4.exe

LT 1.4 for Windows 7 可以支持已发行的全部微软耳麦产品，包括无线耳麦 LifeChat ZX-6000 及有线耳麦 LX 1000/2000/3000。

★ 游戏控制器

微软游戏控制器产品目前主要包括游戏鼠标（SideWinder 07'/X8/X5/X3、Habu、IntelliMouse Explorer、IntelliMouse Optical、Laser Mouse 6000）、游戏键盘（SideWinder X6、Reclusa）、游戏手柄（XBOX 360 Controller for Windows）。其中，游戏鼠标除 Habu 外，其余型号均包含于 IP 7.1 驱动；游戏键盘除 Reclusa 外，SideWinder X6 亦包含于 IT 7.1 驱动。

XBOX 360 Controller 手柄驱动程序是 XBOX 360 Accessories Software，可支持有线或无线版手柄，

最新版本 1.2 for Windows 7 中文版（x86/x64）可以从微软硬件官方网站获取：

http://download.microsoft.com/download/6/9/4/69446ACF-E625-4CCF-8F56-58B589934CD3/Xbox360_32Chs.exe

http://download.microsoft.com/download/6/9/4/69446ACF-E625-4CCF-8F56-58B589934CD3/Xbox360_64Chs.exe

★ 简报演示器

微软简报演示器产品只有无线激光简报鲨 8000（Wireless Notebook Presenter Mouse 8000）及简报演示器 3000（Presenter 3000）。前者做为半鼠标半演示器产品，包含于 IP 7.1 驱动；而后者目前已经停产，不过它采用的是免驱动式设计，只要顺利建立 2.4GHz 无线连接，无需安装任何驱动即可在 Windows 7 中使用。

★ 媒体中心遥控器

微软媒体中心遥控器产品包括千元售价的无线桌面娱乐套装 7000/8000（Wireless Entertainment Desktop 7000/8000），以及两款已经停产的媒体中心遥控器（Remote Controller and Receiver for Windows XP Media Center Edition）与遥控键盘（Remote Keyboard for Windows XP Media Center Edition）。

无线桌面娱乐套装 7000/8000 做为半键鼠套装半遥控器产品，其鼠标键盘分别包含于 IP 7.0 与 IT 7.1 驱动；而两款已停产的媒体中心产品原本是为 Windows XP Media Center Edition 设计的，它们也都是免驱动式设计，只要拥有合适的红外接收器并建立无线连接，无需安装任何驱动即可配合 Windows 7 的媒体中心使用。

★ 指纹识别设备

微软指纹识别设备产品包括单独的指纹识别器（Microsoft Fingerprint Reader）、无线指纹鲨（Wireless IntelliMouse Explorer with Fingerprint Reader）、指纹识别套装（Wireless Optical Desktop with Fingerprint Reader）。它们目前均已停产且不受微软支持，因此在八大产品线中，指纹识别设备与 Windows 7 的兼容问题最严重。

微软指纹识别设备与其配套的驱动程序及指纹管理软件 DigitalPersona Password Manager 是由 DigitalPersona,Inc. 与微软合作开发的产品，其销售方式类似于 Habu 与 Reclusa。由于微软已停止对指纹识别产品的支持，所以我们在微软硬件官方网站只能找到适用于 Windows XP/Vista 的 DigitalPersona Password Manager 2.0：

http://download.microsoft.com/download/7/7/8/7783219a-371f-4b2d-b7e0-02616b12bc68/DPPM_201_CHS.exe

但遗憾的是此软件与 Windows 7 存在兼容问题，主要包括：

1.此软件只有 32 位版本，不支持 64 位系统；

2.驱动程序可能会导致指纹识别器响应迟缓，例如按下手指后不扫描指纹，或者扫描灯持续闪烁等；

3.无法正常导入在 Windows XP/Vista 中导出的指纹数据；

4.如果在 Windows 7 中直接安装此软件，只能以指纹识别方式登录 Windows 用户帐户，但在登录 Web 页或应用程序时，可能无法准确识别用户名与密码的位置。但是假如把已安装有 DigitalPersona Password Manager 的 Windows Vista 升级为 Windows 7，则不会有问题。

为了变通解决这些兼容问题，Windows 7 用户可以按照下列步骤配置指纹识别设备及 DigitalPersona Password Manager：

1.可以从 DigitalPersona,Inc. 网站下载版本更高的 DigitalPersona Password Manager 2.0.1 并安装于 Windows XP/Vista（如果之前正在 Windows XP/Vista 中使用指纹识别设备，这一步可以省略）；

2.在 Windows XP/Vista 中使用 DigitalPersona Password Manager 的向导将现有的指纹数据导出；

3.在 Windows 7 中安装 DigitalPersona Password Manager；

4.进入 DigitalPersona Password Manager 的 Bin 文件夹，将下述七个主要程序文件设置为以管理员权限运行、并设置为以 Windows Vista 兼容模式运行：

DPAgnt.EXE、DPConsol.EXE、DPExpImp.EXE、DPFpLogonManager.EXE、

DPHost.EXE、DPRunDLL.EXE、DPWinLct.EXE；

5.重新启动 Windows 7，然后重新注册用户指纹；

6.使用 DigitalPersona Password Manager 的向导导入之前备份的用户指纹数据。

这样即可在 Windows 7 中解决上述兼容问题，使用微软指纹识别设备登录 Windows 或登录 Web 页及应用程序。

易宝典 KB －如何根据自己的实际需求设置 Windows 7 电源方案

alx-zj — Sat, 26 Dec 2009 17:20:00 GMT

易宝典 KB 首页：

http://support.microsoft.com/gp/howtocenter/zh-cn

本次笔者参与撰写的易宝典《KB979007 －如何根据自己的实际需求设置 Windows 7 电源方案》介绍了 Windows 7 电源按钮设置选项的分类与用途，为初级用户介绍关机、休眠、睡眠等选项的用途，方便用户根据自己的实际情况选择相应电源选项。

http://support.microsoft.com/kb/979007/zh-cn

欢迎大家对此话题展开讨论，请在本篇博文后发表您对易宝典 KB979007 的评论。

个人经验浅谈 Windows Mobile 用户数据的备份与恢复

alx-zj — Thu, 10 Dec 2009 14:20:00 GMT

无论在 PC 计算机还是 PPC 智能手机（以后叫做 Windows Phone）领域，用户个人数据的备份与恢复都是不容忽视的问题。“设备有价、数据无价”，如果不希望丢失数据后郁闷地撞墙，我们一定要事先备份。

说起来，手机在操作系统崩溃以后的数据恢复，难度比计算机更大。假设一台计算机 Windows 系统崩溃，我们至少可以：

1.在不影响其它数据的前提下修复 Windows 安装；

2.使用其它可引导设备及操作系统（例如 Windows PE 闪存盘）启动计算机并恢复数据；

3.将硬盘拆下连接至其它计算机恢复数据。

但是 Windows Mobile 手机系统一旦崩溃无法启动，我们却：

1.不能“修复安装”Windows Mobile 系统（只能重新刷机）；

2.不能使用其它可引导设备及操作系统访问手机（双系统手机？概念产品而已）；

3.不能将手机内存拆下连接至其它手机（指手机机身内存、存储卡除外）。

此时，除了硬启（Device Reset，即恢复出厂设置，相当于用相同版本的 ROM 重新刷机）之外，已经没有别的办法令手机起死回生，而一旦硬启，保存于机身内存中的数据就必然无法挽回。

因此，PPC 手机的数据需要在 Windows Mobile 系统崩溃之前预先备份。而且，应该尽可能将数据保存于存储卡、而不是机身内存。因为一旦发生问题，存储卡毕竟可以从手机中拆下并被其它设备读取。

下面笔者简单谈一下自己在 Windows Mobile 用户数据备份与恢复方面的经验。个人采用的技巧，不一定是最简单高效的，如果哪位朋友有更好的方法，欢迎评论赐教。另外，诸如文档、图片、音乐、视频等寻常格式的数据，它们的备份恢复对于手机而言基本没有区别，最简单的复制粘贴备份即可。笔者主要谈论的是 Windows Mobile 手机的通话记录、短信、日历等个人数据的恢复。

★ 通话记录

手机通话记录在 Windows Mobile 系统执行了硬启或刷机后必然无法挽回。如果没有事前备份，我们就将永远失去通话记录。不过，假如我们自己记得某年某月某日某时曾经与某人通话多长时间，倒是可以使用《智能手机工作室》这款工具软件重新制作一份通话记录。此软件可以通过各大搜索引擎找到。

在 PC 端安装好《智能手机工作室》及 Microsoft ActiveSync（或 Windows Mobile Device Center），以 USB 数据线将手机与 PC 连接，待 ActiveSync 显示“已连接”后，即可在《智能手机工作室》的“通话记录”菜单中找到手机中已有的通话记录。此时我们在《智能手机工作室》的“文件”主菜单点击“备份”或者“恢复”，即可将手机中的通话记录备份为 .XML 文件，或者将已有的 .XML 文件恢复至手机。

那么如何重新制作一份已经丢失的通话记录呢？举个例子，假设笔者（130****2065）因为手机硬启丢失了通话记录，查询中国联通通话详单，发现笔者在 2009 年 2 月 19 日曾接到 Asuka（139****9807）打来的电话，聊了 1 分 35 秒，现在笔者想将这条已丢失的通话记录恢复至手机。

首先，笔者随便拨打或接听几个电话，使通话记录不要为空；其次，笔者将手机连接至 PC，通过《智能手机工作室》将现有通话记录备份为 .XML 文件；接下来，笔者再用任意文本编辑器打开这个 .XML 文件，以 <calllogs> 为关键字进行搜索，可以在找到的 <calllogs> 下看到若干个由 <item> 与 </item> 括起来的子标签，每一组 <item> 与 </item> 均代表一则通话记录。

为了重新制作与 Asuka 的通话记录，笔者选中任意一组 <item> 与 </item> 并复制粘贴，一个新通话记录就诞生了，接下来只需再修改一下这则通话记录的有关数据。按照中国联通通话详单提供的情况，笔者自己输入了这样一组数据：

<item>
<starttime>2009-02-19 17:07:47</starttime>
<endtime>2009-02-19 17:09:22</endtime>
<outgoing>0</outgoing>
<connected>1</connected>
<ended>1</ended>
<roam>0</roam>
<number>"Asuka" <139****9807></number>
<nametype>移动电话</nametype>
</item>

顾名思义：

<starttime> 与 <endtime> 表示电话的起止时间，从 2009 年 2 月 19 日的 17:07:47 至 17:09:22，通话 1 分 35 秒；

<outgoing> 设置为 0 表示我接到 Asuka 打来的电话，如果是 1 则表示我打给 Asuka；

<connected> 设置为 1 表示电话顺利接通，如果是 0 则通话记录将显示为“未接来电”；

<ended> 设置为 1 表示电话由我首先挂断，如果是 1 则表示 Asuka 首先挂断；

<roam> 设置为 0 表示电话不属于漫游，如果是 1 则表示漫游；

<number> 表示 Asuka 的显示名及其电话号码，假如 Asuka 没有被我加入通讯簿，也可以只输入号码、不输入名字，这样将显示为陌生人来电；

<nametype> 表示 Asuka 的电话类型，因为在 Windows Mobile 通讯簿中一个人可以被设置多种类型的号码，例如移动电话、住宅电话、工作电话等，假如 Asuka 没有被加入通讯簿，可以不设置 <nametype>。

这样，我与 Asuka 的通话记录就重新制作好了，通过《智能手机工作室》将新的 .XML 文件还原至手机，即可恢复 2009 年 2 月 19 日 17:07:47 至 17:09:22 接到 Asuka 来电的通话记录。

八卦一句，以这种方法制作的通话记录与拨打电话留下的通话记录完全相同，表面上看不出破绽，因此不要拿来干坏事。例如在手机中伪造与老板的通话记录、然后骗老婆说要加班等。^_^

★ 短信

手机短信在 Windows Mobile 系统中被保存于机身内存根目录的 \我的设备\cemail 文件，平时我们可以在资源管理器中直接将 cemail 文件复制至存储卡备份。

cemail 的存储方式与 Outlook Express（简称 OE）的 .DBX 文件格式比较像，它会把“收件箱”“已发送邮件”“已删除邮件”中所有的短信都保存在一起。我们知道，OE 一旦使用得久了，随着接收邮件增多，相应的 .DBX 文件越变越大，访问速度也会越来越慢，直到 .DBX 文件超过 2GB，OE 就会丢失邮件。Windows Mobile 系统也存在着类似的隐患，如果存储的短信太多，cemail 文件不断变大，访问速度也将越来越慢，直到把 cemail 文件“撑死”为止。因此，我们最好不要在 Windows Mobile 手机中存储过多的短信（100 条以上）。

与通话记录一样，短信也可以通过《智能手机工作室》以 .XML 格式备份还原，也可以手动编辑 .XML 文件重新制作已丢失的短信，在此就不赘述了。笔者只简单说一下短信的 .XML 文件格式的特点。

使用《智能手机工作室》备份短信时，最好将“收件箱”“已发送邮件”等分开保存为不同的 .XML 文件，免得堆在一起容易混乱。以文本编辑器打开相应的 .XML 文件，可以在文件标头处搜索到 <smss folderid="0" name="收件箱"> 或 <smss folderid="2" name="已发送邮件"> 等标识信息，可说明这是位于信息管理器第几行的哪个邮件文件夹。

与通话记录类似，短信的 .XML 文件也由一组 <item> 与 </item> 代表一条短信。不过由于每条短信都有一则唯一的 <msgid>，所以在自行编辑前最好先在手机中建立好相应条目的空白短信，由系统自动为每条短信生成<msgid>，我们只需修改数据就行了。

例如，假设笔者首先在手机“收件箱”中建立好足够数量的空白短信，然后备份为 .XML 文件。接下来再将任一组空白短信的 <item> 与 </item> 修改为如下数据：

<item>
  <folderid>0</folderid>
  <sender>"Asuka" <139****9807></sender>
<receiver>130****2065</receiver>
<msgClass>IPM.SMStext</msgClass>
<subject>热烈祝贺北京国安夺冠。</subject>
<body/>
<delivertime>2009-10-31 16:50:18</delivertime>
<lastmodifytime>2009-10-31 16:51:10</lastmodifytime>
  <msgid>00000000E7000034020000000000000004000000</msgid>
</item>

一条 Asuka 于 2009 年 10 月 31 日发给我的短信就制作好了。其中：

<folderid> 表示短信位于编号为 0 的“收件箱”；

<sender> 与 <receiver> 表示发件人、收件人；

<msgClass> 表示短信类型，IPM.SMStext 代表短信、IPM.MMS 代表彩信；

<subject> 是短信内容；

<delivertime> 与 <lastmodifytime> 表示发送时间、最后访问时间；

<msgid> 表示短信的 ID，最好由手机自行生成。

通过《智能手机工作室》将新的 .XML 文件导入手机，即可恢复 Asuka 于 10 月 31 日发来的短信。

★ 日历

日历的备份与恢复相对比较简单，使用微软自家的 Office Outlook 与 Microsoft ActiveSync（Windows Mobile Device Center）就可以满足要求，无需第三方软件。Office Outlook 的日历与 Windows Mobile 格式相通，通过 ActiveSync 可以直接同步，我们只需设置当两者存在冲突时，以手机为准还是以 Outlook 为准即可。

即使某条日历记录已经丢失了，在 Office Outlook 或 Windows Mobile 中凭借记忆手动重建日历也非常地简单，不用重建 .XML 文件，就是一条条地重建非常麻烦而已。因此，重要的日历最好也事先进行备份。

★ Windows Mobile 用户数据备份工具推荐

丢失的手机数据虽然可以用各种方法恢复，但还是比较麻烦的，特别是当你根本记不清何时接过谁的电话、何时接过谁的短信时，即使知道方法也恢复不出来。因此，平时还是应该尽量做好事前备份，遇到问题后以备份的数据直接恢复才是最简便的。笔者推荐两款平时经常使用的手机数据备份恢复工具。

第一款是 PPC 版本地工具软件 PIM Backup v2.8：

http://www.skycn.com/soft/41127.html （链接仅供参考）

它可以将 Windows Mobile 的通话记录、短信、日历、通讯簿、快速拨号、任务计划及自定义文件等各种数据统一备份或还原，免去了上述项目逐一备份恢复的繁琐。软件备份的速度非常快，笔者用 PIM Backup 一次备份 128 条日历、73 则通话记录、63 条短信加彩信、117 个联系人，仅用时 16 秒。在笔者试用过的各种同类 PPC 备份恢复工具中，PIM Backup 是最为简明高效的一款。

第二款工具实际是一项 Windows Live 在线服务：微软新推出的《Microsoft My Phone 我的手机空间》，允许我们将 Windows Mobile 手机的用户数据联机备份在 Microsoft My Phone 网络中。我们可以到微软官方网站免费下载 My Phone 的 PPC 客户端，在手机中安装使用（.CAB 格式安装包，支持 Windows Mobile 6 全系列系统）：

http://www.microsoft.com/downloads/details.aspx?displaylang=zh-cn&FamilyID=45cd0b4e-cb8c-460c-8f62-b27758721aa8

下载后在手机中运行 My Phone 客户端，通过 WiFi 或 GPRS 将手机接入 Internet，以自己的 Windows Live ID 登录，即可将这部手机与 My Phone 激活。

接下来，我们可以将手机内的通讯簿、日历、任务计划、短信、收藏夹（仅限 Mobile IE）、照片、视频、音乐、文档等与 My Phone 同步，上传至手机空间保存。My Phone 为我们提供了 200MB 的免费空间。

第一次完成登录并上传数据之后，我们即可随时通过 Internet 建立手机与 My Phone 的连接，保持数据的同步。以后如果手机中增加了新的内容，只要连接 Internet 即可立即同步至 My Phone，而且是增量备份，不会重复上传已同步的数据。

完成同步后，如果我们想在 PC 端查看同步的内容，可以在浏览器中打开 My Phone 的 PC 端首页：http://myphone.microsoft.com，以 Live ID 登录查看相关内容。　

如果 My Phone 发现手机中的数据与已同步的数据存在出入，那么会自动以手机为优先，改写 My Phone 空间中的内容，因此我们不用担心手机中的数据遭到篡改。

此外，My Phone 还允许我们同时绑定多部不同的手机，以方便用户将同样的数据从旧手机传递至新手机，只要这些手机都以同样的 Live ID 登录，即可同步共享相同的用户数据，非常方便。

虽然 My Phone 手机空间服务开通的时间还不长，但笔者的试用感觉还不错。唯一遗憾的是，My Phone 提供的一些特色功能，例如远程锁定手机、定位寻找丢失的手机等目前还不支持国内用户，本地化工作还需进一步发展。

剖析将 SP3 整合至 MCE 2005 安装源引发的严重版本冲突与变通解决方法

alx-zj — Sun, 15 Nov 2009 14:50:00 GMT

Windows XP SP3 已经发布了一年半，笔者却一直未见 MSDN 发布整合有 SP3 的 Windows XP Media Center Edition 2005（以下简称 MCE 2005）安装源镜像，而 Windows XP 的家庭版、专业版都已经先后发布了 with SP3 的最新镜像。

起初，笔者还以为 MSDN 已经懒得再为 MCE 2005 进行更新，毕竟使用这个系统的人不是很多。但最近笔者发现，将 SP3 整合至 MCE 2005 安装源存在着非常严重的版本冲突问题。所以，MSDN 并不是懒得对 MCE 2005 进行更新，而是做不出像样的 MCE 2005 with SP3 镜像来。

★ 问题起因

关注笔者博客的朋友可能还记得笔者今年四月所写的一篇《新瓶装旧酒－Vista/7 风格之 Windows XP 最终收藏版》。最近，笔者接到一位网友发来的反馈邮件，那篇文章介绍的 Windows XP with SP3 四合一光盘，其它版本的安装使用都很正常，惟独 MCE 2005 会出现下述问题：

我们知道，将 SP3 整合至 Windows XP 安装源的常规方法是 SP3 安装程序的 -S（-INTEGRATE）参数。如果我们照此方法将 SP3 整合至 MCE 2005 安装源，虽然整合过程可以顺利完成、不会出现任何错误，但当我们用这个整合过的 MCE 2005 with SP3 镜像安装系统时，在安装程序运行到“预计剩余时间 30 分钟－22 分钟”这个阶段，也就是安装系统组件的这个阶段时，必然会报错：

“需要 Windows XP CD 2 上的文件 ehiEPG.DLL，请输入文件的所在位置并点击确定”。

可是，即使我们找遍整个 MCE 2005 with SP3 安装源，也找不到这个文件，安装无法继续。

此时，假如我们选择了“取消”，跳过 ehiEPG.DLL 文件的复制，安装程序就会将“剩余 30 分钟－22 分钟”这个阶段步骤全部甩掉，跳过它直接进入下面的“安装开始菜单”、“注册组件”等步骤。接下来，安装程序虽然也可以运行完、装出来的也是一个显示为 MCE 2005 的系统，但是由于整个“剩余 30 分钟－22 分钟”的阶段都跳过了，所以 MCE 的专有组件将一个也安装不上，甚至连 IE、OE 等系统组件也残缺不全，我们得到的只是一个什么组件也没有的“天生残疾”的 MCE 2005 系统。

笔者接到邮件之后做了一下测试，证明属实。当日笔者制作好的、已经放入包装盒中收藏的四合一光盘，果然也存在这一问题。

★ 问题分析

安装程序找不到 ehiEPG.DLL 文件的问题到底是怎么回事呢？其实，SP3 并不是没有为我们准备 ehiEPG.DLL。假如我们用 WinZip 将 335MB 的 SP3 安装程序打开，可以看到它确实提供了 82 个路径为 i386\root\cmpnents\mediactr\i386 的 MCE 文件，其中就包括 ehiEPG.DLL。可是，当我们以 -S（-INTEGRATE）参数整合 SP3 时，SP3 并没有将这 82 个 MCE 文件添加至 MCE 2005 安装源，而是只更新了 Windows XP 的基本系统文件。这就是为什么安装程序找不到 ehiEPG.DLL 的原因。

那么 SP3 为什么会偷工减料、没有将这 82 个 MCE 文件添加至 MCE 2005 安装源呢？起初笔者对这一怪现象也是百思不得其解。网上搜索了一下，许多 Windows 爱好者对此问题发表了各种看法，有人认为 SP3 误将 MCE 2005 当作了专业版，有人认为应该将 Windows Media Player 11 整合入 MCE 2005 安装源。笔者认为这些观点都没有说到点上，难以令人完全信服。经过一番研究，笔者在 MCE 2005 相关文件的版本号上发现了问题，版本冲突是这一问题的症结所在。

Windows XP Media Center Edition 先后发布过 2002、2004、2005 三个官方版本。MCE 2005 虽然在所有 MCE 中版本最高，但它却是基于 SP2 开发的，因为 2005 年还没有 SP3。直到 2008 年，SP3 才姗姗来迟。

Windows XP 的系统版本号一直是 5.1.2600.XXXX。无论版本号的后缀怎么变，主版本号一直是 2600。例如 SP3 正式版的版本号就是 5.1.2600.5512。可是，当年 MCE 2005 的开发人员却偏偏将 MCE 那些专有组件的文件版本号设成了 5.1.2700.XXXX，这样就造成了一个很可笑的现象：2008 年发布的 SP3，其版本号反而比 2005 年发布的 MCE 2005 还低！

（注：如果我们为 MCE 2005 安装了 Rollup Updates 更新汇总 2 for MCE 2005，则 MCE 专有组件的文件版本号将提升至 5.1.2710；如果进一步安装 KB925766 for MCE 2005，版本号还会继续提升至 5.1.2715。为了叙述方便，以下统一以 MCE 2005 的原始版本号 5.1.2700 说明。）

因此，当我们将 SP3 整合至 MCE 2005 安装源时，安装程序发现 MCE 2005 原有的那些 MCE 文件已经是版本号更高的 5.1.2700.XXXX，试问它怎么可能再把自己那 82 个版本号为 5.1.2600.5512 的文件添加进去、让低版本文件替换高版本文件呢？

有人可能会说，既然 MCE 2005 那些文件当年已经被设为 2700 了，SP3 为什么还要把自己提供的那 82 个 MCE 文件设为 5.1.2600.5512 呢？设一个不比 2700 低的版本号不就没问题了么？这可能就是传说中甲鱼的臀部－不知哪个人的“规定”了：SP3 安装程序压缩包里的所有文件，版本号必须都是 5.1.2600.5512！

由于 SP3 提供的这 82 个 MCE 文件版本号已经被固定为 5.1.2600.5512，所以这 82 个文件也根本不可能是针对 MCE 2005 的更新了。事实上，它们只不过是针对 MCE 2004 系统的更新文件而已，MCE 2004 系统的原文件版本号不是 5.1.2700。总之一句话：SP3 只包含了 82 个适用于 MCE 2004 系统的更新文件、不包含任何适用于 MCE 2005 系统的更新文件。

★ 问题结论

经过上述分析，我们可以得出下列结论：

当我们以 -S（-INTEGRATE）参数将 SP3 整合至 MCE 2005 安装源时，

1.由于版本冲突的原因，SP3 不会把它自己提供的那 82 个版本号为 5.1.2600.5512 的 MCE 文件添加至 MCE 2005 安装源，不会替换版本号 5.1.2700 的 MCE 2005 原文件；

2.由于 SP3 实际只包含针对 MCE 2004 的更新，所以在整合 MCE 2005 时它会把安装源误当作 MCE 2004，并按照 MCE 2004 的规格修改 MCE 2005 相应的 .INF 安装信息文件；

3.ehiEPG.DLL 是一个 MCE 2004 独有的文件、MCE 2005 没有这个文件。将 SP3 整合至 MCE 2005 安装源之后，由于 ehiEPG.DLL 并没有随那 82 个文件被添加至安装源，而 SP3 又将 MCE 2005 的相关 .INF 文件修改为了 MCE 2004 的版本，所以就会在安装 Windows 时出现需要 ehiEPG.DLL、但又找不到 ehiEPG.DLL 的现象。

因此，针对这个问题的最终结论是：

假如我们使用的是 MCE 2004，可以直接以常规方法整合 SP3、得到 MCE 2004 with SP3 安装源，不会有任何问题。

假如我们使用的是 MCE 2005，目前至少按照微软官方提供的方法无法得到理想的 MCE 2005 with SP3 安装源。如果我们需要 MCE 2005 with SP3 系统，最好还是首先安装原版的 MCE 2005 系统（只包含 SP2），然后再单独安装 SP3。这样安装的系统除了步骤麻烦外，没有任何问题。

★ 变通解决

首先安装原版 MCE 2005 系统（只包含 SP2）、再单独安装 SP3 的方法虽然是最稳妥，但像笔者这样希望制作 MCE 2005 with SP3 安装源的用户，还是希望将问题一步搞定。既然微软官方的方法行不通，有没有什么变通的方法可以制作出 MCE 2005 with SP3 安装源呢？经过笔者的摸索，还是有一些门路可循。

1.添加 ehiEPG.DLL。

这是最为简单的变通方法，既然直接将 SP3 整合至 MCE 2005 安装源会提示找不到 ehiEPG.DLL，我们可以自己从 SP3 中解压缩提取 ehiEPG.DLL，然后手动复制到经过整合的安装源。不过，这样得到的只是一个 MCE 2004 with SP3 安装源，原因之前已经解释过了。我们这么做等于是帮助 SP3 把 MCE 2005 完全修改为 MCE 2004、连缺的文件都帮它补上了。因此，如果我们用这样的安装源完成系统安装，启动 Media Center 组件，可以看到其版本信息显示为：Media Center 2004 v5.1.2600.5512

2.还原 MCE 2005 原版的 MEDCTROC.INF。

如果我们不想让 SP3 把 MCE 2005 安装源修改为 MCE 2004，就需要在整合 SP3 前备份原版 MCE 2005 的 MEDCTROC.INF，这个文件直接决定了我们安装的 Media Center 是 v3.0（MCE 2005）还是 v2.8（MCE 2004）。

将 SP3 整合至 MCE 2005 安装源后，我们把备份的 MEDCTROC.INF 复制至安装源 i386 文件夹，替换已有文件，这样 MCE 2004 with SP3 安装源就又升级为 MCE 2005 with SP3 了。此时，我们也无需再手动添加 ehiEPG.DLL，因为只有 MCE 2004 需要它、MCE 2005 不需要。

不过，以这样的安装源执行系统安装时，安装程序可能又会提示找不到 Napclientprov.MOF 与 Napclientschema.MOF。我们可以在已安装好的 MCE 2005 系统的 Windows\system32\wbem 文件夹找到它们，将它们手动添加至安装源即可。

以这样的方式处理后，我们可以初步得到一个名符其实的 MCE 2005 with SP3 安装源。经过测试，在安装好的系统中启动 Media Center，可以看到其版本信息显示为：Media Center 2005 v5.1.2700.2180

3.将 PlusOC 与 Sonic 组件添加至 MCE 2005 with SP3 安装源。

按照上述方法得到的 MCE 2005 with SP3 安装源虽然可以使用，但还是存在一些问题。我们知道，Windows XP 的 Media Center 相比 Windows Vista/7 Media Center 增加了 PlusOC 与 Sonic 组件。PlusOC 包括 Windows 舞者、Windows 聚会模式、Royale 视觉样式及特色屏保等组件；而 Sonic 是一个 DVD 烧录组件，这些都是 MCE 2005 系统的特色功能。但是，按照上述方法处理得到的 MCE 2005 with SP3 安装源，却只包含 Media Center 组件，不会安装原版 MCE 2005 的 PlusOC 与 Sonic 组件，因此我们还需要将这个漏洞填补上。

PlusOC 与 Sonic 组件没有被安装的原因在于 SYSOC.INF 文件。原版 MCE 2005 安装源的 SYSOC.INF 文件包含下列三行语句：

Freestyle=medctroc.dll,MedCtrOCISetupProc,medctroc.inf,HIDE,7
SonicDVDandCDBurning=ehOCGen.dll,OcEntry,sonic.inf,,7
WinPlus=plusoc.dll,OcEntry,plusoc.inf,,7

其中第一行代表 Media Center 组件，第二行、第三行分别代表 Sonic 与 PlusOC。

但是在将 SP3 整合至 MCE 2005 安装源后，第二行、第三行语句就被删除了，SYSOC.INF 只剩下了第一行，所以 PlusOC 与 Sonic 组件不会被安装。

解决这个问题并非只需把第二行、第三行语句添加回 SYSOC.INF 这么简单。如果我们只修改 SYSOC.INF 的话，安装系统时进行到“预计剩余时间 30 分钟－22 分钟”这个阶段，安装程序又会甩掉所有步骤，装出的又是一个没有任何组件的“先天残疾”系统。因为修改一个 SYSOC.INF 是不够的，其它与 PlusOC、Sonic 组件相关的文件也必须进行配合修改。具体如下：

3.1.在整合 SP3 之前，从原版 MCE 2005 安装源中备份下列文件：

（位于 i386 文件夹）ACELPDEC.AX_、EHOCGEN.DL_、ENCDEC.DL_、MEDCTROC.DL_、MEDCTROC.IN_、MEDIACTR.CA_、MPG2DATA.AX_、MSVIDCTL.DL_、PLUSOC.DL_、PLUSOC.IN_、SBE.DL_、SONIC.IN_、VBICODEC.AX_、WSTPAGER.AX_；

（位于 i386\svcpack 文件夹）PLUS.CA_、SONIC.CA_；

3.2.整合 SP3 后，将备份的上述文件还原；

3.3.手动修改 i386\SYSOC.INF，

在 Freestyle=medctroc.dll,MedCtrOCISetupProc,medctroc.inf,HIDE,7 语句后面添加

SonicDVDandCDBurning=ehOCGen.dll,OcEntry,sonic.inf,,7

WinPlus=plusoc.dll,OcEntry,plusoc.inf,,7

两行语句；

3.4.手动修改 i386\TXTSETUP.SIF，在 [SourceDisksFiles] 后面添加下列语句：

ehOCGen.dll = 100,,,,,,,32,0,0
sonic.inf = 100,,,,,,,20,0,0
sonic.cab = 3,,,,,,_x,,3,3

plusoc.dll = 100,,,,,,,32,0,0
plusoc.inf = 100,,,,,,,20,0,0
plus.cab = 3,,,,,,_x,,3,3

3.5.手动修改 i386\DOSNET.INF，在 [Files] 后面添加下列语句：

d1,ehOCGen.dll
d1,sonic.inf
d3,sonic.cab

d1,plusoc.dll
d1,plusoc.inf
d3,plus.cab

3.6.手动修改 i386\SVCPACK.INF，在 [ProductCatalogsToInstall] 后面添加下列语句：

PLUS.CAT

SONIC.CAT

这样才完成了向 MCE 2005 with SP3 安装源添加 PlusOC 与 Sonic 组件的全部步骤。

笔者用经过上述全部步骤处理的 MCE 2005 with SP3 安装源进行了测试，整个安装过程非常顺利。装好的 Windows XP 版本信息显示为 MCE 2005，Media Center 组件、PlusOC 组件、Sonic 组件的运行也都一切正常，Windows XP 的基本组件 IE 6、OE 6、Media Player 9 等也没有受到任何影响。总体来看，这个安装源的效果已经基本等同于先安装原版 MCE 2005（只包含 SP2）、再单独安装 SP3 的系统了。

当然，这种变通的处理方法未经过微软官方严格测试，也许在表面一切正常的掩盖下依然存在一些隐患或弊病，笔者不敢保证 100% 地解决了将 SP3 整合至 MCE 2005 安装源引起的版本冲突问题。

不知道 MSDN 将来还会不会发布正式的 MCE 2005 with SP3 安装源镜像了，估计可能性已经不大；或者，假如 Windows XP 将来还会发布 SP4 的话，希望能在 SP4 中修正一下 MCE 文件的版本号，避免版本冲突问题的再次发生。

★ 特别补充－MCE 2005 组件的升级顺序说明

最后，笔者再总结一下 MCE 2005 的组件升级顺序问题。微软在 2007 年发布 Windows Vista Media Center 之前，一直在对 MCE 2005 进行组件升级，比较重要的两次更新就是之前曾提到的 Rollup Updates 更新汇总 2 for MCE 2005（以下简称更新汇总 2）及 KB925766 for MCE 2005（以下简称 KB925766）。因此，MCE 2005 with SP3 还不能算作真正意义上的最新版本的 MCE 2005。当我们以上述步骤制作的 MCE 2005 with SP3 安装源安装好系统后，还需要继续安装这两个更新，才能得到最新版本的 MCE 2005。

更新汇总 2 及 KB925766 无法整合在 MCE 2005 with SP3 安装源中，因为这两个更新均建立在 Windows Media Player 10 的基础上，MCE 2005 with SP3 安装源内置的是 Windows Media Player 9。由于我们无法将 Windows Media Player 10 整合进安装源，所以也无法整合这两个更新，只能在安装系统后手动安装。

更新汇总 2 相当于 MCE 2005 的专用 Service Pack，它不仅将所有 MCE 组件的文件版本提升至 5.1.2710，同时也是 MCE 2005 继续安装某些系统组件的前提条件。例如当我们试图为 MCE 2005 安装 Windows Media Player 11 时，安装程序就会提示必须首先安装更新汇总 2。从某种意义上说，安装有更新汇总 2 的 MCE 2005 可以视为“MCE 2005 R2”。

KB925766 则是 2006 年 10 月发布的一个针对 MCE 2005 更新汇总 2 的累积性更新，它是目前所有 MCE 2005 更新的最高版本。安装 KB925766 之前必须首先安装更新汇总 2，它可以将 MCE 组件的版本由 5.1.2710 进一步提升至最高的 5.1.2715。按照之前打的比方，KB925766 是一个专门针对 MCE 2005 R2 的更新，原版的 MCE 2005（5.1.2700）不能直接安装它。

言归正传，当我们以 MCE 2005 with SP3 安装源安装好系统后，应按照下述顺序对 MCE 2005 组件进行升级：

1.安装 Microsoft .net Framework 1.1 及 1.1 SP1。

Microsoft .net Framework 1.1 及 1.1 SP1 是安装更新汇总 2 的前提条件之一。原版的 MCE 2005 组件大都基于 .net Framework 1.0 SP3 开发，而可以视作 MCE 2005 R2 的更新汇总 2 则基于 1.1 及 1.1 SP1。只有安装了 1.1 及 1.1 SP1，才能安装更新汇总 2。

2.安装 Windows Media Player 10 for Windows XP。

之前已经说过，更新汇总 2 及 KB925766 均建立在 Windows Media Player 10 的基础上，它是安装更新汇总 2 的另一个前提条件。在 MCE 2005 内置的 Windows Media Player 9 环境中，更新汇总 2 将安装失败。

另外，此时不能将 Windows Media Player 9 直接升级为 Windows Media Player 11，因为之前说过，Windows Media Player 11 的安装前提条件是首先安装更新汇总 2。

3.安装更新汇总 2。

满足了 .net Framework 1.1 及 1.1 SP1 与 Windows Media Player 10 这两个条件后，即可将 MCE 2005 升级为更新汇总 2。

4.安装更新汇总 2 后，如果希望将 Windows Media Player 10 升级至 11，可以在此时安装。

5.安装更新汇总 2 后，最后安装 KB925766。

这样，才能将 MCE 2005 升级为带有更新汇总 2 及 KB925766 的、2006 年 10 月的最新版本。

Native Boot VHD 启动失败的几种常见原因

alx-zj — Tue, 10 Nov 2009 15:40:00 GMT

Native Boot VHD 是 Windows 7 引人关注的新功能之一，它可以由 Windows 7 启动管理器加载 .VHD 虚拟硬盘镜像文件，直接启动安装于 .VHD 镜像中的操作系统。然而，顺利完成 Native Boot VHD 的启动需要满足很多条件，不少朋友在试用此功能时总是遇到这样那样的问题引起 Native Boot VHD 启动失败。笔者在此总结一下微软新闻组中被用户问得最多的几种 Native Boot VHD 启动失败的原因，欢迎大家参考补充。

1.操作系统版本不正确。

这是初学者最容易遇到的问题。很多人听说 Windows 7 提供了 Native Boot VHD 功能便兴冲冲地拿自己以前在 Virtual PC 2007 中安装过的 Windows XP/Vista 试用，结果当然是无法启动。Native Boot VHD 只支持 Windows 7 与 Windows Server 2008 R2 的部分版本的启动，Windows 2000、Windows XP/Server 2003、Windows Vista/Server 2008（非 R2 版）等系统均不受支持。

即使是 Windows 7，也只有专业版、企业版、旗舰版支持 Native Boot VHD，两个家庭版会在启动至欢迎屏幕时提示“此版本不支持从 VHD 启动”的产品授权错误。当然，这其实是人为增加的限制。

2.动态扩展类型的 .VHD 文件，设置的最大容量超过了物理硬盘的实际容量。

熟悉 Virtual PC 2007 的朋友都知道，.VHD 格式的虚拟硬盘镜像文件分为动态扩展（Dynamically Expanding）、固定大小（Fixed Size）、差分（Differencing）、链接至物理硬盘（Linked to a Hard Disk）四种类型，其中动态扩展与固定大小两种类型可以被 Windows 7 支持，我们可以使用 Windows 7 内置的“磁盘管理”中直接建立动态扩展或固定大小类型的 .VHD 文件。

即使是第一次接触 .VHD 也不要紧，它们的区别不难理解：动态扩展类型的 .VHD 需要我们在建立时指定其最大值，但 .VHD 文件占用的实际空间只取决于虚拟硬盘的数据量。例如，假设一个动态扩展的 .VHD 文件最大值被设置为 10GB，其中存有 4GB 的数据，那么这个 .VHD 文件大小也就只有 4GB 而不是 10GB，10GB 只是其上限。固定大小类型的 .VHD 则是指无论虚拟硬盘中存有多少数据，.VHD 文件的大小都始终等于其最大值。例如，假设一个固定大小的 .VHD 文件被设置为 10GB，那么无论其中存有多少数据，哪怕虚拟硬盘是空白的，这个 .VHD 文件也都始终是 10GB。

言归正传，很多人发现，如果把固定大小类型的 .VHD 文件用于 Native Boot VHD，启动一般没有问题；而如果使用动态扩展类型的 .VHD 文件，则有的能够完成启动、有的不能，这是为什么呢？原来，动态扩展类型的 .VHD 文件允许我们将其最大值设置得比物理硬盘实际可用空间还高。例如，假设 .VHD 文件所在的物理硬盘只有 5GB，我们依然可以将 .VHD 文件的最大值设置为 10GB 甚至更高，只要 .VHD 文件的实际大小不超过 5GB 就可以。对于 Virtual PC 2007 虚拟机而言，这样的设置并没有什么问题。但对于 Native Boot VHD 来说，如果动态扩展类型的 .VHD 文件最大值超过了物理硬盘的实际可用空间，就会引起 Native Boot VHD 启动失败。

相反地，固定大小类型的 .VHD 文件由于大小始终固定，它的大小肯定小于物理硬盘的实际可用空间（假如超过了实际可用空间，这个 .VHD 文件根本建立不起来），所以它不会出现动态扩展类型的那种问题，相对比较保险。因此，用于 Native Boot VHD 启动的 .VHD 文件，我们最好将其设置为固定大小类型；如果要设置为动态扩展类型，一定要确保其最大值不能超过物理硬盘的实际可用空间。

3..VHD 文件自身的原因引起 Windows 7 启动管理器无法加载。

.VHD 文件自身的原因可谓多种多样，笔者在微软新闻组中见过的有：.VHD 文件本身残缺受损、.VHD 文件所在的物理硬盘存在磁盘错误、.VHD 文件所在的物理硬盘应用了 NTFS 的压缩或加密、.VHD 文件所在的物理硬盘应用了 RAID 等等。总之只要 Windows 7 启动管理器无法正常访问并加载 .VHD 文件，都会引起 Native Boot VHD 启动失败，需要我们针对具体的问题，进行相应的修复工作。例如，.VHD 文件损坏的，想办法修复；物理硬盘存在磁盘错误的，尝试磁盘扫描；物理硬盘应用 NTFS 压缩或加密的，将 .VHD 文件移动至没有压缩或加密的 NTFS 分区；物理硬盘应用了 RAID 的，可以为 .VHD 文件中安装的操作系统捆绑 RAID 驱动。总之，兵来将挡、见招拆招，确保 Windows 7 启动管理器可以正常访问并加载 .VHD 文件，即可解决因这一类问题引起的 Native Boot VHD 启动失败。

支持网络级别身份验证（NLA）的远程桌面连接

alx-zj — Mon, 05 Oct 2009 08:00:00 GMT

在默认的系统设置中，如果我们在 Windows Vista 与 Windows XP 中分别打开远程桌面，然后在窗口标题栏的右键菜单中打开“关于远程桌面连接”对话框，可以看到远程桌面的“关于”信息如下：

关于远程桌面连接

支持远程桌面协议 6.1。

外壳版本 6.0.6001
控件版本 6.0.6001

(C) 2007 Microsoft Corporation. 保留所有权利。

（Windows Vista）支持网络级别的身份验证。
（Windows XP）不支持网络级别的身份验证。

两个系统在是否支持网络级别的身份验证处存在一字之差。

所谓网络级别的身份验证（Network Level Authentication，简称 NLA）是一种在建立完整的远程桌面连接之前首先完成用户身份验证并显示登录屏幕的更加安全的验证方法，可以防止远程计算机受到黑客或恶意软件的攻击。

使用 NLA 的优点有（摘录自 Windows 帮助文档）：

1. 最初只需要少量的远程计算机资源，对用户进行身份验证之前，远程计算机仅使用有限的资源，而不像早期版本启动整个远程桌面连接；

2. 可以通过降低拒绝服务攻击（尝试限制或阻止访问 Internet）的风险提供更高的安全保障；

3. 使用远程计算机身份验证可以防止我们连接到因恶意目的而安装的远程计算机。

由于 NLA 已经包含于 Windows Vista 系统，所以其远程桌面默认开启 NLA；Windows XP 虽然默认不支持 NLA，但 NLA 已经包含在 SP3 中，为 Windows XP 安装 SP3 即可为远程桌面添加 NLA。这也是 SP3 为 Windows XP 添加的为数不多的新功能之一。

不过，Windows XP 安装 SP3 后添加的 NLA 并没有被自动激活，还需要手动对注册表进行一些修改才可以使用。将如下内容复制至记事本并保存为 .REG 文件，双击导入注册表（此 .REG 文件可以从本文结尾的附件处下载）：

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"Security Packages"=hex(7):6b,00,65,00,72,00,62,00,65,00,72,00,6f,00,73,00,00,\
00,6d,00,73,00,76,00,31,00,5f,00,30,00,00,00,73,00,63,00,68,00,61,00,6e,00,\
6e,00,65,00,6c,00,00,00,77,00,64,00,69,00,67,00,65,00,73,00,74,00,00,00,74,\
00,73,00,70,00,6b,00,67,00,00,00,00,00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders]
"SecurityProviders"="msapsspc.dll, schannel.dll, digest.dll, msnsspc.dll, credssp.dll"

重新启动计算机后，“关于远程桌面连接”对话框即可显示“支持网络级别的身份验证”字样。

为何在命令提示符中输入 ^ 显示 More?

alx-zj — Mon, 21 Sep 2009 11:30:00 GMT

（注：本文被 Microsoft TechNet 中文速递邮件 2009 年第 18 期收录为 MVP 推荐 Blog）

笔者近日在微软新闻组看到这样一个问题：在 CMD 命令提示符输入符号 ^，提示符会变为 More? 字样，如果不输入新的命令，必须回车确认两次才能返回之前的提示符。如下所示：

C:\Windows>^
More?
More?

C:\Windows>

这是什么意思呢？

问题看似很简单，冷不丁被人问起还真回答不出。起初，笔者认为 More? 可能与逐屏显示输出命令 MORE 有关，估计是 MORE 命令的一种提示符。但实际上，More? 根本不是什么提示符，只不过是一种语气非常随意的“还有什么要补充的吗”而已，基本等同于“Anything else？”。

举个例子，DIR 命令可以列出当前文件夹的文件列表，DIR /P 命令则可以以分屏方式列出。如果我们输入 DIR 后又加了一个 ^ 并执行，命令提示符就会认为命令还没有完，并用 More? 来询问“接下来还有什么要补充？”。此时，我们可以接续输入 /P，这样即可与之前输入过的 DIR 组成 DIR /P，实现分屏列出文件。如下所示：

C:\Windows>DIR ^

More? /P

（开始分屏列出文件）

反之，如果命令提示符询问我们 More? 两次后都没有输入新的命令 /P，那么就会只按照之前输入过的 DIR 进行处理。如下所示：