原文链接：https://devblogs.microsoft.com/oldnewthing/20050117-00/?p=36683

The old MS-DOS function calls (ah, int 21h), typically indicated error by returning with carry set and putting the error code in the AX register. These error codes will look awfully familiar today: They are the same error codes that Windows uses. All the small-valued error codes like ERROR_FILE_NOT_FOUND go back to MS-DOS (and possibly even further back).

旧式的 MS-DOS 功能调用（啊，INT 21h）通常通过在返回中设置carry标志、并将错误代码放在AX寄存器中来表明发生了错误。这些错误代码即使今天看起来也极其眼熟，因为 Windows 也使用了相同的错误代码。所有这些由小小的数字代表的错误代码——如 ERROR_FILE_NOT_FOUND ——都可以追溯到 MS-DOS（并且可能更早）。

Error code numbers are a major compatibility problem, because you cannot easily add new error code numbers without breaking existing programs. For example, it became well-known that “The only errors that can be returned from a failed call to OpenFile are 3 (path not found), 4 (too many open files), and 5 (access denied).” If MS-DOS ever returned an error code not on that list, programs would crash because they used the error number as an index into a function table without doing a range check first. Returning a new error like 32 (sharing violation) meant that the programs would jump to a random address and die.

错误代码是一项主要的兼容性问题，因为你无法简单地增加新的错误代码，而不影响已有的应用程序。例如，广为人知的是『调用 OpenFile 且失败时，可能的返回只会是3（找不到路径）、4（打开的文件数已超出上限）或者5（拒绝访问）』。如果 MS-DOS 返回了一个不在这个列表上的错误代码，（第三方）程序们就会崩溃，因为这些程序将错误代码用作了函数列表的索引，甚至连边界检查都没做。返回一个新的错误代码（例如32）会让这些程序跳到一个随机的地址，然后炸掉。

More about error number compatibility next time.

下次有机会时，我们再来说有关错误代码兼容性的事。

When it became necessary to add new error codes, compatibility demanded that the error codes returned by the functions not change. Therefore, if a new type of error occurred (for example, a sharing violation), one of the previous “well-known” error codes was selected that had the most similar meaning and that was returned as the error code. (For “sharing violation”, the best match is probably “access denied”.) Programs which were “in the know” could call a new function called “get extended error” which returned one of the newfangled error codes (in this case, 32 for sharing violation).

等到增加新的错误代码变得有必要时，兼容性需求会要求函数返回的错误代码不能改变。因此，当某个新型的错误发生时（例如共享违例），会返回一个之前『最广为人知』且含义最为接近的的错误代码。（对于『共享违例』来说，最佳的匹配项是『拒绝访问』）。那些『知道内情』的（新）程序可以通过调用名为『获取扩展错误代码』的方法来获取那些『新奇』的错误代码（在前面的例子中，程序会获得32——共享违例）。

The “get extended error” function returned other pieces of information. It gave you an “error class” which gave you a vague idea of what type of problem it is (out of resources? physical media failure? system configuration error?), an “error locus” which told you what type of device caused the problem (floppy? serial? memory?), and what I found to be the most interesting meta-information, the “suggested action”. Suggested actions were things like “pause, then retry” (for temporary conditions), “ask user to re-enter input” (for example, file not found), or even “ask user for remedial action” (for example, check that the disk is properly inserted).

这个『获取扩展错误代码』方法还返回了其它的信息，它会给你返回一个『错误类』来通知你关于问题的大致类别（资源不足？媒体硬件损坏？系统设置出错？），一个『错误核心』来告知你导致错误发生的具体设备类型（软驱？串口？内存？），以及我认为最有趣的元信息部分——『建议操作』。『建议操作』会是类似『暂停，然后重试』（对于暂时性的问题来说），『要求用户重新提供输入』（例如找不到文件这类错误），甚至『要求用户实行补救措施』（例如检查磁盘是否正确插入了）等等。

The purpose of these meta-error values is to allow a program to recover when faced with an error code it doesn’t understand. You could at least follow the meta-data to have an idea of what type of error it was (error class), where the error occurred (error locus), and what you probably should do in response to it (suggested action).

这些有关错误的元数据有助于程序在面对一个其不了解的错误代码时，从错误中恢复过来。至少你可以从元数据所描述中，知晓出错的类型（错误类）、出错的所在（错误核心）以及面对错误时可能应该进行的操作（建议操作）。

Sadly, this type of rich error information was lost when 16-bit programming was abandoned. Now you get an error code or an exception and you’d better know what to do with it. For example, if you call some function and an error comes back, how do you know whether the error was a logic error in your program (using a handle after closing it, say) or was something that is externally-induced (for example, remote server timed out)? You don’t.

可惜的是，这种丰富的错误信息设计随着16位程序退出历史舞台被遗弃了。现在当你面对错误代码或异常信息时，你最好知道自己应该做什么。例如，如果你调用了某个方法，然后返回了一个错误，你如何知道这是你程序设计中的逻辑错误（例如在关闭某个句柄后又去使用它），还是某些外界因素的导致的（例如远程服务器超时）？你没法知道。

This is particularly gruesome for exception-based programming. When you catch an exception, you can’t tell by looking at it whether it’s something that genuinely should crash the program (due to an internal logic error – a null reference exception, for example) or something that does not betray any error in your program but was caused externally (connection failed, file not found, sharing violation).

这种情形在面对以异常为错误机制的编程时尤为可惧。当你捕获了一个异常时，你没有办法通过观察异常信息，来判断是什么地方真的让你的程序崩溃了（来自内部的逻辑设计错误，例如空引用异常等等），还是某些实际上与你的程序无关、而是某些外界因素导致的（例如连接失败、未找到文件、共享违例等等）。

原文链接：https://devblogs.microsoft.com/oldnewthing/20050111-00/?p=36743

Wes Haggard wishes that \ would autocomplete to all the computers on the network. [Link fixed 10am.] An early beta of Windows 95 actually did something similar to this, showing all the computers on the network when you opened the Network Neighborhood folder. And the feature was quickly killed.

Wes Haggard 希望（在『运行』对话框或地址栏中）输入 \\ 时，自动完成功能可以列出网络上的所有计算机。Windows 95 的一个早期 beta 版本实际上有一个与此类似的功能，当你打开『网上邻居』文件夹时便列出网络上的所有计算机，然而这个功能很快就被砍掉了。

Why?

为什么呢？

Corporations with large networks were having conniptions because needlessly enumerating all the machines on the network can bring a large network to its knees. Think about all the times you type “\\”. Now imagine if every single time you did that, Explorer started enumerating all the machines on the network. And imagine how your network administrator would feel if their network traffic saturated with enumerations each time you did that.

拥有大型网络的企业对此大动肝火，因为毫无必要地枚举出网络上所有的计算机有将一个大型网络搞到跪的能力。想像一下每次你输入 \\ 的时候。然后再想像一下每次你这样做的时候，资源管理器都会开始枚举网络上所有的计算机。再想像一下每次你这样做时，网络上的巨额流量会让网管的脸有多难看。

Network administrators made it clear in no uncertain terms that having Windows casually enumerate all the machines on their LAN was totally unacceptable.

网管们非常清楚且毫不含糊地表示，让 Windows 随随便便就在局域网上枚举所有计算机是完全不可接受的事情。

The needs of the corporate environment are very different from those of the home network, and Windows needs to operate in both worlds.

企业环境的需求与家庭网络大相径庭，而 Windows 需要在两种环境下都能正常操作。

原文链接：https://devblogs.microsoft.com/oldnewthing/20041215-00/?p=37003

The performance of the syscall trap gets a lot of attention.

有关 syscall 陷阱的效率问题吸引了很多人的注意。

I was reminded of a meeting that took place between Intel and Microsoft over fifteen years ago. (Sadly, I was not myself at this meeting, so the story is second-hand.)

我想起了十五年前 Intel 和微软之间的一次会议。（很遗憾当时我没有亲自在场，所以接下来的故事是转述的。）

Since Microsoft is one of Intel’s biggest customers, their representatives often visit Microsoft to show off what their latest processor can do, lobby the kernel development team to support a new processor feature, and solicit feedback on what sort of features would be most useful to add.

鉴于微软是 Intel 最大的客户之一，Intel 的代表经常到访微软，炫耀他们最新款的处理器的能力，游说内核开发团队支持一项新的处理器功能，并且征求有关有意向添加到处理器中的、最有用的功能类别。

At this meeting, the Intel representatives asked, “So if you could ask for only one thing to be made faster, what would it be?”

在那次会议上，Intel 的代表问道，『如果只有一件事可以提速，你们希望是什么呢？』

Without hesitation, one of the lead kernel developers replied, “Speed up faulting on an invalid instruction.”

内核团队的一位领头开发者不假思索地回答道：『执行无效指令时的出错再快一点。』

The Intel half of the room burst out laughing. “Oh, you Microsoft engineers are so funny!” And so the meeting ended with a cute little joke.

会议室里 Intel 一侧的人们大笑起来，『哎呀，你们微软的工程师可真有意思！』会议在这个小而有趣的玩笑中收场了。

After returning to their labs, the Intel engineers ran profiles against the Windows kernel and lo and behold, they discovered that Windows spent a lot of its time dispatching invalid instruction exceptions. How absurd! Was the Microsoft engineer not kidding around after all?

等回到实验室之后，Intel 的工程师们对 Windows 的内核进行了测评，出乎意料地发现 Windows 花了大量的时间来调度无效的指令异常。这也太荒谬了吧！微软的那些工程师原来并不是在开玩笑吗？

No he wasn’t.

还真不是。

It so happens that on the 80386 chip of that era, the fastest way to get from V86-mode into kernel mode was to execute an invalid instruction! Consequently, Windows/386 used an invalid instruction as its syscall trap.

原来在那个时代的 80386 处理器上，从虚拟8086模式切换到内核模式最快的方法，正是执行一个无效的指令！因此，Windows/386 将无效指令作为了 syscall 的陷阱。

What’s the moral of this story? I’m not sure. Perhaps it’s that when you create something, you may find people using it in ways you had never considered.

至于这个故事教给我们的道理是什么，我并不太确定。大概是当你创造了一项事物时，你会发现人们会用你从未考虑过的方式去使用它。

原文链接：https://devblogs.microsoft.com/oldnewthing/20041202-00/?p=37153

The story behind the 55ms timer tick rate goes all the way back to the original IBM PC BIOS. The original IBM PC used a 1.19MHz crystal, and 65536 cycles at 1.19MHz equals approximately 55ms. (More accurately, it was more like 1.19318MHz and 54.92ms.)

定时器的运行频率是 55ms 追根究底要回到原始的 IBM PC BIOS 上。最初的 IBM PC 使用了一颗 1.19MHz 的晶振，而 1.19MHz 上 65536 个时钟周期所需的时间大约就是 55ms。（更准确的说，应该是 1.19318 MHz 和 54.92ms。）

But that just pushes the question to another level. Why 1.19…MHz, then?

不过这样一解释只是将问题又推高了一个级别，为什么是 1.19 MHz 呢？

With that clock rate, 2¹⁶ ticks equals approximately 3600 seconds, which is one hour. (If you do the math it’s more like 3599.59 seconds.) [Update: 4pm, change 232 to 216; what was I thinking?]

在这样的时钟频率下，2¹⁶ 个嘀嗒（tick）大约就是 3600 秒，也就是一小时。（精确一些的话，也可以说是3599.59 秒。）

What’s so special about one hour?

为什么『一个小时』这个周期那么特别呢？

The BIOS checked once an hour to see whether the clock has crossed midnight. When it did, it needed to increment the date. Making the hourly check happen precisely when a 16-bit tick count overflowed saved a few valuable bytes in the BIOS.

BIOS 每小时会检查一次系统时钟来确定是否跨越了午夜，当这种情况发生时，系统就会将日期向前推进一天。让这种检查机制发生在16位嘀嗒存储器溢出的时刻，可以在 BIOS 中节约宝贵的几个字节。

Another reason for the 1.19MHz clock speed was that it was exactly one quarter of the original CPU speed, namely 4.77MHz, which was in turn 4/3 times the NTSC color burst frequency of 3.5MHz. Recall that back in these days, personal computers sent their video output to a television set. Monitors were for the rich kids. Using a timer related to the video output signal saved a few dollars on the motherboard.

另一个采用 1.19MHz 时钟频率的原因是因为这个值正好是原始设计中 CPU 运行速度—— 4.77MHz ——的四分之一，而这正好又是 NTSC 制式的彩色信号频率的三分之四倍（译注：没有打错，4.77除以3.5约等于4除以3）。当年，个人电脑是将其视频信号输出到电视上的，那时候显示器是有钱人的玩具，而将定时器频率与视频信号关联起来则又在主板上省出了几美元的成本。

Calvin Hsia has another view of the story behind the 4.77MHz clock.

Calvin Hsia 提供了有关 4.77 MHz 时钟频率的另一个角度的故事。（译注：链接已失效）

(Penny-pinching was very common at this time. The Apple ][ had its own share of penny-saving hijinks.)

（那时候一分钱掰成两半花是很常见的事，Apple ][ 有其自己的省钱小妙招。）（译注：链接已失效）

原文链接：https://devblogs.microsoft.com/oldnewthing/20041122-00/?p=37233

If I had a nickel each time somebody asked for a feature that was a security hole…

如果每当有人要求加一个实际上是安全漏洞的功能，我就能得到一个镍币的话……

I’d have a lot of nickels.

那我应该早已攒下了很多钱。

For example, “I want a file that all users can write to. My program will use it as a common database of goodies.”

例如，『我想要一个文件，对所有用户可写，我的程序会用它来作为一个存放好东西的公用数据库。』

This is a security hole. For a start, there’s an obvious denial of service attack by having a user open the file in exclusive mode and never letting go. There’s also a data tampering attack, where the user opens the file and write zeros all over it or merely alter the data in subtle ways. Your music index suddenly lost all its Britney Spears songs. (Then again, maybe that’s a good thing. Sneakier would be to edit the index so that when somebody tries to play a Britney Spears song, they get Madonna instead.) [Minor typo fixed. 10am]

这就是一个安全漏洞。首先，这是一个很明显的拒绝服务攻击点，某用户以独占方式打开它，然后永远不关闭就可以了。此外这还是一个数据篡改漏洞，用户可以打开文件，然后将数据用0全部覆写，或者对数据做一点细微的变动，你的音乐库里所有 Britney Spears 的歌就突然全部消失了。（说实话，这样都还算好的，更加鬼鬼祟祟的人会修改索引，这样等下次有人想播 Britney Spears 的歌时，放出来的却会是 Madonna 的了。）

A colleague from the security team pointed out another problem with this design: Disk quotas. Whoever created the file is charged for the disk space consumed by that file, even if most of the entries in the file belong to someone else. If you create the file in your Setup program, then it will most likely be owned by an administrator. Administrators are exempt from quotas, which means that everybody can party their data into the file for free! (Use alternate data streams so you can store your data there without affecting normal users of the file.) And if the file is on the system partition (which it probably is), then users can try to fill up all the available disk space and crash the system.

安全团队的一位同事还指出了这种设计制造出的另一个麻烦：磁盘配额。谁创建了这个文件，谁就为此付出了与文件大小等同自己的磁盘配额，即便文件内容中大多数的条目都属于其他人。如果这个程序是在你的安装程序中创建的，那么这个文件的所有人大概率会是系统管理员（Administrator）。系统管理员是从磁盘配额管制中豁免的，意味着任何人都可以将任何数据写到这个文件里，而且还不受配额的限制。（如果使用交换数据流（译注：alternate data stream，个人认为译为『备用数据流』更佳，此处采用通行译法）的方式，你还可以将自己的数据存进交换数据流里，而不会影响到其他人的数据）。如果这个文件存放在系统分区中（大概率会是这样），那么用户就可以尝试耗尽剩余的磁盘空间，让系统崩溃。

If you have a shared resource that you want to let people mess with, one way to do this is with a service. Users do not access the resource directly but rather go through the service. The service decides what the user is allowed to do with the resource. Maybe some users are permitted only to increment the “number of times played” counter, while others are allowed to edit the song titles. If a user is hogging the resource, the server might refuse connections for a while from that user.

如果你有一项共享资源想放开给用户折腾，一种比较可行的做法是通过服务。用户需要通过服务而不是直接去访问这项资源，而服务决定了允许用户对这项资源的所作所为。例如，一些用户只有权限增加『已播放次数』的计数器，而另一些用户则可以编辑歌曲的标题等等。如果某个用户对这项资源的访问过于贪婪，服务器可以决定暂停对这个用户提供服务。

A file doesn’t give you this degree of control over what people can do with it. If you grant write permission to a user, then that user can write to any part of the file. The user can open the file in exclusive mode and prevent anybody else from accessing it. The user can put fake data in the file in an attempt to confuse the other users on the machine.

单一一个文件无法给予这种等级的控制，来管制用户可以对其进行的操作。如果你授予用户写入的权限，那用户就可以对文件的任何部分进行写入。用户可以以独占方式打开这个文件，从而阻止其他人对其的访问。用户甚至可以在文件中写入伪造的数据，借此使同一机器上的其他用户感到困惑。

In other words, the user can make a change to the system that impacts how other users can use the system. This sort of “impact other users” behavior is something that is reserved for administrators. An unprivileged user should be allowed only to mess up his own life; he shouldn’t be allowed to mess up other users’ lives.

换句话说，某个用户可以对系统做出变更，而这些变更会影响其他用户对系统的使用。这类『影响其他用户』的行为是保留给系统管理员的权力。没有特权的用户应当只被允许对其自己的生活瞎折腾，而不应被允许去折腾其他用户的生活。

Armed with this information, perhaps now you can answer this question posted to comp.os.ms-windows.programmer a few months ago.

了解了这一点之后，大概现在你就有资格去回答这个几个月前贴在comp.os.ms-windows.programmer上的问题了。

原文链接：https://devblogs.microsoft.com/oldnewthing/20041118-00/?p=37263

If you have both a folder named, say, C:\Folder and a program named C:\Folder.exe and you type C:\Folder into the Start.Run dialog, you get the program and not the folder.

如果有一个文件夹，比如是 C:\Folder，与此同时有一个程序，其路径为 C:\Folder.exe，当你在开始—运行中输入 C:\Folder 时，会运行那个程序而不是打开那个文件夹。

Why is that?

这是为什么呢？

Because it is common to have D:\Setup.exe D:\Setup\… where there is a setup program in the root, as well as a setup folder containing files needed by the setup program.

因为同时在根目录下包含作为安装程序的 D:\Setup.exe 和作为存储安装程序所需文件的 D:\Setup\ 这个目录是很常见的情况。

Before Windows 95, you couldn’t open a folder by typing its name. (If you wanted to view it in File Manager, you had to run File Manager explicitly.) As a result, programs written for earlier versions of Windows would have instructions like

在 Windows 95 之前，你是不能通过输入目录的名字（译注：即输入到目录为止的路径）来打开一个目录的。（如果你想在“文件管理器”中查看目录的内容，你必须刻意去运行“文件管理器”）因此，为早期版本Windows撰写的程序通常都包含有类似如下的操作指南：

• Insert the floppy disk labelled “Setup”. (CDs were for the rich kids.)
  插入标有『Setup』（安装）标签的软盘。（那年头CD是有钱人才用得起的东西）
• From Program Manager, click File, then Run.
  在“程序管理器”中，单击“文件”，然后选择“运行”
• In the dialog box, type “A:\SETUP” and press Enter.
  在弹出的对话框中，输入“A:\SETUP”，然后按下回车键

Since there was no such thing as “opening a folder”, the only option was to run the program A:\SETUP.EXE.

由于并没有（通过运行对话框来）“打开目录”这种操作，（向上面这样做）唯一的结果就是运行了程序 A:\SETUP.EXE。

Windows 95 was required to prefer the program over the folder in order that those instructions would remain valid (substituting the Start button for the File menu).

Windows 95 为了能让上面这样的操作指示仍然有效，（在遇到目录和程序同名的情况时）会优先选择运行程序而不是打开目录本身（当然还要将『文件菜单』替换为『开始菜单』）。

And each version of Windows that prefers the program over the folder creates an environment wherein people who write setup programs rely on that preference, thereby securing this behavior for the next version of Windows.

另外，每个版本的 Windows 这种优先运行程序而不是打开文件夹的环境，又进一步促使用户在设计安装程序时依赖这种设计，进一步保证了这种设计可以被延续到下一个版本的 Windows 中。

But what if you really want to open the folder?

不过，如果你真的想打开那个同名目录怎么办？

Append a backslash to force the path to be interpreted as a folder (A:\SETUP\).

在最后加一个反斜杠（\），使其强制被解释为文件夹（A:\SETUP\）就可以了。

原文链接：https://devblogs.microsoft.com/oldnewthing/20041029-00/?p=37443

The taskbar created all sorts of interesting problems, since the work area was not equal to the entire screen dimensions. (Multiple monitors created similar problems.) “Why didn’t the gui return the usable workspace as the root window (excluding the taskbar)?”

任务栏制造了各种各样有趣的问题，由于它的存在，工作区域的尺寸与整个屏幕的分辨率并不是相等的。（多显示器环境同样制造了类似的问题。）『为什么GUI不将可用的工作区域作为顶层窗口（排除任务栏）返回呢？』

That would have made things even worse.

那样会让事情变得更糟糕。

Lots of programs want to cover the entire screen. Games, for example, are very keen on covering the entire screen. Slideshow programs also want to cover the entire screen. (This includes both slideshows for digital pictures as well as business presentations.) Screen savers of course must cover the entire screen.

很多程序都有遮挡整个屏幕的需求。例如游戏，在这方面的需求就很强烈。幻灯片应用程序也需要遮挡整个画面（这类程序同时包含了展示数码图片和商业幻灯的场合）。屏幕保护程序则必须遮挡住整个画面。

If the desktop window didn’t include the taskbar, then those programs would leave a taskbar visible while they did their thing. This is particularly dangerous for screen savers, since a user could just click on the taskbar to switch to another program without going through the screen saver’s password lock!

如果桌面窗口没有包含任务栏区域，那么这些程序在运行时任务栏就会可见。这种情形对屏幕保护程序尤为危险，因为这样一来用户就可以通过点击任务栏来切换到其它程序，从而绕过屏幕保护程序的密码保护了！

And if the taskbar were docked at the top or left edge of the screen, this would have resulted in the desktop window not beginning at coordinates (0,0), which would no doubt have caused widespread havoc. (Alternatively, one could have changed the coordinate system so that (0, 0) was no longer the top left corner of the screen, but that would have broken so many programs it wouldn’t have been funny.)

此外，如果任务栏停靠在屏幕的上方或边缘（译注：应当指的是左侧），会使得桌面窗口的左上角坐标不再是（0,0），而这样毫无疑问将会制造出大笔的麻烦。（换个思路想想的话，把坐标系统进行一点『小小的改动』，让左上角的坐标不再是（0,0）也是一种做法，但这样大概会搞炸一大堆程序，所以这一点也不好玩。）

原文链接：https://devblogs.microsoft.com/oldnewthing/20041028-00/?p=37453

Before Explorer was introduced in Windows 95, the Windows desktop was a very different place.

在资源管理器被引入到 Windows 95 之前，桌面是完全大相径庭的另一个物种。

The icons on your desktop did not represent files; rather, when you minimized a program, it turned into an icon on the desktop. To open a minimized program, you had to hunt for its icon, possibly minimizing other programs to get them out of the way, and then double-click it. (You could also Alt+Tab to the program.)

桌面上的图标不是用来代表文件的，与这种印象不同，当你最小化一个程序时，程序就会变成桌面上的一个图标。要打开一个最小化的程序，你得先找到它的图标，或许还得先把其他挡住视线的程序最小化，然后再双击图标（来打开这个最小化的程序）。（你也可以用Alt+Tab切换过去。）

Explorer changed the desktop model so that icons on your desktop represent objects (files, folders) rather than programs. The job of managing programs fell to the new taskbar.

资源管理器改变了桌面的模型，此后桌面上的图标就变成了代表对象（文件、文件夹）而不是程序。管理程序的任务就落到了新生的任务栏上。

But where did the windows go when you minimized them?

不过当程序最小化的时候，它的窗口去哪了呢？

Under the old model, when a window was minimized, it displayed as an icon, the icon had a particular position on the screen, and the program drew the icon in response to paint messages. (Of course, most programs deferred to DefWindowProc which just drew the icon.) In other words, the window never went away; it just changed its appearance.

在旧的模型之下，当一个窗口最小化时，其表现为一个图标，这个图标在屏幕上有特定的位置，而程序在响应描画的窗体消息时，会对这个图标进行绘制。（当然，大多数程序推迟了绘制图标的 DefWindowProc 方法。）换句话说，程序的窗口从来都没有消失，只是换了个表现形式。

But with the taskbar, the window really does go away when you minimize it. Its only presence is in the taskbar. The subject of how to handle windows when they were minimized went through several iterations, because it seemed that no matter what we did, some program somewhere didn’t like it.

但自从有了任务栏以后，最小化的程序的窗口就真的消失了，其存在就仅仅表现在任务栏中而已。对于如何管控最小化的窗口的设计经历了几次迭代，原因是不管我们做什么，总有一些应用程序不喜欢。

The first try was very simple: When a window was minimized, the Windows 95 window manager set it to hidden. That didn’t play well with many applications, which cared about the distinction between minimized (and visible) and hidden (and not visible).

第一次的尝试很简单：当一个窗口最小化后，Windows 95 的窗口管理器就将其设置为隐藏。这样的设计与很多程序配合都不好，因为这些程序会严格区分最小化（同时可见）与隐藏（同时不可见）的区别。

Next, the Windows 95 window manager minimized the window just like the old days, but put the minimized window at coordinates (-32000, -32000), This didn’t work because some programs freaked out if they found their coordinates were negative.

后来，Windows 95 的窗口管理器用以往的方法将窗口最小化，但将最小化的窗口移动到坐标（-32000，-32000）。这样做的效果依然不彰，因为有些程序发现自己的坐标是负值时感觉非常不安。

So the Windows 95 window manager tried putting minimized windows at coordinates (32000, 32000), This still didn’t work because some programs freaked out if they found their coordinates were positive and too large!

所以Windows 95的窗口管理器又转而尝试将最小化的窗口放到坐标（32000，32000）上。这样做的效果仍旧不好，因为有些程序发现自己的坐标是很大的正值时吓坏了。

Finally the Windows 95 window manager tried coordinates (3000, 3000), This seemed to keep everybody happy. Not negative, not too large, but large enough that it wouldn’t show up on the screen (at least not at screen resolutions that were readily available in 1995).

最终，Windows 95 窗口管理器将移动的坐标换成了（3000，3000），这样大家似乎都很满意了。不是负值，不是很大的值，但又足够大使得不会显示在屏幕上（至少以1995年较常见的屏幕分辨率来说如此）。

If you have a triple-monitor Windows 98 machine lying around, you can try this: Set the resolution of each monitor to 1024×768 and place them corner-to-corner. At the bottom right corner of the third monitor, you will see all your minimized windows parked out in the boonies.

如果你有一台三显示器配置的 Windows 98 机器在手边，你可以尝试这样操作一下：将每台显示器的分辨率设置为1024×768，然后将三台显示器底角对顶角地排列起来。在右下角的第三台显示器上，你就能看到那些最小化的窗口们在屏幕的『郊区』安居乐业的样子了。

(Windows NT stuck with the -32000 coordinates and didn’t pick up the compatibility fixes for some reason. I guess they figured that by the time Windows NT became popular, all those broken programs would have been fixed. In other words: Let Windows 95 do your dirty work!)

（出于某些原因，Windows NT 则保留了移动到坐标-32000的做法，没有采用（移动到坐标3000的）那个兼容性补丁。我猜开发人员们大概在想等 Windows NT 普及了，那些不听话的应用程序大概都已经修复这个问题了。换句话说：让 Windows 95 去做那些苦活吧！）

原文链接：https://devblogs.microsoft.com/oldnewthing/20041022-00/?p=37503

Windows 95 Setup would notice that a file it was installing was older than the file already on the machine and would ask you whether you wanted to keep the existing (newer) file or to overwrite it with the older version.

Windows 95 的安装程序会注意到正在安装的文件相较于机器上已有的版本比较旧，于是就会问你是否要保留现有（较新）的文件，或者用较旧的版本进行覆盖替换。（译注：用过Win95的人都知道这是一个很容易令人摸不到头脑的问题）

Asking the user this question at all turned out to have been a bad idea. It’s one of those dialogs that ask the user a question they have no idea how to answer.

事实上向用户提出这个问题本身就是一个很差劲的主意。这种对话框属于那种用户完全不知道如何作答的类型。

Say you’re installing Windows 95 and you get the file version conflict dialog box. “The file Windows is attempting to install is older than the one already on the system. Do you want to keep the newer file?” What do you do?

比如说，你正在安装Windows 95，然后碰到了一个版本冲突提示对话框，上面写着：『Windows 当前尝试安装的文件相较于您机器上的文件版本较旧，是否保留较新的文件？』你会怎么做？

Well, if you’re like most people, you say, “Um, I guess I’ll keep the newer one,” so you click Yes.

如果你跟大多数人的想法一样，会想：『唔，那就保留新版本的文件吧』，然后点击了『是』。

And then a few seconds later, you get the same prompt for some other file. And you say Yes again.

没过几秒钟，对话框又弹了出来，这次换了个文件，你又点了『是』。

And then a few seconds later, you get the same prompt for yet another file. Now you’re getting nervous. Why is the system asking you all these questions? Is it second-guessing your previous answers? Often when this happens, it’s because you’re doing something bad and the computer is giving you one more chance to change your mind before something horrible happens. Like in the movies when you have to type Yes five times before it will launch the nuclear weapons.

又过了几秒钟，对话框换了个文件又一次弹了出来，这下你开始变得焦虑起来了。为什么系统会问我这些问题？是想让我对前面的问题再作三思吗？类似这样的情况发生时，通常是因为你做错了什么事，而计算机正在事情变得无法挽留之前再给你一次改变主意的机会，就像在电影里，在发射核武器之前需要输入五次『Yes』一样。

Maybe this is one of those times.

而眼下大概就是那种场景。

Now you start saying No. Besides, it’s always safer to say No, isn’t it?

于是你开始点『否』了。说实话，说『否』更安全些，不是吗？

After a few more dialogs (answering No this time), Setup finally completes. The system reboots, and… it bluescreens.

又看过几个对话框之后（而你在面对这些对话框时都点了『否』），安装程序终于收工，计算机重启，然后……等着你的是一片蓝屏。

Why?

怎么会这样？

Because those five files were part of a matched set of files that together form your video driver. By saying Yes to some of them and No to others, you ended up with a mishmash of files that don’t work together.

因为你点了『否』的那五个文件是你的显卡驱动的一部分。对其中一部分文件选择了『是』，又对另一部分选择了『否』，结果新旧文件掺杂在一起，无法正常工作。

We learned our lesson. Setup doesn’t ask this question any more. It always overwrites the files with the ones that come with the operating system. Sure, you may lose functionality, but at least you will be able to boot. Afterwards, you can go to Windows Update and update that driver to the latest version.

我们接受了这个教训，安装程序再也不会问这类问题了，现在它总是会用随操作系统出厂的文件对其进行覆盖。的确，这样会损失一些新功能，但至少可以正常启动。在那之后，你总可以去Windows Update里将驱动更新到新版本。

Note, however, that this rule does not apply to hotfixes and Service Packs.

不过需要注意的是，这样的规则并不适用于系统补丁（Hotfix）和服务包（Service Packs）。

原文链接：https://devblogs.microsoft.com/oldnewthing/20041020-00/?p=37523

When you register your program with a file association, the shell needs to decide whether your program supports long file names so it can decide whether to pass you the long name (which may contains spaces! so make sure you put quotation marks around the “%1” in your registration) or the short name.

当你为自己的应用程序建立文件关联时，系统需要知道你的应用程序是否支持长文件名，这样才能决定是否向你的程序传递长文件名（可能会包含空格！所以请保证在注册文件关联时在%1前后包上西文引号）还是短文件名。

The rule is simple: The shell looks at your program’s EXE header to see what kind of program it is.

规则很简单：系统会依据程序exe文件的文件头来进行判断。

• If it is a 16-bit program, then the shell assumes that it supports long file names if it is marked as Windows 95-compatible. Otherwise, the shell assumes that it does not support long file anmes.
  如果是16位应用程序，并且标记为Windows 95兼容，系统会认为其支持长文件名，否则认为不支持。（译注：anmes疑为names误植，此处原样保留）
• If it is a 32-bit program (or 64-bit program for 64-bit systems), then the shell assumes that it supports long file names.
  如果是32位应用程序（或面向64位系统的64位应用程序），系统会认为其支持长文件名。
• If it can’t find your program, then the shell plays it safe and assumes that the program doesn’t support long file names.
  如果找不到你的程序，系统会保守起见认为其不支持长文件名。

Note that third case. If you mess up your program registration, then the shell will be unable to determine whether your program supports long file names and assumes not. Then when your program displays the file name in, say, the title bar, you end up displaying some icky short file name alias instead of the proper long file name that the user expects to see.

注意第三种情况。如果你注册文件关联的时候玩脱了，那么系统就无法判定你的程序是否支持长文件名，并假定其不支持。这样如果你的程序在某些地方显示文件名（比如标题栏）的话，就会显示成那种看上去很讨厌的短文件名别名，而不是用户期望看到的长文件名。

The most common way people mess up their program registration is by forgetting to quote spaces in the path to the program itself! For example, an erroneous registration might go something like this:

最常见玩脱注册文件关联的方式，是忘记将程序路径包含在引号的里面！例如，某程序错误地注册文件关联的情况如下所示：

HKEY_CLASSES_ROOT\litfile\shell\open\command

(default) = C:\Program Files\LitWare Deluxe\litware.exe “%1”

Observe that the spaces in the path “C:\Program Files\Litware Deluxe\litware.exe” are not quoted in the program registration. Consequently, the shell mistakenly believes that the program name is “C:\Program”, which it cannot find. The shell therefore plays it safe and assumes no LFN support.

注意观察程序路径『C:\Program Files\Litware Deluxe\litware.exe』并没有用引号括起来。由此，系统便错误地认为程序的名称是『C:\Program』，并且也找不到对应的文件，所以系统决定保守起见，认为这个程序不支持长文件名。

Compatibility note: As part of other security work, the code in the shell that parses these command lines was augmented to chase down the “intended” path of the program. This presented the opportunity to fix that third case, so that the shell could find the program after all and see that it supported long file names, thereby saving the user the ignominy of seeing their wonderful file name turn into a mush of tildes.

这里有一个兼容性相关的小故事：作为安全方面考量的一环，系统中有关处理这些命令行的代码曾被要求可以主动找出对应程序『原本』的路径。这样的设计提供了一种对前述第三种情况补救的机会，系统可能因此找到对应的程序文件，并实际判断其是否支持长文件名，如此一来用户就不会对其美妙的文件名变成一堆小浪花（译注：~符号，长文件名压缩到短文件名时用以区别多个压缩后同名文件的机制之一，形如FILENA~1.DOC、FILENA~2.DOC等）而干瞪眼了。

And after we made the change, we had to take it out.

我们在做出这样的改进后，又不得不将其撤了下来。

Because there were programs that not only registered themselves incorrectly, but were relying on the shell not being smart enough to find their real location, resulting in the program receiving the short name on the command line. Turns out these programs wanted the short name, and doing this fake-out was their way of accomplishing it.

因为（这样改进之后）某些应用程序不光不用正确的方式去注册文件关联，甚至还依赖这种原先系统无法找到其程序文件的缺陷，由此使系统传短文件名进去。我们发现这个程序就是想要短文件名，而它则是用这种欺骗的手段来达成目的的。

(And to those of you who are already shouting, “Go ahead and break them,” that’s all fine and good as long as the thing that’s incompatible isn’t something you use. But if it’s your program, or a program your company relies on, I expect you’re going to change your tune.)

（此外，对那些此时已经在大喊『那就别管他们啊』的人们，只要这不是你非用不可的软件，怎么样都是好的。但如果这样做的就是你的软件，或者你们公司依赖的软件，我很乐意看到你收回你的说法。）