| OLD | NEW | 
| (Empty) |  | 
 |   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. | 
| OLD | NEW |