[wolfgke]

> Do you think Ms would sign drivers that did the opposite of their guidelines?

According to

> https://technet.microsoft.com/en-us/library/eb9b35a3-64e9-4c...

the central component that Microsoft requires is a code signing certificate (i.e. money and perhaps a little boring bureaucracy, which still can be done in a very systematic way). What Microsoft tests internally at the drivers is whether they have potential dangerous security bugs (e.g. buffer overflows). You can architect the drivers as you want to (though Microsoft provides guidelines and reference source code to make it easier to write drivers "the officially desired way").

Getting the drivers into the Linux kernel means - as one can see - going deeply into kernel politics. If Microsoft required something similarly, the hardware vendors would tap their forehead at Microsoft.

[msandford]

Great point! Microsoft does require something similar. You _only get to use the APIs they provide_ which absolutely means that you don't get to write kernel patches to change the source of the kernel to invent new APIs which you want to use to write drivers for your product. So yeah, Microsoft does exactly this.

It's not as though if AMD had developed drivers for Linux first that they could then go bully MS into allowing them to patch the Windows kernel so that they didn't have to modify their Linux drivers to get them ported to Windows.

[AsyncAwait]

> Getting the drivers into the Linux kernel means - as one can see - going deeply into kernel politics. If Microsoft required something similarly, the hardware vendors would tap their forehead at Microsoft.

I'd imagine if you wanted to include code in the NT kernel they would. But since they don't allow you to include your code in the NT kernel at all, they don't require what the Linux kernel developers require,

i.e. MS is not providing the same level of access, so it doesn't have the same requirements.