| justincarlson | b4730a0c | 2017-04-20 20:22:13 | [diff] [blame] | 1 | # Startup |
| 2 | |
| 3 | Chrome is (mostly) shipped as a single executable that knows how to run as all |
| 4 | the interesting sorts of processes we use. |
| 5 | |
| 6 | Here's an overview of how that works. |
| 7 | |
| 8 | 1. First there's the platform-specific entry point: `wWinMain()` on Windows, |
| 9 | `main()` on Linux. This lives in `chrome/app/chrome_exe_main_*`. On Mac and |
| 10 | Windows, that function loads modules as described later, while on Linux it |
| 11 | does very little, and all of them call into: |
| 12 | 2. `ChromeMain()`, which is the place where cross-platform code that needs to |
| 13 | run in all Chrome processes lives. It lives in `chrome/app/chrome_main*`. |
| 14 | For example, here is where we call initializers for modules like logging and |
| 15 | ICU. We then examine the internal `--process-type` switch and dispatch to: |
| 16 | 3. A process-type-specific main function such as `BrowserMain()` (for the outer |
| 17 | browser process) or `RendererMain()` (for a tab-specific renderer process). |
| 18 | |
| 19 | ## Platform-specific entry points |
| 20 | |
| 21 | ### Windows |
| 22 | |
| 23 | On Windows we build the bulk of Chrome as a DLL. (XXX: why?) `wWinMain()` |
| 24 | loads `chrome.dll`, does some other random stuff (XXX: why?) and calls |
| 25 | `ChromeMain()` in the DLL. |
| 26 | |
| 27 | ### Mac |
| 28 | |
| 29 | Mac is also packaged as a framework and an executable, but they're linked |
| 30 | together: `main()` calls `ChromeMain()` directly. There is also a second entry |
| 31 | point, in |
| 32 | [`chrome_main_app_mode_mac.mm`](https://cs.chromium.org/chromium/src/chrome/app_shim/chrome_main_app_mode_mac.mm), |
| 33 | for app mode shortcuts: "On Mac, one can't make shortcuts with command-line |
| 34 | arguments. Instead, we produce small app bundles which locate the Chromium |
| 35 | framework and load it, passing the appropriate |
| 36 | data." This executable also calls `ChromeMain()`. |
| 37 | |
| 38 | ### Linux |
| 39 | |
| 40 | On Linux due to the sandbox we launch subprocesses by repeatedly forking from a |
| 41 | helper process. This means that new subprocesses don't enter through main() |
| 42 | again, but instead resume from clones in the middle of startup. The initial |
| 43 | launch of the helper process still executes the normal startup path, so any |
| 44 | initialization that happens in `ChromeMain()` will have been run for all |
| 45 | subprocesses but they will all share the same initialization. |
