So what exactly does a draft API mean? What we have done is work with all the vendors. We have gotten their requirements and we have defined the APIs with all the arguments, the return values and everything they accomplish. This is our plan for what we will deliver with SP1. There is a period of time until the end of January where we will be talking with vendors and getting their detailed feedback. So far, we have gotten feedback on the scenarios they are trying to address and their requirements around those scenarios: Why is it that you want an API and what do you want to do with that API? Now we are giving them the actual API itself and they are going to read the document and tell us whether it accomplishes all the scenarios they want or not. Over the next few weeks, we will work with them to see if there are any changes that are needed. Hopefully everybody will agree this is the right set of APIs and this is what we will deliver in SP1.

How will Microsoft handle requests for new APIs from security vendors in future? We will continue to work with them. We have an e-mail alias and regular monthly meetings where they can come and ask for additional requirements. This set we described today is based on all of the things they brought to us so far. They can obviously come work directly with us, or they can send e-mail to that alias and we will prioritize it and add those APIs. To be clear, all of the vendors that we know about we have talked to directly and told them the approach we are taking. They are all fine with it. They all like the idea. They believe they can achieve a majority of the functionality they want with just this first set of APIs

Some vendors have asked that Microsoft allow them the same access to the kernel as they have been allowed in the past with 32-bit Windows. Has your position changed? You've got to be careful when talking about access to the kernel. All of our partners have always had access to the kernel. What we offer is access to extend the functionality of the kernel through documented APIs. What we have always said is that we don't want third parties modifying the kernel itself to achieve some functionality because that is not supportable, because is it not using documented interfaces. Every time we release a service pack or a new version of Windows we break their application. So our definition of access to the kernel is access through documented supported APIs and we haven't changed that.

We will continue to add APIs to make sure [vendors] get everything they want. But our stance on kernel patch protection has not changed. We do not turn it off. There is no way to turn it off because if we do turn it off, basically there is no security in the kernel. We didn't have that opportunity on 32-bit because of a lot of application compatibility issues. There were lots of applications and device drivers that patched the kernel and we felt that if we tightened security using the same measures it would break a lot of applications. So we decided to do it on 64-bit because those drivers and those applications have to be modified anyway. We felt this was the only opportunity and if we didn't do it now we would never be able to clean up the kernel ecosystem.