diff --git a/_config.yml b/_config.yml
index 840a7fd..10e6731 100644
--- a/_config.yml
+++ b/_config.yml
@@ -1,2 +1 @@
-highlighter: pygments
 markdown: kramdown
diff --git a/_includes/header.html b/_includes/header.html
index 23ad164..a3d198e 100644
--- a/_includes/header.html
+++ b/_includes/header.html
@@ -22,17 +22,19 @@ <h2>CppUTest unit testing and mocking framework for C/C++</h2>
 	        <div class="navbar navbar-inverse">
 		        <div class="navbar-inner">
 			        <a class="brand" href="index.html">CppUTest</a>
+			        <a class="brand" href='https://coveralls.io/github/cpputest/cpputest?branch=master'><img src='https://coveralls.io/repos/github/cpputest/cpputest/badge.svg?branch=master' alt='Coverage Status' /></a>
+
 			        <ul class="nav">
 			        	<li class="divider-vertical"></li>
 				        <li><a href="manual.html">Core Manual</a></li>
 			        	<li class="divider-vertical"></li>
 				        <li><a href="mocking_manual.html">CppUMock Manual</a></li>
 				        <li class="divider-vertical"></li>
-				        <li><a href="stories.html">Platforms stories</a></li>
+				        <li><a href="plugin_manual.html">Plugin Manual</a></li>
 				        <li class="divider-vertical"></li>
-				        <li><a href="docs/index.html">Doxygen</a></li>
+				        <li><a href="stories.html">Platforms stories</a></li>
 				        <li class="divider-vertical"></li>
-				        <li><a href="https://github.com/cpputest/cpputest"><span class="github_icon"></span><span>View on 
+				        <li><a href="https://github.com/cpputest/cpputest"><span class="github_icon"></span><span>View on
 				        GitHub</span></a></li>
 				    </ul>
 				</div>
@@ -40,10 +42,10 @@ <h2>CppUTest unit testing and mocking framework for C/C++</h2>
         </nav>
 
         <section id="downloads">
-          <a href="https://github.com/cpputest/cpputest.github.io/blob/master/releases/cpputest-3.6.zip?raw=true" class="btn btn-inverse">Download Release 3.6 as .zip</a>
-          <a href="https://github.com/cpputest/cpputest.github.io/blob/master/releases/cpputest-3.6.tar.gz?raw=true" class="btn btn-inverse">Download Release 3.6 as .tar.gz</a>
-          <a href="https://github.com/cpputest/cpputest.github.io/blob/master/releases/cpputest-3.7dev.zip?raw=true" class="btn btn-inverse">Download code of latest passing build as .zip</a>
-          <a href="https://github.com/cpputest/cpputest.github.io/blob/master/releases/cpputest-3.7dev.tar.gz?raw=true" class="btn btn-inverse">Download code of latest passing build as .tar.gz</a>
+          <a href="https://github.com/cpputest/cpputest/releases/download/v3.8/cpputest-3.8.zip" class="btn btn-inverse">Download Release 3.8 as .zip</a>
+          <a href="https://github.com/cpputest/cpputest/releases/download/v3.8/cpputest-3.8.tar.gz" class="btn btn-inverse">Download Release 3.8 as .tar.gz</a>
+          <a href="https://github.com/cpputest/cpputest/releases/download/latest-passing-build/cpputest-latest.zip" class="btn btn-inverse">Download Latest Passing Build .zip</a>
+          <a href="https://github.com/cpputest/cpputest/releases/download/latest-passing-build/cpputest-latest.tar.gz" class="btn btn-inverse">Download Latest Passing Build .tar.gz</a>
         </section>
 	  </div>
     </header>
diff --git a/index.markdown b/index.markdown
index 58b2cc0..081ff2d 100644
--- a/index.markdown
+++ b/index.markdown
@@ -11,71 +11,128 @@ CppUTest's core design principles are:
 
 * Simple in design and simple in use.
 * Portable to old and new platforms.
-* Build with Test-driven Development in mind
+* Build with Test-driven Development for Test-driven Developers.
 
-## Where to get CppUTest
+## Setting up CppUTest
 
-### Pre-packaged
+There are several ways to setup CppUTest.  One is to install via package management and the other is from source. The big difference is that from source you can use **MakefileWorker.mk**. MakefileWorker is not supported pre-packaged.  MakefileWorker does not require you to know a lot about **make** and makefiles to get started.
+
+An easy way to get your first test case running is to use James Grenning's [cpputest-starter-project for gcc](https://github.com/jwgrenning/cpputest-starter-project) or [cpputest-starter-project for Visual Studio](https://github.com/jwgrenning/cpputest-starter-project-vs).  James is the author of [Test-Driven Development for Embedded C](https://wingman-sw.com/tddec).  You'll find instructions, your first test case, and some other example code.  James' training resources use MakefileWorker, so you need to install from source.
+
+Adding tests to untested C and C++ can be a big challenge.  You might find [Get your Legacy C into a Test Harness](https://wingman-sw.com/articles/tdd-legacy-c) a useful recipe and resource. The page includes links to numerous articles of real legacy C challenges.
+
+### Pre-packaged install
 
 *Linux*
 
-There is an Debian and Ubuntu package available for CppUTest. This is by far the easiest way to install it, via:
+There is a Debian and an Ubuntu package available for CppUTest. This is by far the easiest way to install it, via:
 
-```bash
+{% highlight bash %}
 $ apt-get install cpputest
-```
+{% endhighlight %}
 
 *MacOSX*
 
 For Mac, a Homebrew package is available too. You can install via:
 
-```bash
+{% highlight bash %}
 $ brew install cpputest
-```
+{% endhighlight %}
 
-### From source
+### From source install
 
 You can download the latest 'automatically released' version:
 
-* [Latest version passing the build](https://github.com/cpputest/cpputest.github.io/blob/master/releases/cpputest-3.7dev.tar.gz?raw=true)
+* [Latest version passing the build](https://github.com/cpputest/cpputest/releases/download/latest-passing-build/cpputest-latest.tar.gz)
 This version is automatically packages after a build has passed.
 
 Alternatively, you can clone the github repository, read-only:
 
-```bash
-$ git clone git://github.com/cpputest/cpputest.git
-```
+{% highlight bash %}
+$ git clone https://github.com/cpputest/cpputest.git
+{% endhighlight %}
 
 Or clone it via ssh (which requires a github account)
 
-```bash
+{% highlight bash %}
 $ git clone git@github.com:cpputest/cpputest.git
-```
+{% endhighlight %}
 
-After you cloned CppUTest, you can build it with your favorite build tool (CMake or autoconf).
+CppUTest can also be added to your git repo as a git submodule.
+
+{% highlight bash %}
+$ git submodule add https://github.com/cpputest/cpputest.git
+{% endhighlight %}
+
+Now that you have CppUTest sources, you can build it with your favorite build tool (CMake or autoconf).
 
 Building with autoconf requires you to (this requires you to have installed GNU autotools, apt-get/brew install automake autoconf libtool):
 
-```bash
+{% highlight bash %}
 $ cd cpputest_build
 $ autoreconf .. -i
 $ ../configure
 $ make
-```
+{% endhighlight %}
+
+You can use `make install` if you want to install CppUTest system-wide
+
+**NOTE**: Building from **cpputest_build** means you will not be able to use **MakefileWorker.mk**.  To use MakefileWorker you need to build from the cpputest home directory.
+
+### Using CppUTest with MakefileWorker.mk and gcc
+
+If you want to use CppUTest's MakefileWorker, you cannot currently get CppUTest using the "Pre-packaged" options described above. Instead you can get CppUTest from source using the options already described.
+
+Change to the top level directory of CppUTest (the directory containing **include/** and **src/** among other files)
+
+{% highlight bash %}
+$ cd cpputest \
+$ autoreconf . -i
+$ ./configure
+$ make tdd
+$ export CPPUTEST_HOME=$(pwd).
+{% endhighlight %}
+
+You will want to add **export CPPUTEST_HOME=<path>** somewhere like **.bashrc** or in your build script as a relative path.
+
+### Using CppUTest with Visual Studio
+
+You can build CppUTest using cmake or in the Visual Studio IDE.
+
+*from Visual Studio IDE*
+
+Depending on your VS version double click either
+
+* **CppUTest_VS201x.sln** - for VS 2010 and later
+* **CppUTest.sln** - for pre VS 2010
+
+Say yes to suggested conversions.  Select the menu item corresponding to run without debugging.  CppUTest should build (probably with warnings).  When the build completes the test runner runs. You should see over 1000 tests passing and no test failures. The build also produced a static library (cpputest/lib) holding CppUTest you can link your tests to.
+
+To use CppUTest, define an environment variable **CPPUTEST_HOME** that points to the home directory of CppUTest.  You will find a working example and some more help in [cpputest-starter-project for Visual Studio](https://github.com/jwgrenning/cpputest-starter-project-vs).
+
+## How to create a coverage report
+
+You can use autoconf to create a coverage report for CppUTests own tests. If you have lcov installed, a browsable html report will be generated as well. After the steps outlined in the previous paragraph, do the following:
+
+{% highlight bash %}
+$ make check_coverage
+{% endhighlight %}
+
+This will generate a file called gcov_report.txt with the coverage report in plain text format. It will also generate an HTML file called gcov_report.txt.html. If you have lcov installed, you will be able to browse the lcov report by opening ./cpputest_build/test_coverage/index.html . The lcov report is by far the easiest way to inspect CppUTest's own test coverage.
 
-Or you can use CMake if that is the build tool you fancy (this requires you have install CMake, apt-get install cmake):
+Alternatively, you can use CMake if that is the build tool you fancy (this requires you have install CMake, apt-get install cmake):
 
-```bash
+{% highlight bash %}
 $ cd cpputest_build
 $ cmake ..
 $ make
-```
+{% endhighlight %}
 
-For Windows users, the above work with cygwin. There are also several MS VC++ projects available.
+For Windows users, the above will work with cygwin. There are also several MS VC++ projects available.
 
 ## Where to find more information
 
-* If you have any question, check out the [Google Groups](https://groups.google.com/forum/?fromgroups#!forum/cpputest)
+* If you have any questions, check out the [Google Groups](https://groups.google.com/forum/?fromgroups#!forum/cpputest)
 * The source is at the [main github page](https://github.com/cpputest/cpputest)
 * You can report bugs or features at [the issues page](https://github.com/cpputest/cpputest/issues)
 * You can follow [CppUTest on twitter](https://twitter.com/CppUTest)
@@ -84,7 +141,7 @@ For Windows users, the above work with cygwin. There are also several MS VC++ pr
 
 To write your first test, all you need is a new cpp file with a TEST_GROUP and a TEST, like:
 
-```c++
+{% highlight c++ %}
 TEST_GROUP(FirstTestGroup)
 {
 };
@@ -93,37 +150,37 @@ TEST(FirstTestGroup, FirstTest)
 {
    FAIL("Fail me!");
 }
-```
+{% endhighlight %}
 
 This test will fail.
 
 You can add new tests to the test group by just writing more tests in the file, like this:
 
-```c++
+{% highlight c++ %}
 TEST(FirstTestGroup, SecondTest)
 {
    STRCMP_EQUAL("hello", "world");
    LONGS_EQUAL(1, 2);
    CHECK(false);
 }
-```
+{% endhighlight %}
 
 You do need to create a main where you run all the unit tests. Such a main will look like this:
 
-```c++
+{% highlight c++ %}
 int main(int ac, char** av)
 {
    return CommandLineTestRunner::RunAllTests(ac, av);
 }
-```
+{% endhighlight %}
 
-For more information, We'd recommend to [read the manual](http://www.cpputest.org) or, even better, check some [existing tests](https://github.com/cpputest/cpputest/tree/master/tests) such as [SimpleStringTest](https://github.com/cpputest/cpputest/blob/master/tests/SimpleStringTest.cpp) or (a bit more complicated) [MemoryLeakDetectorTest](https://github.com/cpputest/cpputest/blob/master/tests/MemoryLeakDetectorTest.cpp) or the [mocking tests](https://github.com/cpputest/cpputest/blob/master/tests/CppUTestExt/TestMockSupport.cpp) or just check out the [Cheat Sheet](https://github.com/cpputest/cpputest/blob/master/tests/CheatSheetTest.cpp)
+For more information, We'd recommend [reading the manual](manual.html) or, even better, check some [existing tests](https://github.com/cpputest/cpputest/tree/master/tests) such as [SimpleStringTest](https://github.com/cpputest/cpputest/blob/master/tests/CppUTest/SimpleStringTest.cpp) or (a bit more complicated) [MemoryLeakDetectorTest](https://github.com/cpputest/cpputest/blob/master/tests/CppUTest/MemoryLeakDetectorTest.cpp) or the [mocking tests](https://github.com/cpputest/cpputest/blob/master/tests/CppUTestExt/MockSupportTest.cpp) or just check out the [Cheat Sheet](https://github.com/cpputest/cpputest/blob/master/tests/CppUTest/CheatSheetTest.cpp)
 
 ## Related projects
 
 For Eclipse users, also check:
-* [CppUTest Eclipse Test Runner](https://github.com/tcmak/CppUTestEclipseJunoTestRunner) This will allow you to run your tests JUnit style with red and green bars, and rerun arbitrary selections of tests.  
-Prerequisites:  
+* [CppUTest Eclipse Test Runner](https://github.com/tcmak/CppUTestEclipseJunoTestRunner) This will allow you to run your tests JUnit style with red and green bars, and rerun arbitrary selections of tests.
+Prerequisites:
   - CppUTest off master
   - Eclipse Juno, Kepler, or later
   - Eclipse C/C++ Unit Plugin (if not already present in your version of Eclipse; install directly from Eclipse Help -> Install New Software...).
@@ -131,4 +188,4 @@ Prerequisites:
 
 ## Authors and Contributors
 
-CppUTest has had many contributions from its users. We can't remember all, but we appreciate it a lot!. Much of the original code was written by Michael Feathers (based on CppUnit Lite). The current main maintainers are [@jwgrenning](https://github.com/jwgrenning) and [@basvodde](https://github.com/basvodde)
+CppUTest has had many contributions from its users. We can't remember all, but we appreciate it a lot! Much of the original code was written by Michael Feathers (based on CppUnit Lite). The current main maintainers are [@jwgrenning](https://github.com/jwgrenning) and [@basvodde](https://github.com/basvodde)
diff --git a/manual.markdown b/manual.markdown
index 9efc650..bc23052 100644
--- a/manual.markdown
+++ b/manual.markdown
@@ -34,6 +34,8 @@ CppUTest's core design principles
 
 To write your first test, all you need is a new cpp file with a TEST_GROUP and a TEST, like:
 {% highlight c++ %}
+#include "CppUTest/TestHarness.h"
+
 TEST_GROUP(FirstTestGroup)
 {
 };
@@ -60,13 +62,15 @@ One of the key design goals in CppUTest is to make it *very easy* to add and rem
 Of course, in order to get it to run, you'll need to create a main. Most of the mains in CppUTest are very similar. They typically are in an AllTests.cpp file and look like this:
 
 {% highlight c++ %}
+#include "CppUTest/CommandLineTestRunner.h"
+
 int main(int ac, char** av)
 {
     return CommandLineTestRunner::RunAllTests(ac, av);
 }
 {% endhighlight %}
 
-CppUTest will automatically find your tests (as long as you don't like them in a library).
+CppUTest will automatically find your tests (as long as you don't link them in a library).
 
 ### Makefile changes
 
@@ -85,7 +89,7 @@ If you have a system installed version (e.g. via apt-get) then you probably don'
 For the compiler you have to add the include path and optional (but recommended) the CppUTest pre-include header which enables debug information for the memory leak detector *and* offers memory leak detection in C. Lets start with the include path, you'll need to add:
 
 {% highlight make %}
-    CPPFLAGS += -I(CPPUTEST_HOME)/include
+    CPPFLAGS += -I$(CPPUTEST_HOME)/include
 {% endhighlight %}
 
 (CPPFLAGS works for both .c and .cpp files!)
@@ -107,7 +111,7 @@ You need to add CppUTest library to the linker flags, for example, like:
      LD_LIBRARIES = -L$(CPPUTEST_HOME)/lib -lCppUTest -lCppUTestExt
 {% endhighlight %}
 
-(The last flags is only needed when you want to use extensions such as mocking)
+(The last flag is only needed when you want to use extensions such as mocking)
 
 <a id="test_macros"> </a>
 
@@ -133,20 +137,31 @@ The failure of one of these macros causes the current test to immediately exit:
 
 * CHECK(boolean condition) - checks any boolean result.
 * CHECK_TEXT(boolean condition, text) - checks any boolean result and prints text on failure.
+* CHECK_FALSE(condition) - checks any boolean result
 * CHECK_EQUAL(expected, actual) - checks for equality between entities using ==. So if you have a class that supports operator==() you can use this macro to compare two instances.  You will also need to add a StringFrom() function like those found in SimpleString. This is for printing the objects when the check failed.
+* CHECK_COMPARE(first, relop, second) - checks thats a relational operator holds between two entities. On failure, prints what both operands evaluate to.
 * CHECK_THROWS(expected_exception, expression) - checks if expression throws expected_exception (e.g. std::exception). CHECK_THROWS is only available if CppUTest is built with the Standard C++ Library (default).
-* STRCMP_EQUAL(expected, actual) - check const char* strings for equality using strcmp().
-* LONGS_EQUAL(expected, actual) - Compares two numbers.
-* BYTES_EQUAL(expected, actual) - Compares two numbers, eight bits wide.
-* POINTERS_EQUAL(expected, actual) - Compares two pointers.
-* DOUBLES_EQUAL(expected, actual, tolerance) - Compares two doubles within some tolerance
+* STRCMP_EQUAL(expected, actual) - checks const char* strings for equality using strcmp().
+* STRNCMP_EQUAL(expected, actual, length) - checks const char* strings for equality using strncmp().
+* STRCMP_NOCASE_EQUAL(expected, actual) - checks const char* strings for equality, not considering case.
+* STRCMP_CONTAINS(expected, actual) - checks whether const char* actual contains const char* expected.
+* LONGS_EQUAL(expected, actual) - compares two numbers.
+* UNSIGNED_LONGS_EQUAL(expected, actual) - compares two positive numbers.
+* BYTES_EQUAL(expected, actual) - compares two numbers, eight bits wide.
+* POINTERS_EQUAL(expected, actual) - compares two pointers.
+* DOUBLES_EQUAL(expected, actual, tolerance) - compares two floating point numbers within some tolerance
+* FUNCTIONPOINTERS_EQUAL(expected, actual) - compares two void (*)() function pointers
+* MEMCMP_EQUAL(expected, actual, size) - compares two areas of memory
+* BITS_EQUAL(expected, actual, mask) - compares expected to actual bit by bit, applying mask
 * FAIL(text) - always fails
 
+*NOTE* Most macros have _TEXT() equivalents like CHECK_TEXT(), which are not explicitly listed here.
+
 <a id="setup_teardown"> </a>
 
-*CHECK_EQUALS Warning:*
+*CHECK_EQUAL Warning:*
 
-CHECK_EQUAL(expected, actual) can produce misleading error reports as it will evaluate expected and actual more than ones. THis especially leads to confusions when used with mocks. This happens if the mock function expects to be called exactly once, since the macro needs to evaluate the actual expression more than once. The problem does not occur with type specific checks (e.g. LONGS_EQUAL()), so it is recommended to use them if possible. Instead of:
+CHECK_EQUAL(expected, actual) can produce misleading error reports as it will evaluate expected and actual more than once. This especially leads to confusions when used with mocks. This happens if the mock function expects to be called exactly once, since the macro needs to evaluate the actual expression more than once. The problem does not occur with type specific checks (e.g. LONGS_EQUAL()), so it is recommended to use them if possible. Instead of:
 
 {% highlight c++ %}
 CHECK_EQUAL(10, mock_returning_11())
@@ -175,7 +190,7 @@ TEST_GROUP(FooTestGroup)
 
    void teardown()
    {
-      // Uninit stuff
+      // Un-init stuff
    }
 };
 
@@ -218,16 +233,22 @@ The test execution of this will *likely* (no guarantee of order in CppUTest) be:
 
 ## Command line Switches
 
-* *-v* verbose, print each test name as it runs
 * *-c* colorize output, print green if OK, or red if failed
-* *-r#* repeat the tests some number (#) of times, or two times if # is not specified. This is handy if you are experiencing memory leaks. A second run that has no leaks indicates that someone is allocating statics and not releasing them.
-* *-g* group only run test whose group contains the substring group
-* *-sg* group only run test whose group exactly matches the string group
-* *-n* name only run test whose name contains the substring name
-* *-sn* name only run test whose name exactly matches the string name
-* *"TEST(group, name)"* only run test whose group and name matches the strings group and name. This can be used to copy-paste output from the -v option on the command line.
-* *-ojunit* output to JUnit ant plugin style xml files (for CI systems)
+* *-g group* only run test whose group contains the substring *group*
 * *-k* package name, Add a package name in JUnit output (for classification in CI systems)
+* *-lg* print a list of group names, separated by spaces
+* *-ln* print a list of test names in the form of *group.name*, separated by spaces
+* *-n name* only run test whose name contains the substring *name*
+* *-ojunit* output to JUnit ant plugin style xml files (for CI systems)
+* *-oteamcity* output to xml files (as the name suggests, for TeamCity)
+* *-p* run tests in a separate process.
+* *-r#* repeat the tests some number (#) of times, or twice if # is not specified. This is handy if you are experiencing memory leaks. A second run that has no leaks indicates that someone is allocating statics and not releasing them.
+* *-sg group* only run test whose group exactly matches the string *group*
+* *-sn name* only run test whose name exactly matches the string *name*
+* *-v* verbose, print each test name as it runs
+* *-xg group* exclude tests whose group contains the substring *group* (v3.8)
+* *-xn name* exclude tests whose name contains the substring *name* (v3.8)
+* *"TEST(group, name)"* only run test whose group and name matches the strings group and name. This can be used to copy-paste output from the -v option on the command line.
 
 You can specify multiple -s&#124;sg, -s&#124;sn and "TEST(group, name)" parameters: 
 
@@ -237,6 +258,27 @@ Specifying only test names with multiple -s&#124;sn parameters will run all test
 
 Mixing multiple -s&#124;sg and -s&#124;sn parameters (or using "TEST(group, name)" will only run tests whose groups match as well as their names.
 
+Combining one -xg parameter with one -xn parameter will run only those tests that satisfy both criteria.
+
+Combining -s&#124;sg with -xn, or -s&#124;sn with -xg will run only those tests that satisfy both criteria.
+
+Specifying several -xg or -xn with each other or in other combinations has no effect.
+
+*NOTE* Be careful with *-p*:
+
+* Some systems do not support this feature, in which case tests will fail
+  with a suitable message.
+* Using *-p* to run tests in a separate process can have unexpected side
+  effects.
+* While running tests in a separate process can help to get more information
+  about an unexpected crash, when an expected crash is part of the test scenario,
+  the *-p* command line option should not be used, but running in a separate
+  process should be enabled on a per-test basis like this:
+  {% highlight c++ %}
+  TestRegistry::getCurrentRegistry()->setRunTestsInSeperateProcess();
+  {% endhighlight %}
+  Examples for this can be found in CppUTests's own tests.
+
 <a id="memory_leak_detection"> </a>
 
 ## Memory Leak Detection
@@ -266,7 +308,7 @@ These are added by default when you use the CppUTest Makefile helpers.
 
 ### Turning memory leak detection off and on
 
-If you want to disable the memory leak detection (because you got too much memory leaks?) then you can do so in several ways. However, it is strongly recommended to keep the memory leak detector on and fix your memory leaks (and your static initialization issues) as this tends to lead to higher quality code.
+If you want to disable the memory leak detection (because you have too many memory leaks?) then you can do so in several ways. However, it is strongly recommended to keep the memory leak detector on and fix your memory leaks (and your static initialization issues) as this tends to lead to higher quality code.
 
 You can turn the memory leak detection completely off by adding this to your main:
 
@@ -286,26 +328,26 @@ You can do the same by turning it off on a test by test basis, by adding this to
 
 void setup()
 {
-    MemoryLeakWarningPlugin::turnOffNewDeleteOverloads();
+    MemoryLeakWarningPlugin::saveAndDisableNewDeleteOverloads();
 }
 
 void teardown()
 {
-    MemoryLeakWarningPlugin::turnOnNewDeleteOverloads();
+    MemoryLeakWarningPlugin::restoreNewDeleteOverloads();
 }
 
 {% endhighlight %}
 
-(Do not forget to turn it on in the teardown again!)
+(Do not forget to restore it in the teardown again!)
 
-If you want to completely disable memory leak detection then you can do so by building CppUTest with "configure --disable-memory-leak-detection" or passing -DCPPUTEST_MEM_LEAK_DETECTION_DISABLED to the compiler when compiling CppUTest.
+If you want to completely disable memory leak detection then you can do so by building CppUTest with `configure --disable-memory-leak-detection` or passing `-DCPPUTEST_MEM_LEAK_DETECTION_DISABLED` to the compiler when compiling CppUTest.
 
 ### Conflicts with operator new macros (STL!)
 
-It is common for the memory leak detection macros to conflict with an overloaded operator new or with STL. This is because the macro replaces the call to operator new to a call to operator new with __FILE__, and __LINE__. If you overload operator new, it will replace your overloaded definition resulting in a compiler error. This is common when using Standard C++ library (STL).
+It is common for the memory leak detection macros to conflict with an overloaded operator new or with STL. This is because the macro replaces the call to operator new to a call to operator new with `__FILE__`, and `__LINE__`. If you overload operator new, it will replace your overloaded definition resulting in a compiler error. This is common when using the Standard C++ library (STL).
 
 #### Resolving conflicts with STL
-The easiest way is not to pass the --include MemoryLeakDetectionNewMacros.h to the compiler, but this would lose all your file and line information. So this is not recommended. An alternative is to create your own NewMacros.h file which will include the STL file *before* the new macro is defined. For example, the following NewMacros file can be used for a program that uses std::list:
+The easiest way is to not pass the `--include MemoryLeakDetectionNewMacros.h` to the compiler, but this would lose all your file and line information. So this is not recommended. An alternative is to create your own NewMacros.h file which will include the STL file *before* the new macro is defined. For example, the following NewMacros file can be used for a program that uses std::list:
 
 {% highlight c++ %}
 #include "list"
@@ -316,7 +358,7 @@ Now the call to the compiler needs to be -include MyOwnNewMacros.h and this will
 
 ### Conflicts with my own overload!
 
-This one is harder (and luckily less common). You can solve this the same way as the conflict in STL, but its probably better to use a finer grained control. So, instead you can temporary disable the new macros, overload operator new, enable the new macro again. This can be done with the following code:
+This one is harder (and luckily less common). You can solve this the same way as the conflict with the STL, but it's probably better to use a finer grained control. So, instead you can temporary disable the new macros, overload operator new, enable the new macro again. This can be done with the following code:
 
 {% highlight c++ %}
 class NewDummyClass
@@ -337,6 +379,10 @@ public:
 
 Yes, its ugly. But usually people don't overload operator new everywhere. If you do, consider turning off the new macro completely.
 
+### Other conflicts in the test file only
+
+If your conflict is only in the test code files, put the CppUTest  includes after your includes.  Because of this potential conflict, its a good idea to put the CppUTest includes after your includes as a preemptive measure.
+
 ### Conflicts with MFC
 
 Tbd
@@ -345,84 +391,21 @@ Tbd
 
 ## Test Plugins
 
-Test plugins let you add a preaction and a post action to each test case.  Plugin examples:
+Test plugins let you add a pre-action and a post-action to each test case.  Plugin examples:
 
 * Memory leak detector (provided)
 * Pointer restore mechanism (provided) - helpful when tests overwrite a pointer that must be restored to its original value after the test.  This is especially helpful when a pointer to a function is modified for test purposes.
-* All Mutex's released - you could write a plugin that checks that any Mutexs or other shared resource is released before the test exists.
-
-Example of a main with a SetPointerPlugin:
+* IEEE754 Floating point exceptions (provided; v3.8) - automatically checks whether any floating point exception flags are set at the end of every test and if so, fails the test.
+* All Mutex's released - you could write a plugin that checks that any Mutexs or other shared resource is released before the test exits.
 
-{% highlight c++ %}
-int main(int ac, char** av)
-{
-    TestRegistry* r = TestRegistry::getCurrentRegistry();
-    SetPointerPlugin ps("PointerStore");
-    r->installPlugin(&ps);
-    return CommandLineTestRunner::RunAllTests(ac, av);
-}
-
-TEST_GROUP(HelloWorld)
-{
-   static int output_method(const char* output, ...)
-   {
-      va_list arguments;
-      va_start(arguments, output);
-      cpputest_snprintf(buffer, BUFFER_SIZE, output, arguments);
-      va_end(arguments);
-      return 1;
-   }
-   void setup()
-   {
-      //overwrite the production function pointer witha an output method that captures
-      //output in a buffer.
-      UT_PTR_SET(helloWorldApiInstance.printHelloWorld_output, &output_method);
-   }
-   void teardown()
-   {
-   }
-};
-
-TEST(HelloWorld, PrintOk)
-{
-   printHelloWorld();
-   STRCMP_EQUAL("Hello World!\n", buffer)
-}
-
-//Hello.h
-#ifndef HELLO_H_
-#define HELLO_H_
-
-extern void printHelloWorld();
-
-struct helloWorldApi {
-   int (*printHelloWorld_output) (const char*, ...);
-};
-
-#endif /*HELLO_H_*/
-
-//Hello.c
-
-#include <stdio.h>
-#include "hello.h"
-
-//in production, print with printf.
-struct helloWorldApi helloWorldApiInstance = {
-   &printf
-};
-
-void printHelloWorld()
-{
-   helloWorldApiInstance.printHelloWorld_output("Hello World!\n");
-}
-{% endhighlight %}
+Complete Documentation for provided plugins can be found on the [Plugin Manual](plugin_manual.html) page.
 
 <a id="scripts"> </a>
 
 ## Scripts
 
-There are some scripts that are helpful in creating your initial h, source, and
-Test files.  These save a lot of typing.  See scripts/README.TXT from the CppUTest distribution.
+There are some scripts that are helpful in creating your initial header, source, and
+Test files.  These scripts save a lot of typing.  See scripts/README.TXT from the CppUTest distribution.
 
 <a id="advanced"> </a>
 
@@ -444,7 +427,7 @@ The Extensions directory has a few of these.
 * TestPlugins can be used for, for example, system stability and resource handling like files, memory or network connection clean-up.
 * In CppUTest, the memory leak detection is done via a default enabled TestPlugin
 
-### How can tests run when they are linked in a library
+### How to run tests when they are linked in a library
 
 In larger projects, it is often useful if you can link the tests in "libraries of tests" and then link them to the library of a component or link them all together to be able to run all the unit tests. Putting the tests in a library however causes an interesting problem because the lack of reference to the tests (due to the auto-registration of tests) causes the linker to discard the tests and it won't run any of them. There are two different work-arounds for this:
 
@@ -549,6 +532,34 @@ int main(int ac, char** av)
 
 You can leave out TEST_GROUP_C_SETUP() / TEST_GROUP_C_TEARDOWN() and TEST_GROUP_C_SETUP_WRAPPER() / TEST_GROUP_C_TEARDOWN_WRAPPER(), if you don't need them.
 
+The following assertion macros are supported in the pure C interface:
+
+{% highlight c++ %}
+CHECK_EQUAL_C_BOOL(expected,actual);
+CHECK_EQUAL_C_INT(expected,actual);
+CHECK_EQUAL_C_UINT(expected,actual);
+CHECK_EQUAL_C_LONG(expected,actual);
+CHECK_EQUAL_C_ULONG(expected,actual);
+CHECK_EQUAL_C_LONGLONG(expected,actual);
+CHECK_EQUAL_C_ULONGLONG(expected,actual);
+CHECK_EQUAL_C_REAL(expected,actual,threshold);
+CHECK_EQUAL_C_CHAR(expected,actual);
+CHECK_EQUAL_C_UBYTE(expected,actual);
+CHECK_EQUAL_C_SBYTE(expected,actual);
+CHECK_EQUAL_C_STRING(expected,actual);
+CHECK_EQUAL_C_POINTER(expected,actual); /* v3.8 */
+CHECK_EQUAL_C_BITS(expected, actual, mask); /* v3.8, pending */
+FAIL_TEXT_C(text);
+FAIL_C();
+CHECK_C(condition);
+CHECK_C_TEXT(condition, text);
+{% endhighlight %}
+
+*NOTE* LONGLONG assertions are disabled by default.
+*NOTE2* All macros have _TEXT() equivalents like CHECK_C_TEXT(), which are not explicitly listed here.
+
+These macros ensure tests get terminated in a way appropriate for pure C code.
+
 <a id="gmock"> </a>
 
 ## Using Google Mock
@@ -608,7 +619,7 @@ The most important line to add is the GTestConvertor. Make sure you define the C
 
 ## Running Google Tests in CppUTest
 
-People feel wonderfully religious about unit testing tools. Of course, we feel strongly that CppUTest beats other tools when you actually test-drive your software. But unfortunately, people still use tools like GoogleTest (which is actually not as bad as e.g. CppUnit). It is unlikely that we're going to convince people to use CppUTest instead, so therefore we've written some integration code where you can actually link google test and CppUTest tests together in one binary (with the CppUTest test runner). THis also gives you some additional benefits:
+People feel wonderfully religious about unit testing tools. Of course, we feel strongly that CppUTest beats other tools when you actually test-drive your software. But unfortunately, people still use tools like GoogleTest (which is actually not as bad as e.g. CppUnit). It is unlikely that we're going to convince people to use CppUTest instead, so therefore we've written some integration code where you can actually link google test and CppUTest tests together in one binary (with the CppUTest test runner). This also gives you some additional benefits:
 
 * You get memory leak detection over your google tests...
 * You don't get the verbose gtest output
diff --git a/mocking_manual.markdown b/mocking_manual.markdown
index 0ceeff6..d99ba84 100644
--- a/mocking_manual.markdown
+++ b/mocking_manual.markdown
@@ -3,10 +3,10 @@ layout: default
 title: CppUTest Mocking Manual
 ---
 
-CppUTest has support for building mocks. This document described the mocking support. A couple of design goals for the mocking support were:
+CppUTest has support for building mocks. This document describes the mocking support. A couple of design goals for the mocking support were:
 
 
-* Same design goals as CppuTest -- limited C++ set to make it well suitable for embedded soft.
+* Same design goals as CppuTest -- limited C++ set to make it suitable for embedded software.
 * No code generation
 * No or very few magic hiding macros
 * Very simple to use
@@ -21,12 +21,15 @@ The main idea is to make manual mocking easier, rather than to make automated mo
 * [Using Parameters](#parameters)
 * [Objects as Parameters](#objects_as_parameters)
 * [Output Parameters](#output_parameters)
+* [Memory Buffer Parameters](#memory_buffer_parameters)
+* [Output Parameters Using Objects](#output_parameters_using_objects)
 * [Return Values](#return_values)
 * [Passing other data](#other_data)
 * [Other MockSupport](#other_mock_support)
 * [MockSupport Scope](#mock_scope)
-* [MockPlugin](#mock_plugin)
+* [MockSupportPlugin](#mock_plugin)
 * [C Interface](#c_interface)
+* [Miscellaneous](#miscellaneous)
 
 <a id="simple_scenario"> </a>
 
@@ -67,7 +70,7 @@ The TEST(MockDocumentation, SimpleScenario) contains the recording of the expect
 mock().expectOneCall("productionCode");
 {% endhighlight %}
 
-The call to mock() return the global MockSupport (more about that later) on which we can record our expectations. In this example, we'll call expectOneCall("productionCode") which... records an expectation for *one* call to a function called productionCode.
+The call to mock() returns the global MockSupport (more about that later) on which we can record our expectations. In this example, we'll call expectOneCall("productionCode") which... records an expectation for *one* call to a function called productionCode.
 
 The productionCode call is to show a call to whatever your real code is. The test ends with checking whether the expectations have been met. This is done with the:
 
@@ -88,7 +91,7 @@ void productionCode()
 
 where we use MockSupport by calling mock() and then record the actual call to the productionCode function.
 
-This scenario is quite common when using linker stubbing of e.g. a 3rd partly library.
+This scenario is quite common when using linker stubbing of e.g. a 3rd party library.
 
 If the call to productionCode wouldn't happen, then the test would fail with the following error message:
 
@@ -99,6 +102,12 @@ If the call to productionCode wouldn't happen, then the test would fail with the
         ACTUAL calls that did happen:
             <none>
 
+Sometimes you expect *several identical calls* to the same function, for example five calls to productionCode. There is a convenient shorthand for that situation:
+
+{% highlight c++ %}
+mock().expectNCalls(5, "productionCode");
+{% endhighlight %}
+
 <a id="objects"> </a>
 
 ### Using Objects
@@ -155,7 +164,7 @@ If the call to a wrong object happens, it would give the following error message
 
 ### Parameters
 
-Of course, just checked whether a function is called is not particularly useful when we cannot check the parameters. Recording parameters on a function is done like this:
+Of course, just checking whether a function is called is not particularly useful when we cannot check the parameters. Recording parameters on a function is done like this:
 
 {% highlight c++ %}
 mock().expectOneCall("function").onObject(object).withParameter("p1", 2).withParameter("p2", "hah");
@@ -200,11 +209,11 @@ MyTypeComparator is a custom comparator, which implements the MockNamedValueComp
 class MyTypeComparator : public MockNamedValueComparator
 {
 public:
-    virtual bool isEqual(void* object1, void* object2)
+    virtual bool isEqual(const void* object1, const void* object2)
     {
         return object1 == object2;
     }
-    virtual SimpleString valueToString(void* object)
+    virtual SimpleString valueToString(const void* object)
     {
         return StringFrom(object);
     }
@@ -213,13 +222,13 @@ public:
 
 The isEqual is called to compare the two parameters. The valueToString is called when an error message is printed and it needs to print the actual and expected values. If you want to use normal C functions, you can use the MockFunctionComparator which accepts pointers to functions in the constructor.
 
-To remove the comparators, all you needs to do is call removeAllComparators, like:
+To remove the comparators, all you needs to do is call removeAllComparatorsAndCopiers, like:
 
 {% highlight c++ %}
-mock().removeAllComparators();
+mock().removeAllComparatorsAndCopiers();
 {% endhighlight %}
 
-Comparators sometimes lead to surprised, so a couple of warnings on its usage:
+Comparators sometimes lead to surprises, so a couple of warnings on its usage:
 
 *Warning 1:*
 
@@ -231,7 +240,23 @@ Comparators are *not* copied, instead it uses the exact instance as passed to th
 
 * Pay extra attention to scope when using the MockPlugin
 
-When using the MockPlugin (recommended), then its best to install the comparators via the MockPlugin or put them in global space. The checkExpectations will be called *after* teardown and if your comparator was destroyed in the teardown then this will cause a crash.
+When using the MockPlugin (recommended), then it's best to install the comparators via the MockPlugin or put them in global space. The checkExpectations will be called *after* teardown and if your comparator was destroyed in the teardown then this will cause a crash.
+
+<a id="memory_buffer_parameters"> </a>
+
+### Memory Buffer Parameters
+
+When testing a function that accepts a pointer to data as a parameter you may want to check the value of the data referenced by the pointer instead of the value of the pointer itself. This can be done using withMemoryBufferParameter like:
+
+{% highlight c++ %}
+mock().expectOneCall("function").onObject(object).withMemoryBufferParameter("buffer", buffer, length);
+{% endhighlight %}
+
+and the actual call would be:
+
+{% highlight c++ %}
+mock().actualCall("function").onObject(this).withMemoryBufferParameter("buffer", buffer, length);
+{% endhighlight %}
 
 <a id="output_parameters"> </a>
 
@@ -251,7 +276,7 @@ mock().expectOneCall("Foo").withOutputParameterReturning("bar", &outputValue, si
 {% highlight c++ %}
 void Foo(int *bar)
 {
-    mock().actualCall("foo").withOutputParameter("bar", bar);
+    mock().actualCall("Foo").withOutputParameter("bar", bar);
 }
 {% endhighlight %}
 
@@ -261,31 +286,57 @@ After the actual call, the bar parameter passed to function Foo will have the va
 
 * CppUMock _does not_ and _cannot_ prevent invalid memory accesses when using output parameters. It will memcpy exactly the number of bytes specified in the withOutputParameterReturning call. A segmentation fault may occur if this is larger than the data pointed to by the output parameter provided in the actual call.
 
-Function overloads of withOutputParameterReturning are provided for char, int, unsigned, long, unsigned long, and double types so that the size parameter may be omitted:
+*Warning 2:*
+
+* When a char, int, etc. array is passed to withOutputParameter, you must use the generic withOutputParameterReturning and provide the actual size of the array or only one element will be copied.
+
+<a id="output_parameters_using_objects"> </a>
+
+### Output Parameters Using Objects
+
+By far the best way to handle output parameters is by using a custom type copier (v3.8). The general principle is similar to the custom comparators described above:
 
 {% highlight c++ %}
-char charOutputValue = 'a';
-mock().expectOneCall("Foo").withOutputParameterReturning("bar", &charOutputValue);
+MyType outputValue = 4;
+mock().expectOneCall("Foo").withOutputParameterOfTypeReturning("MyType", "bar",  &outputValue);
+{% endhighlight %}
 
-int intOutputValue = 4;
-mock().expectOneCall("Foo").withOutputParameterReturning("bar", &intOutputValue);
+The corresponding actual call is:
 
-unsigned unsignedOutputValue = 4;
-mock().expectOneCall("Foo").withOutputParameterReturning("bar", &unsignedOutputValue);
+{% highlight c++ %}
+void Foo(MyType *bar)
+{
+    mock().actualCall("Foo").withOutputParameterOfType("MyType", "bar",  bar);
+}
+{% endhighlight %}
+
+When using withOutputParameterOfTypeReturning, the mocking framework needs to know how to copy the type and therefore a Copier has to be installed before using parameters of this type. This is done using installCopier, as below:
 
-long longOutputValue = 4;
-mock().expectOneCall("Foo").withOutputParameterReturning("bar", &longOutputValue);
+{% highlight c++ %}
+MyTypeCopier copier;
+mock().installCopier("myType", copier);
+{% endhighlight %}
 
-unsigned long unsignedLongOutputValue = 4;
-mock().expectOneCall("Foo").withOutputParameterReturning("bar", &unsignedLongOutputValue);
+MyTypeCopier is a custom copier, which implements the MockNamedValueCopier interface. For example:
 
-double doubleOutputValue = 4;
-mock().expectOneCall("Foo").withOutputParameterReturning("bar", &doubleOutputValue);
+{% highlight c++ %}
+class MyTypeCopier : public MockNamedValueCopier
+{
+public:
+    virtual void copy(void* out, const void* in)
+    {
+        *(MyType*)out = *(const MyType*)in;
+    }
+};
 {% endhighlight %}
 
-*Warning 2:*
+To remove the copier, you need to call removeAllComparatorsAndCopiers, like:
 
-* When an char, int, etc. array is passed to withOutputParameter, you must use the generic withOutputParameterReturning and provide the actual size of the array or only one element will be copied.
+{% highlight c++ %}
+mock().removeAllComparatorsAndCopiers();
+{% endhighlight %}
+
+*Warning 1* and *Warning 2* above apply to copiers as well.
 
 <a id="return_values"> </a>
 
@@ -336,7 +387,7 @@ int value = mock().getData("importantValue").getIntValue();
 pobject = (ClassFromProductionCode*) mock().getData("importantObject").getObjectPointer();
 {% endhighlight %}
 
-Like return values. Setting data will not ever make a test fail but it provides support in building mock objects.
+Like return values, setting data will not ever make a test fail but it provides support in building mock objects.
 
 <a id="other_mock_support"> </a>
 
@@ -344,7 +395,7 @@ Like return values. Setting data will not ever make a test fail but it provides
 
 MockSupport offers a couple of other useful functions, which will be covered in this section.
 
-Frequently, you only want to check a couple of calls in your test and ignore all the other calls. If you add expectOneCall for each of these calls, you're tests might become too large (though, it might be a smell that your test is indeed too large). One way to prevent this is the ignoreOtherCalls, like:
+Frequently, you only want to check a couple of calls in your test and ignore all the other calls. If you add expectOneCall for each of these calls, your tests might become too large (though, it might be a smell that your test is indeed too large). One way to prevent this is the ignoreOtherCalls, like:
 
 {% highlight c++ %}
 mock().expectOneCall("foo");
@@ -373,7 +424,7 @@ int function () {
 
 If you try to ignore it or disable the framework, it will explode. Why ? The return value is not defined so there is no way to define the return value of the mocked function.
 
-To cases like these there is a series of return value functions that allows you to define a default return value, that will be returned when the mock function is ignored.
+To cases like these there is a series of return value functions that allows you to define a default return value that will be returned when the mock function is ignored.
 
 The example above could be written as:
 
@@ -447,29 +498,9 @@ mock("filesystem").ignoreOtherCalls();
 
 <a id="mock_plugin"> </a>
 
-### MockPlugin
-
-CppUTest plugins can be installed in the main and 'extent' the unit test framework. It is a place where you can put work that needs to be done in all unit tests. There is a MockPlugin to make the work with mocks easier. It does the following work:
-
-* checkExpectations at the end of every test (on global scope, which goes recursive over all scopes)
-* clear all expectations at the end of every test
-* install all comparators that were configured in the plugin at the beginning of every test
-* remove all comparators at the end of every test
-
-Installing the MockPlugin means you'll have to add to main something like:
-
-{% highlight c++ %}
-#include "CppUTest/TestRegistry.h"
-#include "CppUTestExt/MockSupportPlugin.h"
-
-MyDummyComparator dummyComparator;
-MockSupportPlugin mockPlugin;
-
-mockPlugin.installComparator("MyDummyType", dummyComparator);
-TestRegistry::getCurrentRegistry()->installPlugin(&mockPlugin);
-{% endhighlight %}
+### MockSupportPlugin
 
-This code creates a comparator for MyDummy and installs it at the plugin. This means the comparator is available for all test cases. It creates the plugin and installs it at the current test registry. After installing the plugin, you don't have to worry too much anymore about calling checkExpectations or cleaning your MockSupport.
+There is a MockSupportPlugin to make the work with mocks easier. Complete Documentation for MockSupportPlugin can be found on the [Plugin Manual](plugin_manual.html) page.
 
 <a id="c_interface"> </a>
 
@@ -481,7 +512,7 @@ Sometimes it is useful to access the mocking framework from a .c file rather tha
 #include "CppUTestExt/MockSupport_c.h"
 
 mock_c()->expectOneCall("foo")->withIntParameters("integer", 10)->andReturnDoubleValue(1.11);
-mock_c()->actualCall("foo")->withIntParameters("integer", 10)->returnValue().value.doubleValue;
+return mock_c()->actualCall("foo")->withIntParameters("integer", 10)->returnValue().value.doubleValue;
 
 mock_c()->installComparator("type", equalMethod, toStringMethod);
 mock_scope_c("scope")->expectOneCall("bar")->withParameterOfType("type", "name", object);
@@ -495,3 +526,29 @@ mock_c()->clear();
 {% endhighlight %}
 
 The C interface uses a similar builder structure as the C++ interface. It is far less common in C, but it works the same.
+
+It is now also possible to specify the actual return value in the same way as with C++ (v3.8):
+
+{% highlight c++ %}
+return mock_c()->actualCall("foo")->withIntParameters("integer", 10)->doubleReturnValue();
+return mock_c()->doubleReturnValue();
+{% endhighlight %}
+
+and to specify a default return value, in case mocking is currently disabled when the actual call occurs (v3.8):
+
+{% highlight c++ %}
+return mock_c()->actualCall("foo")->withIntParameters("integer", 10)->returnDoubleValueOrDefault(2.25);
+return mock_c()->returnDoubleValueOrDefault(2.25);
+{% endhighlight %}
+
+<a id="miscellaneous"></a>
+
+### Miscellaneous
+
+If you want your test to be more explicit about that a certain mocked function call should not occur, you can write (v3.8):
+
+{% highlight c++ %}
+mock().expectNoCall("productionCode");
+{% endhighlight %}
+
+Doing so is functionally equivalent to stating no expectations at all.
diff --git a/other_docs/WalkThrough_VS21010.docx b/other_docs/WalkThrough_VS21010.docx
new file mode 100644
index 0000000..1927edb
Binary files /dev/null and b/other_docs/WalkThrough_VS21010.docx differ
diff --git a/plugin_manual.markdown b/plugin_manual.markdown
new file mode 100644
index 0000000..3ead14a
--- /dev/null
+++ b/plugin_manual.markdown
@@ -0,0 +1,306 @@
+---
+layout: default
+title: Plugin Manual
+---
+
+CppUTest plugins can be installed in the main and 'extend' the unit test framework. A plugin is a place where you can put work that needs to be done in all unit tests.
+
+## Table of Content
+
+* [SetPointerPlugin](#setpointerplugin)
+* [MockSupportPlugin](#mocksupportplugin)
+* [IEEE754ExceptionsPlugin](#ieee754exceptionsplugin)
+* [OrderedTests](#orderedtests)
+
+<a id="setpointerplugin"> </a>
+
+## SetPointerPlugin
+
+### Description
+
+The SetPointerPlugin provides a Pointer restore mechanism - helpful when tests overwrite a pointer that must be restored to its original value after the test.  This is especially helpful when a pointer to a function is modified for test purposes.
+
+### Example
+
+{% highlight c++ %}
+int main(int ac, char** av)
+{
+    TestRegistry* r = TestRegistry::getCurrentRegistry();
+    SetPointerPlugin ps("PointerStore");
+    r->installPlugin(&ps);
+    return CommandLineTestRunner::RunAllTests(ac, av);
+}
+
+TEST_GROUP(HelloWorld)
+{
+   static int output_method(const char* output, ...)
+   {
+      va_list arguments;
+      va_start(arguments, output);
+      cpputest_snprintf(buffer, BUFFER_SIZE, output, arguments);
+      va_end(arguments);
+      return 1;
+   }
+   void setup()
+   {
+      // overwrite the production function pointer witha an output method that captures
+      // output in a buffer.
+      UT_PTR_SET(helloWorldApiInstance.printHelloWorld_output, &output_method);
+   }
+   void teardown()
+   {
+   }
+};
+
+TEST(HelloWorld, PrintOk)
+{
+   printHelloWorld();
+   STRCMP_EQUAL("Hello World!\n", buffer)
+}
+
+// Hello.h
+#ifndef HELLO_H_
+#define HELLO_H_
+
+extern void printHelloWorld();
+
+struct helloWorldApi {
+   int (*printHelloWorld_output) (const char*, ...);
+};
+
+#endif
+
+// Hello.c
+
+#include <stdio.h>
+#include "hello.h"
+
+// in production, print with printf.
+struct helloWorldApi helloWorldApiInstance = {
+   &printf
+};
+
+void printHelloWorld()
+{
+   helloWorldApiInstance.printHelloWorld_output("Hello World!\n");
+}
+{% endhighlight %}
+
+<a id="mocksupportplugin"> </a>
+
+## MockSupportPlugin
+
+MockSupportPlugin makes the work with mocks easier. It does the following work for you automatically: 
+
+* checkExpectations at the end of every test (on global scope, which goes recursive over all scopes)
+* clear all expectations at the end of every test
+* install all comparators that were configured in the plugin at the beginning of every test
+* remove all comparators at the end of every test
+
+Installing the MockPlugin means you'll have to add to main something like:
+
+{% highlight c++ %}
+#include "CppUTest/TestRegistry.h"
+#include "CppUTestExt/MockSupportPlugin.h"
+
+MyDummyComparator dummyComparator;
+MockSupportPlugin mockPlugin;
+
+mockPlugin.installComparator("MyDummyType", dummyComparator);
+TestRegistry::getCurrentRegistry()->installPlugin(&mockPlugin);
+{% endhighlight %}
+
+This code creates a comparator for MyDummy and installs it at the plugin. This means the comparator is available for all test cases. It creates the plugin and installs it at the current test registry. After installing the plugin, you don't have to worry too much anymore about calling checkExpectations or cleaning your MockSupport.
+
+<a id="ieee754exceptionsplugin"> </a>
+
+## IEEE754ExceptionsPlugin
+
+### Description
+
+This plugin detects floating point error conditions and fails the test, if any were found. According to the IEEE754 Floating Point Standard, floating point errors do not by default cause abnormal program termination. Rather, flags are set to indicate a problem, and the operation returns a defined value such as Infinity or Not-a-Number (NaN).
+
+This is a list of floating point error conditions, and how they are supported by the plugin:
+
+{% highlight c++ %}
+FE_DIVBYZERO   /* supported (v3.8) */
+FE_OVERFLOW    /* supported (v3.8) */
+FE_UNDERFLOW   /* supported (v3.8) */
+FE_INVALID     /* supported (v3.8) */
+FE_INEXACT     /* supported; disabled by default (v3.8) */
+FE_DENORMAL    /* NOT supported (v3.8) */
+{% endhighlight %}
+
+You can turn on FE_INEXACT checking manually, although this probably won't be very useful most of the time, since almost every floating-point operation is likely to set this flag:
+
+{% highlight c++ %}
+IEEE754ExceptionsPlugin::enableInexact();
+IEEE754ExceptionsPlugin::disableInexact();
+{% endhighlight %}
+
+### Example
+
+{% highlight c++ %}
+#include "CppUTest/CommandLineTestRunner.h"
+#include "CppUTest/TestRegistry.h"
+#include "CppUTestExt/IEEE754ExceptionsPlugin.h"
+
+int main(int ac, char** av)
+{
+    IEEE754ExceptionsPlugin ieee754Plugin;
+    TestRegistry::getCurrentRegistry()->installPlugin(&ieee754Plugin);
+    return CommandLineTestRunner::RunAllTests(ac, av);
+}
+
+static volatile float f;
+
+TEST_GROUP(CatchFloatingPointErrors)
+{
+    void setup()
+    {
+        IEEE754ExceptionsPlugin::disableInexact();
+    }
+};
+
+TEST(CatchFloatingPointErrors, underflow)
+{
+    f = 0.01f;
+    while (f > 0.0f) f *= f;
+    CHECK(f == 0.0f);
+}
+
+TEST(CatchFloatingPointErrors, inexact) {
+    IEEE754ExceptionsPlugin::enableInexact();
+    f = 10.0f;
+    DOUBLES_EQUAL(f / 3.0f, 3.333f, 0.001f);
+}
+{% endhighlight %}
+
+The output of these tests will be:
+{% highlight bash %}
+$ ./example.exe
+example.cpp:29: error: Failure in TEST(CatchFloatingPointErrors, inexact)
+src/CppUTestExt/IEEE754ExceptionsPlugin.cpp:164: error:
+        IEEE754_CHECK_CLEAR(FE_INEXACT) failed
+.
+example.cpp:22: error: Failure in TEST(CatchFloatingPointErrors, underflow)
+src/CppUTestExt/IEEE754ExceptionsPlugin.cpp:164: error:
+        IEEE754_CHECK_CLEAR(FE_UNDERFLOW) failed
+.
+Errors (2 failures, 2 tests, 2 ran, 12 checks, 0 ignored, 0 filtered out, 39 ms)
+$  
+{% endhighlight %}
+
+### Debugging floating point failures
+
+When a test fails due to a floating point error, it can be challenging to find the location of the offending operation, since the plugin has no knowledge of where the flag was originally set. To aid in debugging, there is are a number of static methods you can use to set up a watch:
+{% highlight c++ %}
+IEEE754ExceptionsPlugin::checkIeee754OverflowExceptionFlag();
+IEEE754ExceptionsPlugin::checkIeee754UnderflowExceptionFlag();
+IEEE754ExceptionsPlugin::checkIeee754InexactExceptionFlag();
+IEEE754ExceptionsPlugin::checkIeee754DivByZeroExceptionFlag();
+{% endhighlight %}
+Here is an minimal example using Gdb, example.cpp:
+{% highlight c++ %}
+#include "CppUTest/TestHarness.h"
+#include "CppUTestExt/IEEE754ExceptionsPlugin.h"
+
+static volatile float f = 1.0;
+static volatile IEEE754ExceptionsPlugin plugin;   // Make sure this is linked, so the debugger knows it
+
+int main(int, char**) {
+    f /= 0.0f;           // the offending statement
+    return 0;
+}
+{% endhighlight %}
+1) Compile the example. Your command line will look roughly like this:
+{% highlight bash %}
+$ g++ -Wextra -Wall -Werror -g3 -O0 -std=c++11 -Iinclude -Llib example.cpp -lCppUTest -lCppUTestExt -o example.exe
+{% endhighlight %}
+2) Start the example in Gdb:
+{% highlight bash %}
+$ gdb ./example.exe
+GNU gdb (GDB) 7.6.50.20130728-cvs (cygwin-special)
+#...more gdb output here...
+Reading symbols from /cygdrive/c/data/00_Dev/06_Faking/MiscellanousTests/example.exe...done.
+(gdb)
+{% endhighlight %}
+3) Set a breakpoint and run the example:
+{% highlight bash %}
+(gdb) break main
+Breakpoint 1 at 0x4011ab: file example.cpp, line 8.
+(gdb) run
+Starting program: /cygdrive/c/data/00_Dev/06_Faking/MiscellanousTests/example.exe
+[New Thread 6476.0x2038]
+[New Thread 6476.0x239c]
+
+Breakpoint 1, main () at example.cpp:8
+8           f /= 0.0f;
+(gdb)
+{% endhighlight %}
+4) Set up the watch you need:
+{% highlight bash %}
+(gdb) watch IEEE754ExceptionsPlugin::checkIeee754DivByZeroExceptionFlag()
+Watchpoint 2: IEEE754ExceptionsPlugin::checkIeee754DivByZeroExceptionFlag()
+(gdb)
+{% endhighlight %}
+5) Stepping over the offending statement will change the value of your watch:
+{% highlight bash %}
+(gdb) next
+Watchpoint 2: IEEE754ExceptionsPlugin::checkIeee754DivByZeroExceptionFlag()
+
+Old value = false
+New value = true
+0x004011b5 in main () at example.cpp:8
+8           f /= 0.0f;
+(gdb)
+{% endhighlight %}
+Of course you don't have to use commandline Gdb to do this; you can debug your code from within your favorite IDE (Eclipse, Code::Blocks, ...) following basically the same procedure.
+
+## OrderedTests
+
+### Usage
+
+{% highlight c++ %}
+TEST_ORDERED(TestGroup, TestName, Level) {}
+TEST_ORDERED_C_WRAPPER(TestGroup, TestName, Level)
+{% endhighlight %}
+
+Order: Test are executed from lowest to highest level. Tests with same same level are executed top down.
+
+{% highlight c++ %}
+#include "CppUTest/TestHarness.h"
+#include "CppUTestExt/OrderedTest.h"
+
+TEST_GROUP(TestOrderedTest) {}
+
+TEST_ORDERED(TestOrdered, Test3, 3) {
+    // 3. Test
+}
+
+TEST_ORDERED(TestOrdered, Test1, 1) {
+    // 1. Test
+}
+
+TEST_ORDERED(TestOrdered, Test4, 3) {
+    // 4. Test
+}
+
+TEST_ORDERED_C_WRAPPER(TestOrdered, Test2, 2)
+
+TEST_ORDERED_C_WRAPPER(TestOrdered, Test5, 5)
+{% endhighlight %}
+
+Only the C++-wrapper changes, the C-file synatx is as usual.
+
+{% highlight c++ %}
+#include "CppUTest/TestHarness_c.h"
+
+TEST_C(TestOrdered, Test2) {
+    // 2. Test
+}
+
+TEST_C(TestOrdered, Test5) {
+    // 5. Test
+}
+{% endhighlight %}
diff --git a/releases/cpputest-3.7.1.tar.gz b/releases/cpputest-3.7.1.tar.gz
new file mode 100644
index 0000000..541b8bb
Binary files /dev/null and b/releases/cpputest-3.7.1.tar.gz differ
diff --git a/releases/cpputest-3.7.1.zip b/releases/cpputest-3.7.1.zip
new file mode 100644
index 0000000..8d54de1
Binary files /dev/null and b/releases/cpputest-3.7.1.zip differ
diff --git a/releases/cpputest-3.7.2.tar.gz b/releases/cpputest-3.7.2.tar.gz
new file mode 100644
index 0000000..b68baef
Binary files /dev/null and b/releases/cpputest-3.7.2.tar.gz differ
diff --git a/releases/cpputest-3.7.2.zip b/releases/cpputest-3.7.2.zip
new file mode 100644
index 0000000..922bf7a
Binary files /dev/null and b/releases/cpputest-3.7.2.zip differ
diff --git a/releases/cpputest-3.7.tar.gz b/releases/cpputest-3.7.tar.gz
new file mode 100644
index 0000000..89fcc48
Binary files /dev/null and b/releases/cpputest-3.7.tar.gz differ
diff --git a/releases/cpputest-3.7.zip b/releases/cpputest-3.7.zip
new file mode 100644
index 0000000..d13c082
Binary files /dev/null and b/releases/cpputest-3.7.zip differ
diff --git a/releases/cpputest-3.8dev.tar.gz b/releases/cpputest-3.8dev.tar.gz
new file mode 100644
index 0000000..b68baef
Binary files /dev/null and b/releases/cpputest-3.8dev.tar.gz differ
diff --git a/releases/cpputest-3.8dev.zip b/releases/cpputest-3.8dev.zip
new file mode 100644
index 0000000..922bf7a
Binary files /dev/null and b/releases/cpputest-3.8dev.zip differ
diff --git a/stories.markdown b/stories.markdown
index 4a5416e..0d2d682 100644
--- a/stories.markdown
+++ b/stories.markdown
@@ -4,11 +4,16 @@ title: Useful CppUTest Application Stories
 ---
 
 # Useful CppUTest Application Stories
+
 ## Table of Content
+
 * [Unit Testing With IAR Embedded Workbench](#iar)
+* [Guide to setup CppUTest for Eclipse in Windows 7](#eclipsewindows7)
 
 <a id="iar"> </a>
+
 ## Unit Testing With IAR Embedded Workbench
+
 By Heath Raftery
 
 [The original post in CppUTest google group](https://groups.google.com/forum/#!topic/cpputest/WxCfnVZYGHw)
@@ -16,6 +21,7 @@ By Heath Raftery
 I've just completed an assessment of CppUTest for adoption as our company's standard Unit Testing framework. It was a bit of a battle at times but I've come out victorious so would like to share my experience for three reasons: see if there's anything I could be doing better; provide a crumb trail for other pioneers; and also contribute to CppUTest itself.
 
 One of our strict criteria is compatibility with IAR Embedded Workbench 6.4 projects. We don't want to have to maintain a separate build environment just to run tests. Here's what I found:
+
 Pulling from git source was best way to download, since that simultaneously allows us to make local changes to enable a build and store it all in our own repositories, while still allowing synchronisation with changes to the CppUTest source. As a bonus, for our users that don't want to know about git, as far as they're concerned they're pulling the software from our (SVN) repository.
 
 To build the CppUTest library in IAR, I created a new empty IAR project in the root folder of cpputest and made the following changes:
@@ -137,3 +143,20 @@ Show the Terminal I/O window to see the output. In non-verbose mode a dot is wri
 There's lots of other details to be considered such as Workspaces, build configurations, and what to do when things go wrong, but hopefully that's enough to get started.
 
 So that's about it. At the end of the day, CppUTest looks like it will meet our needs nicely. Once the initial setup is done, it integrates well into IAR and the output is readable within the IDE. The simulator provides a suitable alternative to execution on the PC (which means having to maintain a build with a different compiler) and execution on the hardware (which requires working hardware, Flash writes, functioning peripherals and is difficult to inject test vectors into).
+
+<a id="eclipsewindows7"> </a>
+
+## Guide to setup CppUTest for Eclipse in Windows 7
+
+By Miguel Mora Perea
+
+Can be found [at the github page](https://github.com/miguelmoraperea/guide_setup_cpputest_eclipse_win_7)
+
+<a id="eclipsewindows7"> </a>
+
+## Guide to setup CppUTest with Windows 10 with WSL
+
+By Rob Baragona
+
+Can be found [at the github page](https://github.com/RBaragona/Windows-10-with-WSL-cpputest-starter-project)
+
