What's on the grocery list?

A co-worker of mine overheard me talking with a customer the other day and said he thought my conversation would make a nice quick blog, so I told him I would write this up.  Basically a customer and I were discussing how servicing worked and what all of the moving parts were, I do this fairly often at Microsoft with customers, so thats nothing new.  What was new was the way I related the concepts about how things work and I think thats what my colleague keyed off of.  Honestly, I think it might have been the first time I explained things in the manner that I did and my co-worker said it finally made a little more sense to him.  So, even though I know I have gone over the servicing concepts on here in the past, I figured I would throw this out there and see what those of you who read my blog thought about it.

The servicing mechanisms in Windows are broken into a couple of concepts, namely packages, components and payloads. 

Packages, which are defined by manifests, can be thought of as grocery lists.  They detail all of the different components that make them up.  Most of the time when we talk about packages, we're speaking about feature packages (.mum files in \Windows\servicing\packages) and the components that make them up.

Components are also defined by manifests, and similarly are a more detailed grocery list for things in a specific recipe.  They are defined by .manifest files and are located in the \Windows\winsxs directory.

Payloads are the groceries themselves.  These are the files that you're looking to have installed on your machine when you install a role/feature/update.

So, how does this all come together?  Using the grocery/recipe analogy, let's say you're installing a new update named joscon.msu on your machine.  The .msu itself is a cabinet file packaged in a wrapper.  Inside of this .msu is the manifest for the package and the payload.  What happens when you run this is:

1.  Windows parses the package to determine whats in the package. 

2.  Once we know what's in the package, we need to determine if it applies or not to the current system. 

3.  If the update supercedes what's in the component store, we stage the update in the component store and schedule it for installation. 

4.  After the update has been staged, we change the component state of any installed files to staged and then change the state of the new package from staged to installed. 

This is all a high level overview but if you were to look at these operations similarly to buying groceries, it might put things into perspective.  Before you go to the store, you determine what groceries you need based on what you have.  You comprise a list of groceries and then you head to the store and "fill" that list based on what you have.  In a servicing operation, we basically do the same thing.  We check to see what you're attempting to install, determine if we need it and then unpackage and install those files.

Hopefully that helps.....it sounds better when I say it than when I write it.

--Joseph

Comments

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  Thanks for the feedback.

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  October 26, 2010
  The comment has been removed

• Anonymous
  February 17, 2011
  The comment has been removed

• Anonymous
  February 19, 2011
  The comment has been removed