diff options
Diffstat (limited to 'general')
| -rw-r--r-- | general/DCHU/README.md | 35 | ||||
| -rw-r--r-- | general/cancel/README.md | 20 | ||||
| -rw-r--r-- | general/echo/kmdf/README.md | 48 | ||||
| -rw-r--r-- | general/echo/umdf/README.md | 53 | ||||
| -rw-r--r-- | general/echo/umdf2/README.md | 46 | ||||
| -rw-r--r-- | general/echo/umdfSocketEcho/README.md | 84 |
6 files changed, 88 insertions, 198 deletions
diff --git a/general/DCHU/README.md b/general/DCHU/README.md index 05f61035..a4d1dd25 100644 --- a/general/DCHU/README.md +++ b/general/DCHU/README.md @@ -8,32 +8,22 @@ products: - windows-wdk --- - - -<!--- - name: DHCU - Driver package installation toolkit for universal drivers - platform: UMDF2 - language: cpp - category: General DHCU - description: Illustrates DCHU principles of universal driver design. - samplefwlink: https://aka.ms/sceeqq ----> - # Driver package installation toolkit for universal drivers This sample illustrates the DCHU principles of universal driver design. The sample uses the [OSR FX2 learning kit](http://store.osr.com/product/osr-usb-fx2-learning-kit-v2/). For a detailed code walkthrough, see [Universal Driver Scenarios](https://docs.microsoft.com/windows-hardware/drivers/develop/universal-driver-scenarios). There are three Visual Studio solutions in this sample. Each one represents a single submission on the [Windows Hardware Dev Center dashboard](https://developer.microsoft.com/windows/hardware/dashboard-sign-in). The solutions are split into the following subdirectories: -* `osrfx2_DCHU_base` : The driver for the OSR FX2 Learning Kit. This includes the device driver, an upper filter driver for the device (a no-op), a Win32 User Service that controls lights on the device, and a console app that can control the device. +- `osrfx2_DCHU_base` : The driver for the OSR FX2 Learning Kit. This includes the device driver, an upper filter driver for the device (a no-op), a Win32 User Service that controls lights on the device, and a console app that can control the device. -* `osrfx2_DCHU_extension_loose`: An extension INF for the OSR FX2 device. This extension modifies some registry settings originally specified by the base driver (`osrfx2_DCHU_base`) and also uses AddComponent to create a Software Component. There is also a component INF project that would be a separate submission to DevCenter, which runs some simple software. These two projects are loosely coupled, and can be installed in any order on the machine. +- `osrfx2_DCHU_extension_loose`: An extension INF for the OSR FX2 device. This extension modifies some registry settings originally specified by the base driver (`osrfx2_DCHU_base`) and also uses AddComponent to create a Software Component. There is also a component INF project that would be a separate submission to DevCenter, which runs some simple software. These two projects are loosely coupled, and can be installed in any order on the machine. -* `osrfx2_DCHU_extension_tight`: An extension INF for the OSR FX2 device. This extension mimics the behavior of `osrfx2_DCHU_extension_loose`; however, it does so in a tightly coupled manner. Using CopyINF, both the extension and component INF are placed into one driver package (and one submission to DevCenter). Here there is less flexibility with the base/component/extension relationship, but it ensures that the component INF is applied at the same time as the extension. +- `osrfx2_DCHU_extension_tight`: An extension INF for the OSR FX2 device. This extension mimics the behavior of `osrfx2_DCHU_extension_loose`; however, it does so in a tightly coupled manner. Using CopyINF, both the extension and component INF are placed into one driver package (and one submission to DevCenter). Here there is less flexibility with the base/component/extension relationship, but it ensures that the component INF is applied at the same time as the extension. -Both `osrfx2_DCHU_extension_loose` and `osrfx2_DCHU_extension_tight` provide the same functionality, so installing both on the same OSR FX2 device is unnecessary. They are intended to show a different way to use extension and component INF's depending on a project's needs. +Both `osrfx2_DCHU_extension_loose` and `osrfx2_DCHU_extension_tight` provide the same functionality, so installing both on the same OSR FX2 device is unnecessary. They are intended to show a different way to use extension and component INFs depending on a project's needs. -NOTE: osrfx2_DCHU_extension_tight will not currently build on Windows 10 version 1703. You will see an error saying that the directive CopyINF does not work from extension INFs. This has been fixed for the Windows 10 Fall Creators Update. +> [!NOTE] +> Information the user should notice even if skimmingosrfx2_DCHU_extension_tight will not currently build on Windows 10 version 1703. You will see an error saying that the directive CopyINF does not work from extension INFs. This has been fixed for the Windows 10 Fall Creators Update. Each of these solutions can be built with the latest WDK on Visual Studio 2015. Additionally, you can also download a [Universal Windows Platform app (UWP)](https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/CustomCapability) that controls the OSR FX2 Learning Kit's device. To learn how to pair a UWP app with a device, see [Hardware access for Universal Windows Platform apps](https://docs.microsoft.com/windows-hardware/drivers/devapps/hardware-access-for-universal-windows-platform-apps) @@ -41,11 +31,12 @@ The app and the contents of this sample can coexist, but on Windows 10 version 1 To install these driver packages, make sure that the target machine is in Test Mode, using `bcdedit /set testsigning on`. -Then, use `pnputil /i /a <PATHTOINF>` to install each of the desired driver packages. They should -be installed in the following order: +Then, use `pnputil /i /a <PATHTOINF>` to install each of the desired driver packages. They should be installed in the following order: + +- `osrfx2_DCHU_base` + +- `osrfx2_DCHU_extension` -* `osrfx2_DCHU_base` -* `osrfx2_DCHU_extension` -* `osrfx2_DCHU_component` +- `osrfx2_DCHU_component` -Technically the order of `osrfx2_DCHU_extension` and `osrfx2_DCHU_component` doesn't matter, but the software within `osrfx2_DCHU_component` will read the registry set by the extension to show that an extension INF's settings are applied *after* the base INF's. +Technically the order of `osrfx2_DCHU_extension` and `osrfx2_DCHU_component` doesn't matter, but the software within `osrfx2_DCHU_component` will read the registry set by the extension to show that an extension's INF settings are applied *after* the base INFs. diff --git a/general/cancel/README.md b/general/cancel/README.md index 71f090c6..a45e145e 100644 --- a/general/cancel/README.md +++ b/general/cancel/README.md @@ -8,20 +8,9 @@ products: - windows-wdk --- - - -<!--- - name: Cancel-Safe IRP Queue Sample - platform: WDM - language: cpp - category: General - description: Demonstrates the use of the cancel-safe queue routines. - samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617705 ----> - # Cancel-Safe IRP Queue Sample -This sample demonstrates the use of the cancel-safe queue routines [**IoCsqInitialize**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549054), [**IoCsqInsertIrp**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549066), [**IoCsqRemoveIrp**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549070), [**IoCsqRemoveNextIrp**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549072). These routines were introduced in Windows for queuing IRPs in the driver's internal device queue. By using these routines, driver developers do not have to worry about IRP cancellation race conditions. A common problem with cancellation of IRPs in a driver is synchronization between the cancel lock or the InterlockedExchange in the I/O Manager with the driver's queue lock. The **IoCsq*Xxx*** routines abstract the cancel logic while allowing the driver to implement the queue and associated synchronization. +This sample demonstrates the use of the cancel-safe queue routines [**IoCsqInitialize**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/wdm/nf-wdm-iocsqinitialize), [**IoCsqInsertIrp**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/wdm/nf-wdm-iocsqinsertirp), [**IoCsqRemoveIrp**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/wdm/nf-wdm-iocsqremoveirp), [**IoCsqRemoveNextIrp**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/wdm/nf-wdm-iocsqremovenextirp). These routines were introduced in Windows for queuing IRPs in the driver's internal device queue. By using these routines, driver developers do not have to worry about IRP cancellation race conditions. A common problem with cancellation of IRPs in a driver is synchronization between the cancel lock or the InterlockedExchange in the I/O Manager with the driver's queue lock. The **IoCsq*Xxx*** routines abstract the cancel logic while allowing the driver to implement the queue and associated synchronization. The sample is accompanied by a simple multithreaded Win32 console application to stress-test the driver's cancel and cleanup routines. @@ -29,9 +18,9 @@ This driver is written for an hypothetical data-acquisition device that requires This sample driver is not a Plug and Play driver. This is a minimal driver meant to demonstrate a feature of the operating system. Neither this driver nor its sample programs are intended for use in a production environment. Instead, they are intended for educational purposes and as a skeleton driver. -Look in the Startio directory for another version of the sample driver that shows how to use cancel-safe IRP queues to implement I/O queuing functionality similar to the [**IoStartPacket**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550370) and [**IoStartNextPacket**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550358) routines. The same test application works with this driver as well. +Look in the Startio directory for another version of the sample driver that shows how to use cancel-safe IRP queues to implement I/O queuing functionality similar to the [**IoStartPacket**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/ntifs/nf-ntifs-iostartpacket) and [**IoStartNextPacket**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/ntifs/nf-ntifs-iostartnextpacket) routines. The same test application works with this driver as well. -For more information, see [Cancel-Safe IRP Queues](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540755). +For more information, see [Cancel-Safe IRP Queues](https://docs.microsoft.com/windows-hardware/drivers/kernel/cancel-safe-irp-queues). ## Run the sample @@ -39,4 +28,5 @@ To test this driver, run Testapp.exe, which is a simple Win32 multithreaded cons `Usage: testapp <NumberOfThreads>` -**Note** The `NumberOfThreads` command-line parameter is limited to a maximum of 10 threads; the default value if no parameter is specified is 1. The main thread waits for user input. If you press Q, the application exits gracefully; otherwise, it exits the process abruptly and forces all the threads to be terminated and all pending I/O operations to be canceled. Other threads perform I/O asynchronously in a loop. After every overlapped read, the thread goes into an alertable sleep and wakes as soon as the completion routine runs, which occurs when the driver completes the read IRP. You should run multiple instances of the application to stress test the driver. +> [!NOTE] +> The `NumberOfThreads` command-line parameter is limited to a maximum of 10 threads; the default value if no parameter is specified is 1. The main thread waits for user input. If you press Q, the application exits gracefully; otherwise, it exits the process abruptly and forces all the threads to be terminated and all pending I/O operations to be canceled. Other threads perform I/O asynchronously in a loop. After every overlapped read, the thread goes into an alertable sleep and wakes as soon as the completion routine runs, which occurs when the driver completes the read IRP. You should run multiple instances of the application to stress test the driver. diff --git a/general/echo/kmdf/README.md b/general/echo/kmdf/README.md index 2358f650..2118e3e5 100644 --- a/general/echo/kmdf/README.md +++ b/general/echo/kmdf/README.md @@ -8,17 +8,6 @@ products: - windows-wdk --- - - -<!--- - name: KMDF Echo Sample - platform: KMDF - language: cpp - category: General WDF - description: Demonstrates how to use a sequential queue to serialize read and write requests presented to the driver. - samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617706 ----> - # KMDF Echo Sample The ECHO (KMDF) sample demonstrates how to use a sequential queue to serialize read and write requests presented to the driver. @@ -31,7 +20,7 @@ This sample builds a Universal Windows Driver. It uses only APIs and DDIs that a ## Related technologies -[Kernel-Mode Driver Framework](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544396) +[Kernel-Mode Driver Framework](https://docs.microsoft.com/windows-hardware/drivers/kernel/) ## Code Tour @@ -53,48 +42,29 @@ Since the queue is a sequential queue, only one request is outstanding in the dr **Usage:** -Echoapp.exe --- Send single write and read request synchronously +- Echoapp.exe --- Send single write and read request synchronously -Echoapp.exe -Async --- Send 100 reads and writes asynchronously +- Echoapp.exe -Async --- Send 100 reads and writes asynchronously Exit the app anytime by pressing Ctrl-C ## File Manifest -File - -Description - -Echo.htm - -Documentation for this sample (this file). - -***(The AutoSync and DriverSync versions of the sample each have their own version of the following files)*** +> [!NOTE] +> The AutoSync and DriverSync versions of the sample each have their own version of the following files: Driver.h, Driver.c -DriverEntry and Events on the Driver Object. +- DriverEntry and Events on the Driver Object. Device.h, Device.c -Events on the Device Object. +- Events on the Device Object. Queue.h, Queue.c -Contains Events on the I/O Queue Objects. +- Contains Events on the I/O Queue Objects. Echo.inx -File that describes the installation of this driver. The build process converts this into an INF file. - -Makefile.inc - -A makefile that defines custom build actions. This includes the conversion of the .INX file into a .INF file - -Makefile - -This file merely redirects to the real makefile that is shared by all the driver components of the Windows NT DDK. - -Sources - -Generic file that lists source files and all the build options. +- File that describes the installation of this driver. The build process converts this into an INF file. diff --git a/general/echo/umdf/README.md b/general/echo/umdf/README.md index 745482aa..241e633d 100644 --- a/general/echo/umdf/README.md +++ b/general/echo/umdf/README.md @@ -8,17 +8,6 @@ products: - windows-wdk --- - - -<!--- - name: Echo Sample (UMDF Version 1) - platform: UMDF1 - language: cpp - category: General WDF - description: Demonstrates how to use UMDF version 1 to write a driver and demonstrates best practices. - samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617707 ----> - # Echo Sample (UMDF Version 1) This sample demonstrates how to use User-Mode Driver Framework (UMDF) version 1 to write a driver and demonstrates best practices. @@ -27,13 +16,11 @@ It also demonstrates the use of a default Serial Dispatch I/O Queue, its request This sample driver is a minimal driver meant to demonstrate the usage of the User-Mode Driver Framework. It is not intended for use in a production environment. -Related technologies --------------------- +## Related technologies -[User-Mode Driver Framework](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560456) +[User-Mode Driver Framework](https://docs.microsoft.com/windows-hardware/drivers/wdf/getting-started-with-umdf-version-2) -Testing -------- +## Testing To test the Echo driver, you can run echoapp.exe which is built from \\echo\\exe. @@ -45,14 +32,14 @@ Usage: Echoapp.exe --- Send single write and read request synchronously Echoapp.exe -Async --- Send 100 reads and writes asynchronously Exit the app anytime by pressing Ctrl-C - + D:\>echoapp DevicePath: \\?\root#sample#0000#{cdc35b6e-0be4-4936-bf5f-5537380a7c1a} Opened device successfully 512 Pattern Bytes Written successfully 512 Pattern Bytes Read successfully Pattern Verified successfully - + D:\>echoapp -Async DevicePath: \\?\root#sample#0000#{cdc35b6e-0be4-4936-bf5f-5537380a7c1a} Opened device successfully @@ -84,52 +71,50 @@ Number of bytes written by request number 11 is 1024 Note that the reads and writes are performed by independent threads in the echo test application. As a result the order of the output may not exactly match what you see above. -File Manifest -------------- +## File Manifest -**comsup.cpp & comsup.h** +comsup.cpp and comsup.h - COM Support code - specifically base classes which provide implementations for the standard COM interfaces IUnknown and IClassFactory which are used throughout this sample. + - The implementation of IClassFactory is designed to create instances of the CMyDriver class. If you should change the name of your base driver class, you would also need to modify this file. -**dllsup.cpp** +dllsup.cpp - DLL Support code - provides the DLL's entry point as well as the single required export (DllGetClassObject). + - These depend on comsup.cpp to perform the necessary class creation. -**exports.def** +exports.def - This file lists the functions that the driver DLL exports. -**internal.h** +internal.h - This is the main header file for this driver. -**Driver.cpp and Driver.h** +Driver.cpp and Driver.h - DriverEntry and events on the driver object. -**Device.cpp and Device.h** +Device.cpp and Device.h - The Events on the device object. -**Queue.cpp and Queue.h** +Queue.cpp and Queue.h - Contains Events on the I/O Queue Objects. -**Echo.rc** +Echo.rc - Resource file for the driver. -**WUDFEchoDriver.inx** +WUDFEchoDriver.inx - File that describes the installation of this driver. The build process converts this into an INF file. -**makefile.inc** - -- A makefile that defines custom build actions. This includes the conversion of the .INX - -**echodriver.ctl** +echodriver.ctl - This file lists the WPP trace control GUID(s) for the sample driver. This file can be used with the tracelog command's -guid flag to enable the collection of these trace events within an established trace session. + - These GUIDs must remain in sync with the trace control GUIDs defined in internal.h. diff --git a/general/echo/umdf2/README.md b/general/echo/umdf2/README.md index ae812ab8..b5f1d461 100644 --- a/general/echo/umdf2/README.md +++ b/general/echo/umdf2/README.md @@ -8,17 +8,6 @@ products: - windows-wdk --- - - -<!--- - name: Echo Sample (UMDF Version 2) - platform: UMDF2 - language: cpp - category: General WDF - description: Demonstrates how to use UMDF 2 to write a driver and to employ best practices. - samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617708 ----> - # Echo Sample (UMDF Version 2) The ECHO (UMDF version 2) sample demonstrates how to use a sequential queue to serialize read and write requests presented to the driver. @@ -29,28 +18,25 @@ It also shows how to synchronize execution of these events with other asynchrono This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. -Related technologies --------------------- +## Related technologies + +[User-Mode Driver Framework](https://docs.microsoft.com/windows-hardware/drivers/wdf/getting-started-with-umdf-version-2) -[User-Mode Driver Framework](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560456) +## Build the sample with Visual Studio -Open the driver solution in Visual Studio ------------------------------------------ +### Open the driver solution in Visual Studio In Microsoft Visual Studio, open the solution file (umdf2echo.sln). Choose **Solution Explorer** from the **View** menu. In Solution Explorer, you can see one solution that contains three projects. There is a driver project (Driver-\>AutoSync-\>echo), an application project (Exe-\>echoapp), and a package project named **package** (lower case). -Set the configuration and platform in Visual Studio ---------------------------------------------------- +### Set the configuration and platform in Visual Studio In Visual Studio, in Solution Explorer, right click **Solution**, 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. -Locate the built driver package -------------------------------- +### Locate the built driver package In File Explorer, navigate to the folder that contains your built driver package. The location of this folder varies depending on what you set for configuration and platform. -Run the sample --------------- +## Run the sample The computer where you install the driver is called the *target computer* or the *test computer*. Typically this is a separate computer from where you develop and build the driver package. The computer where you develop and build the driver is called the *host computer*. @@ -58,20 +44,23 @@ The process of moving the driver package to the target computer and installing t ### Automatic deployment (root enumerated) -Before you automatically deploy a driver, you must provision the target computer. For instructions, see [Configuring a Computer for Driver Deployment, Testing, and Debugging](http://msdn.microsoft.com/en-us/library/windows/hardware/). +Before you automatically deploy a driver, you must provision the target computer. For instructions, see [Provision a computer for driver deployment and testing](https://docs.microsoft.com/windows-hardware/drivers/gettingstarted/provision-a-target-computer-wdk-8-1). 1. On the host computer, in Visual Studio, in Solution Explorer, right click **package** (lower case), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**. + 1. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, select the name of a target computer that you provisioned previously. Select **Hardware ID Driver Update**, and enter **root\\ECHO** for the hardware ID. Click **OK**. + 1. On the **Build** menu, choose **Build Solution**. ### Manual deployment (root enumerated) -Before you manually deploy a driver, you must turn on test signing and install a certificate on the target computer. You also need to copy the [DevCon](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544707) tool to the target computer. For instructions, see [Preparing a Computer for Manual Driver Deployment](https://docs.microsoft.com/en-us/windows-hardware/drivers/develop/preparing-a-computer-for-manual-driver-deployment). +Before you manually deploy a driver, you must turn on test signing and install a certificate on the target computer. You also need to copy the [DevCon](https://docs.microsoft.com/windows-hardware/drivers/devtest/devcon) tool to the target computer. For instructions, see [Preparing a Computer for Manual Driver Deployment](https://docs.microsoft.com/windows-hardware/drivers/develop/preparing-a-computer-for-manual-driver-deployment). 1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\umdf2echoPkg). + 1. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter the following command: - **devcon install echoum.inf root\\ECHO** + `devcon install echoum.inf root\\ECHO` ### View the root enumerated driver in Device Manager @@ -79,11 +68,10 @@ On the target computer, in a Command Prompt window, enter **devmgmt** to open De In Device Manager, on the **View** menu, choose **Devices by connection**. Locate **Sample WDF ECHO Driver** as a child of the root node of the device tree. -Build the sample using MSBuild ------------------------------- +## Build the sample using MSBuild As an alternative to building the driver sample in Visual Studio, you can build it in a Visual Studio Command Prompt window. In Visual Studio, on the **Tools** menu, choose **Visual Studio Command Prompt**. In the Visual Studio Command Prompt window, navigate to the folder that has the solution file, umdf2echo.sln. Use the MSBuild command to build the solution. Here is an example: -**msbuild /p:configuration="Release" /p:platform="Win32" umdf2echo.sln** +`msbuild /p:configuration="Release" /p:platform="Win32" umdf2echo.sln` -For more information about using MSBuild to build a driver package, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644). +For more information about using MSBuild to build a driver package, see [MSBuild primer for WDK developers](https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/msbuild-primer-for-wdk-developers). diff --git a/general/echo/umdfSocketEcho/README.md b/general/echo/umdfSocketEcho/README.md index 38107cec..724e251e 100644 --- a/general/echo/umdfSocketEcho/README.md +++ b/general/echo/umdfSocketEcho/README.md @@ -8,39 +8,27 @@ products: - windows-wdk --- - - -<!--- - name: UMDF SocketEcho Sample (UMDF Version 1) - platform: UMDF1 - language: cpp - category: General WDF - description: Demonstrates how to use UMDF version 1 to write a driver and demonstrates best practices. - samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617709 ----> - # UMDF SocketEcho Sample (UMDF Version 1) The UMDF SocketEcho sample demonstrates how to use the User-Mode Driver Framework (UMDF) to write a driver and demonstrates best practices. This sample also demonstrates how to use a default parallel dispatch I/O queue, use a Microsoft Win32 dispatcher, and handle a socket handle by using a Win32 file I/O target. -Related technologies --------------------- +## Related technologies -[User-Mode Driver Framework](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560456) +[User-Mode Driver Framework](https://docs.microsoft.com/windows-hardware/drivers/wdf/getting-started-with-umdf-version-2) -Code Tour ---------- +## Code Tour This sample driver is a minimal driver that is intended to demonstrate how to use UMDF. It is not intended for use in a production environment. -- **CMyDriver::OnInitialize** in **driver.cpp** is called by the framework when the driver loads. This method initiates use of the Winsock Library. +- **CMyDriver::OnInitialize** in **driver.cpp** is called by the framework when the driver loads. This method initiates use of the Winsock Library. + - **CMyDriver::OnDeviceAdd** in **driver.cpp** is called by the framework to install the driver on a device stack. OnDeviceAdd creates a device callback object, and then calls IWDFDriver::CreateDevice to create an framework device object and to associate the device callback object with the framework device object. + - **CMyQueue::OnCreateFile** in **queue.cpp** is called by the framework to create a socket connection, create a file i/o target that is associated with the socket handle for this connection, and store the socket handle in the file object context. -Installation ------------- +## Installation In Visual Studio, you can press F5 to build the sample and then deploy it to a target machine. For more information, see [Deploying a Driver to a Test Computer](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454834). Alternatively, you can install the sample from the command line. @@ -52,11 +40,12 @@ To install the UMDF Echo sample driver from the command line, do the following: 1. Copy the UMDF coinstaller, WUDFUpdate\_*MMmmmm*.dll, from the \\redist\\wdf\\\<architecture\> directory to the same directory (for example, C:\\socketechoSample). - **Note** You can obtain redistributable framework updates by downloading the *wdfcoinstaller.msi* package from [WDK 8 Redistributable Components](http://go.microsoft.com/fwlink/p/?LinkID=226396). This package performs a silent install into the directory of your Windows Driver Kit (WDK) installation. You will see no confirmation that the installation has completed. You can verify that the redistributables have been installed on top of the WDK by ensuring there is a redist\\wdf directory under the root directory of the WDK, %ProgramFiles(x86)%\\Windows Kits\\8.0. + > [!NOTE] + > You can obtain redistributable framework updates by downloading the *wdfcoinstaller.msi* package from [WDK 8 Redistributable Components](https://go.microsoft.com/fwlink/p/?LinkID=253170). 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. 1. Navigate to the directory that contains the INF file and binaries (for example, cd /d c:\\socketechoSample), and run DevCon.exe as follows: - `devcon.exe install socketecho.inf WUDF\\socketecho` + `devcon.exe install socketecho.inf WUDF\\socketecho` You can find DevCon.exe in the \\tools directory of the WDK (for example, \\tools\\devcon\\i386\\devcon.exe). @@ -78,8 +67,7 @@ To test this sample drivers on a checked operating system that you have installe 1. If WdfCoinstaller*MMmmmm*.dll or WinUsbCoinstaller.dll is included in your driver package, repeat step 1 and step 2 for them. -Testing -------- +## Testing 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. @@ -87,94 +75,72 @@ First, you must install the device as described earlier. Then, run socketechoser `D:\\\>socketechoserver -h` -Usage ------- +## Usage -```cmd -socketechoserver Display Usage +socketechoserver usage -socketechoserver -h Display Usage +```cmd +D:\>socketechoserver -h socketechoserver -p Start the app as server listening on default port - socketechoserver -p [port\#] Start the app as server listening on this port -D:\\\>socketechoserver -p +D:\>socketechoserver -p Listening on socket... +``` In another Command Prompt window, run echoapp.exe. -D:\\\>echoapp +```cmd +D:\>echoapp DevicePath: \\\\?\\root\#sample\#0000\#{ e5e65b0c-82c8-4689-96d4-f77837971990} Opened device successfully 512 Pattern Bytes Written successfully - 512 Pattern Bytes Read successfully Pattern Verified successfully -D:\\\>echoapp -Async +D:\>echoapp -Async -DevicePath: \\\\?\\root\#sample\#0000\#{cdc35b6e-0be4-4936-bf5f-5537380a7c1a} +DevicePath: \\?\root\#sample\#0000\#{cdc35b6e-0be4-4936-bf5f-5537380a7c1a} Opened device successfully Starting AsyncIo Number of bytes written by request number 0 is 1024 - Number of bytes read by request number 0 is 1024 - +Number of bytes written by request number 1 is 1024 Number of bytes read by request number 1 is 1024 - Number of bytes written by request number 2 is 1024 - Number of bytes read by request number 2 is 1024 - Number of bytes written by request number 3 is 1024 - Number of bytes read by request number 3 is 1024 - Number of bytes written by request number 4 is 1024 - Number of bytes read by request number 4 is 1024 - Number of bytes written by request number 5 is 1024 - Number of bytes read by request number 5 is 1024 - Number of bytes written by request number 6 is 1024 - Number of bytes read by request number 6 is 1024 - Number of bytes written by request number 7 is 1024 - Number of bytes read by request number 7 is 1024 - Number of bytes written by request number 8 is 1024 - Number of bytes read by request number 8 is 1024 - Number of bytes written by request number 9 is 1024 - Number of bytes read by request number 9 is 1024 - Number of bytes written by request number 10 is 1024 - Number of bytes read by request number 10 is 1024 - Number of bytes written by request number 11 is 1024 - ... ``` -Note that independent threads perform the reads and writes in the echo test application. As a result, the order of the output might not exactly match what you see in the preceding output. +> [!NOTE] +> Independent threads perform the reads and writes in the echo test application. As a result, the order of the output might not exactly match what you see in the preceding output example. -File Manifest -------------- +## File Manifest **Dllsup.cpp**: The DLL support code that provides the DLL's entry point and the single required export (DllGetClassObject). |