OLD | NEW |
---|---|
(Empty) | |
1 # Install Static Library | |
2 | |
3 The install_static library for Windows contains the minimum functionality to | |
4 determine the fundamental properties of Chrome's installation plus various | |
5 installation-related utility functions. It has no dependencies beyond | |
6 kernel32.dll and version.dll. | |
robertshield
2016/10/17 05:27:23
Perhaps mention why the no dependencies bit is imp
grt (UTC plus 2)
2016/10/24 11:17:51
Done
robertshield
2016/10/24 14:59:26
Elf has a now-release-only-because-gn-source-sets
grt (UTC plus 2)
2016/10/24 19:36:00
Thanks. I see I forgot to do the actual + thing fo
robertshield
2016/10/28 06:56:52
The test is imho the barest minimum to prevent reg
grt (UTC plus 2)
2016/10/28 10:59:44
I'll run off and try to make something simple for
grt (UTC plus 2)
2016/10/28 14:20:33
Hmm. My something simple was to make a dummy dll a
robertshield
2016/10/28 14:34:21
Ah right.
s/every function/every exported functi
grt (UTC plus 2)
2016/10/31 10:44:30
Acknowledged.
| |
7 | |
8 [TOC] | |
9 | |
10 ## Key Concepts | |
11 | |
12 * **Brand** (or *branding*): In the abstract, a browser's brand comprises all | |
13 identifying markings that distinguish it from a browser produced by another | |
14 party. Chromium has remnants of both the Chromium and Google Chrome brands. | |
15 | |
16 * **Mode** (or *install mode*): Each brand defines a primary install mode for | |
17 the browser. A brand may additionally define one or more secondary install | |
18 modes (e.g., Google Chrome's SxS mode for the canary channel). Install modes | |
19 are described by compile-time instantiations of the `InstallConstants` | |
20 struct in a brand's `kInstallModes` array. | |
21 | |
22 * **Google Update Integration**: Each brand indicates whether or not it | |
23 integrates with Google Update via `kUseGoogleUpdateIntegration`. Google | |
24 Chrome does, while Chromium does not. | |
25 | |
26 * **Channel** (or *update channel*): Brands that integrate with Google Update | |
27 have the capability of supporting multiple update channels (e.g., Google | |
28 Chrome's stable, beta, dev, and canary channels). Each install mode | |
29 specifies a default update channel and a strategy for dynamically | |
30 determining a browser's channel. Brands that do not integrate with Google | |
31 Update are unconditinally on the `"unknown"` channel. | |
32 | |
33 ## Operational Details | |
robertshield
2016/10/17 05:27:23
Some of these details may be more appropriate as c
grt (UTC plus 2)
2016/10/24 11:17:51
Good point. I've moved most of what I'd typed here
| |
34 | |
35 Chrome calls `InitializeModuleProductDetails` early in process startup to | |
robertshield
2016/10/17 05:27:23
naming bikeshedding: perhaps "InitializeProductDet
grt (UTC plus 2)
2016/10/24 11:17:51
Done.
| |
36 determine its install mode, update channel, and other related details. This | |
37 results in the creation of a process-wide `InstallDetails` instance within the | |
38 allocation domain of the calling module. The calling module exposes a | |
39 `GetInstallDetailsPayload` function by which other modules in the process may | |
40 obtain a pointer to a POD-struct payload containing these details and create | |
41 their own module-specific `InstallDetails` instance. Code in Chrome may then use | |
42 `InstallDetails::Get()` to access its module's view of the process's details. | |
43 | |
44 While Chrome's installer has its own logic for determining its `InstallDetails`, | |
45 it also makes it available process-wide. This enables code sharing between the | |
46 browser and the installer -- code in each can use `InstallDetails::Get()` to | |
47 determine things like the active install mode, or whether the browser/installer | |
48 is operating at system-level. | |
OLD | NEW |