向API添加标志位并不具备扩展性

acoputojos

之前，我曾提到网络交互中存在的一些兼容性问题，有人提出了他的解决方案：可以在 IShellFolder::EnumObjects 中添加一个标志，来表明调用者是希望使用快速模式的枚举还是慢速模式的枚举。
我想说的是，通过向 API 函数添加一个标志位参数来解决驱动中的问题，从长远来看，并不能对解决问题有帮助。
我们考虑这样一种场景：如果一个视频驱动有 Bug，如果 Windows 想解决的视频驱动程序的错误，假设 Windows 决定向应用程序显示所有这些错误及其解决方法，那么像ExtTextOut 这样的函数将有几十个标志来控制各种优化，这些优化适用于所有驱动程序，除了一个。
对 ExtTextOut 的调用会变成这样：

其中每个奇怪的标志都表明你希望获得每个标志启用的性能优势，因为运行的不是视频驱动程序版本，该版本具有创建每个标志的特定错误。
然后（仍然假设地谈论）在 Windows Vista 中，你会发现你的程序运行速度比 Windows XP 慢：假设在视频驱动程序中发现了一个错误，其中长度超过1024个字符的字符串出现乱码。因此，Windows Vista 包含将所有字符串分解为 1024 个字符的块的代码，但作为优化，你可以传递
ETO_PASS_LONG_STRINGS_TO_DRIVER 标志以告知 GDI 不要使用此变通办法。Windows XP 程序不使用此标志，因此它现在在 Windows Vista 上运行速度较慢。你必须将更新发送到你的程序才能回到原来的位置。
它也不仅限于标志。按照这种”不要试图掩盖驱动程序错误，只是让应用程序处理它们”的理念，你会在 FindNextFile 文档中看到以下奇怪的段落：
如果 FindNextFile 函数返回 FALSE 并将错误代码设置为 ERROR_NO_MORE_FILES，则没有更多匹配的文件。一些非常旧的 Lan Manager 服务器（大约 1994 年）过早地报告了此错误情况。如果要枚举旧 Lan 管理器服务器中的文件，并且 FindNextFile 函数指示没有更多文件，请再次调用该函数以确认确实没有更多文件。
也许只有我，但我不认为驱动程序问题的解决方法应该像合同一样。我认为操作系统的目标之一是消除这些颠簸，并为应用程序提供统一的编程模型。应用程序在处理自己的错误时遇到了足够的麻烦，你不希望他们也不得不处理驱动程序错误。
总结

尽可能地在设计之初就固定好各个组件之间的接口参数，而不是在后期为了解决问题而随意添加参数，这样只会让代码的”坏味道”越来越重，最后积重难返。
最后

Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一，里面有很多关于Windows的小知识，对于广大Windows平台开发者来说，确实十分有帮助。
本文来自：《Adding flags to APIs to work around driver bugs doesn’t scale》


来源：
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！