分类： Win故知新

原文链接：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.)

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

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

The Listview control when placed in report mode has a child header control which it uses to display column header titles. This header control is the property of the listview, but the listview is kind enough to let you retrieve the handle to that header control.

当Listview控件置于报表模式下时，其内有一个表头控件，用来展示列标题。这个表头控件是属于Listview的“私有财产”，不过Listview很大方，允许你去获取这个表头空间的句柄。

And some programs abuse that kindness.

而有些应用程序就滥用了这种大方。

It so happens that the original listview control did not use the lParam of the header control item for anything. So some programs said, “Well, if you’re not using it, then I will!” and stashed their own private data into it.

凑巧，原始版本的Listview没有使用这个表头控件的lParam，这时个别程序就决定，『你不用的话，我就用一下好了！』然后将其内部数据塞了进去。

Then a later version of the listview decided, “Gosh, there’s some data I need to keep track of for each header item. Fortunately, since this is my header control, I can stash my data in the lParam of the header item.”

后续版本的Listview做了个决定：『哎呀，这些个表头有些数据我得跟踪监视，不过还好，这个表头控件是属于我的，只要把数据藏进lParam里去修好了。』

And then the application compatibility team takes those two ingredients (the program that stuffs data into the header control and the listview that does the same) to their laboratory, mixes them, and an explosion occurs.

后来，应用程序兼容性团队把这两种成分（把私有数据塞进表头控件里的应用、和同样这样做的Listview）带进了实验室，将二者混合，然后就炸了。

After some forensic analysis, the listview development team figures out what happened and curses that they have to work around yet another program that grovels into internal data structures. The auxiliary data is now stored in some other less convenient place so those programs can continue to run without crashing.

经过一番正经八百的论证，Listview控件的开发团队找到了问题的原因，并选择在这又一个随便挖进内部数据结构的应用程序面前退让一步。前面提到的辅助数据现在被放进了不太容易被乱来的地方，这样那个乱改（Listview）内部数据的程序就能继续运行而不崩溃了。

The moral of the story: Even if you change something that nobody should be relying on, there’s a decent chance that somebody is relying on it.

故事的寓意是：即便你修改了别人不该依赖的位置，还是有相当的可能有人是依赖它的。

(I’m sure there will be the usual chorus of people who will say, “You should’ve just broken them.” What if I told you that one of the programs that does this is a widly-used system administration tool? Eh, that probably wouldn’t change your mind.)

（我敢肯定肯定又有很多人要说，『别管那家伙不就好了』，要是我告诉你这样做的程序之一是某个被广泛使用的系统管理工具呢？不过，这大概也不会让你收回前言吧。）

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

If the system directory is always %windir%\SYSTEM32, why is there a special function to get it?

如果系统目录总会是 %windir%\SYSTEM32，为什么还有专门的一个方法来获取它？

Because it wasn’t always that.

因为并不总是如此。

For 16-bit programs on Windows NT, the system directory is %windir%\SYSTEM. That’s also the name of the system directory for Windows 95-based systems and all the 16-bit versions of Windows.

对于 Windows NT 下的 16 位应用程序来说，系统目录是 %windir%\SYSTEM。对于以 Windows 95 为基础、以及所有16位版本的 Windows 来说也是如此。

But even in the 16-bit world, if it was always %windir%\SYSTEM, why have a function for it?

然而，即便在16位的世界里，如果系统目录总会是 %windir%\SYSTEM 的话，那为什么还需要专门的一个方法呢？

Because even in the 16-bit world, it wasn’t always %windir%\SYSTEM.

因为即使在16位的世界里，也并不总是如此。

Back in the old days, you could run Windows directly over the network. All the system files were kept on the network server, and only the user’s files were kept on the local machine. What’s more, every single computer on the network used the same system directory on the server. There was only one copy of USER.EXE, for example, which everybody shared.

在过去，你可以直接通过网络来运行Windows。所有的系统文件都存放在网络服务器上，只有用户的文件保存在本地。另外，网络上的所有计算机都会调用服务器上相同的系统目录，例如，只会有一份USER.exe供所有人共享使用。

Under this network-based Windows configuration, the system directory was a directory on a server somewhere (\\server\share\somewhere) and the Windows directory was a directory on the local machine (C:\WINDOWS). Clients did not have write permission into the shared system directory, but they did have permission to write into the Windows directory.

在这种以网络为基础配置的Windows环境下，系统目录是存放在服务器上的某处的（例如\\server\共享名\共享目录），而Windows目录是本机上的某个文件夹（例如C:\WINDOWS）。客户端没有权限写入系统目录，不过的确有权限对Windows目录进行写入。

That’s why GetSystemDirectory is a separate function.

这就是为什么GetSystemDirectory是单独存在的一个方法。

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

I didn’t debug it personally, but I know the people who did. During Windows XP development, a bug arrived on a computer game that crashed only after you got to one of the higher levels.

我并不亲自进行调试工作，不过我认识做这项工作的人。在 Windows XP 的开发过程中，曾经有款游戏的一个 bug，只有玩到进度比较深入的时候才会显现，并使游戏崩溃。

After many saved and restored games, the problem was finally identified.

存档读档很多次之后，问题终于定位出来了。

The program does its video work in an offscreen buffer and transfers it to the screen when it’s done. When it draws text with a shadow, it first draws the text in black, offset down one and right one pixel, then draws it again in the foreground color.

游戏的程序在一处屏幕外的缓冲区中处理图像，当处理完成后，再传输到屏幕上。绘制带阴影的文字时，程序会先以黑色将文字绘制一遍，将其向右、向下移动各1个像素，然后再用前景色将文字绘制出来。

So far so good.

到此为止还没什么问题。

Except that it didn’t check whether moving down and right one pixel was going to go beyond the end of the screen buffer.

只是开发商忘了检查向右、向下移动各1个像素的时候，有没有超出屏幕缓冲区的边界。

That’s why it took until one of the higher levels before the bug manifested itself. Not until then did you accomplish a mission whose name contained a lowercase letter with a descender! Shifting the descender down one pixel caused the bottom row of pixels in the character to extend past the video buffer and start corrupting memory.

这就是为什么只有打到高等级的时候 bug 才会显现，因为直到那时才会完成一个任务，而这个任务的名字里有一个带下延部^（注1）的小写字母！将这个字母的下延部下移1个像素，会导致底部一行的像素超出视频缓冲区，进而损毁了内存数据。

Once the problem was identified, fixing it was comparatively easy. The application compatibility team has a bag of tricks, and one of them is called “HeapPadAllocation”. This particular compatibility fix adds padding to every heap allocation so that when a program overruns a heap buffer, all that gets corrupted is the padding. Enable that fix for the bad program (specifying the amount of padding necessary, in this case, one row’s worth of pixels), and run through the game again. No crash this time.

找到问题的根源后，修复起来就相对比较容易了。应用程序兼容性团队有一口袋的戏法，其中之一名叫『HeapPadAllocation』。这一兼容性修复补丁会为每个堆分配增加一块补丁，这样当程序发生了堆缓冲区溢出的问题时，弄坏的就只是这块补丁而已。为这个惹事的程序启用这个补丁（指定所需的补丁大小，此处即1行像素的尺寸），再运行游戏，就不会再崩溃了。

What made this interesting to me was that you had to play the game for hours before the bug finally surfaced.

这件事让我感到有趣的一点是，你得把这款游戏先玩上4个小时，然后bug才会崭露头角。

注1：在西文字体排印学中，降部（英语：Descender）指的是一个字体中，字母向下延伸超过基线的笔画部分，也称为下延部。如图所示，字母y第二笔的“尾巴”部分就是降部。另外字母v两条对角线连接的时候也有超过基线的部分，虽然很少，但也是降部。（以上信息来自维基百科『降部』词条）