分类： Win故知新

原文链接：https://devblogs.microsoft.com/oldnewthing/20050816-08/?p=34563

Probably the single greatest source of bluescreen crashes in Windows XP is buggy device drivers. Since drivers run in kernel mode, there is no higher authority checking what they’re doing. If some user-mode code runs amok and corrupts memory, it’s just corrupting its own memory. The process eventually crashes, but the system stays up. On the other hand, if a driver runs amok and corrupts memory, it’s corrupting your system and eventually your machine dies.

Windows XP 蓝屏崩溃的最大原因之一是有问题的设备驱动。由于驱动运行在内核模式下，已经没有更高级别的机制来监控它们在做什么了。如果一段用户模式下的代码发飙，破坏了内存数据，那它也只是破坏了它自己的内存段而已。其进程最终会崩溃，但整个系统还是好好的。另一方面，如果某个驱动程序发飙，破坏了内存数据，那它破坏的是整个系统，最终你的机器会停止运转。

In acknowledgement of the importance of having high-quality drivers, Windows XP warns you when an uncertified driver is being installed. Which leads to today’s topic, a question from a device driver author.

鉴于驱动高质量的重要性，Windows XP 会在安装未经认证的驱动时警告用户，这就引出了今天的话题，是一位来自某个设备驱动程序作者的提问：

When I try to install any driver, I get a User Consent Dialog box which tells the user that this is an unsigned driver. Is it possible to author a driver installation package that by-passes this user consent dialog box?

当我尝试安装驱动时，系统都会弹出一个请求用户允许的对话框，告诉用户正在安装一个未签名的驱动。有没有办法编写一种驱动安装包，能让系统不显示这个对话框？

The whole purpose of that dialog is to prevent the situation you desire from happening! [typo fixed 5pm] If you don’t want the warning dialog, submit your driver for certification. (For testing purposes, you can sign your drivers with the test root certificate and install the test root certificate before running your setup program. Of course, installing the test root certificate also causes the desktop to read “For test purposes only” as a reminder that your machine is now allowing test-signed drivers to be installed.)

这个对话框的存在意义，可正是阻止你所想要的这种事情的发生啊！如果你不想让这个对话框出现，那就把你的驱动提交认证就好。（如果是出于测试的目的，你可以将你的驱动用测试根证书签名，并且在运行你的安装程序之前安装这个测试根证书。当然，安装测试根证书会让桌面上冒出“仅供测试使用”的字样，用来提醒你你的机器目前允许安装测试签名的驱动。）

Driver writers, of course, find the certification process cumbersome and will do whatever they can to avoid it. Because, of course, if you submit your driver for certification, it might fail! This has led to varying degrees of shenanigans to trick the WHQL team into certifying a driver different from the one you intend to use. My favorite stunt was related to my by a colleague who was installing a video card driver whose setup program displayed a dialog that read, roughly, “After clicking OK, do not touch your keyboard or mouse while we prepare your system.” After you click OK, the setup program proceeds to move the mouse programmatically all over the screen, opening the Display control panel, clicking on the Advanced button, clicking through various other configuration dialogs, a flurry of activity for what seems like a half a minute. When faced with a setup program that does this, your natural reaction is to scream, “Aaaiiiiigh!”

而驱动的编写者们，自然而然地发现这个认证过程缓慢而冗长，继而想出各种各样的办法来避免之。毕竟，如果你把自己的驱动提交认证的话，还是有通不过的可能性的！这种可能性让开发者们想出了各种稀奇古怪的门路，让WHQL团队给你所提交的驱动进行认证，但实际发布的则不是那一个。我所最喜欢的一则是由我的同事提供的，当他安装某款显卡驱动的时候，安装程序弹出一个对话框，上面大体上写着这些内容：“点击OK后，在我们帮你为系统进行准备配置时，请不要操作键盘或鼠标。”点击OK之后，安装程序就开始以程序操作你的鼠标满屏幕跑，打开『显示』控制面板，点击『高级』按钮，然后这里那里点击很多配置项，一同忙乱下来大概要花半分钟左右。面对这样的安装程序，你的内心想必是在大喊『啊啊啊啊啊』的吧。

原文链接：https://devblogs.microsoft.com/oldnewthing/20050810-13/?p=34623

The nickname for the feature known as Windows Error Reporting is “Dr. Watson”. Where did that name come from?

Windows 的错误报告功能有个昵称叫『Dr. Watson』（华生博士），这个名字是从哪来的呢？

As you have probably guessed, The name Dr. Watson was inspired by the character of Dr. Watson, the assistant to Sherlock Holmes in the stories by Arthur Conan Doyle.

如你所想，『华生博士』这个名字是受亚瑟·柯南道尔笔下的夏洛克·福尔摩斯的助手华生博士启发而起的。

It is my understanding that the doctor was originally developed as part of Windows 3.0 beta testing. His job was to record data about application crashes to a file, so that the file could be uploaded and included with bug reports. The icon was (and continues to be) a friendly doctor using his stethoscope to investigate a problem.

据我所了解，Dr. Watson 原本是作为 Windows 3.0 的 beta 测试工具被开发出来的，其工作是将崩溃的应用程序的数据记录到文件，以便将其嵌入到bug报告中进行上传。Dr. Watson 的图标曾经（并且至今如此）是一位用听诊器在调查问题的、和善的博士。

The Doctor has remained true to the “capture information about an error” aspect of his job. In the meantime, the word “Watson” has expanded its meaning to encompass anonymous end-user feedback mechanisms in general, such as “Content Watson”. (But if you hear “Watson” by itself, the speaker is almost certainly talking about error reporting.)

Dr. Watson 的工作『获取关于错误的信息』方面的描述一直保持不变。与此同时，Watson 这个词的含义也被扩展，囊括了面向最终用户的匿名反馈事项，例如『Content Watson』这种用法。（不过如果你单独听到 Watson 这个词，那说话者多半肯定是在讨论错误报告这回事。）

原文链接：https://devblogs.microsoft.com/oldnewthing/20050728-16/?p=34783

One reaction I’ve seen when people learn about all the compatibility work done in the Windows 95 kernel is to say,

当人们对 Windows 95 内核所作出的兼容性努力发表意见时，我所知的其中一条是：

Why not add code to the installer wizard [alas, page is now 404] which checks to see if you’re installing SimCity and, if so, informs you of a known design flaw, then asks you to visit Electronic Arts’ webpage for a patch?

为什么不在安装程序里加一行代码（可惜这个页面已经404了）（译注：所以这里就不再引用失效链接了），让它可以检测到你是不是正在安装《模拟城市》，如果是的话，就提醒你游戏里的bug，然后帮你打开EA的网站去下载补丁呢？

Let’s ignore the issue of the “installer wizard”; most people do not go through the Add and Remove Programs control panel to install programs, so any changes to that control panel wouldn’t have helped anyway.

这里我们先忽略『安装程序』这个说法，毕竟大多数人是不会跑到控制面板的『添加/删除程序』里去安装新应用的，所以对控制面板做出变动并没有什么帮助。

But what about detecting that you’re running SimCity and telling you to get a patch from Electronic Arts’ web site?

姑且说，系统能不能做到检测你开启了《模拟城市》，然后通知你去EA的网站上下载补丁呢？

Remember, this was 1993. Almost nobody had web sites. The big thing was the “Information Superhighway”. (Remember that? I don’t think it ever got built; the Internet sort of stole its thunder.) If you told somebody, “Go to Electronic Arts’ web site and download a patch”, you’d get a blank stare. What’s a “web site”? How do I access that from Prodigy? I don’t have a modem. Can you mail me their web site?

请记住，那是1993年，基本上没什么人开设了『网站』这种东西，那时候的热门话题叫『信息高速公路』。（还记得这个词吗？我反正没记得这东西建成了没有，『互联网』把它的风头全抢尽了。）如果那年头你跟别人说『去EA的网站上下个补丁』，得到的只能是一脸茫然：『网站』是嘛玩意？我怎么访问它？我家又没有调制解调器，你能把他们的网站寄给我吗？

In Windows XP, when Windows detects that you’re running a program with which it is fundamentally incompatible, you do get a pop-up window directing you to the company’s web site. But that’s because it’s now 2005 and even hermits living in caves have email addresses.

在 Windows XP 中，当 Windows 检测到你运行的程序存在完全不兼容的情况时，你的确会得到一项提示，将你导向开发这个软件的公司的网站。但这是因为这时已经是2005年了，就连住在山洞里的隐士都有电子邮件地址了。

In 1993, things were a little different.

而1993年的时候，事情可不太一样。

(Heck, even by 1995 things most people did not have Internet access and those few that did used modems. Requiring users to obtain Internet access in order to set the computer clock via NTP would have been rather presumptuous.)

（1995年的时候，大多数人都没法上网，而仅有的能上网的人倒的确都在用调制解调器。让用户上网就为了能通过NTP服务设置一下本机的时钟就更加扯淡了。）

原文链接：https://devblogs.microsoft.com/oldnewthing/20050720-16/?p=34883

The FindFirstFile function matches both the short and long names. This can produce somewhat surprising results. For example, if you ask for “*.htm”, this also gives you the file “x.html” since its short name is “X~1.HTM”.

FindFirstFile 函数会同时匹配短文件名和长文件名，有时这种设计会带来一些意料之外的结果。例如，如果你查找『*.htm』，x.html（译注：注意此处的扩展名是HTML，其在8.3形式下为HTM，感谢石樱灯笼在评论中指出）也会出现在结果中，因为它的短文件名是X~1.HTM。

Why does it bother matching short names? Shouldn’t it match only long names? After all, only old 16-bit programs use short names.

为什么要去匹配短文件名呢，只匹配长文件名不就够了吗？毕竟只有旧式的16位应用程序会用短文件名了。

But that’s the problem: 16-bit programs use short names.

然而这却正视问题所在：16位应用程序使用的是短文件名。

Through a process known as generic thunks, a 16-bit program can load a 32-bit DLL and call into it. Windows 95 and the Windows 16-bit emulation layer in Windows NT rely heavily on generic thunks so that they don’t have to write two versions of everything. Instead, the 16-bit version just thunks up to the 32-bit version.

通过名为通用 Thunk 的过程，16位应用程序可以加载32位的DLL并调用之。Windows 95 和 Windows NT 中的 16 位 Windows 模拟层对于通用 Thunk 重度依赖，这样才不必为各种各样的东西编写2个版本，而是让 16 位的调用直接与 32 位的相关调用进行联动。

Note, however, that this would mean that 32-bit DLLs would see two different views of the file system, depending on whether they are hosted from a 16-bit process or a 32-bit process.

然而需要注意的是，如此一来32位的DLL便对文件系统有了两种观察方式，具体取决于其宿主进程是16位还是32位。

“Then make the FindFirstFile function check to see who its caller is and change its behavior accordingly,” doesn’t fly because you can’t trust the return address.

『那就让 FindFirstFile 看看调用方是谁，然后执行不同的行为不就好了』，这种想法是不现实的，因为你无法信任返回地址。

Even if this problem were solved, you would still have the problem of 16/32 interop across the process boundary.

就算能解决这个问题，你还是要面对16/32位进程边界间互操作的问题。

For example, suppose a 16-bit program calls WinExec(“notepad X~1.HTM”). The 32-bit Notepad program had better open the file X~1.HTM even though it’s a short name. What’s more, a common way to get properties of a file such as its last access time is to call FindFirstFile with the file name, since the WIN32_FIND_DATA structure returns that information as part of the find data. (Note: GetFileAttributesEx is a better choice, but that function is comparatively new.) If the FindFirstFile function did not work for short file names, then the above trick would fail for short names passed across the 16/32 boundary.

例如，假设某个程序调用了WinExec(“notepad X~1.HTM”)，那么32位的记事本最好是去打开X~1.HTM，即便这是个短文件名。此外，获取文件属性（例如文件的最后访问时间）的一种通常方式便是调用 FindFirstFile 并提供文件名，因为 WIN32_FIND_DATA 结构会将这类信息包含在返回中。（请注意：使用 GetFileAttributesEx 是更好的做法，不过这个函数相对来说还比较新就是了。）如果 FindFirstFile（在32位程序调用它的时候）不能使用短文件名，那么前述的做法就会失效，因为此时短文件名跨越了16/32位的边界。

As another example, suppose the DLL saves the file name in a location external to the process, say a configuration file, the registry, or a shared memory block. If a 16-bit program program calls into this DLL, it would pass short names, whereas if a 32-bit program calls into the DLL, it would pass long names. If the file system functions returned only long names for 32-bit programs, then the copy of the DLL running in a 32-bit program would not be able to read the data written by the DLL running in a 16-bit program.

另一个例子是，假设某个DLL将文件名保存在进程之外的某处，例如配置文件中、注册表中，或某个共享的内存区域里。如果16位应用程序调用了这个DLL，那么它传入的就是短文件名，而32位应用程序调用时则会传入长文件名。如果文件系统函数只为32位应用程序返回长文件名，那么运行在32位应用程序下的这个DLL就无法读取由16位应用程序调用其时写入的数据了。

原文链接：https://devblogs.microsoft.com/oldnewthing/20050719-12/?p=34893

The ES_OEMCONVERT edit control style is a holdover from 16-bit Windows. This ancient MSDN article from the Windows 3.1 SDK describes the flag thus:

编辑控件的 ES_OEMCONVERT 样式是从 16 位 Windows 中继承下来的。下面这篇在 Windows 3.1 SDK 中古老的 MSDN 文章对这个标志是这样描述的：

ES_OEMCONVERT causes text entered into the edit control to be converted from ANSI to OEM and then back to ANSI. This ensures proper character conversion when the application calls the AnsiToOem function to convert a Windows string in the edit control to OEM characters. ES_OEMCONVERT is most useful for edit controls that contain filenames.

ES_OEMCONVERT 标记会将输入到编辑控件的文字从 ANSI 编码转换到 OEM 编码，然后再转回 ANSI 编码。通过这样操作，可以保证应用程序调用AnsiToOem 将编辑控件中的字符转换为 OEM 编码的字符时，可以获得恰当的结果。ES_OEMCONVERT  在包含文件名的编辑控件中最有裨益。

Set the wayback machine to, well, January 31, 1992, the date of the article.

让我们把时间倒回1992年1月31日，也就是上面那段文字那时候。

At this time, the predominant Windows platform was Windows 3.0. Windows 3.1 was still a few months away from release, and Windows NT 3.1 was over a year away. The predominant file system was 16-bit FAT, and the relevant feature of FAT of this era for the purpose of this discussion is that file names were stored on disk in the OEM character set. (We discussed the history behind the schism between the OEM and ANSI code pages in an earlier article.)

那个时候，占据主导地位的 Windows 平台是 Windows 3.0。Windows 3.1 还得再过几个月才会发布，而 Windows NT 3.1 还得再等一年。那时占主导地位的文件系统是 16 位 FAT，而与此处讨论相关的 FAT 文件系统的设计，则是磁盘上存储的文件名使用的是 OEM 字符集。（我们在早先的一篇文章中讨论过有关 OEM 和 ANSI 代码页之间的分崩离析。）（译注：链接已失效，无法查证）

Since GUI programs used the ANSI character set, but file names were stored in the OEM character set, the only characters that could be used in file names from GUI programs were those that exist in both character sets. If a character existed in the ANSI character set but not the OEM character set, then there would be no way of using it as a file name; and if a character existed in the OEM character set but not the ANSI character set, the GUI program couldn’t manipulate it.

由于 GUI 程序用的是 ANSI 字符集，而文件名是用 OEM 字符集存储的，所以在 GUI 应用程序中使用的文件名，其字符集只能是在两种字符集中共存的那些。如果某个字符在 ANSI 字符集中存在，但并不存在于 OEM 字符集中，那么就不能讲这个字符用在文件名中；反之，如果某个字符在 OEM 字符集中存在，但在 ANSI 字符集中不存在，那么 GUI 应用程序也搞不定它。

The ES_OEMCONVERT flag on a edit control ensures that only characters that exist in both the ANSI and OEM character sets are used, hence the remark “ES_OEMCONVERT is most useful for edit controls that contain filenames”.

编辑控件中的 ES_OEMCONVERT 样式可以保证只有在 ANSI 和 OEM 两种字符集中共存的字符才能使用，也就印证了『ES_OEMCONVERT  在包含文件名的编辑控件中最有裨益』的说法。

Fast-forward to today.

回到现在。

All the popular Windows file systems support Unicode file names and have for ten years. There is no longer a data loss converting from the ANSI character set to the character set used by the file system. Therefore, there is no need to filter out any characters to forestall the user typing a character that will be lost during the conversion to a file name. In other words, the ES_OEMCONVERT flag is pointless today. It’s a leftover from the days before Unicode.

如今所有流行的 Windows 文件系统都支持 Unicode 文件名，并且已经如此十年了（译注：原文发布时间为2005年7月19日，Windows 3.0 发布时间为1990年5月22日），在将（文件名中的字符从）ANSI 字符集转换为文件系统使用的字符集（Unicode）不会再有数据丢失的问题了。因此也没有必要再预先将用户录入文件名时，可能在后期转换中丢失的字符过滤掉了。换句话说，ES_OEMCONVERT 这个样式标记已经毫无意义了，只是一个在 Unicode 年代之前的遗留而已。

Indeed, if you use this flag, you make your program worse, not better, because it unnecessarily restricts the set of characters that the user will be allowed to use in file names. A user running the US-English version of Windows would not be allowed to enter Chinese characters as a file name, for example, even though the file system is perfectly capable of creating files whose names contain those characters.

实际上，如果你非要用这个样式标记不可，只会让你的程序更糟糕而不是更优秀，因为对用户在文件名中允许使用过的字符集进行限制已经毫无必要。例如，（在你经过这样设计的应用程序中，）使用美国英语版本 Windows 的用户就不能输入中文字符作为文件名了，即便是文件系统可以完美支持创建包含那些（中文）字符的文件名也一样。