diff options
| -rw-r--r-- | TrEE/README.md | 10 | ||||
| -rw-r--r-- | serial/VirtualSerial/README.md | 25 | ||||
| -rw-r--r-- | serial/VirtualSerial2/README.md | 25 | ||||
| -rw-r--r-- | serial/serenum/README.md | 33 | ||||
| -rw-r--r-- | serial/serial/README.md | 22 | ||||
| -rw-r--r-- | setup/devcon/README.md | 39 | ||||
| -rw-r--r-- | spb/SkeletonI2C/README.md | 25 | ||||
| -rw-r--r-- | spb/SpbTestTool/README.md | 116 | ||||
| -rw-r--r-- | storage/class/cdrom/README.md | 21 | ||||
| -rw-r--r-- | storage/class/classpnp/README.md | 13 | ||||
| -rw-r--r-- | storage/class/disk/README.md | 21 | ||||
| -rw-r--r-- | storage/filters/addfilter/README.md | 18 | ||||
| -rw-r--r-- | storage/iscsi/README.md | 13 | ||||
| -rw-r--r-- | storage/miniports/lsi_u3/README.md | 18 | ||||
| -rw-r--r-- | storage/miniports/storahci/README.md | 13 | ||||
| -rw-r--r-- | storage/msdsm/README.md | 6 | ||||
| -rw-r--r-- | storage/sfloppy/README.md | 15 | ||||
| -rw-r--r-- | storage/tools/spti/README.md | 15 | ||||
| -rw-r--r-- | thermal/simsensor/README.md | 14 | ||||
| -rw-r--r-- | thermal/thermalclient/README.md | 16 |
20 files changed, 188 insertions, 290 deletions
diff --git a/TrEE/README.md b/TrEE/README.md index 471893c3..066a9812 100644 --- a/TrEE/README.md +++ b/TrEE/README.md @@ -8,16 +8,6 @@ products: - windows-wdk --- - -<!--- - name: TrEE sample - platform: KMDF - language: cpp - category: TrEE - description: TrEE sample - samplefwlink: https://go.microsoft.com/fwlink/p/?linkid=869055 ----> - # TrEE sample The Trusted Execution Environment (TrEE) sample. diff --git a/serial/VirtualSerial/README.md b/serial/VirtualSerial/README.md index 05c1f385..3eeb9764 100644 --- a/serial/VirtualSerial/README.md +++ b/serial/VirtualSerial/README.md @@ -8,37 +8,30 @@ products: - windows-wdk --- - -<!--- - name: Virtual serial driver sample - platform: UMDF1 - language: cpp - category: Serial - description: Demonstrates a simple virtual serial driver (ComPort) and a controller-less modem driver (FakeModem). - samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617963 ----> - # Virtual serial driver sample This sample demonstrates these two serial drivers: - A simple virtual serial driver (ComPort) + - A controller-less modem driver (FakeModem).This driver supports sending and receiving AT commands using the ReadFile and WriteFile calls or via a TAPI interface using an application such as, HyperTerminal. This sample driver is a minimal driver meant to demonstrate the usage of the User-Mode Driver Framework. It is not intended for use in a production environment. -For more information, see [Serial Controller and Device Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff546939) in the WDK documentation. +For more information, see the [Serial Controller Driver Design Guide](https://docs.microsoft.com/windows-hardware/drivers/serports/). ## Code tour -### comsup.cpp & comsup.h +### comsup.cpp and comsup.h - COM Support code - specifically base classes which provide implementations for the standard COM interfaces **IUnknown** and **IClassFactory** which are used throughout the 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 - DLL Support code - provides the DLL's entry point as well as the single required export (**DllGetClassObject**). + - These depend on comsup.cpp to perform the necessary class creation. ### exports.def @@ -49,15 +42,15 @@ For more information, see [Serial Controller and Device Drivers](http://msdn.mic - This is the main header file for the sample driver. -### driver.cpp & driver.h +### driver.cpp and driver.h - Definition and implementation of the driver callback class (CMyDriver) for the sample. This includes **DriverEntry** and events on the framework driver object. -### device.cpp & driver.h +### device.cpp and driver.h - Definition and implementation of the device callback class (CMyDriver) for the sample. This includes events on the framework device object. -### queue.cpp & queue.h +### queue.cpp and queue.h - Definition and implementation of the base queue callback class (CMyQueue). This includes events on the framework I/O queue object. @@ -67,4 +60,4 @@ For more information, see [Serial Controller and Device Drivers](http://msdn.mic ### VirtualSerial.inf / FakeModem.inf -- INF file that contains installation information for this driver.
\ No newline at end of file +- INF file that contains installation information for this driver. diff --git a/serial/VirtualSerial2/README.md b/serial/VirtualSerial2/README.md index f9312528..2230b108 100644 --- a/serial/VirtualSerial2/README.md +++ b/serial/VirtualSerial2/README.md @@ -9,37 +9,30 @@ products: - windows-wdk --- - -<!--- - name: Virtual serial driver sample (UMDF version 2) - platform: UMDF2 - language: cpp - category: Serial - description: Demonstrates UMDF version 2 serial drivers and includes a simple virtual serial driver (ComPort) and a controller-less modem driver (FakeModem). - samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617965 ----> - # Virtual serial driver sample This sample demonstrates these two serial drivers: - A simple virtual serial driver (ComPort) + - A controller-less modem driver (FakeModem).This driver supports sending and receiving AT commands using the ReadFile and WriteFile calls or via a TAPI interface using an application such as, HyperTerminal. This sample driver is a minimal driver meant to demonstrate the usage of the User-Mode Driver Framework. It is not intended for use in a production environment. -For more information, see [Serial Controller and Device Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff546939) in the WDK documentation. +For more information, see the [Serial Controller Driver Design Guide](https://docs.microsoft.com/windows-hardware/drivers/serports/). ## Code tour -### comsup.cpp & comsup.h +### comsup.cpp and comsup.h - COM Support code - specifically base classes which provide implementations for the standard COM interfaces **IUnknown** and **IClassFactory** which are used throughout the 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 - DLL Support code - provides the DLL's entry point as well as the single required export (**DllGetClassObject**). + - These depend on comsup.cpp to perform the necessary class creation. ### exports.def @@ -50,15 +43,15 @@ For more information, see [Serial Controller and Device Drivers](http://msdn.mic - This is the main header file for the sample driver. -### driver.cpp & driver.h +### driver.cpp and driver.h - Definition and implementation of the driver callback class (CMyDriver) for the sample. This includes **DriverEntry** and events on the framework driver object. -### device.cpp & driver.h +### device.cpp and driver.h - Definition and implementation of the device callback class (CMyDriver) for the sample. This includes events on the framework device object. -### queue.cpp & queue.h +### queue.cpp and queue.h - Definition and implementation of the base queue callback class (CMyQueue). This includes events on the framework I/O queue object. @@ -68,4 +61,4 @@ For more information, see [Serial Controller and Device Drivers](http://msdn.mic ### VirtualSerial.inf / FakeModem.inf -- INF file that contains installation information for this driver.
\ No newline at end of file +- INF file that contains installation information for this driver. diff --git a/serial/serenum/README.md b/serial/serenum/README.md index d793f8d5..d3f712a6 100644 --- a/serial/serenum/README.md +++ b/serial/serenum/README.md @@ -8,25 +8,16 @@ products: - windows-wdk --- - -<!--- - name: Serenum sample - platform: WDM - language: cpp - category: Serial - description: Enumerates Plug-n-Play RS-232 devices that are compliant with the current revision of Plug and Play External COM Device. - samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617961 ----> - # Serenum sample Serenum enumerates Plug-n-Play RS-232 devices that are compliant with the current revision of Plug and Play External COM Device. It loads as an upper filter driver to many different RS-232 device drivers that are compliant with its requirements and performs this service for them. -Serenum implements the Serenum service; its executable image is serenum.sys. +Serenum implements the Serenum service and its executable image is serenum.sys. Serenum is an upper-level device filter driver that is used with a serial port function driver to enumerate the following types of devices that are connected to an RS-232 port: - Plug and Play serial devices that comply with Plug and Play External COM Device Specification, Version 1.00, February 28, 1995. + - Pointer devices that comply with legacy mouse detection in Windows. The combined operation of Serial and Serenum provides the function of a Plug and Play bus driver for an RS-232 port. Serenum supports Plug and Play and power management. @@ -35,14 +26,14 @@ Windows provides Serenum to support Serial and other serial port function driver ## 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 +| 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).
\ No newline at end of file +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 cfd335d7..7578f9ba 100644 --- a/serial/serial/README.md +++ b/serial/serial/README.md @@ -8,16 +8,6 @@ products: - windows-wdk --- - -<!--- - name: Serial Port Driver - platform: KMDF - language: cpp - category: Serial - description: The Serial (16550-based RS-232) sample driver is a WDF version of the inbox Serial.sys driver. - samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617962 ----> - # Serial Port Driver The Serial (16550-based RS-232) sample driver is a WDF version of the inbox Serial.sys driver in %WINDIR%\\system32\\drivers. @@ -26,23 +16,27 @@ The Serial (16550-based RS-232) sample driver is a WDF version of the inbox Seri This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. +## Sample overview + This sample driver is functionally equivalent to the inbox driver, with these two exceptions: 1. This sample does not support multi-function serial devices. -2. This sample does not support legacy serial ports. Legacy ports are not detected by the BIOS, and are, therefore, not enumerated by the operating system. + +1. This sample does not support legacy serial ports. Legacy ports are not detected by the BIOS, and are, therefore, not enumerated by the operating system. The Serial sample driver runs in kernel mode. This sample driver supports power management. When a serial port is not in use, the driver places the port hardware in a low-power state. When the port is opened, it receives power and wakes up. The driver supports wake-on-ring for platforms that support this function. The driver can be compiled to run on both 32-bit and 64-bit versions of Windows. -For more information, see [Features of Serial and Serenum](http://msdn.microsoft.com/en-us/library/windows/hardware/ff546505). +For more information, see [Features of Serial and Serenum](https://docs.microsoft.com/windows-hardware/drivers/serports/features-of-serial-and-serenum). This sample can be used for these hardware IDs without any modification to the .inx file included in the project. - PNP0501 + - PNP0500 -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. +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. ```inf ; For XP and later @@ -52,4 +46,4 @@ If you have other hardware such as an add-in card, then you must add the hardwar %PNP0500.DevDesc%= Serial_Inst, *PNP0500, *PNP0501 ; Communications Port %PNP0501.DevDesc%= Serial_Inst, *PNP0501, *PNP0500 ; Communications Port %PNP0501.DevDesc%= Serial_Inst, MF\PCI9710_COM ; Communications Port -```
\ No newline at end of file +``` diff --git a/setup/devcon/README.md b/setup/devcon/README.md index 638c7c28..f2cdc6b9 100644 --- a/setup/devcon/README.md +++ b/setup/devcon/README.md @@ -10,7 +10,7 @@ products: # Device Console (DevCon) Tool -[DevCon](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544707) is a command-line tool that displays detailed information about devices, and lets you search for and manipulate devices from the command line. DevCon enables, disables, installs, configures, and removes devices on the local computer and displays detailed information about devices on local and remote computers. DevCon is included in the WDK. +[DevCon](https://docs.microsoft.com/windows-hardware/drivers/devtest/devcon) is a command-line tool that displays detailed information about devices, and lets you search for and manipulate devices from the command line. DevCon enables, disables, installs, configures, and removes devices on the local computer and displays detailed information about devices on local and remote computers. DevCon is included in the WDK. This document explains the DevCon design, and how to use the SetupAPI and device installation functions to enumerate devices and perform device operations in a console application. For a complete description of DevCon features and instructions for using them, see the DevCon help file included with the WDK documentation in Driver Development Tools/Tools for Testing Drivers/DevCon. @@ -23,8 +23,11 @@ You can build the sample in two ways: using the Visual Studio Integrated Develop ### Building the sample using Visual Studio 1. Open Visual Studio. From the **File** menu, select **Open Project/Solution**. Navigate to the DevCon sample folder and open the devcon.sln project file. + 1. Right-click the solution in the **Solution Explorer** and select **Configuration Manager**. + 1. 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. + 1. 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. You can use the Visual Studio Command Prompt window for all build configurations. @@ -32,30 +35,32 @@ Previous versions of the WDK used the Windows Build utility (Build.exe) and prov ### 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. -1. 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**. + +1. 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`. + 1. 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 -Type "devcon find \*" to list device instances of all present devices on the local machine. +Type `devcon find *` to list device instances of all present devices on the local machine. -Type "devcon status @root\\rdp\_mou\\0000" to list status of the terminal server mouse driver. +Type `devcon status @root\rdp\_mou\0000` to list status of the terminal server mouse driver. -Type "devcon status \*PNP05\*" to list status of all COM ports. +Type `devcon status *PNP05*` to list status of all COM ports. ### How DevCon works -Running "devcon help" will provide a list of commands along with short descriptions of what each command does. "devcon help \<command\>" will give more detailed help on that command. The interpretation of each command is done via a dispatch table "DispatchTable" that is at the bottom of "cmds.cpp". Some of the commands make use of a generic device enumerator "EnumerateDevices". A few of these commands will work when given a remote target computer, and will also work if using the 32-bit devcon on Wow64. +Running `devcon help` will provide a list of commands along with short descriptions of what each command does. `devcon help <command>` will give more detailed help on that command. The interpretation of each command is done via a dispatch table "DispatchTable" that is at the bottom of "cmds.cpp". Some of the commands make use of a generic device enumerator "EnumerateDevices". A few of these commands will work when given a remote target computer, and will also work if using the 32-bit devcon on Wow64. A description of some of the more interesting functions and the APIs they use follows: cmdClasses -- This command demonstrates the use of [**SetupDiBuildClassInfoListEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550911) to enumerate all device class GUIDs. The function [**SetupDiClassNameFromGuidEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550950) and [**SetupDiGetClassDescriptionEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551058) are used to obtain more information about each device class. +- This command demonstrates the use of [**SetupDiBuildClassInfoListEx**](https://docs.microsoft.com/windows/win32/api/setupapi/nf-setupapi-setupdibuildclassinfolistexa) to enumerate all device class GUIDs. The function [**SetupDiClassNameFromGuidEx**](https://docs.microsoft.com/windows/win32/api/setupapi/nf-setupapi-setupdiclassnamefromguidexa) and [**SetupDiGetClassDescriptionEx**](https://docs.microsoft.com/windows/win32/api/setupapi/nf-setupapi-setupdigetclassdescriptionexa) are used to obtain more information about each device class. cmdListClass -- This command demonstrates the use of [**SetupDiClassGuidsFromNameEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550941) to enumerate one or more class GUIDs that match the class name. This command also demonstrates the use of [**SetupDiGetClassDevsEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551072) to list all the devices for each class GUID. +- This command demonstrates the use of [**SetupDiClassGuidsFromNameEx**](https://docs.microsoft.com/windows/win32/api/setupapi/nf-setupapi-setupdiclassguidsfromnameexa) to enumerate one or more class GUIDs that match the class name. This command also demonstrates the use of [**SetupDiGetClassDevsEx**](https://docs.microsoft.com/windows/win32/api/setupapi/nf-setupapi-setupdigetclassdevsexa) to list all the devices for each class GUID. cmdFind cmdFindAll cmdStatus @@ -67,7 +72,7 @@ cmdEnable cmdDisable cmdRestart cmdUpdate -- This command shows how to use [**UpdateDriverForPlugAndPlayDevices**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff553534) to update the driver for all devices to a specific driver. Normally INSTALLFLAG\_FORCE would not be specified allowing **UpdateDriverForPlugAndPlayDevices** to determine if there is a better match already known. It's specified in DevCon to allow DevCon to be used more effectively as a debugging/testing tool. This cannot be done on a remote machine or in the context of Wow64. +- This command shows how to use [**UpdateDriverForPlugAndPlayDevices**](https://docs.microsoft.com/windows/win32/api/newdev/nf-newdev-updatedriverforplugandplaydevicesa) to update the driver for all devices to a specific driver. Normally INSTALLFLAG\_FORCE would not be specified allowing **UpdateDriverForPlugAndPlayDevices** to determine if there is a better match already known. It's specified in DevCon to allow DevCon to be used more effectively as a debugging/testing tool. This cannot be done on a remote machine or in the context of Wow64. cmdInstall @@ -83,11 +88,11 @@ cmdRescan cmdDPAdd -- This command allows you to add a Driver Package to the machine. The main functionality of this command demonstrates the use of [**SetupCopyOEMInf**](http://msdn.microsoft.com/en-us/library/windows/hardware/). Adding a Driver Package to the machine doesn't mean the drivers are installed on devices, it simply means the drivers are available automatically when a new device is plugged in or a existing device is updated. +- This command allows you to add a Driver Package to the machine. The main functionality of this command demonstrates the use of [**SetupCopyOEMInf**](https://docs.microsoft.com/windows/win32/api/setupapi/nf-setupapi-setupcopyoeminfa). Adding a Driver Package to the machine doesn't mean the drivers are installed on devices, it simply means the drivers are available automatically when a new device is plugged in or a existing device is updated. cmdDPDelete -- This command allows you to uninstall a Driver Package from the machine. The main functionality of this command demonstrates the use of [**SetupUninstallOEMInf**](http://msdn.microsoft.com/en-us/library/windows/hardware/). Removing a Driver Package from the machine does not uninstall the drivers associated with a device. If you want to accomplish both then use *cmdRemove* on all the devices using a given Driver Package and then *cmdDPDelete* to remove the Driver Package itself from the machine. +- This command allows you to uninstall a Driver Package from the machine. The main functionality of this command demonstrates the use of [**SetupUninstallOEMInf**](https://docs.microsoft.com/windows/win32/api/setupapi/nf-setupapi-setupuninstalloeminfa). Removing a Driver Package from the machine does not uninstall the drivers associated with a device. If you want to accomplish both then use *cmdRemove* on all the devices using a given Driver Package and then *cmdDPDelete* to remove the Driver Package itself from the machine. cmdDPEnum @@ -99,11 +104,11 @@ Reboot EnumerateDevices -- Demonstrates the use of [**SetupDiGetClassDevsEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551072) to enumerate all devices or all present devices, either globally or limited to a specific setup class. Demonstrates the use of [**SetupDiCreateDeviceInfoListEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550958) to create a blank list associated with a class or not (for most cases, a blank list need not be associated with a class). Demonstrates the use of [**SetupDiOpenDeviceInfo**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552071) to add a device instance into a device info list. These last two API's are ideal to obtain a [SP\_DEVINFO\_DATA](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552344) structure from a device instance and machine name when mixing CFGMGR32 API's with SETUPAPI API's. [**SetupDiGetDeviceInfoListDetail**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551103) is called to obtain a remote machine handle that may be passed into CFGMGR32 API's. [**SetupDiEnumDeviceInfo**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551010) is called to enumerate each and every device that is in the device info list (either explicitly added, or determined by the call to **SetupDiGetClassDevsEx**). The instance ID is obtained by calling [**CM\_Get\_Device\_ID\_Ex**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff538411), using information in devInfo (obtained from **SetupDiEnumerateDeviceInfo**) and devInfoListDetail (obtained from **SetupDiGetDeviceInfoListDetail**). *GetHwIds* is called to obtain a list of hardware and compatible ID's (explained below). Once an interesting device has been determined (typically by checking hardware ID's) then the callback is called to operate on that individual device. +- Demonstrates the use of [**SetupDiGetClassDevsEx**](https://docs.microsoft.com/windows/win32/api/setupapi/nf-setupapi-setupdigetclassdevsexa) to enumerate all devices or all present devices, either globally or limited to a specific setup class. Demonstrates the use of [**SetupDiCreateDeviceInfoListEx**](https://docs.microsoft.com/windows/win32/api/setupapi/nf-setupapi-setupdicreatedeviceinfolistexa) to create a blank list associated with a class or not (for most cases, a blank list need not be associated with a class). Demonstrates the use of [**SetupDiOpenDeviceInfo**](hhttps://docs.microsoft.com/windows/win32/api/setupapi/nf-setupapi-setupdiopendeviceinfoa) to add a device instance into a device info list. These last two API's are ideal to obtain a [SP\_DEVINFO\_DATA](https://docs.microsoft.com/windows/win32/api/setupapi/ns-setupapi-sp_devinfo_data) structure from a device instance and machine name when mixing CFGMGR32 API's with SETUPAPI API's. [**SetupDiGetDeviceInfoListDetail**](https://docs.microsoft.com/windows/win32/api/setupapi/nf-setupapi-setupdigetdeviceinfolistdetaila) is called to obtain a remote machine handle that may be passed into CFGMGR32 API's. [**SetupDiEnumDeviceInfo**](https://docs.microsoft.com/windows/win32/api/setupapi/nf-setupapi-setupdienumdeviceinfo) is called to enumerate each and every device that is in the device info list (either explicitly added, or determined by the call to **SetupDiGetClassDevsEx**). The instance ID is obtained by calling [**CM\_Get\_Device\_ID\_Ex**](https://docs.microsoft.com/windows/win32/api/cfgmgr32/nf-cfgmgr32-cm_get_device_id_exw), using information in devInfo (obtained from **SetupDiEnumerateDeviceInfo**) and devInfoListDetail (obtained from **SetupDiGetDeviceInfoListDetail**). *GetHwIds* is called to obtain a list of hardware and compatible ID's (explained below). Once an interesting device has been determined (typically by checking hardware ID's) then the callback is called to operate on that individual device. GetHwIds -- Shows how to get the complete list of hardware ID's or compatible ID's for a device using [**SetupDiGetDeviceRegistryProperty**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551967). +- Shows how to get the complete list of hardware ID's or compatible ID's for a device using [**SetupDiGetDeviceRegistryProperty**](https://docs.microsoft.com/windows/win32/api/setupapi/nf-setupapi-setupdigetdeviceregistrypropertya). GetDeviceDescription @@ -111,11 +116,11 @@ GetDeviceDescription DumpDeviceWithInfo -- Shows how to obtain an instance ID (or use any CFGMGR32 API) given HDEVINFO (device info list) and [PSP\_DEVINFO\_DATA](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552344) (device info data). +- Shows how to obtain an instance ID (or use any CFGMGR32 API) given HDEVINFO (device info list) and [PSP\_DEVINFO\_DATA](https://docs.microsoft.com/windows/win32/api/setupapi/ns-setupapi-sp_devinfo_data) (device info data). DumpDeviceStatus -- Shows how to interpret the information returned by [**CM\_Get\_DevNode\_Status\_Ex**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff538517). Refer to *cfg.h* for information returned by this API. +- Shows how to interpret the information returned by [**CM\_Get\_DevNode\_Status\_Ex**](https://docs.microsoft.com/windows/win32/api/cfgmgr32/nf-cfgmgr32-cm_get_devnode_status_ex). Refer to *cfg.h* for information returned by this API. DumpDeviceResources @@ -123,11 +128,11 @@ DumpDeviceResources DumpDeviceDriverFiles -- Provided as a debugging aid, obtains information about the files apparently being used for a device. It uses [**SetupDiBuildDriverInfoList**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550917) to obtain information about the driver being used for the specified device. The driver list associated with a device may be enumerated by calling [**SetupDiEnumDriverInfo**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551018). In this case, there will be no more than one driver listed. This function proceeds to obtain a list of files that would normally be copied for this driver using DIF\_INSTALLDEVICEFILES. [**SetupScanFileQueue**](http://msdn.microsoft.com/en-us/library/windows/hardware/) is used to enumerate the file queue to display the list of files that are associated with the driver. +- Provided as a debugging aid, obtains information about the files apparently being used for a device. It uses [**SetupDiBuildDriverInfoList**](https://docs.microsoft.com/windows/win32/api/setupapi/nf-setupapi-setupdibuilddriverinfolist) to obtain information about the driver being used for the specified device. The driver list associated with a device may be enumerated by calling [**SetupDiEnumDriverInfo**](https://docs.microsoft.com/windows/win32/api/setupapi/nf-setupapi-setupdienumdriverinfoa). In this case, there will be no more than one driver listed. This function proceeds to obtain a list of files that would normally be copied for this driver using DIF\_INSTALLDEVICEFILES. [**SetupScanFileQueue**](https://docs.microsoft.com/windows/win32/api/setupapi/nf-setupapi-setupscanfilequeuea) is used to enumerate the file queue to display the list of files that are associated with the driver. DumpDeviceDriverNodes -- Provided as a debugging aid, this function determines the list of compatible drivers for a device. It uses [**SetupDiBuildDriverInfoList**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550917) to obtain the list of compatible drivers. In this case, all drivers are enumerated, however typically DIF\_SELECTBESTCOMPATDRV and [**SetupDiGetSelectedDriver**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552013) would be used together to find which driver the OS would consider to be the best. +- Provided as a debugging aid, this function determines the list of compatible drivers for a device. It uses [**SetupDiBuildDriverInfoList**](https://docs.microsoft.com/windows/win32/api/setupapi/nf-setupapi-setupdibuilddriverinfolist) to obtain the list of compatible drivers. In this case, all drivers are enumerated, however typically DIF\_SELECTBESTCOMPATDRV and [**SetupDiGetSelectedDriver**](https://docs.microsoft.com/windows/win32/api/setupapi/nf-setupapi-setupdigetselecteddrivera) would be used together to find which driver the OS would consider to be the best. DumpDeviceStack diff --git a/spb/SkeletonI2C/README.md b/spb/SkeletonI2C/README.md index 1e1efa4d..1affed0d 100644 --- a/spb/SkeletonI2C/README.md +++ b/spb/SkeletonI2C/README.md @@ -10,9 +10,9 @@ products: # Skeleton I2C Sample Driver -The SkeletonI2C sample demonstrates how to design a KMDF controller driver for Windows that conforms to the [simple peripheral bus](http://msdn.microsoft.com/en-us/library/windows/hardware/hh450903) (SPB) device driver interface (DDI). SPB is an abstraction for low-speed serial buses (for example, I<sup>2</sup>C and SPI) that allows peripheral drivers to be developed for cross-platform use without any knowledge of the underlying bus hardware or device connections. While this sample implements an empty I<sup>2</sup>C driver, it could just as easily be the starting point for an SPI driver with only minor modifications. +The SkeletonI2C sample demonstrates how to design a KMDF controller driver for Windows that conforms to the [simple peripheral bus](https://docs.microsoft.com/windows-hardware/design/component-guidelines/simple-peripheral-bus--spb-) (SPB) device driver interface (DDI). SPB is an abstraction for low-speed serial buses (for example, I<sup>2</sup>C and SPI) that allows peripheral drivers to be developed for cross-platform use without any knowledge of the underlying bus hardware or device connections. While this sample implements an empty I<sup>2</sup>C driver, it could just as easily be the starting point for an SPI driver with only minor modifications. -Note that the SkeletonI2C sample is simplified to show the overall structure of an SPB controller, but contains only the code that the driver requires to communicate with the [SPB framework extension (SpbCx)](http://msdn.microsoft.com/en-us/library/windows/hardware/hh406203) and KMDF. The SkeletonI2C sample driver omits all hardware-specific code. It does not simulate data transfers or implement request completion asynchronously. Pay close attention to code comments marked with "TODO" that refer to blocks of code that must be removed or updated. +Note that the SkeletonI2C sample is simplified to show the overall structure of an SPB controller, but contains only the code that the driver requires to communicate with the [SPB framework extension (SpbCx)](https://docs.microsoft.com/windows-hardware/drivers/spb/spb-framework-extension) and KMDF. The SkeletonI2C sample driver omits all hardware-specific code. It does not simulate data transfers or implement request completion asynchronously. Pay close attention to code comments marked with "TODO" that refer to blocks of code that must be removed or updated. The simplified structure of the SkeletonI2C sample driver makes it a convenient starting point for development of a real SPB controller driver that manages the hardware functions in an SPB controller. @@ -21,10 +21,15 @@ The simplified structure of the SkeletonI2C sample driver makes it a convenient Here are some high-level points to consider when modifying the SkeletonI2C sample for use on real hardware: - Edit (and likely rename) Skeletoni2c.h to describe your hardware's register set. + - Modify Controller.cpp and Device.cpp to translate the SPB DDI and primitives into I<sup>2</sup>C or SPI protocol for your hardware. This includes initialization, I/O configuration, and interrupt processing. + - Address any comments marked with "TODO" in the sample, especially those that short circuit the I/O path to complete requests synchronously. + - Modify the HWID (`ACPI\skeletoni2c`) in Skeletoni2c.inf to match the device node in your firmware. + - Generate and specify a unique trace GUID in I2ctrace.h. + - Refactor the driver name, functions, comments, etc., to better describe your implementation. ## Code tour @@ -33,25 +38,25 @@ Here are some high-level points to consider when modifying the SkeletonI2C sampl The following are relevant functions in the SkeletonI2C driver for implementing the SPB DDI. -INITIALIZATION +#### INITIALIZATION `OnDeviceAdd` Within `OnDeviceAdd`, the driver makes several configuration calls for SPB. -[**SpbDeviceInitConfig**](http://msdn.microsoft.com/en-us/library/windows/hardware/hh450918) must be called before creating the WDFDEVICE. Note that SpbCx sets a default security descriptor on the device object, but the controller driver can override it by calling [**WdfDeviceInitAssignSDDLString**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff546035) after **SpbDeviceInitConfig**. +[**SpbDeviceInitConfig**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/spbcx/nf-spbcx-spbdeviceinitconfig) must be called before creating the WDFDEVICE. Note that SpbCx sets a default security descriptor on the device object, but the controller driver can override it by calling [**WdfDeviceInitAssignSDDLString**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/wdfdevice/nf-wdfdevice-wdfdeviceinitassignsddlstring) after **SpbDeviceInitConfig**. -After creating the WDFDEVICE, the driver configures it appropriately for SPB by calling [**SpbDeviceInitialize**](http://msdn.microsoft.com/en-us/library/windows/hardware/hh450919). Here the driver also sets the target and request attributes. +After creating the WDFDEVICE, the driver configures it appropriately for SPB by calling [**SpbDeviceInitialize**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/spbcx/nf-spbcx-spbdeviceinitialize). Here the driver also sets the target and request attributes. Finally the driver configures a WDF system-managed idle time-out. -TARGET CONNECTION +#### TARGET CONNECTION `OnTargetConnect` Invoked when a client opens a handle to the specified SPB target. Queries the I<sup>2</sup>C connection parameters from the resource hub (via SPB) and initializes the target context. -SPB I/O CALLBACKS +#### SPB I/O CALLBACKS `OnRead` @@ -81,7 +86,7 @@ Configures the request context for the specified transfer index. This could be a `PbcRequestComplete` -Sets the number of bytes completed for a request and invokes the [**SpbRequestComplete**](http://msdn.microsoft.com/en-us/library/windows/hardware/hh450920) method. +Sets the number of bytes completed for a request and invokes the [**SpbRequestComplete**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/spbcx/nf-spbcx-spbrequestcomplete) method. \*An atomic transfer in SPB is implemented using Sequence or a Lock/Unlock pair. For I<sup>2</sup>C, this means a set of reads and writes with restarts in between. For SPI, this means a set of reads and writes with the chip select-line asserted throughout. @@ -89,7 +94,7 @@ Sets the number of bytes completed for a request and invokes the [**SpbRequestCo The following are relevant functions in the SkeletonI2C driver for implementing controller-specific I2C protocol. For the most part, these are placeholders and must be filled in appropriately. -INITIALIZATION +#### INITIALIZATION (controller-specific) `ControllerInitialize` @@ -101,7 +106,7 @@ Per-I/O controller configuration. Depending on the type of I/O (and whether its Additionally, for I<sup>2</sup>C, the driver may need to insert a start, restart, or stop bit as necessary, and for SPI the driver may need to assert or de-assert the chip select line. -I/O PROCESSING +#### I/O PROCESSING `OnInterruptIsr` diff --git a/spb/SpbTestTool/README.md b/spb/SpbTestTool/README.md index 3f4c4680..e771969b 100644 --- a/spb/SpbTestTool/README.md +++ b/spb/SpbTestTool/README.md @@ -10,16 +10,18 @@ products: # SpbTestTool -The SpbTestTool sample serves two purposes. First, it demonstrates how to open a handle to the [SPB controller](http://msdn.microsoft.com/en-us/library/windows/hardware/hh698220), use the SPB interface from a KMDF driver, and employ GPIO [passive-level interrupts](http://msdn.microsoft.com/en-us/library/windows/hardware/hh451035). Second, it implements a set of commands for communicating with a peripheral device to aid in debugging. +The SpbTestTool sample serves two purposes. First, it demonstrates how to open a handle to the [SPB controller](https://docs.microsoft.com/windows-hardware/drivers/spb/spb-controller-drivers), use the SPB interface from a KMDF driver, and employ GPIO [passive-level interrupts](https://docs.microsoft.com/windows-hardware/drivers/wdf/supporting-passive-level-interrupts). Second, it implements a set of commands for communicating with a peripheral device to aid in debugging. -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. +This sample is incomplete as a driver and merely demonstrates use of the [SPB I/O request interface](https://docs.microsoft.com/windows-hardware/drivers/spb/using-the-spb-i-o-request-interface) and [GPIO interrupts](https://docs.microsoft.com/windows-hardware/drivers/gpio/gpio-interrupts). It is not intended for use in a production environment. ## Run the sample To install the SpbTestTool peripheral driver, follow these steps: 1. Ensure that the driver builds without errors. + 1. Copy the SYS and INF files to a separate folder. + 1. Run Devcon.exe. You can find this program in the tools\\devcon folder where you installed the WDK. Type the following command in the command window: `devcon.exe update SpbTestTool.inf ACPI\<hwid>` @@ -44,74 +46,74 @@ To launch the SpbTestTool application, follow these steps: 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 | 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. +| 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. | ## Code tour The following are the relevant functions in the SpbTestTool peripheral driver for using the SPB interface from a KMDF driver. -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. +| 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 The following source files are in the \\SpbTestTool\\sys folder and are used to build the SpbTestTool.sys and SpbTestTool.inf files. -File | Description ------|------------ -driver.h, driver.cpp | Events on the Device Object, and read, write, and IOCTLs from the SpbTestTool application. Implements the driver's interrupt service routine. -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. +| 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 \\SpbTestTool\\exe folder and are used to build the SpbTestTool.exe file. -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 +| File | Description | +| --- | --- | +| command.h, command.cpp | Classes representing 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 56e68f15..4b081014 100644 --- a/storage/class/cdrom/README.md +++ b/storage/class/cdrom/README.md @@ -15,7 +15,9 @@ The CD ROM driver is used to provide access to CD, DVD and Blu-ray drives. It su ## 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 @@ -24,8 +26,11 @@ You build a driver the same way you build any project or solution in Visual Stud 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). + 1. Right-click the solution in the **Solutions Explorer** and select **Configuration Manager**. + 1. 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. + 1. From the Build menu, click **Build Solution** (Ctrl+Shift+B). ## Building a Driver Using the Command Line (MSBuild) @@ -33,25 +38,37 @@ The default Solution build configuration is Visual Studio Debug and Win32. You can build a driver from the command line using the Visual Studio Command Prompt window and the Microsoft Build Engine (MSBuild.exe) 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 now use the Visual Studio Command Prompt window for all build configurations. 1. Open a Visual Studio Command Prompt window at the **Start** screen. From this window you can use MsBuild.exe to build any Visual Studio project by specifying the project (.VcxProj) or solutions (.Sln) file. + 1. 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 *filtername*.vcxproj, navigate to the project directory and enter the following MSBuild command: - **msbuild /t:clean /t:build .\\***samplename***.vcxproj**. + `msbuild /t:clean /t:build .\<samplename>.vcxproj` ## Installation and Operation The in-box CD ROM driver is protected by the system, and thus a normal device driver update attempt through the Device Manager will fail. Users are not encouraged to replace the in-box CD ROM driver. The following work-around is provided in case there is a need, but the users are warned that this may harm the system. 1. Locate the "cdrom.inf" file in the binary output directory, and update the file by replacing all "cdrom.sys" occurrences with "mycdrom.sys". + 1. Rename the "cdrom.inf" file to "mycdrom.inf". + 1. Copy "mycdrom.sys" and "mycdrom.inf" from the binary output directory to the test machine, if applicable. + 1. Launch the Device Manager + 1. Select the appropriate device under the "DVD/CD-ROM drives" category. + 1. On the right-click menu, select "Update Driver Software...". + 1. Select "Browse my computer for driver software". + 1. Select "Let me pick from a list of device drivers on my computer". + 1. Click "Have Disk...", and point to the directory that contains "mycdrom.inf" and "mycdrom.sys". + 1. Click "Next". If you get a warning dialog about installing unsigned driver, click "Yes". + 1. Click "Next" to complete the driver upgrade. + 1. After installation completes successfully, "mycdrom.sys" will be the effective driver for the device, "cdrom.sys" will no longer be used. For more information, see [CD-ROM Drivers](https://docs.microsoft.com/windows-hardware/drivers/storage/cd-rom-drivers) in the storage technologies design guide. diff --git a/storage/class/classpnp/README.md b/storage/class/classpnp/README.md index 2de5c329..f89e774a 100644 --- a/storage/class/classpnp/README.md +++ b/storage/class/classpnp/README.md @@ -8,17 +8,6 @@ products: - windows-wdk --- - - -<!--- - name: ClassPnP Class Driver Library - platform: WDM - language: cpp - category: Storage - description: A library storage class driver used by disk, CDROM, and the tape class drivers. - samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617978 ----> - # ClassPnP Storage Class Driver Library This is the library for all storage drivers. It simplifies writing a storage class driver by implementing 90 percent of the code that you need to support Plug and Play (PnP), power management, and so on. This library is used by disk, CDROM, and the tape class drivers. @@ -31,4 +20,4 @@ This sample builds a Universal Windows Driver. It uses only APIs and DDIs that a The storage class drivers are used to interact with mass storage devices along with appropriate port driver. The class drivers are layered above the port drivers and manage mass storage devices of a specific class, regardless of their bus type. The classpnp sample contains the common routines that are required for all storage class drivers such as PnP and power management. It also provides I/O and error handling support. -For more information, see [Introduction to Storage Class Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff559215) in the storage technologies design guide.
\ No newline at end of file +For more information, see [Introduction to Storage Class Drivers](https://docs.microsoft.com/windows-hardware/drivers/storage/introduction-to-storage-class-drivers) in the storage technologies design guide. diff --git a/storage/class/disk/README.md b/storage/class/disk/README.md index 8dd297bd..d1518c0e 100644 --- a/storage/class/disk/README.md +++ b/storage/class/disk/README.md @@ -8,17 +8,6 @@ products: - windows-wdk --- - - -<!--- - name: Disk Class Driver - platform: WDM - language: cpp - category: Storage - description: A class driver for disk devices. - samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617979 ----> - # Disk Class Driver The disk class driver sample is used for managing disk devices @@ -32,8 +21,11 @@ You build a driver the same way you build any project or solution in Visual Stud The default Solution build configuration is Debug and Win32. 1. Open the driver project or solution in Visual Studio (find *samplename*.sln or *samplename*.vcxproj). + 1. Right-click the solution in the **Solutions Explorer** and select **Configuration Manager**. + 1. 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. + 1. From the Build menu, click **Build Solution** (Ctrl+Shift+B). ## Building a Driver Using the Command Line (MSBuild) @@ -41,10 +33,13 @@ The default Solution build configuration is Debug and Win32. You can build a driver from the command line using the Visual Studio Command Prompt window and the Microsoft Build Engine (MSBuild.exe) 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 now use the Visual Studio Command Prompt window for all build configurations. 1. Open a Visual Studio Command Prompt window at the **Start** screen. From this window you can use MsBuild.exe to build any Visual Studio project by specifying the project (.VcxProj) or solutions (.Sln) file. -1. 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 *filtername*.vcxproj, navigate to the project directory and enter the following MSBuild command: **msbuild /t:clean /t:build .\\***samplename***.vcxproj**. + +1. 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 *filtername*.vcxproj, navigate to the project directory and enter the following MSBuild command: + + `msbuild /t:clean /t:build .\<samplename>.vcxproj` ## Installation and Operation The disk class driver is used to interact with disk devices along with the appropriate port driver. The disk class driver is layered above the port driver and manages disk devices regardless of their bus type. This driver attaches to the disk devices that are enumerated by all of the storage port drivers. This driver exposes the required functionality to the file system drivers to access the disk devices. -For more information, see [Introduction to Storage Class Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff559215) in the storage technologies design guide.
\ No newline at end of file +For more information, see [Introduction to Storage Class Drivers](https://docs.microsoft.com/windows-hardware/drivers/storage/introduction-to-storage-class-drivers) in the storage technologies design guide. diff --git a/storage/filters/addfilter/README.md b/storage/filters/addfilter/README.md index 4ffe9c45..149922df 100644 --- a/storage/filters/addfilter/README.md +++ b/storage/filters/addfilter/README.md @@ -8,17 +8,6 @@ products: - windows-wdk --- - - -<!--- - name: AddFilter Storage Filter Tool - platform: Application - language: cpp - category: Storage - description: A command-line application that adds and removes filter drivers for a given drive or volume. - samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617980 ----> - # AddFilter Storage Filter Tool Addfilter is a command-line application that adds and removes filter drivers for a given drive or volume. This application demonstrates how to insert a filter driver into the driver stack of a device. The sample illustrates how to insert such a filter driver by using the SetupDi API. @@ -29,7 +18,8 @@ This initial sample does not check the filter for validity before it is added to The minifilter identifies implicit locks when it sees a non-shared write open request on a volume object. In this scenario, the minifilter closes its metadata file and sets a trigger that corresponds to the volume in its instance object. Later, each close operation is examined to identify if the implicit lock on the volume is being released and, if so, a re-open of the minifilter's metadata file is triggered. -**Important** If you attempt to add a non-existing filter to a boot device and then restart, the system might show the INACCESSIBLE\_BOOT\_DEVICE error message. If this message appears, you will be unable to start the computer. To fix this problem, when the startup menu is displayed when the computer starts up, go to the Advanced Options screen and select **Use Last Known Good Profile**. +> [!IMPORTANT] +> If you attempt to add a non-existing filter to a boot device and then restart, the system might show the INACCESSIBLE\_BOOT\_DEVICE error message. If this message appears, you will be unable to start the computer. To fix this problem, when the startup menu is displayed when the computer starts up, go to the Advanced Options screen and select **Use Last Known Good Profile**. The sample is intended for use with upper filter drivers only. @@ -39,6 +29,6 @@ Because the sample currently enumerates only disk devices, the sample can operat The following is the command line usage for addfilter: - **addfilter [/listdevices] [/device device\_name] [/add filter] [/remove filter]** +`addfilter [/listdevices] [/device device_name] [/add filter] [/remove filter]` -If the device name is not supplied, settings will apply to all devices. If there is no /add or /remove argument, a list of currently installed drivers will be printed.
\ No newline at end of file +If the device name is not supplied, settings will apply to all devices. If there is no /add or /remove argument, a list of currently installed drivers will be printed. diff --git a/storage/iscsi/README.md b/storage/iscsi/README.md index e7275c01..b219a099 100644 --- a/storage/iscsi/README.md +++ b/storage/iscsi/README.md @@ -8,21 +8,10 @@ products: - windows-wdk --- - - -<!--- - name: iSCSI WMI Client - platform: WDM - language: cpp - category: Storage - description: A WMI iSCSI miniport that can be tested using the iSCSICLI.exe tool, the iSCSI Initiator Properties page, the WBEMTEST.exe tool, and customized WMI scripts. - samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617981 ----> - # iSCSI WMI Client WMI Implementation in an iSCSI miniport can be tested using the iSCSICLI.exe tool, the iSCSI Initiator Properties page, the WBEMTEST.exe tool, and customized WMI scripts ## Installation and Operation -The iSCSI WMI sample uses the iSCSI WMI Class, and MOF definitions described at [iSCSI WMI Classes](http://msdn.microsoft.com/en-us/library/windows/hardware/ff561578) in the storage WMI classes reference. Their corresponding class structure details are described at [iSCSI Structures](http://msdn.microsoft.com/en-us/library/windows/hardware/ff561569).
\ No newline at end of file +The iSCSI WMI sample uses the iSCSI WMI Class, and MOF definitions described at [iSCSI WMI Classes](https://docs.microsoft.com/windows-hardware/drivers/storage/iscsi-wmi-classes) in the storage WMI classes reference. Their corresponding class structure details are described at [iSCSI Structures](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/index). diff --git a/storage/miniports/lsi_u3/README.md b/storage/miniports/lsi_u3/README.md index 86b970a9..55f16b34 100644 --- a/storage/miniports/lsi_u3/README.md +++ b/storage/miniports/lsi_u3/README.md @@ -8,20 +8,11 @@ products: - windows-wdk --- - - -<!--- - name: LSI_U3 StorPort Miniport Driver - platform: WDM - language: cpp - category: Storage - description: An adapter driver for use with Parallel SCSI Host Bus Adapters or on-motherboard solutions that use the LSI 53C1010 SCSI ASIC. - samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617982 ----> - # LSI\_U3 StorPort Miniport Driver -The LSI\_U3 sample is an adapter driver for use with Parallel SCSI Host Bus Adapters or on-motherboard solutions that use the LSI 53C1010 SCSI ASIC.These sources are presented for your education and use with these generally available LSI SCSI-class adapters. The intended use of this sample driver is for this purpose only. +The LSI\_U3 sample is an adapter driver for use with Parallel SCSI Host Bus Adapters or on-motherboard solutions that use the LSI 53C1010 SCSI ASIC. + +These sources are presented for your education and use with these generally available LSI SCSI-class adapters. The intended use of this sample driver is for this purpose only. ## Universal Windows Driver Compliant @@ -32,6 +23,7 @@ This sample builds a Universal Windows Driver. It uses only APIs and DDIs that a The operation of this sample requires one of the following hardware items: - Parallel SCSI Host Bus Adapter + - On-motherboard solution that uses the LSI 53C1010 SCSI ASIC -For more information, see [Storport Miniport Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff567562) in the storage technologies design guide.
\ No newline at end of file +For more information, see [Storport Miniport Drivers](https://docs.microsoft.com/windows-hardware/drivers/storage/storport-miniport-drivers) in the storage technologies design guide. diff --git a/storage/miniports/storahci/README.md b/storage/miniports/storahci/README.md index 0f2ab36e..fdfcc176 100644 --- a/storage/miniports/storahci/README.md +++ b/storage/miniports/storahci/README.md @@ -8,21 +8,10 @@ products: - windows-wdk --- - - -<!--- - name: StorAHCI StorPort Miniport - platform: WDM - language: cpp - category: Storage - description: A sample Storport ACHI miniport driver. - samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617983 ----> - # StorAhci StorPort Miniport Driver The StorAhci sample is a Storport ACHI miniport driver. ## Universal Windows Driver Compliant -This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP.
\ No newline at end of file +This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. diff --git a/storage/msdsm/README.md b/storage/msdsm/README.md index 06fa8759..42ba9bc3 100644 --- a/storage/msdsm/README.md +++ b/storage/msdsm/README.md @@ -21,8 +21,11 @@ You build a driver the same way you build any project or solution in Visual Stud The default Solution build configuration is **Debug** and **Win32**. 1. Open the driver project or solution in Visual Studio (find *samplename*.sln or *samplename*.vcxproj). + 1. Right-click the solution in the **Solutions Explorer** and select **Configuration Manager**. + 1. 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. + 1. From the Build menu, click **Build Solution** (Ctrl+Shift+B). ## Building a Driver Using the Command Line (MSBuild) @@ -30,9 +33,10 @@ The default Solution build configuration is **Debug** and **Win32**. You can build a driver from the command line using the Visual Studio Command Prompt window and the Microsoft Build Engine (MSBuild.exe) 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 now use the Visual Studio Command Prompt window for all build configurations. 1. Open a Visual Studio Command Prompt window at the **Start** screen. From this window you can use MsBuild.exe to build any Visual Studio project by specifying the project (.VcxProj) or solutions (.Sln) file. + 1. 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 *filtername*.vcxproj, navigate to the project directory and enter the following MSBuild command: - **msbuild /t:clean /t:build .\\<*samplename*>.vcxproj**. + `msbuild /t:clean /t:build .\<samplename>.vcxproj` ## Installation and Operation diff --git a/storage/sfloppy/README.md b/storage/sfloppy/README.md index 0ca05293..d05748df 100644 --- a/storage/sfloppy/README.md +++ b/storage/sfloppy/README.md @@ -8,17 +8,6 @@ products: - windows-wdk --- - - -<!--- - name: Super Floppy (sfloppy) Storage Class Driver - platform: WDM - language: cpp - category: Storage - description: A sample class driver for Super Floppy disk drives. - samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617989 ----> - # Super Floppy (sfloppy) Storage Class Driver The sfloppy sample is a super floppy driver. This driver is a class driver for Super Floppy disk drives. @@ -29,6 +18,6 @@ This sample builds a Universal Windows Driver. It uses only APIs and DDIs that a ## Installation and Operation -This sample sits a level above the port driver (ATAPI, USB, and so on) in the driver stack and controls communication between the application level and the port driver. The floppy driver takes requests from file system drivers and then sends the appropriate [**SCSI\_REQUEST\_BLOCK**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff565393) (SRB) to the port driver. +This sample sits a level above the port driver (ATAPI, USB, and so on) in the driver stack and controls communication between the application level and the port driver. The floppy driver takes requests from file system drivers and then sends the appropriate [**SCSI\_REQUEST\_BLOCK**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/srb/ns-srb-_scsi_request_block) (SRB) to the port driver. -For more information, see [Introduction to Storage Class Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff559215) in the storage technologies design guide.
\ No newline at end of file +For more information, see [Introduction to Storage Class Drivers](https://docs.microsoft.com/windows-hardware/drivers/storage/introduction-to-storage-class-drivers) in the storage technologies design guide. diff --git a/storage/tools/spti/README.md b/storage/tools/spti/README.md index 9c4bd2c9..b0d08237 100644 --- a/storage/tools/spti/README.md +++ b/storage/tools/spti/README.md @@ -8,23 +8,12 @@ products: - windows-wdk --- - - -<!--- - name: SCSI Pass-Through Interface Tool - platform: Application - language: cpp - category: Storage - description: Demonstrates how to communicate with a SCSI device using pass-through IOCTLs in an application using DeviceIoControl API. - samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617990 ----> - # SCSI Pass-Through Interface Tool The SCSI Pass Through Interface sample demonstrates how to communicate with a SCSI device from Microsoft Win32 applications by using the **DeviceIoControl** API. ## Installation and Operation -The storage port drivers provide an interface for Win32 applications to send SCSI CBDs (Command Descriptor Block) to SCSI devices. The interfaces are [**IOCTL\_SCSI\_PASS\_THROUGH**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560519) and [**IOCTL\_SCSI\_PASS\_THROUGH\_DIRECT**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560521). Applications can build a pass-through request and send it to the device by using this IOCTL. +The storage port drivers provide an interface for Win32 applications to send SCSI CBDs (Command Descriptor Block) to SCSI devices. The interfaces are [**IOCTL\_SCSI\_PASS\_THROUGH**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/ntddscsi/ni-ntddscsi-ioctl_scsi_pass_through) and [**IOCTL\_SCSI\_PASS\_THROUGH\_DIRECT**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/ntddscsi/ni-ntddscsi-ioctl_scsi_pass_through_direct). Applications can build a pass-through request and send it to the device by using this IOCTL. -Two command line parameters can be used with *SPTI.EXE*. The first parameter is mandatory. It is the name of the device to be opened. Typical values for this are drive letters such as "C:", or device names as defined by a class driver such as Scanner0, or the SCSI port driver name, ScsiN:, where N = 0, 1, 2, etc. The second parameter is optional and is used to set the share mode (note that access mode and share mode are different things) and sector size. The default share mode is (FILE\_SHARE\_READ | FILE\_SHARE\_WRITE) and the default sector size is 512. A parameter of "r" changes the share mode to only FILE\_SHARE\_READ. A parameter of "w" changes the share mode to only FILE\_SHARE\_WRITE. A parameter of "c" changes the share mode to only FILE\_SHARE\_READ and also changes the sector size to 2048. Typically, a CD-ROM device would use the "c" parameter.
\ No newline at end of file +Two command line parameters can be used with *SPTI.EXE*. The first parameter is mandatory. It is the name of the device to be opened. Typical values for this are drive letters such as "C:", or device names as defined by a class driver such as Scanner0, or the SCSI port driver name, ScsiN:, where N = 0, 1, 2, etc. The second parameter is optional and is used to set the share mode (note that access mode and share mode are different things) and sector size. The default share mode is (FILE\_SHARE\_READ | FILE\_SHARE\_WRITE) and the default sector size is 512. A parameter of "r" changes the share mode to only FILE\_SHARE\_READ. A parameter of "w" changes the share mode to only FILE\_SHARE\_WRITE. A parameter of "c" changes the share mode to only FILE\_SHARE\_READ and also changes the sector size to 2048. Typically, a CD-ROM device would use the "c" parameter. diff --git a/thermal/simsensor/README.md b/thermal/simsensor/README.md index 0e8153ff..ee308112 100644 --- a/thermal/simsensor/README.md +++ b/thermal/simsensor/README.md @@ -8,16 +8,6 @@ products: - windows-wdk --- - -<!--- - name: SimSensor - Simulated Temperature Sensor Sample Driver - platform: KMDF - language: cpp - category: Thermal Power - description: Demonstrates a simulated temperature sensor device. - samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617991 ----> - # SimSensor - Simulated Temperature Sensor Sample Driver This sample is a driver for a simulated temperature sensor device. @@ -26,6 +16,6 @@ This sample is a driver for a simulated temperature sensor device. This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. -A hardware platform designer can strategically place temperature sensors in various thermal zones around the platform. The operating system gets the temperature readings from the temperature sensor drivers and uses these readings to regulate the temperatures across the platform. Regulation can be either passive or active. For more information, see [Device-Level Thermal Management](http://msdn.microsoft.com/en-us/library/windows/hardware/hh698236). +A hardware platform designer can strategically place temperature sensors in various thermal zones around the platform. The operating system gets the temperature readings from the temperature sensor drivers and uses these readings to regulate the temperatures across the platform. Regulation can be either passive or active. For more information, see [Device-Level Thermal Management](https://docs.microsoft.com/windows-hardware/drivers/kernel/device-level-thermal-management). -The SimSensor sample provides the source code for a specialized sensor driver that supports platform-wide thermal management by the operating system. This driver does not make the temperature sensor accessible to applications through the [Sensor API](http://msdn.microsoft.com/en-us/library/windows/hardware/dd318953).
\ No newline at end of file +The SimSensor sample provides the source code for a specialized sensor driver that supports platform-wide thermal management by the operating system. This driver does not make the temperature sensor accessible to applications through the [Sensor API](https://docs.microsoft.com/windows/win32/sensorsapi/portal). diff --git a/thermal/thermalclient/README.md b/thermal/thermalclient/README.md index 2074cd65..35405f86 100644 --- a/thermal/thermalclient/README.md +++ b/thermal/thermalclient/README.md @@ -8,22 +8,14 @@ products: - windows-wdk --- - -<!--- - name: SimThermalClient - Simulated Thermal Client Sample Driver - platform: KMDF - language: cpp - category: Thermal Power - description: Simulates a device that is a Windows thermal management client. - samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617992 ----> - # 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. 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](https://docs.microsoft.com/windows-hardware/drivers/kernel/global-thermal-mgmt) 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. -For more information, see [Device-Level Thermal Management](http://msdn.microsoft.com/en-us/library/windows/hardware/hh698236).
\ No newline at end of file +## See also + +[Device-Level Thermal Management](https://docs.microsoft.com/windows-hardware/drivers/kernel/device-level-thermal-management) |