TONT 37523 资源管理器是如何检测你的程序是否支持长文件名的？

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

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