轶事一则：码农何必为难码农

有这么一个事儿

在Windows95的DirectX视频驱动程序接口暴露出一种公开方法，每个驱动程序都必须实现它，它被称为”DoesDriverSupport(REFGUID guidCapability)”，我们会传递一个指示功能的GUID给这个方法，然后接口方法会返回一个值，指示该驱动是否支持该功能。

我们定义了各种功能的GUID，例如GUID_CanStretchAlpha，它主要用来询问驱动程序是否能够通过Alpha通道来扩展位图。

有一次，我们调用DoesDriverSupport(GUID_XYZ)时，有一个驱动程序返回了TRUE，但是当DirectDraw尝试使用该功能时，它以一种非常引人注目的方式失败了。

因此，这名DirectDraw开发人员致电该驱动程序开发商，并问他们：”你们的视频开也可以支持XYZ吗?”

他们的回答是：”什么是XYZ?”

事实证明，他们的驱动程序对DidDriverSupport的实现是这样的：

换句话说，每当DirectX询问驱动程序：”你支持这个功能吗？” 他们回答说：”当然，我们是支持的。”

而驱动程序甚至没有检查要支持的功能是什么。

(我想，驱动程序大抵是由销售部门编写的吧。没有任何冒犯之意)

因此，DirectDraw的开发人员改变了他们查询驱动程序功能的方式。其中一名开发人员走进老板的办公室，拿了一张网卡，提取了MAC地址，然后用锤子砸碎了这张网卡。

你会看到，这最后一步很重要：GUID生成算法基于时间和空间的组合。当你要求CoCreateGuid创建一个新的GUID时，它将在GUID的第一部分中编码你的请求时间，并唯一标识你的计算机的信息(网卡的MAC地址，适用于该标准的网卡必须是唯一的网卡)。

通过用锤子砸碎网卡，他阻止了该网卡被用来生成GUID。

接下来，他在DirectDraw中添加了代码，以便在启动时，它会基于该网卡(由于其被销毁而无法有效创建)制造一个随机GUID，并将其传递给DidDriverSupport。如果驾驶员说：”当然，我们支持这个功能”，DirectDraw会说：”啊！终于抓到你了！从现在开始，我不会相信你所说的话。”

总结

所以，大家看懂这个故事了吗？

接口定义了组件需要实现功能，但是组件可没有义务一定实现接口描述的规范，我还是希望：大部分组件开发者还是老老实实按规矩办事儿吧，码农何必为难码农，对不对？

最后

Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一，里面有很多关于Windows的小知识，对于广大Windows平台开发者来说，确实十分有帮助。

本文来自：《Sure, we do that》