关于注册表向后兼容的悲伤故事

当你尝试设计一个操作系统的时候，向后兼容性，是其中一个你不得不考虑的问题。如果新的应用程序依赖那些为旧版应用程序设计的”小技巧”时，你就得发狂了。

在很久很久以前的一个遥远星系(Windows 95的Beta发布版本的代号是”M3″)，我们将那些用来描述特定文件夹的位置的信息保存到了名为”Shell Folders”的注册表键下面，这样应用程序就可以通过读取这些注册表值来获取类似于字体或者我的文档之类的文件夹的路径。

开发人员收到了Windows 95 M3版本，并按照文档的说明使用了上述的注册表键名。同时，Windows 95继续开发着，我们意识到，使用注册表键错误的保存这一路径信息是不合适的，因为很多东西(类似于控制面板)都不是文件夹，所以它们就不能在注册表中进行很好地表达。

另一方面，我们没有考虑到Windows NT系统引入的用户配置文件漫游的特性，这一特性允许用户可以随意移动他们的配置文件，所以将一个硬编码的路径保存在注册表中不是一个好主意。 所以，我们添加了一个新的API函数SHGetSpecialFolderLocation，并且更新了开发文档来指导开发者使用新的方法来获取特殊文件夹的路径。而原来使用的注册表方法也从开发文档中移除了。

但是为了简化M3文档到RTM版本文档的迁移，我们还是暂时留下了关于注册表这一部分，但是实际上它不再存储之前我们设计的信息，而只是真实数据(用户外壳目录)的一个映射。随后，我们发布了带有这个临时注册表的Windows 95 RTM版本，因为我们意识到还有很少一部分应用程序(大概是四个)还没有能从注册表方法迁移到新的API方法。所以，我们对这个注册表键的支持减少了很多，所以这个方法就刚刚好能让这四个应用程序继续正常工作。所有新开发的应用程序都会使用SHGetSpecialFolderLocation这个API。

换句话说，临时保留的”Shell Folders”注册表键的存在只是为了这四个应用程序能正常的在Windows 95 RTM上正常工作而已。

你应该可以猜到接下来发生的故事。

Windows 95发布了，大家都希望在上面写自己的应用程序。但是阅读开发文档就需要花费很多的时间和精力。所以，每当有人需要设置个什么东西的时候，他可能不想阅读那么一大堆的技术文档，而是直接在注册表里直接改。(是不是听起来很熟悉呢？直到今天，还有很多人这么做)所以，后面就很多的开发者没有按照文档的要求调用SHGetSpecialFolderLocation，而是直接去访问”Shell Folders”这个注册表键。但他们不知道的是，保留这个注册表仅仅是为了之前那很少一小部分应用能正常运行而已。

举个例子，你知道吗？如果你从来没有打开过字体文件夹，或者没有任何应用程序调用过SHGetSpecialFolderLocation(CSIDL_FONTS)，则注册表中的”Shell Folders”下根本不会出现”Fonts”这个条目。因为它只是在有人明确请求的情况下才会创建。当然，当你测试你的应用程序，你不会重新格式化硬盘，然后安装Windows 95，然后再进行测试。你只是将应用程序的文件拷贝到Windows 95上然后运行可靠效果。接下来，有趣的事情发生了。因为几个月之前的测试中，你偶然的至少打开了字体文件夹一次，所以”Fonts”这个条目会在注册表中创建，应用程序会如预期般运行。但如果到了我们的应用程序兼容性测试实验室，情况就不一样了。你的应用程序在运行之前，我们实验室的电脑重新格式化并重装了系统，应用程序不能正常工作了。然后，我们的开发人员不得不研究为什么应用程序不能正常工作，最后，他们发现，应用程序在全新环境下的第一次运行都会出现错误。

是时候抛出一个哲学性的问题了：如果一个应用程序第一次总是不能正常运行，那么它在今天没有正常运行是一个Bug吗？

可能有些人会说了：这里有一个注册表名字”User Shell Folders”比之前的”Shell Folders”更酷一些，让我去试试看。

求求你，不要这样测试并请不要依赖新的注册表名字。而是使用SHGetFolderPath这个API，它会返回你想得到的任何文件夹的路径。还是不要再打扰”User Shell Folders”了吧。

因为在Vista中我们实现更多和用户配置相关的功能，所以对于我个人来说，如果我们因为向后兼容的问题，移除掉”User Shell Folders”而使用新的”Real User Shell Folders”的话，我会十分生气。

我十分怀疑，在最初创建“Shell Folders”键的四个程序中，没有一个程序今天仍然存在。