Port sandbox, sandbox faq, and startup design docs to markdown.

docs/design/startup.md

Index: docs/design/startup.md
diff --git a/docs/design/startup.md b/docs/design/startup.md
new file mode 100644
index 0000000000000000000000000000000000000000..1fea51c7641b3ad824338770b9d077c081cfb501
--- /dev/null
+++ b/docs/design/startup.md
@@ -0,0 +1,45 @@
+# Startup
+
+Chrome is (mostly) shipped as a single executable that knows how to run as all
+the interesting sorts of processes we use.
+
+Here's an overview of how that works.
+
+1. First there's the platform-specific entry point: `wWinMain()` on Windows,
+   `main()` on Linux.  This lives in `chrome/app/chrome_exe_main_*`.  On Mac and
+   Windows, that function loads modules as described later, while on Linux it
+   does very little, and all of them call into:
+2. `ChromeMain()`, which is the place where cross-platform code that needs to
+   run in all Chrome processes lives.  It lives in `chrome/app/chrome_main*`.
+   For example, here is where we call initializers for modules like logging and
+   ICU.  We then examine the internal `--process-type` switch and dispatch to:
+3. A process-type-specific main function such as `BrowserMain()` (for the outer
+   browser process) or `RendererMain()` (for a tab-specific renderer process).
+
+## Platform-specific entry points
+
+### Windows
+
+On Windows we build the bulk of Chrome as a DLL.  (XXX: why?)  `wWinMain()`
+loads `chrome.dll`, does some other random stuff (XXX: why?) and calls
+`ChromeMain()` in the DLL.
+
+### Mac
+
+Mac is also packaged as a framework and an executable, but they're linked
+together: `main()` calls `ChromeMain()` directly.  There is also a second entry
+point, in
+[`chrome_main_app_mode_mac.mm`](https://cs.chromium.org/chromium/src/chrome/app_shim/chrome_main_app_mode_mac.mm),
+for app mode shortcuts: "On Mac, one can't make shortcuts with command-line
+arguments. Instead, we produce small app bundles which locate the Chromium
+framework and load it, passing the appropriate
+data."  This executable also calls `ChromeMain()`.
+
+### Linux
+
+On Linux due to the sandbox we launch subprocesses by repeatedly forking from a
+helper process.  This means that new subprocesses don't enter through main()
+again, but instead resume from clones in the middle of startup.  The initial
+launch of the helper process still executes the normal startup path, so any
+initialization that happens in `ChromeMain()` will have been run for all
+subprocesses but they will all share the same initialization.