Fixed typo's and improved consistency. (#704)

doc/AddASetting.md

@@ -13,7 +13,7 @@
 2. Add matching fields to Settings.hpp
     - add getters, setters, the whole drill.
 
-3. Add to the propsheet.
+3. Add to the propsheet
     - We need to add it to *reading and writing* the registry from the propsheet, and *reading* the link from the propsheet. Yes, that's weird, but the propsheet is smart enough to re-use ShortcutSerialization::s_SetLinkValues, but not smart enough to do the same with RegistrySerialization.
     - `src/propsheet/registry.cpp`
         -  `propsheet/registry.cpp@InitRegistryValues` should initialize the default value for the property.
@@ -28,7 +28,7 @@
 6. Add the setting to `Menu::s_GetConsoleState`, and `Menu::s_PropertiesUpdate`
 Now, your new setting should be stored just like all the other properties.
 
-7. Update the feature test properties to get add the setting as well.
+7. Update the feature test properties to get add the setting as well
     - `ft_uia/Common/NativeMethods.cs@WinConP`:
         - `Wtypes.PROPERTYKEY PKEY_Console_`
         - `NT_CONSOLE_PROPS`
@@ -36,5 +36,5 @@ Now, your new setting should be stored just like all the other properties.
 8. Add the default value for the setting to `win32k-settings.man`
     - If the setting shouldn't default to 0 or `nullptr`, then you'll need to set the default value of the setting in `win32k-settings.man`.
 
-9. Update `Settings::InitFromStateInfo` and `Settings::CreateConsoleStateInfo` to get/set the value in a CONSOLE_STATE_INFO appropriately.
+9. Update `Settings::InitFromStateInfo` and `Settings::CreateConsoleStateInfo` to get/set the value in a CONSOLE_STATE_INFO appropriately
 

doc/ConsoleCtrlEvent.md

@@ -2,7 +2,7 @@
 
 ## Generation
 
-conhost requests that user32 inject a thread into the attached console application.
+conhost requests that user32 injects a thread into the attached console application.
 See ntuser's exitwin.c for `CreateCtrlThread`.
 
 ## Timeouts

doc/ConsoleHostSettings.md

@@ -1,6 +1,6 @@
 # Understanding Console Host Settings
 
-Settings in the Windows Console Host can be a bit tricky to understand. This is mostly because the settings system evolved over the course of decades. Before we dig into the details of how settings are persisted, it's probably worth a quick look at what these settings are.
+Settings in the Windows Console Host can be a bit tricky to understand. This is mostly because the settings system evolved over the course of decades. Before we dig into the details of how settings are persisted, it's probably worth taking a quick look at what these settings are.
 
 ## Settings Description
 

doc/Debugging.md

@@ -6,5 +6,5 @@ This file contains notes about debugging various items in the repository.
 
 If you want to debug code in the Cascadia package via Visual Studio, your breakpoints will not be hit by default. A tweak is required to the *CascadiaPackage* project in order to enable this.
 
-1. Right-click on *CascadiaPackage* in Solution Explorer and select Properties
+1. Right-click on *CascadiaPackage* in Solution Explorer and select Properties.
 2. Change the *Application process* type from *Mixed (Managed and Native)* to *Native Only*.

doc/ORGANIZATION.md

@@ -4,7 +4,7 @@
 
 - **Follow the pattern of what you already see in the code**
 - Try to package new ideas/components into libraries that have nicely defined interfaces
-- Package new ideas into classes or refactor existing ideas into a class as you extend. 
+- Package new ideas into classes or refactor existing ideas into a class as you extend
 - Each project should have a Unit test in a ut_ folder in its subdirectory (like `ut_host`)
 - Functional tests should be in ft_ subdirectories (like `ft_api`)
 - Build scripts are generally in subdirectories with their type of output (like `/dll` or `/exe`)

doc/UniversalTest.md

@@ -7,13 +7,13 @@ Universal Testing is the Microsoft framework for creating and deploying test pac
 It involves several parts:
 - TESTMD
   - These define a package unit for deployment to the test device. This usually includes the test binaries and any dependent data that it will need to execute.
-  - There can also be a hierarchy where one package can depend on another such that packages can be re-used
+  - There can also be a hierarchy where one package can depend on another such that packages can be re-used.
 
 - TESTLIST
   - This defines a batch of TESTMD packages that should be executed together.
 
 - TESTPASSES
-  - This defines a list of tests via a TESTLIST and a lab environment configuration on which the tests should be run
+  - This defines a list of tests via a TESTLIST and a lab environment configuration on which the tests should be run.
 
   These files can either include their child element as they're supposed to (TESTMDs included in TESTLISTs) or they can often include themselves to provide chain structuring (one TESTLIST can reference another TESTLIST).
 

doc/WindowsTestPasses.md

@@ -24,9 +24,9 @@ Prerequisites:
 - Visual Studio 2017
 - Install the TDP (Test Development Platform) plug-in (see: [https://osgwiki.com/wiki/Test_Development_Platform_(TDP)]).
 
-1. Open Visual Studio 2017 and use the TDP drop-down menu to open the `Device Manager`
+1. Open Visual Studio 2017 and use the TDP drop-down menu to open the `Device Manager`.
 1. In the pane that opens to the left, choose `Add` and then `Nebula VM Device`. Nebula is a cloud provider for VMs (like Azure but a more private instance for corporate work usage).
-1. Name the machine and choose the build/branch/flavor/SKU from the drop downs at the bottom. It will find the VHD for you from the build shares. Hit `Add Device` to deploy to Nebula
+1. Name the machine and choose the build/branch/flavor/SKU from the drop downs at the bottom. It will find the VHD for you from the build shares. Hit `Add Device` to deploy to Nebula.
 1. Wait a few minutes. It took 5-10 for it to be deployed.
 1. Right click the machine name in the `Device Manager` list and choose `Launch T-Shell`. You can also use `Connect via Console` to get a "remote desktop"-like session to the KVM port on the VM.
 1. In T-shell, use `testd Microsoft.Console.TestLab.Desktop.testlist` or a command of that format with a different TESTLIST or TESTMD name from our project (see the [UniversalTest.md] documentation). The `testd` utility will automatically resolve the build/branch/flavor information, dig through the build shares for the matching TESTLIST/TESTMD metadata, and attempt to deploy all relevant packages and dependencies on the device. When it's successful, it will move onto running all the tests and giving you the results. On conclusion, the test results should pop up in the web browser or the `Hubble - Log Viewer` tool provided by the Engineering Systems team.

doc/building.md

@@ -8,18 +8,18 @@ Openconsole can be built with Visual Studio or from the command line. There are
 The cmd scripts are set up to emulate a portion of the OS razzle build environment. razzle.cmd is the first script that should be run. bcz.cmd will build clean and bz.cmd should build incrementally.
 
 There are also scripts for running the tests:
-- runut.cmd - run the unit tests
-- runft.cmd - run the feature tests
-- runuia.cmd - run the UIA tests
+- `runut.cmd` - run the unit tests
+- `runft.cmd` - run the feature tests
+- `runuia.cmd` - run the UIA tests
 
 ## Build with Powershell
 
 Openconsole.psm1 should be loaded with `Import-Module`. From there `Set-MsbuildDevEnvironment` will set up environment variables required to build. There are a few exported functions (look at their documentation for further details):
 
-- Invoke-OpenConsolebuild - builds the solution. Can be passed msbuild arguments.
-- Invoke-OpenConsoleTests - runs the various tests. Will run the unit tests by default.
-- Start-OpenConsole - starts Openconsole.exe from the output directory. x64 is run by default.
-- Debug-OpenConsole - starts Openconsole.exe and attaches it to the default debugger. x64 is run by default.
+- `Invoke-OpenConsolebuild` - builds the solution. Can be passed msbuild arguments.
+- `Invoke-OpenConsoleTests` - runs the various tests. Will run the unit tests by default.
+- `Start-OpenConsole` - starts Openconsole.exe from the output directory. x64 is run by default.
+- `Debug-OpenConsole` - starts Openconsole.exe and attaches it to the default debugger. x64 is run by default.
 
 ## Configuration Types