Windows SDK: How our web setup works

One of the trickiest things about being the setup PM on my team involves the issue of how we design the actual installation process of getting stuff to disk. There are as many ways to install a product as there are products themselves, and everybody that does setup believes their way is the best way. The thing is, their way is the best way - for them. I'm coming to realize that, at least in the SDK world, every product is unique and has its own requirements. For instance, because MSDN offline is composed solely of docs, they can have a very different setup than the Windows SDK, which is composed of docs as well as headers, libs, tools, samples and many other binaries.

Because of our unique requirements, we have a unique back-end system. Where MSDN and Visual Studio use a tool called Decatur to manage the input of content into their system, we have our own content management system and content database (CMS and BOM). The CMS essentially manages the input of new content into our system, while the BOM holds metadata about the content - where to pick it up, what buckets content fits into, meta-data about the content, etc. Our setup is the third part of the throughput of the build system, seamlessly building our setup directly out of the BOM.

Through the BOM, we've been able to deliver our componentized setup. This is the act of splitting the SDK into a set of MSIs with external CABs that allow for efficient downloading of content via our web setup. Essentially, through this componentization, we split content into discrete packages that may be downloaded more quickly and which take advantage of multithreading. The componentized MSIs also give us the advantage of being able to hand our components to external teams for addition to their content. In that way, we have the ability to integrate with others without a lot of additional pain.

Finally, we are also better able to take in MSIs created by external teams, simply queuing them up for installation as part of our installation. This latter fact means that when a user needs to install Microsoft Document Explorer (DExplore) in order to view docs, the installation happens under the hood, without any additional action by the user. Here we get back to the differences in the way different setups are run. If MSDN's install detects the lack of DExplore, it runs the DExplore install before starting the MSDN install. With the Windows SDK, the installation happens silently. There's no awkward waiting for DExplore to be installed before the full install of the SDK starts. There's nothing wrong with MSDN's approach, it's just different.

The BOM also helps drive setup itself. Some of the metadata about the MSIs bubbles into UI strings that are exposed when the users click the Installation Options screen. Through the BOM we can easily create new MSIs, and easily choose the viewing order that everything has in the Installation Options tree. We have the ability to create localized strings on top of those files, and therefore produce a setup that shows Japanese text for Japanese users.

Please let me know if you have specific questions you'd like to know about our setup. Over the next two posts, which I'll try to post weekly, I'll post more about our plans for localization as well as about how exactly content gets placed on disk for installation.

Comments

• Anonymous
  February 13, 2007
  The comment has been removed