Windows install_static refactor.

chrome/install_static/README.md

Index: chrome/install_static/README.md
diff --git a/chrome/install_static/README.md b/chrome/install_static/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..b85d11300db8ddc08e03aa877038fdeb43f605c8
--- /dev/null
+++ b/chrome/install_static/README.md
@@ -0,0 +1,48 @@
+# 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.

[robertshield, 2016/10/17 05:27:23]

Perhaps mention why the no dependencies bit is important ("making it suitable
for use in other dependency-free libraries"). 

Is this dependency-free nature enforced by tests or otherwise?

[grt (UTC plus 2), 2016/10/24 11:17:51]

Done
Not in this library. +pennymac to confirm whether or not chrome_elf has a test
for dependencies.

[robertshield, 2016/10/24 14:59:26]

Elf has a now-release-only-because-gn-source-sets (:-() test here: 

https://codesearch.chromium.org/chromium/src/chrome_elf/elf_imports_unittest....

[grt (UTC plus 2), 2016/10/24 19:36:00]

Thanks. I see I forgot to do the actual + thing for pennymac. :-)

Do you think that test is sufficient?

[robertshield, 2016/10/28 06:56:52]

The test is imho the barest minimum to prevent regressions. I wasn't able to
think of anything better at the time. It's not robust against dynamic loading or
anything like that. 

Worth checking with Penny directly if there have been any changes in thinking
since then, but for a module that wishes to stay dependency free, having a
similar test is a good idea.

[grt (UTC plus 2), 2016/10/28 10:59:44]

I'll run off and try to make something simple for this library while checking
with pennymac. Thanks for the advice.

[grt (UTC plus 2), 2016/10/28 14:20:33]

Hmm. My something simple was to make a dummy dll and have a test that would
check its imports. This doesn't pan out unless the dummy dll exercises every
function of the install_static library. Since chrome_elf is the thing that
really needs to not have excess dependencies, it seems to me that that's really
the right place to evaluate them. What do you two (robertshield and pennymac)
think?

[robertshield, 2016/10/28 14:34:21]

Ah right. 

s/every function/every exported function/ I guess, but as you say if chrome_elf
depends on install_static and is the only thing that has the no-dependencies
requirement, then the existing chrome_elf test should suffice.

[grt (UTC plus 2), 2016/10/31 10:44:30]

Acknowledged.

+
+[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

[robertshield, 2016/10/17 05:27:23]

Some of these details may be more appropriate as code comments, the chances of
the README and implementation diverging are a bit larger than code and nearby
comments.

[grt (UTC plus 2), 2016/10/24 11:17:51]

Good point. I've moved most of what I'd typed here into other places.

+
+Chrome calls `InitializeModuleProductDetails` early in process startup to

[robertshield, 2016/10/17 05:27:23]

naming bikeshedding: perhaps "InitializeProductDetailsForModule" or
""InitializeProductDetailsInModule" or maybe even ""InitializeProductDetails".

"ModuleProduct" is a bit confusing

[grt (UTC plus 2), 2016/10/24 11:17:51]

Done.

+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.