From 93217010e0c3d492c432fbccb167f6070775ba36 Mon Sep 17 00:00:00 2001 From: Barry Golden Date: Fri, 7 Aug 2015 17:05:36 -0700 Subject: [PATCH] Update README.md --- README.md | 4 +- audio/sysvad/ReadMe.md | 2 +- avstream/avshws/ReadMe.md | 10 +- avstream/avssamp/ReadMe.md | 47 ++-- bluetooth/bthecho/ReadMe.md | 24 +- bluetooth/serialhcibus/ReadMe.md | 36 +-- general/echo/umdf/ReadMe.md | 2 +- general/echo/umdfSocketEcho/ReadMe.md | 2 +- general/ioctl/kmdf/ReadMe.md | 2 - general/obcallback/ReadMe.md | 12 +- general/pcidrv/ReadMe.md | 8 +- hid/firefly/ReadMe.md | 6 +- hid/hidusbfx2/ReadMe.md | 226 ++++-------------- input/kbfiltr/ReadMe.md | 26 +- network/ndis/filter/ReadMe.md | 18 +- network/ndis/mux/ReadMe.md | 34 +-- network/ndis/ndisprot_kmdf/ReadMe.md | 117 +++------ network/trans/ReadMe.md | 4 +- network/wsk/echosrv/ReadMe.md | 2 +- print/XpsRasFilter/ReadMe.md | 2 +- print/autoconfig/ReadMe.md | 4 +- .../ReadMe.md | 2 +- security/elam/ReadMe.md | 2 +- serial/serenum/ReadMe.md | 2 +- setup/devcon/ReadMe.md | 2 +- spb/SpbTestTool/ReadMe.md | 10 +- .../sdv/samples/SDV-FailDriver-KMDF/ReadMe.md | 2 +- .../sdv/samples/SDV-FailDriver-NDIS/ReadMe.md | 2 +- .../samples/SDV-FailDriver-STORPORT/ReadMe.md | 2 +- .../sdv/samples/SDV-FailDriver-WDM/ReadMe.md | 2 +- usb/kmdf_fx2/ReadMe.md | 2 +- usb/umdf_filter_kmdf/ReadMe.md | 2 +- usb/usbsamp/ReadMe.md | 2 +- video/KMDOD/ReadMe.md | 27 +-- wpd/WpdBasicHardwareDriver/ReadMe.md | 6 +- 35 files changed, 219 insertions(+), 434 deletions(-) diff --git a/README.md b/README.md index 0ac20e551..af838f2cc 100644 --- a/README.md +++ b/README.md @@ -9,7 +9,7 @@ Use Visual Studio 2015 and Windows Driver Kit (WDK) 10 to build, test, and deplo ### Windows 10 Driver Kit (WDK) Take a look at the compilation of the new and changed driver-related content for Windows 10. Areas of improvement include camera, print, display, Near Field Communication (NFC), WLAN, Bluetooth, and more. -[Find out what’s new in the WDK](http://go.microsoft.com/fwlink/p/?LinkId=528349 "Find out what's new in the WDK") +[Find out what's new in the WDK](http://go.microsoft.com/fwlink/p/?LinkId=528349 "Find out what's new in the WDK") ### Universal Windows drivers Write one driver that runs on both Windows 10 for desktop editions and Windows 10 Mobile devices, as well as other Windows 10 editions that share a common set of interfaces. @@ -22,7 +22,7 @@ The Windows Driver Frameworks (WDF) are a set of libraries that make it simple t [WDF driver development guide](http://go.microsoft.com/fwlink/p/?LinkId=524489 "WDF driver development guide") ### Samples -Use the samples in this repo to guide your Windows driver development. Whether you’re just getting started or porting an older driver to the newest version of Windows, code samples are valuable guides on how to write drivers. +Use the samples in this repo to guide your Windows driver development. Whether you're just getting started or porting an older driver to the newest version of Windows, code samples are valuable guides on how to write drivers. ### Build your first driver If you're writing your first driver, use these exercises to get started. Each exercise is independent of the others, so you can do them in any order. diff --git a/audio/sysvad/ReadMe.md b/audio/sysvad/ReadMe.md index 87dbe85b1..bb553998d 100644 --- a/audio/sysvad/ReadMe.md +++ b/audio/sysvad/ReadMe.md @@ -96,7 +96,7 @@ On the target computer, perform the steps in the **Test the sample** section to ### Manual deployment -Before you manually deploy a driver, you must prepare the target computer by turning on test signing and by installing a certificate. You also need to locate the DevCon tool in your WDK installation. After that you’re ready to run the built driver sample. +Before you manually deploy a driver, you must prepare the target computer by turning on test signing and by installing a certificate. You also need to locate the DevCon tool in your WDK installation. After that you're ready to run the built driver sample. **1. Prepare the target computer** diff --git a/avstream/avshws/ReadMe.md b/avstream/avshws/ReadMe.md index 0f0a3ccb8..73d4a3891 100644 --- a/avstream/avshws/ReadMe.md +++ b/avstream/avshws/ReadMe.md @@ -8,16 +8,16 @@ This sample features enhanced parameter validation and overflow detection. Provision a target computer --------------------------- -After you've installed the sample on your host computer, run Visual Studio, and from the **File** menu, select **Open**, then **Project/Solution…**, navigate to the directory where you’ve copied the Avshws sample, then to the C++ folder, and select **avshws.vcxproj** (the VC++ Project). +After you've installed the sample on your host computer, run Visual Studio, and from the **File** menu, select **Open**, then **Project/Solution...**, navigate to the directory where you've copied the Avshws sample, then to the C++ folder, and select **avshws.vcxproj** (the VC++ Project). -In the **Solution Explorer** pane in Visual Studio, at the top is **Solution ‘avshws’**. Right-click this and select **Configuration Manager**. Follow the instructions in [Building a Driver with the WDK](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644) to set the platform, operating system, and debug configuration you want to use, and to build the sample. This sample project will automatically sign the driver package. +In the **Solution Explorer** pane in Visual Studio, at the top is **Solution 'avshws'**. Right-click this and select **Configuration Manager**. Follow the instructions in [Building a Driver with the WDK](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644) to set the platform, operating system, and debug configuration you want to use, and to build the sample. This sample project will automatically sign the driver package. Provision your target computer using instructions in, for example, [Preparing a Computer for Provisioning](http://msdn.microsoft.com/en-us/library/windows/hardware/dn265573). Ensure that in the **Network and Sharing Center** control panel your target computer has **Network Discovery** and **File and Printer Sharing** enabled. Deploy the driver to the target computer ---------------------------------------- -Now you can deploy the Avshws driver that you've just built to the target computer, using guidance in [Deploying a Driver to a Test Computer](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454834). Specifically, find the package file under the **Package** folder in the Avshws solution. Right-click **package** and select **Properties**. Under Configuration Properties, click **Driver install** and then **Deployment**. Here you must click the check box for **Enable deployment**, and then click the button to the right of **\**. In the next dialog you enter the **Target Computer Name** and can let the host computer automatically provision the target computer and set up debugger options. +Now you can deploy the Avshws driver that you've just built to the target computer, using guidance in [Deploying a Driver to a Test Computer](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454834). Specifically, find the package file under the **Package** folder in the Avshws solution. Right-click **package** and select **Properties**. Under Configuration Properties, click **Driver install** and then **Deployment**. Here you must click the check box for **Enable deployment**, and then click the button to the right of **\**. In the next dialog you enter the **Target Computer Name** and can let the host computer automatically provision the target computer and set up debugger options. Finally, in Visual Studio, from the **Build** menu select **Deploy Solution** to deploy the sample to the target computer. On the target computer, you can see the deployed package in the **%Systemdrive%\\drivertest\\drivers** folder. @@ -32,7 +32,7 @@ On the target computer, open Device Manager, and follow these steps: 4. You should see the **AVStream Simulated Hardware Sample** in the **Model** pane on the right. Click this and then click **Next**. 5. Click **Next** again to install the driver, and then click **Finish** to exit the wizard. -The sample driver now appears in the Device Manager console tree under **Sound, video and game controllers**. The Avshws INF file will be on the system drive at, for example, **…windows\\System32\\DriverStore\\FileRepository\\**. +The sample driver now appears in the Device Manager console tree under **Sound, video and game controllers**. The Avshws INF file will be on the system drive at, for example, **...windows\\System32\\DriverStore\\FileRepository\\**. Sample code hierarchy --------------------- @@ -56,7 +56,7 @@ Follow these steps to see how the sample driver functions: 1. After installation has completed, access the driver through the Graphedt tool. Graphedt.exe is available in the *tools* directory of the WDK. 2. Before running GraphEdit, use the regsvr32 utility to register the proppage.dll DLL and to enable GraphEdit to display property pages for some of the built-in Microsoft DirectShow filters. Open an elevated command window with Administrator privileges, and navigate to the WDK or SDK *tools* directory that contains proppage.dll. -3. On the command line, type regsvr32 proppage.dll. If the registration succeeds, you’ll get a message, “DllRegisterServer in proppage.dll succeeded.” Click OK. +3. On the command line, type regsvr32 proppage.dll. If the registration succeeds, you'll get a message, "DllRegisterServer in proppage.dll succeeded." Click OK. 4. In the Graphedt tool, click the **Graph** menu and click **Insert Filters**. The sample appears under "WDM Streaming Capture Devices" as "avshws Source." 5. Click **Insert Filter**. The sample appears in the graph as a single filter labeled, "avshws Source." There is one output pin, which is the video capture pin. This pin emits video in YUY2 format. 6. Attach this filter to either a DirectShow Video Renderer or to the VMR default video renderer. Then click **Play**. diff --git a/avstream/avssamp/ReadMe.md b/avstream/avssamp/ReadMe.md index 185178803..6188c5b32 100644 --- a/avstream/avssamp/ReadMe.md +++ b/avstream/avssamp/ReadMe.md @@ -27,30 +27,25 @@ Audio.cpp lays out a [**KSPIN\_DISPATCH**](http://msdn.microsoft.com/en-us/libra For more information, see the comments in all .cpp files. -Code tour ---------- - -**File manifest** - - ---- - - - - - - - - - - - -
File -Description
Audio.cpp -

Audio capture pin implementation

Audio.h -

Header file for Audio.cpp

- +File Manifest +------------- + +File | Description +-----|---------- +Audio.cpp | Audio capture pin implementation. +Audio.h | Header file for Audio.cpp. +Avssamp.cpp | Main file for the AVStream filter-centric sample. +Avssamp.h | Main header for the AVStream filter-centric sample. +Avssamp.inf | Installation information for the AVStream sample driver (avssamp.sys). +Capture.cpp | Capture pin implementation for all capture pins on the sample filter. +Capture .h | Capture pin level header for all capture pins on the sample filter. +Filter.cpp | Capture filter implementation (including frame synthesis) for the fake capture filter. +Filter.h | Filter level header for the filter-centric capture filter. +Image.cpp | Image synthesis and overlay code. These objects provide image synthesis (pixel, color-bar, etc) onto RGB24 and UYVY buffers as well as software string overlay into these buffers. +Image.h | Image synthesis and overlay header. +Purecall.h | _purecall stub necessary for virtual function usage in drivers. +Video.cpp | Video capture pin implementation. +Video.h | Video capture pin header. +Wave.cpp | Wave object implementation +Wave.h | Wave object header diff --git a/bluetooth/bthecho/ReadMe.md b/bluetooth/bthecho/ReadMe.md index fa41920e1..6c1a7a2f3 100644 --- a/bluetooth/bthecho/ReadMe.md +++ b/bluetooth/bthecho/ReadMe.md @@ -1,7 +1,7 @@ Bluetooth Echo L2CAP Profile Driver =================================== -This sample demonstrates developing [Bluetooth L2CAP profile drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff536598) using [Bluetooth L2CAP DDIs](http://msdn.microsoft.com/en-us/library/windows/hardware/ff536585).The sample includes two drivers. One for a device that acts as an L2CAP server and another for a device that acts as an L2CAP client. The server simply echoes back any data that it receives from client on the same L2CA channel. These drivers can be used with devices that can be installed with bth.inf. Such devices get installed as ‘Generic Bluetooth Radio’. Examples of such devices are Bluetooth USB dongles such as (but not limited to): +This sample demonstrates developing [Bluetooth L2CAP profile drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff536598) using [Bluetooth L2CAP DDIs](http://msdn.microsoft.com/en-us/library/windows/hardware/ff536585).The sample includes two drivers. One for a device that acts as an L2CAP server and another for a device that acts as an L2CAP client. The server simply echoes back any data that it receives from client on the same L2CA channel. These drivers can be used with devices that can be installed with bth.inf. Such devices get installed as 'Generic Bluetooth Radio'. Examples of such devices are Bluetooth USB dongles such as (but not limited to): ``` Generic Bluetooth Radio=\ @@ -63,7 +63,7 @@ Run the sample If errorlevel is 1, you need to reboot the machine for KMDF update to take effect. If errorlevel is 2, please make sure that you have the driver files described in \#1 available in the current directory. For more information on installation failure please check setup logs. -4. Upon successful installation you will see ‘Bluetooth Echo Sample Server’ in Device Manager under Bluetooth devices. +4. Upon successful installation you will see 'Bluetooth Echo Sample Server' in Device Manager under Bluetooth devices. **Device tree for Echo Server device** @@ -103,13 +103,13 @@ Run the sample 2. Copy KMDF coinstaller (wdfcoinstallerMMmmm.dll, from redist\\wdf\\), BthEchoSampleCli.Sys, BthEchoSampleCli.inf and bthecho.exe on a temporary directory on the target machine. -3. Run bthprops.cpl from a command line or right click on the Bluetooth icon in the system tray and select ‘Show Devices' to bring up a list of installed Bluetooth devices. +3. Run bthprops.cpl from a command line or right click on the Bluetooth icon in the system tray and select 'Show Devices' to bring up a list of installed Bluetooth devices. 4. In the **Bluetooth Devices** window, click the **Add a device** button. -5. In the Add a Device wizard select the server machine (the machine where you installed the echo server) as a Bluetooth device. If the server machine does not appear, please check the echo server installation and make sure that you have enabled ‘Allow Bluetooth device to find this computer’ on the server machine as explained above. When the server machine is correctly displayed, select it and pick ‘Next’. +5. In the Add a Device wizard select the server machine (the machine where you installed the echo server) as a Bluetooth device. If the server machine does not appear, please check the echo server installation and make sure that you have enabled 'Allow Bluetooth device to find this computer' on the server machine as explained above. When the server machine is correctly displayed, select it and pick 'Next'. -6. The wizard should default to a numeric compare ceremony for pairing the machines. When this happens, ensure the numbers match on both the client and the server, select ‘Yes’ on both machines to indicate they match, and click ‘Next’ on both machines to complete the pairing. +6. The wizard should default to a numeric compare ceremony for pairing the machines. When this happens, ensure the numbers match on both the client and the server, select 'Yes' on both machines to indicate they match, and click 'Next' on both machines to complete the pairing. 7. Go through Device Manager and update driver software for it. Either point the wizard to the temporary directory created in step \#2, or use devcon.exe from the tools\\devcon folder to install the client device: @@ -119,20 +119,20 @@ Run the sample Check for any error from devcon.exe as described in server installation. - If the installation is successful, you will see ‘Bluetooth Echo Sample Client’ in Device Manager under Bluetooth devices. + If the installation is successful, you will see 'Bluetooth Echo Sample Client' in Device Manager under Bluetooth devices. The device tree for echo client device is similar to the one shown for the echo server device, since both client and server are enumerated by BthEnum.sys (although the installation mechanism and properties of client and server are different). **Uninstalling Server** -1. Uninstall the device and delete driver software using the Bluetooth Devices window by running bthprops.cpl, right clicking on the device, and selecting ‘Remove Device’ +1. Uninstall the device and delete driver software using the Bluetooth Devices window by running bthprops.cpl, right clicking on the device, and selecting 'Remove Device' -2. Run bthsrvinst.exe /u to uninstall the echo server. This would make bthenum.sys stop enumerating the echo server. Without this step ‘Found New Hardware’ wizard will be launched again when you reconnect the device. +2. Run bthsrvinst.exe /u to uninstall the echo server. This would make bthenum.sys stop enumerating the echo server. Without this step 'Found New Hardware' wizard will be launched again when you reconnect the device. **Uninstalling Client** -- Uninstall the device and delete driver software using the Bluetooth Devices window by running bthprops.cpl, right clicking on the device, and selecting ‘Remove Device’ +- Uninstall the device and delete driver software using the Bluetooth Devices window by running bthprops.cpl, right clicking on the device, and selecting 'Remove Device'. **TESTING** @@ -202,12 +202,12 @@ One transition to note here is that if disconnect is received in the connecting **Client** -**Startup**: Client retrieves local and server Bluetooth address in BthEchoSrvEvtDeviceSelfManagedIoInit (this callback is invoked by WDF during device start). Please note that server Bluetooth address would be available regardless of presence of the server. Thus echo client device start doesn’t fail even if echo server is not available. +**Startup**: Client retrieves local and server Bluetooth address in BthEchoSrvEvtDeviceSelfManagedIoInit (this callback is invoked by WDF during device start). Please note that server Bluetooth address would be available regardless of presence of the server. Thus echo client device start doesn't fail even if echo server is not available. **Connecting to server**: Client connects to echo server when application opens a handle to it (BthEchoCliEvtDeviceFileCreate) and closes the connection on file close (BthEchoCliEvtFileClose). -**Sending and receiving data from server**: When application writes data to the client, client sends this data to server on the connection opened for the given handle. Server would echo back this data. This data is retrieved by the application using a read operation. Echo Sample Client doesn’t do any draining of echoed data on its own. Application read/write are handled using a parallel WDF I/O queue. +**Sending and receiving data from server**: When application writes data to the client, client sends this data to server on the connection opened for the given handle. Server would echo back this data. This data is retrieved by the application using a read operation. Echo Sample Client doesn't do any draining of echoed data on its own. Application read/write are handled using a parallel WDF I/O queue. -**Shutdown**: Client doesn’t need any specific shutdown code as connection open/close and read/write are done within the context of application’s handle open. +**Shutdown**: Client doesn't need any specific shutdown code as connection open/close and read/write are done within the context of application's handle open. diff --git a/bluetooth/serialhcibus/ReadMe.md b/bluetooth/serialhcibus/ReadMe.md index 46a30f38f..45f56512b 100644 --- a/bluetooth/serialhcibus/ReadMe.md +++ b/bluetooth/serialhcibus/ReadMe.md @@ -1,7 +1,7 @@ Bluetooth Serial HCI Bus Driver =============================== -The purpose of this sample is to demonstrate how to implement a basic bus driver to support the new [Bluetooth Extensibility transport DDIs](http://msdn.microsoft.com/en-us/library/windows/hardware/ff536585) over the UART transport. Such a serial bus driver can support a multi-radio device over the UART transport and utilize a common Bluetooth HCI packet for communication. The lower edge of this driver interfaces with a UART controller following the Bluetooth SIG’s UART (H4) transport protocol. +The purpose of this sample is to demonstrate how to implement a basic bus driver to support the new [Bluetooth Extensibility transport DDIs](http://msdn.microsoft.com/en-us/library/windows/hardware/ff536585) over the UART transport. Such a serial bus driver can support a multi-radio device over the UART transport and utilize a common Bluetooth HCI packet for communication. The lower edge of this driver interfaces with a UART controller following the Bluetooth SIG's UART (H4) transport protocol. ## Universal Windows Driver Compliant This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. @@ -16,44 +16,44 @@ It is recommended to use the WDK version that matches the target Windows build **WDK header file** -BthXDDI.h – this has the constants, struct, and IOCTL definitions for the Bluetooth extensibility transport. This header file is included in WDK. +BthXDDI.h - this has the constants, struct, and IOCTL definitions for the Bluetooth extensibility transport. This header file is included in WDK. **Common code section** -driver.c – driver initialization +driver.c - driver initialization -driver.h – common header file for driver.c and includes other header files +driver.h - common header file for driver.c and includes other header files -Fdo.c – functions for function device object (FDO) and BTHX DDI processing +Fdo.c - functions for function device object (FDO) and BTHX DDI processing -io.c – functions that perform IO read pump via UART controller +io.c - functions that perform IO read pump via UART controller -Io.h – header for io.c +Io.h - header for io.c pdo.c - PDO (Bluetooth function) enumeration and IOCTL processing -public.h – header to share with application to support Radio On/Off (“Airplane mode”) +public.h - header to share with application to support Radio On/Off ("Airplane mode") Note: The goal is to keep the common code section the same, so the vendor will only need to update those code sections in the device specific directory. **Device-specific code section** -Debugdef.h – WPP trace GUID; user should use a new GUID (unique per driver) +Debugdef.h - WPP trace GUID; user should use a new GUID (unique per driver) -device.c – device specific functions to implement: +device.c - device specific functions to implement: ---DeviceInitialize() – to perform UART and Bluetooth device initialization; +--DeviceInitialize() - to perform UART and Bluetooth device initialization; ---DeviceEnable() – (optional) to bring serial bus device out of disable/reset state. +--DeviceEnable() - (optional) to bring serial bus device out of disable/reset state. ---DevicePowerOn() – (optional) to power on the device. +--DevicePowerOn() - (optional) to power on the device. ---DeviceEnableWakeControl() – (optional) to arm for device wake signal +--DeviceEnableWakeControl() - (optional) to arm for device wake signal ---DeviceDisableWakeControl() – (optional) to disarm for device wake signal +--DeviceDisableWakeControl() - (optional) to disarm for device wake signal -device.h – header file for device.c +device.h - header file for device.c -driver.rc – driver version and name +driver.rc - driver version and name -SerialBusWdk.inx – device specific INF file to install this driver. The vendor will need to add the hardware ID to match the “\_HID” for the Serial Bus Device (Bluetooth) in the DSDT.asl file. For example, in SerialBusWDK.inx, the hardware ID is “ACPI\\\\_BTH0” where “\” could be a 4 digit vendor name +SerialBusWdk.inx - device specific INF file to install this driver. The vendor will need to add the hardware ID to match the "\_HID" for the Serial Bus Device (Bluetooth) in the DSDT.asl file. For example, in SerialBusWDK.inx, the hardware ID is "ACPI\\<*vendor*\>\_BTH0" where <*vendor*\> could be a 4 digit vendor name diff --git a/general/echo/umdf/ReadMe.md b/general/echo/umdf/ReadMe.md index 75ae46cd6..e2123cd33 100644 --- a/general/echo/umdf/ReadMe.md +++ b/general/echo/umdf/ReadMe.md @@ -16,7 +16,7 @@ Related technologies Testing ------- -To test the Echo driver, you can run echoapp.exe which is built from src\\general\\echo\\exe. +To test the Echo driver, you can run echoapp.exe which is built from \\echo\\exe. First install the device as described above. Then run echoapp.exe. diff --git a/general/echo/umdfSocketEcho/ReadMe.md b/general/echo/umdfSocketEcho/ReadMe.md index 8015044b5..06819a479 100644 --- a/general/echo/umdfSocketEcho/ReadMe.md +++ b/general/echo/umdfSocketEcho/ReadMe.md @@ -61,7 +61,7 @@ To test this sample drivers on a checked operating system that you have installe Testing ------- -To test the SocketEcho driver, you can run socketechoserver.exe, which is built from the src\\general\\echo\\umdfSocketEcho\\Exe directory, and echoapp.exe, which is built from the Kernel-Mode Driver Framework (KMDF) samples in the src\\general\\echo\\kmdf directory. +To test the SocketEcho driver, you can run socketechoserver.exe, which is built from the \\echo\\umdfSocketEcho\\Exe directory, and echoapp.exe, which is built from the Kernel-Mode Driver Framework (KMDF) samples in the \\echo\\kmdf directory. First, you must install the device as described earlier. Then, run socketechoserver.exe from a Command Prompt window. diff --git a/general/ioctl/kmdf/ReadMe.md b/general/ioctl/kmdf/ReadMe.md index 848acd06c..c9a103657 100644 --- a/general/ioctl/kmdf/ReadMe.md +++ b/general/ioctl/kmdf/ReadMe.md @@ -23,8 +23,6 @@ This sample would be useful for writing a driver that does not interact with any The sample is accompanied by a simple multithreaded Win32 console application to test the driver. -This sample is adapted from the original IOCTL sample present in WDK (src\\general\\ioctl). - *Disclaimer*: This is a minimal driver meant to demonstrate an OS feature. Neither it nor its sample programs are intended for use in a production environment. Rather, they are intended for educational purposes and as a skeleton driver. diff --git a/general/obcallback/ReadMe.md b/general/obcallback/ReadMe.md index d91a209d2..ca4069a23 100644 --- a/general/obcallback/ReadMe.md +++ b/general/obcallback/ReadMe.md @@ -14,18 +14,18 @@ The following is a command line usage scenario to exercise access restriction: ``` C:\> obcallbacktestctrl.exe -? (for command line help) C:\> obcallbacktestctrl.exe -install (installs the kernel driver) -C:\> obcallbacktestctrl.exe -name notepad (specifies that the string “notepad” will be watched as a protected executable) - (now you can start up “notepad.exe”) +C:\> obcallbacktestctrl.exe -name notepad (specifies that the string "notepad" will be watched as a protected executable) + (now you can start up "notepad.exe") C:\> notepad C:\> tlist (locate the process ID of notepad.exe) C:\> kill -f 2329 (attempt to kill off the notepad.exe with a PID of 2329) -process notepad.exe (2329) - 'Untitled – Notepad' could not be killed +process notepad.exe (2329) - 'Untitled - Notepad' could not be killed C:\> obcallbacktestctrl.exe -deprotect (remove the protections on the notepad process) -C:\> kill -f 2329 (attempt to kill off the process – which will succeed) +C:\> kill -f 2329 (attempt to kill off the process - which will succeed) C:\> obcallbacktestctrl.exe -uninstall (uninstall the kernel driver) ``` @@ -33,8 +33,8 @@ The following is another sample test you can run to prevent a process from being ``` C:\> obcallbacktestctrl.exe -install (installs the kernel driver) -C:\> obcallbacktestctrl.exe -reject notepad (specifies that the string “notepad” will be watched and prevented from starting as a process) +C:\> obcallbacktestctrl.exe -reject notepad (specifies that the string "notepad" will be watched and prevented from starting as a process) -C:\> notepad (now you can start up “notepad.exe”) +C:\> notepad (now you can start up "notepad.exe") Access is denied. ``` diff --git a/general/pcidrv/ReadMe.md b/general/pcidrv/ReadMe.md index fcd56df26..04bf35b57 100644 --- a/general/pcidrv/ReadMe.md +++ b/general/pcidrv/ReadMe.md @@ -37,15 +37,15 @@ The following is a list of key KMDF interfaces demonstrated in this sample: Note: This sample provides an example of a minimal driver intended for educational purposes. Neither the driver nor its sample test programs are intended for use in a production environment. -As stated earlier, this sample is meant to demonstrate how to write a KMDF driver for a generic PCI device and not for PCI network controllers. For network controllers, you should write a monolithic NDIS miniport driver based on the samples given under the src\\network\\ndis directory. +As stated earlier, this sample is meant to demonstrate how to write a KMDF driver for a generic PCI device and not for PCI network controllers. For network controllers, you should write a monolithic NDIS miniport driver based on the samples given under the \\network\\ndis directory. -Note that it is still possible to use a subset of KMDF APIs when writing a NDIS miniport (see src\\network\\ndis\\usbnwifi directory for a sample on how to use KMDF interfaces to talk to USB device in an NDIS miniport). +Note that it is still possible to use a subset of KMDF APIs when writing a NDIS miniport (see \\network\\ndis\\usbnwifi directory for a sample on how to use KMDF interfaces to talk to USB device in an NDIS miniport). The sample driver has been tested on the following Intel Ethernet controllers: Device Description | Hardware ID -------------------|------------ -IBM Netfinity 10/100 Ethernet Adapter | PCIVEN_8086&DEV_1229&SUBSYS_005C1014&REV_05 +IBM Netfinity 10/100 Ethernet Adapter | PCIVEN_8086&DEV_1229&SUBSYS_005C1014&REV_05 Intel(R) PRO/100+ Management Adapter with Alert On LAN | PCI\VEN_8086&DEV_1229&SUBSYS_000E8086&REV_08 Intel 8255x-based PCI Ethernet Adapter (10/100) | PCI\VEN_8086&DEV_1229&SUBSYS_00000000&REV_01 Intel Pro/100 S Server Adapter | PCI\VEN_8086&DEV_1229&SUBSYS_00508086&REV_0D @@ -91,7 +91,7 @@ The PCIDRV sample acts as a power policy owner of the device and implements all INSTALLATION ------------ -The driver can be installed as a Net class driver or as a standalone driver (user defined class). The KMDF versions of the INF files are dynamically generated from .INX file. In addition to the driver files, you have to include the WDF coinstaller DLL from the src\\redist\\wdf folder of the WDK. +The driver can be installed as a Net class driver or as a standalone driver (user defined class). The KMDF versions of the INF files are dynamically generated from .INX file. In addition to the driver files, you have to include the WDF coinstaller DLL from the \\redist\\wdf folder of the WDK. 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. diff --git a/hid/firefly/ReadMe.md b/hid/firefly/ReadMe.md index a1e97063e..306d816fa 100644 --- a/hid/firefly/ReadMe.md +++ b/hid/firefly/ReadMe.md @@ -77,7 +77,7 @@ The Firefly sample is installed as an upper filter driver for the Microsoft USB The sample consists of: - Driver (firefly.sys): The Firefly driver is an upper device filter driver for the mouse driver (mouhid.sys). Firefly is a generic filter driver based on the toaster filter driver sample available in the WDK. During start device, the driver registers a WMI class (FireflyDeviceInformation). The user mode application connects to the WMI namespace (root\\wmi) and opens this class using COM interfaces. Then the application can make requests to read ("get") or change ("set") the current value of the TailLit data value from this class. In response to a set WMI request, the driver opens the HID collection using IoTarget and sends [**IOCTL\_HID\_GET\_COLLECTION\_INFORMATION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff541092) and [**IOCTL\_HID\_GET\_COLLECTION\_DESCRIPTOR**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff541089) requests to get the preparsed data. The driver then calls [**HidP\_GetCaps**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff539715) using the preparsed data to retrieve the capabilities of the device. After getting the capabilities of the device, the driver creates a feature report to set or clear the feature that causes the light to toggle. -- Library (luminous.lib): The sources for this file are located in the WINDDK\\src\\hid\\firefly\\lib folder. You will need to build the library before using it. This library is shared by the WDM and WDF samples. All the interfaces required to access the WMI is defined in this library and exposed as CLuminous class. -- Application (flicker.exe): The sources for this file are located in the WINDDK\\src\\hid\\firefly\\app folder. You will need to build the application before using it. This application is shared by the WDM and WDF samples. The application links to luminous.lib to open the WMI interfaces and send set requests to toggle the light. -- Sauron (sauron.dll): The sources for this file are located in the WINDDK\\src\\hid\\firefly\\sauron folder. You will need to build this dll before using it. The library is shared by the WDM and WDF samples. Sauron is a Windows Media Player visualization DLL, and is based on a sample from the Windows Media Player SDK kit. By using this DLL, you can cause the mouse lights to blink to the beats of the music. +- Library (luminous.lib): The sources for this file are located in the \\hid\\firefly\\lib folder. You will need to build the library before using it. This library is shared by the WDM and WDF samples. All the interfaces required to access the WMI is defined in this library and exposed as CLuminous class. +- Application (flicker.exe): The sources for this file are located in the \\hid\\firefly\\app folder. You will need to build the application before using it. This application is shared by the WDM and WDF samples. The application links to luminous.lib to open the WMI interfaces and send set requests to toggle the light. +- Sauron (sauron.dll): The sources for this file are located in the \\hid\\firefly\\sauron folder. You will need to build this dll before using it. The library is shared by the WDM and WDF samples. Sauron is a Windows Media Player visualization DLL, and is based on a sample from the Windows Media Player SDK kit. By using this DLL, you can cause the mouse lights to blink to the beats of the music. diff --git a/hid/hidusbfx2/ReadMe.md b/hid/hidusbfx2/ReadMe.md index f3c8f58f0..bd0b88a91 100644 --- a/hid/hidusbfx2/ReadMe.md +++ b/hid/hidusbfx2/ReadMe.md @@ -8,13 +8,13 @@ Related topics -------------- [Human Input Devices Design Guide](http://msdn.microsoft.com/en-us/library/windows/hardware/ff539952) - [Human Input Devices Reference](http://msdn.microsoft.com/en-us/library/windows/hardware/ff539956) Related technologies -------------------- -[Creating Framework-based HID Minidrivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540774) , [Creating UMDF-based HID Minidrivers](http://msdn.microsoft.com/en-us/library/windows/hardware/hh439579) +[Creating Framework-based HID Minidrivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540774) +[Creating UMDF-based HID Minidrivers](http://msdn.microsoft.com/en-us/library/windows/hardware/hh439579) Build the sample ---------------- @@ -42,7 +42,7 @@ Kernel-Mode Driver Framework (KMDF) does not support HID minidrivers natively be You can resolve this ownership conflict by using a driver stack that consists of a minimal WDM driver as a function driver and a complete KMDF driver as a lower filter driver. The function driver registers with the HID class (so**hidclass.sys** owns its dispatch table) and forwards all of the requests to the lower filter driver. The lower filter driver (KMDF owns the dispatch table) processes all of the requests. -The minimal function driver code is located in the src\\hid\\hidusbfx2\\hidkmdf directory (the driver binary is named **hidkmdf.sys**), and the lower filter driver code is located in the src\\hid\\hidusbfx2\\sys folder (the binary is named **hidusbfx2.sys**). The function driver is a minimal WDM driver and you can reuse it without any modification. Remember to rename the driver binary when you reuse it, to avoid a name conflict. You need to modify the KMDF filter driver according to your device's requirements. +The minimal function driver code is located in the \\hidusbfx2\\hidkmdf directory (the driver binary is named **hidkmdf.sys**), and the lower filter driver code is located in the \\hidusbfx2\\sys folder (the binary is named **hidusbfx2.sys**). The function driver is a minimal WDM driver and you can reuse it without any modification. Remember to rename the driver binary when you reuse it, to avoid a name conflict. You need to modify the KMDF filter driver according to your device's requirements. **Mapping a Non-HID USB Device to HID** @@ -60,41 +60,9 @@ The HID class driver creates a driver stack for each top-level collection. The o The switch pack on the USB device is mapped as hot keys that are commonly found on modern keyboards. This mapping is possible by exposing the switch pack as two system-supported collections: consumer control and system control. The consumer control collection provides a mapping for some application-launch and application-action keys, as shown in the following table. The system control collection provides a mapping for the power sleep function. -Switch - -1 - -2 - -3 - -4 - -5 - -6 - -7 - -8 - -Mapping - -Sleep - -Calculator - -Mail - -Favorites - -Refresh - -Forward - -Back - -Browser +Switch | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 +-------|---|---|---|---|---|---|---|--- +Mapping | Sleep | Calculator | Mail | Favorites | Refresh | Forward | Back | Browser **Segment Display and Bar Graph** @@ -102,97 +70,17 @@ The segment display and bar graph are mapped as HID feature controls that you ca **Segment Display Mapping** -Usage ID - -0xD7 - -0x06 - -0xB3 - -0xA7 - -0x66 - -0xE5 - -0xF4 - -0x07 - -0xF7 - -0x67 - -Mapping - -Display 0 - -Display 1 - -Display 2 - -Display 3 - -Display 4 - -Display 5 - -Display 6 - -Display 7 - -Display 8 - -Display 9 +Usage ID | 0xD7 | 0x06 | 0xB3 | 0xA7 | 0x66 | 0xE5 | 0xF4 | 0x07 | 0xF7 | 0x67 +---------|------|------|------|------|------|------|------|------|------|------ +Mapping | Display 0 | Display 1 | Display 2 | Display 3 | Display 4 | Display 5 | Display 6 | Display 7 | Display 8 | Display 9 **Bar Graph Mapping** Note that you can OR these values to light multiple LEDs. -Usage ID - -0x01 - -0x02 - -0x04 - -0x08 - -0x10 - -0x20 - -0x40 - -0x80 - -0xFF - -0x00 - -Mapping - -LED 1 ON - -LED 2ON - -LED 3ON - -LED 4ON - -LED 5ON - -LED 6ON - -LED 7ON - -LED 8ON - -All LEDS ON - -All LEDS OFF +Usage ID | 0x01 | 0x02 | 0x04 | 0x08 | 0x10 | 0x20 | 0x40 | 0x80 | 0xFF | 0x00 +---------|------|------|------|------|------|------|------|------|------|------ +Mapping | LED 1 ON | LED 2 ON | LED 3 ON | LED 4 ON | LED 5 ON | LED 6 ON | LED 7 ON | LED 8 ON | All LEDS ON | All LEDS OFF **Support for Selective Suspend** @@ -232,7 +120,7 @@ Testing **Testing Bar Graph and 7-Segment Display** -1. Start the **hidclient.exe** GUI application from the WDK. The application source code is located in the *src\\hid\\hclient* directory, and you build it by using the appropriate build environment. +1. Start the **hidclient.exe** GUI application from the WDK. The application source code is located in the \\hid\\hclient directory, and you build it by using the appropriate build environment. 2. From the **HID Device to examine** menu, select the device that contains "UsagePage 0ff00, Usage 01" as a substring. @@ -248,13 +136,8 @@ Testing **Report Descriptor** - --- - - - - - -
  // Consumer control collection
+```
+   // Consumer control collection
  
    0x05,0x0C,  // USAGE_PAGE (Consumer Page)
  
@@ -343,61 +226,36 @@ Testing
    0xB1,0x00,  //  Feature (Data,Ary,Abs)
  
    0xC0  // END_COLLECTION
+``` Code Tour --------- -This section includes a file manifest of all the files in the src\\hid\\hidusbfx2 directory. - -**File Manifest** - -src\\hid\\hidusbfx2\\hidkmdf - - ---- - - - - - - - - - - - -
File -Description

hidkmdf.c

-

Contains code for driver entry and dispatch

Sources

-

WDK sources file

- -src\\hid\\hidusbfx2\\sys - - ---- - - - - - - - - - - - -
File -Description

Driver.c

-

Contains code for driver entry and dispatch functions

hid.c

-

Contains code for handling HID IOCTLS

+This section includes a file manifest of the files in the \\hidusbfx2 directory. +### File Manifest +**\\hidusbfx2\\hidkmdf** + +File | Description +-----|------------ +hidkmdf.c | Contains code for driver entry and dispatch +Sources | WDK sources file +Makefile | WDK build environment makefile +hidkmdf.rc | Resource file for the driver + +**\\hidusbfx2\\sys** + +File | Description +-----|------------ +Driver.c | Contains code for driver entry and dispatch functions +hid.c | Contains code for handling HID IOCTLS +usb.c | Contains code for communicating with USB stack +Trace.h | Contains trace-related definitions +Hidusbfx2.h | Contains type definitions and function declarations +Hidusbfx2.rc | Resource file for the driver +Hidusbfx2.inx | INX file for the driver +Sources | WDK sources file +Makefile | WDK build environment make file +Makefile.inc | A makefile that defines custom build actions, including the conversion of the .INX file into a .INF file + diff --git a/input/kbfiltr/ReadMe.md b/input/kbfiltr/ReadMe.md index ac5088f5a..9942ec402 100644 --- a/input/kbfiltr/ReadMe.md +++ b/input/kbfiltr/ReadMe.md @@ -43,26 +43,12 @@ In File Explorer, navigate to the folder that contains your built driver package The package contains these files: - ---- - - - - - - - - - - - -
File -Description
Kmdfsamples.cat -A signed catalog file, which serves as the signature for the entire package.kbfiltr.inf -An information (INF) file that contains information needed to install the driver.
+File | Description +-----|------------ +Kmdfsamples.cat | A signed catalog file, which serves as the signature for the entire package. +kbfiltr.inf | An information (INF) file that contains information needed to install the driver. +WdfCoinstaller010xx.dll | The coinstaller for version 1.xx of KMDF. +kbfiltr.sys | The driver file. Using MSBuild ------------- diff --git a/network/ndis/filter/ReadMe.md b/network/ndis/filter/ReadMe.md index 6967f1b69..ac1bc67c8 100644 --- a/network/ndis/filter/ReadMe.md +++ b/network/ndis/filter/ReadMe.md @@ -82,14 +82,14 @@ Viewing trace messages On the host computer, in the kernel-mode debugger, verify that you see trace messages similar to these: ``` -NDISLWF: ===>DriverEntry... -NDISLWF: ===>FilterRegisterOptions -NDISLWF: <===FilterRegisterOptions -NDISLWF: ==>FilterRegisterDevice -NDISLWF: <==FilterRegisterDevice: 0 -NDISLWF: <===DriverEntry, Status = 0 -NDISLWF: ===>FilterAttach: NdisFilterHandle FFFFE00000F73650 -NDISLWF: <===FilterAttach: Status 0 +NDISLWF: ===>DriverEntry... +NDISLWF: ===>FilterRegisterOptions +NDISLWF: <===FilterRegisterOptions +NDISLWF: ==>FilterRegisterDevice +NDISLWF: <==FilterRegisterDevice: 0 +NDISLWF: <===DriverEntry, Status = 0 +NDISLWF: ===>FilterAttach: NdisFilterHandle FFFFE00000F73650 +NDISLWF: <===FilterAttach: Status 0 ``` What the Ndislwf sample driver does: ------------------------------------ @@ -101,6 +101,6 @@ What the Ndislwf sample driver does: 5. All requests and sends coming from overlying drivers for the Ndislwf filter driver are repackaged if necessary and sent down to NDIS, to be passed to the underlying NDIS driver. 6. All indications arriving from an underlying NDIS driver are forwarded up by Ndislwf filter driver. 7. NDIS calls the filter's [*FilterPause*](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549957) handler when NDIS needs to detach the filter from the stack or there is some configuration changes in the stack. In processing the pause request from NDIS, the Ndislwf driver waits for all its own outstanding requests to be completed before it completes the pause request. -8. NDIS calls the Ndislwf driver’s [*FilterDetach*](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549918) entry point when NDIS needs to detach a filter module from NDIS stack. The *FilterDetach* handler should free all the memory allocation done in [*FilterAttach*](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549905), and undo the operations it did in *FilterAttach* Handler. +8. NDIS calls the Ndislwf driver's [*FilterDetach*](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549918) entry point when NDIS needs to detach a filter module from NDIS stack. The *FilterDetach* handler should free all the memory allocation done in [*FilterAttach*](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549905), and undo the operations it did in *FilterAttach* Handler. diff --git a/network/ndis/mux/ReadMe.md b/network/ndis/mux/ReadMe.md index eb0cbedf2..0a545a3a3 100644 --- a/network/ndis/mux/ReadMe.md +++ b/network/ndis/mux/ReadMe.md @@ -1,7 +1,7 @@ NDIS MUX Intermediate Driver and Notify Object ============================================== -The MUX Intermediate Miniport (IM) driver is an NDIS 6.0 driver that demonstrates the operation of an “N:1” MUX driver.The sample demonstrates creating multiple virtual network devices on top of a single lower adapter. Protocols bind to these virtual adapters as if they are real adapters. Examples of Intermediate Miniport drivers that can use this framework are Virtual LAN (VLAN) drivers. Included in the project is a sample Notify Object that demonstrates how to write a notify object for installing and configuring an NDIS MUX intermediate miniport (IM) driver that implements an N:1 relationship between upper and lower bindings, i.e. it creates multiple virtual network devices on top of a single lower adapter. Protocols bind to these virtual adapters as if they are real adapters. Examples of Intermediate Miniport drivers that can use this type of notify object are Virtual LAN (VLAN) drivers. +The MUX Intermediate Miniport (IM) driver is an NDIS 6.0 driver that demonstrates the operation of an "N:1" MUX driver.The sample demonstrates creating multiple virtual network devices on top of a single lower adapter. Protocols bind to these virtual adapters as if they are real adapters. Examples of Intermediate Miniport drivers that can use this framework are Virtual LAN (VLAN) drivers. Included in the project is a sample Notify Object that demonstrates how to write a notify object for installing and configuring an NDIS MUX intermediate miniport (IM) driver that implements an N:1 relationship between upper and lower bindings, for example, it creates multiple virtual network devices on top of a single lower adapter. Protocols bind to these virtual adapters as if they are real adapters. Examples of Intermediate Miniport drivers that can use this type of notify object are Virtual LAN (VLAN) drivers. For more information, see [NDIS Intermediate Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff565773) in the network devices design guide. @@ -24,13 +24,13 @@ Two .INF files are needed rather than one because MUX is installed both as a pro NDIS MUX Intermediate Driver ---------------------------- -The driver binds to Ethernet (NdisMedium802\_3) adapters as a protocol, and exposes one or more virtual Ethernet devices over each lower adapter, based on its configuration. The term “VELAN” is used to denote a Virtual Ethernet LAN adapter implemented by this driver. +The driver binds to Ethernet (NdisMedium802\_3) adapters as a protocol, and exposes one or more virtual Ethernet devices over each lower adapter, based on its configuration. The term "VELAN" is used to denote a Virtual Ethernet LAN adapter implemented by this driver. -When it binds to a lower adapter, MUX reads the standard “UpperBind” key to obtain a list of VELANs configured over this adapter. For each such VELAN, it calls NdisIMInitializeDeviceInstanceEx() to instantiate the NDIS miniport for the VELAN. NDIS then calls the driver’s MiniportInitialize (MPInitialize) routine to start the VELAN miniport. +When it binds to a lower adapter, MUX reads the standard "UpperBind" key to obtain a list of VELANs configured over this adapter. For each such VELAN, it calls NdisIMInitializeDeviceInstanceEx() to instantiate the NDIS miniport for the VELAN. NDIS then calls the driver's MiniportInitialize (MPInitialize) routine to start the VELAN miniport. -The MUX driver supports configuring the MAC address for each VELAN miniport using the standard “NetworkAddress” key that it reads from its MiniportInitialize routine. If this is not configured, it computes a “locally significant” MAC address for the VELAN using the MAC address of the lower adapter. The MUX driver sets its lower adapter to promiscuous mode in order to be able to receive frames directed to any of the VELAN MAC addresses. However it does implement packet-filtering (and multicast address filtering) logic for all its VELAN miniports so that it only passes up relevant frames on each VELAN. This aspect of the driver may be modified if, for example, your driver design uses the same MAC address as that of the lower adapter on all VELANs. With such a modification, it is not required to set the lower adapter to promiscuous mode and incur the costs of receiving all packets on the network. +The MUX driver supports configuring the MAC address for each VELAN miniport using the standard "NetworkAddress" key that it reads from its MiniportInitialize routine. If this is not configured, it computes a "locally significant" MAC address for the VELAN using the MAC address of the lower adapter. The MUX driver sets its lower adapter to promiscuous mode in order to be able to receive frames directed to any of the VELAN MAC addresses. However it does implement packet-filtering (and multicast address filtering) logic for all its VELAN miniports so that it only passes up relevant frames on each VELAN. This aspect of the driver may be modified if, for example, your driver design uses the same MAC address as that of the lower adapter on all VELANs. With such a modification, it is not required to set the lower adapter to promiscuous mode and incur the costs of receiving all packets on the network. -It supports dynamic addition and deletion of VELANs in conjunction with its notify object (related sample). If a VELAN is deleted, the virtual device corresponding to the VELAN is stopped and removed, which in turn results in NDIS halting the miniport instance for the VELAN (see MPHalt). If a VELAN is added, NDIS sends a global reconfiguration event to the protocol edge of this driver. The handler function for this event, PtPNPHandler, goes through all lower adapters to see if any new VELANs have been added, i.e. if any of the “UpperBind” keys have been modified. +It supports dynamic addition and deletion of VELANs in conjunction with its notify object (related sample). If a VELAN is deleted, the virtual device corresponding to the VELAN is stopped and removed, which in turn results in NDIS halting the miniport instance for the VELAN (see MPHalt). If a VELAN is added, NDIS sends a global reconfiguration event to the protocol edge of this driver. The handler function for this event, PtPNPHandler, goes through all lower adapters to see if any new VELANs have been added, i.e. if any of the "UpperBind" keys have been modified. Since the driver implements a virtual device, it does not simply pass through most NDIS queries/sets. It keeps its own device view that is reflected in its responses to queries/sets. However it does pass through queries/sets for certain OIDs that are best handled by the lower adapter driver. @@ -52,29 +52,29 @@ 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 (for example, 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). +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. +`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. `MPHalt` may also be called if the VELAN device is disabled, e.g. from the Network Connections Folder. There is no special code within `MPHalt` to handle this condition. However, `PtUnbindAdapter` takes care to not attempt to deinitialize a VELAN miniport (via `NdisIMDeInitializeDeviceInstance`) that has already been halted. ### Handling Queries -`MPRequest` is the MUX driver’s function that handles queries for OID values on VELAN miniports. Most of the “Ethernet” type information for the virtual miniport is stored in the VELAN structure itself, and the driver returns information from this structure. The queries that are forwarded are **OID\_GEN\_MEDIA\_CONNECT\_STATUS**, **OID\_PNP\_CAPABILITIES** and **OID\_PNP\_WAKE\_UP\_PATTERN\_LIST**. See “Handling Power Management” below for more information about the latter two OIDs. +`MPRequest` is the MUX driver's function that handles queries for OID values on VELAN miniports. Most of the "Ethernet" type information for the virtual miniport is stored in the VELAN structure itself, and the driver returns information from this structure. The queries that are forwarded are **OID\_GEN\_MEDIA\_CONNECT\_STATUS**, **OID\_PNP\_CAPABILITIES** and **OID\_PNP\_WAKE\_UP\_PATTERN\_LIST**. See "Handling Power Management" below for more information about the latter two OIDs. ### Handling Sets -`MPRequest` handles setting OID values on VELAN miniports. Data management OIDs handled by the MUX driver are **OID\_802\_3\_MULTICAST\_LIST** and **OID\_GEN\_CURRENT\_PACKET\_FILTER**. The multicast list is handled entirely within the MUX driver – it just stores the set of multicast addresses in the VELAN structure, for reference during receive-side data processing. The packet filter is handled in a different way – the MUX driver combines the packet filter settings (bitwise OR) of all VELANs associated with the same lower adapter. If the combined packet filter is non-zero, MUX sends a Set request with a value of **NDIS\_PACKET\_TYPE\_PROMISCUOUS** for **OID\_GEN\_CURRENT\_PACKET\_FILTER** to start receives on the lower adapter. If the combined packet filter is zero, MUX sets the lower adapter’s packet filter to 0 (turns off all receives if there aren’t any interested protocols). +`MPRequest` handles setting OID values on VELAN miniports. Data management OIDs handled by the MUX driver are **OID\_802\_3\_MULTICAST\_LIST** and **OID\_GEN\_CURRENT\_PACKET\_FILTER**. The multicast list is handled entirely within the MUX driver, it just stores the set of multicast addresses in the VELAN structure, for reference during receive-side data processing. The packet filter is handled in a different way. The MUX driver combines the packet filter settings (bitwise OR) of all VELANs associated with the same lower adapter. If the combined packet filter is non-zero, MUX sends a Set request with a value of **NDIS\_PACKET\_TYPE\_PROMISCUOUS** for **OID\_GEN\_CURRENT\_PACKET\_FILTER** to start receives on the lower adapter. If the combined packet filter is zero, MUX sets the lower adapter's packet filter to 0 (turns off all receives if there aren't any interested protocols). Note that setting the lower adapter to promiscuous mode is only done here in order to be able to receive unicast frames directed to multiple MAC addresses. If, for example, all VELANs are assigned the same MAC address (which is identical to the address of the lower adapter), then the MUX driver should only pass down the combined (bitwise OR) setting of packet filter settings of all VELANs. -Some power management OIDs are forwarded to the lower miniport. See “Handling Power Management” below for details. +Some power management OIDs are forwarded to the lower miniport. See "Handling Power Management" below for details. ### Sending Data @@ -84,9 +84,9 @@ If a non-zero VLAN ID is configured for the VELAN, and/or the packet has non-zer ### Receiving Data -Data received from a lower adapter is indicated up on zero or more VELANs. The `PtReceiveNBL` function is called for each `NetBufferList` received from the lower adapter. The received data is checked for matches with the packet filter and multicast list for each VELAN associated with the adapter (see `PtMatchPacketToVElan`). Whenever a match is found, a new `NET_BUFFER_LIST` is allocated and set to point to the received data. A pointer to the original received `NET_BUFFER_LIST` (if any) is also stored in the new `NET_BUFFER_LIST`’s reserved area. This packet is indicated up via `NdisMIndicateReceiveNetBufferLists` to all interested protocols on that VELAN. +Data received from a lower adapter is indicated up on zero or more VELANs. The `PtReceiveNBL` function is called for each `NetBufferList` received from the lower adapter. The received data is checked for matches with the packet filter and multicast list for each VELAN associated with the adapter (see `PtMatchPacketToVElan`). Whenever a match is found, a new `NET_BUFFER_LIST` is allocated and set to point to the received data. A pointer to the original received `NET_BUFFER_LIST` (if any) is also stored in the new `NET_BUFFER_LIST`'s reserved area. This packet is indicated up via `NdisMIndicateReceiveNetBufferLists` to all interested protocols on that VELAN. -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'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. @@ -108,13 +108,13 @@ See `PtPostProcessPnPCapabilities` for details. **OID\_PNP\_SET\_POWER** and **OID\_PNP\_QUERY\_POWER** are not passed to the lower adapter, since the lower layer miniport will receive independent requests from NDIS. -NDIS calls the MUX driver’s `ProtocolPnPEvent` function (`PtPNPHandler`) whenever the underlying adapter is transitioned to a different power state. If the underlying adapter is transitioning to a low power state, the driver waits for all outstanding sends and requests to complete. +NDIS calls the MUX driver's `ProtocolPnPEvent` function (`PtPNPHandler`) whenever the underlying adapter is transitioned to a different power state. If the underlying adapter is transitioning to a low power state, the driver waits for all outstanding sends and requests to complete. Queries/sets received on a VELAN miniport that are to be forwarded to the underlying adapter are queued on the VELAN if the underlying adapter is at a low power state. These are picked up for processing on receiving a notification that the underlying adapter is back to a powered-up state. ### Handling Global Reconfiguration -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. +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 @@ -139,7 +139,7 @@ This flag is defined to allow the MUX driver to be used in a passthru mode. When You can also use this notify object with the Passthru driver by doing the following: -1. Change the protocol name in file src\\network\\ndis\\passthru\\passthru.c from **PASSTHRU** to **MUXP.** +1. Change the protocol name in file \\ndis\\passthru\\passthru.c from **PASSTHRU** to **MUXP.** 2. Change the driver name from Passthru to MUX in the sources file. 3. Rebuild the driver to obtain a mux.sys driver binary. 4. Build the MUX notify object with **PASSTHRU\_NOTIFY** defined. diff --git a/network/ndis/ndisprot_kmdf/ReadMe.md b/network/ndis/ndisprot_kmdf/ReadMe.md index 7a9ee69ce..0da2ae315 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. +The 60 subdirectory (\\ndisprot\_kmdf\\60) indicates that the built sample will be NDIS 6.0 compatible. Installation ------------ @@ -45,60 +45,40 @@ From an administrator command prompt, to start the driver, type **Net start ndis To stop the driver, type **Net stop ndisprot**. -You can build Prottest.exe from source code located in the src\\network\\ndis\\ndisprot\\6x\\test directory. +You can build Prottest.exe from source code located in the \\ndisprot\\6x\\test directory. To test the NDIS 6.0 driver, run prottest. For help on usage, run **prottest -?**. - --- - - - - - -
usage: PROTTEST [options] <devicename>
+```
+usage: PROTTEST [options] 
 options:
  -e: Enumerate devices
  -r: Read
  -w: Write (default)
- -l <length>: length of each packet (default: 100)
- -n <count>: number of packets (defaults to infinity)
- -m <MAC address> (defaults to local MAC)
- -f Use a fake address to send out the packets.
+ -l : length of each packet (default: 100) + -n : number of packets (defaults to infinity) + -m (defaults to local MAC) + -f Use a fake address to send out the packets. +``` + 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 buffer that is large enough to contain the data returned. 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. For an NDIS 6.0 driver, use the -e option on prottest to enumerate all devices to which NDISPROT is bound: - --- - - - - - -
C:\prot>prottest -e
+```
+C:\prot>prottest -e
  0. \DEVICE\{9273DA7D-5275-4B9A-AC56-68A49D121F1F}
- - Intel-Based 10/100 Ethernet Card
+ - Intel-Based 10/100 Ethernet Card +``` The following command sends and receives 2 packets on a device. Since these packets are sent to the local MAC address (default), both packets are received. The device name parameter to prottest is picked up from the output of **prottest -e** (see above). - --- - - - - - -
C:\prot>prottest -n 2 \DEVICE\{9273DA7D-5275-4B9A-AC56-68A49D121F1F}
+```
+C:\prot>prottest -n 2 \DEVICE\{9273DA7D-5275-4B9A-AC56-68A49D121F1F}
 DoWriteProc: finished sending 2 packets of 100 bytes each
-DoReadProc finished: read 2 packets
+DoReadProc finished: read 2 packets +``` For security reasons, this driver does not allow packets with fake MAC addresses to be sent from user-mode applications. @@ -109,48 +89,27 @@ File Manifest **Directory: 60** - ---- - - - - - - - - - - - -
File -Description

debug.c

-

Routines to aid debugging

debug.h

-

Debug macro definitions

+File | Description +-----|------------ +debug.c | Routines to aid debugging +debug.h | Debug macro definitions +excallbk.c | Handles load order dependency between this sample and NDISWDM sample +macros.h | Spinlock, event, referencing macros +ndisbind.c | NDIS protocol entry points to handle binding/unbinding from adapters +ndisprot.h | Data structure definitions +precomp.h | Contains the precompiled headers +protuser.h | Has the definitions of ioctls issued by protuser.exe application used on NDIS 6.0 +nuiouser.h | Has the definitions of ioctls issued by nuiouser.exe application used on NDIS 5.0 +ndisprot.inf | INF file for installing NDISPROT +ntdisp.c | NT Entry points and dispatch routines for NDISPROT +recv.c | NDIS protocol entry points for receiving data, and IRP_MJ_READ processing **Directory: NotifyOb** - ---- - - - - - - - - - - - -
File -Description

Common.hpp

-

Header file containing the common include files for the project

dllmain.cpp

-

Handles loading/unloading of Wdf Coinstaller and the notify object dll

- +File | Description +-----|------------ +Common.hpp | Header file containing the common include files for the project +dllmain.cpp | Handles loading/unloading of Wdf Coinstaller and the notify object dll +ProtNotify.idl | Defines the interfaces for the notify object dll +ProtNotify.rc | Resource file for the notify object dll diff --git a/network/trans/ReadMe.md b/network/trans/ReadMe.md index 5f7ea8a86..d23c25543 100644 --- a/network/trans/ReadMe.md +++ b/network/trans/ReadMe.md @@ -38,7 +38,7 @@ Navigate to the folder that contains the sample. Double click the solution file, Set the configuration and platform in Visual Studio --------------------------------------------------- -In Visual Studio, in Solution Explorer, right click **Solution ‘WFPSampler’ (5 projects)**, and choose **Configuration Manager**. Set the configuration and the platform. Make sure that the configuration and platform are the same for all projects. Do not check the **Deploy** boxes. +In Visual Studio, in Solution Explorer, right click **Solution 'WFPSampler' (5 projects)**, and choose **Configuration Manager**. Set the configuration and the platform. Make sure that the configuration and platform are the same for all projects. Do not check the **Deploy** boxes. Set the runtime library for the user-mode application, library, and service --------------------------------------------------------------------------- @@ -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. diff --git a/network/wsk/echosrv/ReadMe.md b/network/wsk/echosrv/ReadMe.md index 826e09f41..8b93db2de 100644 --- a/network/wsk/echosrv/ReadMe.md +++ b/network/wsk/echosrv/ReadMe.md @@ -11,7 +11,7 @@ This sample is not intended for use in a production environment. WPP SOFTWARE TRACING -------------------- -This sample driver uses WPP Software Tracing in order to log its actions. You can find detailed information on WPP Software Tracing in the WDK documentation. Here is a quick overview of one way to collect trace logs from the sample driver by using the tracing tools that are available in the \\tools\\tracing directory in the WDK. All code for this sample is located in the src\\network\\WSK\\echosrv directory. +This sample driver uses WPP Software Tracing in order to log its actions. You can find detailed information on WPP Software Tracing in the WDK documentation. Here is a quick overview of one way to collect trace logs from the sample driver by using the tracing tools that are available in the \\tools\\tracing directory in the WDK. All code for this sample is located in \\network\\WSK\\echosrv directory. 1. In a Command Prompt window, copy Echosrv.ctl and Echosrv.pdb into a directory and change to that directory (cd). 2. Start software tracing for the sample driver by typing the following command: diff --git a/print/XpsRasFilter/ReadMe.md b/print/XpsRasFilter/ReadMe.md index 3a88ca71b..a742f66c1 100644 --- a/print/XpsRasFilter/ReadMe.md +++ b/print/XpsRasFilter/ReadMe.md @@ -22,5 +22,5 @@ The default parameters in this sample are as follows: - Letter-sized physical page (can override in print ticket). - 0.25-inch margins (creating an 8-inch by 10.5-inch imageable area). - Scaling is set to FitApplicationBleedSizeToImageableSize. -- •Destination resolution set to 96 dpi (can override in print ticket). +- Destination resolution set to 96 dpi (can override in print ticket). diff --git a/print/autoconfig/ReadMe.md b/print/autoconfig/ReadMe.md index 72f100426..e46420080 100644 --- a/print/autoconfig/ReadMe.md +++ b/print/autoconfig/ReadMe.md @@ -5,7 +5,7 @@ This sample demonstrates how to implement auto-configuration in v4 print drivers **Auto-configuration basics** -Many printers ship with optional components which are not present in all versions of the printer. For these printers, it’s important that the driver only shows options which are enabled by the currently installed hardware. For example, if a stapling unit is optional for a particular printer, then the driver shouldn’t expose the stapling feature to the end user if that unit is not installed. +Many printers ship with optional components which are not present in all versions of the printer. For these printers, it's important that the driver only shows options which are enabled by the currently installed hardware. For example, if a stapling unit is optional for a particular printer, then the driver shouldn't expose the stapling feature to the end user if that unit is not installed. Windows auto-configuration allows a print driver to specify a mapping between driver installable options and the state of the printer as expressed through the Bidi Schema. @@ -17,7 +17,7 @@ For more information on the Bidi Schema, see [Bidirectional Communication Schema Build the sample ---------------- -The auto-configuration sample doesn’t have any binaries to be built. It may be installed by using **Add Printer Wizard** and supplying the AutoCnfg.INF as the INF file. +The auto-configuration sample doesn't have any binaries to be built. It may be installed by using **Add Printer Wizard** and supplying the AutoCnfg.INF as the INF file. But to build a signed driver package using Windows Driver Kit (WDK) 10 and Visual Studio 2015, for the project file (csproj) that ships with the auto-configuration sample, perform the following steps. diff --git a/print/v4PrintDriverSamples/v4PrintDriver-USBMon-Bidi-Extension/ReadMe.md b/print/v4PrintDriverSamples/v4PrintDriver-USBMon-Bidi-Extension/ReadMe.md index 2f7ec05dc..294dee1e7 100644 --- a/print/v4PrintDriverSamples/v4PrintDriver-USBMon-Bidi-Extension/ReadMe.md +++ b/print/v4PrintDriverSamples/v4PrintDriver-USBMon-Bidi-Extension/ReadMe.md @@ -24,7 +24,7 @@ readBytes = readBuffer.length; var cleanArray = []; -for ( i = 0; i < readBytes; i++ ) { +for ( i = 0; i < readBytes; i++ ) { cleanArray[i] = readBuffer.shift(); } ``` diff --git a/security/elam/ReadMe.md b/security/elam/ReadMe.md index 101a52020..927dc32d2 100644 --- a/security/elam/ReadMe.md +++ b/security/elam/ReadMe.md @@ -7,7 +7,7 @@ This sample driver is a minimal driver meant to demonstrate the usage of the API **SIGNING THE SAMPLE** -Early Launch drivers are required to be signed with a code-signing certificate that also contains the Early Launch EKU "1.3.6.1.4.1.311.61.4.1". In a production environment, Early Launch drivers are signed by Microsoft for qualifying Anti-Malware vendors with a WHQL certificate that contains this EKU. The makecert.exe tool can be used to generate a self-signed test certificate that contains both the Early Launch EKU and the “1.3.6.1.5.5.7.3.3” Code Signing EKU. Once a certificate of this form has been created, signtool.exe can be used to sign elamsample.sys. +Early Launch drivers are required to be signed with a code-signing certificate that also contains the Early Launch EKU "1.3.6.1.4.1.311.61.4.1". In a production environment, Early Launch drivers are signed by Microsoft for qualifying Anti-Malware vendors with a WHQL certificate that contains this EKU. The makecert.exe tool can be used to generate a self-signed test certificate that contains both the Early Launch EKU and the "1.3.6.1.5.5.7.3.3" Code Signing EKU. Once a certificate of this form has been created, signtool.exe can be used to sign elamsample.sys. Run the sample diff --git a/serial/serenum/ReadMe.md b/serial/serenum/ReadMe.md index 6875e8b74..7b28ae46c 100644 --- a/serial/serenum/ReadMe.md +++ b/serial/serenum/ReadMe.md @@ -18,7 +18,7 @@ Windows provides Serenum to support Serial and other serial port function driver File | Description -----|------------ -Enum.c | Functions that enumerate external serial devices—the main purpose of this driver +Enum.c | Functions that enumerate external serial devices (the main purpose of this driver) Pnp.c | Plug and Play support code Power.c | Power support code Serenum.c | Basic driver functionality diff --git a/setup/devcon/ReadMe.md b/setup/devcon/ReadMe.md index a018d3bdb..b559f0f1a 100644 --- a/setup/devcon/ReadMe.md +++ b/setup/devcon/ReadMe.md @@ -65,7 +65,7 @@ cmdRescan This command shows the correct way to rescan for all Plug & Play devices that may have previously been removed, or that otherwise require a rescan to detect them. cmdDPAdd -This command allows you to add a Driver Package to the machine. The main functionality of this command demonstrates the use of [**SetupCopyOEMInf**](http://msdn.microsoft.com/en-us/library/windows/hardware/). Adding a Driver Package to the machine doesn’t mean the drivers are installed on devices, it simply means the drivers are available automatically when a new device is plugged in or a existing device is updated. +This command allows you to add a Driver Package to the machine. The main functionality of this command demonstrates the use of [**SetupCopyOEMInf**](http://msdn.microsoft.com/en-us/library/windows/hardware/). Adding a Driver Package to the machine doesn't mean the drivers are installed on devices, it simply means the drivers are available automatically when a new device is plugged in or a existing device is updated. cmdDPDelete This command allows you to uninstall a Driver Package from the machine. The main functionality of this command demonstrates the use of [**SetupUninstallOEMInf**](http://msdn.microsoft.com/en-us/library/windows/hardware/). Removing a Driver Package from the machine does not uninstall the drivers associated with a device. If you want to accomplish both then use *cmdRemove* on all the devices using a given Driver Package and then *cmdDPDelete* to remove the Driver Package itself from the machine. diff --git a/spb/SpbTestTool/ReadMe.md b/spb/SpbTestTool/ReadMe.md index ec6a1c2a6..d7c9eb2eb 100644 --- a/spb/SpbTestTool/ReadMe.md +++ b/spb/SpbTestTool/ReadMe.md @@ -58,7 +58,7 @@ The following are the relevant functions in the SpbTestTool peripheral driver fo Function | Description ---------|------------ -OnPrepareHardware | Traverses the driver’s start resources and caches the connection ID of the I2C or SPI resource. This ID will be used to open the SPB controller later on. +OnPrepareHardware | Traverses the driver's start resources and caches the connection ID of the I2C or SPI resource. This ID will be used to open the SPB controller later on. SpbPeripheralOpen | Opens a handle to the underlying SPB controller via the resource hub. This allows the peripheral driver to be developed without any underlying knowledge of the platform or hardware connections. Instead, the dependency between controller and peripheral is described in ACPI. SpbPeripheralClose | Sends IOCTL_SPB_LOCK_CONTROLLER to the SPB controller to lock the bus for exclusive access by this peripheral. SpbPeripheralLock | Sends IOCTL_SPB_LOCK_CONTROLLER to the SPB controller to lock the bus for exclusive access by this peripheral. @@ -74,7 +74,7 @@ The following are the relevant functions in the SpbTestTool peripheral driver fo Function | Description ---------|------------ -OnPrepareHardware | Traverses the driver’s start resources. If "ConnectInterrupt" is set to 1 in the registry, the driver connects the first interrupt resource found and registers an interrupt service routine. +OnPrepareHardware | Traverses the driver's start resources. If "ConnectInterrupt" is set to 1 in the registry, the driver connects the first interrupt resource found and registers an interrupt service routine. OnInterruptIsr | The interrupt service routine, which has been configured to run at passive-level. Doing so enables the driver to acknowledge or quiesce the interrupt using the SPB interface, which cannot be called at DIRQL. Typically a driver will clear the hardware interrupt and save any volatile information in its ISR, and then it will queue a workitem to continue processing. Our sample driver instead notifies the SpbTestTool app that an interrupt has occurred and calls KeWaitForSingleObject to wait until the interrupt is handled before returning. A "real" driver should never stall in the ISR like this. SpbPeripheralWaitOnInterrupt | Called to pend a WaitOnInterrupt request in the driver, which will be completed when the next interrupt occurs. SpbPeripheralInterruptNotify | Completes an outstanding WaitOnInterrupt request to inform the SpbTestTool app that an interrupt has occurred. @@ -82,11 +82,11 @@ SpbPeripheralSignalInterrupt | Notifies the interrupt service routine that the i ### File manifest -The following source files are in the src\\SPB\\SpbTestTool\\sys folder and are used to build the SpbTestTool.sys and SpbTestTool.inf files. +The following source files are in the \\SpbTestTool\\sys folder and are used to build the SpbTestTool.sys and SpbTestTool.inf files. File | Description -----|------------ -driver.h, driver.cpp | Events on the Device Object, and read, write, and IOCTLs from the SpbTestTool application. Implements the driver’s interrupt service routine. +driver.h, driver.cpp | Events on the Device Object, and read, write, and IOCTLs from the SpbTestTool application. Implements the driver's interrupt service routine. internal.h | Common includes and typedefs makefile | Redirects to the real makefile that is shared by all components of the WDK. peripheral.h, peripheral.cpp | Reflection of the SpbTestTool IOCTLs to the SPB API, including opening the controller via the resource hub and using lock, unlock, read, write, and sequence. @@ -98,7 +98,7 @@ spbtesttool.h | Private SpbTestTool IOCTLs for use between the application and p spbtesttool.inx | Describes the installation of the driver. The build process converts this into an INF. trace.h | Sets up WPP tracing. -The following source files are in the src\\SPB\\SpbTestTool\\exe folder and are used to build the SpbTestTool.exe file. +The following source files are in the \\SpbTestTool\\exe folder and are used to build the SpbTestTool.exe file. File | Description -----|------------ diff --git a/tools/sdv/samples/SDV-FailDriver-KMDF/ReadMe.md b/tools/sdv/samples/SDV-FailDriver-KMDF/ReadMe.md index 003e71a09..ce2b381c3 100644 --- a/tools/sdv/samples/SDV-FailDriver-KMDF/ReadMe.md +++ b/tools/sdv/samples/SDV-FailDriver-KMDF/ReadMe.md @@ -10,7 +10,7 @@ Run the sample 1. In the **Solutions Explorer** window, select the driver project (fail\_driver1). - From the **Driver** menu, click **Launch Static Driver Verifier…**. + From the **Driver** menu, click **Launch Static Driver Verifier...**. This opens the Static Driver Verifier application, where you can control, configure, and schedule when Static Driver Verifier performs an analysis. diff --git a/tools/sdv/samples/SDV-FailDriver-NDIS/ReadMe.md b/tools/sdv/samples/SDV-FailDriver-NDIS/ReadMe.md index 67d821a1f..5903ad294 100644 --- a/tools/sdv/samples/SDV-FailDriver-NDIS/ReadMe.md +++ b/tools/sdv/samples/SDV-FailDriver-NDIS/ReadMe.md @@ -10,7 +10,7 @@ Run the sample 1. In the **Solutions Explorer** window, select the driver project (sdvmp.vcxProj). - From the **Driver** menu, click **Launch Static Driver Verifier…**. + From the **Driver** menu, click **Launch Static Driver Verifier...**. This opens the Static Driver Verifier application, where you can control, configure, and schedule when Static Driver Verifier performs an analysis. diff --git a/tools/sdv/samples/SDV-FailDriver-STORPORT/ReadMe.md b/tools/sdv/samples/SDV-FailDriver-STORPORT/ReadMe.md index d0c361330..8611e51db 100644 --- a/tools/sdv/samples/SDV-FailDriver-STORPORT/ReadMe.md +++ b/tools/sdv/samples/SDV-FailDriver-STORPORT/ReadMe.md @@ -10,7 +10,7 @@ Run the sample 1. In the **Solutions Explorer** window, select the driver project (lsi\_u3.vcxProj). - From the **Driver** menu, click **Launch Static Driver Verifier…**. + From the **Driver** menu, click **Launch Static Driver Verifier...**. This opens the Static Driver Verifier application, where you can control, configure, and schedule when Static Driver Verifier performs an analysis. diff --git a/tools/sdv/samples/SDV-FailDriver-WDM/ReadMe.md b/tools/sdv/samples/SDV-FailDriver-WDM/ReadMe.md index 43630cadf..49a697531 100644 --- a/tools/sdv/samples/SDV-FailDriver-WDM/ReadMe.md +++ b/tools/sdv/samples/SDV-FailDriver-WDM/ReadMe.md @@ -10,7 +10,7 @@ Run the sample 1. In the **Solutions Explorer** window, select the driver project (fail\_driver1). - From the **Driver** menu, click **Launch Static Driver Verifier…**. + From the **Driver** menu, click **Launch Static Driver Verifier...**. This opens the Static Driver Verifier application, where you can control, configure, and schedule when Static Driver Verifier performs an analysis. diff --git a/usb/kmdf_fx2/ReadMe.md b/usb/kmdf_fx2/ReadMe.md index 81edf40ae..934a39e9e 100644 --- a/usb/kmdf_fx2/ReadMe.md +++ b/usb/kmdf_fx2/ReadMe.md @@ -58,7 +58,7 @@ Here is the overview of the device: - Three events are targeted to the event log: - Failure during the add device routine. - Failure to start the OSR device on a USB 1.1 controller. - - Invocation of the “re-enumerate device” IOCTL. + - Invocation of the "re-enumerate device" IOCTL. - Read/write start/stop events can be used to measure the time taken. - For more information, see Unified Tracing later in this document. diff --git a/usb/umdf_filter_kmdf/ReadMe.md b/usb/umdf_filter_kmdf/ReadMe.md index 17f9e6967..ecc62acd2 100644 --- a/usb/umdf_filter_kmdf/ReadMe.md +++ b/usb/umdf_filter_kmdf/ReadMe.md @@ -41,7 +41,7 @@ Here is the overview of the device: - Three events are targeted to the event log: - Failure during the add device routine. - Failure to start the OSR device on a USB 1.1 controller. - - Invocation of the “re-enumerate device” IOCTL. + - Invocation of the "re-enumerate device" IOCTL. - Read/write start/stop events can be used to measure the time taken. Testing the driver diff --git a/usb/usbsamp/ReadMe.md b/usb/usbsamp/ReadMe.md index c7a203205..8d9d4d9d4 100644 --- a/usb/usbsamp/ReadMe.md +++ b/usb/usbsamp/ReadMe.md @@ -24,7 +24,7 @@ If you have a different USB device, you can still use the driver by adding the d Set the configuration and platform in Visual Studio --------------------------------------------------- -In Visual Studio, in Solution Explorer, right click **Solution ‘usbsamp’ (3 projects)**, and choose **Configuration Manager**. Set the configuration and the platform. Make sure that the configuration and platform are the same for both the driver project and the package project. Do not check the **Deploy** boxes. +In Visual Studio, in Solution Explorer, right click **Solution 'usbsamp' (3 projects)**, and choose **Configuration Manager**. Set the configuration and the platform. Make sure that the configuration and platform are the same for both the driver project and the package project. Do not check the **Deploy** boxes. Build the sample using Visual Studio ------------------------------------ diff --git a/video/KMDOD/ReadMe.md b/video/KMDOD/ReadMe.md index 2e03e2920..5e0052563 100644 --- a/video/KMDOD/ReadMe.md +++ b/video/KMDOD/ReadMe.md @@ -21,13 +21,13 @@ In Microsoft Visual Studio, press **F5** to build the sample and then deploy it In some cases you might need to install the driver manually, as follows. -1. Add the following files to the directory given by …\\[x64]\\C++\\Package: +1. Add the following files to the directory given by ...\\[x64]\\C++\\Package: - SampleDriver.cat - SampleDriver.inf - SampleDriver.sys - SampleDriver.cer -2. Unless you’ve provided a production certificate, you should manually install the SampleDriver.cer digital certificate with the following command: +2. Unless you've provided a production certificate, you should manually install the SampleDriver.cer digital certificate with the following command: `Certutil.exe -addstore root SampleDriver.cer` @@ -45,23 +45,12 @@ In some cases you might need to install the driver manually, as follows. To install the KMDOD sample driver on a GPU that is an Advanced Configuration and Power Interface (ACPI) device, add these lines to the `[MS]`, `[MS.NTamd64]`, and `[MS.NTarm]` sections of the Sampledisplay.inf file: - --- - - - - - - - - - - -
Text
" Kernel mode display only sample driver " = KDODSamp_Inst, ACPI\CLS_0003&SUBCLS_0000
-" Kernel mode display only sample driver " = KDODSamp_Inst, ACPI\CLS_0003&SUBCLS_0001
-" Kernel mode display only sample driver " = KDODSamp_Inst, ACPI\CLS_0003&SUBCLS_0003
+``` +Text +" Kernel mode display only sample driver " = KDODSamp_Inst, ACPI\CLS_0003&SUBCLS_0000 +" Kernel mode display only sample driver " = KDODSamp_Inst, ACPI\CLS_0003&SUBCLS_0001 +" Kernel mode display only sample driver " = KDODSamp_Inst, ACPI\CLS_0003&SUBCLS_0003 +``` This new code provides generic identifiers for ACPI hardware. diff --git a/wpd/WpdBasicHardwareDriver/ReadMe.md b/wpd/WpdBasicHardwareDriver/ReadMe.md index 238860a9f..523d60220 100644 --- a/wpd/WpdBasicHardwareDriver/ReadMe.md +++ b/wpd/WpdBasicHardwareDriver/ReadMe.md @@ -3,7 +3,7 @@ WPD Basic Hardware Sample Driver (UMDF Version 1) The WpdBasicHardwareDriver is a WPD driver that supports nine devices. These devices were selected because of their simplicity. This simplicity allowed the sample to focus on the tasks that are common to portable devices without getting bogged down in hardware complexities. -This sample driver is based on the WpdHelloWorldDriver that is also included in the Windows Driver Kit (WDK). The "Supporting the WPD Infrastructure” sections for this driver show the changes that were made to the WpdHelloWorldDriver source so that it can communicate with basic hardware devices. Before you work through the topics in this section of the documentation, be familiar with the WpdHelloWorldDriver. +This sample driver is based on the WpdHelloWorldDriver that is also included in the Windows Driver Kit (WDK). The "Supporting the WPD Infrastructure" sections for this driver show the changes that were made to the WpdHelloWorldDriver source so that it can communicate with basic hardware devices. Before you work through the topics in this section of the documentation, be familiar with the WpdHelloWorldDriver. The sensor devices that are supported by the WpdBasicHardwareDriver, such as the Memsic 2125 Accelerometer, are sold by the Parallax Corporation in Rocklin, California. @@ -11,7 +11,7 @@ To use these sensors with the WpdBasicHardwareDriver, you must purchase the sens The circuit designs are based on the sample circuits provided by Parallax in their sensor data sheets. These circuits are designed to integrate each sensor with the Parallax BS2 programmable microcontroller . -The microcontroller firmware for each of the nine circuits is included in the src\\wpd\\WpdBasicHardwareDriver\\firmware subdirectory in the Windows Driver Kit (WDK). +The microcontroller firmware for each of the nine circuits is included in the **\\firmware** subdirectory of this sample. For a complete description of this sample and its underlying code and functionality, refer to the [WPD Basic Hardware Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff597697) description in the Windows Driver Kit documentation. @@ -37,7 +37,7 @@ To install the WpdBasicHardwareDriver sample, do the following: 2. Copy the UMDF coinstaller, WUDFUpdate\_*MMmmmm*.dll, from the \\redist\\wdf\\\ directory to the same directory (for example, C:\\wpdbasichardwaredriver). - **Note** You can obtain the co-installers by downloading and installing the “Windows Driver Framework (WDF)” package from [WDK 8 Redistributable Components](http://go.microsoft.com/fwlink/p/?LinkID=226396). + **Note** You can obtain the co-installers by downloading and installing the "Windows Driver Framework (WDF)" package from [WDK 8 Redistributable Components](http://go.microsoft.com/fwlink/p/?LinkID=226396). 3. Navigate to the directory that contains the INF file and binaries (for example, cd /d c:\\wpdbasichardwaredriver), and run DevCon.exe as follows: **devcon.exe install wpdbasichardwaredriver.inf WUDF\\WpdBasicHardware**