diff options
| author | Barry Golden <[email protected]> | 2015-07-30 16:03:24 -0700 |
|---|---|---|
| committer | Barry Golden <[email protected]> | 2015-07-30 16:03:24 -0700 |
| commit | 4dc90ad04d5e40851e2e370f487b7cc9a3be071b (patch) | |
| tree | c2e74dd18a743893c555d311f29ad9fba77b60c6 | |
| parent | d3abcb10a801986a2956d6bbdfeb652bda1d9a74 (diff) | |
Update README.md
50 files changed, 790 insertions, 1108 deletions
diff --git a/avstream/samplemft0/ReadMe.md b/avstream/samplemft0/ReadMe.md index 8087c135..7f6e50f6 100644 --- a/avstream/samplemft0/ReadMe.md +++ b/avstream/samplemft0/ReadMe.md @@ -15,8 +15,6 @@ Related topics [Windows Store device apps for cameras](http://go.microsoft.com/fwlink/p/?LinkId=306683) -[Windows 8 device experience](http://go.microsoft.com/fwlink/p/?linkid=241442) - [Media Foundation Transforms](http://msdn.microsoft.com/en-us/library/windows/hardware/ms703138) [Roadmap for Developing Streaming Media Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff568130) diff --git a/bluetooth/bthecho/ReadMe.md b/bluetooth/bthecho/ReadMe.md index cf19189a..83ba0940 100644 --- a/bluetooth/bthecho/ReadMe.md +++ b/bluetooth/bthecho/ReadMe.md @@ -3,34 +3,38 @@ 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): - Generic Bluetooth Radio = BthUsb, USB\Vid_0a12&Pid_0001 - CSR Nanosira = BthUsb, USB\Vid_0a12&Pid_0003 - CSR Nanosira WHQL Reference Radi o= BthUsb, USB\Vid_0a12&Pid_0004 - CSR Nanosira-Multimedia = BthUsb, USB\Vid_0a12&Pid_0005 - CSR Nanosira-Multimedia WHQL Reference Radio = BthUsb, USB\Vid_0a12&Pid_0006 - -Please refer to bth.inf for the complete list of devices. The installation steps below describe how to install echo server and client with such a device. Please note that RFCOMM based profiles must be developed and accessed using user-mode socket APIs. This sample is applicable to Windows® Vista, Windows® 7 and Windows® 8 operating systems. +``` +Generic Bluetooth Radio=\ + BthUsb, USB\Vid_0a12&Pid_0001 +CSR Nanosira=\ + BthUsb, USB\Vid_0a12&Pid_0003 +CSR Nanosira WHQL Reference Radio=\ + BthUsb, USB\Vid_0a12&Pid_0004 +CSR Nanosira-Multimedia=\ + BthUsb, USB\Vid_0a12&Pid_0005 +CSR Nanosira-Multimedia WHQL Reference Radio=\ + BthUsb, USB\Vid_0a12&Pid_0006 +``` +Please refer to bth.inf for the complete list of devices. The installation steps below describe how to install echo server and client with such a device. Please note that RFCOMM based profiles must be developed and accessed using user-mode socket APIs. Build the sample ---------------- -Starting in the WDK, you can build the sample in two ways: using the Visual Studio Integrated Development Environment (IDE) or from the command line using the Visual Studio Command Prompt window and the Microsoft Build Engine (MSBuild.exe). +You can build the sample in two ways: using the Visual Studio Integrated Development Environment (IDE) or from the command line using the Visual Studio Command Prompt window and the Microsoft Build Engine (MSBuild.exe). **Building the sample using Visual Studio** -1. Open Visual Studio. From the **File** menu, select **Open Project/Solution**. Within your WDK installation, navigate to src\\bluetooth\\bthecho and open the bthecho.sln project file. +1. Open Visual Studio. From the **File** menu, select **Open Project/Solution** and open the bthecho.sln project file. 2. Right-click the solution in the **Solution Explorer** and select **Configuration Manager**. -3. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Windows 8.1 Debug or Windows 8.1 Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. +3. From the **Configuration Manager**, select the **Active Solution Configuration** and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. 4. From the **Build** menu, click **Build Solution** (Ctrl+Shift+B). -Previous versions of the WDK used the Windows Build utility (Build.exe) and provided separate build environment windows for each of the supported build configurations. Starting in the WDK, you can use the Visual Studio Command Prompt window for all build configurations. - **Building the sample using the command line (MSBuild)** 1. Open a Visual Studio Command Prompt window. Click **Start** and search for **Developer Command Prompt**. If your project is under %PROGRAMFILES%, you need to open the command prompt window using elevated permissions (**Run as administrator**). From this window you can use MsBuild.exe to build any Visual Studio project by specifying the project (.VcxProj) or solutions (.Sln) file. 2. Navigate to each of the respective project directories and enter the appropriate **MSbuild** command for your target. For example, to perform a clean build of a Visual Studio driver project called BthEcho.vcxproj, navigate to the samples\\bluetooth\\bthecho\\bthcli\\sys project directory and enter the following MSBuild command: **msbuild /t:clean /t:build .\\BthEchoSampleCli.vcxproj**. -3. If the build succeeds, you will find the driver (BthEchoSampleCli.sys) in the binary output directory corresponding to the target platform, for example src\\bluetooth\\bthecho\\PackageWindows 8.1 Debug. +3. If the build succeeds, you will find the driver (BthEchoSampleCli.sys) in the binary output directory corresponding to the target platform. Run the sample -------------- @@ -45,29 +49,27 @@ Run the sample 2. Run bthsrvinst.exe /i to install the echo server device. This enables the Bluetooth Enumerator (BthEnum.sys) to enumerate echo server device and create a PDO for the device (please refer to the device tree below). -3. Step \#2 causes BthEnum.sys to create a PDO. Consequently hardware installation wizard gets launched. Either go through the UI (Device Manager – Update Driver Software in Windows® 7, ‘Found New Hardware’ wizard in Windows® Vista) and point it to the temporary directory where you copied the binaries in step \#1, or using devcon.exe from the tools\\devcon folder, run the following command from the temporary directory: +3. Step \#2 causes BthEnum.sys to create a PDO. Consequently hardware installation wizard gets launched. Either go through the UI and point it to the temporary directory where you copied the binaries in step \#1, or using devcon.exe from the tools\\devcon folder, run the following command from the temporary directory: -``` {.syntax xml:space="preserve"} -devcon.exe update BthEchoSampleSrv.inf BTHENUM\{c07508f2-b970-43ca-b5dd-cc4f2391bef4} -``` + ``` + devcon.exe update BthEchoSampleSrv.inf BTHENUM\{c07508f2-b970-43ca-b5dd-cc4f2391bef4} + ``` -If devcon.exe fails check the error level using: + If devcon.exe fails check the error level using: -``` {.syntax xml:space="preserve"} -echo %errorlevel% -``` + ``` + echo %errorlevel% + ``` -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. + 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. -5. (This steps in needed only on Windows® Vista) Navigate to the system tray, right click on the Bluetooth icon, and select ‘Open Settings’. This launches the ‘Bluetooth Settings’ dialog. On the ‘Options’ tab, check ‘Allow Bluetooth devices to find this Computer’. Note that this will make your computer discoverable to other Bluetooth devices, and should be disabled again when no longer required. - **Device tree for Echo Server device** (Drivers for FDOs are shown for each devnode in the tree.) -``` {.syntax xml:space="preserve"} +``` -------------------- |BthEchoSampleSrv.sys|<----Function driver for PDO ejected by BthEnum.sys -------------------- @@ -103,21 +105,21 @@ If errorlevel is 1, you need to reboot the machine for KMDF update to take effec 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. Windows® 7: In the ‘Bluetooth Devices’ window click the ‘Add a device’ button. Windows® Vista: In the ‘Devices’ tab, click Add button. +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’. 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. The ‘Found New Hardware’ wizard will be launched on Windows® Vista. On Windows® 7 and Windows® 8 you will need to 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: +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: -``` {.syntax xml:space="preserve"} -Devcon.exe update BthEchoSampleCli.inf BTHENUM\{c07508f2-b970-43ca-b5dd-cc4f2391bef4} -``` + ``` + Devcon.exe update BthEchoSampleCli.inf BTHENUM\{c07508f2-b970-43ca-b5dd-cc4f2391bef4} + ``` -Check for any error from devcon.exe as described in server installation. + 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). @@ -129,13 +131,14 @@ The device tree for echo client device is similar to the one shown for the echo **Uninstalling Client** -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’ + +- 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** Run BthEcho.exe on the client machine. You should see client sending data to the server and receiving the same data echoed back. Press Ctrl+c to terminate the application. You will see output similar to below: -``` {.syntax xml:space="preserve"} +``` D:\bth\wdfcli>BthEcho.exe DevicePath: \\?\bthenum#{c07508f2-b970-43ca-b5dd-cc4f2391bef4}_localmfg&000a#7&3 62d0a3&0&000c55ff727a_c00000001#{fc71b33d-d528-4763-a86c-78777c7bcd7b} @@ -172,7 +175,7 @@ You can launch multiple instances of BthEcho.exe. Each client application would **Connection state machine**: -``` {.syntax xml:space="preserve"} +``` ConnectFailed ^ | diff --git a/filesys/miniFilter/NameChanger/ReadMe.md b/filesys/miniFilter/NameChanger/ReadMe.md index 9846414b..3aff5c17 100644 --- a/filesys/miniFilter/NameChanger/ReadMe.md +++ b/filesys/miniFilter/NameChanger/ReadMe.md @@ -14,13 +14,13 @@ Building a Driver Using Visual Studio You build a driver the same way you build any project or solution in Visual Studio. When you create a new driver project using a Windows driver template, the template defines a default (active) project configuration and a default (active) solution build configuration. When you create a project from existing driver sources or convert existing driver code that was built with previous versions of the WDK, the conversion process preserves the target version information (operating systems and platform). -The default Solution build configuration is Windows 8.1 Debug and Win32. +The default Solution build configuration is Debug and Win32. ### To select a configuration and build a driver 1. Open the driver project or solution in Visual Studio (find *filtername*.sln or *filtername*.vcxproj). 2. Right-click the solution in the **Solutions Explorer** and select **Configuration Manager**. -3. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Windows 8.1 Debug or Windows 8.1 Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. +3. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Debug or Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. 4. From the Build menu, click **Build Solution** (Ctrl+Shift+B). Building a Driver Using the Command Line (MSBuild) @@ -54,49 +54,19 @@ Design and Operation The *NameChanger* minifilter illustrates how to make one part of a volume's namespace appear as though it belongs to part of another namespace. It accomplishes this by altering the names of files that reside beneath a particular path (called the "real mapping") to appear as though they actually reside beneath a different path (called the "user mapping"). The .inf file supplied with the sample defines the real and user mappings in the *[Strings]* section. The three strings used for the mappings are: -<table> -<colgroup> -<col width="50%" /> -<col width="50%" /> -</colgroup> -<thead> -<tr class="header"> -<th align="left">String -Description</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td align="left"><p>UserMapping</p> -<p>The location where files will appear to be in when the filter is attached</p></td> -<td align="left"><p>UserMappingFinalComponentShort</p> -<p>The"short" (e.g. DOS-compliant 8.3-format) name for the final component of the UserMapping path.</p></td> -</tr> -</tbody> -</table> +String | Description +-------|------------- +UserMapping | The location where files will appear to be in when the filter is attached +UserMappingFinalComponentShort | The "short" (DOS-compliant 8.3-format) name for the final component of the UserMapping path. +RealMapping | The actual location where the files reside. Before attaching the minifilter to a volume, you must set up the user and real paths. By default the .inf defines the mapping paths like in the following manner: -<table> -<colgroup> -<col width="50%" /> -<col width="50%" /> -</colgroup> -<thead> -<tr class="header"> -<th align="left">String -Mapping</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td align="left"><p>UserMapping</p> -<p>"\X\Y"</p></td> -<td align="left"><p>UserMappingFinalComponentShort</p> -<p>"Y"</p></td> -</tr> -</tbody> -</table> +String | Mapping +-------|-------- +UserMapping | "\X\Y" +UserMappingFinalComponentShort | "Y" +RealMapping | "\A\B" To successfully attach the filter to a volume you must first create a couple of directories. For example, to attach the *NameChanger* minifilter to the F: volume, first create the RealMapping directory (the F:\\A\\B directory). Next, create the parent of the UserMapping path (the F:\\X directory). The following directories are be created: diff --git a/general/cancel/ReadMe.md b/general/cancel/ReadMe.md index 5baab9b9..c2b09ead 100644 --- a/general/cancel/ReadMe.md +++ b/general/cancel/ReadMe.md @@ -1,14 +1,12 @@ 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 XP 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**](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. The sample is accompanied by a simple multithreaded Win32 console application to stress-test the driver's cancel and cleanup routines. This driver is written for an hypothetical data-acquisition device that requires polling at a regular interval. The device has some settling period between two successive reads. On a user request, the driver reads data and records the time. When the next read request comes in, the driver checks the interval to see if it's reading the device too soon. If so, it pends the IRP and sleeps for a while, and then tries again. On arrival, IRPs are queued in a cancel-safe queue and a semaphore is signaled. A polling thread that waits indefinitely on the semaphore wakes up to the signal and processes queued IRPs sequentially. -The building and installation instructions given here apply to Windows 2000 and later versions of Windows. - 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. diff --git a/general/echo/umdf/ReadMe.md b/general/echo/umdf/ReadMe.md index 750d34df..75ae46cd 100644 --- a/general/echo/umdf/ReadMe.md +++ b/general/echo/umdf/ReadMe.md @@ -20,7 +20,7 @@ To test the Echo driver, you can run echoapp.exe which is built from src\\genera First install the device as described above. Then run echoapp.exe. -``` {.syntax xml:space="preserve"} +``` D:\>echoapp /? Usage: Echoapp.exe --- Send single write and read request synchronously @@ -68,57 +68,50 @@ Note that the reads and writes are performed by independent threads in the echo File Manifest ------------- -File - -Description - -comsup.cpp & 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 +**comsup.cpp & comsup.h** -DLL Support code - provides the DLL's entry point as well as the single required export (DllGetClassObject). +- 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. -These depend on comsup.cpp to perform the necessary class creation. +**dllsup.cpp** -exports.def +- 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. -This file lists the functions that the driver DLL exports. +**exports.def** -internal.h +- This file lists the functions that the driver DLL exports. -This is the main header file for this driver. +**internal.h** -Driver.cpp and Driver.h +- This is the main header file for this driver. -DriverEntry and events on the driver object. +**Driver.cpp and Driver.h** -Device.cpp and Device.h +- DriverEntry and events on the driver object. -The Events on the device object. +**Device.cpp and Device.h** -Queue.cpp and Queue.h +- The Events on the device object. -Contains Events on the I/O Queue Objects. +**Queue.cpp and Queue.h** -Echo.rc +- Contains Events on the I/O Queue Objects. -Resource file for the driver. +**Echo.rc** -WUDFEchoDriver.inx +- Resource file for the driver. -File that describes the installation of this driver. The build process converts this into an INF file. +**WUDFEchoDriver.inx** -makefile.inc +- File that describes the installation of this driver. The build process converts this into an INF file. -A makefile that defines custom build actions. This includes the conversion of the .INX file into a .INF file +**makefile.inc** -echodriver.ctl +- A makefile that defines custom build actions. This includes the conversion of the .INX -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. +**echodriver.ctl** -These GUIDs must remain in sync with the trace control GUIDs defined in internal.h. +- 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 3229f61b..bb45c52a 100644 --- a/general/echo/umdf2/ReadMe.md +++ b/general/echo/umdf2/ReadMe.md @@ -22,18 +22,18 @@ Click the download button on this page. Click **Save**, and then click **Open Fo Open the driver solution in Visual Studio ----------------------------------------- -Navigate to the folder that has the extracted sample. Double click the solution file (umdf2echo.sln). In Microsoft Visual Studio, locate Solution Explorer. (If this is not already open, choose **Solution Explorer** from the **View** menu.) In Solution Explorer, you can see one solution that contains 3 projects. There is a driver project (Driver-\>AutoSync-\>echo), an application project (Exe-\>echoapp), and a package project named **package** (lower case). +Navigate to the folder that has the extracted sample. Double click the solution file (umdf2echo.sln). In Microsoft Visual Studio, locate Solution Explorer. (If this is not already open, 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 --------------------------------------------------- -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. Because this solution uses UMDF version 2, you cannot select a configuration earlier than Windows 8.1. +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 ------------------------------- -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. For example, if your settings are Win8.1 Debug and x64, the package is in your solution folder under x64\\Win8.1Debug\\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 -------------- @@ -70,7 +70,7 @@ 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=”Win8 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). diff --git a/general/echo/umdfSocketEcho/ReadMe.md b/general/echo/umdfSocketEcho/ReadMe.md index 12515365..ed4ce05f 100644 --- a/general/echo/umdfSocketEcho/ReadMe.md +++ b/general/echo/umdfSocketEcho/ReadMe.md @@ -13,18 +13,18 @@ Related technologies Code Tour --------- -Parts of this code sample are generated from the ATL Project Wizard in Microsoft Visual Studio 2005. 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. +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::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. +- **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 ------------ 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. -To test this sample, you must have a test computer that is running Windows Vista or later. This test computer can be a second computer or, if necessary, your development computer. +To test this sample, you must have a test computer. This test computer can be a second computer or, if necessary, your development computer. To install the UMDF Echo sample driver from the command line, do the following: @@ -32,17 +32,13 @@ To install the UMDF Echo sample driver from the command line, do the following: 2. 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. - -3. + **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. - Navigate to the directory that contains the INF file and binaries (for example, cd /d c:\\socketechoSample), and run DevCon.exe as follows: +3. 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). + You can find DevCon.exe in the \\tools directory of the WDK (for example, \\tools\\devcon\\i386\\devcon.exe). To update the socketecho driver after you make any changes, do the following: @@ -52,7 +48,7 @@ To update the socketecho driver after you make any changes, do the following: 3. 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 update socketecho.inf WUDF\\socketecho + `devcon.exe update socketecho.inf WUDF\\socketecho` To test this sample drivers on a checked operating system that you have installed (in contrast to the standard retail installations), you must modify the INF file to use the checked version of the UMDF co-installer. That is, you must do the following: @@ -69,12 +65,11 @@ To test the SocketEcho driver, you can run socketechoserver.exe, which is built First, you must install the device as described earlier. Then, run socketechoserver.exe from a Command Prompt window. -D:\\\>socketechoserver -h - -Usage: +`D:\\\>socketechoserver -h` +Usage ------ - +``` socketechoserver Display Usage socketechoserver -h Display Usage @@ -154,31 +149,13 @@ 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. File Manifest ------------- -<table> -<colgroup> -<col width="50%" /> -<col width="50%" /> -</colgroup> -<thead> -<tr class="header"> -<th align="left">File -Description</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td align="left"><p>Socketecho.htm</p> -<p>The documentation for this sample.</p></td> -<td align="left"><p>Dllsup.cpp</p> -<p>The DLL support code that provides the DLL's entry point and the single required export (DllGetClassObject).</p></td> -</tr> -</tbody> -</table> +**Dllsup.cpp**: The DLL support code that provides the DLL's entry point and the single required export (DllGetClassObject). diff --git a/general/filehistory/ReadMe.md b/general/filehistory/ReadMe.md index 58ebbb46..3e29b08e 100644 --- a/general/filehistory/ReadMe.md +++ b/general/filehistory/ReadMe.md @@ -3,7 +3,7 @@ File History Sample The FileHistory sample is a console application that starts the file history service, if it is stopped, and schedules regular backups. The application requires, as a command-line parameter, the path name of a storage device to use as the default backup target. -This sample application uses the [File History API](http://msdn.microsoft.com/en-us/library/windows/hardware/hh829789), which is available starting with Windows 8.1. The File History API enables third parties to automatically configure the File History feature on a Windows platform and customize it in accordance with their unique needs. +This sample application uses the [File History API](http://msdn.microsoft.com/en-us/library/windows/hardware/hh829789). The File History API enables third parties to automatically configure the File History feature on a Windows platform and customize it in accordance with their unique needs. Run the sample diff --git a/general/obcallback/ReadMe.md b/general/obcallback/ReadMe.md index def34eac..7efc2741 100644 --- a/general/obcallback/ReadMe.md +++ b/general/obcallback/ReadMe.md @@ -11,7 +11,7 @@ The sample exercises both the [**PsSetCreateProcessNotifyRoutineEx**](http://msd The following is a command line usage scenario to exercise access restriction: -``` {.syntax xml:space="preserve"} +``` 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) @@ -27,13 +27,11 @@ C:\> obcallbacktestctrl.exe -deprotect (remove the protections on C:\> kill –f 2329 (attempt to kill off the process – which will succeed) C:\> obcallbacktestctrl.exe -uninstall (uninstall the kernel driver) - - ``` The following is another sample test you can run to prevent a process from being created: -``` {.syntax xml:space="preserve"} +``` 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) diff --git a/general/pcidrv/ReadMe.md b/general/pcidrv/ReadMe.md index 72898b5b..39d4a2d6 100644 --- a/general/pcidrv/ReadMe.md +++ b/general/pcidrv/ReadMe.md @@ -43,31 +43,22 @@ Note that it is still possible to use a subset of KMDF APIs when writing a NDIS The sample driver has been tested on the following Intel Ethernet controllers: -<table> -<colgroup> -<col width="50%" /> -<col width="50%" /> -</colgroup> -<thead> -<tr class="header"> -<th align="left">Device Desc -Hardware ID</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td align="left"><p>IBM Netfinity 10/100 Ethernet Adapter</p> -<p>PCI\VEN_8086&DEV_1229&SUBSYS_005C1014&REV_05</p></td> -<td align="left"><p>Intel(R) PRO/100+ Management Adapter with Alert On LAN</p> -<p>PCI\VEN_8086&DEV_1229&SUBSYS_000E8086&REV_08</p></td> -</tr> -</tbody> -</table> +Device Description | Hardware ID +-------------------|------------ +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 +Intel 8255x-based PCI Ethernet Adapter (10/100) | PCI\VEN_8086&DEV_1229&SUBSYS_00031179&REV_08 +Intel(R) PRO/100 VE Network Connection | PCI\VEN_8086&DEV_103D&SUBSYS_00011179&REV_83 +Intel(R) PRO/100 VM Network Connection | PCI\VEN_8086&DEV_1031&REV_42 +Intel(R) PRO/100 VE Network Connection | PCI\VEN_8086&DEV_1038&REV_41 +Intel(R) PRO/100 SR Mobile Adapter | PCI\VEN_8086&DEV_1229 Using this sample as a standalone driver ---------------------------------------- -``` {.syntax xml:space="preserve"} +``` --------------------- | | | MYPING | <-- Usermode test application @@ -162,25 +153,11 @@ If you have questions on using or adapting this sample for your project, you can FILE MANIFEST ------------- -<table> -<colgroup> -<col width="50%" /> -<col width="50%" /> -</colgroup> -<thead> -<tr class="header"> -<th align="left">File -Description</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td align="left"><p>KMDF</p> -<p>Contains the driver.</p></td> -<td align="left"><p>KMDF\HW</p> -<p>Contains hardware specific code.</p></td> -</tr> -</tbody> -</table> +File | Description +-----|------------ +KMDF | Contains the driver. +KMDF\HW | Contains hardware specific code. +TEST | Contains source of test application (MYPING). + diff --git a/general/perfcounters/kcs/ReadMe.md b/general/perfcounters/kcs/ReadMe.md index 4f28894c..1cbd3ac0 100644 --- a/general/perfcounters/kcs/ReadMe.md +++ b/general/perfcounters/kcs/ReadMe.md @@ -7,8 +7,6 @@ This module contains sample code to demonstrate how to provide counter data from This sample driver should not be used in a production environment. -Kcs is designed for Windows 7 and later versions of Windows. - The Microsoft Windows operating system allows system components and third parties to expose performance metrics in a standard way by using [Performance Counters](http://msdn.microsoft.com/en-us/library/windows/hardware/aa373083). Kernel-mode PCW providers are installed in the system as Performance Counter Library (PERFLIB) (Version 2 providers), which allows their counters to be browsed, and allows for data collection and instance enumeration. Consumers can query KM PCW providers by using PDH and PERFLIB Version 1 without any modification to the consumer code. diff --git a/general/registry/regfltr/ReadMe.md b/general/registry/regfltr/ReadMe.md index 731e8ca3..9e5a0740 100644 --- a/general/registry/regfltr/ReadMe.md +++ b/general/registry/regfltr/ReadMe.md @@ -9,8 +9,6 @@ The RegFltr sample shows how to write a [registry filter driver](http://msdn.mic - Changes in version 1.1 of registry filtering. - How to use version 1 of the [**REG\_CREATE\_KEY\_INFORMATION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560920) and [**REG\_OPEN\_KEY\_INFORMATION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560957) data structures. -The RegFltr sample demonstrates the registry filtering system on Windows Vista, Windows Server 2008 and later versions of the Windows operating system. It does not work for Windows XP or Windows Server 2003. - The RegFltr sample contains several examples of user-mode and kernel-mode registry-filtering operations. Each example comes with its own corresponding registry callback routine, and performs the following steps: 1. Does some setup work. diff --git a/general/tracing/SystemTraceControl/ReadMe.md b/general/tracing/SystemTraceControl/ReadMe.md index f581e52e..eb044ddb 100644 --- a/general/tracing/SystemTraceControl/ReadMe.md +++ b/general/tracing/SystemTraceControl/ReadMe.md @@ -5,7 +5,7 @@ This sample application demonstrates how to use event tracing control APIs to co The sample code provided shows how to start an [Event Tracing](http://msdn.microsoft.com/en-us/library/windows/hardware/bb968803) for Windows trace session and how to enable system events with stacks. When you build and run the application, it collects the trace data for 30 seconds and then stops. The sample application writes the results to a file, Systemtrace.etl. For more information, see [Tools for Software Tracing](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552961). -You can process the Systemtrace.etl file using Tracerpt.exe. Tracerpt.exe is a command-line trace tool that formats trace events. It also analyzes the events and generates summary reports. Tracerpt is included in Windows XP and later versions of Windows. For more information about how to use this tool, see [Tracerpt](http://go.microsoft.com/fwlink/p/?linkid=179389) topic on the TechNet website. +You can process the Systemtrace.etl file using Tracerpt.exe, a command-line trace tool included in Windows that formats trace events. It also analyzes the events and generates summary reports. For more information about how to use this tool, see [Tracerpt](http://go.microsoft.com/fwlink/p/?linkid=179389) topic on the TechNet website. You can also process the file using the [Windows Performance Toolkit](http://go.microsoft.com/fwlink/p/?linkid=250774) (WPT), which is available in the SDK. diff --git a/general/tracing/evntdrv/ReadMe.md b/general/tracing/evntdrv/ReadMe.md index f5780ef6..a560a0a4 100644 --- a/general/tracing/evntdrv/ReadMe.md +++ b/general/tracing/evntdrv/ReadMe.md @@ -13,7 +13,7 @@ Run the sample 1. Install the manifest (Evntdrv.xml), which is located in the Evntdrv\\Eventdrv folder. Open a Visual Studio Command window (Run as administrator) and use the following command: - ``` {.syntax xml:space="preserve"} + ``` wevtutil im evntdrv.xml ``` @@ -29,7 +29,7 @@ Run the sample 3. Use Tracelog to start a trace session that is called "TestEventdrv." The following command starts the trace session and creates a trace log file, Eventdrv.etl, in the local directory. - ``` {.syntax xml:space="preserve"} + ``` Tracelog -start TestEventdrv -guid #b5a0bda9-50fe-4d0e-a83d-bae3f58c94d6 -f Eventdrv.etl ``` @@ -37,13 +37,13 @@ Run the sample 5. To stop the trace session, run the following command: - ``` {.syntax xml:space="preserve"} + ``` tracelog -stop TestEventdrv ``` 6. To display the traces collected in the Tracedrv.etl file, run the following command: - ``` {.syntax xml:space="preserve"} + ``` tracerpt Eventdrv.etl ``` @@ -51,12 +51,12 @@ Run the sample 7. To uninstall the manifest, run the following command: - ``` {.syntax xml:space="preserve"} + ``` wevtutil um evntdrv.xml ``` Notes ----- -If you are building the Eventdrv sample to test on a 64-bit version of Windows, you need to sign the driver. Starting with Windows Vista, all 64-bit versions of Windows require driver code to have a digital signature for the driver to load. See [Signing a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554809) and [Signing a Driver During Development and Testing](http://msdn.microsoft.com/en-us/library/windows/hardware/hh967733). You might also need to configure the test computer so that it can load test-signed kernel mode code, see [The TESTSIGNING Boot Configuration Option](http://msdn.microsoft.com/en-us/library/windows/hardware/ff553484) and [**BCDEdit /set**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff542202). +If you are building the Eventdrv sample to test on a 64-bit version of Windows, you need to sign the driver. All 64-bit versions of Windows require driver code to have a digital signature for the driver to load. See [Signing a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554809) and [Signing a Driver During Development and Testing](http://msdn.microsoft.com/en-us/library/windows/hardware/hh967733). You might also need to configure the test computer so that it can load test-signed kernel mode code, see [The TESTSIGNING Boot Configuration Option](http://msdn.microsoft.com/en-us/library/windows/hardware/ff553484) and [**BCDEdit /set**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff542202). diff --git a/general/tracing/tracedriver/ReadMe.md b/general/tracing/tracedriver/ReadMe.md index 99c46dd5..3e95d383 100644 --- a/general/tracing/tracedriver/ReadMe.md +++ b/general/tracing/tracedriver/ReadMe.md @@ -12,49 +12,37 @@ Run the sample To test the Tracedrv event tracing provider, use the following procedure. -1. Copy the Tracectl.exe file that was created when you built the Tracedrv solution from the Tracectl directory (for example, \\Documents\\Visual Studio 2013\\Projects\\tracedrv\\tracectl\\*platform*) to the Tracedrv directory (for example, \\Documents\\Visual Studio 2013\\Projects\\tracedrv\\tracedrv\\*platform*). -2. Use Tracepdb to create a trace message format (TMF) file and a trace message control (TMC) file from the Tracedrv.pdb file. Tracepdb is located in the C:\\Program Files (x86)\\Windows Kits\\8.1\\bin\\*platform* directory. The PDB file that is used in this command is created when you the build the solution. Open a Visual Studio Command prompt window and navigate to the target build platform and configuration directory. Type the following command: +1. Copy the Tracectl.exe file that was created when you built the Tracedrv solution from the Tracectl directory (for example, \\Documents\\Visual Studio 2015\\Projects\\tracedrv\\tracectl\\*platform*) to the Tracedrv directory (for example, \\Documents\\Visual Studio 2015\\Projects\\tracedrv\\tracedrv\\*platform*). +2. Use Tracepdb to create a trace message format (TMF) file and a trace message control (TMC) file from the Tracedrv.pdb file. Tracepdb is located in the C:\\Program Files (x86)\\Windows Kits\\10\\bin\\*platform* directory. The PDB file that is used in this command is created when you the build the solution. Open a Visual Studio Command prompt window and navigate to the target build platform and configuration directory. Type the following command: **tracepdb -f tracedrv.pdb** 3. In the same Tracedrv target build directory, create a control GUID file for Tracedrv by opening a text file, adding the following content, and saving the file as Tracedrv.ctl. - <table> - <colgroup> - <col width="100%" /> - </colgroup> - <thead> - <tr class="header"> - <th align="left">Text</th> - </tr> - </thead> - <tbody> - <tr class="odd"> - <td align="left"><pre><code>d58c126f-b309-11d1-969e-0000f875a5bc </code></pre></td> - </tr> - </tbody> - </table> + ```txt + d58c126f-b309-11d1-969e-0000f875a5bc + ``` -4. Use Tracelog to start a trace session that is called *TestTracedrv*. Tracelog is located in the C:\\Program Files (x86)\\Windows Kits\\8.1\\bin\\*platform* directory. The Tracedrv.ctl file that is used in this command was created in the previous step. The following command starts a trace session and creates a trace log file, tracedrv.etl, in the local directory. +4. Use Tracelog to start a trace session that is called *TestTracedrv*. Tracelog is located in the C:\\Program Files (x86)\\Windows Kits\\10\\bin\\*platform* directory. The Tracedrv.ctl file that is used in this command was created in the previous step. The following command starts a trace session and creates a trace log file, tracedrv.etl, in the local directory. - ``` {.syntax xml:space="preserve"} - tracelog -start TestTracedrv -guid tracedrv.ctl -f tracedrv.etl -flag 1 - ``` + ``` + tracelog -start TestTracedrv -guid tracedrv.ctl -f tracedrv.etl -flag 1 + ``` - **Note** Note: Without the -flag parameter, Tracedrv will not generate any trace messages. + **Note** Note: Without the -flag parameter, Tracedrv will not generate any trace messages. 5. To generate trace messages, run Tracectl.exe. This executable file is built when you build the solution. Each time you type a character, other than **Q** or **q**, Tracectl sends an IOCTL to the driver that signals it to generate trace messages. To stop Tracectl, type **Q** or **q**. 6. To stop the trace session, use the following Tracelog command. - ``` {.syntax xml:space="preserve"} - tracelog -stop TestTracedrv - ``` + ``` + tracelog -stop TestTracedrv + ``` -7. To display the trace messages in the Tracedrv.etl file, use Tracefmt.exe. Tracefmt.exe is located in the C:\\Program Files (x86)\\Windows Kits\\8.1\\bin\\*platform*. The TMF file used in this command was created by Tracepdb.exe in step 2. The **-p** option specifies the directory of the TMF file. In this case, the TMF file is in the current directory. Type the following command: +7. To display the trace messages in the Tracedrv.etl file, use Tracefmt.exe. Tracefmt.exe is located in the C:\\Program Files (x86)\\Windows Kits\\10\\bin\\*platform*. The TMF file used in this command was created by Tracepdb.exe in step 2. The **-p** option specifies the directory of the TMF file. In this case, the TMF file is in the current directory. Type the following command: - ``` {.syntax xml:space="preserve"} - tracefmt tracedrv.etl -p . -o Tracedrv.out - ``` + ``` + tracefmt tracedrv.etl -p . -o Tracedrv.out + ``` The resulting Tracedrv.out file is a human-readable text file of the Tracedrv trace messages. To interpret the trace messages, in the Tracedrv.c file, search for the [**DoTraceMessage**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544918) macros. @@ -63,11 +51,9 @@ Notes This sample driver should not be used in a production environment. -Tracedrv is designed for Windows XP and later versions of Windows. It does not demonstrate how to add WPP software tracing to a Windows 2000 driver. (For information about adding WPP software tracing to a Windows 2000 driver, see the [Software Tracing FAQ](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551795) topic in the Windows DDK documentation.) - Also, because it is not a Plug and Play driver, Tracedrv does not demonstrate tracing in a Plug and Play environment. Tracedrv demonstrates the basic elements required for software tracing. It does not demonstrate more advanced tracing techniques, such as writing customized tracing calls (variations of [**DoTraceMessage**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544918)), or the use of WMI calls for software tracing. -If you are building the Tracedrv sample to test on a 64-bit version of Windows, you need to sign the driver. Starting with Windows Vista, all 64-bit versions of Windows require driver code to have a digital signature for the driver to load. See [Signing a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554809) and [Signing a Driver During Development and Testing](http://msdn.microsoft.com/en-us/library/windows/hardware/hh967733). You might also need to configure the test computer so that it can load test-signed kernel mode code, see [The TESTSIGNING Boot Configuration Option](http://msdn.microsoft.com/en-us/library/windows/hardware/ff553484) and [**BCDEdit /set**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff542202). +If you are building the Tracedrv sample to test on a 64-bit version of Windows, you need to sign the driver. All 64-bit versions of Windows require driver code to have a digital signature for the driver to load. See [Signing a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554809) and [Signing a Driver During Development and Testing](http://msdn.microsoft.com/en-us/library/windows/hardware/hh967733). You might also need to configure the test computer so that it can load test-signed kernel mode code, see [The TESTSIGNING Boot Configuration Option](http://msdn.microsoft.com/en-us/library/windows/hardware/ff553484) and [**BCDEdit /set**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff542202). diff --git a/gpio/samples/ReadMe.md b/gpio/samples/ReadMe.md index 97464c5e..894bb7f1 100644 --- a/gpio/samples/ReadMe.md +++ b/gpio/samples/ReadMe.md @@ -3,26 +3,13 @@ GPIO Sample Drivers The GPIO samples contain annotated code to illustrate how to write a [GPIO controller driver](http://msdn.microsoft.com/en-us/library/windows/hardware/hh439509) that works in conjunction with the [GPIO framework extension](http://msdn.microsoft.com/en-us/library/windows/hardware/hh439512) (GpioClx) to handle GPIO I/O control requests, and a peripheral driver that runs in kernel mode and uses GPIO resources. For a sample that shows how to write a GPIO peripheral driver that runs in user mode, please refer to the SPB accelerometer sample driver (SPB\\peripherals\\accelerometer). -The GPIO sample set contains the following three samples. +The GPIO sample set contains the following samples: + +Minifilter | Sample Description +-----------|------------------- +SimGpio | The files in this sample contain the source code for a GPIO controller driver that communicates with GpioClx through the GpioClx device driver interface (DDI). The GPIO controller driver is written for a hypothetical memory-mapped GPIO controller (simgpio). The code is meant to be purely instructional. An ASL file illustrates how to specify a GPIO interrupt and I/O descriptor in the ACPI firmware. +SimGpio_I2C | The files in this sample contain the source code for a GPIO controller driver that communicates with GpioClx through the GpioClx DDI. In contrast to the SimGpio sample, the GPIO controller in this sample is not memory-mapped. The GPIO controller driver is written for a hypothetical GPIO controller that resides on an I2C bus (simgpio_i2c). The code is meant to be purely instructional. An ASL file illustrates how to specify a GPIO interrupt and I/O descriptor in the ACPI firmware. +SimDevice | The purpose of this sample is to show how a driver opens a device and performs I/O operations on a GPIO controller in kernel mode. Additionally, this sample demonstrates how the driver connects to a GPIO interrupt resource. The ASL file illustrates how to specify a GPIO interrupt and I/O descriptor in the ACPI firmware. +SimDeviceUmdf | The purpose of this sample is to show how a driver opens a device and performs I/O operations on a GPIO controller with UMDF. Additionally, this sample demonstrates how the driver connects to a GPIO interrupt resource. The ASL file illustrates how to specify a GPIO interrupt and I/O descriptor in the ACPI firmware. -<table> -<colgroup> -<col width="50%" /> -<col width="50%" /> -</colgroup> -<thead> -<tr class="header"> -<th align="left">Minifilter Sample -Description</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td align="left"><p><em>SimGpio</em></p> -<p>The files in this sample contain the source code for a GPIO controller driver that communicates with GpioClx through the GpioClx device driver interface (DDI). The GPIO controller driver is written for a hypothetical memory-mapped GPIO controller (simgpio). The code is meant to be purely instructional. An ASL file illustrates how to specify a GPIO interrupt and I/O descriptor in the ACPI firmware.</p></td> -<td align="left"><p><em>SimGpio_I2C</em></p> -<p>The files in this sample contain the source code for a GPIO controller driver that communicates with GpioClx through the GpioClx DDI. In contrast to the SimGpio sample, the GPIO controller in this sample is not memory-mapped. The GPIO controller driver is written for a hypothetical GPIO controller that resides on an I<sup>2</sup>C bus (simgpio_i2c). The code is meant to be purely instructional. An ASL file illustrates how to specify a GPIO interrupt and I/O descriptor in the ACPI firmware.</p></td> -</tr> -</tbody> -</table> diff --git a/hid/hclient/ReadMe.md b/hid/hclient/ReadMe.md index f0d2b154..b98902fe 100644 --- a/hid/hclient/ReadMe.md +++ b/hid/hclient/ReadMe.md @@ -5,14 +5,6 @@ The *HClient* sample demonstrates how to write a user-mode client application th You will find this sample useful if you need to develop an application that communicates with, or extracts information from, a HID device. This sample illustrates a method for detecting a connected HID, opening that device for communication, and extracting or formatting the data into, or from, device reports. -**Note** - -To build this sample, you can use Microsoft Visual Studio 2013 (Express, Professional, or Ultimate) and Windows Driver Kit (WDK) 8.1 Update. You can get Visual Studio 2013 and WDK 8.1 Update [here](http://go.microsoft.com/fwlink/p/?LInkID=239721). - -You can also build this sample with Visual Studio 2013 (Professional or Ultimate) and [Windows Driver Kit (WDK) 8.1](http://go.microsoft.com/fwlink/p/?LInkID=391348). - -For Windows Driver Kit (WDK) 8 samples, download the [WDK 8 samples pack](%20http://go.microsoft.com/fwlink/?LinkId=317090). The samples in the WDK 8 samples pack will build only with Microsoft Visual Studio Professional 2012 (Professional or Ultimate) and WDK 8. - Related topics -------------- diff --git a/network/ndis/filter/ReadMe.md b/network/ndis/filter/ReadMe.md index 4202c41a..386115a1 100644 --- a/network/ndis/filter/ReadMe.md +++ b/network/ndis/filter/ReadMe.md @@ -36,9 +36,11 @@ Before you manually deploy a driver, you must turn on test signing and install a Ndislwf is installed as a service (called **NDIS Sample LightWeight Filter** in the supplied INF). To install it, do the following: 1. Prepare an installation directory on the target computer and copy these files from the host computer into the directory: +``` netlwf.cat netlwf.inf ndislwf.sys +``` 2. Open **Control Panel**. 3. Click **Network and Internet** and then open **Network and Sharing Center**. Under **View your active networks**, click the connection listed under **Connections**: and click **Properties**. 4. If you have previously installed this sample, highlight it in the list. @@ -68,7 +70,7 @@ If you chose to deploy your driver manually, then you need to set up kernel debu The kernel-mode debuggers (WinDbg.exe and Kd.exe) are included in the WDK. -On the host computer, locate and open a kernel-mode debugger (example: c:\\Program Files (x86)\\Windows Kits\\8.1\\Debuggers\\x64\\windbg.exe). Establish a kernel-mode debugging session between the host and target computers. The details of how to do this depend on the type of debug cable you are using. For information about how to start a debugging session, see [Setting Up Kernel-Mode Debugging Manually](http://msdn.microsoft.com/en-us/library/windows/hardware/hh439378). +On the host computer, locate and open a kernel-mode debugger (example: c:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\x64\\windbg.exe). Establish a kernel-mode debugging session between the host and target computers. The details of how to do this depend on the type of debug cable you are using. For information about how to start a debugging session, see [Setting Up Kernel-Mode Debugging Manually](http://msdn.microsoft.com/en-us/library/windows/hardware/hh439378). Setting kd\_default\_mask ------------------------- @@ -83,25 +85,16 @@ Viewing trace messages ---------------------- On the host computer, in the kernel-mode debugger, verify that you see trace messages similar to these: - -<table> -<colgroup> -<col width="100%" /> -</colgroup> -<tbody> -<tr class="odd"> -<td align="left"><pre><code>NDISLWF: ===>DriverEntry... +``` +NDISLWF: ===>DriverEntry... NDISLWF: ===>FilterRegisterOptions NDISLWF: <===FilterRegisterOptions NDISLWF: ==>FilterRegisterDevice NDISLWF: <==FilterRegisterDevice: 0 NDISLWF: <===DriverEntry, Status = 0 NDISLWF: ===>FilterAttach: NdisFilterHandle FFFFE00000F73650 -NDISLWF: <===FilterAttach: Status 0</code></pre></td> -</tr> -</tbody> -</table> - +NDISLWF: <===FilterAttach: Status 0 +``` What the Ndislwf sample driver does: ------------------------------------ diff --git a/network/ndis/mux/ReadMe.md b/network/ndis/mux/ReadMe.md index e22050fe..cc864aec 100644 --- a/network/ndis/mux/ReadMe.md +++ b/network/ndis/mux/ReadMe.md @@ -98,18 +98,11 @@ The only status indications that are forwarded up by MUX are media connect statu During initialization (`MPInitialize`), the MUX miniport sets the attribute **NDIS\_ATTRIBUTE\_NO\_HALT\_ON\_SUSPEND** in its call to `NdisMSetMiniportAttributes`. When the MUX miniport is requested to report its Plug and Play capabilities (**OID\_PNP\_CAPABILITIES**), the MUX miniport forwards the request to the underlying miniport. If this request succeeds, then the MUX miniport overwrites the following fields before successfully completing the original request: -<table> -<colgroup> -<col width="100%" /> -</colgroup> -<tbody> -<tr class="odd"> -<td align="left"><pre><code>NDIS_DEVICE_POWER_STATE MinMagicPacketWakeUp = NdisDeviceStateUnspecified; +``` +NDIS_DEVICE_POWER_STATE MinMagicPacketWakeUp = NdisDeviceStateUnspecified; NDIS_DEVICE_POWER_STATE MinPatternWakeUp= NdisDeviceStateUnspecified; -NDIS_DEVICE_POWER_STATE MinLinkChangeWakeUp=NdisDeviceStateUnspecified</code></pre></td> -</tr> -</tbody> -</table> +NDIS_DEVICE_POWER_STATE MinLinkChangeWakeUp=NdisDeviceStateUnspecified +``` See `PtPostProcessPnPCapabilities` for details. @@ -170,5 +163,19 @@ The notify object provides a custom property page for the MUX IM driver. The cus When the MUX IM driver is uninstalled, or binding is disabled, or the user deletes all the virtual adapters on top of a physical adapter, the notify object restores the bindings of other protocols to the physical adapter if it has been compiled with the preprocessor flag **DISABLE\_PROTOCOLS\_TO\_PHYSICAL** defined in the Sources file. +### File Manifest +File | Description +-----|------------ +Miniport.c | Miniport related routines for the MUX driver +Mux.c | DriverEntry routine and any routines common to the MUX miniport and protocol +Mux.h | Prototypes of all functions and data structures used by the MUX driver +Mux.rc | Resource file for the MUX driver +Muxp.inf | Installation INF for the service (protocol side installation) +Mux_mp.inf | Installation INF for the miniport (virtual device installation) +Precomp.h | Precompile header file +Protocol.c | Protocol related routines for the MUX driver +Public.h | Contains the common declarations shared by driver and user applications + +For more information, see **NDIS Intermediate Drivers** in the network devices design guide. diff --git a/network/ndis/ndisprot/6x/ReadMe.md b/network/ndis/ndisprot/6x/ReadMe.md index 63e3a5ec..cdf35d7c 100644 --- a/network/ndis/ndisprot/6x/ReadMe.md +++ b/network/ndis/ndisprot/6x/ReadMe.md @@ -3,9 +3,7 @@ NDIS Connection-less Protocol Driver Sample This sample demonstrates a connection-less NDIS 6.0 protocol.The driver supports sending and receiving raw Ethernet frames using `ReadFile`/`WriteFile` calls from user-mode. It only receives frames with a specific EtherType field. As an NDIS protocol, it illustrates how to establish and tear down bindings to Ethernet adapters, i.e. those that export medium type **NdisMedium802\_3**. It shows how to set a packet filter, send and receive data, and handle plug-and-play events. - -INSTALLATION ------------- +### INSTALLATION The driver is installed using the INF file ndisprot.inf, which is provided in the driver directory. In Network Connections UI, select an adapter and open **Properties.** @@ -13,8 +11,7 @@ Click **Install**, then **Protocol**, then **Add**, and then **Have disk**. Then Select **Sample NDIS Protocol Driver** and click **OK**. After installing the protocol, copy over the test application prottest.exe to a convenient location. Please note that the driver service has been set to manual start in the INF file. As a result, it doesn't get loaded automatically when you install. -Usage ------ +### Usage To start the driver, type **Net start ndisprot**. @@ -22,24 +19,16 @@ To stop the driver, type **Net stop ndisprot**. To test the driver, run **prottest**. For help on usage, run **prottest -?** -**usage: PROTTEST [options] \<devicename\>** - -**options:** +**usage: PROTTEST [options] \\*devicename*** -<table> -<colgroup> -<col width="50%" /> -<col width="50%" /> -</colgroup> -<tbody> -<tr class="odd"> -<td align="left">-e -Enumerate devices</td> -<td align="left">-r -Read</td> -</tr> -</tbody> -</table> +options | Description +----------|------------ +-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) Prottest exercises the IOCTLs supported by NDISPROT, and sends and/or receives data on the selected device. In order to use prottest, the user must have administrative privilege. Users should pass down a big enough buffer in order to receive the entire received data. If the length of the buffer passed down is smaller than the length of the received data, NDISPROT will only copy part of the data and discard the rest when the given buffer is full. @@ -51,34 +40,24 @@ Use the **–e** option to enumerate all devices to which NDISPROT is bound: **DoReadProc finished: read 2 packets** -**Note** - -With a checked version of ndisprot.sys, you can control the volume of debug information generated by changing the variable `ndisprotDebugLevel`. Refer to debug.h for more information. +**Note** With a checked version of ndisprot.sys, you can control the volume of debug information generated by changing the variable `ndisprotDebugLevel`. Refer to debug.h for more information. For more information, see [NDIS Protocol Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff566821) in the network devices design guide. -File Manifest -------------- +### File Manifest -<table> -<colgroup> -<col width="50%" /> -<col width="50%" /> -</colgroup> -<thead> -<tr class="header"> -<th align="left">File -Description</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td align="left">prottest.c -User-mode test application</td> -<td align="left">debug.c -Routines to aid debugging</td> -</tr> -</tbody> -</table> +File | Description +-----|------------ +prottest.c | User-mode test application +debug.c | Routines to aid debugging +debug.h | Debug macro definitions +macros.h | Spinlock, event, referencing macros +ndisbind.c | NDIS protocol entry points to handle binding/unbinding from adapters +ndisprot.h | Data structure definitions +ndisprot.inf | INF file for installing NDISPROT +ntdisp.c | NT Entry points and dispatch routines for NDISPROT +protuser.h | IOCTL and associated structure definitions +recv.c | NDIS protocol entry points for receiving data, and IRP_MJ_READ processing +send.c | NDIS protocol routines for sending data, and IRP_MJ_WRITE processing diff --git a/network/radio/HidSwitchDriverSample/ReadMe.md b/network/radio/HidSwitchDriverSample/ReadMe.md index 5a94b523..5f4fdd81 100644 --- a/network/radio/HidSwitchDriverSample/ReadMe.md +++ b/network/radio/HidSwitchDriverSample/ReadMe.md @@ -3,8 +3,15 @@ Radio Switch Test Driver for OSR USB-FX2 Development Board This sample demonstrates how to structure a HID driver for radio switches for the OSR USB-FX2 Development Board. -Starting with Windows 8.1, the hardware switch or button to control wireless transmission and the global software switch (Airplane mode switch) in the Radio Management User Interface must be synchronized. To ensure the hardware and software switches that control radio transmission are synchronized, the hardware switch or button must have a HID-compliant driver. +The hardware switch or button to control wireless transmission and the global software switch (Airplane mode switch) in the Radio Management User Interface must be synchronized. To ensure the hardware and software switches that control radio transmission are synchronized, the hardware switch or button must have a HID-compliant driver. +Switch Pack Mapping +------------------- + +### Switch Mapping + 1 | 2 | 3 | 4 | 5 | 7 | 8 +---|---|---|---|---|---|--- + Mode Select Bit 3 | Mode Select Bit 2 | Mode Select Bit 1 | - | - | - | Radio Switch Testing ------- @@ -15,42 +22,17 @@ The driver supports five modes representing the valid combinations of HID descri ### Switch Mapping -<table> -<colgroup> -<col width="25%" /> -<col width="25%" /> -<col width="25%" /> -<col width="25%" /> -</colgroup> -<thead> -<tr class="header"> -<th align="left">1 -2 -3 -Mode</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td align="left">0 -0 -0 -Mode 1</td> -<td align="left">0 -0 -1 -Mode 1</td> -<td align="left">0 -1 -0 -Mode 2</td> -<td align="left">0 -1 -1 -Mode 3</td> -</tr> -</tbody> -</table> + 1 | 2 | 3 | Mode +---|---|---|----- + 0 | 0 | 0 | Mode 1 + 0 | 0 | 1 | Mode 1 + 0 | 1 | 0 | Mode 2 + 0 | 1 | 1 | Mode 3 + 1 | 0 | 0 | Mode 4 + 1 | 0 | 1 | Mode 5 + 1 | 1 | 0 | Mode 1 + 1 | 1 | 1 | Mode 1 + ### Mode 1 Radio Push Button diff --git a/network/radio/RadioManagerSample/ReadMe.md b/network/radio/RadioManagerSample/ReadMe.md index 4c481bbd..e62f096c 100644 --- a/network/radio/RadioManagerSample/ReadMe.md +++ b/network/radio/RadioManagerSample/ReadMe.md @@ -1,9 +1,9 @@ Windows Radio Management Sample =============================== -The Radio Manager sample demonstrates how to structure a Radio Manager for use with the Windows 8.1 Radio Management APIs. +The Radio Manager sample demonstrates how to structure a Radio Manager for use with the Windows Radio Management APIs. -Starting with Windows 8.1, the operating system contains a set of APIs which are used as a software mechanism to control the various radios found on the machine. The APIs work by communicating with a Radio Manager, which is a COM object that relays commands from the APIs to turn the radio on or off, and reports back radio information to the APIs. This feature is designed in such a way that a separate Radio Manager is required for each radio media type. For example, a WLAN radio will be controlled by a different Radio Manager than a GPS radio. If there are 2 WLAN radios and a GPS radio, the 2 WLAN radios will be controlled by one Radio Manager, and the GPS radio will be controlled by a different Radio Manager. The Radio Manager must be able to run correctly within Local Service Account context. Under this context, the Radio Manager will have the minimum privilege on the local computer. +The operating system contains a set of APIs which are used as a software mechanism to control the various radios found on the machine. The APIs work by communicating with a Radio Manager, which is a COM object that relays commands from the APIs to turn the radio on or off, and reports back radio information to the APIs. This feature is designed in such a way that a separate Radio Manager is required for each radio media type. For example, a WLAN radio will be controlled by a different Radio Manager than a GPS radio. If there are 2 WLAN radios and a GPS radio, the 2 WLAN radios will be controlled by one Radio Manager, and the GPS radio will be controlled by a different Radio Manager. The Radio Manager must be able to run correctly within Local Service Account context. Under this context, the Radio Manager will have the minimum privilege on the local computer. When the user turns the radio off (either by using the specific radio software switch or the airplane mode switch), radio transmission must be turned off. The device can be powered off as long as the radio switch does not disappear from the UI. It is very important that the radio manager developer ensures that when the device is powered off, the radio switch does not disappear from the UI. If the radio switch disappears from the UI when the radio is turned off by the user, then user has no way to turn the radio back on! If it is desired to conserve power by cutting power to the device when the radio is turned off, but the device cannot be completely powered off because it disappears from the UI, then the solution would be to put the device in a low power state (e.g. D3). @@ -20,84 +20,28 @@ Copy the *install.cmd*, *SampleRM.reg* and *SampleRM.dll* files to a directory. Code Tour --------- -File - -Description - -install.cmd - -Installation script. Copies and registers the dll and executes SampleRM.reg. - -SampleRM.reg - -script to install the Sample Radio Manager into the registry, along with 2 radio instances. - -SampleRM.sln - -The Visual Studio solution file for building the Sample Radio Manager dll. - -sampleRM.idl - -The interface definition for the Sample Radio Manager. - -RadioMgr.idl - -The interface definition for a Windows Radio Manager. - -SampleRadioManager.h - -Header file for the functions required for a Radio Manager. - -SampleRadioInstance.h - -Header file for the functions required for a Radio Instance. - -SampleInstanceCollection.h - -Header file for the functions required for a Collection of Radio Instances. - -precomp.h - -Common header file. - -InternalInterfaces.h - -Header file for internal interface used for this sample. - -dllmain.cpp - -Standard dllmain. - -SampleRadioManager.cpp - -Implementation details for the Sample Radio Manager. Important concepts include: - -- Utilizing [IMediaRadioManagerNotifySink](http://msdn.microsoft.com/en-us/library/windows/hardware/hh406534) for radio instance events -- Adding/Removing radio instances -- Queuing and deploying worker jobs for system events - -SampleRadioInstance.cpp - -Implementation details for the Sample Radio Instance. Important concepts include: - -- Accessors & Modifiers for radio information -- Instance change functions - -SampleInstanceCollection.cpp - -Implementation details for the Sample Instance Collection. Important concepts include:l - -- Radio Instance discovery and retrieval - -RadioMgr\_interface.cpp - -Helper source file to include the MIDL-generated files. +File | Description +-----|----- +install.cmd | Installation script. Copies and registers the dll and executes SampleRM.reg. +SampleRM.reg | Script to install the Sample Radio Manager into the registry, along with 2 radio instances. +SampleRM.sln | The Visual Studio solution file for building the Sample Radio Manager dll. +sampleRM.idl |The interface definition for the Sample Radio Manager. +RadioMgr.idl | The interface definition for a Windows Radio Manager. +SampleRadioManager.h | Header file for the functions required for a Radio Manager. +SampleRadioInstance.h | Header file for the functions required for a Radio Instance. +SampleInstanceCollection.h | Header file for the functions required for a Collection of Radio Instances. +precomp.h | Common header file. +InternalInterfaces.h | Header file for internal interface used for this sample. +dllmain.cpp | Standard dllmain. +SampleRadioManager.cpp | Implementation details for the Sample Radio Manager. Important concepts include utilizing [IMediaRadioManagerNotifySink](http://msdn.microsoft.com/en-us/library/windows/hardware/hh406534) for radio instance events, adding/Removing radio instances, and queuing and deploying worker jobs for system events. +SampleRadioInstance.cpp | Implementation details for the Sample Radio Instance. Important concepts include accessors and modifiers for radio information, and instance change functions. +SampleInstanceCollection.cpp | Implementation details for the Sample Instance Collection. Important concepts include radio instance discovery and retrieval. +RadioMgr\_interface.cpp | Helper source file to include the MIDL-generated files. Run the sample -------------- -Operation ---------- +### Operation ### This sample Radio Manager does not operate on an actual radio. Instead, it uses registry keys to act as virtual radios. @@ -115,22 +59,13 @@ IsAssociatingDevice \*\*\* It is required that the registry key has AT LEAST a Name value, otherwise the Sample Radio Manager will fail to initialize. \*\*\* -**Important** The radio manager must be given a name and the registry key must have, as a minimum, a Name value. Otherwise, the Sample Radio Manager will fail to initialize. This is the name of the radio switch that is displayed to the user in the Wireless page of PC Settings. The name must be simple, yet descriptive of what the radio is. For example, for NFC radios, the value of the name field should be "NFC", and for GPS radios, the value of the name field should be "GPS" or "GNSS", whichever is more appropriate. The name must not include the word "radio" or the manufacturer's name or some other word related to the functionality of the radio (e.g. "Location" OR "port"). +**Important** The radio manager must be given a name and the registry key must have, as a minimum, a Name value. Otherwise, the Sample Radio Manager will fail to initialize. This is the name of the radio switch that is displayed to the user in the Wireless page of PC Settings. The name must be simple, yet descriptive of what the radio is. For example, for NFC radios, the value of the name field should be "NFC", and for GPS radios, the value of the name field should be "GPS" or "GNSS", whichever is more appropriate. The name must not include the word "radio" or the manufacturer's name or some other word related to the functionality of the radio (e.g. "Location" OR "port"). When the Radio Manager is initialized, it uses these registry keys to retrieve the "radio" information. The radio state values can be any of the following enum values: -<table> -<colgroup> -<col width="100%" /> -</colgroup> -<thead> -<tr class="header"> -<th align="left">C++</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td align="left"><pre><code>typedef enum _DEVICE_RADIO_STATE + +```c_cpp +typedef enum _DEVICE_RADIO_STATE { DRS_RADIO_ON = 0, DRS_SW_RADIO_OFF = 1, @@ -140,32 +75,27 @@ When the Radio Manager is initialized, it uses these registry keys to retrieve t DRS_RADIO_INVALID = 5, DRS_HW_RADIO_OFF_UNCONTROLLABLE = 6, DRS_RADIO_MAX = DRS_HW_RADIO_OFF_UNCONTROLLABLE -} DEVICE_RADIO_STATE;</code></pre></td> -</tr> -</tbody> -</table> +} DEVICE_RADIO_STATE; +``` For IsMultiComm and IsAssociatingDevice, a value of 0 means 'no' and 1 means 'yes'. -Adding and Setting a Radio Instance ------------------------------------ +### Adding and Setting a Radio Instance ### To add a new radio instance, add a new instance key to the registry key like the following entry: -``` {.syntax xml:space="preserve"} +``` [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\RadioManagement\Misc\SampleRadioManager\SampleRadioX] "RadioState"=dword:00000000 "Name"="SampleRadioX" "IsMultiComm"=dword:00000000 ``` -Editing a Radio Instance ------------------------- +### Editing a Radio Instance ### Simply change the values in the registry. For example, change the radio state from DRS\_RADIO\_ON to DRS\_SW\_RADIO\_OFF by changing the 'RadioState' value from 0 to 1. -Removing a Radio Instance -------------------------- +### Removing a Radio Instance ### Delete the corresponding registry key. diff --git a/network/trans/inspect/ReadMe.md b/network/trans/inspect/ReadMe.md index ef7fc9e8..4f28598c 100644 --- a/network/trans/inspect/ReadMe.md +++ b/network/trans/inspect/ReadMe.md @@ -5,7 +5,7 @@ This sample driver demonstrates the traffic inspection capabilities of the Windo The sample driver consists of a kernel-mode Windows Filtering Platform (WFP) callout driver (Inspect.sys) that intercepts all transport layer traffic (for example, Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and nonerror Internet Control Message Protocol (ICMP)) sent to or received from a configurable remote peer and queues then to a worker thread for out-of-band processing. -Inspect.sys inspects inbound and outbound connections and all packets that belong to those connections. Additionally, Inspect.sys demonstrates the special considerations that are required to be compatible with Internet Protocol security (IPsec) in Windows Vista and Windows Server 2008. +Inspect.sys inspects inbound and outbound connections and all packets that belong to those connections. Additionally, Inspect.sys demonstrates the special considerations that are required to be compatible with Internet Protocol security (IPsec). Inspect.sys implements the `ClassifyFn` callout functions for the ALE Connect, Recv-Accept, and Transport callouts. In addition, the system worker thread that performs the actual packet inspection is also implemented along with the event mechanisms that are shared between the Classify function and the worker thread. diff --git a/network/trans/msnmntr/ReadMe.md b/network/trans/msnmntr/ReadMe.md index 9f247ff5..9c980db4 100644 --- a/network/trans/msnmntr/ReadMe.md +++ b/network/trans/msnmntr/ReadMe.md @@ -40,7 +40,7 @@ Copy the user-mode application, monitor.exe to a folder on the target computer ( Copy the PDB file, msnmntr.pdb to a folder on the target computer (for example, c:\\Symbols). -Copy the tool TraceView.exe to a folder on the target computer (for example c:\\Tools). TraceView.exe comes with the WDK. You can find it in your WDK installation folder under Tools (for example, c:\\Program Files (x86)\\Windows Kits\\8.1\\Tools\\x64\\TraceView.exe). +Copy the tool TraceView.exe to a folder on the target computer (for example c:\\Tools). TraceView.exe comes with the WDK. You can find it in your WDK installation folder under Tools (for example, c:\\Program Files (x86)\\Windows Kits\\10\\Tools\\x64\\TraceView.exe). Start the msnmntr service ------------------------- @@ -52,7 +52,7 @@ Running the user-mode application On the target computer, open a Command Prompt window as Administrator, and navigate to the folder that contains monitor.exe. Enter **monitor.exe addcallouts**. Then enter **monitor.exe monitor** *TargetAppPath*, where *TargetAppPath* is the path to the application that you want to monitor. Here is an example that initiates monitoring of Internet Explorer. -``` {.syntax xml:space="preserve"} +``` monitor.exe addcallouts monitor.exe monitor "C:\Program Files (x86)\Internet Explorer\iexplore.exe" ``` @@ -71,9 +71,9 @@ Using MSBuild As an alternative to building the WFP MSN Messenger Monitor 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, msnmntr.sln. Use the [MSBuild](http://go.microsoft.com/fwlink/p/?linkID=262804) command to build the solution. Here are some examples: -**msbuild /p:configuration=”Win7 Debug” /p:platform=”x64” msnmntr.sln** +**msbuild /p:configuration="Debug" /p:platform="x64" msnmntr.sln** -**msbuild /p:configuration=”Win8 Release” /p:platform=”win32” msnmntr.sln** +**msbuild /p:configuration="Release" /p:platform="Win32" msnmntr.sln** For more information about using [MSBuild](http://go.microsoft.com/fwlink/p/?linkID=262804) to build a driver package, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644). diff --git a/pofx/UMDF2/ReadMe.md b/pofx/UMDF2/ReadMe.md index e492a3bd..db47b385 100644 --- a/pofx/UMDF2/ReadMe.md +++ b/pofx/UMDF2/ReadMe.md @@ -8,7 +8,7 @@ This sample builds a Universal Windows Driver. It uses only APIs and DDIs that a Related technologies -------------------- -For related information, see the [KMDF Power Framework (PoFx) Sample](http://code.msdn.microsoft.com/windowshardware/PoFx-1974b51c). +For related information, see the [KMDF Power Framework (PoFx) Sample](http://go.microsoft.com/fwlink/p/?LinkId=617937). [User-Mode Driver Framework](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560456) @@ -47,7 +47,7 @@ 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, PoFx.sln. Use the MSBuild command to build the solution. Here is an example: -**msbuild /p:configuration=”Win8 Release” /p:platform=”Win32” PoFx.sln** +**msbuild /p:configuration="Release" /p:platform="Win32" PoFx.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). diff --git a/pofx/WDF/ReadMe.md b/pofx/WDF/ReadMe.md index f351a587..883cc5cd 100644 --- a/pofx/WDF/ReadMe.md +++ b/pofx/WDF/ReadMe.md @@ -55,7 +55,7 @@ The driver can be installed on a root-enumerated device using the devcon.exe too 1. Obtain the devcon.exe tool from the WDK 2. Copy the driver binary, INF file and the KMDF coinstaller to a directory on your test machine. - **Note** Starting in Windows 8.1, the WDK no longer contains the co-installers by default. You can obtain the co-installers by downloading theWdfcoinstaller.msi package from [WDK 8 Redistributable Components](http://go.microsoft.com/fwlink/p/?LinkID=226396). + **Note** The WDK no longer contains the co-installers by default. You can obtain the co-installers by downloading theWdfcoinstaller.msi package from [WDK 8 Redistributable Components](http://go.microsoft.com/fwlink/p/?LinkID=226396). 3. Run the command "devcon.exe install WdfMultiComp.inf WDF\\WdfMultiComp". Testing @@ -68,9 +68,7 @@ Design overview The driver controls a device that has more than one component. It needs to access one of those components for processing each I/O request that it receives. The specific component that it needs to access depends on the I/O request that it receives. -In order to support this, the driver creates one top-level, power-managed queue to receive all its requests. It also creates one secondary, power-managed queue for each of its components. These secondary queues are called component queues. This is shown in the diagram below. - - +In order to support this, the driver creates one top-level, power-managed queue to receive all its requests. It also creates one secondary, power-managed queue for each of its components. These secondary queues are called component queues. When the driver's dispatch routine for the top-level queue is invoked, it examines the request to determine which component it needs to access in order to process the request. Then, it forwards the request to the component queue for the component that it needs to access for that request. When the driver's dispatch routine for the component queue is invoked, it accesses the component hardware to process the request. diff --git a/print/XPSDrvSmpl/ReadMe.md b/print/XPSDrvSmpl/ReadMe.md index 659f442a..bbf1948b 100644 --- a/print/XPSDrvSmpl/ReadMe.md +++ b/print/XPSDrvSmpl/ReadMe.md @@ -3,7 +3,7 @@ XPSDrv Driver and Filter Sample This sample is intended to provide a starting point for developing XPSDrv printer drivers and to illustrate the facility and potential of an XPSDrv print driver. This goal is accomplished by implementing a number of real-world features within a set of XPS print pipeline filters that are configured through a configuration plug-in that supports custom UI content and PrintTicket handling. -Windows Vista introduced a new print architecture and a new document format known as XPS (XML Paper Specification). Part of the new architecture is the XPSDrv print driver, which is designed to provide a flexible, extensible path to manipulate and print an XPS spool file through a series of filters. +Windows includes a print architecture and a document format known as XPS (XML Paper Specification). Part of the new architecture is the XPSDrv print driver, which is designed to provide a flexible, extensible path to manipulate and print an XPS spool file through a series of filters. This sample is intended to provide a starting point for developing XPSDrv printer drivers and to illustrate the facility and potential of an XPSDrv print driver. This goal is accomplished by implementing a number of real-world features within a set of XPS print pipeline filters that are configured through a configuration plug-in that supports custom UI content and PrintTicket handling. @@ -13,41 +13,26 @@ The sample broadly consists of three components: a set of filters, a configurati Build the sample ---------------- -To build a driver solution using Windows 8.1 driver kit (WDK 8.1) and Visual Studio 2013, perform the following steps. +To build a driver solution using Windows Driver Kit (WDK) 10 and Visual Studio 2015, perform the following steps. -1. Open the solution file in Visual Studio 2013 +1. Open the solution file in Visual Studio 2015. +2. Add all non-binary files (usually located in the \\install directory of the sample) to the Package project: + a. In the **Solution Explorer**, right click **Driver Files** + b. Select **Add**, then click **Existing Item** + c. Navigate to the location to which you downloaded the sample, and select all the files in the install directory, or the equivalent set of non-binary files such as INFs, INIs, GPD, PPD files, etc. + d. Click **Add** +3. Configure these files to be added into the driver package: + a. In the **Solution Explorer**, right click on the solution and choose **Add** > **New Project**. Choose **Driver Install Package** under Visual C++/Windows Driver/Package. + b. In the **Solution Explorer**, right click the Package project and select **Properties**. + c. In the left pane, click **Configuration Properties** \> **Driver Install** \> **Package Files**. + d. In the right pane, use the ellipsis button (...) to browse to the set of files that needs to be added to the driver package. All the data files that you added in **Step 2-c**, except the INF file, should be added. This configuration is per-architecture, so this configuration must be repeated for each architecture that will be built. + e. Click **OK**. +4. Open the INF file and edit it to match the built output. + a. Open the INF file. + b. In the Version section, add a reference to a catalog file like this: CatalogFile=XpsDrvSmpl.cat. + c. In the SourceDisksFiles section, change the location of the DLL files you are building, to =1. This indicates that there is no architecture specific directory in this driver. If you ship multiple architectures simultaneously, you will need to collate the driver INF manually. -2. Add all non-binary files (usually located in the \\install directory of the sample) to the Package project - -a. In the **Solution Explorer**, right click **Driver Files** - -b. Select **Add**, then click **Existing Item** - -c. Navigate to the location to which you downloaded the sample, and select all the files in the install directory, or the equivalent set of non-binary files such as INFs, INIs, GPD, PPD files, etc. - -d. Click **Add** - -3. Configure these files to be added into the driver package - -a. In the **Solution Explorer**, right click the Package project and select **Properties** - -b. In the left pane, click **Configuration Properties** \> **Driver Install** \> **Package Files**. - -c. In the right pane, use the ellipsis button (...) to browse to the set of files that needs to be added to the driver package. All the data files that you added in **Step 2-c**, except the INF file, should be added. - -**Note** This configuration is per-architecture, so this configuration must be repeated for each architecture that will be built. - -d. Click **OK** - -4. Open the INF file and edit it to match the built output - -a. Open the INF file - -b. In the Version section, add a reference to a catalog file like this: CatalogFile=XpsDrvSmpl.cat - -c. In the SourceDisksFiles section, change the location of the DLL files you are building, to =1. This indicates that there is no architecture specific directory in this driver. If you ship multiple architectures simultaneously, you will need to collate the driver INF manually. - -At this point, Visual Studio 2013 will be able to build a driver package and output the files to disk. In order to configure driver signing and deployment, see [Developing, Testing, and Deploying Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554651(v=vs.85).aspx). +At this point, Visual Studio 2015 will be able to build a driver package and output the files to disk. In order to configure driver signing and deployment, see [Developing, Testing, and Deploying Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554651(v=vs.85).aspx). **Note** If you compile your sample driver with Microsoft Visual Studio version 10, or 11 with the \_DEBUG flag set, then you should not use CComVariant on the following two XPS Print Filter Pipeline properties: @@ -56,32 +41,18 @@ At this point, Visual Studio 2013 will be able to build a driver package and ou There is a known issue with the current implementation of the Print Filter Pipeline, where the variant type for these two properties is set to VT\_BYREF. And as a result of this known issue, any filter binary that is compiled with the \_DEBUG flag set will experience the ATLASSERT() failure. This is because when you use the CComVariant, its destructor checks the returned value from the Clear() function, as shown: -<table> -<colgroup> -<col width="100%" /> -</colgroup> -<thead> -<tr class="header"> -<th align="left">C++</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td align="left"><pre><code>~CComVariant() throw() + +```c_cpp +~CComVariant() throw() { HRESULT hr = Clear(); ATLASSERT(SUCCEEDED(hr)); (hr); -}</code></pre></td> -</tr> -</tbody> -</table> +} +``` When you compile this sample driver with Visual Studio version 9, you don't experience this problem because the destructor for CComVariant doesn't perform this check on the returned value from the Clear() function. -Run the sample --------------- - Installation ------------ diff --git a/print/XpsRasFilter/ReadMe.md b/print/XpsRasFilter/ReadMe.md index 2dc4fe52..3a88ca71 100644 --- a/print/XpsRasFilter/ReadMe.md +++ b/print/XpsRasFilter/ReadMe.md @@ -1,11 +1,7 @@ XPS Rasterization Filter Service Sample ======================================= -This sample implements an XPSDrv filter that rasterizes fixed pages in an XPS document. Hardware vendors can modify this sample to build an XPSDrv filter that produces bitmap images for their printers or other display devices. The sample uses the XPS Rasterization Service in Windows 7. The sample does not run in versions of Windows before Windows 7. - -This document describes the contents and use of the XPS Rasterization Service Filter sample included in the Windows 7 WDK. This document will serve as a point-of-reference to gather and draft the information required for the MSDN entries to accompany the sample prior to flowing this text and information into the appropriate MSDN format. - -The XPS Rasterization Service creates rasterizer objects for use by XPSDrv filters. A rasterizer object takes an XPS Object Model (XPS OM) page object and creates a bitmap of a specified region of the page. The sample implements an XPSDrv filter (xpsrasfilter.dll) that can be inserted into the XPS Filter Pipeline. For each fixed page in an XPS document, the sample filter does the following: +This sample implements an XPSDrv filter that rasterizes fixed pages in an XPS document. Hardware vendors can modify this sample to build an XPSDrv filter that produces bitmap images for their printers or other display devices. The sample uses the XPS Rasterization Service that creates rasterizer objects for use by XPSDrv filters. A rasterizer object takes an XPS Object Model (XPS OM) page object and creates a bitmap of a specified region of the page. The sample implements an XPSDrv filter (xpsrasfilter.dll) that can be inserted into the XPS Filter Pipeline. For each fixed page in an XPS document, the sample filter does the following: - Uses the XPS rasterization service to create a rasterizer object for the fixed page. - Partitions the fixed page into several horizontal bands. @@ -28,11 +24,3 @@ The default parameters in this sample are as follows: - Scaling is set to FitApplicationBleedSizeToImageableSize. - •Destination resolution set to 96 dpi (can override in print ticket). -**Note** - -To build this sample, you can use Microsoft Visual Studio 2013 (Professional, or Ultimate) and Windows Driver Kit (WDK) 8.1 Update. This sample will not build with Microsoft Visual Studio Express 2013 for Windows Desktop, because the sample uses Active Template Library (ATL). You can get Visual Studio 2013 and WDK 8.1 Update [here](http://go.microsoft.com/fwlink/p/?LInkID=239721). - -You can also build this sample with Visual Studio 2013 (Professional or Ultimate) and [Windows Driver Kit (WDK) 8.1](http://go.microsoft.com/fwlink/p/?LInkID=391348). - -For Windows Driver Kit (WDK) 8 samples, download the [WDK 8 samples pack](%20http://go.microsoft.com/fwlink/?LinkId=317090). The samples in the WDK 8 samples pack will build only with Microsoft Visual Studio Professional 2012 (Professional or Ultimate) and WDK 8. - diff --git a/print/autoconfig/ReadMe.md b/print/autoconfig/ReadMe.md index 21ee2294..821e1897 100644 --- a/print/autoconfig/ReadMe.md +++ b/print/autoconfig/ReadMe.md @@ -19,9 +19,9 @@ 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. -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. +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. -1. Open the solution file in Visual Studio 2015. +1. Open the solution file in Visual Studio 2015. 2. On the **Build** menu, select **Configuration Manager...**. @@ -29,7 +29,7 @@ But to build a signed driver package using Windows Driver Kit (WDK) 10 and Visua **Note** When the driver builds, it will be placed in the output folder for the architecture you selected. -At this point, Visual Studio will be able to build a driver package and output the files to disk. In order to configure driver signing and deployment, see [Developing, Testing, and Deploying Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554651(v=vs.85).aspx). +At this point, Visual Studio will be able to build a driver package and output the files to disk. In order to configure driver signing and deployment, see [Developing, Testing, and Deploying Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554651(v=vs.85).aspx). For more information about how to build a driver solution using Microsoft Visual Studio, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644). diff --git a/print/v4PrintDriverSamples/v4PrintDriver-USBMon-Bidi-Extension/ReadMe.md b/print/v4PrintDriverSamples/v4PrintDriver-USBMon-Bidi-Extension/ReadMe.md index 2b0528d3..753af28b 100644 --- a/print/v4PrintDriverSamples/v4PrintDriver-USBMon-Bidi-Extension/ReadMe.md +++ b/print/v4PrintDriverSamples/v4PrintDriver-USBMon-Bidi-Extension/ReadMe.md @@ -12,33 +12,20 @@ For more information, see [USB Bidi Extender](http://msdn.microsoft.com/en-us/li **Note** This sample is for the v4 print driver model. -**Note** When you make calls to printerStream.read() in the sample, the printer returns an array which includes an additional element that represents the array length. The following code snippet can be used to copy the returned array into a new array, and also to remove the additional element. +**Note** When you make calls to printerStream.read() in the sample, the printer returns an array which includes an additional element that represents the array length. The following JavaScript code can be used to copy the returned array into a new array, and also to remove the additional element. -<table> -<colgroup> -<col width="100%" /> -</colgroup> -<thead> -<tr class="header"> -<th align="left">JavaScript</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td align="left"><pre><code>var readBuffer = []; +``` +var readBuffer = []; var readBytes = 0; var readSize = 4096; readBuffer = printerStream.read( readSize ); readBytes = readBuffer.length; - var cleanArray = []; for ( i = 0; i < readBytes; i++ ) { cleanArray[i] = readBuffer.shift(); -}</code></pre></td> -</tr> -</tbody> -</table> +} +``` diff --git a/security/elam/ReadMe.md b/security/elam/ReadMe.md index 64fa0308..101a5202 100644 --- a/security/elam/ReadMe.md +++ b/security/elam/ReadMe.md @@ -3,11 +3,9 @@ Early Launch Anti-Malware Driver This sample demonstrates how to use the [**IoRegisterBootDriverCallback**](http://msdn.microsoft.com/en-us/library/windows/hardware/hh439379) and [**IoUnRegisterBootDriverCallback**](http://msdn.microsoft.com/en-us/library/windows/hardware/hh439394) DDIs from an Early Launch Anti-Malware driver, to receive notifications about the initialization of regular boot start drivers. -The building and installation instructions given here apply to Windows® 8 and later operating systems. - This sample driver is a minimal driver meant to demonstrate the usage of the APIs mentioned above. It is not intended for use in a production environment. -SIGNING THE SAMPLE +**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. @@ -15,36 +13,37 @@ Early Launch drivers are required to be signed with a code-signing certificate t Run the sample -------------- -INSTALLING THE SAMPLE +**INSTALLING THE SAMPLE** 1. Copy the signed elamsample.sys file to the %WINDIR%\\System32\\Drivers directory on your test machine. 2. Use the sc.exe tool present in Windows to install the driver: -sc create ElamSample binpath=%windir%\\system32\\drivers\\elamsample.sys type=kernel start=boot error=critical group=Early-Launch - + `sc create ElamSample binpath=%windir%\\system32\\drivers\\elamsample.sys type=kernel start=boot error=critical group=Early-Launch` + 3. Enable test signing: -bcdedit /set testsigning on + `bcdedit /set testsigning on` -CODE TOUR +**CODE TOUR** -DriverEntry - Creates a framework driver object and calls IoRegisterBootDriverCallback to register to boot driver status callbacks. +**DriverEntry:** Creates a framework driver object and calls IoRegisterBootDriverCallback to register to boot driver status callbacks. -ElamSampleEvtDriverUnload: Calls IoUnregisterBootDriverCallback to unregister for callbacks when elamsample.sys is about to be unloaded. +**ElamSampleEvtDriverUnload:** Calls IoUnregisterBootDriverCallback to unregister for callbacks when elamsample.sys is about to be unloaded. -ElamSampleBootDriverCallback: Dispatches to other functions to process the specific callback types. +**ElamSampleBootDriverCallback**: Dispatches to other functions to process the specific callback types. -ElamSampleProcessStatusUpdate: Displays callback BdCbStatusUpdate information, such as when dependencies and drivers are about to be initialized, or when the ELAM driver is about to be unload. +**ElamSampleProcessStatusUpdate:** Displays callback BdCbStatusUpdate information, such as when dependencies and drivers are about to be initialized, or when the ELAM driver is about to be unload. -ElamSampleProcessInitializeImage: Displays callback BdCbInitializeImage information, such as the driver image name and the name of the entity that signed the driver. +**ElamSampleProcessInitializeImage:** Displays callback BdCbInitializeImage information, such as the driver image name and the name of the entity that signed the driver. -ElamSamplePrintHex: A utility function to display a buffer in hexadecimal form. +**ElamSamplePrintHex:** A utility function to display a buffer in hexadecimal form. -TESTING +**TESTING** After installing the driver, attach the Kernel Debugger and reboot your test machine. If ELAMSAMPLE\_TRACE\_LEVEL is set to DPFLTR\_ERROR\_LEVEL, traces will be output to the debugger automatically. For example: +``` ElamSample is being initialized. ElamSample reports the following dependency is about to be initialized: ElamSample: @@ -108,4 +107,4 @@ ElamSample: 93 29 d5 f2 e2 7a c9 79 41 b2 6d c0 78 35 2a d3 ElamSample: da 2d 7e 72 f0 05 5f 8b 63 8c 7b a2 6b 37 5c 4f ElamSample reports that all Boot Start drivers have been initialized and that ElamSample is about to be unloaded ElamSample is being unloaded. - +``` diff --git a/serial/serenum/ReadMe.md b/serial/serenum/ReadMe.md index afb6916f..6875e8b7 100644 --- a/serial/serenum/ReadMe.md +++ b/serial/serenum/ReadMe.md @@ -14,26 +14,17 @@ The combined operation of Serial and Serenum provides the function of a Plug and Windows provides Serenum to support Serial and other serial port function drivers that need to enumerate an RS-232 port. Hardware vendors do not have to create their own enumerator for RS-232 ports. For example, a device driver can use Serenum to enumerate the devices that are attached to the individual RS-232 ports on a multiport device. -<table> -<colgroup> -<col width="50%" /> -<col width="50%" /> -</colgroup> -<thead> -<tr class="header"> -<th align="left">File manifest -Description</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td align="left">Enum.c -Functions that enumerate external serial devices—the main purpose of this driver</td> -<td align="left">Pnp.c -Plug and Play support code</td> -</tr> -</tbody> -</table> +### File Manifest + +File | Description +-----|------------ +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 +Serenum.h | Local header with defines, prototypes +String.c | String handling support; mainly ASCII to UNICODE functionality +Serenum.rc | Resource script For more information, see [Features of Serial and Serenum](http://msdn.microsoft.com/en-us/library/windows/hardware/ff546505). diff --git a/serial/serial/ReadMe.md b/serial/serial/ReadMe.md index 7fe112cf..de76bfb3 100644 --- a/serial/serial/ReadMe.md +++ b/serial/serial/ReadMe.md @@ -24,7 +24,7 @@ This sample can be used for these hardware IDs without any modification to the . If you have other hardware such as an add-in card, then you must add the hardware ID in the .inx as shown in this example. Then, you must build the project as per the instructions given in the Building the sample section in this readme. - ``` {.syntax xml:space="preserve"} + ``` ; For XP and later [MSFT.NTamd64] ; DisplayName Section DeviceId diff --git a/setup/devcon/ReadMe.md b/setup/devcon/ReadMe.md index fbea8dca..8a7d70ca 100644 --- a/setup/devcon/ReadMe.md +++ b/setup/devcon/ReadMe.md @@ -12,22 +12,22 @@ Download and extract the sample Download the C++ sample from this page, and extract its contents. For example, you could extract to c:\\DevConSample. -Starting in the Visual Studio 2013 WDK, you can build the sample in two ways: using the Visual Studio Integrated Development Environment (IDE) or from the command line using the Visual Studio Command Prompt window and the Microsoft Build Engine (MSBuild.exe). +You can build the sample in two ways: using the Visual Studio Integrated Development Environment (IDE) or from the command line using the Visual Studio Command Prompt window and the Microsoft Build Engine (MSBuild.exe). **Building the sample using Visual Studio** 1. Open Visual Studio. From the **File** menu, select **Open Project/Solution**. Within your WDK installation, navigate to the folder where you extracted DevCon. For example c:\\DevConSample\\C++ and open the devcon.sln project file. 2. Right-click the solution in the **Solution Explorer** and select **Configuration Manager**. -3. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Windows 8.1 Debug or Windows 8.1 Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. +3. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Debug or Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. 4. From the **Build** menu, click **Build Solution** (Ctrl+Shift+B). -Previous versions of the WDK used the Windows Build utility (Build.exe) and provided separate build environment windows for each of the supported build configurations. Starting in the Visual Studio 2013 WDK, you can use the Visual Studio Command Prompt window for all build configurations. +Previous versions of the WDK used the Windows Build utility (Build.exe) and provided separate build environment windows for each of the supported build configurations. You can use the Visual Studio Command Prompt window for all build configurations. **Building the sample using the command line (MSBuild)** 1. Open a Visual Studio Command Prompt window. Click **Start** and search for **Developer Command Prompt**. If your project is under %PROGRAMFILES%, you need to open the command prompt window using elevated permissions (**Run as administrator**). From this window you can use MsBuild.exe to build any Visual Studio project by specifying the project (.VcxProj) or solutions (.Sln) file. 2. Navigate to the project directory and enter the **MSbuild** command for your target. For example, to perform a clean build of a Visual Studio driver project called devcon.vcxproj, navigate to the project directory and enter the following MSBuild command: **msbuild /t:clean /t:build .\\devcon.vcxproj**. -3. If the build succeeds, you will find the tools (devcon.exe) in the binary output directory corresponding to the target platform, for example samples\\setup\\devcon\\Windows 8.1 Debug. +3. If the build succeeds, you will find the tools (devcon.exe) in the binary output directory corresponding to the target platform, for example samples\\setup\\devcon\\Debug. Run the sample -------------- diff --git a/smartcrd/ReadMe.md b/smartcrd/ReadMe.md index b623b669..a4c9f9fa 100644 --- a/smartcrd/ReadMe.md +++ b/smartcrd/ReadMe.md @@ -12,10 +12,20 @@ Power Management is described in detail in the WDK documentation. There is, howe A card reader will not see any card insertion or removal events in these modes, because the bus might not even have power. The card state must be saved before the reader goes into standby or hibernation mode. After the system returns from these modes, it is necessary to determine what the state of the card is. Card tracking calls must complete whenever there was a card in the reader before standby or hibernation mode or whenever there is a card in the reader after these modes. This step is necessary because the user could have changed the card while the system was in a low-power mode. +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). + +**Note** You can obtain the co-installers by downloading the *wdfcoinstaller.msi* package from [WDK 8 Redistributable Components](http://go.microsoft.com/fwlink/p/?LinkID=226396). + +Run the sample +-------------- + Installation ------------ -The PSCR.SYS driver is included in-box in Windows or, starting with Windows 8.1, available from Windows Update. Therefore, when the SCM 488 PCMCIA reader is inserted, the system will automatically install the driver. However, if you want to customize the source code of this driver and replace the in-box driver or the driver from Windows Update with your driver, use the supplied INF file. +The PSCR.SYS driver is available from Windows Update. Therefore, when the SCM 488 PCMCIA reader is inserted, the system will automatically install the driver. However, if you want to customize the source code of this driver and replace the driver from Windows Update with your driver, use the supplied INF file. Tools ----- diff --git a/spb/SpbTestTool/ReadMe.md b/spb/SpbTestTool/ReadMe.md index 21a7bf49..ec6a1c2a 100644 --- a/spb/SpbTestTool/ReadMe.md +++ b/spb/SpbTestTool/ReadMe.md @@ -5,8 +5,7 @@ The SpbTestTool sample serves two purposes. First, it demonstrates how to open a This sample is incomplete as a driver and merely demonstrates use of the [SPB I/O request interface](http://msdn.microsoft.com/en-us/library/windows/hardware/hh698224) and [GPIO interrupts](http://msdn.microsoft.com/en-us/library/windows/hardware/hh406467). It is not intended for use in a production environment. -Run the sample --------------- +### Run the sample To install the SpbTestTool peripheral driver, follow these steps: @@ -34,170 +33,80 @@ To launch the SpbTestTool application, follow these steps: `SpbTestTool.exe /i <script.txt>` -Executing commands ------------------- +### Executing commands The SpbTestTool application loops indefinitely waiting for one of the following commands. The commands are translated to the appropriate SPB I/O request without any state tracking in the driver. Transfer status, buffer contents, and error codes are returned as necessary. Type `help` at any time to display this command list. Press Ctrl-C at any time to cancel the current command and exit the application. -Command +Command | Description +--------|------------ +open | Open handle to SPB controller. +close | Close handle to SPB controller. +lock | Lock the bus for exclusive access. +unlock | Unlock the bus. +lockconn | Lock the shared connection for exclusive access. This command is used to synchronize bus transfers by the sample driver with op-region accesses by the ACPI firmware. +unlockconn | Unlock the shared connection. +write {} | Write a byte array to the peripheral device. Example: `> write {01, 02, 03}` +read <*numBytes*> | Read <*numBytes*> from the peripheral device. Example: `> read 5` +writeread {} <*numBytes*> | Atomically write a byte array to the peripheral device and read <*numBytes*> back. Example: `> writeread {01, 02, 03} 5` +signal | Inform the SpbTestTool driver that the interrupt has been handled. +help | Display the list of supported commands. +Ctrl-C | Press Ctrl-C at any time to cancel the outstanding command and exit the application. -Description - -*open* - -Open handle to SPB controller. - -*close* - -Close handle to SPB controller. - -*lock* - -Lock the bus for exclusive access. - -*unlock* - -Unlock the bus. - -*lockconn* - -Lock the shared connection for exclusive access. This command is used to synchronize bus transfers by the sample driver with op-region accesses by the ACPI firmware. - -*unlockconn* - -Unlock the shared connection. - -*write {}* - -Write a byte array to the peripheral device. - -Example: `> write {01, 02, 03}` - -*read \<numBytes\>* - -Read \<numBytes\> from the peripheral device. - -Example: `> read 5` - -*writeread {} \<numBytes\>* - -Atomically write a byte array to the peripheral device and read \<numBytes\> back. - -Example: `> writeread {01, 02, 03} 5` - -*signal* - -Inform the SpbTestTool driver that the interrupt has been handled. - -*help* - -Display the list of supported commands. - -*Ctrl-C* - -Press Ctrl-C at any time to cancel the outstanding command and exit the application. - -Code tour ---------- +### Code tour The following are the relevant functions in the SpbTestTool peripheral driver for using the SPB interface from a KMDF driver. -<table> -<colgroup> -<col width="50%" /> -<col width="50%" /> -</colgroup> -<thead> -<tr class="header"> -<th align="left">Function -Description</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td align="left"><p><code>OnPrepareHardware</code></p> -<p>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.</p></td> -<td align="left"><p><code>SpbPeripheralOpen</code></p> -<p>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.</p></td> -</tr> -</tbody> -</table> +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. +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. +SpbPeripheralUnlock | Sends IOCTL_SPB_UNLOCK_CONTROLLER to the SPB controller to unlock the bus from exclusive access by this peripheral. +SpbPeripheralLockConnection | Sends IOCTL_SPB_LOCK_CONNECTION to the SPB controller to lock the shared connection for exclusive access by this target (file handle). +SpbPeripheralUnlockConnection | Sends IOCTL_SPB_UNLOCK_CONNECTION to the SPB controller to unlock the shared connection from exclusive access by this target (file handle). +SpbPeripheralRead | Sends a read request to the SPB controller. +SpbPeripheralWrite | Sends a write request to the SPB controller. +SpbPeripheralWriteRead | Builds a write-read sequence and sends IOCTL_SPB_EXECUTE_SEQUENCE to the SPB controller. +SpbPeripheralOnComplete | Completion callback for all I/O requests. The following are the relevant functions in the SpbTestTool peripheral driver for managing GPIO passive-level interrupts from a KMDF driver. -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. - -`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. - -`SpbPeripheralSignalInterrupt` - -Notifies the interrupt service routine that the interrupt has been handled and the ISR should return. +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. +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. +SpbPeripheralSignalInterrupt | Notifies the interrupt service routine that the interrupt has been handled and the ISR should return. -File manifest -------------- +### 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. -<table> -<colgroup> -<col width="50%" /> -<col width="50%" /> -</colgroup> -<thead> -<tr class="header"> -<th align="left">File -Description</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td align="left"><p>driver.h, driver.cpp</p> -<p>Events on the Device Object, and read, write, and IOCTLs from the SpbTestTool application. Implements the driver’s interrupt service routine.</p></td> -<td align="left"><p>internal.h</p> -<p>Common includes and typedefs</p></td> -</tr> -</tbody> -</table> +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. +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. +resource.rc | Resource descriptor file used for versioning +sources | Lists source files and build options. +sources.dep | Defines build dependencies. +spbtesttool.asl | Sample ASL file for a peripheral device node. It declares I2C and GPIO interrupt resources. Note each macro specifies an ACPI path to describe direct dependencies. +spbtesttool.h | Private SpbTestTool IOCTLs for use between the application and peripheral driver, and driver path names. +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. -<table> -<colgroup> -<col width="50%" /> -<col width="50%" /> -</colgroup> -<thead> -<tr class="header"> -<th align="left">File -Description</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td align="left"><p>command.h, command.cpp</p> -<p>Classes respresenting each of the SpbTestTool commands. For the list of commands, see <a href="#executing_commands">Executing commands</a>.</p></td> -<td align="left"><p>internal.h</p> -<p>Common includes and function definitions</p></td> -</tr> -</tbody> -</table> +File | Description +-----|------------ +command.h, command.cpp | Classes respresenting each of the SpbTestTool commands. For the list of commands, see Executing commands. +internal.h | Common includes and function definitions +main.cpp | Application entry point, input parsing, and main execution loop. Also contains the interrupt notification thread. +makefile | Redirects to the real makefile that is shared by all components of the WDK. +sources | Lists source files and build options. +util.cpp | Helper functions diff --git a/storage/class/cdrom/ReadMe.md b/storage/class/cdrom/ReadMe.md index fbdc3b53..187ca63b 100644 --- a/storage/class/cdrom/ReadMe.md +++ b/storage/class/cdrom/ReadMe.md @@ -7,7 +7,7 @@ Build the sample ---------------- You can build the sample in two ways: using Microsoft Visual Studio or the command line (*MSBuild*). -*Note:* When building in Visual Studio, INFVerifer will throw errors. This is intended. Fix those errors with your custom values to build successfully. +**Note:** When building in Visual Studio, INFVerifer will throw errors. This is intended. Fix those errors with your custom values to build successfully. Building a Driver Using Visual Studio ------------------------------------- @@ -20,7 +20,7 @@ The default Solution build configuration is Visual Studio Debug and Win32. 1. Open the driver project or solution in Visual Studio (find *samplename*.sln or *samplename*.vcxproj). 2. Right-click the solution in the **Solutions Explorer** and select **Configuration Manager**. -3. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Windows 8.1 Debug or Windows 8.1 Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. +3. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Debug or Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. 4. From the Build menu, click **Build Solution** (Ctrl+Shift+B). Building a Driver Using the Command Line (MSBuild) diff --git a/storage/class/disk/ReadMe.md b/storage/class/disk/ReadMe.md index 4945350a..1acd4ed5 100644 --- a/storage/class/disk/ReadMe.md +++ b/storage/class/disk/ReadMe.md @@ -13,13 +13,13 @@ Building a Driver Using Visual Studio You build a driver the same way you build any project or solution in Visual Studio. When you create a new driver project using a Windows driver template, the template defines a default (active) project configuration and a default (active) solution build configuration. When you create a project from existing driver sources or convert existing driver code that was built with previous versions of the WDK, the conversion process preserves the target version information (operating systems and platform). -The default Solution build configuration is Windows 8.1 Debug and Win32. +The default Solution build configuration is Debug and Win32. ### To select a configuration and build a driver or an application 1. Open the driver project or solution in Visual Studio (find *samplename*.sln or *samplename*.vcxproj). 2. Right-click the solution in the **Solutions Explorer** and select **Configuration Manager**. -3. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Windows 8.1 Debug or Windows 8.1 Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. +3. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Debug or Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. 4. From the Build menu, click **Build Solution** (Ctrl+Shift+B). Building a Driver Using the Command Line (MSBuild) diff --git a/storage/ramdisk/ReadMe.md b/storage/ramdisk/ReadMe.md index f1278157..1ef67580 100644 --- a/storage/ramdisk/ReadMe.md +++ b/storage/ramdisk/ReadMe.md @@ -3,102 +3,33 @@ RAMDisk Storage Driver Sample The RAMDisk storage driver sample demonstrates how to write a software only function driver using the Kernel Mode Driver Framework (KMDF). This driver creates a RAM disk drive.The RAM disk can be used like any other disk, but the contents of the disk will be lost when the computer is shut down. -**Note** - -To build this sample, you can use Microsoft Visual Studio 2013 (Express, Professional, or Ultimate) and Windows Driver Kit (WDK) 8.1 Update. You can get Visual Studio 2013 and WDK 8.1 Update [here](http://go.microsoft.com/fwlink/p/?LInkID=239721). - -You can also build this sample with Visual Studio 2013 (Professional or Ultimate) and [Windows Driver Kit (WDK) 8.1](http://go.microsoft.com/fwlink/p/?LInkID=391348). - -For Windows Driver Kit (WDK) 8 samples, download the [WDK 8 samples pack](%20http://go.microsoft.com/fwlink/?LinkId=317090). The samples in the WDK 8 samples pack will build only with Microsoft Visual Studio Professional 2012 (Professional or Ultimate) and WDK 8. - -Operating system requirements ------------------------------ - -Client - -Windows 7 - -Server - -Windows Server 2008 R2 - Build the sample ---------------- -Download and extract the sample -------------------------------- - -Click the download button on this page. Click **Save**, and then click **Open Folder**. Right click ramdisk.zip, and choose **Extract All**. Specify or browse to a folder for the extracted files. For example, you could extract to c:\\RamDiskStorageDriver. - -Open the driver solution in Visual Studio ------------------------------------------ +### Open the driver solution in Visual Studio ### Navigate to the folder that has the extracted sample. Double click the solution file, ramdisk.sln. In Microsoft Visual Studio, locate Solution Explorer. (If this is not already open, choose **Solution Explorer** from the **View** menu.) In Solution Explorer, you can see one solution that has two projects. There is a driver project named **WdfRamdisk** 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 ‘ramdisk’ (2 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. Here are some examples of configuration and platform settings. -<table> -<colgroup> -<col width="33%" /> -<col width="33%" /> -<col width="33%" /> -</colgroup> -<thead> -<tr class="header"> -<th align="left">Configuration -Platform -Description</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td align="left">Win8.1 Debug -x64 -The driver will run on an x64 hardware platform that is running Windows 8.1. The driver will not run on any earlier versions of Windows.</td> -<td align="left">Win7 Debug -x64 -The driver will run on an x64 hardware platform that is running Windows 7 or a later version of Windows.</td> -</tr> -</tbody> -</table> - -Build the sample using Visual Studio ------------------------------------- +### Build the sample using Visual Studio ### In Visual Studio, on the **Build** menu, choose **Build Solution**. For more information about using Visual Studio to build a driver package, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644). -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. For example, if your settings are Win7 Debug and x64, the package is your solution folder under x64\\Win7Debug\\Package. +### Locate the built driver package ### -The package contains these files: +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. The package contains these files: -<table> -<colgroup> -<col width="50%" /> -<col width="50%" /> -</colgroup> -<thead> -<tr class="header"> -<th align="left">File -Description</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td align="left">Kmdfsamples.cat -A signed catalog file, which serves as the signature for the entire package.</td> -<td align="left">Ramdisk.inf -An information (INF) file that contains information needed to install the driver.</td> -</tr> -</tbody> -</table> +File | Description +-----| ----------- +Kmdfsamples.cat | A signed catalog file, which serves as the signature for the entire package. +Ramdisk.inf | An information (INF) file that contains information needed to install the driver. +WdfCoinstaller010xx.dll | The coinstaller for version 1.xx of KMDF. +WdfRamdisk.sys | The driver file. Run the sample -------------- @@ -107,8 +38,7 @@ The computer where you install the driver is called the *target computer* or the The process of moving the driver package to the target computer and installing the driver is called *deploying the driver*. You can deploy RAMDisk sample driver automatically or manually. -Automatic deployment --------------------- +###Automatic deployment ### 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/). @@ -116,8 +46,7 @@ Before you automatically deploy a driver, you must provision the target computer 2. 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 **Ramdisk** for the hardware ID. Click **OK**. 3. On the **Build** menu, choose **Deploy Package** or **Build Solution**. -Manual deployment ------------------ +### Manual 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](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](http://msdn.microsoft.com/en-us/library/windows/hardware/dn265571). @@ -126,20 +55,18 @@ Before you manually deploy a driver, you must turn on test signing and install a **Devcon install ramdisk.inf Ramdisk** -View the installed driver in Device Manager -------------------------------------------- +### View the installed driver in Device Manager ### On the target computer, in a Command Prompt window, enter **devmgmt** to open Device Manager. In Device Manager, on the **View** menu, choose **Devices by type**. In the device tree, locate **WDF Sample RAM disk Driver** (for example, this might be under the **Sample Device** node). The RAM disk sample is a root enumerated software driver. To see this in Device Manager, choose **Devices by connection** from the **View** menu. Locate **WDF Sample RAM disk Driver** as a child of the root node of the device tree. -Save a file on the RAM disk ---------------------------- +### Save a file on the RAM disk ### On the target computer, open a Command Prompt window as Administrator. Enter **R:** to switch to the RAM disk drive. In your Command Prompt window, enter **notepad** to open Notepad. Type some text in your notepad document, and then save the document on the R drive. In your Command Prompt window, enter **dir** to verify that the file was saved. -View Ramdisk entries in the Registry ------------------------------------- +### View Ramdisk entries in the Registry ### + The INF file in the RAM disk driver package specifies parameters that get saved in the registry. On the target computer, open the registry editor (Regedit.exe). In the registry editor, locate the Parameters key for the Ramdisk service. For example, @@ -147,42 +74,20 @@ The INF file in the RAM disk driver package specifies parameters that get saved The registry key has these entries: -<table> -<colgroup> -<col width="33%" /> -<col width="33%" /> -<col width="33%" /> -</colgroup> -<thead> -<tr class="header"> -<th align="left">Parameter -Value -Description</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td align="left">DiskSize -0x100000 -The size, in bytes, of the RAM disk drive.</td> -<td align="left">DriveLetter -R: -The driver letter associated with the RAM disk drive.</td> -<td align="left">RootDirEntries -0x200 -The number of entries in the root directory.</td> -</tr> -</tbody> -</table> +Parameter | Value | Description +----------------|---------|------------ +DiskSize |0x100000 |The size, in bytes, of the RAM disk drive. +DriveLetter |R: |The driver letter associated with the RAM disk drive. +RootDirEntries |0x200 |The number of entries in the root directory.</td> Using MSBuild ------------- As an alternative to building the RAMDisk Storage 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, ramdisk.sln. Use the [MSBuild](http://go.microsoft.com/fwlink/p/?linkID=262804) command to build the solution. Here are some examples: -**msbuild /p:configuration=”Win7 Debug” /p:platform=”x64” ramdisk.sln** +**msbuild /p:configuration="Debug" /p:platform="x64" ramdisk.sln** -**msbuild /p:configuration=”Win8 Release” /p:platform=”win32” ramdisk.sln** +**msbuild /p:configuration="Release" /p:platform="Win32" ramdisk.sln** For more information about using [MSBuild](http://go.microsoft.com/fwlink/p/?linkID=262804) to build a driver package, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644). diff --git a/thermal/thermalclient/ReadMe.md b/thermal/thermalclient/ReadMe.md index 4ebcb51f..47f8a2f6 100644 --- a/thermal/thermalclient/ReadMe.md +++ b/thermal/thermalclient/ReadMe.md @@ -1,7 +1,7 @@ SimThermalClient: Simulated Thermal Client Sample Driver ======================================================== -This sample is a driver for a simulated device that is a client of Windows thermal management. This driver publishes a [GUID\_THERMAL\_COOLING\_INTERFACE](http://msdn.microsoft.com/en-us/library/windows/hardware/hh698265) driver interface. Support for this interface is available starting with Windows 8.1. Drivers publish this interface so that they can participate in global thermal management under the coordination of the Windows operating system. +This sample is a driver for a simulated device that is a client of Windows thermal management. This driver publishes a [GUID\_THERMAL\_COOLING\_INTERFACE](http://msdn.microsoft.com/en-us/library/windows/hardware/hh698265) driver interface. Drivers publish this interface so that they can participate in global thermal management under the coordination of the Windows operating system. ## Universal Windows Driver Compliant This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. diff --git a/usb/kmdf_enumswitches/ReadMe.md b/usb/kmdf_enumswitches/ReadMe.md index 2107d9b8..d6a7ee9f 100644 --- a/usb/kmdf_enumswitches/ReadMe.md +++ b/usb/kmdf_enumswitches/ReadMe.md @@ -17,7 +17,7 @@ To test the device, follow these steps: 5. Flip the switches on the OSR USB-FX-2 hardware board and watch the raw PDO entries appear and disappear under **Sample Device** in Device Manager. 6. Right-click a raw PDO entry, select **Properties**, and then click the **Events** tab. Under **Information**, examine the hardware ID for the PDO. It should be something like this: - ``` {.syntax xml:space="preserve"} + ``` 6FDE7521-1B65-48ae-B628-80BE62016026}\OsrUsbFxRawPdo\6&227995e2&0&08 ``` diff --git a/usb/umdf2_fx2/ReadMe.md b/usb/umdf2_fx2/ReadMe.md index 291e91cb..8e7e8db1 100644 --- a/usb/umdf2_fx2/ReadMe.md +++ b/usb/umdf2_fx2/ReadMe.md @@ -1,74 +1,323 @@ -Sample Function Driver for OSR USB-FX2 (UMDF Version 2) -======================================================= +Sample UMDF Function Driver for OSR USB-FX2 (UMDF Version 1) +============================================================ -The umdf2\_fx2 sample is a User-Mode Driver Framework (UMDF) version 2 driver for the OSR USB-FX2 device. - -The specification for the device is at <http://www.osronline.com/hardware/OSRFX2_32.pdf>. The driver and sample device metadata also work with the [Custom driver access](http://go.microsoft.com/fwlink/p/?LinkID=248288) sample. +The umdf\_fx2 sample is a User-Mode Driver Framework (UMDF) driver for the OSR USB-FX2 device. It includes a test app and sample device metadata, and supports impersonation and idle power down. ## Universal Windows Driver Compliant This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. -Set the configuration and platform in Visual Studio ---------------------------------------------------- +The sample can also be used with the CustomDeviceAccess MSDK sample. The sample demonstrates how to perform bulk and interrupt data transfers to an USB device. The specification for the device is at <http://www.osronline.com/hardware/OSRFX2_32.pdf>. The driver and sample device metadata also work with the [Custom driver access](http://go.microsoft.com/fwlink/p/?LinkID=248288) sample. + +The osrusbfx2 sample is divided into three samples: +* **WDF Sample Driver Learning Lab for OSR USB-FX2**: This sample is a series of iterative drivers that demonstrate how to write a "Hello World" driver and adds additional features in each step. +* **kmdf\_fx2**: This sample is the final version of kernel-mode wdf\_osrfx2 driver. The sample demonstrates KMDF methods. +* **umdf\_fx2**: This sample is the final version of the user-mode driver **wdf\_osrfx2**. The sample demonstrates UMDF methods. + +Overview +-------- + +Here is the overview of the device: + +- The device is based on the development board supplied with the Cypress EZ-USB FX2 Development Kit (CY3681). +- It contains 1 interface and 3 endpoints (Interrupt IN, Bulk Out, Bulk IN). +- Firmware supports vendor commands to query or set LED Bar graph display and 7-segment LED display, and to query toggle switch states. +- Interrupt Endpoint: + - Sends an 8-bit value that represents the state of the switches. + - Sent on startup, resume from suspend, and whenever the switch pack setting changes. + - Firmware does not de-bounce the switch pack. + - One switch change can result in multiple bytes being sent. + - Bits are in the reverse order of the labels on the pack (for example, bit 0x80 is labeled 1 on the pack). +- Bulk Endpoints are configured for loopback: + - The device moves data from IN endpoint to OUT endpoint. + - The device does not change the values of the data it receives nor does it internally create any data. + - Endpoints are always double buffered. + - Maximum packet size depends on speed (64 full speed, 512 high speed). + +Testing the driver +------------------ + +You can use the [Custom driver access](http://go.microsoft.com/fwlink/p/?LinkID=248288) sample to test the umdf\_fx2 sample. + +This sample also includes a test application, osrusbfx2.exe, that you can use to test the device. This console application enumerates the interface registered by the driver and opens the device to send read, write, or IOCTL requests based on the command line options. + +Usage for Read/Write test: + +- -r [*n*], where *n* is number of bytes to read. +- -w [*n*], where *n* is number of bytes to write. +- -c [*n*], where *n* is number of iterations (default = 1). +- -v, shows verbose read data. +- -p, plays with Bar Display, Dip Switch, 7-Segment Display. +- -a, performs asynchronous I/O operation. +- -u, dumps USB configuration and pipe information. +- -f \<*filename*\> [*interval-seconds*], where *interval-seconds* is a delay in milliseconds, to send a text file to the seven-segment display (UMDF only) + +**Playing with the 7 segment display, toggle switches, and bar graph display** + +Use the command **osrusbfx2.exe -p** with options 1 through 9 to set and clear bar graph display, set and get 7 segment state, and read the toggle switch states. The following shows the function options: + +1. Light Bar +2. Clear Bar +3. Light entire Bar graph +4. Clear entire Bar graph +5. Get bar graph state +6. Get Switch state +7. Get Switch Interrupt Message +8. Get 7 segment state +9. Set 7 segment state +10. Reset the device +11. Re-enumerate the device + +0. Exit + +Selection: + +**Reset and re-enumerate the device** + +Use the command **osrusbfx2.exe -p** with options 10 and 11 to either reset the device or re-enumerate the device. + +**Read and write to bulk endpoints** + +The following commands send read and write requests to the device's bulk endpoint. + +- `osrusbfx2.exe -r 64` + + The preceding command reads 64 bytes to the bulk IN endpoint. + +- `osrusbfx2.exe -w 64 ` + + The preceding command writes 64 bytes to the bulk OUT endpoint. + +- `osrusbfx2.exe -r 64 -w 64 -c 100 -v` + + The preceding command first writes 64 bytes of data to bulk OUT endpoint (Pipe 1), then reads 64 bytes from bulk IN endpoint (Pipe 2), and then compares the read buffer with write buffer to see if they match. If the buffer contents match, it repeats this operation 100 times. + +- `osrusbfx2.exe -a` + + The preceding command reads and writes to the device asynchronously in an infinite loop. + +The bulk endpoints are double buffered. Depending on the operational speed (full or high), the buffer size is either 64 bytes or 512 bytes, respectively. A request to read data does not complete if the buffers are empty. If the buffers are full, a request to write data does not complete until the buffers are emptied. When you are doing a synchronous read, make sure the endpoint buffer has data (for example, when you send 512 bytes write request to the device operating in full speed mode). Because the endpoints are double buffered, the total buffer capacity is 256 bytes. The first 256 bytes fills the buffer and the write request waits in the USB stack until the buffers are emptied. If you run another instance of the application to read 512 bytes of data, both write and read requests complete successfully. + +**Displaying descriptors** + +The following command displays all the descriptors and endpoint information. + +**osrusbfx2.exe -u** + +If the device is operating in high speed mode, you get the following information: + +`===================` + +`USB_CONFIGURATION_DESCRIPTOR` + +`bLength = 0x9, decimal 9` + +`bDescriptorType = 0x2 ( USB_CONFIGURATION_DESCRIPTOR_TYPE )` + +`wTotalLength = 0x27, decimal 39` + +`bNumInterfaces = 0x1, decimal 1` + +`bConfigurationValue = 0x1, decimal 1` + +`iConfiguration = 0x4, decimal 4` + +`bmAttributes = 0xa0 ( USB_CONFIG_BUS_POWERED )` + +`MaxPower = 0x32, decimal 50` + +`-----------------------------` + +`USB_INTERFACE_DESCRIPTOR #0` + +`bLength = 0x9` + +`bDescriptorType = 0x4 ( USB_INTERFACE_DESCRIPTOR_TYPE )` + +`bInterfaceNumber = 0x0` + +`bAlternateSetting = 0x0` + +`bNumEndpoints = 0x3` + +`bInterfaceClass = 0xff` + +`bInterfaceSubClass = 0x0` + +`bInterfaceProtocol = 0x0` + +`bInterface = 0x0` + +`------------------------------` + +`USB_ENDPOINT_DESCRIPTOR for Pipe00` + +`bLength = 0x7` + +`bDescriptorType = 0x5 ( USB_ENDPOINT_DESCRIPTOR_TYPE )` + +`bEndpointAddress= 0x81 ( INPUT )` + +`bmAttributes= 0x3 ( USB_ENDPOINT_TYPE_INTERRUPT )` + +`wMaxPacketSize= 0x49, decimal 73` + +`bInterval = 0x1, decimal 1` + +`------------------------------` + +`USB_ENDPOINT_DESCRIPTOR for Pipe01` + +`bLength = 0x7` + +`bDescriptorType = 0x5 ( USB_ENDPOINT_DESCRIPTOR_TYPE )` + +`bEndpointAddress= 0x6 ( OUTPUT )` + +`bmAttributes= 0x2 ( USB_ENDPOINT_TYPE_BULK )` + +`wMaxPacketSize= 0x200, ` + +`decimal 512 bInterval = 0x0, ` + +`decimal 0` + +`------------------------------` + +`USB_ENDPOINT_DESCRIPTOR for Pipe02` + +`bLength = 0x7` + +`bDescriptorType = 0x5 ( USB_ENDPOINT_DESCRIPTOR_TYPE )` + +`bEndpointAddress= 0x88 ( INPUT )` + +`bmAttributes= 0x2 ( USB_ENDPOINT_TYPE_BULK )` + +`wMaxPacketSize= 0x200, decimal 512` + +`bInterval = 0x0, decimal 0` + +If the device is operating in low speed mode, you will get the following information: + +`===================` + +`USB_CONFIGURATION_DESCRIPTOR` + +`bLength = 0x9, decimal 9` + +`bDescriptorType = 0x2 ( USB_CONFIGURATION_DESCRIPTOR_TYPE )` + +`wTotalLength = 0x27, decimal 39` + +`bNumInterfaces = 0x1, decimal 1` + +`bConfigurationValue = 0x1, decimal 1` + +`iConfiguration = 0x3, decimal 3` + +`bmAttributes = 0xa0 ( USB_CONFIG_BUS_POWERED )` + +`MaxPower = 0x32, decimal 50 ` + +`-----------------------------` + +`USB_INTERFACE_DESCRIPTOR #0` + +`bLength = 0x9` + +`bDescriptorType = 0x4 ( USB_INTERFACE_DESCRIPTOR_TYPE )` + +`bInterfaceNumber = 0x0 bAlternateSetting = 0x0` + +`bNumEndpoints = 0x3` + +`bInterfaceClass = 0xff` + +`bInterfaceSubClass = 0x0` + +`bInterfaceProtocol = 0x0` + +`bInterface = 0x0` + +`------------------------------` + +`USB_ENDPOINT_DESCRIPTOR for Pipe00` + +`bLength = 0x7` + +`bDescriptorType = 0x5 ( USB_ENDPOINT_DESCRIPTOR_TYPE )` + +`bEndpointAddress= 0x81 ( INPUT )` + +`bmAttributes= 0x3 ( USB_ENDPOINT_TYPE_INTERRUPT )` + +`wMaxPacketSize= 0x49, decimal 73` + +`bInterval = 0x1, decimal 1` -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. Because this solution uses UMDF version 2, you cannot select a configuration earlier than Windows 8.1. +`------- -----------------------` -Build the sample using Visual Studio ------------------------------------- +`USB_ENDPOINT_DESCRIPTOR for Pipe01` -In Visual Studio, on the **Build** menu, choose **Build Solution**. +`bLength = 0x7` -For more information about using Visual Studio to build a driver package, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644). +`bDescriptorType = 0x5 ( USB_ENDPOINT_DESCRIPTOR_TYPE )` -Locate the built driver package -------------------------------- +`bEndpointAddress= 0x6 ( OUTPUT )` -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. For example, if your settings are Win8.1 Debug and x64, the package is in your solution folder under x64\\Win8.1Debug\\Package. +`bmAttributes= 0x2 ( USB_ENDPOINT_TYPE_BULK )` -Run the sample --------------- +`wMaxPacketSize= 0x40, decimal 64` -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*. +`bInterval = 0x0, decimal 0` -The process of moving the driver package to the target computer and installing the driver is called *deploying the driver*. You can deploy a driver sample automatically or manually. +`------------------------------` -### Automatic deployment (FX2 board) +`USB_ENDPOINT_DESCRIPTOR for Pipe02` -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/). +`bLength = 0x7` -1. Plug in the OSR USB-FX2 board to the target computer. -2. 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**. -3. 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 **Install and Verify**. Click **OK**. -4. On the **Build** menu, choose **Deploy Package** or **Build Solution**. +`bDescriptorType = 0x5 ( USB_ENDPOINT_DESCRIPTOR_TYPE )` -### Manual deployment (FX2 board) +`bEndpointAddress= 0x88 ( INPUT )` -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](http://msdn.microsoft.com/en-us/library/windows/hardware/dn265571). +`bmAttributes= 0x2 ( USB_ENDPOINT_TYPE_BULK )` -1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\umdf2\_fx2). -2. Plug in the OSR USB-FX2 board to the target computer. Open a Command Prompt window and enter **dvmgmt** to open Device Manager. In Device Manager, locate the node for the OSR USB-FX2 board. Right click the node, and choose **Properties**. In the **Details** tab, under **Properties**, choose **Hardware Ids**. Note the hardware IDs listed for your FX2 board. One of these IDs should match one of the IDs in the osrusbfx2um.inf file. For example, Device Manager might show an ID of USB\\VID\_0547&PID\_1002, which matches one of the IDs in the [Microsoft.*xxx*] section of osrusbfx2um.inf. +`wMaxPacketSize= 0x40, decimal 64` -3. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter this command: +`bInterval = 0x0, decimal 0 ` - **devcon update osrusbfx2um.inf"***HardwareID***"** +Sample Contents +--------------- - where *HardwareID* is the hardware ID of your FX2 board. Here is an example: +Folder - **devcon update osrusbfx2um.inf "USB\\VID\_0547&PID\_1002"** +Description -View the driver for the OSR USB-FX2 board in Device Manager ------------------------------------------------------------ +usb\\umdf\_fx2\\driver -On the target computer, in your Command Prompt window, enter **devmgmt** to open Device Manager. In Device Manager, on the **View** menu, choose **Devices by type**. In the device tree, locate **UMDF 2.0 Sample Driver for OSR Fx2 Learning Kit** (for example, this might be under the **Sample Device** node). +This directory contains driver code that demonstrates the following functionality: -In Device Manager, on the **View** menu, choose **Devices by connection**. Locate **UMDF 2.0 Sample Driver for OSR Fx2 Learning Kit** as a child of a USB hub node, which may be contained with the **ACPI x64-based PC** node. +- Loads the driver and responds to PnP and Power events. You can install, uninstall, disable, enable, suspend, and resume the system. +- Registers a PnP device interface so that application can open a handle to the device. +- Implements **IPnpCallbackHardware** interface and initializes USB I/O targets in **IPnpCallbackHardware::OnPrepareHardware** method. +- Creates a sequential queue for handling IOCTL requests. +- Adds code to handle the IOCTL to set bar graph display. +- Creates a parallel queue for handling read and write requests. +- Retrieves memory from read and write requests, format the requests, and sends them to a USB target. +- Supports additional IOCTLs to get and set the 7-segment display, get bar graph display, and get config descriptor. +- Sets power policy for the device. +- Adds code to indicate that the device is ready by lighting up the period on 7-segment display. +- Calls **SetupDi** functions to determine the "BusTypeGUID" of the device, and uses impersonation to access resources that only the caller has access to. +- Shows how to implement idle and wake functionality to make the driver the power policy owner (PPO). The sample achieves this using power-managed queues and UMDF DDIs, AssignS0IdleSettings, and AssignSxWakeSettings. +- Demonstrates implementation of a continuous reader. +- Demonstrates the use of impersonation. -Build the sample using MSBuild ------------------------------- +usb\\umdf\_fx2\\exe -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: +This directory contains a test application that can be used to drive the UMDF driver and FX2 device. This is a modified version of the test application for the KMDF Fx2 driver. -**msbuild /p:configuration=”Win8 Release” /p:platform=”Win32” umdf2\_fx2.sln** +usb\\umdf\_fx2\\deviceMetadata -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). +This directory contains the device metadata package for the sample. You must copy the device metadata to the system before installing the device. For information on how to update and deploy device metadata, see [Custom driver access sample](http://go.microsoft.com/fwlink/p/?LinkID=248288). diff --git a/usb/umdf_filter_umdf/ReadMe.md b/usb/umdf_filter_umdf/ReadMe.md index 56eb02db..b0c7970f 100644 --- a/usb/umdf_filter_umdf/ReadMe.md +++ b/usb/umdf_filter_umdf/ReadMe.md @@ -5,8 +5,8 @@ The umdf\_filter\_umdf sample demonstrates how to load a User-Mode Driver Framew This sample is written for the OSR USB-FX2 Learning Kit. The specification for the device is at <http://www.osronline.com/hardware/OSRFX2_32.pdf>. -Overview --------- +### Overview + Here is the overview of the device: @@ -25,33 +25,15 @@ Here is the overview of the device: - Endpoints are always double buffered. - Maximum packet size depends on speed (64 full speed, 512 high speed). -Testing the driver ------------------- +### Testing the driver You can test this sample either by using the [Custom driver access](http://go.microsoft.com/fwlink/p/?LinkID=248288) sample application, or by using the osrusbfx2.exe test application. For information on how to build and use the osrusbfx2.exe application, see the test instructions for the [umdf\_fx2](http://msdn.microsoft.com/en-us/library/windows/hardware/) sample. -Sample Contents ---------------- +### Sample Contents -<table> -<colgroup> -<col width="50%" /> -<col width="50%" /> -</colgroup> -<thead> -<tr class="header"> -<th align="left">Folder -Description</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td align="left">usb\umdf_filter_umdf\umdf_driver -This directory contains source code for the umdf_fx2 sample driver.</td> -<td align="left">usb\umdf_filter_umdf\umdf_filter -This directory contains the UMDF filter driver.</td> -</tr> -</tbody> -</table> +Folder | Description +-------|------------ +usb\umdf_filter_umdf\umdf_driver | This directory contains source code for the umdf_fx2 sample driver. +usb\umdf_filter_umdf\umdf_filter | This directory contains the UMDF filter driver. diff --git a/usb/umdf_fx2/ReadMe.md b/usb/umdf_fx2/ReadMe.md index 8b04f98e..2f7f1ded 100644 --- a/usb/umdf_fx2/ReadMe.md +++ b/usb/umdf_fx2/ReadMe.md @@ -5,25 +5,24 @@ The umdf\_fx2 sample is a User-Mode Driver Framework (UMDF) driver for the OSR U The sample can also be used with the CustomDeviceAccess MSDK sample. The sample demonstrates how to perform bulk and interrupt data transfers to an USB device. The specification for the device is at <http://www.osronline.com/hardware/OSRFX2_32.pdf>. The driver and sample device metadata also work with the [Custom driver access](http://go.microsoft.com/fwlink/p/?LinkID=248288) sample. +The osrusbfx2 sample is divided into three samples: -Related topics --------------- +- **WDF Sample Driver Learning Lab for OSR USB-FX2**: This sample is a series of iterative drivers that demonstrate how to write a "Hello World" driver and adds additional features in each step. -**** - -[kmdf\_fx2](http://msdn.microsoft.com/en-us/library/windows/hardware/) +- **kmdf\_fx2**: This sample is the final version of kernel-mode **wdf\_osrfx2** driver. The sample demonstrates KMDF methods. +- **umdf\_fx2**: This sample is the final version of the user-mode driver **wdf\_osrfx2**. The sample demonstrates UMDF methods. Build the sample ---------------- -The default Solution build configuration is Windows 8.1 Debug and Win32. You can change the default configuration to build for Windows 8 or Windows 7 version of the operating system. +The default Solution build configuration is Debug and Win32. **To select a configuration and build a driver** -1. Open the driver project or solution in Visual Studio 2013 (find *filtername*.sln or *filtername*.vcxproj). +1. Open the driver project or solution in Visual Studio 2015 (find *filtername*.sln or *filtername*.vcxproj). 2. Right-click the solution in the **Solutions Explorer** and select **Configuration Manager**. -3. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Windows 8.1 Debug or Windows 8.1 Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. +3. From the **Configuration Manager**, select the **Active Solution Configuration** and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. 4. From the **Build** menu, click **Build Solution** (Ctrl+Shift+B). Overview diff --git a/usb/usbview/ReadMe.md b/usb/usbview/ReadMe.md index b017a426..b627f091 100644 --- a/usb/usbview/ReadMe.md +++ b/usb/usbview/ReadMe.md @@ -22,14 +22,12 @@ For information about USB, see [Universal Serial Bus (USB) Drivers](http://msdn. Run the sample -------------- -Local debugging ---------------- +### Local debugging 1. Change **Debugger** to launch to **Local Windows Debugger**. 2. On the **Debug** menu, select **Start debugging** or hit **F5**. -Manual deployment to a remote target computer ---------------------------------------------- +### Manual deployment to a remote target computer If you want to debug the sample app on a remote computer, @@ -38,8 +36,7 @@ If you want to debug the sample app on a remote computer, 3. Change **Debugger** to launch to **Remote Windows Debugger**. 4. On the **Debug** menu, select **Start debugging** or hit **F5**. -View a USB device in Usbview ----------------------------- +### View a USB device in Usbview 1. Attach a USB device to one of USB ports on the computer that has Usbview running. 2. In the device tree, locate the device. For example the device might be under the Intel(R) ICH10 Family USB Universal Host Controller - 3A34 \> Root Hub node. @@ -48,26 +45,17 @@ View a USB device in Usbview Code tour --------- -<table> -<colgroup> -<col width="50%" /> -<col width="50%" /> -</colgroup> -<thead> -<tr class="header"> -<th align="left">File manifest -Description</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td align="left">Resource.h -ID definitions for GUI controls</td> -<td align="left">Usbdesc.h -USB descriptor type definitions</td> -</tr> -</tbody> -</table> +File manifest | Description +--------------|------------ +Resource.h | ID definitions for GUI controls +Usbdesc.h | USB descriptor type definitions +Usbview.h | Main header file for this sample +Vndrlist.h | List of USB Vendor IDs and vendor names +Debug.c | Assertion routines for the checked build +Devnode.c | Routines for accessing DevNode information +Dispaud.c | Routines for displaying USB audio class device information +Enum.c | Routines for displaying USB device information +Usbview.c | Entry point and GUI handling routines The major topics covered in this tour are: diff --git a/wmi/wmisamp/ReadMe.md b/wmi/wmisamp/ReadMe.md index f5c9ed38..d2449f80 100644 --- a/wmi/wmisamp/ReadMe.md +++ b/wmi/wmisamp/ReadMe.md @@ -8,7 +8,7 @@ This sample builds a Universal Windows Driver. It uses only APIs and DDIs that a The sample demonstrates how to register the WMI providers and create provider instances for the Framework device object. It also illustrates how to handle the WMI queries sent to the device. -The [Firefly](gallery_samples.48_gallery#1), [PCIDRV](gallery_samples.32_gallery#1), and [Toaster](gallery_samples.37_gallery#1) sample drivers also implement WMI data providers. +The **Firefly**, **PCIDRV**, and **Toaster** sample drivers also implement WMI data providers. Installation ------------ diff --git a/wpd/WpdHelloWorldDriver/ReadMe.md b/wpd/WpdHelloWorldDriver/ReadMe.md index d21b2d69..0bf883bd 100644 --- a/wpd/WpdHelloWorldDriver/ReadMe.md +++ b/wpd/WpdHelloWorldDriver/ReadMe.md @@ -5,118 +5,58 @@ The WpdHelloWorld sample driver supports four objects: a device object, a storag The sample driver supports a device object that exposes ten read-only properties. These properties, their types, and their values are listed in the following table. -<table> -<colgroup> -<col width="33%" /> -<col width="33%" /> -<col width="33%" /> -</colgroup> -<tbody> -<tr class="odd"> -<td align="left">Property name -Property type -Value</td> -<td align="left">DEVICE_PROTOCOL -String -"Hello World Protocol ver 1.00"</td> -<td align="left">DEVICE_FIRMWARE_VERSION -String -"1.0.0.0"</td> -</tr> -</tbody> -</table> +Property name | Property type | Value +--------------|---------------|------ +DEVICE_PROTOCOL | String | "Hello World Protocol ver 1.00" +DEVICE_FIRMWARE_VERSION | String | "1.0.0.0" +DEVICE_POWER_LEVEL | Integer | 100 +DEVICE_MODEL | String | "Hello World!" +DEVICE_MANUFACTURER | String | "Windows Portable Devices Group" +DEVICE_FRIENDLY | String | "Hello World!" +DEVICE_SERIAL_NUMBER | String | "01234567890123-45676890123456" +DEVICE_SUPPORTS_NONCONSUMABLE | Bool | True +WPD_DEVICE_TYPE | Integer | WPD_DEVICE_TYPE_GENERIC +WPD_FUNCTIONAL_OBJECT_CATEGORY | GUID | WPD_FUNCTIONAL_CATEGORY_STORAGE -The driver supports a storage object that exposes six read-only properties. These properties, their types, and their values are listed in the following table. +The driver supports a storage object that exposes seven read-only properties. These properties, their types, and their values are listed in the following table. -<table> -<colgroup> -<col width="33%" /> -<col width="33%" /> -<col width="33%" /> -</colgroup> -<tbody> -<tr class="odd"> -<td align="left">Property name -Property type -Value</td> -<td align="left">STORAGE_CAPACITY -64-bit Integer -1024 * 1024</td> -<td align="left">STORAGE_FREE_SPACE_IN_BYTES -64-bit Integer -(same as above)</td> -</tr> -</tbody> -</table> +Property name | Property type | Value +--------------|---------------|------ +STORAGE_CAPACITY | 64-bit Integer | 1024 * 1024 +STORAGE_FREE_SPACE_IN_BYTES | 64-bit Integer | 1024 * 1024 +STORAGE_SERIAL_NUMBER | String | 98765432109876-54321098765432 +STORAGE_FILE_SYSTEM_TYPE | String | FAT32 +STORAGE_DESCRIPTION | String | Hello World! Memory Storage System +WPD_STORAGE_TYPE | Integer | WPD_STORAGE_TYPE_FIXED_ROM +WPD_FUNCTIONAL_OBJECT_CATEGORY | GUID | WPD_FUNCTIONAL_CATEGORY_STORAGE The driver supports a folder object that exposes three read-only properties. These properties, their types, and their values are listed in the following table. -<table> -<colgroup> -<col width="33%" /> -<col width="33%" /> -<col width="33%" /> -</colgroup> -<tbody> -<tr class="odd"> -<td align="left">Property name -Property type -Value</td> -<td align="left">WPD_OBJECT_DATE_MODIFIED -Date -2006/6/26 5:0:0.0</td> -<td align="left">WPD_OBJECT_DATE_CREATED -Date -2006/1/25 12:0:0.0</td> -</tr> -</tbody> -</table> +Property name | Property type | Value +--------------|---------------|------ +WPD_OBJECT_DATE_MODIFIED | Date | 2006/6/26 5:0:0.0 +WPD_OBJECT_DATE_CREATED | Date | 2006/1/25 12:0:0.0 +WPD_OBJECT_ORIGINAL_FILE_NAME_VALUE | String | Documents The driver supports a file object that exposes three read-only properties. These properties, their types, and their values are listed in the following table. -<table> -<colgroup> -<col width="33%" /> -<col width="33%" /> -<col width="33%" /> -</colgroup> -<tbody> -<tr class="odd"> -<td align="left">Property name -Property type -Value</td> -<td align="left">WPD_OBJECT_DATE_MODIFIED -Date -2006/6/26 5:0:0.0</td> -<td align="left">WPD_OBJECT_DATE_CREATED -Date -2006/1/25 12:0:0.0</td> -</tr> -</tbody> -</table> +Property name | Property type | Value +--------------|---------------|------ +WPD_OBJECT_DATE_MODIFIED | Date | 2006/6/26 5:0:0.0 +WPD_OBJECT_DATE_CREATED | Date | 2006/1/25 12:0:0.0 +WPD_OBJECT_ORIGINAL_FILE_NAME | String | Readme.txt In addition to the above properties, every object (for example, device, storage, folder, or file) also supports seven common WPD object properties. These are read-only properties that contain object-specific values for the most part. These properties, their types, and their values are listed in the following table. -<table> -<colgroup> -<col width="33%" /> -<col width="33%" /> -<col width="33%" /> -</colgroup> -<tbody> -<tr class="odd"> -<td align="left">Property name -Property type -Value</td> -<td align="left">WPD_OBJECT_ID -String -Object-specific</td> -<td align="left">WPD_OBJECT_PERSISTENT_UNIQUE_ID -String -Object-specific</td> -</tr> -</tbody> -</table> +Property name | Property type | Value +--------------|---------------|------ +WPD_OBJECT_ID | String | Object-specific +WPD_OBJECT_PERSISTENT_UNIQUE_ID | String | Object-specific +WPD_OBJECT_PARENT_ID | String | Object-specific +WPD_OBJECT_NAME | String | Object-specific +WPD_OBJECT_FORMAT | GUID | Object-specific +WPD_OBJECT_CONTENT_TYPE | GUID | Object-specific +WPD_OBJECT_CAN_DELETE | Bool | False For a complete description of this sample and its underlying code and functionality, refer to the [WPD HelloWorld Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/) description in the Windows Driver Kit documentation. @@ -127,4 +67,4 @@ Related topics [WPD Driver Development Tools](http://msdn.microsoft.com/en-us/library/windows/hardware/ff597568) -[WPD Programming Guide](http://msdn.microsoft.com/en-us/library/windows/hardware/) +[WPD Programming Guide](https://msdn.microsoft.com/en-us/library/windows/hardware/ff597898) diff --git a/wpd/WpdMultiTransportDriver/ReadMe.md b/wpd/WpdMultiTransportDriver/ReadMe.md index 89700605..4e277f0a 100644 --- a/wpd/WpdMultiTransportDriver/ReadMe.md +++ b/wpd/WpdMultiTransportDriver/ReadMe.md @@ -3,7 +3,7 @@ WPD multi-transport sample driver The WpdMultiTransportDriver sample demonstrates how you could extend the WpdHelloWorldDriver for a device that supports multiple transports. A transport is a protocol over which a portable device communicates with a computer. Example transports include Internet Protocol (IP), Bluetooth, and USB. -A number of portable devices now support multiple transports. For example, a number of cell phones support both Bluetooth and USB. Before Windows 7, if a user connected a portable device that supported multiple transports to their computer, the Windows Device Manager displayed a unique node for each transport. This implied that multiple devices had been installed and left the user confused. To resolve this, Windows now supports a multitransport driver model. This model ensures that only one node appears for each device. +A number of portable devices now support multiple transports. For example, a number of cell phones support both Bluetooth and USB. Windows supports a multitransport driver model that ensures that only one node appears for each device. For a complete description of this sample and its underlying code and functionality, refer to the [WPD MultiTransport Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff597709) description in the Windows Driver Kit documentation. @@ -14,4 +14,4 @@ Related topics [WPD Driver Development Tools](http://msdn.microsoft.com/en-us/library/windows/hardware/ff597568) -[WPD Programming Guide](http://msdn.microsoft.com/en-us/library/windows/hardware/) +[WPD Programming Guide](https://msdn.microsoft.com/en-us/library/windows/hardware/ff597898) diff --git a/wpd/WpdServiceSampleDriver/ReadMe.md b/wpd/WpdServiceSampleDriver/ReadMe.md index d9ed7246..24fcc336 100644 --- a/wpd/WpdServiceSampleDriver/ReadMe.md +++ b/wpd/WpdServiceSampleDriver/ReadMe.md @@ -17,4 +17,4 @@ Related topics [WPD Driver Development Tools](http://msdn.microsoft.com/en-us/library/windows/hardware/ff597568) -[WPD Programming Guide](http://msdn.microsoft.com/en-us/library/windows/hardware/) +[WPD Programming Guide](https://msdn.microsoft.com/en-us/library/windows/hardware/ff597898) diff --git a/wpd/WpdWudfSampleDriver/ReadMe.md b/wpd/WpdWudfSampleDriver/ReadMe.md index f47a712b..3d2f449b 100644 --- a/wpd/WpdWudfSampleDriver/ReadMe.md +++ b/wpd/WpdWudfSampleDriver/ReadMe.md @@ -17,4 +17,4 @@ Related topics [WPD Driver Development Tools](http://msdn.microsoft.com/en-us/library/windows/hardware/ff597568) -[WPD Programming Guide](http://msdn.microsoft.com/en-us/library/windows/hardware/) +[WPD Programming Guide](https://msdn.microsoft.com/en-us/library/windows/hardware/ff597898) |