Update README.md

5 files changed, 16 insertions, 22 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).