Skip to content

Commit

Permalink
Update README.md (microsoft#424)
Browse files Browse the repository at this point in the history
  • Loading branch information
barrygolden authored Sep 25, 2019
1 parent 16022c5 commit 2e23771
Show file tree
Hide file tree
Showing 30 changed files with 224 additions and 403 deletions.
2 changes: 1 addition & 1 deletion network/ndis/filter/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -82,7 +82,7 @@ On the host computer, in **Visual Studio**, in the **Debug** menu, choose **Atta
> [!NOTE]
> If you see a dialog box that asks you to allow the debugger to communicate through the firewall, click the boxes for all types of networks. Click **Allow Access**.
For more information, see [Setting Up Kernel-Mode Debugging in Visual Studio](http://msdn.microsoft.com/library/windows/hardware/hh439376).
For more information, see [Setting Up Kernel-Mode Debugging in Visual Studio](https://docs.microsoft.com/windows-hardware/drivers/debugger/setting-up-kernel-mode-debugging-in-visual-studio).

### Setting up kernel-mode debugging manually

Expand Down
2 changes: 1 addition & 1 deletion network/trans/msnmntr/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -86,4 +86,4 @@ As an alternative to building the WFP MSN Messenger Monitor Sample in Visual Stu

`msbuild /p:configuration="Release" /p:platform="Win32" msnmntr.sln`

For more information about using [MSBuild](https://docs.microsoft.com/visualstudio/msbuild/msbuild?view=vs-2019) to build a driver package, see [Building a Driver Using the Command Line (MSBuild)](https://docs.microsoft.com/en-us/windows-hardware/drivers/develop/building-a-driver#building-a-driver-using-the-command-line-msbuild).
For more information about using [MSBuild](https://docs.microsoft.com/visualstudio/msbuild/msbuild?view=vs-2019) to build a driver package, see [Building a Driver Using the Command Line (MSBuild)](https://docs.microsoft.com/windows-hardware/drivers/develop/building-a-driver#building-a-driver-using-the-command-line-msbuild).
10 changes: 0 additions & 10 deletions nfp/net/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,16 +8,6 @@ products:
- windows-wdk
---


<!---
name: Near-Field Proximity Sample Driver (UMDF Version 1)
platform: UMDF1
language: cpp
category: Proximity
description: Demonstrates how to use UMDF version 1 to write a near-field proximity driver.
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=620200
--->

# Near-Field Proximity Sample Driver (UMDF Version 1)

> [!WARNING]
Expand Down
18 changes: 5 additions & 13 deletions pofx/PEP/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,22 +8,14 @@ products:
- windows-wdk
---


<!---
name: Power Engine Plugin (PEP) ACPI Sample
platform: KMDF
language: cpp
category: ACPI Power
description: Demonstrates an interface which allows PEP to implement ACPI runtime methods natively via a driver.
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=620311
--->

# PEP ACPI Sample

The Power Engine Plugin (PEP) provides interfaces for platform power management including device power management (DPM), processor power management (PPM), and, starting with Windows 10, ACPI runtime methods. This sample documents the latter: an interface which allows a PEP to implement ACPI runtime methods natively via a Windows driver rather than firmware (AML). A PEP using the ACPI interface is often called a Platform Extension. Note that this interface can be used independently or in conjunction with the DPM and/or PPM interfaces as appropriate.

Use the PEP ACPI interface if:

* You want to write peripheral (off-SoC) device power management in C rather than in ACPI Source Language (ASL).
* You need to override an ACPI method which exists in a platform's DSDT or SSDT firmware tables.
* Shipping, maintaining, and updating a driver binary suits your platform better than firmware updates (note that you will still need FADT, MADT, DBG2, and so on in firmware - this interface is only for runtime methods).
- You want to write peripheral (off-SoC) device power management in C rather than in ACPI Source Language (ASL).

- You need to override an ACPI method which exists in a platform's DSDT or SSDT firmware tables.

- Shipping, maintaining, and updating a driver binary suits your platform better than firmware updates (note that you will still need FADT, MADT, DBG2, and so on in firmware, this interface is only for runtime methods).
41 changes: 23 additions & 18 deletions pofx/UMDF2/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,47 +16,52 @@ This solution demonstrates how a User-Mode Driver Framework (UMDF) version 2 dri

This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP.

Related technologies
--------------------
For related information, see the [KMDF Power Framework (PoFx) Sample](http://go.microsoft.com/fwlink/p/?LinkId=617937).
## Related technologies

[User-Mode Driver Framework](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560456)
[KMDF Power Framework (PoFx) Sample](https://docs.microsoft.com/samples/microsoft/windows-driver-samples/kmdf-power-framework-pofx-sample/).

Run the sample
--------------
[User-Mode Driver Framework](https://docs.microsoft.com/windows-hardware/drivers/wdf/getting-started-with-umdf-version-2)

## Run the sample

The computer where you install the driver is called the *target computer* or the *test computer*. Typically this is a separate computer from where you develop and build the driver package. The computer where you develop and build the driver is called the *host computer*.

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 (root enumerated)

Before you automatically deploy a driver, you must provision the target computer. For instructions, see [Configuring a Computer for Driver Deployment, Testing, and Debugging](http://msdn.microsoft.com/en-us/library/windows/hardware/).
Before you automatically deploy a driver, you must provision the target computer. For instructions, see [Provision a computer for driver deployment and testing](https://docs.microsoft.com/windows-hardware/drivers/gettingstarted/provision-a-target-computer-wdk-8-1).

After you have provisioned the target computer, continue with these steps:

1. On the host computer, in Visual Studio, in Solution Explorer, right click **package** (lower case), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**.

1. 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**.
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 **root\\SingleComponentSingleState** for the hardware ID. Click **OK**.
3. On the **Build** menu, choose **Build Solution**.
1. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, select the name of a target computer that you provisioned previously. Select **Hardware ID Driver Update**, and enter **root\\SingleComponentSingleState** for the hardware ID. Click **OK**.

1. On the **Build** menu, choose **Build Solution**.

### Manual deployment (root enumerated)

Before you manually deploy a driver, you must turn on test signing and install a certificate on the target computer. You also need to copy the [DevCon](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544707) tool to the target computer. For instructions, see [Preparing a Computer for Manual Driver Deployment](https://docs.microsoft.com/en-us/windows-hardware/drivers/develop/preparing-a-computer-for-manual-driver-deployment).
Before you manually deploy a driver, you must turn on test signing and install a certificate on the target computer. You also need to copy the [DevCon](https://docs.microsoft.com/windows-hardware/drivers/devtest/devcon) tool to the target computer. For instructions, see [Preparing a Computer for Manual Driver Deployment](https://docs.microsoft.com/windows-hardware/drivers/develop/preparing-a-computer-for-manual-driver-deployment).

After you have prepared the target computer for manual deployment, continue with these steps:

1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\PoFx).

1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\PoFx).
2. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter the following command:
1. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter the following command:

**devcon install SingleComponentSingleStateUm.inf root\\SingleComponentSingleState**
`devcon install SingleComponentSingleStateUm.inf root\\SingleComponentSingleState`

### View the root enumerated 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 **UMDF 2.0 Single Component Single State Device** (for example, this might be under the **Sample Device** node).

In Device Manager, on the **View** menu, choose **Devices by connection**. Locate **UMDF 2.0 Single Component Single State Device** as a child of the root node of the device tree.

Build the sample using MSBuild
------------------------------
## Build the sample using MSBuild

As an alternative to building the driver sample in Visual Studio, you can build it in a Visual Studio Command Prompt window. In Visual Studio, on the **Tools** menu, choose **Visual Studio Command Prompt**. In the Visual Studio Command Prompt window, navigate to the folder that has the solution file, PoFx.sln. Use the MSBuild command to build the solution. Here is an example:

**msbuild /p:configuration="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).
For more information about using [MSBuild](https://docs.microsoft.com/visualstudio/msbuild/msbuild?view=vs-2019) to build a driver package, see [Building a Driver with Visual Studio and the WDK](https://docs.microsoft.com/windows-hardware/drivers/develop/building-a-driver).
Loading

0 comments on commit 2e23771

Please sign in to comment.