原文链接：https://devblogs.microsoft.com/oldnewthing/20051108-05/?p=33423

John Elliott wondered why the GlobalWire function was called GlobalWire.

John Elliott 想知道为什么 GlobalWire 函数起了这么个名字。

First, some background for those who never had to write 16-bit Windows programs. The GlobalWire function was similar to the 16-bit GlobalLock function, except that it had the bonus feature of relocating the memory to the lowest available linear address. You used this function as a courtesy if you intended to leave the memory locked for a long time. Moving it to the edge of the address space means that it is unlikely to become an obstacle in the middle of the address space which would otherwise prevent future large memory allocations from succeeding.

首先，给从来都不需要撰写 16 位 Windows 应用程序的人一点背景资料。GlobalWire 函数与 16 位函数 GlobalLock 类似，不过还有将内存块移动到可用的最低线性地址的附加作用。调用这个函数意味着你想让某部分内存锁定较长的一段时间。将内存块移动到地址空间的边缘，使得这块内存不会成为不上不下地横亘在地址空间的一部分，以期未来的大块内存分配不会失败。

But why “wire”?

不过『wire』这个写法又是怎么回事呢？

This employs a colloquial sense of the word “wire” as a verb which has lost its currency in the intervening years. To wire means to fasten securely in a very strong sense. It probably derives from the phrase “hard-wired”, which means “permanently attached in circuitry”. Therefore, “wiring” memory into place ensures that it doesn’t move around.

这里是借用了 wire 这个词作为动词的口语说法，而这种用法这些年大概逐渐式微了。『To wire』意味着将某物『紧紧绑住』的一种强烈语气，可能是来自短语『hard-wired』，含义是『在电路中永久固定』。由此，将内存『捆绑』在某处就是期望其不会到处乱跑。

原文链接：https://devblogs.microsoft.com/oldnewthing/20051103-43/?p=33473

Many people misinterpreted my use of the term “reluctant” to describe the attitude of the designers in changing the way the Date/Time control panel functions. It was a reluctance of shame, not a reluctance of defiance.

很多人错误地理解了我对修改日期/时间控制面板功能中设计人员的『不情愿』的含义。这里的『不情愿』指的是羞愧心，而不是抗拒心。

Your software is there for the users, not vice versa. If you find that your users are using the software in a manner contrary to its intended purpose, your first reaction may be to try to educate users not to do whatever it is they’re doing. But eventually you reach a point where the efforts in convincing people not to do something dangerous outweighs the cost of just making it less dangerous. (Even though this may annoy those who genuinely want to perform that dangerous activity.)

你的软件是为了用户而生的，但并不是说反之亦然。如果你发现用户在使用你的软件时，总是与你的设计初衷相悖，你的第一反应可能是去指导用户不要这么做。但是，迟早你会发现教给用户不要做什么的成本大大高于让你的设计更加合理。（虽然这会让刻意做这些操作的人感到恼火就是。）

You may not do it with a smile on your face (hence the reluctance), but you know deep in your heart that it’s the right thing to do.

可能做出这些修改的时候，你的脸上不会带着笑容（也就是所谓的『不情愿』），但在内心深处你也明白这才是正道。

Side note: Why did the Date/Time control panel apply changes immediately anyway? Historical artifact. That’s the way the Date/Time control panel has worked since Windows 1.0. In fact, originally, the Date/Time control panel didn’t even have a Cancel button. Any changes you made to the time took effect immediately and irrevocably. (Mind you, MS-DOS and the original Macintosh did the same thing.) It wasn’t until after Windows 95 shipped that this behavior started being a problem.

再说个小故事：为什么日期/时间控制面板会立刻应用修改呢？这是历史上一以贯之的设计，也是日期/时间控制面板从 Windows 1.0 起的设计。实际上，原本日期/时间控制面板连『取消』按钮都没有，任何对时间的修改都立刻生效、无法撤销。（小提示：MS-DOS 和原始的 Macintosh 都是这么设计的。）但是直到 Windows 95 发布后，这样的设计才成为了一个问题。

原文链接：https://devblogs.microsoft.com/oldnewthing/20051102-48/?p=33503

Earlier versions of Internet Explorer used inline autocomplete, but newer versions use drop-down autocomplete that requires you to press the down-arrow key to select an item from the drop-down. Why the change?

早期版本的 Internet Explorer 启用了行内自动完成，但新版本改成了下拉列表式的自动完成，需要用户按下箭头键来在列表中选择一项。为什么会有这种变动呢？

Because it interferes with normal keyboard operation.

因为先前的设计影响了正常的键盘操作。

Suppose http://www.microsoft.com/windows/ is in your history, but you want to go to http://www.microsoft.com/. As you type the desired destination, inline autocomplete kicks in and fills in the remainder of the URL for you, http://www.microsoft.com/windows/. If you aren’t watching the screen and just hit Enter, you end up going to the autocompleted URL instead of the URL you typed. Oops.

假设 http://www.microsoft.com/windows/ 在你的浏览记录中，但你想浏览的是 http://www.microsoft.com/。当你在地址栏中输入要访问的网址时，行内自动完成发挥了作用，帮你补全了余下的部分，（使网址变成了）http://www.microsoft.com/windows/。如果你（低头敲键盘）没看屏幕就直接按下了回车键，结果就是访问了自动完成给出的 URL 而不是你录入的网址。哎呀。

To me, this is a fatal flaw, namely that one has to be watching the screen to perform an operation that one would think consisted purely of typing. In particular, this creates problems for people with limited visual capability who necessarily “type blind” most of the time.

对我来说，这是个难以接受的缺陷，使得一项让只管录入就能完成的工作，变成了需要盯着屏幕才能完成的情况。尤其是针对事实上总是在『盲打』的视弱用户而言，便是一个大问题。

Even using Tab as the autocomplete character suffers from the same flaw. Consider the Run dialog or IE’s address bar. In those places, the Tab key moves you around the window. (To the OK, Cancel, and Browse buttons on the Run dialog, or into the web page itself for IE.) If the Tab key were the autocomplete completion key, it wouldn’t be possible to Tab around the dialog/window any more. For example, suppose you want to browse around your C drive, so you type C:\ into the Run dialog and hit Tab three times to get to the Browse button. But, oops, the Tab key autocompletes, so instead of browsing C:\, you’re browsing whatever directory in your C: drive the autocomplete engine decided to show you.

就算将自动完成功能改成用 Tab 键，也会产生同样的问题。考虑在『运行』对话框或 IE 的地址栏里，在这些地方，Tab 键会将你的焦点移动到其它控件上。（例如在『运行』对话框中移动到『确定』、『取消』或『浏览』按钮上，或者在 IE 中移动到网页上去。）如果让 Tab 键作为自动完成的案件，那么就无法再用其在对话框或窗口中的控件之间进行切换了。举个例子，假设你想浏览C盘的内容，于是你就在『运行』对话框中输入了 C:\，然后按了 3 下 Tab 键想移动到『浏览』按钮上，然而这时 Tab 键是自动完成键了，于是你输入的路径就变成了自动完成引擎帮你决定的、你的 C 盘中随便哪个目录的内容，而不是浏览 C:\ 的内容了。

原文链接：https://devblogs.microsoft.com/oldnewthing/20051027-37/?p=33593

It has been pointed out that the documentation for the cmd.exe program says

Cmd.exe 的文档中曾指出，

/A Causes the output of internal commands to a pipe or file to be ANSI

/A 选项使内部命令输出至管道或文件时使用 ANSI

even though the output is actually in the OEM code page. Why do errors such as this persist?

——不过实际上是用 OEM 代码页输出的，为什么这种错误会不断出现呢？

Because ANSI sometimes means OEM.

因为 ANSI 有时候指的就是 OEM。

The “A” versions of the console functions accept characters in the OEM code page despite the “A” suffix that would suggest ANSI. What’s more, if you call the SetFileAPIsToOEM function, then “A” functions that accept file names will also interpret the filenames in the OEM code page rather than the ANSI code page.

『A』版本的控制台函数接受在 OEM 代码页中的字符，即便『A』这个前缀指的是 ANSI 也一样。此外，如果你调用 SetFileAPIsToOEM 这个函数，那么接受传入文件名的『A』系的函数同样会使用 OEM 代码页、而不是 ANSI 代码页来解析文件名。

“There are two types of people in the world: Those who believe that the world can be divided into two types of people, and those who do not.”

『这世上有两种人：相信人们可以被分成两种人的，和不相信的。』

There are those who mentally divide the world of characters into two groups: Unicode and 8-bit. And as you can see, many of them were involved in the original design of Win32. There are “W” functions (Unicode) and “A” functions (ANSI). There are no “O” functions (OEM). Instead, the OEM folks got lumped in with the ANSI folks.

这世上也有在精神上将字符世界一分为二的人：不是 Unicode 就是 8 位字符集。并且与此同时，这类人中的许多也与 Win32 的原始设计相关联。有『W』系函数（Unicode）（译注：W 指 Wide），也有『A』系函数（ANSI），就是没有『O』系函数（OEM），OEM 字符集的认同者们被与 ANSI 字符集的拥趸们撮成了一堆。

There are also those who realize the distinction, but out of laziness or convenience often use “ANSI” as an abbreviation for “an appropriate 8-bit character set, determined from context”. In the context of console programming, the appropriate 8-bit character set is the OEM character set.

这世上也有人能分清（这三种字符集）的区别，但出于懒惰或便利，经常使用『ANSI』来指代『某种8位字符集（依据上下文来确定）』。在控制台应用程序的上下文中，对应的8位字符集指的就是 OEM 字符集。

The person who wrote the online help for cmd.exe clearly meant ANSI to mean “That thing that isn’t Unicode.”

给 cmd.exe 撰写线上帮助信息的人，实际上想让 ANSI 指代的是『不是 Unicode 的那种字符集』。

/A Causes the output of internal commands to a pipe or file to be ANSI

/A 选项使内部命令输出至管道或文件时使用 ANSI

/U Causes the output of internal commands to a pipe or file to be Unicode

/U 选项使内部命令输出至管道或文件时使用 Unicode

I’ll leave you to decide whether this author belongs to the “Everything is either Unicode or ANSI” camp or the “just being casual” camp.

至于写这个帮助信息的人是属于『这世上的字符不是 Unicode 就是 ANSI』还是『俺就素懒』阵营的，就留待您自行评说了。

原文链接：https://devblogs.microsoft.com/oldnewthing/20051026-44/?p=33613

An example, all too frequent, of ways programs assume that the user interface will never change is reaching into system binaries and sucking out undocumented resources. In the shell, we have fallen into the reluctant position of carrying “dead” icons around for the benefit of programs that assumed that they would always be available. However, we often make these “orphaned” icons blank so that these programs don’t crash, but they don’t necessarily look all that wonderful either.

有些程序认为用户界面永远不会改变的、非常常见的一种表现，便是深入到系统文件中随便扒拉没有在文档中描述的资源。在 Shell 设计中，我们陷入了一种不情愿的境地，即保留某些已经『死掉』的图标，来让这类认为某些资源会一直存在的程序高兴。不过，我们通常都会将这些『遗孤』图标变成空白，使得这些程序虽然不会崩溃，但也不会让它们看上去再那么完美。

Recently, I learned of a new type of resource stealing: Stealing animations. For Windows Vista, there have been many changes to the way the system internally organizes its resources in order to support the Multilingual User Interface feature. One of the things we found was a handful of programs that reach directly into Shell32.dll in order to obtain the file copy animation. Too bad (1) the animation isn’t kept there any more, and even if we moved the animation back to its original location, (2) the animation uses a new compression scheme that older programs can’t handle.

最近，我又了解了一种窃取资源的新方法：盗用动画。在 Windows Vista 中，为了支持多语言用户界面（MUI）功能，在系统内部对资源的排序整理方式发生了很大的变化。（在此过程中，）我们发现了一件事，有不少应用程序直接跑进 SHELL32.DLL 中直接将复制文件的动画拿来用。可惜的是，（1）这个动画已经不在原先的位置了，并且就算我们将这个动画放回原来的位置，（2）这个动画所使用的新的压缩方式，这些老版本的程序也不支持。

Remember, resources in system DLLs should be treated as implementation details, unless explicitly documented otherwise.

请记住，除非在文档中明示，否则系统 DLL 中的资源应当被视为实施细节。

I’m not sure what we’re going to do about the animation resource problem. Suggestions anyone? Should we declare these programs broken and make the people who bought them go back to their vendors for upgrades? (What if there is no vendor?) Should we develop a shim and hope that those four are the only programs that need it? Should we carry the original animation in shell32.dll as junk? If I told you that one of the programs that did this won “Game of the Year” recently, would that change your answer? What if another turned out to be a top-rated anti-spyware program?

我不是很确定应该怎么解决这个盗用系统动画的问题，有人能给个建议吗？是不是应该让这些程序无法运行，让购买了这些软件的人们回去找发行商进行升级呢（要是没有发行商该怎么办）？还是应该针对这些程序打个补丁，然后寄希望于只有这些程序需要这个补丁吗？或者让旧版本的动画继续存在于 SHELL32.DLL 中作为残留呢？如果我告诉你有这个问题的软件最近还拿了『年度最佳游戏』的奖项，你会选择修改你的回答吗？要是我告诉你还有一款存在这个问题的软件，是某个名列前茅的反间谍软件呢？