Windows SDK: How content makes it to your hard drive
This may be a bit nuts-and-bolts for some readers, but I thought you might enjoy reading over the next few posts about how we create the Windows SDK setup packages and how it's determined what gets installed to your computer.
First of all, it's important to keep in mind what an SDK is. An SDK is, as you might think, a kit that helps you develop software. What constitutes a kit is a set of files that we take in from all around the company and put into one container. Think of the SDK as a toolbox that contains a whole range of tools. We create the toolbox and fill it with tools that we think might be useful for our users. Just as Sears will give you a screwdriver, wrench, hammer and tape measure with your new toolbox, so too do we give you Win32 headers and libraries, tools, samples, and docs to help you use our content effectively. We don't have anything to do with the manufacture of the stuff we put in the box, but we do create specifications and rules for the quality and diversity of content that we ship. For instance, we have a goal to have sample coverage for every API that we ship, and of course, we have to document every API in the OS.
But the SDK is an amalgamator, not a content creator. We're not Office, where specific binary products are shipped from inside the same team. We simply amalgamate content, collate it together, and place it in logical chunks on the user's machine.
As you'd imagine, much of the complexity of our work comes in the content gathering phase. We have a content management system that allows product teams to drop us content. The teams are required to give us sufficient metadata to help us determine if we want to take the file, and give us sufficient backup to ensure that the content passes all security, privacy and best practices requirements. Simply submitting a file isn't enough; the SDK team reviews each submission for quality and suitability for the SDK. We occasionally get submissions that don't fit the key goals of the SDK, and those are rejected.
Once content is accepted into the system, it lives in what we call the BOM, short for the Build Object Manifest. The BOM is simply a database that contains references to all the files we ship. The BOM allows us to do many things with content. For instance, we can chunk content into many different buckets depending on what we want to do with it. Last year we made the decision to ship the SDK as a set of MSIs, and so the BOM is organized in a way to maximize that approach. Previously we used MSMs and that involved a somewhat different process. No content lives in the BOM - all content lives in the file system - but the BOM is created in such a way that content may be collated at run time.
In addition, meta-data about builds is in the BOM. Text in the setup screen is, in part, included in the BOM. This allows for text in the Installation Options screen to be changed without requiring that the entire binary setup file be recompiled.
Setup is the piece where everything is pulled together into one package. Currently 36 separate MSIs come together to be part of one full SDK setup. Setup provides a wrapper in which each MSI may run. In that way we are able to dramatically improve download and install speed while at the same time provide a master exe file that manages error handling, logging and user notification screens.
I manage the setup piece, and naturally I find it to be the most interesting. I'll talk more about setup specifically in the next few posts.
Comments
Anonymous
January 22, 2007
Ever wonder about how things get in the Windows SDK and how they get installed on your computer? It'sAnonymous
February 13, 2007
The comment has been removed