请注意:本页内容发布于 1889 天前,内容可能已经过时,请注意甄别。
原文链接:https://devblogs.microsoft.com/oldnewthing/20040709-00/?p=38493
If the program doesn’t provide this information itself, Add/Remove Programs is forced to guess.
如果应用程序没有主动提供这些信息,『添加/删除程序』不得已就得用猜的了。
The problem is that there is no “obvious” way to map an entry in the Add/Remove Programs list to an actual program. Each entry in the list, for those who care about such things, comes from the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall registry key. The only mandatory properties for an uninstallable program are the DisplayName and the UninstallPath. Everything else is optional.
问题在于,『添加/删除程序』并没有一种明确的手段将一项(已安装程序的)条目与实际的应用程序关联起来。为关注相关事项的人服务一把:(『添加/删除程序』中的)每一个条目都取自注册表键 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall。对于每个可以卸载的应用程序而言,必需的条目是 DisplayName 和 UninstallPath,剩下的都是可选项。
Let’s suppose Add/Remove Programs is given a program registration like this:
假设有以下注册表信息被给予了『添加/删除程序』:
HKEY_LOCAL_MACHINE\
Software\
Microsoft\
Windows\
CurrentVersion\
Uninstall\
SomeProgram
DisplayName=REG_SZ:”Awesome Program for Windows”
UninstallPath=REG_SZ:”C:\WINDOWS\uninstall.exe -SomeParameters”
In order to get the “Last Used” and “Frequency” values, Add/Remove Programs needs to know the name of the EXE so it can ask the Start menu “Hey, how often did the user run this program, and when was the last time it happened?”
为了获取『最近使用时间』和『使用频率』的值,『添加/删除程序』需要知道应用程序主程序的EXE文件名,这样才能向开始菜单咨询:『嗨,用户有多经常运行这个应用程序,上次运行又是什么时候的事情呀?』
Notice that there are no clues in the registration above as to the identity of this EXE file.
请注意,上述注册表信息中,并无辨认应用程序主程序EXE文件的线索。
So Add/Remove Programs starts guessing. It goes through all the programs on your Start menu and compares their names with the display name of the uninstallable item. It looks for Start menu items which share at least two words with the words in the DisplayName.
于是『添加/删除程序』就开始靠猜的了。『添加/删除程序』遍历开始菜单,将上述注册表信息提供的、可卸载应用程序的『显示名称』与开始菜单中的条目进行比较,标准是有至少两个单词与 DisplayName 相同。
For example, if there were a Start menu item called “Pretty Decent Windows Program”, this would count as a two-word match (“Windows” and “Program”).
例如,如果有一个开始菜单条目叫『Pretty Decent Windows Program』,这样就算有两个单词相符(Windows 和 Program)(译注:前例中的 DisplayName 叫 Awesome Program for Windows)了。
It then takes the one with the most matches and decides, “Okay, I guess this is it.” Suppose for the sake of illustration that the best match is indeed “Pretty Decent Windows Program.lnk”, which is a shortcut to “C:\Program Files\LitWare\Decent Program\Decent.exe”. Add/Remove Programs would decide that “Awesome Program for Windows” should get the icon for “Pretty Decent Windows Program.lnk”, that the frequency of use and most-recently-used information for “C:\Program Files\LitWare\Decent Program\Decent.exe” will be displayed for “Awesome Program for Windows”.
『添加/删除程序』会挑选相似程度最高的一项,然后下定决心说:『行了,依我看就是它了。』假设在本例中,相似程度最高的一项正好是『Pretty Decent Windows Program.lnk』,而它是到『C:\Program Files\LitWare\Decent Program\Decent.exe』的快捷方式,『添加/删除程序』便由此决定『Awesome Program for Windows』应当采用『Pretty Decent Windows Program.lnk』的图标,而使用频率和最近使用时间的信息则取自『C:\Program Files\LitWare\Decent Program\Decent.exe』。
But wait, there’s more. There’s also the program size. Add/Remove Programs looks in your “Program Files” directory for directories whose names share at least two words in common with the DisplayName. The best match is assumed to be the directory that the program files are installed into. The sizes are added together and reported as the size of “Awesome Program for Windows”.
不过等等,还没完。还有一项信息叫『大小』。『添加/删除程序』将在『Program Files』目录中查找与 DisplayName 有至少两个单词相同的项目,而该项目则被视为应用程序的安装目录。将这个目录下的文件大小汇总一下,这个数字就作为『Awesome Program for Windows』的『大小』了。
A program can add some properties to its registration to avoid a lot of this guessing. It can set an EstimatedSize property to avoid making Add/Remove Programs guess how big the program is. It can also set a DisplayIcon property to specify which icon to show for the program in the list.
应用程序可以在向注册表中写入信息时主动指定对应的属性值来避免上述的猜测工作,比如可以通过设置 EstimatedSize 属性来省去『添加/删除程序』估算应用程序的大小,也可以通过设置 DisplayIcon 来指定在列表中应用程序的图标。
But if a program omits all of these hints, the guess that Add/Remove Programs ends up making can often be ridiculously wide of the mark due to coincidental word matches. In my experience, Spanish suffers particularly badly from this algorithm, due to that language’s heavy use of prepositions and articles (which result in a lot of false matches).
不过,如果某个应用程序完全无视这些提示的话,『添加/删除程序』估测出来的信息有可能因为巧合的单词相符而与实际情况大相径庭。据我个人经验而言,西班牙语(的条目)在面对这一算法时误差最大,原因是西班牙语中的介词和冠词的使用极其频繁(因而造成了大量的误匹配)。
Yes, this is all lame, but when you are forced to operate with inadequate information, lame is the best you can do.
没错,这个机制是很蹩脚,但当你被迫用不完整的信息来构建资料时,做到蹩脚已是最好的结果。
[July 15 2004: Emphasizing that this is done only if the program fails to provide the information itself. For some reason, a lot of people who link to this page fail to notice that little detail.]
(2004年7月15日更新:强调一下,『添加/删除程序』只有在应用程序未能提供相关信息时才会进行上述的猜测工作。不知为何,很多链接到这个页面的读者都忽略了这一细节。)
感觉这就是个鸡肋特性。不仅没什么实际意义,还严重拖慢打开『添加/删除程序』时的速度。