Windows install_static refactor.

chrome/install_static/README.md

+# Install Static Library
+
+The install_static library for Windows contains the minimum functionality to
+determine the fundamental properties of Chrome's installation plus various
+installation-related utility functions. It has no dependencies beyond
+kernel32.dll and version.dll.
+
+[TOC]
+
+## Key Concepts
+
+* **Brand** (or *branding*): In the abstract, a browser's brand comprises all
+    identifying markings that distinguish it from a browser produced by another
+    party. Chromium has remnants of both the Chromium and Google Chrome brands.
+
+* **Mode** (or *install mode*): Each brand defines a primary install mode for
+    the browser. A brand may additionally define one or more secondary install
+    modes (e.g., Google Chrome's SxS mode for the canary channel). Install modes
+    are described by compile-time instantiations of the `InstallConstants`
+    struct in a brand's `kInstallModes` array.
+
+* **Google Update Integration**: Each brand indicates whether or not it
+    integrates with Google Update via `kUseGoogleUpdateIntegration`. Google
+    Chrome does, while Chromium does not.
+
+* **Channel** (or *update channel*): Brands that integrate with Google Update
+    have the capability of supporting multiple update channels (e.g., Google
+    Chrome's stable, beta, dev, and canary channels). Each install mode
+    specifies a default update channel and a strategy for dynamically
+    determining a browser's channel. Brands that do not integrate with Google
+    Update are unconditinally on the `"unknown"` channel.
+
+## Operational Details
+
+Chrome calls `InitializeModuleProductDetails` early in process startup to
+determine its install mode, update channel, and other related details. This
+results in the creation of a process-wide `InstallDetails` instance within the
+allocation domain of the calling module. The calling module exposes a
+`GetInstallDetailsPayload` function by which other modules in the process may
+obtain a pointer to a POD-struct payload containing these details and create
+their own module-specific `InstallDetails` instance. Code in Chrome may then use
+`InstallDetails::Get()` to access its module's view of the process's details.
+
+While Chrome's installer has its own logic for determining its `InstallDetails`,
+it also makes it available process-wide. This enables code sharing between the
+browser and the installer -- code in each can use `InstallDetails::Get()` to
+determine things like the active install mode, or whether the browser/installer
+is operating at system-level.