dotnet · blackdwarf · Jun 10, 2015 · Jun 7, 2015 · Jun 10, 2015
diff --git a/Documentation/README.md b/Documentation/README.md
@@ -3,80 +3,84 @@ Documents Index
 
 This repo includes several documents that explain both high-level and low-level concepts about the .NET runtime. These are very useful for contributors, to get context that can be very difficult to acquire from just reading code.
 
+Intro to .NET Core
+==================
+
+.NET Core is a self-contained .NET runtime and framework that implements [ECMA 335](dotnet-standards.md). It can be (and has been) ported to multiple architectures and platforms. It support a variety of installation options, having no specific deployment requirements itself.
+
 Learn about .NET Core
 ====================
 
-- [Brief Intro to .NET Core](dotnetcore-intro.md)
 - [[WIP] Official .NET Core Docs](http://dotnet.readthedocs.org)
 
 Get .NET Core
 =============
 
-- [Get .NET Core DNX SDK on Windows](get-dotnetcore-dnx-windows.md)
-- [Get .NET Core DNX SDK on OS X](get-dotnetcore-dnx-osx.md)
-- [Get .NET Core DNX SDK on Linux](get-dotnetcore-dnx-linux.md)
-- [Get .NET Core (Raw) on Windows](get-dotnetcore-windows.md)
+- [Get .NET Core DNX SDK on Windows](install/get-dotnetcore-dnx-windows.md)
+- [Get .NET Core DNX SDK on OS X](install/get-dotnetcore-dnx-osx.md)
+- [Get .NET Core DNX SDK on Linux](install/get-dotnetcore-dnx-linux.md)
+- [Get .NET Core (Raw) on Windows](install/get-dotnetcore-windows.md)
 
 Project Docs
 ============
 
-- [Developer Guide](developer-guide.md)
-- [Project priorities](project-priorities.md)
-- [Contributing to .NET Core](contributing.md)
-- [Contributing Workflow](contributing-workflow.md)
-- [Performance Guidelines](performance-guidelines.md)
-- [Garbage Collector Guidelines](garbage-collector-guidelines.md)
+- [Developer Guide](project-docs/developer-guide.md)
+- [Project priorities](project-docs/project-priorities.md)
+- [Contributing to .NET Core](project-docs/contributing.md)
+- [Contributing Workflow](project-docs/contributing-workflow.md)
+- [Performance Guidelines](project-docs/performance-guidelines.md)
+- [Garbage Collector Guidelines](project-docs/garbage-collector-guidelines.md)
 
 Coding Guidelines
 =================
 
-- [CLR Coding Guide](clr-code-guide.md)
-- [CLR JIT Coding Conventions](clr-jit-coding-conventions.md)
-- [Cross Platform Performance and Eventing Design](cross-platform-performance-and-eventing.md)
+- [CLR Coding Guide](coding-guidelines/clr-code-guide.md)
+- [CLR JIT Coding Conventions](coding-guidelines/clr-jit-coding-conventions.md)
+- [Cross Platform Performance and Eventing Design](coding-guidelines/cross-platform-performance-and-eventing.md)
 
 Build CoreCLR from Source
 =========================
 
-- [Building CoreCLR on FreeBSD](freebsd-instructions.md)
-- [Building CoreCLR on Linux](linux-instructions.md)
-- [Building CoreCLR on OS X](osx-instructions.md)
-- [Building CoreCLR on Windows](windows-instructions.md)
-- [Debugging CoreCLR on Windows](windows-debugging-instructions.md)
-- [Testing Changes on Windows](windows-test-instructions.md)
-- [Testing with CoreFX](testing-with-corefx.md)
-- [Creating a Custom DNX](custom-dnx-instructions.md)
+- [Building CoreCLR on FreeBSD](building/freebsd-instructions.md)
+- [Building CoreCLR on Linux](building/linux-instructions.md)
+- [Building CoreCLR on OS X](building/osx-instructions.md)
+- [Building CoreCLR on Windows](building/windows-instructions.md)
+- [Debugging CoreCLR on Windows](building/windows-debugging-instructions.md)
+- [Testing Changes on Windows](building/windows-test-instructions.md)
+- [Testing with CoreFX](building/testing-with-corefx.md)
+- [Creating a Custom DNX](building/custom-dnx-instructions.md)
 
 Book of the Runtime
 ===================
 
-- [Book of the Runtime FAQ](botr-faq.md)
-- [Introduction to the Common Language Runtime](intro-to-clr.md)
-- [Garbage Collection Design](garbage-collection.md)
-- [Threading](threading.md)
-- [RyuJIT Overview](ryujit-overview.md)
-- [Type System](type-system.md)
-- [Type Loader](type-loader.md)
-- [Method Descriptor](method-descriptor.md)
-- [Virtual Stub Dispatch](virtual-stub-dispatch.md)
-- [Stack Walking](stackwalking.md)
-- [Mscorlib and Calling Into the Runtime](mscorlib.md)
-- [Data Access Component (DAC) Notes](dac-notes.md)
-- [Profiling](profiling.md)
-- [Implementing Profilability](profilability.md)
-- [What Every Dev needs to Know About Exceptions in the Runtime](exceptions.md)
+- [Book of the Runtime FAQ](botr/botr-faq.md)
+- [Introduction to the Common Language Runtime](botr/intro-to-clr.md)
+- [Garbage Collection Design](botr/garbage-collection.md)
+- [Threading](botr/threading.md)
+- [RyuJIT Overview](botr/ryujit-overview.md)
+- [Type System](botr/type-system.md)
+- [Type Loader](botr/type-loader.md)
+- [Method Descriptor](botr/method-descriptor.md)
+- [Virtual Stub Dispatch](botr/virtual-stub-dispatch.md)
+- [Stack Walking](botr/stackwalking.md)
+- [Mscorlib and Calling Into the Runtime](botr/mscorlib.md)
+- [Data Access Component (DAC) Notes](botr/dac-notes.md)
+- [Profiling](botr/profiling.md)
+- [Implementing Profilability](botr/profilability.md)
+- [What Every Dev needs to Know About Exceptions in the Runtime](botr/exceptions.md)
 
 Decoder Rings
 =============
 
-- [.NET Core Glossary](glossary.md)
-- [.NET Filename Encyclopedia](dotnet-filenames.md)
+- [.NET Core Glossary](project-docs/glossary.md)
+- [.NET Filename Encyclopedia](project-docs/dotnet-filenames.md)
 
 Other Information
 =================
 
 - [CoreFX Repo documentation](https://github.com/dotnet/corefx/tree/master/Documentation)
 - [Porting to .NET Core](https://github.com/dotnet/corefx/blob/master/Documentation/support-dotnet-core-instructions.md)
-- [.NET Standards (Ecma)](dotnet-standards.md)
-- [CLR Configuration Knobs](clr-configuration-knobs.md)
+- [.NET Standards (Ecma)](project-docs/dotnet-standards.md)
+- [CLR Configuration Knobs](project-docs/clr-configuration-knobs.md)
 - [MSDN Entry for the CLR](http://msdn.microsoft.com/library/8bs2ecf4.aspx)
 - [Wikipedia Entry for the CLR](http://en.wikipedia.org/wiki/Common_Language_Runtime)
diff --git a/Documentation/botr-faq.md → Documentation/botr/botr-faq.md b/Documentation/botr-faq.md → Documentation/botr/botr-faq.md
diff --git a/Documentation/dac-notes.md → Documentation/botr/dac-notes.md b/Documentation/dac-notes.md → Documentation/botr/dac-notes.md
@@ -58,7 +58,7 @@ DAC marshaling works through a collection of typedefs, macros and templated type
 
 An example may be helpful in understanding how marshaling works. The common debugging scenario is represented in the following block diagram:
 
-![DAC Overview](images/dac-overview.png)
+![DAC Overview](../images/dac-overview.png)
 
 The debugger in this figure could be Visual Studio, MDbg, WinDbg, etc. The debugger interfaces with the CLR debugger interface (DBI) APIs to get the information it needs. Information that must come from the target goes through the DAC. The debugger implements the data target, which is responsible for implementing a ReadVirtual function to read memory in the target. The dotted line in the diagram represents the process boundary.
 

diff --git a/Documentation/exceptions.md → Documentation/botr/exceptions.md b/Documentation/exceptions.md → Documentation/botr/exceptions.md
diff --git a/Documentation/garbage-collection.md → Documentation/botr/garbage-collection.md b/Documentation/garbage-collection.md → Documentation/botr/garbage-collection.md
diff --git a/Documentation/intro-to-clr.md → Documentation/botr/intro-to-clr.md b/Documentation/intro-to-clr.md → Documentation/botr/intro-to-clr.md
diff --git a/Documentation/method-descriptor.md → Documentation/botr/method-descriptor.md b/Documentation/method-descriptor.md → Documentation/botr/method-descriptor.md
@@ -50,11 +50,11 @@ P/Invoke methods. These are methods marked with DllImport attribute.
 
 **EEImpl**
 
-Delegate methods whose implementation is provided by the runtime (Invoke, BeginInvoke, EndInvoke). See [ECMA 335 Partition II - Delegates](dotnet-standards.md).
+Delegate methods whose implementation is provided by the runtime (Invoke, BeginInvoke, EndInvoke). See [ECMA 335 Partition II - Delegates](../project-docs/dotnet-standards.md).
 
 **Array**
 
-Array methods whose implementation is provided by the runtime (Get, Set, Address). See [ECMA Partition II – Arrays](dotnet-standards.md).
+Array methods whose implementation is provided by the runtime (Get, Set, Address). See [ECMA Partition II – Arrays](../project-docs/dotnet-standards.md).
 
 **ComInterop**
 
@@ -87,7 +87,7 @@ Each MethodDesc has a slot, which contains the entry point of the method. The sl
 
 The slot is either in MethodTable or in MethodDesc itself. The location of the slot is determined by `mdcHasNonVtableSlot` bit on MethodDesc.
 
-The slot is stored in MethodTable for methods that require efficient lookup via slot index, e.g. virtual methods or methods on generic types. The MethodDesc contains the slot index to allow fast lookup of the entry point in this case. 
+The slot is stored in MethodTable for methods that require efficient lookup via slot index, e.g. virtual methods or methods on generic types. The MethodDesc contains the slot index to allow fast lookup of the entry point in this case.
 
 Otherwise, the slot is part of the MethodDesc itself. This arrangement improves data locality and saves working set. Also, it is not even always possible to preallocate a slot in a MethodTable upfront for dynamically created MethodDescs, such as for methods added by Edit & Continue, instantiations of generic methods or [dynamic methods](https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/Reflection/Emit/DynamicMethod.cs).
 
@@ -96,7 +96,7 @@ MethodDesc Chunks
 
 The MethodDescs are allocated in chunks to save space. Multiple MethodDesc tend to have identical MethodTable and upper bits of metadata token. MethodDescChunk is formed by hoisting the common information in front of an array of multiple MethodDescs. The MethodDesc contains just the index of itself in the array.
 
-![Figure 1](images/methoddesc-fig1.png)
+![Figure 1](../images/methoddesc-fig1.png)
 
 Figure 1 MethodDescChunk and MethodTable
 
@@ -175,7 +175,7 @@ The worker code of the stub is wrapped by a precode fragment that can be mapped
 
 **Temporary entry points:** Methods must provide entry points before they are jitted so that jitted code has an address to call them. These temporary entry points are provided by precode. They are a specific form of stub wrappers.
 
-This technique is a lazy approach to jitting, which provides a performance optimization in both space and time. Otherwise, the transitive closure of a method would need to be jitted before it was executed. This would be a waste, since only the dependencies of taken code branches (e.g. if statement) require jitting. 
+This technique is a lazy approach to jitting, which provides a performance optimization in both space and time. Otherwise, the transitive closure of a method would need to be jitted before it was executed. This would be a waste, since only the dependencies of taken code branches (e.g. if statement) require jitting.
 
 Each temporary entry point is much smaller than a typical method body. They need to be small since there are a lot of them, even at the cost of performance. The temporary entry points are executed just once before the actual code for the method is generated.
 
@@ -185,13 +185,13 @@ The **stable entry point** is either the native code or the precode. The **nativ
 
 Temporary entry points are never saved into NGen images. All entry points in NGen images are stable entry points that are never changed. It is an important optimization that reduced private working set.
 
-![Figure 2](images/methoddesc-fig2.png)
+![Figure 2](../images/methoddesc-fig2.png)
 
 Figure 2 Entry Point State Diagram
 
 A method can have both native code and precode if there is a need to do work before the actual method body is executed. This situation typically happens for NGen image fixups. Native code is an optional MethodDesc slot in this case. This is necessary to lookup the native code of the method in a cheap uniform way.
 
-![Figure 3](images/methoddesc-fig3.png)
+![Figure 3](../images/methoddesc-fig3.png)
 
 Figure 3 The most complex case of Precode, Stub and Native Code
 
@@ -285,7 +285,7 @@ Compact entry point is a space efficient implementation of temporary entry point
 
 Temporary entry points implemented using StubPrecode or FixupPrecode can be patched to point to the actual code. Jitted code can call temporary entry point directly. The temporary entry point can be multicallable entry points in this case.
 
-Compact entry points cannot be patched to point to the actual code. Jitted code cannot call them directly. They are trading off speed for size. Calls to these entry points are indirected via slots in a table (FuncPtrStubs) that are patched to point to the actual entry point eventually. A request for a multicallable entry point allocates a StubPrecode or FixupPrecode on demand in this case. 
+Compact entry points cannot be patched to point to the actual code. Jitted code cannot call them directly. They are trading off speed for size. Calls to these entry points are indirected via slots in a table (FuncPtrStubs) that are patched to point to the actual entry point eventually. A request for a multicallable entry point allocates a StubPrecode or FixupPrecode on demand in this case.
 
 The raw speed difference is the cost of an indirect call for a compact entry point vs. the cost of one direct call and one direct jump on the given platform. The the later used to be faster  by a few percent in large server scenario since it can be predicted by the hardware better (2005). It is not always the case on current (2015) hardware.
 

diff --git a/Documentation/mscorlib.md → Documentation/botr/mscorlib.md b/Documentation/mscorlib.md → Documentation/botr/mscorlib.md
@@ -174,7 +174,7 @@ FCalls require a lot of glue, too much to describe here. Look at [fcall.h][fcall
 
 ### GC Holes, FCall, and QCall
 
-A much more complete discussion on GC holes can be found in the [CLR Code Guide](clr-code-guide.md). Look for ["Is your code GC-safe?"](clr-code-guide.md#is-your-code-gc-safe). This tailored discussion motivates some of the reasons why FCall and QCall have some of their strange conventions.
+A much more complete discussion on GC holes can be found in the [CLR Code Guide](../coding-guidelines/clr-code-guide.md). Look for ["Is your code GC-safe?"](../coding-guidelines/clr-code-guide.md#is-your-code-gc-safe). This tailored discussion motivates some of the reasons why FCall and QCall have some of their strange conventions.
 
 Object references passed as parameters to FCall methods are not GC-protected, meaning that if a GC occurs, those references will point to the old location in memory of an object, not the new location. For this reason, FCalls usually follow the discipline of accepting something like "StringObject*" as their parameter type, then explicitly converting that to a STRINGREF before doing operations that may trigger a GC. You must GC protect object references before triggering a GC, if you expect to be able to use that object reference later.
 

diff --git a/Documentation/profilability.md → Documentation/botr/profilability.md b/Documentation/profilability.md → Documentation/botr/profilability.md
diff --git a/Documentation/profiling.md → Documentation/botr/profiling.md b/Documentation/profiling.md → Documentation/botr/profiling.md