Update README.md

8 files changed, 23 insertions, 28 deletions

diff --git a/network/ndis/filter/ReadMe.md b/network/ndis/filter/ReadMe.md
index 386115a1..6967f1b6 100644
--- a/network/ndis/filter/ReadMe.md
+++ b/network/ndis/filter/ReadMe.md
@@ -20,13 +20,11 @@ Before you automatically deploy a driver, you must provision the target computer
 4.  On the target computer, open **Control Panel**. Click **Network and Internet** and then open **Network and Sharing Center**.
 5.  Under **View your active networks**, click the connection listed under **Connections:** and click **Properties**. If you have previously installed this sample, highlight it in the list.
 6.  Click **Install**, then **Service**, then **Add**.
-    **Note**  You may see multiple instances of the **NDIS Sample LightWeight Filter** service. If so, highlight the newest one.
+    **Note** You may see multiple instances of the **NDIS Sample LightWeight Filter** service. If so, highlight the newest one.
 7.  Click **Have Disk**.
 8.  In the **Install from Disk** dialog, browse to the DriverTest\\Drivers directory. Highlight the netlwf.inf file and click **Open**, then click OK. This should show **NDIS Sample LightWeight Filter** in a list of **Network Services**. Highlight **NDIS Sample LightWeight Filter** and click **OK**. Click **OK**. Click **Close**. Click **Close**. This installs the Ndislwf filter driver service.
 
-**Note**  
-
-If you've installed the Ndislwf sample on the target computer before, you can use the [PnPUtil](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550419) tool to delete the older versions from the driver store.
+**Note** If you've installed the Ndislwf sample on the target computer before, you can use the [PnPUtil](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550419) tool to delete the older versions from the driver store.
 
 Manual deployment
 -----------------
@@ -47,9 +45,7 @@ Ndislwf is installed as a service (called **NDIS Sample LightWeight Filter** in
 5.  Click **Install**, then **Service**, then **Add**, then **Have Disk**.
 6.  Browse to the installation directory. Highlight the netlwf.inf file and click **Open**, then click OK. This should show **NDIS Sample LightWeight Filter** in a list of Network Services. Highlight this and click OK. Click OK. This installs the Ndislwf filter driver.
 
-**Note**  
-
-If you've installed the Ndislwf sample on the target computer before, you can use the [PnPUtil](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550419) tool to delete the older versions from the driver store.
+**Note** If you've installed the Ndislwf sample on the target computer before, you can use the [PnPUtil](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550419) tool to delete the older versions from the driver store.
 
 Viewing sample output in the debugger
 -------------------------------------
@@ -60,7 +56,7 @@ If you chose to deploy your driver automatically, then kernel debugging is alrea
 
 On the host computer, in **Visual Studio**, in the **Debug** menu, choose **Attach to Process**. For **Transport**, choose **Windows Kernel Mode Debugger**. For **Qualifier**, choose the name of your target computer. Click **Attach**.
 
-**Note**  If you see a dialog box that asks you to allow the debugger to communicate through the firewall, click the boxes for all types of networks. Click **Allow Access**.
+**Note** If you see a dialog box that asks you to allow the debugger to communicate through the firewall, click the boxes for all types of networks. Click **Allow Access**.
 
 For more information, see [Setting Up Kernel-Mode Debugging in Visual Studio](http://msdn.microsoft.com/en-us/library/windows/hardware/hh439376).
 
diff --git a/network/ndis/mux/ReadMe.md b/network/ndis/mux/ReadMe.md
index cc864aec..eb0cbedf 100644
--- a/network/ndis/mux/ReadMe.md
+++ b/network/ndis/mux/ReadMe.md
@@ -44,7 +44,7 @@ With the default configured VLAN ID of zero, the driver does not insert tag head
 
 ### Configuring VLANs
 
-The VLAN ID for each VELAN (virtual miniport) can be configured as follows. Right-click on the virtual miniport Local Area Connection icon and choose Properties. Click on the Configure button to bring up the Device Manager UI for the virtual device. Select the Advanced property sheet – this should contain a “VLAN ID” parameter that is configurable to the desired VLAN ID. Choosing a value of 0 (zero) disables receive-side filtering based on VLAN ID.
+The VLAN ID for each VELAN (virtual miniport) can be configured as follows. Right-click on the virtual miniport Local Area Connection icon and choose Properties. Click on the Configure button to bring up the Device Manager UI for the virtual device. Select the Advanced property sheet, this should contain a VLAN ID parameter that is configurable to the desired VLAN ID. Choosing a value of 0 (zero) disables receive-side filtering based on VLAN ID.
 
 ### Programming Tour
 
@@ -52,13 +52,13 @@ When it loads, i.e. from its DriverEntry function, the MUX driver registers as a
 
 ### Binding and VELAN Creation
 
-NDIS calls MUX’s BindAdapter function, `PtBindAdapter`, for each underlying NDIS adapter to which it is configured to bind. This function allocates an `ADAPT` structure to represent the lower adapter, and calls `NdisOpenAdapter` to set up a binding to it. In the context of `BindAdapterHandler`, after successfully opening a binding to the underlying adapter, the driver queries the reserved keyword "UpperBindings" to get a list of device names for the virtual adapters that this particular binding is to expose – see `PtBootStrapVElans` for more details. Note that the MUX driver does not create bindings (i.e. call `NdisOpenAdapter`) from any context other than its BindAdapter function – this is recommended behavior for all drivers of this type.
+NDIS calls MUX’s BindAdapter function, `PtBindAdapter`, for each underlying NDIS adapter to which it is configured to bind. This function allocates an `ADAPT` structure to represent the lower adapter, and calls `NdisOpenAdapter` to set up a binding to it. In the context of `BindAdapterHandler`, after successfully opening a binding to the underlying adapter, the driver queries the reserved keyword "UpperBindings" to get a list of device names for the virtual adapters that this particular binding is to expose – see `PtBootStrapVElans` for more details. Note that the MUX driver does not create bindings (i.e. call `NdisOpenAdapter`) from any context other than its BindAdapter function. This is recommended behavior for all drivers of this type.
 
 For each device name specified in the “UpperBindings” key, the MUX driver allocates a VELAN data structure to represent the virtual miniport, calls `NdisIMInitializeDeviceInstanceEx`. In response, NDIS eventually calls the MUX miniport’s MiniportInitialize entry point, MPInitialize, for each VELAN. After MPInitialize successfully returns, NDIS takes care of getting upper-layer protocols to bind to the newly created virtual adapter(s).
 
 ### Unbinding and Halting
 
-NDIS calls MUX’s `UnbindAdapter` handler, `PtUnbindAdapter`, to request it to unbind from a lower adapter. In processing this, MUX calls `NdisIMDeInitializeDeviceInstance` for each VELAN instantiated on the indicated adapter – see `PtStopVElan` for details. This call results in NDIS first unbinding any protocols bound to the indicated VELAN, and then calling the MiniportHalt routine, `MPHalt`, for that VELAN. `MPHalt` waits for any outstanding receives/sends on the VELAN to finish before unlinking the VELAN from the ADAPT.
+NDIS calls MUX's `UnbindAdapter` handler, `PtUnbindAdapter`, to request it to unbind from a lower adapter. In processing this, MUX calls `NdisIMDeInitializeDeviceInstance` for each VELAN instantiated on the indicated adapter – see `PtStopVElan` for details. This call results in NDIS first unbinding any protocols bound to the indicated VELAN, and then calling the MiniportHalt routine, `MPHalt`, for that VELAN. `MPHalt` waits for any outstanding receives/sends on the VELAN to finish before unlinking the VELAN from the ADAPT.
 
 `PtUnbindAdapter` itself blocks until all VELANs associated with the ADAPT structure have been unlinked from it. This is to make sure that no thread running in the context of a miniport-edge entry point for a VELAN will ever access an invalid lower binding handle. Once all VELANs have been unlinked, `PtUnbindAdapter` closes the lower binding by calling `NdisCloseAdapter`. Note that the MUX driver does not close its lower binding from any context other than its `UnbindAdapter` function – this is recommended behavior for all drivers of this type.
 
@@ -80,7 +80,7 @@ Some power management OIDs are forwarded to the lower miniport. See “Handling
 
 Data sent down on a VELAN miniport is forwarded to the lower adapter. The MUX driver itself does not generate any data of its own. The MUX driver clones a `NET_BUFFER_LIST` for each `NetBufferList` passed to its `MPSendNetBufferLists` function, and saves a pointer to the original `NET_BUFFER_LIST` in the reserved area of the `NET_BUFFER_LIST` structure. When the lower adapter completes the send (`PtSendNBLComplete`), MUX picks up the original packet and calls `NdisMSendNetBufferListsComplete` to complete the original send request.
 
-If a non-zero VLAN ID is configured for the VELAN, and/or the packet has non-zero Ieee8021QInfo per-packet information, then the MUX driver inserts an NDIS buffer containing a tag header to the front of the packet before sending it down – see function `MPHandleSendTagging` for details.
+If a non-zero VLAN ID is configured for the VELAN, and/or the packet has non-zero Ieee8021QInfo per-packet information, then the MUX driver inserts an NDIS buffer containing a tag header to the front of the packet before sending it down, see function `MPHandleSendTagging` for details.
 
 ### Receiving Data
 
@@ -88,7 +88,7 @@ Data received from a lower adapter is indicated up on zero or more VELANs. The `
 
 The driver’s `MPReturnNetBufferLists` function is called either by NDIS or by MUX itself when protocols are done with a received `NET_BUFFER_LIST`. This function returns the original `NET_BUFFER_LIST` indicated by the lower driver, if any, by calling `NdisReturnNetBufferLists.`
 
-The driver indicates up received frames that do not have an IEEE 802.1Q tag header in them – see function `PtHandleRcvTagging`. It always strips off tag headers, if present, on received frames. If a non-zero VLAN ID is configured, then it checks received frames that contain tag headers for matching VLAN Ids – only matching frames are indicated up to protocols. Any VLAN/priority information present in incoming frames is copied to per-packet information fields of indicated `NET_BUFFER_LIST` structures.
+The driver indicates up received frames that do not have an IEEE 802.1Q tag header in them, see function **PtHandleRcvTagging**. It always strips off tag headers, if present, on received frames. If a non-zero VLAN ID is configured, then it checks received frames that contain tag headers for matching VLAN Ids, only matching frames are indicated up to protocols. Any VLAN/priority information present in incoming frames is copied to per-packet information fields of indicated `NET_BUFFER_LIST` structures.
 
 ### Status Indications
 
@@ -114,7 +114,7 @@ Queries/sets received on a VELAN miniport that are to be forwarded to the underl
 
 ### Handling Global Reconfiguration
 
-All modifications to VELAN configuration are accompanied by PnP reconfigure notifications, i.e. `NetEventReconfigure` events passed to the MUX’s `PnPEventHandler`, `PtPNPHandler`. This driver takes a broad approach to handling reconfiguration, which is to simply re-examine all the “UpperBindings” keys for all currently bound adapters, and start off VELANs for any that do not exist – see `PtBootStrapVElans` for details.
+All modifications to VELAN configuration are accompanied by PnP reconfigure notifications, for example, `NetEventReconfigure` events passed to the MUX’s `PnPEventHandler`, `PtPNPHandler`. This driver takes a broad approach to handling reconfiguration, which is to simply re-examine all the “UpperBindings” keys for all currently bound adapters, and start off VELANs for any that do not exit, see `PtBootStrapVElans` for details.
 
 ### Canceling Sends
 
@@ -177,5 +177,5 @@ Precomp.h | Precompile header file
 Protocol.c | Protocol related routines for the MUX driver 
 Public.h | Contains the common declarations shared by driver and user applications
 
-For more information, see **NDIS Intermediate Drivers** in the network devices design guide.
+For more information, see [NDIS Intermediate Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff565773) in the network devices design guide.
 
diff --git a/network/ndis/ndisprot/6x/ReadMe.md b/network/ndis/ndisprot/6x/ReadMe.md
index cdf35d7c..55843a0c 100644
--- a/network/ndis/ndisprot/6x/ReadMe.md
+++ b/network/ndis/ndisprot/6x/ReadMe.md
@@ -32,7 +32,7 @@ options | Description
 
 Prottest exercises the IOCTLs supported by NDISPROT, and sends and/or receives data on the selected device. In order to use prottest, the user must have administrative privilege. Users should pass down a big enough buffer in order to receive the entire received data. If the length of the buffer passed down is smaller than the length of the received data, NDISPROT will only copy part of the data and discard the rest when the given buffer is full.
 
-Use the **–e** option to enumerate all devices to which NDISPROT is bound:
+Use the **-e** option to enumerate all devices to which NDISPROT is bound:
 
 **C:\\prot\>prottest -n 2 \\DEVICE\\{9273DA7D-5275-4B9A-AC56-68A49D121F1F}**
 
@@ -40,7 +40,7 @@ Use the **–e** option to enumerate all devices to which NDISPROT is bound:
 
 **DoReadProc finished: read 2 packets**
 
-**Note**  With a checked version of ndisprot.sys, you can control the volume of debug information generated by changing the variable `ndisprotDebugLevel`. Refer to debug.h for more information.
+**Note** With a checked version of ndisprot.sys, you can control the volume of debug information generated by changing the variable `ndisprotDebugLevel`. Refer to debug.h for more information.
 
 For more information, see [NDIS Protocol Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff566821) in the network devices design guide.
 
diff --git a/network/ndis/ndisprot_kmdf/ReadMe.md b/network/ndis/ndisprot_kmdf/ReadMe.md
index 422a7ace..7a9ee69c 100644
--- a/network/ndis/ndisprot_kmdf/ReadMe.md
+++ b/network/ndis/ndisprot_kmdf/ReadMe.md
@@ -16,7 +16,7 @@ Build the sample
 
 For information on how to build a driver solution using Microsoft Visual Studio, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644).
 
-The 60 subdirectory (src\\network\\ndis\\ndisprot\_kmdf\\60) indicates that the built sample will be NDIS 6.0 compatible and will work on Windows Vista and later operating systems.
+The 60 subdirectory (src\\network\\ndis\\ndisprot\_kmdf\\60) indicates that the built sample will be NDIS 6.0 compatible.
 
 Installation
 ------------
@@ -26,9 +26,7 @@ Use the following steps to install the sample.
 1.  When you build the sample, the build engine produces ndisprot.inf in the build target directory. Copy nprt6wdf.sys, protnotify.dll, and ndisprot.inf to a directory.
 2.  Copy the KMDF coinstaller (wdfcoinstaller*MMmmm*.dll) to the same directory.
 
-    **Note**  
-
-    You can obtain redistributable framework updates by downloading the *wdfcoinstaller.msi* package from [WDK 8 Redistributable Components](http://go.microsoft.com/fwlink/p/?LinkID=226396). This package performs a silent install into the directory of your Windows Driver Kit (WDK) installation. You will see no confirmation that the installation has completed. You can verify that the redistributables have been installed on top of the WDK by ensuring there is a redist\\wdf directory under the root directory of the WDK, %ProgramFiles(x86)%\\Windows Kits\\8.0.
+    **Note** You can obtain redistributable framework updates by downloading the *wdfcoinstaller.msi* package from [WDK 8 Redistributable Components](http://go.microsoft.com/fwlink/p/?LinkID=226396). This package performs a silent install into the directory of your Windows Driver Kit (WDK) installation. You will see no confirmation that the installation has completed. You can verify that the redistributables have been installed on top of the WDK by ensuring there is a redist\\wdf directory under the root directory of the WDK, %ProgramFiles(x86)%\\Windows Kits\\8.0.
 
 3.  In Control Panel, in the **Network and Internet** group, open **Network Connections**, select an adapter, and then open **Properties**.
 
diff --git a/network/ndis/netvmini/6x/ReadMe.md b/network/ndis/netvmini/6x/ReadMe.md
index a056a846..76020b5d 100644
--- a/network/ndis/netvmini/6x/ReadMe.md
+++ b/network/ndis/netvmini/6x/ReadMe.md
@@ -9,7 +9,7 @@ This sample driver demonstrates an NDIS virtual miniport driver. If a single ins
 
 To test the miniport driver, install more than one miniport driver instance. You can repeat the installation to install more than one instance of the miniport.
 
-**Note**  This sample provides an example of minimal driver intended for education purposes. The driver and its sample test programs are not intended for use in a production environment.
+**Note** This sample provides an example of minimal driver intended for education purposes. The driver and its sample test programs are not intended for use in a production environment.
 
 For more information on creating NDIS Miniport Drivers, see [NDIS Miniport Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff565949).
 
diff --git a/network/radio/RadioManagerSample/ReadMe.md b/network/radio/RadioManagerSample/ReadMe.md
index e62f096c..e391e051 100644
--- a/network/radio/RadioManagerSample/ReadMe.md
+++ b/network/radio/RadioManagerSample/ReadMe.md
@@ -7,7 +7,7 @@ The operating system contains a set of APIs which are used as a software mechani
 
 When the user turns the radio off (either by using the specific radio software switch or the airplane mode switch), radio transmission must be turned off. The device can be powered off as long as the radio switch does not disappear from the UI. It is very important that the radio manager developer ensures that when the device is powered off, the radio switch does not disappear from the UI. If the radio switch disappears from the UI when the radio is turned off by the user, then user has no way to turn the radio back on! If it is desired to conserve power by cutting power to the device when the radio is turned off, but the device cannot be completely powered off because it disappears from the UI, then the solution would be to put the device in a low power state (e.g. D3).
 
-**Important**  The radio manager MUST be given a name. This is the name of the radio switch that is displayed to the user in the Wireless page of PC Settings. The name must be simple, yet descriptive of what the radio is. For example, for NFC radios, the value of the name field should be "NFC", and for GPS radios, the value of the name field should be "GPS" or "GNSS", whichever is more appropriate. The name must not include the word "radio" or the manufacturer's name or some other word related to the functionality of the radio (e.g. "Location" OR "port").
+**Important** The radio manager must be given a name. This is the name of the radio switch that is displayed to the user in the Wireless page of PC Settings. The name must be simple, yet descriptive of what the radio is. For example, for NFC radios, the value of the name field should be "NFC", and for GPS radios, the value of the name field should be "GPS" or "GNSS", whichever is more appropriate. The name must not include the word "radio" or the manufacturer's name or some other word related to the functionality of the radio (e.g. "Location" OR "port").
 
 
 Installation
@@ -57,9 +57,9 @@ IsMultiComm
 
 IsAssociatingDevice
 
-\*\*\* It is required that the registry key has AT LEAST a Name value, otherwise the Sample Radio Manager will fail to initialize. \*\*\*
+**Note** It is required that the registry key has AT LEAST a Name value, otherwise the Sample Radio Manager will fail to initialize.
 
-**Important**   The radio manager must be given a name and the registry key must have, as a minimum, a Name value. Otherwise, the Sample Radio Manager will fail to initialize. This is the name of the radio switch that is displayed to the user in the Wireless page of PC Settings. The name must be simple, yet descriptive of what the radio is. For example, for NFC radios, the value of the name field should be "NFC", and for GPS radios, the value of the name field should be "GPS" or "GNSS", whichever is more appropriate. The name must not include the word "radio" or the manufacturer's name or some other word related to the functionality of the radio (e.g. "Location" OR "port").
+**Important** The radio manager must be given a name and the registry key must have, as a minimum, a Name value. Otherwise, the Sample Radio Manager will fail to initialize. This is the name of the radio switch that is displayed to the user in the Wireless page of PC Settings. The name must be simple, yet descriptive of what the radio is. For example, for NFC radios, the value of the name field should be "NFC", and for GPS radios, the value of the name field should be "GPS" or "GNSS", whichever is more appropriate. The name must not include the word "radio" or the manufacturer's name or some other word related to the functionality of the radio (e.g. "Location" OR "port").
 
 When the Radio Manager is initialized, it uses these registry keys to retrieve the "radio" information. The radio state values can be any of the following enum values:
 
diff --git a/network/trans/ReadMe.md b/network/trans/ReadMe.md
index 9dd3585e..5f7ea8a8 100644
--- a/network/trans/ReadMe.md
+++ b/network/trans/ReadMe.md
@@ -82,7 +82,7 @@ wfpsamplercalloutdriver.cat | A signed catalog file, which serves as the signatu
 WFPSamplerCalloutDriver.inf | An information (INF) file that contains information needed to install the driver.
 WFPSamplerCalloutDriver.sys | The WFPSampler driver.
 
-**Note**  The build process might also put WdfCoinstaller010*xx*.dll in the driver folder, but this file is not really part of the driver package. The INF file does not reference any coinstallers.    
+**Note**�The build process might also put WdfCoinstaller010*xx*.dll in the driver folder, but this file is not really part of the driver package. The INF file does not reference any coinstallers.    
 
 Because the package does not contain a KMDF coinstaller, it is important that you set the KMDF minor version according to your target operating system when you built the driver.
 
@@ -147,7 +147,8 @@ Installing the driver
     -   For automatic deployment, this will be DriverTest\\Drivers.
 
 2.  Enter **WFPSamplerInstall.cmd** to run the installation script.
-    **Note**  If you need to uninstall a previous version of the driver, enter **WFPSamplerInstall.cmd -r**.
+
+    **Note** If you need to uninstall a previous version of the driver, enter **WFPSamplerInstall.cmd -r**.
 
 Running the user-mode application
 ---------------------------------
diff --git a/network/trans/msnmntr/ReadMe.md b/network/trans/msnmntr/ReadMe.md
index 9c980db4..fcc9c420 100644
--- a/network/trans/msnmntr/ReadMe.md
+++ b/network/trans/msnmntr/ReadMe.md
@@ -5,7 +5,7 @@ This sample application and driver demonstrate the stream inspection capabilitie
 
 The sample consists of a user mode application (Monitor.exe) that registers traffic of interest. In this case, all Transmission Control Protocol (TCP) data segments that are sent and received by an application of your choice.
 
-**Note**  Originally this sample was written to monitor the MSN Messenger application. Now it can monitor any application that you specify.
+**Note** Originally this sample was written to monitor the MSN Messenger application. Now it can monitor any application that you specify.
 
 Monitor.exe adds filters and callouts to Windows through the Windows Filtering Platform (WFP) Win32 API. A kernel-mode WFP callout driver (Msnmntr.sys) intercepts TCP traffic and parses out communication patterns. Monitor.exe controls the operations of the callout driver through I/O controls (IOCTLs).