I’m pleased to announce that the online version of the RC1 Windows Vista SDK docs are live!

 

We are working on Vista RTM and making plans for Visual Studio “Orcas”.

 

Moving into the “Orcas” time frame, one of the areas we have been discussing is the Windows SDK install options.

 

When you install the Windows SDK, you can install the whole thing or optionally you can install a subset of the SDK. For example if you just work on Win32 C++ applications, you can install just the Win32 and COM portions of the SDK. There might be a few benefits of installing a subset of the SDK. Some possible benefits are that the SDK downloads faster, the download is more likely to succeed, searching either manually or using a search program is likely to be more accurate, faster and use less computing resources. Of course, in some scenarios installing a subset might not be the right choice.

 

If having the option to install a subset is helpful for some people, which options should exist? Should we have options to install a subset for native developers that use Win32 and COM, a subset for .NET Framework users (this exists today)? Maybe a Web option would be nice for some folks as well. Are these even the right way to think about install options? Perhaps the options should be completely different, more like C#, Visual Basic .NET, and C++. Should the Visual Basic option include content that only applies to Visual Basic or to any .NET program? How many options should we even have? I advocated for users being able to create their own install options, like just Visual Basic reference about Web development with ASP.NET, but this might be confusing for many customers.

 

Another thing we discussed this week is the class library. The class library contains reference documentation, which includes a description of the parameters and return values for members. Today we organize the .NET class library and the Win32 and COM class libraries differently.

 

The class library in the .NET Development section contains reference for most managed types – they are pretty much all in there. The logic behind grouping them together is that all of these topics are similar in that they are managed reference. They look the same and have the same type of information. If you write .NET managed code, it is also likely that you will use managed types in combination with managed types from other technologies.

 

This is not how we organize the Win32 and COM section reference. We could have the managed reference grouped with the technology. For example instead of the having the reference for the System.Data types in the class library in the .NET Development section, we could move it to a location along with the other ADO.NET documentation. This is nice when you want to see all the classes in ADO.NET, but it gets annoying when you want to see the reference for a type not in the System.Data namespace and have to try to find it in another section of the SDK. We absolutely don’t want to make it harder to find the right content!

 

If you have an opinion about these topics or anything else related to the Windows SDK, we can make changes. Now is a great time to let us know what changes you would like to see.  

 

Sean Grimaldi