TONT 40663 好的先生，没问题先生

包治百病。

原文链接：https://blogs.msdn.microsoft.com/oldnewthing/20040211-00/?p=40663

The DirectX video driver interface for Windows 95 had a method that each driver exposed called something like “DoesDriverSupport(REFGUID guidCapability)” where we handed it a capability GUID and it said whether or not that feature was supported.

Windows 95的DirectX视频驱动接口中，每个驱动都公开一个方法，名字类似于DoesDriverSupport(REFGUID guidCapability)（驱动是否支持某特性（REFGUID 相关特性GUID）），使用时会传入一个特性GUID，而其会返回该驱动对此特性的支持与否情况。

There were various capability GUIDs defined, things like GUID_CanStretchAlpha to ask the driver whether it was capable of stretching a bitmap with an alpha channel.

系统有一系列预定义的特性GUID，例如GUID_CanStretchAlpha用来询问驱动程序其是否可以拉伸带有Alpha通道的位图图像。

There was one driver that returned TRUE when you called DoesDriverSupport(GUID_XYZ), but when DirectDraw tried to use that capability, it failed, and in a pretty spectacular manner.

某个驱动当调用DoesDriverSupport(GUID_XYZ)时返回了True，但等到DirectDraw真的去调用这个特性时，却会遭遇失败，而且失败得惊天动地。

So one of the DirectDraw developers called the vendor and asked them, “So does your card do XYZ?”

后来DirectDraw开发组的一位同事向硬件的供应商咨询，问道：『你们的办卡支持XYZ吗？』

Their response: “What’s XYZ?”

对方的回答是：『XYZ是啥玩意儿？』

Turns out that their driver’s implementation of DoesDriverSupport was something like this:

后来我们才知道，他们的驱动里对DoesDriverSupport的实现大体是这个样子的：

BOOL DoesDriverSupport(REFGUID guidCapability)
{
return TRUE;
}

In other words, whenever DirectX asked, “Can you do this?” they answered, “Sure, we do that,” without even checking what the question was.

换句话说，每当DirectX提问『你支持这个特性不？』的时候，驱动总是会回报：『好的先生，没问题先生』，实际上却根本不在乎问题的内容。

(The driver must have been written by the sales department.)

（这驱动肯定是他们的销售部门写的。）

So the DirectDraw folks changed the way they queried for driver capabilities. One of the developers went into his boss’s office, took a network card, extracted the MAC address, and then smashed the card with a hammer.

因此DirectDraw的开发组改变了检测驱动支持特性的方式。开发组的一位同事走进他们经理的办公室，拿出一张网卡，抄下了它的MAC地址，然后把网卡用锤子砸碎了。

You see, this last step was important: The GUID generation algorithm is based on a combination of time and space. When you ask CoCreateGuid to create a new GUID, it encodes the time of your request in the first part of the GUID and information that uniquely identifies your machine (the network card’s MAC address, which is required to be unique by the standards that apply to network card).

要知道，最后一步是很重要的：GUID的生成算法基于时间和空间的组合。当你调用CoCreateGuid来创建一个新的GUID时，函数会将你调用它的时间编码进GUID的第一部分中，同时被编码进去的还有可以唯一指认你的机器的信息（即本机网卡的MAC地址，这个地址基于网卡的制造标准，必须是（全球）唯一的值）。

By smashing the network card with a hammer, he prevented that network card from ever being used to generate a GUID.

通过把那块网卡用锤子砸碎，那块网卡（的MAC地址）就再也不能被用来生成GUID了。

Next, he added code to DirectDraw so that when it starts up, it manufactures a random GUID based on that network card (which – by its having been destroyed – can never be validly created) and passes it to DoesDriverSupport. If the driver says, “Sure, we do that”, DirectDraw says, “Aha! Caught you! I will not believe anything you say from now on.”

接下来，他在DirectDraw中增加了相应的代码，这样在其初始化时，DirectDraw就会基于那块（被砸碎的）网卡（的MAC地址）生成一个随机的GUID（鉴于那块网卡已经被销毁，基于其地址生成的GUID统统都不可能是有效的），然后把这个GUID传入DoesDriverSupport里。如果驱动回报：『好的先生，没问题先生』，DirectDraw立刻就知道：『嘿，抓到你啦！从现在开始你说什么东西我也不会再相信了。』