贵州省发改委付京得病:Alexis Zhang's Blog 1

来源：百度文库 编辑：九乡新闻网 时间：2024/04/29 01:08:48

笔者从 2001 年起开始订阅来自微软的速递邮件，包括 MSDN 速递、TechNet 速递、微软新闻速递、 Windows 视界、Office 月报等若干种，一直未曾间断。但从 2008 年 10 月起，笔者的邮箱一直没有 收到过任何速递邮件。经检查，笔者的邮箱并未将速递邮件地址 Microsoft@e-mail.microsoft.com、 Microsoft@newsletters.microsoft.com 设置为垃圾邮件拒收；在微软网站的“个人简档中心”检查 “管理我的订阅”也可以看到订阅的所有速递邮件列表。而且，此问题并非笔者一人遇到，在微软中文 技术论坛的“领先一步 从 TechNet 中文速递邮件开始”组也有不少人有此问题，都是在 2008 年前后 发现订阅的速递邮件失效：   http://social.microsoft.com/Forums/zh-CN/2018/thread/08fed77e-b6e4-48c2-bdd9-676106833176   由于微软网站的订阅中心在 2008 年做过一次改版，笔者认为这个问题可能是那些早于 2008 年注册的 老订户的 Live ID 邮箱信息在改版后未能重新激活所致。最近，笔者在微软网站的“个人简档中心”－ “管理我的订阅”尝试重新激活邮箱设置解决了问题，原先失效的邮箱已经可以重新接收速递邮件了。 步骤如下：   1. 打开微软中文网站首页，点击右下角的“个人信息中心”，然后以 Live ID 登录；   2. 在登录后的“个人简档中心”里点击“管理通信”中的“订阅 Microsoft 通信或管理您现有的订阅”， 此时将出现以前订阅过的速递邮件列表，我们可以确认一下订阅的项目是否有误，并按照需要增减；   3. 在页面左侧点击“我的个人信息”，然后点击“我的电子邮件地址”旁的“编辑”；   4. 将以前填写的电子邮件地址修改为一个不同的邮箱，“个人简档中心”会自动向这个新邮箱发送一封 确认邮件，点击邮件中提供的专有链接完成修改；   5. 重新打开“我的个人信息”，这时可以看到“我的电子邮件地址”已经被修改为新的邮箱；   6. 如果希望继续使用以前注册的邮箱接收速递邮件，可以重复步骤 4，将“我的电子邮件地址”再修改 为以前注册的邮箱，这个邮箱同样也将收到一封确认邮件，需要点击邮件中提供的专有链接完成修改。   这样将“我的电子邮件地址”修改两次后，即可重新激活以前注册的邮箱，以后就可以正常地接收所有 微软速递邮件了。但如果不修改两次邮箱设置的话，以前注册的邮箱始终收不到重新激活的确认邮件， 就将一直无法接收速递邮件，即使其它的设置均正确无误。 发表于 作者 alx-zj | 1 评论 归档在：网络（IE/Mail/Messenger等）应用技巧 2011年3月28日 6:30

通过 Microsoft IntelliPoint 设置鼠标中键单击有何特殊用途

我们现在已经很难买到传统的老式三键鼠标了，只有极少数 PS/2 或串口的早期产品还提供中键。 由于鼠标中键并未广泛地应用于 Windows 程序，所以自从微软发明滚轮鼠标后，鼠标中键便逐步 被可按动的滚轮取代了。目前市面上销售的绝大多数鼠标均只配备左键、右键及可按动的滚轮。

对于非微软鼠标及未安装 Microsoft IntelliPoint 驱动程序的微软鼠标而言，可按动的滚轮键在多数 Windows 程序中只起着 AutoScroll 自动滚动的作用：当我们打开了一篇比较长的、带有滚动条的 文档或 Web 页时，除了可以拨动滚轮上下翻动之外，还可以按下滚轮键，这时鼠标箭头将显示为 AutoScroll 自动滚动的标志，只需直接移动鼠标即可上下翻动文档或 Web 页。

对于安装有 Microsoft IntelliPoint 驱动程序的微软鼠标而言，滚轮键默认会被驱动程序自动分配为 “Flip 3D（Windows 7/Vista）”或“即时查看（Windows XP）”。由于所有安装了 Microsoft IntelliPoint 驱动程序的微软鼠标每个按键的功能都可以自行定义，所以如果我们不满意默认的滚轮键功能， 可以通过 Microsoft IntelliPoint 驱动程序重新定义滚轮键的功能，在滚轮键的下拉菜单中重新选择 “中键单击”。

那么，除了 AutoScroll 自动滚动外，将滚轮键重新设置为“中键单击”还有什么其它的实际用途呢？ 微软硬件官方博客的一篇技巧值得我们参考，在 Windows 系统及 IE 浏览器中，偶尔还是可以用上 “中键单击”的。   1. 快速启动新的程序窗口。   Windows 7 超级任务栏会将同类的程序窗口分组堆叠显示为一个任务栏程序图标。假设我们已经打开 若干 Word 文档，现在需要新建一个空白的 Word 文档窗口，常规的做法要么首先切换至任一 Word 窗口，从 Word 的 Ribbon 工具栏中选择新建文档，要么用鼠标右键单击任务栏的 Word 图标，然后 从跳转列表中重新点击“Microsoft Word”。假如鼠标设置了中键单击，我们只需对任务栏的 Word 图标 中键单击一下即可。   2. 快速关闭已堆叠的任意程序窗口。   当若干同类的程序窗口分组堆叠显示为一个任务栏程序图标后，在鼠标箭头悬停在任务栏图标时， Windows 7 会为我们显示每一个窗口的缩略图。如果我们希望关闭其中的某个窗口，常规的做法可以 点击窗口缩略图那个很小的红色 × 按钮。假如鼠标设置了中键单击，我们只需对需要关闭的缩略图 中键单击一下即可。   3. 新建标签在后台打开链接。   假如鼠标设置了中键单击，我们只需对 IE 浏览器中的任何链接中键单击一下即可新建一个 IE 标签 并在后台打开链接。这则技巧非常适合那些习惯于在浏览一个网站时首先挑出自己感兴趣的文章， 逐一打开后再慢慢浏览的用户。   4. 快速关闭浏览器标签。   IE 浏览器同时打开的若干标签也会在 Windows 7 超级任务栏中显示缩略图，哪怕它们都位于同一个 IE 窗口。假如鼠标设置了中键单击，除了可以中键单击任务栏缩略图关闭标签，在 IE 浏览器窗口里 中键单击标签也可以快速关闭标签，从而不用点击标签右侧那个很小的 × 按钮。   5. 快速打开收藏夹中的所有链接。   不知道大家是否习惯于对收藏夹中保存的链接进行整理？假如我们在收藏夹中建立了若干文件夹， 将收藏的链接分类保存，并且对鼠标设置了中键单击，那么我们只需首先点击 IE 浏览器中的五角星 图标打开收藏夹，然后对收藏夹中的文件夹中键单击一下，即可快速打开此文件夹中的所有链接， 并且每个链接均使用一个新的标签，而且这些标签是以相同的颜色分组归类的。例如，我们可以将 自己常去的论坛版面分别保存在收藏夹的一个文件夹里，每次访问论坛时只需用鼠标中键单击一次 文件夹，即可用分组归类的标签分别打开所有的版面。   如果哪位朋友还有其它的鼠标中键应用技巧，还望不吝分享。 发表于 作者 alx-zj | 0 评论 归档在：WindowsXP/Server2003及早期版本的Windows, Windows7/Vista/Server2008, 微软硬件及其它硬件 2011年2月22日 22:00

自行设置记事本的 ShellNew 模板令新建的文本文档避免 ANSI 乱码

众所周知，Windows 记事本一直以 ANSI 做为默认编码保存新建的 .TXT 文本文档，而 ANSI 编码在处理 部分字符时会出现乱码或显示黑色方块的问题，例如曾经广为流传的“记事本保存‘联通’二字即乱码”。 为了避免这种错误，通常我们会在新建文本文档后将其以 Unicode 或 UTF-8 编码保存。   不过，每次新建文本文档都要手动修改编码未免有些繁琐，有没有办法令新建的文本文档默认即以 Unicode 或 UTF-8 编码保存呢？微软英文论坛的帖子《Default UTF-8 Encoding for New NotePad Documents》 提供的一则修改 ShellNew 模板的方法值得推荐，笔者特将其翻译并精简总结如下：   1. 打开记事本新建一个空白的文本文档，不输入任何文字，然后保存此文档，在“另存为”对话框中将编码 由默认的 ANSI 修改为 Unicode 或 UTF-8，接着为文件取名，在此假设将新文档命名为 UNICODE.TXT。   2. 将 UNICODE.TXT 复制至隐含的系统文件夹 C:\Windows\ShellNew。   3. 打开注册表编辑器定位至：HKEY_CLASSES_ROOT\.txt\ShellNew，新建名为 FileName 的字符串值， 将此字符串值设置为 C:\Windows\ShellNew\UNICODE.TXT。   上述做法的目的是将 .TXT 文本文件的“新建”模板 ShellNew 设置为我们自定义的以 Unicode 编码保存的 空白文本文件。这样，如果我们再使用资源管理器右键菜单中的“新建”－“文本文档”建立新文本文档， Windows 就会自动以 C:\Windows\ShellNew\UNICODE.TXT 做为模板来新建文本文档，文档的默认编码 就变为 Unicode 了。   不过，此方法只适用于以“新建”右键菜单方式建立新文本文档。假如我们首先通过开始菜单启动记事本， 然后再新建文本文档，C:\Windows\ShellNew\UNICODE.TXT 模板便不会被使用，新建的文本文档依然 还将使用默认的 ANSI 编码。 发表于 作者 alx-zj | 2 评论 归档在：WindowsXP/Server2003及早期版本的Windows, Windows7/Vista/Server2008 2011年2月14日 15:40

简析 Windows Theme 如何将开始按钮上的 Windows LoGo 及开始二字隐藏

Windows 的开始按钮自 Windows 95 起首次出现于任务栏左下角，其基本外观一直没有什么变化。无论 我们在任何版本的 Windows 中使用经典视觉样式，都可以看到开始按钮的主体呈矩形，在按钮左侧显示 Windows LoGo、右侧显示“开始”二字（英文版 Windows 显示“Start”字样）。从 Windows 95 至 Windows 7，开始按钮的经典样式一直延续着这种传统的外观设计。   Windows XP 首次引入了 Windows Theme 视觉样式。不过 Windows XP 默认的 Luna 以及 Royale （Media Center Edition 默认）视觉样式依然延续着经典开始按钮的外观特征。我们可以看到一个近似于 矩形的绿色开始按钮，按钮上面依然是左侧显示 Windows LoGo、右侧显示“开始”二字，与经典样式的 开始按钮如出一辙。
  Windows 7/Vista 的 Aero 及 Basic 视觉样式对开始按钮的外观进行了较大的修改，使用一个圆形的 Windows Pearl 珍珠球取代了矩形的开始按钮。同时，我们也看不到始终显示的“开始”二字了， 仅当鼠标箭头悬停在 Windows Pearl 珍珠球上时，才能看到一个悬浮的“开始”提示。
  
笔者原先一直不明白 Aero 及 Basic 视觉样式、以及某些由第三方制作的模仿 Aero 风格的 Windows XP 视觉样式是如何将开始按钮上的“开始”二字隐藏的，也不明白 Windows 为何仅在应用这些视觉样式时 不显示“开始”二字、切换为经典视觉样式就会显示。最近，笔者通过 ResBuild 研究了一款来自 Se7en Transformation Pack 的第三方仿 Aero 视觉样式，才弄明白了此类视觉样式隐藏“开始”二字的原理。

1. 此“开始”非彼“开始”。

当我们将鼠标箭头悬停在 Windows Pearl 珍珠球上时看到的悬浮的“开始”提示，并不是经典样式的开始 按钮上始终显示的“开始”二字。因为当我们将 Windows 7/Vista 设置为经典视觉样式时，不仅开始按钮 始终显示“开始”二字，鼠标箭头悬停时依然也可以看到悬浮出现的“开始”提示。这就可以证明，它们是 两个不同的“开始”，此“开始”并非彼“开始”。     其实，鼠标箭头悬停在 Windows Pearl 珍珠球上时看到的悬浮的“开始”提示是从早期版本 Windows 的 “单击这里开始”提示修改而来的。Windows 7/Vista 只是将原来的六个字删减成了两个字而已。因此， 无论 Windows 使用何种视觉样式，这个悬浮的“开始”提示都会在鼠标箭头悬停在开始按钮时出现。     2. Windows Pearl 并非原开始按钮左侧的 Windows LoGo。

起初，笔者曾经误以为 Aero 及 Basic 视觉样式的 Windows Pearl 珍珠球是由开始按钮左侧的 Windows LoGo 变化而来的，后来笔者发现它们也是两个不同的元素。Windows Pearl 珍珠球在常规时、鼠标箭头 悬停时、被单击按下时具有三种不同的形态，而开始按钮左侧的 Windows LoGo 无论在任何时候都始终 没有形态变化。这就可以证明 Windows Pearl 珍珠球并非原开始按钮左侧的 Windows LoGo。     其实，在 Windows XP 的 Luna 及 Royale 视觉样式中，具有三种不同形态变化的并不是开始按钮左侧的 Windows LoGo，而是开始按钮的绿色矩形按钮底板。我们知道，Luna 及 Royale 视觉样式的开始按钮 平时呈绿色，鼠标箭头悬停时变为亮绿色、被单击按下时变为深绿色，而开始按钮左侧的 Windows LoGo 始终没有形态变化。因此，Aero 及 Basic 视觉样式具有三种形态变化的 Windows Pearl 珍珠球并非源自 开始按钮左侧的 Windows LoGo，而是从 Luna 及 Royale 视觉样式的绿色矩形按钮底板发展而来。     3. Windows LoGo 及“开始”二字始终覆盖在开始按钮底板之上。   虽然 Windows Pearl 珍珠球是从开始按钮的底板发展而来，但是这个元素最初存在的目的毕竟只是底板， 开始按钮上显示的 Windows LoGo 及“开始”二字会始终覆盖在这块底板之上、无法被底板遮挡在下。 如果我们直接将 Windows XP 的 Luna 或 Royale 视觉样式的绿色矩形底板图案替换为 Windows Pearl 珍珠球的图案，Windows LoGo 及“开始”二字依然会覆盖在 Windows Pearl 珍珠球上面，这并不是 我们想要的用 Windows Pearl 珍珠球完全取代开始按钮的效果。   4. Windows LoGo 及“开始”二字无法删除。

既然 Windows LoGo 及“开始”二字无法被开始按钮底板遮挡在下，能否将这两个元素彻底删除以避免 它们覆盖 Windows Pearl 珍珠球呢？答案是不能。首先，Windows LoGo 及“开始”二字并不是由 Windows Theme 定义的界面元素，而是 Explorer.EXE 包含的资源；其次，虽然 Windows Pearl 珍珠球 不需要 Windows LoGo 及“开始”二字，但经典视觉样式的开始按钮依然需要它们。如果我们真的删除了 Windows LoGo 及“开始”二字，那么经典视觉样式就无法正常显示开始按钮了。   5. 改变元素坐标值令 Windows LoGo 及“开始”二字隐藏在屏幕之外。   既然 Windows LoGo 及“开始”二字始终显示在 Windows Pearl 珍珠球之上、又无法将它们删除，那么 Aero、Basic 视觉样式，以及 Se7en Transformation Pack 制作的第三方仿 Aero 视觉样式是如何将它们 隐藏的呢？   原来，这些视觉样式修改了 Windows LoGo 及“开始”二字元素的坐标值，把它们移动到屏幕外面去了。 在这些视觉样式的 TextFile 表中，关于开始按钮的 [Start::Button] Specific 有一行定义 Windows LoGo 及“开始”二字坐标位置的语句 ContentMargins。它定义的横坐标值比 Windows XP 的 Luna 及 Royale 视觉样式定义的横坐标值向左侧偏移了大约 100 多个像素。我们可以想像一下，Windows XP 的开始按钮 原本就已位于屏幕的左下角，如果把开始按钮上的 Windows LoGo 及“开始”二字向左偏移 100 多像素， Windows LoGo 及“开始”二字已经超出了显示器的显示范围。显示器显示不出来的元素，就与隐藏起来 没什么不同了。接下来只要把光秃秃的绿色开始按钮底板图案替换为 Windows Pearl 珍珠球的图案，即可 实现用 Windows Pearl 珍珠球完全取代开始按钮的最终效果。   以上就是 Aero、Basic 视觉样式，以及 Se7en Transformation Pack 制作的第三方仿 Aero 视觉样式将 Windows LoGo 及“开始”二字从开始按钮上隐藏起来的大致原理，再加上一些细节方面的加工，例如 Windows 7/Vista 将“单击这里开始”删减为“开始”，就是我们看到的最终效果。同时，开始按钮上的 Windows LoGo 及“开始”二字也没有真正地消失，当 Windows 使用经典视觉样式时，它们依然可以 被经典视觉样式调用、并显示在正确的坐标位置上，覆盖经典视觉样式的开始按钮底板，组成我们熟悉的 经典样式开始按钮。 发表于 作者 alx-zj | 4 评论 归档在：WindowsXP/Server2003及早期版本的Windows, Windows7/Vista/Server2008 2011年1月31日 23:30

4GB 内存在 64 位 Windows 7 中显示为 3.86GB 可用的案例分析

笔者昨天在微软中文技术论坛见到一则 64 位 Windows 7 将 4GB 物理内存显示为仅 3.86GB 可用的问题： 一台安装有 Windows 7 x64 系统的 Sony EA37EC 笔记本电脑，配备有两条规格完全相同的 2GB 内存。 Windows 7 x64 控制面板的“系统”属性显示“安装内存”为 4.00GB，但加了个括号（3.86GB 可用）。 如果将两条内存拆下一条，“系统”属性则可以显示“安装内存”为 2.00GB，没有出现可用内存容量 与实际容量不符的问题。   笔者看到这则问题后以“3.86GB”、“64 位 Windows 7”为关键字在各大搜索引擎查找了一下，搜到了 不少相同的案例，看来此问题具有一定的普遍性。关于 Windows 7 x64 为何将 4GB 内存显示为 3.86GB 可用的原因，网上也有各种不同的说法，但其中有些明显站不住脚。例如：   1. 硬件保留内存寻址。   Windows 将部分内存保留为硬件寻址空间确实是 Windows 显示可用内存容量与实际容量不符的一个常见 原因。但这个原因只存在于 32 位 Windows 7/Vista/XP，而且 32 位 Windows 7/Vista/XP 的内存容量 上限是 3.25GB。因此，这个说法不正确，64 位 Windows 并不受此影响。   2. 1000/1024 换算误差。   众所周知 Windows 对存储器容量的识别存在一个 1000/1024 的换算误差问题。硬盘、光盘、闪存等各种 存储器在 Windows 中显示的容量都只有设备标称容量的 93% 左右（1000 的三次方除以 1024 的三次方 约等于 93%）。但是，内存却不受此换算误差的影响，内存条是严格按照 1：1024 的设计来计算容量的。 当 Windows 7 x64 计算机只配备 2GB 内存时，并没有出现可用内存容量与实际容量不符的问题。而且， 4GB 容量的 93% 也不是 3.86GB。这都可以说明 1000/1024 换算误差的说法不正确。   3. 在 MSCONFIG.EXE 系统配置实用程序中设置了“最大内存”。   Windows 7/Vista 的 MSCONFIG.EXE 系统配置实用程序在其“引导”选项卡的“高级选项”中提供了 “最大内存”选项，开启此选项会引起可用内存容量与实际容量不符。不过，笔者看到的 Sony EA37EC 笔记本问题与网上搜到的其它 3.86GB 问题都没有开启这个选项。因此，这也不是导致此问题的原因。   4. 集成显卡共享显存。   集成显卡共享显存应该是 Windows 显示可用内存容量与实际容量不符的最常见原因了。但是，Sony EA37EC 笔记本电脑配备的是 ATi Mobility Radeon HD 5470 独立显卡，网上搜到的其它出现 3.86GB 问题的计算机也都采用独立显卡，并不存在集成显卡共享显存的问题。而且，即使真的是集成显卡共享了 显存，为何只有计算机插满 4GB 内存时才会出现 3.86GB 偏差、只插 2GB 内存时却显示正常呢？因此， 这个说法也并不能完全解释 3.86GB 偏差的问题。     后来，笔者发现 Sony EA37EC 笔记本以及网上所有 3.86GB 问题的计算机都是去年推出的新机型，它们 使用的均是 Intel 第二代 Nehalem 酷睿 i5 或 i3 处理器，搭配的是 H55 或 HM55（笔记本）芯片组。 H55 系列芯片组与 P55 最大的差别就是此系列芯片组首次提供了对内建显示核心的第二代 Nehalem 酷睿 处理器的支持，例如 Sony EA37EC 搭配的酷睿 i3 370M。这些新一代的 Nehalem 处理器内建的显示 核心会像集成显卡一样共享显存，它们正是引起 3.86GB 问题的原因。   至于为什么计算机在只插 2GB 内存时 Nehalem 处理器没有共享显存，仅在插满 4GB 内存时才会共享， 笔者也在 Intel 官方网站找到了答案：   The shared memory size is dynamically controlled by VGA driver, and the maximum shared memory size will be available only when more than 4GB physical memory is installed under 64-bit Windows.   在计算机使用独立显卡时，Nehalem 处理器共享的显存仅在物理内存容量不小于 4GB 时才会被激活。 因此当计算机只插 2GB 内存时，不会出现可用内存容量与实际容量不符的问题。 发表于 作者 alx-zj | 9 评论 归档在：Windows7/Vista/Server2008, 微软硬件及其它硬件 2010年12月30日 23:30

Windows 7/Vista 到底需不需要 CTFMON.EXE 常驻内存

CTFMON.EXE 是 Windows 输入法指示器（CTFMonitor），也就是任务栏右下角通知区域的小键盘图标。 在 Windows XP 或早期版本的 Windows 2000/ME/9X 中（这些早期系统必须安装 Office XP 或以上版本 才具有 CTFMON.EXE），CTFMON.EXE 是通过在注册表项：   HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run   添加命令，以启动加载项的形式随 Windows 的运行一同加载的。每次启动 Windows 后，我们都可以看到 CTFMON.EXE 进程常驻于内存。而从 Windows Vista 开始，Windows 不再以注册表项的形式加载输入法 指示器。在 Windows 7/Vista 的默认系统设置中，我们应该也看不到 CTFMON.EXE 进程常驻于内存了。   在微软中文技术论坛中曾经有很多人问过 Windows 7/Vista 的输入法指示器消失不见、在任务栏通知区域 看不到小键盘图标的问题，不少人给出的建议解答就是在上述注册表中手动添加 CTFMON.EXE，这个方法 也确实可以解决问题。可是，Windows 7/Vista 的默认系统设置是如何实现不通过注册表项自动加载输入法 指示器的呢？Windows 7/Vista 到底需不需要 CTFMON.EXE 常驻内存呢？   原来，Windows 7/Vista 加载输入法指示器的默认设置不是通过注册表、而是通过任务计划。我们可以在 Windows 7/Vista 中运行命令：   %SystemRoot%\system32\TASKSCHD.MSC   在 MMC 控制台中启动任务计划，并在主菜单的“查看”中选中“显示隐藏的任务”复选框。接着我们依次 展开“任务计划程序库”－“Microsoft”－“Windows”－“TextServicesFramework”，在这里便可以 看到隐藏的任务 MsCTFMonitor，其触发对象是“任何登录的用户”。这就是 Windows 7/Vista 用以取代 注册表项加载输入法指示器的方法。   因此，通过注册表项手动添加 CTFMON.EXE 的方法虽然依旧可行，但我们说，Windows 7/Vista 已经不再 需要 CTFMON.EXE 常驻于内存了。如果 Windows 7/Vista 遇到了输入法指示器消失、看不到小键盘图标 停靠于任务栏通知区域的问题，我们可以从如下三个方面检查：   1. 检查 TextServicesFramework 中的隐藏任务 MsCTFMonitor 是否被禁用或删除。   如果此任务被禁用，或者其触发对象由“任何登录的用户”被修改为特定帐户，我们可以将任务重新启用并 设置其触发对象为“任何登录的用户”；如果此任务被删除，我们可以从其它 Windows 7/Vista 计算机中 将此任务导出为 .XML 文件，复制到有问题的计算机中重新导入至 TextServicesFramework 任务列表。   2. 确认在输入法列表中添加有两种或两种以上的输入法。   如果输入法列表仅有一种输入法，输入法指示器就失去了存在的意义，因此我们需要添加两种或两种以上的 输入法。在默认的系统设置中，我们应该至少添加有“中文（简体）－美式键盘”及“微软拼音输入法”。   3. 确认将语言栏设置为停靠于任务栏。   我们在控制面板中打开“区域与语言选项”，切换至“语言栏”选项卡，在这里可以选择将语言栏设置为 “隐藏”、“悬浮于桌面”或“停靠于任务栏”。如果我们希望输入法指示器的小键盘图标常驻于任务栏 通知区域，应该选择“停靠于任务栏”。   只要上述三个地方设置正确，我们即可保证 Windows 7/Vista 始终在任务栏通知区域显示输入法指示器的 小键盘图标，而无需在注册表中手动添加 CTFMON.EXE。Windows 7/Vista 也完全不需要 CTFMON.EXE 常驻内存了。 发表于 作者 alx-zj | 10 评论 归档在：Windows7/Vista/Server2008 2010年12月1日 4:40

设置大小合适的 Windows 7 休眠文件 Hiberfil.SYS

Hiberfil.SYS 是 Windows 休眠功能（Windows Hibernation）将内存数据与会话保存至硬盘、以便计算机 断电重新启动后可以快速恢复会话所需的内存镜像文件。在早期版本的 Windows 中，Hiberfil.SYS 文件的 大小等同于物理内存大小；而在 Windows 7 中，Hiberfil.SYS 可以在物理内存大小的 50%－100% 的范围 自行调整。因此， Windows 7 的 Hiberfil.SYS 大小不一定等同于物理内存大小。


Windows 7 之所以出现这种改变，主要是出于节省系统分区的硬盘空间考虑。因为 Hiberfil.SYS 必须位于 系统分区的根目录，我们无法修改其文件名及所在位置。

曾经有人在微软中文技术论坛中问过，为什么无法将 Hiberfil.SYS 由系统分区根目录转移至其它位置，这是 由于 Windows 要想在硬盘的其它位置读取启动文件，必须首先加载文件系统驱动程序。但是已经转入休眠 状态的 Windows，其文件系统驱动程序在 Hiberfil.SYS 里。不加载文件系统驱动，Windows 就无法读取 Hiberfil.SYS；不读取 Hiberfil.SYS，Windows 就无法加载文件系统驱动。这好比黄宏在春晚小品中表演的 那个情节一样：林永健不打开箱子，黄宏就取不出身份证明；但黄宏不出示证件，林永健就无权打开箱子。 为了解决这个矛盾，Windows 唯有在读取 Hiberfil.SYS 之前加载一个小型的文件系统驱动程序，但是这个 小型的驱动程序只能访问系统分区根目录中包括 Hiberfil.SYS 在内的有限的若干系统文件。这就是为什么 Hiberfil.SYS 无法由系统分区根目录转移至其它位置的原因。

无法修改 Hiberfil.SYS 的所在位置是 Windows 7 减小 Hiberfil.SYS 的原因之一；提高 Hiberfil.SYS 的文件 利用率是减小 Hiberfil.SYS 的另一个原因。随着计算机物理内存容量越来越大，多数计算机都有相当一部分 物理内存处于空闲状态，并非每次休眠都有完全等同于物理内存容量的内存数据需要保存为 Hiberfil.SYS。 在早期版本的 Windows 中，尽管 Hiberfil.SYS 的大小始终等同于物理内存大小，但 Windows 每次休眠时 也并没有从头到脚地更新 Hiberfil.SYS 的所有内容。换言之，早期版本的 Windows 的 Hiberfil.SYS 存在着 没有充分利用的浪费的空间。

基于以上两个原因，为了节省系统分区的硬盘空间，Windows 7 在计算机转入休眠之前，可以将内存数据 进行 0－50% 比率的压缩，从而将 Hiberfil.SYS 减小为物理内存大小的 50%－100%。这个百分比可以通过 POWERCFG 命令配合 -H -SIZE 参数进行设置。

例如，在物理内存容量 2GB 的 Windows 7 计算机中，如果以管理员权限执行命令：

POWERCFG -H -SIZE 70

即可将这台计算机的 C:\Hiberfil.SYS 减小为 2GB 的 70%，即 1.4GB。


在默认的系统设置中，Windows 7 使用物理内存容量的 75% 做为 Hiberfil.SYS 默认的文件大小，这是 Windows 开发团队在评估了大多数计算机的物理内存容量与内存空间占用后设置的平衡值。百分比设置得 太大，容易造成系统分区空间浪费；百分比设置得太小，也可能因为 Hiberfil.SYS 空间不足引起休眠失败。 如果我们在 Windows 7 中执行休眠时遇到如下故障代码的蓝屏，即表明当前 Hiberfil.SYS 设置得太小了：

STOP：0x000000A0 INTERNAL_POWER_ERROR
参数 1
参数 2
参数 3

（参数 1 始终为 0x0000000B、参数 2 是 Hiberfil.SYS 大小的字节数、 参数 3 是无法被压缩并写入 Hiberfil.SYS 的剩余的内存数据字节数）

此时，我们必须放弃失败的休眠，以正常模式重新启动 Windows 7，然后重新设置 Hiberfil.SYS 的大小。


总之，我们在 Windows 7 中可以根据自己计算机的实际情况，通过 POWERCFG -H -SIZE 设置合适的 Hiberfil.SYS 大小。如果计算机内存容量不大或硬盘容量很大，不在乎几百 MB 至 1GB 的空间 开销，我们可以将 Hiberfil.SYS 设置为物理内存容量的 100%，这样 Windows 7 可以省去压缩内存数据的 步骤；如果计算机内存容量很大或系统分区可用空间非常紧张，可以将 Hiberfil.SYS 设置为更小的物理内存 容量百分比，但要小心 Hiberfil.SYS 设置得太小可能会存在休眠失败的风险。对于大部分的普通用户而言， 如果我们不确定应该如何设置 Hiberfil.SYS 的大小，保持 Windows 7 默认设置的 Hiberfil.SYS 文件大小 为物理内存容量的 75% 即可。  发表于 作者 alx-zj | 6 评论 归档在：Windows7/Vista/Server2008 2010年11月20日 21:00

为 Debugging Tools 设置 symbol 路径以提高分析 Windows 蓝屏故障的准确性

笔者以前曾经撰写过博文《蓝屏死机不用愁 －借助 Debugging Tools 分析蓝屏故障原因》以及 《易宝典 KB972602 －Windows 常见蓝屏故障分析》，介绍了如何在 Windows 中设置自动保存 Crash Dump File，以便在遇到蓝屏故障时使用 Debugging Tools 分析故障原因的方法。   然而，有时当我们使用 Dubugging Tools 分析 Crash Dump 时，可能会遇到分析结果不准确或 没有什么参考价值信息的情况，这可能是由于 Debugging Tools 没有设置合适的 symbol 路径所致。   具有软件开发经验的朋友应该知道 symbol 符号文件对于软件调试的重要性。symbol 包含多种在实际运行 相关的二进制文件（.EXE、.DLL）时可能不需要、但在调试过程中非常有用的参考数据。为 Debugging Tools 设置合适的 symbol 可以在分析 Crash Dump 时获得更为准确的参考信息。我们可以选择手动下载 或在线获取的方式为 Debugging Tools 设置合适的 symbol。   ★ 手动下载 symbol   微软官方网站为我们提供了 symbol 下载页面：   http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx   在下载 symbol 之前首先要选择正确的 Windows 版本（Windows 7、Windows Vista、Windows XP、 Windows Server 2008 R2、Windows Server 2008、Windows Server 2003、Windows 2000）及具体 Service Pack 版本，不同的 Windows 及 Service Pack 版本使用的 symbol 是不同的，高版本对于低版本 并不是累积的关系。然后我们需要选择下载 symbol 的 retail 还是 checked 版本。多数情况下选择 retail 即可，只有在调试具有附加信息的特殊版本的 Windows 时才需要选择 checked。   下载完毕后运行安装程序，将 symbol 解压缩至一个文件夹（例如 C:\Windows\symbols），然后运行 Debugging Tools，在主菜单中打开 File（文件）－Symbol File Path（符号文件路径），将路径设置为 symbol 解压缩的文件夹位置即可。或者，我们可以在控制面板的“系统”属性中设置环境变量，新建一条 名为 _NT_SYMBOL_PATH 的用户变量，然后将其值设置为 symbol 解压缩的文件夹位置，也可以令 Dubugging Tools 自动在指定的文件夹搜索 symbol。   ★ 在线获取 symbol   手动下载的 symbol 虽然数据量比较齐全，但也会消耗不少硬盘空间。我们还可以通过微软官方提供的 Symbol Server 在线获取并随时更新 symbol：   http://msdl.microsoft.com/download/symbols
（这个页面供 Debugging Tools 在线获取 symbol，单独访问无效）   我们运行 Debugging Tools，在主菜单中打开 File（文件）－Symbol File Path（符号文件路径）， 将路径设置为：   SRV*C:\Windows\symbols*http://msdl.microsoft.com/download/symbols   这样，Debugging Tools 就会首先试图从 C:\Windows\symbols 文件夹搜索 symbol（这个文件夹的位置 可以随意自行修改）。如果文件夹不存在，Debugging Tools 将自行建立文件夹，并把它做为在线获取 symbol 的本地保存路径，然后联机从 http://msdl.microsoft.com/download/symbols 搜索合适的 symbol，并将其下载到 C:\Windows\symbols 文件夹供 Debugging Tools 使用。随着使用次数增多， 如果 C:\Windows\symbols 文件夹已经存在、且已经含有已安装或已下载的 symbol，Debugging Tools 以后即可在联机时自动更新其内容。   如果我们没有手动下载过任何 symbol，只为 Debugging Tools 设置了一个空文件夹做为 symbol 路径， 那么当 Debugging Tools 第一次从 http://msdl.microsoft.com/download/symbols 搜索并下载所需的 symbol 时可能需要一些时间。随着使用次数以及联机更新次数的增加，Debugging Tools 加载 symbol 以及分析 Crash Dump 的速度会逐渐加快。而且，在线下载更新 symbol 的方式也会比手动下载 symbol 节省不少硬盘空间。 发表于 作者 alx-zj | 2 评论 归档在：WindowsXP/Server2003及早期版本的Windows, Windows7/Vista/Server2008 2010年10月24日 2:40

如何改变 IE for Windows 7 点击 Office 文档链接时的打开方式

笔者上周在微软中文技术论坛里见到有人提起这样一个问题：当我们在 Windows 7 的 IE 中点击一个指向 Office 文档的链接，IE for Windows 7 将询问用户希望下载保存还是在线打开这个文档。假如用户不希望 IE 弹出此对话框、而是由 IE 浏览器直接打开 Office 文档，应该如何实现呢？（此问题 10 月 15 日见于 微软中文技术论坛 CnPartner 在线合作伙伴 Windows Client 讨论组）

这个问题看似简单，但在 Windows 7 中实现起来却稍显麻烦。假如我们在 Windows XP 或早期版本的 Windows 中遇到这个问题，我们可能会想到在控制面板中打开“文件夹选项”－“文件关联”，为指定的 Office 文档设置“高级”选项，取消“下载前确认打开”复选框。但是 Windows 7/Vista 为了方便菜鸟的 使用，已经用一个更加傻瓜化的“将文件或协议与特定程序关联”取代了“文件关联”，不再提供“下载前 确认打开”选项了。如果我们需要在 Windows 7 中实现同样的设置，只能靠手动修改注册表来实现。

以 .DOCX 格式文档为例，“下载后确认打开”的设置对应注册表 HKEY_CLASSES_ROOT\docxfile 的 DWORD 值 EditFlags。在 Windows XP 的“文件关联”工具中，如果“下载后确认打开”是勾选状态， EditFlags 的 DWORD 值为 0；如果“下载后确认打开”是未勾选状态，EditFlags 的 DWORD 值为 0x10000。Windows 7 也具有相同的注册表项定义。假如我们在 Windows 7 的 HKEY_CLASSES_ROOT\ docxfile 中手动添加 DWORD 值 EditFlags 并设置为 0x10000，就相当于间接地为 .DOCX 文档设置了 “下载后确认打开”。

经过上述修改后，当 IE for Windows 7 再次打开指向 Office 文档的链接时，便不再弹出询问下载还是 打开文档的对话框了。但是 IE for Windows 7 也没有直接打开 Office 文档，而是先将其下载至 Internet 临时文件夹，然后单独启动一个 Word 窗口打开文档，还是没有实现用户希望的“像早期版本的 Windows 那样由 IE 直接打开 Office 文档”的要求。这又是怎么回事呢？

原来，这种现象是 Office 2007 设计使然，Office 2010 及 Office 2003 的文档不受影响。根据微软知识库 文章 KB927009 提供的资料，由于 Office 文档直接在 IE 中打开会引起部分编辑功能不可用，所以 Office 2007 有意为 Office 文档设置了 BrowserFlags 注册表值，强制文档在 Office 程序中、而不是 IE 中打开。

如果要取消 Office 2007 的这种设置，我们需要手动在注册表的 HKEY_CLASSES_ROOT 中查找相应格式的 Office 文档，将其 BrowserFlags 的值修改为 DWORD:80000024。以 Office 2007 的 .DOCX 文档为例， 它在 HKEY_CLASSES_ROOT 中对应的注册表项为 Word.Document.12，其中 .12 表示 Office 12、也即 Office 2007。修改之后，在安装有 Office 2007 的 Windows 7 中用 IE 打开指向 .DOCX 文档的链接时， 就可以直接用 IE 打开文档了。

Windows XP 及早期版本的 Windows 通过“文件关联”工具修改这个设置比 Windows 7 方便，我们只需 在“文件关联”工具中为指定的 Office 文档设置“高级”选项，并勾选“在同一窗口中浏览”复选框即可。 这个选项即相当于在注册表中为指定的 Office 文档取消了 BrowserFlags。


由于 Windows 7/Vista 提供的“将文件或协议与特定程序关联”工具过于傻瓜化、功能非常简单，所以在 Windows 7 中处理类似的问题时反而不如 Windows XP 的“文件关联”工具使用方便。来自第三方的绿色 工具软件 FileTypesMan 可以弥补 Windows 7 在这个方面的不足，我们可以从如下链接免费下载（此工具 区分 x86、x64 版）：

http://www.askvg.com/filetypesman-free-alternative-to-windows-default-file-type-option
FileTypesMan 提供了类似于 Windows XP 的“文件关联”工具的功能，我们可以使用它为指定的文件关联 设置“Open this file type immediately after download, without confirmation”与“Don't open inside a Web browser window”选项，它们即相当于 Windows XP 的“文件关联”工具中的“（不要） 下载后确认打开”与“（不要）在同一窗口中浏览”选项。


笔者希望 Windows 的后续版本能恢复 Windows XP 的“文件关联”工具，因为 Windows 7 的“将文件 或协议与特定程序关联”实在过于傻瓜化、已经“傻”到有些不实用了，它只适合面向普通菜鸟用户的 Windows 家庭版。Windows 专业版、旗舰版等高级版本还是提供功能强一些的“文件关联”工具比较好。 发表于 作者 alx-zj | 2 评论 归档在：Windows7/Vista/Server2008 2010年9月20日 20:00

如何为 Windows Client 在 MMC 控制台中添加远程桌面

笔者上周在微软中文技术论坛里见到有人提起如何在 Windows Client 桌面操作系统的 MMC 控制台中 添加远程桌面的问题，在此进行一下小结。   当我们在 Windows Client 的 MMC 控制台中选择“添加管理单元”，无法像 Windows Server 那样找到 远程桌面管理单元，这是所有 Windows Client（Windows 7/Vista/XP）的设计使然。 （此问题 9 月 15 日见于微软中文技术论坛 Windows 7 讨论组）   如需在 MMC 控制台中手动添加远程桌面管理单元，我们可以按照如下步骤操作：     ★ 适用于 Windows 7、Windows Vista   1. 下载安装远程服务器管理工具：   http://www.microsoft.com/downloads/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d&displayLang=zh-cn   （适用于 Windows 7）   http://www.microsoft.com/downloads/details.aspx?FamilyID=9ff6e897-23ce-4a36-b7fc-d52065de9960&displayLang=zh-cn   （适用于 Windows Vista SP1 或 SP2）   2. 通过控制面板中的“程序与功能”－“打开或关闭 Windows 功能”－“远程服务器管理工具”－ “角色管理工具”，勾选添加“远程桌面服务工具”；   3. 重新运行 MMC 控制台，添加管理单元并选择远程桌面。     ★ 适用于 Windows XP   1. 下载安装 Windows Server 2003 管理工具软件包（Administration Tools Pack）：   http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c16ae515-c8f4-47ef-a1e4-a8dcbacff8e3&displaylang=en   2. 提取 Windows Server 2003 的系统文件     Windows\system32\MSTSMMC.DLL、Windows\system32\MSTSMHST.DLL；   3. 通过故障恢复控制台将这两个文件复制到 Windows XP 的 Windows\system32，替换原文件，这将破坏 Windows XP 系统文件完整性，最好选择发布日期及版本号不低于当前 Windows XP 版本号的 Windows Server 2003 文件；   4. 重新启动 Windows XP，确认 MSTSMMC.DLL 与 MSTSMHST.DLL 已经被替换，然后使用 REGSVR32 命令重新注册一下这两个文件。   5. 重新运行 MMC 控制台，添加管理单元并选择远程桌面。 发表于 作者 alx-zj | 2 评论 归档在：WindowsXP/Server2003及早期版本的Windows, Windows7/Vista/Server2008 2010年9月16日 15:30

IE 9、IE 8 for Windows Vista 的连环卸载

微软于 3 月 14 日如期发布了 Windows Internet Explorer 9（以下简称 IE 9）正式版，支持 x86、x64 的 Windows 7、Windows Vista 或 Windows Server 2008（R2）。相比以往历代版本，IE 9 的宣传声势及 发布速度均有明显超越，并提供了将近三十种不同的语言版本。   笔者在 2008 年 IE 8 Beta 发布时曾写过一篇《IE 8、IE 7 for Windows XP/Server 2003 的连环卸载》， 分析了在 Windows XP/Server 2003 中卸载 IE 8 时可能遇到的几种情况。因为对于内置 IE 6 的 Windows XP/Server 2003 而言，IE 8、IE 7 均属于独立安装的版本，所以三者之间存在一个连环卸载的问题。   随着 IE 9 的逐渐成形，Windows Vista 也将涉及到 IE 9、IE 8 及其内置的 IE 7 三者之间的连环卸载。 Windows 7 由于本身内置 IE 8、只有 IE 9 这一个独立安装版本，所以在 IE 10 面世之前，它暂不涉及 连环卸载的问题。   IE 9 的早期平台预览版要求 Windows Vista 必须首先安装有 IE 8 才可以安装，不能直接从 IE 7 升级。 这是由于 IE 9 预览版还不具备完整 UI 界面，需要 IE 8 的一些框架进行辅助。而 IE 9 Beta 及后续的版本 已经具有自己的 UI 框架，不再需要 IE 8 进行“借尸还魂”了，因此 Windows Vista 可以在其内置的 IE 7 环境中直接升级安装至 IE 9，就像 Windows XP/Server 2003 既可以首先安装 IE 7 再安装 IE 8、也可以 从 IE 6 直接升级至 IE 8 一样。    于是，在 Windows Vista 中安装 IE 9 后，如果需要卸载 IE 9，可能会遇到如下情况：     ★ 如果以前未安装过 IE 8，IE 9 从 IE 7 直接升级而来：

在 Windows Vista 中安装 IE 9 后，控制面板中的“打开或关闭 Windows 功能”－“已安装的更新”列表 会显示 IE 9 的卸载选项，执行此卸载可以自动回滚至安装 IE 9 之前的 IE 7。   但是，这个 IE 9 的卸载选项不能回滚至 IE 8，因为我们此前没有安装过 IE 8。IE 8 在已安装 IE 9 的情况下 也不能直接安装。因此如果我们希望回滚至 IE 8，只能首先卸载 IE 9、恢复 IE 7，然后再重新安装 IE 8。
   ★ 如果以前安装过 IE 8，IE 9 从 IE 8 升级而来：   如果以前曾经为 Windows Vista 安装过 IE 8，那么在“已安装的更新”列表中原本就应有一个 IE 8 的卸载 选项。在此基础上安装 IE 9 后，“已安装的更新”列表会同时显示 IE 8 与 IE 9 两个卸载选项。这一点与 Windows XP/Server 2003 有所不同。   在 Windows XP/Server 2003 中，如果我们在 IE 6 的基础上首先安装 IE 7、然后再继续安装 IE 8，控制 面板的“添加删除程序”列表不会同时显示 IE 7 与 IE 8，只会显示卸载 IE 8 一个选项。执行此卸载将回滚 至 IE 7，此时才会出现 IE 7 的卸载选项，再次执行卸载才可以进一步回滚至 IE 6。换言之，曾经安装过  IE 7 的 Windows XP/Server 2003 不能从 IE 8 直接回滚至 IE 6，必须按照顺序分两次执行。   而在 Windows Vista 中，我们可以在“已安装的更新”列表中同时看到 IE 8 与 IE 9 两个卸载选项，而且 这两个选项都可以点击执行，这样就又分为两种情况：   1. 如果我们点击 IE 9 的卸载选项，执行此卸载可以自动回滚至安装 IE 9 之前的 IE 8，且回滚至 IE 8 后， 还可以接续执行 IE 8 的卸载，恢复安装 IE 8 之前的 IE 7。这一系列操作类似 Windows XP/Server 2003 从 IE 8 至 IE 6 的两次卸载。   2. 如果我们点击 IE 8 的卸载选项，执行此卸载可以将 Windows Vista 此前保存的与 IE 8 相关的卸载信息 删除，但不会影响到已安装的版本更高的 IE 9。重新启动 Windows 后，我们可以看到 IE 浏览器版本依然 是 IE 9，但“已安装的更新”列表中不再有 IE 8 的选项了。此时即使再卸载 IE 9，也无法回滚至 IE 8 了， 而是回滚至 Windows Vista 内置的 IE 7。   总之，如果我们在 Windows Vista 中首先安装 IE 8 再安装 IE 9，在执行连环卸载时，并不能从 IE 9 一步 回滚至 IE 7，依然必须分两次执行。只不过 Windows Vista 将 IE 8 与 IE 9 的两个卸载选项同时显示在 “已安装的更新”列表中，使我们有两种不同的执行顺序而已。但无论选择哪个顺序，也都必须执行两次 卸载、重新启动 Windows 两次才能回滚至 IE 7。因此，IE 9、IE 8 for Windows Vista 的连环卸载， 步骤依然像 IE 8、IE 7 for Windows XP/Server 2003 一样繁琐。 发表于 作者 alx-zj | 4 评论 归档在：Windows7/Vista/Server2008, 网络（IE/Mail/Messenger等）应用技巧 2010年8月25日 11:20

格式转换引起的 Windows 7 桌面墙纸显示模糊问题分析

首先纪念一下经典的 Windows 95 问世十五周年。    言归正传，笔者曾经在多台 Windows 7 计算机（包括虚拟机）中遇到过桌面墙纸显示模糊的问题：当我们 把一张自定义的 .BMP 位图设置为 Windows 7 桌面墙纸后，即使这张墙纸在预览窗口中看起来一切正常， 但当我们返回桌面，却发现实际的墙纸显示效果非常模糊，看起来仿佛失真了一样；而在使用 Windows 7 本身自带的桌面主题提供的墙纸时却没有问题。   起初，笔者认为这个问题可能是自定义的 .BMP 位图规格有毛病，无法在 Windows 7 中正常显示。但后来 笔者发现即使是那些使用 Windows 7 图片查看器查看时一切正常的位图，设置为墙纸也会变模糊。而且， 哪怕是同样的一张位图，在 Windows XP/Vista 中设置为墙纸就很清晰，惟独在 Windows 7 中设置为墙纸 会变模糊。   之后，笔者又想到墙纸显示模糊是否与 Windows 7 设置墙纸时的“拉伸”“平铺”显示方式有关，但笔者 发现即使用一张与 Windows 7 桌面分辨率一致的同尺寸位图，以“居中”的方式显示，设置为墙纸后依然 也会变模糊。   在检查过位图本身及墙纸显示方式后依然找不到原因，笔者认为这个问题唯一的解释是 Windows 7 并没有 直接使用我们指定的 .BMP 位图做墙纸，而是使用了一张失真的缓存图。为了验证此想法，笔者在墙纸显示 模糊的 Windows 7 中打开注册表编辑器，检查了注册表项：   HKEY_CURRENT_USER\Control Panel\Desktop 中的字符串值 Wallpaper   发现这个注册表项的值果然不是我们指定的 .BMP 位图的名称及路径，而是：   C:\Users\%用户帐户名%\AppData\Roaming\Microsoft\Windows\Themes\ TranscodedWallpaper.JPG   笔者用资源管理器找到此位置，打开 TranscodedWallpaper.JPG，发现它果然是与我们设置的 .BMP 位图 内容相同，但图像质量不佳、显示失真的图片。   TranscodedWallpaper.JPG 的最后修改时间与我们设置 .BMP 位图为桌面墙纸时的时间吻合。也就是说， 当我们指定 .BMP 位图后，Windows 7 并没有直接将其设置为墙纸，而是先对其进行了格式转换，生成 TranscodedWallpaper.JPG，再将转换之后的 TranscodedWallpaper.JPG 设置为墙纸。墙纸之所以显示 模糊，是因为 Windows 7 转换图像格式水平不佳，TranscodedWallpaper.JPG 采用的压缩比过大，无法 完整地重现 .BMP 位图的高质量，这就是为什么只有墙纸显示模糊，但用图片查看器查看 .BMP 原图时依然 清晰的原因。   了解问题的起因后，解决 Windows 7 桌面墙纸显示模糊就很容易了，有两种做法：   1. 将注册表项 HKEY_CURRENT_USER\Control Panel\Desktop 中的字符串值 Wallpaper 由 TranscodedWallpaper.JPG 重新修改为 .BMP 位图的名称及路径；   2. 使用一款效果更好的第三方图像处理软件，在保证图像质量的前提下将 .BMP 位图转换为 TranscodedWallpaper.JPG，或者干脆将 .BMP 位图直接重命名为 TranscodedWallpaper.JPG， 然后替换 Windows 7 自行转换的 TranscodedWallpaper.JPG 即可。   两种方法都可以令 Windows 7 桌面墙纸恢复 .BMP 位图应有的高图像质量。 发表于 作者 alx-zj | 1 评论 归档在：Windows7/Vista/Server2008 2010年8月18日 17:40

修改注册表令 Windows XP SP2 强制安装 7.13 大限以后的安全更新实属伪技巧

微软于 2010 年 7 月 13 日正式终止了 Windows 2000、Windows XP SP2 的扩展技术支持。 八月份最新发布的安全公告说到做到，所有 Windows XP 安全更新的下载链接均标明了更新 仅适用于 Windows XP SP3 的字样，其中包括前段时间热议的快捷方式漏洞更新 KB2286198。

由于 Windows XP SP2 未能赶上八月的更新末班车，错过了包括 KB2286198 在内的好几个 重要更新，所以很多依然使用 Windows XP SP2 的人在想能不能用一些旁门左道的方法为 Windows XP SP2 修补这些漏洞。笔者日前就在网上看到这样一则消息：


芬兰反病毒开发商 F-Secure 顾问 Sean Sullivan 建议 Windows XP SP2 用户可以将注册表项：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows

里面的 DWORD 值 CSDVersion 由 512 修改为 768。重新启动之后即可安装包括 KB2286198 在内的所有 7.13 大限之后的安全更新。


这则技巧是不是真的可以解决问题呢？笔者认为，这只不过是一条自欺欺人、多此一举的伪技巧。

首先，CSDVersion 只是一条表面上记录 Windows Service Pack 版本信息的注册表项。十进制的 512、768 换算为十六进制是 200、300，也就是代表当前 Service Pack 版本是 SP2 还是 SP3。 只要我们乐意的话，完全可以将 CSDVersion 设置为 1024、1280 甚至 2304，将 Service Pack 版本修改为不存在的 SP4、SP5、SP6 甚至 SP9。因此，即使我们将 Windows XP SP2 系统的 CSDVersion 修改为 768、将显示的版本信息修改为 SP3，也只是一种自欺欺人的做法，操作系统 本身依旧是 Windows XP SP2。

其次，有的人可能会说：我不管 Windows XP 到底是真的 SP3 还是由 SP2 冒充的 SP3，只要 CSDVersion 能够骗过安装程序、能够安装那些 7.13 大限之后的更新程序不就行了吗？的确， 虽然安装程序仅仅根据 CSDVersion 的数值判断当前系统是 SP2 还是 SP3，将 CSDVersion 修改为 768 的确可以骗过安装程序执行安装。但是，这并不代表这些安装程序提供了适用于 SP2 的正确的系统文件。

我们可以随便找一个在 7.13 大限之前发布的、可以同时支持 SP2 与 SP3 的 Windows XP 更新 程序，与 7.13 大限之后发布的更新程序进行一下对比。在此笔者以 2010 年 6 月发布的 KB979559 与 2010 年 8 月发布的 KB2160329 为例。这两个更新修复的是同一漏洞，前者目前 已经被后者取代。但前者的发布时间早于 7.13 大限，可以同时支持 SP2 与 SP3；而后者则晚于 7.13 大限，仅支持 SP3。

我们在 Windows XP 中开始安装 KB979559，安装程序会自动在可用空间最大的硬盘分区中建立 一个名称随机的临时文件夹，里面含有 SP2GDR、SP2QFE、SP3GDR、SP3QFE 四个子文件夹， 每个子文件夹均包含适用于 SP2 或 SP3 的、对应 GDR 或 QFE 的新版的系统文件。至于这四个 子文件夹中的哪一个会被安装程序采用并应用于系统，这是由 Windows XP 的 Service Pack 版本 及具体配置决定的。   （笔者注：有关 GDR 与 QFE 的概念与区别，可以参考笔者早前所写的博文 《简介 Windows 系统更新 GDR 与 QFE 的区别》。）

接下来，我们取消 KB979559 的安装、开始安装 KB2160329，安装程序也会自动在可用空间最大的 磁盘分区建立一个名称随机的临时文件夹，但这一次这个临时文件夹就只包含 SP3GDR、SP3QFE 两个子文件夹、并且只提供适用于 SP3 的 GDR 与 QFE 文件了。换言之，KB2160329，以及所有 7.13 大限之后发布的 Windows XP 更新，都已不再提供任何适用于 SP2 的 GDR 或 QFE 文件了。

假如我们把 Windows XP SP2 系统的 CSDVersion 修改为 768 并安装 7.13 大限之后发布的更新， 虽然安装过程表面上看起来没什么问题，但安装程序实际只是把来自 SP3GDR 或 SP3QFE 的文件 更新在了 Windows XP SP2 系统中而已。这种由新旧不同版本的文件混合组建的系统稳定性是可想 而知的，在没有官方严格测试的前提下不受微软的正式支持，而且今后在执行 SFC /SCANNOW 检测系统文件完整性时也会遇到版本混乱的问题。   最可笑的一点是，即使我们不在乎系统稳定性、坚持用来自 SP3GDR 或 SP3QFE 的系统文件更新 Windows XP SP2 系统，只要把相应的系统文件从 SP3GDR 或 SP3QFE 中提取出来，通过故障恢复 控制台手动替换至 Windows\system32 即可，根本没必要又是修改注册表、又是欺骗安装程序的， 这两种做法本质上干的都是同一勾当。修改注册表欺骗安装程序，完全是多此一举。     由于微软在 7.13 大限之后已经停止了对 Windows XP SP2 的支持，所以说来说去，Windows XP SP2 用户最好的做法还是安装 SP3，以便继续保持系统安全更新至 2014 年 4 月。笔者个人并不 盲目地支持所有用户都升级至 Windows 7/Vista，因为对于那些不得不使用旧电脑或旧版应用程序的 用户而言，Windows 7/Vista 未必会比 Windows XP 表现得更好。但是，如果仅对 Windows XP 用户 而言，却没有什么理由不升级至 SP3。诸如本文提到的此类伪技巧，是完全不可取的。 发表于 作者 alx-zj | 4 评论 归档在：WindowsXP/Server2003及早期版本的Windows 2010年8月1日 18:40

Fixit 50486 究竟 Fix 了什么

最近很多用户在微软中文技术论坛问起 Windows 快捷方式为何显示未知图标的问题，即桌面、开始菜单、 快速启动工具栏中的 .LNK 及 .PIF 快捷方式突然变成了白色的未知类型的图标，很多用户误以为系统受到了 恶意程序的攻击，或者 Windows 图标缓存出现了问题。实际上，这只是用户安装了预防 Windows Shell 快捷方式漏洞的 Fixit 50486 工具所致：   http://go.microsoft.com/?linkid=9738980   根据微软近期发布的安全公告 KB2286198，几乎所有主流版本 Windows 均存在一个 Windows Shell 快捷 方式漏洞，恶意代码可能会在 Windows 解析并显示某些特定快捷方式的图标时被执行。截止到八月一日， 微软尚未发布针对此漏洞的安全更新。将快捷方式图标修改为未知类型的 Fixit 50486 工具只是在安全更新 发布之前的一种临时解决方案而已。   当我们在 Windows 中安装 Fixit 50486 时，此工具会将注册表项 HKEY_CLASSES_ROOT\lnkfile\shellex\ IconHandler 与 HKEY_CLASSES_ROOT\piffile\shellex\IconHandler 的默认值 {00021401-0000-0000 -C000-000000000046} 删掉（即改为空白）。重新启动 Windows 后，.LNK 文件与 .PIF 文件的图标就将 变为白色的未知图标。手动删除删除上述两个注册表项的默认值即相当于运行了 Fixit 50486。   如需解除 Fixit 50486 所做的修改， 只要将上述两个注册表项的默认值还原为 {00021401-0000-0000-C000-000000000046} 即可。   与 Fixit 50486 同时发布的 Fixit 50487：   http://go.microsoft.com/?linkid=9738981   就是为解除 Fixit 50486 所做的修改而设的。Fixit 50487 可以看作 Fixit 50486 的卸载工具，或者我们可以 对照其它计算机手动还原注册表项。   此外，由于 Windows Shell 快捷方式漏洞不仅会通过本地存储设备、而且也会通过 WebDAV （Web Distributed Authoring and Versioning）对系统产生影响，所以 KB2286198 安全公告 同时建议我们暂时禁用系统服务 WebClient。待过几天安装了针对 Windows Shell 快捷方式漏洞的 安全更新后再启用服务。 
Alexis Zhang's Blog 1 Alexis Zhang's Blog 3 Alexis Zhang's Blog 4 Alexis Zhang's Blog 5 Alexis Zhang's Blog 6 Alexis Zhang's Blog 7 Alexis Zhang's Blog 8 Alexis Zhang's Blog 9 Alexis Zhang's Blog 10 zhang zhang Discovery--Nicholas‘s Blog No.1 佛往今来(liuyq502'S Blog) Oliver Yang's blog Alex yu's Blog Bo’s Blog 邵博客 allaboutU’s blog ? Blog Archive ? <长长见识> 清宫有关... 统计整数二进制表示中1的个数 - Crane's Blog 婚礼倒记时的计划书1（转） - fisker‘s blog 我的博客(戒定慧空'S Blog) 君合(君合'S Blog) 街头骗术大全 --Nicholas‘s Blog 风险投资行业概述 - lyle‘s venture blog 涅瓦河边----------萨沙's Blog