Reference Counting, Side by Side installation and the Windows SDK

One of the most interesting challenges for me as a member of the Windows SDK team is that we ship so many products. Between Betas, CTPs and RTM releases, I’ve probably been part of at least a dozen releases since I joined the team in June 2005, and we have three more major releases in the pipeline for 2007. What’s extra complicated about that is that each of the releases has their own unique sets of content. How do pre-release SDKs live alongside released SDKs? How does each RTM SDK treat each other RTM SDK? How do we manage our content when multiple copies of the same content are installed by different products?

As the Setup Program Manager for the SDK, it’s my job to worry about things like these. I’ve created a matrix that shows the expected behaviors when products are installed one on top of the next, but the matrix is, by its nature, massively complex. My spec that lists the scenarios around this has 16 different scenarios listed, and I’m constantly concerned that I’ve missed one or two key scenarios.

Thankfully, the scenarios for install boil down to a few clear rules. We decided early on that pre-release and RTM versions of the SDK must live side by side on the user’s machine. A pre-release can never overwrite an RTM version; otherwise, the users would have release-quality content overwritten by Beta content. That’s obviously a bad, bad scenario. Another rule is that when the user has an SDK that has almost the same content in it – as in when the user has one of the three versions of the Windows SDK that are almost the same (the RTM SDK, our SDK Update or our Japanese-language version of the SDK) we just ask you to uninstall one SDK before installing another.

That solution works, but, to me, it’s not the perfect solution. The better solution to me is something called Reference Counting, or RefCounting. RefCounting is a MSI Custom Action which we use to track which content is installed by which application. If the content would be installed by more than one version of the SDK, we don’t install it more than once. Instead, we simply track that more than one application has installed the content.

As an example, if you installed the Windows SDK Tools for the .NET Framework through Visual Studio “Orcas” and also through an install of the SDK, the tools won’t be installed twice. They’ll be dropped to disk once, and the Setup Custom Action will write a registry key to note that the file was installed by both apps. In that way we prevent disk sprawl and also prevent users from breaking one product when uninstalling another product.

RefCounting is generally thought of as applying to uninstallation, but we use it to help with our install story as well. We get installation detection from the way we deal with product codes in the SDK MSIs. If the same product code for an MSI is in place, the MSI simply doesn’t get installed. At the same time that install is skipped, the RefCounting Custom Action also writes to the registry that another product is sharing that MSI. At uninstall, then, RefCounting queries the Registry and sees what apps have used that MSI. If more than one installed SDK uses that MSI, the MSI stays on disk while the product is simply RefCounted down by one iteration.

This process is crucial  to our hopes of producing  multiple localized Windows SDKs for future SDK releases.  If we were to release an SDK with Japanese content and at the same time release content in some of the other Visual Studio-supported languages, it would create massive disk sprawl. Instead, through this scheme, we’ll be working to enable to allow you to install multiple versions of the .NET Framework documentation while only installing only one version of the Win32 samples.

It would help our decision making a lot if you gave us an idea of how you manage content on disk. Would you expect more than one copy of the same content to be installed, or would you prefer one copy? When do you expect our setup to upgrade for you, and when would you expect it to install side by side?

Jason Sacks
Setup Program Manager, Windows SDK

Comments (2)

  1. Zooba says:

    I personally have never had more than one Windows/Platform SDK installed at once. Granted, I don’t use it in a production environment nor do I have any need for localised varieties (I can translate US English to Australian English just fine 😉 ).

    I spend most of my time digging through the SDK directory structure (the only Start Menu shortcut I use is for the documentation and I don’t even use the default one for that) so if some items were installed side-by-side and some were common the separation would have to be clear (Common folder and version number folders?).

    In terms of upgrading content, I would only expect it to happen when the new content can be used directly in place of the old content, alternatively, the new content produces identical results to the old content in the same context. For example, CreateFont had the CLEARTYPE_QUALITY flag added for Windows XP. In the context of Windows 2000 (ie. ignoring anything marked for a later version), the documentation page is identical to what it was previously, so it should replace the old one. If a sample program demonstrating CreateFont assumes that CLEARTYPE_QUALITY is available, the behaviour will have changed from under Windows 2000, so it goes side-by-side.

    For what it’s worth, I use the WSDK as a hobbyist, not a full time programmer. However, the geek in me says "too many advanced options is never enough!" 😀

  2. camoguard says:

    You have an example in which you use reference counting.  Why not add a variation value?  The variation value would be added when an installer detects previously installed components and determines to install side by side.  The variation value could be an alternate key that identifies a similar component. This variations list has a similar benefit to the RefCount scheme because in the event that one semi-identical product is uninstalled, programs seeking common components could find them in the variant location.  Then you could rely on the user to make their own choice to increase the RefCount for better disk space management or to side install for better configuration management.  Your variations could even have priorities by order or by additional value so that components were searched in a sensible order.  A beta component would be lower on the list to a release component.  Maybe a newer date is higher in priority to an older date.  The variations may even have their own key an form a sort of many to many relation in the registry.

    That’s my idea.

Skip to main content