WIP: Migrate Wiki content over to src/docs

docs/windows_split_dll.md

Index: docs/windows_split_dll.md
diff --git a/docs/windows_split_dll.md b/docs/windows_split_dll.md
new file mode 100644
index 0000000000000000000000000000000000000000..3b85cbb57f9ba4e5a8dac951a00a051f4abc6478
--- /dev/null
+++ b/docs/windows_split_dll.md
@@ -0,0 +1,35 @@
+# Introduction
+
+A build mode where chrome.dll is split into two separate DLLs. This was undertaken as one possible workaround for toolchain limitations on Windows.
+
+
+# Details
+
+## How
+
+Normally, you probably don't need to worry about doing this build. If for some reason you need to build it locally:
+
+  * From a _Visual Studio Command Prompt_ running as **Administrator** run `python tools\win\split_link\install_split_link.py`.
+  * Set `GYP_DEFINES=chrome_split_dll=1`. In particular, don't have `component=shared_library`. Other things, like `buildtype` or `fastbuild` are fine.
+  * `gclient runhooks`
+  * `ninja -C out\Release chrome`
+
+`chrome_split_dll` currently applies only to chrome.dll (and not test binaries).
+
+## What
+
+This is intended to be a temporary measure until either the toolchain is improved or the code can be physically separated into two DLLs (based on a browser/child split).
+
+The link replacement forcibly splits chrome.dll into two halves based on a description in `build\split_link_partition.py`. Code is primarily split along browser/renderer lines. Roughly, Blink and its direct dependencies are in the "chrome1.dll", and the rest of the browser code remains in "chrome.dll".
+
+Splitting the code this way allows keeping maximum optimization on the Blink portion of the code, which is important for performance.
+
+There is a compile time define set when building in this mode `CHROME_SPLIT_DLL`, however it should be used very sparingly-to-not-at-all.
+
+## Details
+
+This forcible split is implemented by putting .lib files in either one DLL or the other, and causing unresolved externals that result during linking to be forcibly exported from the other DLL. This works relatively cleanly for function import/export, however it cannot work for data export.
+
+There are relatively few instances where data exports are required across the DLL boundary. The waterfall builder http://build.chromium.org/p/chromium/waterfall?show=Win%20Split will detect when new data exports are added, and these will need to be repaired. For constants, the data can be duplicated to both DLLs, but for writeable data, a wrapping set/get function will need to be added.
+
+Some more details can be found on the initial commit of the split\_link script http://src.chromium.org/viewvc/chrome?revision=200049&view=revision and the associated bugs: http://crbug.com/237249 http://crbug.com/237267