How Often should the Windows SDK be updated?

The Windows SDK is typically updated only when a Windows operating system or the .NET Framework reaches a major milestone or is released.  Unfortunately, this leaves large gaps of time between SDK updates.  Are there parts of the SDK would you like to see updated more frequently? i.e. Documentation, Samples, Tools, Headers, Libraries, etc.


The MSDN Windows SDK Developer Center is the place to find resources and links to Windows SDK products, release notes, technical articles, and more.

Comments (9)

  1. Koby Kahane says:

    Documentation for the Windows Driver Kit is now updated every few weeks. I think a similar arrangement would be welcome with the Windows SDK documentation. It’s probably possible to throw in updated Samples into the mix, as well.

    Not everyone likes depending on the online MSDN documentation. For example, there is no offline version of the updated documentation for MFC and TR1 in the Visual C++ 2008 Feature Pack. An offline version of that is not expected to be available until the MSDN Library for the upcoming Visual Studio 2008 SP1. It’s inconvenient to have to go online to look up TR1 classes. Similarly, the latest Windows SDK documentation should always be available in a convenient offline package.

    As for Tools, Headers and Libraries – those are probably best kept for more explicit and orderly releases in order to avoid versioning madness. If there’s a critical issue with a tool or header, a SDK QFE could be rolled out.

    That’s my two cents.

  2. Mike Dunn says:

    Once I get a dev machine set up and working, I don’t change *anything* related to VC or SDKs because I need the machine to be rock-stable. I’m still using the first Windows SDK on my home machine because it works perfectly fine for me. The only time I mess with the setup is for a new version of VC.

    So for me, more frequest SDK releases aren’t valuable. A new SDK for each new OS version seems reasonable. It would also be very much appreciated if you’d stop breaking backcompat with older versions of VC (which is another reason I don’t update the WSDK, I never know if my perfectly-working VC will be rendered useless by a new WSDK).

  3. Gregory Attila Far says:

    If you do not want to roll out frequently full SDK packages, you could open a "beta" program, where you could roll out QFE packages or just that parts of the SDK what necessary or updated (like WDK beta program).

  4. My latest in a series of the weekly, or more often, summary of interesting links I come across related to Visual Studio. Visual Studio 2008 KB: Also applies to VS 2005. Workaround for ‘getaddrinfo’ could not be located in the dynamic link library WS2_32

  5. JamesNT says:

    I like the way they are released now.


  6. Do you think that the Windows SDK should be updated more frequently?  Less frequently?  Why?  

  7. tarlano says:

    The identification schemes of the WinSDK has always been a weak point.

    Please start using a numbering scheme.. Ie X.Y in the name of the releases.

    We should stop talking about WinSDK and start talking about WinSDK X.Y, so it’s instantaneously clear what version is installed and being used..  

  8. says:

    Well, since you asked, I think the WinSDK product has run off the tracks a little.  Why does Visual Studio install 5 other "WinSDK items" that don’t get uninstalled when Visual Studio gets uninstalled?  Why does the WinSDK install so much stuff that is part of the Visual Studio SKU?  Why don’t you just abandon the concept of the WinSDK and make it part of Visual Studio that is updated via patches?

  9. yan047 says:

    IMO, WinSDK definitely should only be updated with major milestones of Windows platform or .Net Framework.

    As stated on the top of this page, it is about SDK for platform and framework. Naturally, the updating of SDK means the updating of platform or framework. It would be a nightmare for deploying and application support if it were required to track dozens of version numbers of platforms or frameworks.

    For the frequently updated libraries, independent component library release is more plausible. This is the perfect time when we need libraries. Also, this will make developers crystal clear about the component/library dependencies by referencing ‘third party’(even it comes from Microsoft) libraries when organizing projects. The system requirement will be component XYZ on top of general platform/.Net framework as it is today.

    I dare not imagine the system requirement of platform a.b.c plus .Net Framework d.e.f. It would be a huge burden for the developers to sort that frightening requirement back to component XYZ on top of general platform for every project, which is inevitable if the SDK were to be updated frequently.