From 9026073a419b5ef68fb46d4f7fae52dbef09dbe1 Mon Sep 17 00:00:00 2001 From: Barry Golden Date: Thu, 6 Aug 2015 20:06:07 -0700 Subject: Remove obsolete readme.htm files --- avstream/avshws/avshws.htm | 458 ---- avstream/avssamp/avssamp.htm | 297 --- bluetooth/bthecho/bthecho.htm | 2222 ---------------- .../serialhcibus/BluetoothHCISampleBusDriver.htm | 2333 ----------------- general/SystemDma/wdm/systemdma.htm | 741 ------ general/cancel/cancel.htm | 302 --- general/event/event.htm | 229 -- general/ioctl/wdm/ioctl.htm | 742 ------ general/perfcounters/kcs/kcs.htm | 757 ------ general/toaster/toastpkg/toastpkg.htm | 186 -- general/tracing/evntdrv/evntdrv.htm | 189 -- general/tracing/tracedriver/tracedrv.htm | 1052 -------- hid/firefly/firefly.htm | 101 - hid/hclient/hclient.htm | 775 ------ input/kbfiltr/kbfiltr.htm | 465 ---- input/moufiltr/Moufiltr.htm | 699 ----- network/config/bindview/bindview.htm | 345 --- network/modem/fakemodem/fakemodem.htm | 926 ------- network/ndis/filter/filter.htm | 152 -- network/ndis/mux/driver/60/mux.htm | 617 ----- network/ndis/mux/notifyob/notify.htm | 552 ---- network/ndis/ndisprot/6x/ndisprot.htm | 393 --- network/ndis/ndisprot_kmdf/ndisprot.htm | 197 -- nfp/net/NetNfpProvider.htm | 1240 --------- print/autoconfig/AutoConfig.htm | 367 --- print/cpsuisam/cpsui.htm | 236 -- sd/sdiomars/sdiosample.htm | 356 --- security/elam/elamsample.htm | 1110 -------- serial/serenum/serenum.htm | 203 -- setup/devcon/devcon.htm | 680 ----- smartcrd/pscr/pscr.htm | 867 ------- spb/SpbTestTool/SpbTestTool.htm | 2688 -------------------- storage/class/cdrom/src/cdrom.htm | 86 - storage/class/classpnp/src/classpnp.htm | 273 -- storage/class/disk/src/disk.htm | 42 - storage/filters/addfilter/src/addfiltr.htm | 245 -- storage/sfloppy/src/sfloppy.htm | 187 -- storage/tools/spti/src/spti.htm | Bin 109034 -> 0 bytes usb/usbview/usbview.htm | 400 --- wpd/WpdHelloWorldDriver/WpdHelloWorldDriver.htm | 536 ---- .../WpdMultiTransportDriver.htm | 535 ---- wpd/WpdWudfSampleDriver/WpdWudfSampleDriver.htm | 496 ---- 42 files changed, 25277 deletions(-) delete mode 100644 avstream/avshws/avshws.htm delete mode 100644 avstream/avssamp/avssamp.htm delete mode 100644 bluetooth/bthecho/bthecho.htm delete mode 100644 bluetooth/serialhcibus/BluetoothHCISampleBusDriver.htm delete mode 100644 general/SystemDma/wdm/systemdma.htm delete mode 100644 general/cancel/cancel.htm delete mode 100644 general/event/event.htm delete mode 100644 general/ioctl/wdm/ioctl.htm delete mode 100644 general/perfcounters/kcs/kcs.htm delete mode 100644 general/toaster/toastpkg/toastpkg.htm delete mode 100644 general/tracing/evntdrv/evntdrv.htm delete mode 100644 general/tracing/tracedriver/tracedrv.htm delete mode 100644 hid/firefly/firefly.htm delete mode 100644 hid/hclient/hclient.htm delete mode 100644 input/kbfiltr/kbfiltr.htm delete mode 100644 input/moufiltr/Moufiltr.htm delete mode 100644 network/config/bindview/bindview.htm delete mode 100644 network/modem/fakemodem/fakemodem.htm delete mode 100644 network/ndis/filter/filter.htm delete mode 100644 network/ndis/mux/driver/60/mux.htm delete mode 100644 network/ndis/mux/notifyob/notify.htm delete mode 100644 network/ndis/ndisprot/6x/ndisprot.htm delete mode 100644 network/ndis/ndisprot_kmdf/ndisprot.htm delete mode 100644 nfp/net/NetNfpProvider.htm delete mode 100644 print/autoconfig/AutoConfig.htm delete mode 100644 print/cpsuisam/cpsui.htm delete mode 100644 sd/sdiomars/sdiosample.htm delete mode 100644 security/elam/elamsample.htm delete mode 100644 serial/serenum/serenum.htm delete mode 100644 setup/devcon/devcon.htm delete mode 100644 smartcrd/pscr/pscr.htm delete mode 100644 spb/SpbTestTool/SpbTestTool.htm delete mode 100644 storage/class/cdrom/src/cdrom.htm delete mode 100644 storage/class/classpnp/src/classpnp.htm delete mode 100644 storage/class/disk/src/disk.htm delete mode 100644 storage/filters/addfilter/src/addfiltr.htm delete mode 100644 storage/sfloppy/src/sfloppy.htm delete mode 100644 storage/tools/spti/src/spti.htm delete mode 100644 usb/usbview/usbview.htm delete mode 100644 wpd/WpdHelloWorldDriver/WpdHelloWorldDriver.htm delete mode 100644 wpd/WpdMultiTransportDriver/WpdMultiTransportDriver.htm delete mode 100644 wpd/WpdWudfSampleDriver/WpdWudfSampleDriver.htm diff --git a/avstream/avshws/avshws.htm b/avstream/avshws/avshws.htm deleted file mode 100644 index bd715e2c..00000000 --- a/avstream/avshws/avshws.htm +++ /dev/null @@ -1,458 +0,0 @@ - - - - - - - - -AVSHwS - - - - - - - -
- -

AVSHwS: AVStream Simulated -Hardware Sample Driver

- -

SUMMARY

- -

The AVSHwS sample provides a pin-centric AVStream capture driver for a simulated piece of hardware. The -driver performs captures at 320x240 in either an RGB24 or YUV422 format via -direct DMA into capture buffers. The purpose of the sample is to demonstrate -how to write a pin-centric AVStream minidriver. The sample also shows how to implement DMA by -using the related functionality provided by AVStream. 

- -

This sample features enhanced -parameter validation and overflow detection.

- - - -

BUILDING THE SAMPLE

- -

Build the sample by typing build -cez in either the standard -checked or free WDK build environment. A successful build produces AVSHwS.sys.

- -

The sample works on -32-bit x86 and 64-bit amd64 platforms running Vista Beta 2 or higher, Windows XP -SP2, Windows Server 2003 SP1 and Windows 2000 (If DirectX 8 or higher is -installed on the system)

- -

Installation -instructions:

- - - -

PROGRAMMING TOUR

- -

DriverEntry in device.cpp -is the initial point of entry. This routine passes control to AVStream through a call to KsInitializeDriver. -In this call, the minidriver passes the device -descriptor, an AVStream structure that recursively -defines the AVStream object hierarchy for a driver. -This is common behavior for an AVStream minidriver.

- -

At device start time (see -the CcaptureDevice::PnpStart method in device.cpp), a simulated piece of capture hardware -is created (the ChardwareSimulation class), a DMA adapter is acquired from the operating system and is -registered with AVStream through a call to KsDeviceRegisterAdapterObject. This call is required -for a sample that performs DMA directly into the capture buffers, instead of -using DMA to write to a common buffer. In PnPStart -the driver creates the KS Filter for this device dynamically by calling KsCreateFilterFactory.

- -

Filter.cpp is where the sample lays out the -KSPIN_DESCRIPTOR_EX structure for the single capture pin. In addition, a -KSFILTER_DISPATCH structure and a KSFILTER_DESCRIPTOR structure are provided in -this source file. The filter dispatch provides only a create dispatch, a -routine that is included in Filter.cpp. The -process dispatch is provided on the pin, since this is a pin-centric sample.

- -

Capture.cpp contains source for the video -capture pin on the capture filter. This is where the KSPIN_DISPATCH structure -for the unique pin is provided. This dispatch structure specifies a Process -callback routine, also defined in this source file. This routine is where -stream pointer manipulation and cloning occurs.

- -

The process callback is -one of two routines of interest in Capture.cpp -that demonstrate how to do DMA transfers using AVStream -functionality. The other is CCapturePin::CompleteMappings. -These two methods show how to use the queue, obtain clone pointers, use -scatter/gather lists, and perform other DMA-related tasks.

- -

Hwsim.cpp contains the hardware simulation -code and also code that fills the scatter/gather mappings. This source file -includes the Start, Pause and Stop methods for the hardware simulation class (CHardwaresimulation). Image synthesis and overlay code is -also here. The supplied objects provide image synthesis (pixel, color-bar, -etc...) to RGB24 and UYVY buffers as well as software string overlay into these -buffers. The Image.cpp file, including data, -must exist in locked segments.

- -

See comments in all .cpp files. Also see complete AVStream -documentation in the WDK documentation.

- -

RUNNING THE SAMPLE

- -

Once -installation is complete, access the driver through the graphedt -tool. Graphedt.exe -is available in the Tools directory of the WDK. In the Graphedt application, click the Graph menu and select -Insert Filters. The sample appears under "WDM Streaming Capture -Devices" as "avshws Source." Click -Insert Filter and the sample appears in the graph as a single filter labelled as ”avshws -Source”. There is one output pin which is the video capture pin. It sends out -video in YUY2 format. Attach this filter to either a DirectShow Video Renderer or the VMR default video renderer -and click Play.

- -

The output produced by -the sample is a 320x240 image of standard EIA-189-A color bars. In the middle -of the image near the bottom, a clock appears over the image. This clock -displays the elapsed time since the graph was introduced into the run state -following the last stop. The clock shows MINUTES:SECONDS.HUNDREDTHS. -

- -

In the top left corner of -the image, a counter counts the number of frames that have been dropped since -the graph was introduced into the run state after the last stop.

- -

COMMENTS

- -

For more -information on AVStream, see the WDK documentation.

- -

CODE TOUR

- -

File -Manifest

- -
File           Description
 
AVSHwS.htm     The Sample Tour documentation for this sample (this file).
Sources        The generic file for building the code sample.
AVSHwS.inf     A sample installation file.
AVSHwS.h       The main header file for the sample.
device.cpp     DriverEntry, Plug and Play handling, initialization, device level code.
device.h       Header file for above.
filter.cpp     Filter level code for the capture filter.
filter.h       Header file for above.
capture.cpp    Pin level code for the capture pin, DMA handling.
capture.h      Header file for above.
hwsim.cpp      Hardware simulation code, filling scatter/gather mappings, etc.
hwsim.h        Header file for above.
image.cpp      RGB24 and UYVY image synthesis and overlay code.
image.h        Header file for above.
purecall.c     Purecall stub for virtual function usage
AVSHwS.rc      Resource file mainly for version.
 
 
- - - - - -
-

 

-
- -
 
- -

© -2004- 2006 Microsoft Corporation -

- -
 
- -

 

- -
- - - - diff --git a/avstream/avssamp/avssamp.htm b/avstream/avssamp/avssamp.htm deleted file mode 100644 index c7390f8e..00000000 --- a/avstream/avssamp/avssamp.htm +++ /dev/null @@ -1,297 +0,0 @@ - - - - - - -Avssamp - - - - - - -
- -

Avssamp: Sample Filter-Centric AVStream -Simulated Capture Driver

- -

SUMMARY

- -

The Avssamp -sample provides a filter-centric AVStream capture -driver with functional audio. The driver performs captures at 320x240 in either -an RGB24 or YUV422 format while playing a user-provided PCM wave audio file in -a loop. The purpose of the sample is to demonstrate how to write a -filter-centric AVStream minidriver. -This sample was significantly redesigned for the Microsoft® Windows Server -2003® DDK.

- -

BUILDING THE SAMPLE

- -

Build the sample by -typing build -zc in -either the standard checked or free build environment. A successful build -produces avssamp.sys. To install the -driver, right click on avssamp.inf and select -Install. When prompted for avssamp.sys, select -the built binary.

- -

The sample works on x86 -platforms and builds correctly using Microsoft® Visual C® 6.0. The driver uses -Plug and Play.

- -

This sample runs on -Microsoft® Windows XP®, and Windows Server 2003® or any platform Windows 98® -gold or beyond, including Windows 2000®, that has -DirectX 8.0 or beyond installed.

- -

PROGRAMMING TOUR

- -

DriverEntry in avssamp.cpp -is the initial point of entry. This routine passes control to AVStream through a call to KsInitializeDriver. -In this call, the minidriver passes the device -descriptor, an AVStream structure that recursively -defines the AVStream object hierarchy for a driver. -This is common behavior for an AVStream minidriver.

- -

Filter.cpp is where the sample lays out the -KSPIN_DESCRIPTOR_EX structure for the single video pin. Audio.cpp -contains the KSPIN_DESCRIPTOR_EX structure for the audio capture pin. This pin -is dynamically created only if c:\avssamp.wav exists and is a valid and -readable PCM format wave file.

- -

The filter dispatch -structure in filter.cpp provides dispatches to -create and process. The DispatchProcess method -is defined inline in filter.h. It calls the Process -method in filter.cpp in the context of the CCaptureFilter. Note that the process dispatch is provided -in KSFILTER_DISPATCH since this sample is filter-centric.

- -

Audio.cpp lays out a KSPIN_DISPATCH -structure which contains the dispatch table for the audio pin. Note that the -Process member of this structure is NULL since the sample is filter-centric. -Similarly, video.cpp contains the pin dispatch -structure for the video capture pin, again with the Process member set to NULL. -

- -

See comments in all .cpp files. Also see complete AVStream -documentation in the DDK documentation.

- -

RUNNING THE SAMPLE

- -

Once -installation is complete, access the driver using the Graphedt -tool. Graphedt.exe -is available under the Tools\AVStream -directory of the DDK. In the Graphedt application, -click the Graph menu and select Insert Filters. The sample appears under -"WDM Streaming Capture Devices" as "avssamp -Source." Click Insert Filter and the sample appears -in the graph as a single filter labelled as avssamp Source. Attach this filter to either a DirectShow -Video Renderer or the VMR default video renderer and click Play.

- -

To play audio, before -inserting the avssamp filter, make sure that a valid -PCM wave file exists at c:\avssamp.wav. Then insert the avssamp filter. If a valid file exists at this location, -the avssamp filter will appear with an audio capture -pin. Connect the video pin to the DirectShow Smart Tee filter and connect the -Tee's preview pin as described for video above (note that this is only -necessary for synchronized preview -- not capture). Attach the audio pin to a -Default Waveout Device filter from the Audio Renderer list. Click play.

- -

The output produced by -the sample is a 320x240 image of standard EIA-189-A color bars.

- -

COMMENTS

- -

For more -information on AVStream, see the DDK documentation.

- -

CODE TOUR

- -

File Manifest

- -
File           Description
 
audio.cpp      Audio capture pin implementation.
audio.h        Audio capture pin header.
avssamp.cpp    The main file for the filter-centric sample.
avssamp.h      The main header file for the sample.
avssamp.htm    The Sample Tour documentation for this sample (this file).
avssamp.inf    A sample installation file.
avssamp.rc     Resource file mainly for version.
capture.cpp    The capture pin implementation for all capture pins on the sample filter.
capture.h      The capture pin header for all capture pins on the sample filter.
filter.cpp     The capture filter implementation (including frame synthesis) for the fake capture filter.
filter.h       Header for the capture filter implementation for the fake capture filter.
image.cpp      Image synthesis and overlay code. See comments in file.
image.h        Image synthesis and overlay header.
Sources        The generic file for building the code sample.
video.cpp      Video capture pin implementation.
video.h        Video capture pin header.
wave.cpp       Wave object implementation.
wave.h         Wave object header.
 
 
- - - - - -
-

 

-
- -
 
 
- -

© -2004 Microsoft Corporation

- -
 
- - - - diff --git a/bluetooth/bthecho/bthecho.htm b/bluetooth/bthecho/bthecho.htm deleted file mode 100644 index 9ea0ff09..00000000 --- a/bluetooth/bthecho/bthecho.htm +++ /dev/null @@ -1,2222 +0,0 @@ - - - - - - - - -BTHECHO - - - - - - - - - - - -
- -

Bluetooth Echo Sample

- -

SUMMARY

- -

This sample demonstrates developing Bluetooth L2CAP -profile drivers using Bluetooth L2CAP DDIs.

- -

The sample includes two drivers. One for a device that -acts as an L2CAP server and another for the device that acts as an L2CAP -client. Server simply echoes back any data that it receives from client on the -same L2CA channel.

- -

These drivers can be used with devices that can be -installed with bth.inf. Such devices get installed as ‘Generic Bluetooth -Radio’. Examples of such devices are Bluetooth USB dongles such as (but not -limited to):

- -

Generic Bluetooth -Radio=                         -BthUsb, USB\Vid_0a12&Pid_0001

- -

CSR Nanosira=                                    -BthUsb, USB\Vid_0a12&Pid_0003

- -

CSR Nanosira -WHQL Reference -Radio=               -BthUsb, USB\Vid_0a12&Pid_0004

- -

CSR Nanosira-Multimedia=                         -BthUsb, USB\Vid_0a12&Pid_0005

- -

CSR Nanosira-Multimedia -WHQL Reference Radio=    BthUsb, -USB\Vid_0a12&Pid_0006

- -

Please refer to bth.inf for the complete list of -devices.

- -

The installation steps below describe how to install -echo server and client with such a device.

- -

Please note that RFCOMM based profiles must be -developed and accessed using user-mode socket APIs.

- -

This sample is applicable to Windows® Vista, Windows® -7 and Windows® Developer Preview operating systems.

- -

BUILDING THE SAMPLE

- -

To build the sample drivers and exe, you must first -set up the WDK environment on your host machine on your Windows Developer -Preview operating system.

- -

Run msbuild command -in the bthecho directory as follows

- -

1.    BthEcho.lib (common library for the -Bluetooth Echo sample)

- -

cd bthecho\common\lib
-msbuild /t:clean /t:build BthEcho.VcxProj

- -

2.    BthEchoSampleSrv.sys (driver for -Bluetooth Echo Server device)

- -

cd ..\..\bthsrv\sys
-msbuild /t:clean -/t:build BthEchoSampleSrv.VcxProj

- -

3.    BthSrvInst.exe (Bluetooth echo -sever installation utility)

- -

cd ..\inst
-msbuild /t:clean -/t:build bthsrvinst.VcxProj

- -

4.    BthEchoSampleCli.sys (driver for -Bluetooth Echo client device)

- -

cd ..\..\bthcli\ sys
-msbuild /t:clean -/t:build BthEchoSampleCli.VcxProj

- -

5.    BthEcho.exe (Bluetooth echo -application used to exercise client device)

- -

cd ..\app
-msbuild /t:clean -/t:build BthEcho.VcxProj

- -

 

- -

INSTALLATION

- -

Note: Bluetooth echo server device and echo client device -must be installed on two different machines.

- -

 

- -

Server Installation

- -

1.    -Copy KMDF coinstaller -(wdfcoinstallerMMmmm.dll, from redist\wdf\ ), BthEchoSampleSrv.Sys, -BthEchoSampleSrv.inf and bthsrvinst.exe on a temporary directory on the -target machine.

- -

2.    -Run bthsrvinst.exe /i -to install the echo server device. This enables the Bluetooth Enumerator -(BthEnum.sys) to enumerate echo server device and create a PDO for the device -(please refer to the device tree below).

- -

2.    -Step #2 causes BthEnum.sys to create a PDO. -Consequently hardware installation wizard gets launched. Either go through the UI (Device Manager – Update Driver Software -in Windows® 7, ‘Found New Hardware’ wizard in Windows® Vista) and point it to -the temporary directory where you copied the binaries in step #1, or using -devcon.exe from the tools\devcon folder, run the -following command from the temporary directory:

- -

devcon.exe update BthEchoSampleSrv.inf -BTHENUM\{c07508f2-b970-43ca-b5dd-cc4f2391bef4}

- -

If devcon.exe fails -check the error level using:

- -

echo %errorlevel%

- -

If errorlevel is 1, you need to reboot the machine for KMDF -update to take effect. If errorlevel is 2, please -make sure that you have the driver files described in #1 available in the -current directory. For more information on installation failure please check -setup logs.

- -

4.    -Upon successful installation you will see ‘Bluetooth -Echo Sample Server’ in Device Manager under Bluetooth devices.

- -

5.    -(This steps in needed only on Windows® Vista) Navigate -to the system tray, right click on the Bluetooth icon, and select ‘Open Settings’. -This launches the ‘Bluetooth Settings’ dialog. On the ‘Options’ tab, check -‘Allow Bluetooth devices to find this Computer’. Note that this will make your -computer discoverable to other Bluetooth devices, and should be disabled again -when no longer required.

- -

 

- -

Device tree for Echo Server device

- -

 

- -

(Drivers for FDOs are shown for each devnode -in the tree.)

- -

 

- -
                   ---------------------
                  |                     |
                  |BthEchoSampleSrv.sys |<---------------Function driver for PDO ejected by BthEnum.sys
                  |                     |
                   ---------------------
                            ^
                            |          ---------------------
                            |         |                     |
                            |         |Bluetooth Enumerator |
                            --------- |    (BthEnum.SYS)    | 
                                      |                     |
                                       ---------------------
                                                 ^
                                                 |
                                                 |          ---------------------            ---------------------
                                                 |         |                     |          |                     |
                                                 ----------|     bthport.SYS     |<-------->|     bthusb.SYS      |       
                                                           |                     |          |                     |
                                                            ---------------------            ---------------------
- -

                                                            -Bth port driver loaded by bthusb.sys -       ^

- -

                                                                                                        -|

- -

                                                              -                                          V

- -

                                                                                               ----------------------

- -

                                                                                              -|                     -|

- -

                                                                                              -|      USB Stack      |

- -

                                                                                              -|                    - |

- -

                                                                                               ----------------------

- -

                                                         -                                               ^

- -

                                                                                                        -|   

- -

                                                                                                 -       V

- -

                                                                                               -----------------------

- -

                                                                                              -| USB Bluetooth Dongle |

- -

          -                                                                                     ----------------------

- -

Client Installation

- -

1.    Important: This must be done on a -separate machine from the one where echo server device was installed.

- -

2.    Copy KMDF coinstaller -(wdfcoinstallerMMmmm.dll, from redist\wdf\), BthEchoSampleCli.Sys, -BthEchoSampleCli.inf and bthecho.exe on a temporary directory on the target -machine.

- -

3.    Run bthprops.cpl from a command line or right -click on the Bluetooth icon in the system tray and select ‘Show Devices' to -bring up a list of installed Bluetooth devices.

- -

4.   Windows® 7:  In the ‘Bluetooth Devices’ window click the ‘Add a -device’ button. Windows® Vista: In the ‘Devices’ tab, click Add button.

- -

5.    In the Add a Device wizard select the server machine (the machine where -you installed the echo server) as a Bluetooth device. If the server machine -does not appear, please check the echo server installation and make sure that -you have enabled ‘Allow Bluetooth device to find this computer’ on the server -machine as explained above. When the server machine is correctly displayed, -select it and pick ‘Next’.

- -

6. The wizard should default to a numeric compare -ceremony for pairing the machines. When this happens, ensure the numbers match -on both the client and the server, select ‘Yes’ on both machines to indicate -they match, and click ‘Next’ on both machines to complete the pairing.

- -

7. The ‘Found New Hardware’ wizard will be launched on -Windows® Vista. On Windows® 7 and Windows® Developer Preview you will need to -go through Device Manager and update driver software for it. Either point the -wizard to the temporary directory created in step #2, or use devcon.exe from -the tools\devcon folder to install the client device:

- -

Devcon.exe update BthEchoSampleCli.inf BTHENUM\{c07508f2-b970-43ca-b5dd-cc4f2391bef4}

- -

Check for any error from devcon.exe as described in -server installation.

- -

If the installation is successful, you will see -‘Bluetooth Echo Sample Client’ in Device Manager under Bluetooth devices.

- -

 

- -

The device tree for echo client device is similar to -the one shown for the echo server device, since both client and server are -enumerated by BthEnum.sys (although the installation mechanism and properties -of client and server are different).

- -

 

- -

Uninstalling Server

- -

1.  Uninstall the device and delete driver -software using the Bluetooth Devices window by running bthprops.cpl, -right clicking on the device, and selecting ‘Remove Device’

- -

2.  Run bthsrvinst.exe /u to -uninstall the echo server. This would make bthenum.sys stop enumerating the -echo server. Without this step ‘Found New Hardware’ wizard will be launched -again when you reconnect the device.

- -

Uninstalling Client

- -

1.  Uninstall the device and delete driver -software using the Bluetooth Devices window by running bthprops.cpl, -right clicking on the device, and selecting ‘Remove Device’

- -

TESTING

- -

Run BthEcho.exe on the client machine. You should see -client sending data to the server and receiving the same data echoed back. -Press Ctrl+c to terminate the application. You will -see output similar to below:

- -

D:\bth\wdfcli>BthEcho.exe

- -

DevicePath: -\\?\bthenum#{c07508f2-b970-43ca-b5dd-cc4f2391bef4}_localmfg&000a#7&3

- -

62d0a3&0&000c55ff727a_c00000001#{fc71b33d-d528-4763-a86c-78777c7bcd7b}

- -

Opened device successfully

- -

Written                 -26 bytes: WDF Bluetooth Sample Echo

- -

Reply from server       26 bytes: WDF -Bluetooth Sample Echo

- -

Written                 -26 bytes: WDF Bluetooth Sample Echo

- -

Reply from server       26 bytes: WDF -Bluetooth Sample Echo

- -

Written                 -26 bytes: WDF Bluetooth Sample Echo

- -

Reply from server       26 bytes: WDF -Bluetooth Sample Echo

- -

Written                 -26 bytes: WDF Bluetooth Sample Echo

- -

Reply from server       26 bytes: WDF -Bluetooth Sample Echo

- -

Written                 -26 bytes: WDF Bluetooth Sample Echo

- -

^C

- -

You can launch multiple instances of BthEcho.exe. Each -client application would cause echo client device to have an independent -connection to the echo server and thereby have an independent echo session. You -can also have echo client devices and apps installed on multiple machines and -talking to a single echo server.

- -

DIRECTORY MANIFEST

- -
File           Description
 
bthcli         contains files for Bluetooth echo sample client
bthcli\sys     contains driver code for echo client (produces BthEchoSampleCli.sys and BthEchoSampleCli.inf)
bthcli\app     contains code for echo test application (produces BthEcho.exe)
bthsrv         contains files for Bluetooth echo sample server
bthsrv\sys     contains driver code for echo server (produces BthEchoSampleSrv.sys and BthEchoSampleSrv.inf)
bthsrv\inst    contains code for server installation utility (produces bthsrvinst.exe)
common         contains headers and code shared by client and server
common\inc     contains common headers
common\lib     contains common code (produces bthecho.lib used while building BthEchoSampleSrv.sys and BthEchoSampleCli.sys)
- -

FILE MANIFEST

- -

(build related files and inx files omitted for brevity)

- -

 

- -

bthcli\sys

- -

 

- -
File           Description
 
driver.*       contains WDF driver functionality
device.*       contains Bluetooth echo client device functionality
client.*       contains reusable code for Bluetooth L2CAP client, this code is used by device.*
queue.*        contains code for WDF queue used for read/write operations
 
- -

bthcli\app

- -

 

- -
File           Description
 
main.cpp       contains code for writing to and reading from Bluetooth echo client
 
bthsrv\sys
 
File           Description
 
driver.*       WDF driver functionality
device.*       contains Bluetooth echo server device functionality
server.*       contains reusable code for Bluetooth L2CAP server, this code is used by device.*
echo.*         contains functionality for sending echo to the client
sdp.*          contains code for building server SDP record
 
bthsrv\inst
 
File           Description
 
main.cpp       contains code for installing and uninstalling echo sample server
 
common\inc
 
File           Description
 
clisrv.h       header for common functions used by both echo client and echo server drivers
connection.h   contains header for connection object used by both echo client and echo server drivers
public.h       definitions used by echo client and server drivers as well as install and echo apps
trace.h        tracing related definitions
 
common\lib
 
File           Description
 
clisrv.c       code for common functions used by both echo client and echo server drivers
connection.c   contains code for connection object used by both echo client and echo server drivers
- -

CODE TOUR

- -

Common code

- - - -

Server

- -

·         -Startup: Server -registers PSM and L2CA server and published SDP record on startup in BthEchoSrvEvtDeviceSelfManagedIoInit (this callback is -invoked by WDF during device start). While registering the L2CA server it -passes BthEchoSrvIndicationCallback as the callback -for incoming connection notifications.

- -

·         -Server SDP record creation: The sample uses dynamic creation of server SDP record -using Bluetooth DDIs. Please note that for your particular device you may be -able to use static data for the SDP record.

- -

·         -Incoming connections: Bluetooth stack invokes BthEchoSrvIndicationCallback -for the incoming connections from clients. In response server accepts the -connection and passes BthEchoSrvConnectionIndicationCallback -callback to Bluetooth stack for disconnect notification. It is possible to use -the same indication callback for server and connection but the sample uses -different callbacks for clarity. Server adds the accepted connection to the -connection list it maintains. Please see below for connection rundown details.

- -

·         -Connection rundown: Server maintains a list of all the connections it has accepted. This -allows server to properly close down these connections on orderly removal. On -surprise removal bthport.sys itself gets removed and takes care of running down -the connections, but in case of orderly removal driver has to make sure to -rundown the connections.

- -

·         -Connection state machine:

- -

                                                                   -                            ConnectFailed

- -
                                                     ^
                                                     |
                                                     |          
                                                     | (connection failure)
- -

                         - Uninitialized   ------> Connecting ------> Connected

- -
                                                     | (disconnect)  /  ^ 
                                                     |              /  /
                                                     |             /  /
                                                     V            V  / (connection complete)
- -

                                                  -Disconnecting   

- -
                                                     | (disconnect complete)
                                                     |          
                                                     |             
                                                     V           
- -

                                                  -Disconnected

- -

 

- -

One transition to note here is that if disconnect is -received in the connecting state (i.e. when the connection is not completed) we -wait for connection to completed (transition to connected state) and then -invoke -disconnect.                                         -

- -

 

- -

Important: Such state machine is needed only if Disconnect is initiated by -something other than Bluetooth stack (for example device removal in our case). -Bluetooth stack itself would not send disconnect before connect completion. If -you adapt this sample for your device please evaluate whether your driver would -require such state machine. For example, the echo client device does not need -such state machine (although we use common connection code for client and the -server).

- -

 

- - - -

Client

- - - -

RESOURCES

- -

For the latest release of the Windows device Driver -Development Kit, see http://www.microsoft.com/whdc/. -For Bluetooth user mode APIs used in BthSrvInst.exe please see MSDN (http://msdn.microsoft.com).

- -

Please see the latest WDK release for documentation on -Bluetooth and WDF.

- -

If you have questions on using or adapting this sample -for your project, you can post your questions in the Microsoft -driver development newsgroup.

- -

 

- -

Top of page

- - - - - -
- -

© 2009 Microsoft Corporation. All rights reserved.

- -
- - - - diff --git a/bluetooth/serialhcibus/BluetoothHCISampleBusDriver.htm b/bluetooth/serialhcibus/BluetoothHCISampleBusDriver.htm deleted file mode 100644 index 375b609d..00000000 --- a/bluetooth/serialhcibus/BluetoothHCISampleBusDriver.htm +++ /dev/null @@ -1,2333 +0,0 @@ - - - - - - - - -BluetoothHciSampleBusDriver - - - - - - - - - -
- -

README—Bluetooth Serial HCI Sample Bus Driver

- -

 

- -

VERSION 0.2

- -

 

- -

Note: The sample driver & this documentation are -in their pre-release versions, thus they are both subject to change at any time

- -

 

- -

6/22/2011

- -

AUTHOR - Windows Bluetooth

- -

1       Document purpose

- -

 

- -

The purpose of this -sample is to demonstrate how to implement a basic bus driver to support the new -Bluetooth Extensibility transport DDIs over the UART transport. Such a serial -bus driver can support a multi-radio device over the UART transport and utilize -a common Bluetooth HCI packet for communication. The lower edge of this driver -interfaces with a UART controller following the Bluetooth SIG’s UART (H4) -transport protocol.

- -

 

- -

Note:

- -

·         This sample driver is generic—i.e. it is -not designed for a specific device and allows for a vendor to adopt and enhance -it for supporting Bluetooth

- -

·         This sample driver, as is, may not -properly function for a device until all vendor-specific device requirements -(e.g. device initialization) have been incorporated

- -

·         It is recommended to use WDK whose -version matches the target Windows build version or newer for the development -of the serial bus driver

- -

 

- -

2       Building the sample

- -

 

- -

1.       Open the project file (SerialHciBus\WDK\SerialBusWDK VC++ -project) from Visual Studio Dev11 to build this project.

- -

2.       After rebuilding the driver, you can -find SerialBusWDK.sys/pdb/inf -files.

- -

 

- -

3       Directory Manifest

- -

 

- -

File Description

- -

SerialHciBus – contains files for the Bluetooth -serial HCI bus driver

- -

SerialHciBus\Wdk – -contains driver code for device specific functions (produces SerialBusWdk.sys -and SerialBusWdk.inf)

- -

 

- -

4       File Manifest

- -

4.1        WDK header file

- -

·         BthXDDI.h – this has the constants, -struct, and IOCTL definitions for the Bluetooth extensibility transport. This -header file is included in WDK.

- -

4.2        Common code section

- -
    -
  1. driver.c – driver initialization
    2. -
  2. driver.h – common header file for driver.c and includes other header files
    3. -
  3. Fdo.c – functions for function - device object (FDO) and BTHX DDI processing
    4. -
  4. io.c – functions that perform IO - read pump via UART controller
    5. -
  5. Io.h – header for io.c
    6. -
  6. pdo.c – PDO (Bluetooth function) - enumeration and IOCTL processing
    7. -
  7. public.h – header to share with - application to support Radio On/Off (“Airplane mode”)
    8. -
- -

 

- -

Note: The goal is to -keep the common code section the same, so the vendor will only need to update -those code sections in the device specific directory.

- -

4.3        Device-specific code section

- -
    -
  1. Debugdef.h – WPP trace GUID; user should - use a new GUID (unique per driver)
    2. -
  2. device.c – device specific functions to - implement
    3. -
      -
    1. DeviceInitialize() - – to perform UART and Bluetooth device initialization;
      2. -
    2. DeviceEnable() - – (optional) to bring serial bus device out of disable/reset state.
      3. -
    3. DevicePowerOn() - – (optional) to power on the device.
      4. -
    4. DeviceEnableWakeControl() – (optional) to arm for device wake signal
      5. -
    5. DeviceDisableWakeControl() – (optional) to disarm for device wake signal
      6. -
    -
  3. device.h – header file for device.c
    4. -
  4. driver.rc – driver version and name
    5. -
  5. SerialBusWdk.inx – device specific INF file to - install this driver. The vendor will need to add the hardware ID to match - the “_HID” for the Serial Bus Device (Bluetooth) in the DSDT.asl file. For example, in SerialBusWDK.inx, - the hardware ID is “ACPI\<Vendor>_BTH0” where “<vendor>” could - be a 4 digit vendor name
    6. -
- -

 

- -

5       Installation

- -

 

- -

The vendor can adopt -this driver to add device specific functions, e.g. vendor-specific device -initialization. After this is completed, the following steps can be followed to -perform device installation in order to test the driver:

- -

·         Copy driver and inf file to a directory on the test system

- -

·         Perform “Update Driver” on the devnode corresponding to the hardware ID in the DSDT.asl file for this multifunction serial bus driver

- -

·         Point the installation to the -directory to find the INF and sys files

- -

·         Upon successful installation, you will -see “Serial Bus Driver over UART Bus Enumerator" in Device Manager under -the Ports device class

- -

·         Upon successful installation of the -serial bus driver, a PDO will be created with a compat ID of “MS_BTHX_BTHMINI.” -This will cause PnP to find the match in bth.inf to perform the installation of -the Bluetooth core components with its extensibility transport

- -

 

- -

Pre-requisite: -DSDT.ASL

- -

A multifunction serial -bus device is a peripheral device on a SoC platform. Its configuration is often -defined in the DSDT.asl (Differentiated System -Description Table) file to reflect its configuration and interconnection with a -UART controller and other optional dependent controllers, e.g. I2C, GPIO, etc. -for additional control.

- -

Here is an -(incomplete) sample system bus device section of a DSDT.ASL file for a UART -controller and a multifunction serial bus device that supports Bluetooth. For -details, please reference the document “Minimum WOA ACPI Requirements.docx” -from Microsoft.

- -

 

- -

//

- -

// -UART where a serial bus device is connected to

- -

//

- -

Device -(UAR1)

- -

{

- -

    -Name (_HID, "ABCD_UART")      // where -“ABCD” is vendor name;

- -

    -// …

- -

 

- -

    -Name (_CID, "ACPI\ABCD_UART")

- -

    -Name (_UID, 6)

- -

 

- -

    -Method (_CRS, 0x0, NotSerialized) {

- -

        -Name (RBUF, ResourceTemplate ()

- -

        -{

- -

                     -…

- -

        -})

- -

        -Return (RBUF)

- -

    -}

- -

}

- -

 

- -

//

- -

// -Multifunction serial bus device to support Bluetooth function

- -

//

- -

Device(BTH0)

- -

{

- -

    -// ACPI enumerate will generate a hardware ID “ACPI\ABCD_BTH0”

- -

    -Name (_HID, "ABCD_BTH0") // where “ABCD” is vendor name; 

- -

       - 

- -

    -Method(_CRS, 0x0, NotSerialized)

- -

    -{

- -

        -Name (RBUF, ResourceTemplate ()

- -

        -{

- -

        -// GPIO Descriptor

- -

        -// (optional)

- -

 

- -

        -// I2C Serial Bus Descriptor

- -

        -// (optional)

- -

 

- -

        -// UART Serial Bus Descriptor

- -

        -UARTSerialBus (

- -

      0xC0, // RTS | -CTS

- -

      LittleEndian,

- -

      DataBitsEight,

- -

      StopBitsOne,

- -

      FlowControlHardware,

- -

      115200, // -Initial Baudrate

- -

      480, // Rx FIFO -size

- -

      32, // Tx FIFO size

- -

      ParityTypeNone,

- -

      -"\\_SB.UAR1", , )

- -

        -})

- -

        -Return -(RBUF)            

- -

    -}

- -

}

- -

 

- -

6       Resources

- -

 

- -

For the latest release -of the Windows device Driver Development Kit, see http://www.microsoft.com/whdc/. -

- -

 

- -

Please see the latest -WDK release for documentation on Bluetooth and WDF.

- -

 

- -

Bus Driver Development -Based on KMDF http://msdn.microsoft.com/en-us/windows/hardware/gg463281.aspx

- -
- - - - diff --git a/general/SystemDma/wdm/systemdma.htm b/general/SystemDma/wdm/systemdma.htm deleted file mode 100644 index 301dead7..00000000 --- a/general/SystemDma/wdm/systemdma.htm +++ /dev/null @@ -1,741 +0,0 @@ - - - - - - - - - - - - - - - - - - - - -
- -

SDMA -

- -

SUMMARY

- -

This -sample demonstrates the usage of V3 System DMA. It shows how a driver -could use a system DMA controller supported by Windows to -write data to a hardware location using DMA.

- -

The sample -consists of a legacy device driver and a Win32 console mode test application. -The test application opens a handle to the device exposed by the driver and makes -a DeviceIoControl call to initiate the example system DMA. To understand how -the V3 system DMA calls are invoked please study SDmaWrite() in SDma.c.

- -

This -driver will work on Windows 2000 and later operating systems.

- -

This -sample driver is not a PnP driver. This is a minimal driver meant to -demonstrate an OS feature. Neither it nor its sample programs are intended for -use in a production environment. Rather, they are intended for educational -purposes and as a skeleton driver.

- -

BUILDING THE SAMPLE

- -

Click the -Free Build Environment or Checked Build Environment icon under Development Kits -program group to set basic environment variables.

- -

Change to -the directory containing the sample source code, such as CD Src\General\sdma\wdm. -

- -

Run build --ceZ, or use the macro BLD. This command invokes the Microsoft make routines to -build the components. If the build succeeds, you will find the driver, -sdma.sys, and the test application, SystemDmaApp.exe, in the binary output -directory specified for the build environment. You can get the output path from -the buildxxx.log file (for example, buildfre_win7_arm.log). If the build fails -you can find errors and warnings in the buildxxx.err and buildxxx.wrn respectively, -where xxx is either chk or fre depending on the build environment.

- -

TESTING

- -

To test -this driver, copy the test app, SystemDmaApp.exe, and the driver to the same -directory, and run the application. The application will automatically load the -driver if it's not already loaded and interact with the driver. When you exit -the app, the driver will be stopped, unloaded and removed. Because no system DMA -controller exists for Windows which uses the advertised DRQ, the sample driver -will not proceed any further than failing to acquire a system DMA adapter.

- -

CODE TOUR

- -

File Manifest

- -
File           Description
 
SystemDma.htm  Sample Tour documentation for this sample (this file).
Sources        Generic file that lists source files and all the build options.
SDma.c         Source file of the sample driver.
SDma.h         Header file for defining ioctls; included by driver and the test application.
Testapp.c      Source file of the test application. Contains routines to send one IOCTL to the driver.
Install.c      Source file of the test application. Contains routines to load and unload the driver.
SDma.rc        Resource file that specifies information such as file type, version, etc.
Makefile       This file merely indirects to the real makefile that is shared by all the driver components of the Windows NT DDK.
- -

Top -of page -

- - - - - -
- -

© 1998 Microsoft -Corporation -

- -
- - - - diff --git a/general/cancel/cancel.htm b/general/cancel/cancel.htm deleted file mode 100644 index cac03a7f..00000000 --- a/general/cancel/cancel.htm +++ /dev/null @@ -1,302 +0,0 @@ - - - - - - - - -CANCEL - - - - - - - - - -
- -

CANCEL

- -

SUMMARY

- -

This sample demonstrates -the use of new  cancel-safe -queue (IoCsqInitialize, IoCsqInsertIrp, -IoCsqRemoveIrp, IoCsqRemoveNextIrp) -APIs introduced on Windows XP for queuing IRPs in the -driver's internal device queue. By using these APIs, driver writers do not have -to worry about any IRP cancellation race condition issues. A common problem -with cancellation of IRPs in a driver is -synchronization between the cancel lock or the InterlockedExchange in the I/O Manager with the driver's -queue lock. These APIs abstract the cancel logic while allowing the driver to -implement the queue and associated synchronization.

- -

The sample is accompanied -by a simple multithreaded Win32 console application to stress-test the driver's -cancel and cleanup routines.

- -

This driver is written -for an hypothetical data acquisition device that -requires polling at a regular interval. The device has some settling period -between two reads. Upon user request the driver reads data and records the -time. When the next read request comes in, it checks the interval to see if -it's reading the device too soon. If so, it pends the -IRP and sleeps for a while and tries again. Upon arrival, IRPs -are queued in a cancel-safe queue and a semaphore is signaled. A polling thread -waiting indefinitely on the semaphore wakes up to the signal and processes queued IRPs sequentially.

- -

This sample is adapted -from the original cancel sample -(http://support.microsoft.com/support/kb/articles/Q188/2/76.asp) written for -NT4.0.

- -

The building and -installation instructions given here apply to Windows® 2000 and later operating systems.

- -

This sample driver is not -a PnP driver. This is a minimal driver meant to demonstrate an OS feature. -Neither it nor its sample programs are intended for use in a production -environment. Rather, they are intended for educational purposes and as a -skeleton driver.

- -

BUILDING THE SAMPLE

- -

Click the Free Build -Environment or Checked Build Environment icon under Development Kits program -group to set basic environment variables.

- -

Change to the directory -containing the device source code, such as CD Src\General\Cancel. -

- -

Run build -ceZ, or use the macro BLD. This command invokes -the Microsoft make routines to build the components. If the build succeeds, you will find the driver, -cancel.sys, and the test application, canclapp.exe, -in the binary output directory specified for the build environment. You can get the output path from the buildxxx.log file. If it fails you can find errors and warnings in the buildxxx.err -and buildxxx.err respectively, where xxx is either chk or fre depending on the build -environment.

- -

STARTIO IMPLEMENTATION

- -

In the startio directory is another version of the sample driver -that shows how to use the  cancel-safe queues to implement IO -queuing functionality similar to the IoStartPacket/IoStartNextPacket -APIs. The same test application works with this driver as well.

- -

TESTING

- -

To test this driver, run -Testapp.exe, a simple Win32 multithreaded console mode application. The driver -will be automatically loaded and started. When you exit the app, the driver -will stopped and removed.

- -

Usage:testapp (NumberOfThreads)

- -

Note: NumberOfThreads -is limited to a maximum of 10 threads; the default value if run without the option -is 1. The main thread waits for user input. If you press Q, the application -exits gracefully; otherwise it exits the process abruptly forcing all the -threads to be terminated and all pending I/Os to be canceled. Other threads -perform I/O asynchronously in a loop. After every overlapped read, the thread -goes into an alertable sleep and wakes as soon as -completion routines is executed, when the read IRP gets completed by the -driver. You should run multiple instances of the application to stress test the -driver.

- -

CODE TOUR

- -

File Manifest

- -
File           Description
 
Cancel.htm     Documentation for this sample (this file).
Cancel.c       Source file of the sample driver.
Sources        Generic file that lists source files and all the build options.
Testapp.c      Source file of the test application.
Install.c      Contains functions to load/start/stop/remove the driver.
Testapp.h      Header file for common definitions and function prototypes.
Cancel.rc      Resource file that specify information such as file type, version, etc.
Makefile       This file merely indirects to the real makefile that is shared by all the driver components of the Windows NT DDK.
- -

Top of page

- - - - - -
-

 

-
- -

© 2004 Microsoft -Corporation

- -
- - - - diff --git a/general/event/event.htm b/general/event/event.htm deleted file mode 100644 index 32485d9a..00000000 --- a/general/event/event.htm +++ /dev/null @@ -1,229 +0,0 @@ - - - - - -EVENT - - - - - - - -
- -

EVENT

- -

SUMMARY

- -

This -sample demonstrates two different ways a Windows NT kernel-mode driver can -notify an application about a hardware event. One is event based method and the -other is an IRP based method. Since the sample driver is not talking to any -real hardware, it uses a timer DPC to simulate hardware events. The test -application informs the driver whether it wants to be notified by signaling an -event or by completing the pending IRP and also gives a relative time at which -the DPC timer has to fire.

- -

Event -based approach: -The application creates an event using CreateEvent(). It then passes the event -handle to the driver in a private ioctl IOCTL_REGISTER_EVENT. Since the driver -is a monolithic toplevel driver, its IRP dispatch routines run in the -application process context and as a result the event handle is still valid in -the driver. The driver dereferences the user-mode handle into system space -& saves the event object pointer for later use and queues a custom timer -DPC. When the DPC fires, the driver signals the event via KeSetEvent() at -DISPATCH_LEVEL and deletes the references to the event object. You can't use -this approach if your driver is not a monolithic - toplevel driver, because you -can't guarantee the process context in a multi-level driver stack if you are -not at the top.

- -

Pending -IRP based approach: -The application make a synchronous ioctl(IOCTL_REGISTER_EVENT) request. The -driver marks the device I/O control IRP pending and queues a timer DPC and -returns STATUS_PENDING. When the timer fires to indicate a hardware event, the -driver completes the pending IRP to notify the application about the hardware -event.

- -

There are -two advantages of this method over the event based approach. One is that you -can send a message to the application along with your notification and other -one is that the driver routines don't have to be in the context of the process -that made the request. The application can do a synchronous or asynchronous -(overlapped) ioctl to the driver.

- -

This -sample driver is not a PnP driver. This is a minimal driver meant to -demonstrate an OS feature. Neither it nor its sample programs are intended for -use in a production environment. Rather, they are intended for educational -purposes and as a skeleton driver.

- -

This driver -will work on Windows NT 4.0, Windows 2000 and later operating systems.

- -

BUILDING THE SAMPLE

- -

Click the -Free Build Environment or Checked Build Environment icon under Development Kits -program group to set basic environment variables.

- -

Change to -the directory containing the device source code, such as CD Src\General\Event.

- -

Run build --ceZ, or use the macro BLD. This command invokes the Microsoft make -routines to build the components. If the build succeeds, you will find the -driver, event.sys, and the test application, event.exe, in the binary output directory specified for the build environment. You can get the output path from the buildxxx.log file. If the build -fails you can find errors and warnings in the buildxxx.err and buildxxx.err -respectively, where xxx is eithr chk or fre depending on the build environment. -

- -

TESTING

- -

To test -this driver, copy the test app, event.exe, and the driver to the same -directory, and run the application. The application will automatically load the -driver if it's not already loaded and interact with the driver. When you exit -the app, the driver will be stopped, unloaded and removed.

- -

c:\>Event.exe -DELAY <0/1>

- -

where -DELAY equals the time to delay the Event signal in seconds.

- -

Specify O -for IRP based notification and 1 for event based notification.

- -

CODE TOUR

- -

File Manifest

- -
File           Description
 
 
Event.htm      Documentation for the sample (this file)
 
Exe\Sources    Generic file for building the test app
Exe\Eventtest.c Simple console test application
Exe\install.c  Code for registering and starting the driver service
 
Wdm\Sources    Generic file for building the driver
Wdm\Event.h    Header file private to the driver
Wdm\public.h   Common header file between app and driver
Wdm\Event.c    Main driver file
Wdm\Event.rc   Driver resource file
 
- -

Top -of page -

- -
 
- - - - - -
- -
 
 
- -

© 1998 -Microsoft Corporation -

- -
- - - - diff --git a/general/ioctl/wdm/ioctl.htm b/general/ioctl/wdm/ioctl.htm deleted file mode 100644 index bfce1a9e..00000000 --- a/general/ioctl/wdm/ioctl.htm +++ /dev/null @@ -1,742 +0,0 @@ - - - - - - - - - - - - - - - - - - - - -
- -

IOCTL -

- -

SUMMARY

- -

This -sample demonstrates the usage of four different types of IOCTLs -(METHOD_IN_DIRECT, METHOD_OUT_DIRECT, METHOD_NEITHER, and METHOD_BUFFERED) -supported by Windows, and how the user input & output buffer specified in -the DeviceControl function is handled by the I/O subsystem and the driver in -each case.

- -

The sample -consists of a legacy device driver and a Win32 console mode test application. -The test application opens a handle to the device exposed by the driver and makes -all four different DeviceIoControl calls one after another. To understand how -the IRP fields are set the I/O manager, you should run the checked build version -of the driver and see the debug output.

- -

This -driver will work on Windows 2000 and later operating systems.

- -

This -sample driver is not a PnP driver. This is a minimal driver meant to -demonstrate an OS feature. Neither it nor its sample programs are intended for -use in a production environment. Rather, they are intended for educational -purposes and as a skeleton driver.

- -

BUILDING THE SAMPLE

- -

Click the -Free Build Environment or Checked Build Environment icon under Development Kits -program group to set basic environment variables.

- -

Change to -the directory containing the sample source code, such as CD Src\General\ioctl\wdm. -

- -

Run build --ceZ, or use the macro BLD. This command invokes the Microsoft make routines to -build the components. If the build succeeds, you will find the driver, -sioctl.sys, and the test application, ioctlapp.exe, in the binary output -directory specified for the build environment. You can get the output path from -the buildxxx.log file (for example, buildfre_win7_x86.log). If the build fails -you can find errors and warnings in the buildxxx.err and buildxxx.wrn respectively, -where xxx is either chk or fre depending on the build environment.

- -

TESTING

- -

To test -this driver, copy the test app, ioctlapp.exe, and the driver to the same -directory, and run the application. The application will automatically load the -driver if it's not already loaded and interact with the driver. When you exit -the app, the driver will be stopped, unloaded and removed.

- -

CODE TOUR

- -

File Manifest

- -
File           Description
 
Ioctl.htm      Sample Tour documentation for this sample (this file).
Sources        Generic file that lists source files and all the build options.
Sioctl.c       Source file of the sample driver.
Sioctl.h       Header file for defining ioctls; included by driver and the test application.
Testapp.c      Source file of the test application. Contains routines to send IOCTLs to the driver.
Install.c      Source file of the test application. Contains routines to load and unload the driver.
Sioctl.rc      Resource file that specifies information such as file type, version, etc.
Makefile       This file merely indirects to the real makefile that is shared by all the driver components of the Windows NT DDK.
- -

Top -of page -

- - - - - -
- -

© 1998 Microsoft -Corporation -

- -
- - - - diff --git a/general/perfcounters/kcs/kcs.htm b/general/perfcounters/kcs/kcs.htm deleted file mode 100644 index 4349388b..00000000 --- a/general/perfcounters/kcs/kcs.htm +++ /dev/null @@ -1,757 +0,0 @@ - - - - - - - - -Sample Name - - - - - - - - - -
- -

Kernel Counter Sample (Kcs)

- -

SUMMARY

- -

kcs is a -sample to demonstrate the use of kernel mode perflib -API. The driver does not control any hardware; it simple provides counters. The -code contains comments to explain what each function does.

- -

USING THE SAMPLE

- -

To test the Kcs counter provider, -use the following procedure.

- -
    -
  1. Copy kcs.sys and kcs.man files in %windir%\system32 dir, and kcs.sys.mui in %windir%\system32\en-US - dir if kcs.sys.mui was - generated.
    -
    -
    2. -
  2. Sign the sample driver. For - details about how to sign the driver, see "SIGNNING THE SAMPLE - DRIVER" section.
    -
    -
    3. -
  3. Install the counters.
    4. -
- -

lodctr.exe /m:kcs.man

- -
    -
  1. Create a service to control - the driver.
    2. -
- -

sc create kcs -binpath= %windir%\system32\kcs.sys -type= kernel start= demand

- -
    -
  1. Start the service
    2. -
- -

net start kcs

- -
    -
  1. Run perfmon - and add Geometric Wave and Trignometric Wave - Counter Sets
    2. -
- -

perfmon.exe

- -
    -
  1. To stop the service, run
    2. -
- -

net stop kcs

- -
    -
  1. To un-install the counters, - run
    2. -
- -

unlodctr.exe /m:kcs.man

- -

BUILD THE SAMPLE

- -

To get the simple driver (kcs.sys), use the following -procedure.

- -
    -
  1. Click kcs.vcxproj - to open the sample.
    2. -
  2. Right click project, select - Properties, goto Linker -> Manifest File, make sure "Generate Manifest" is "No".
    3. -
  3. Build the project.
    4. -
      -
    1. You can press "F7" - or choose Build->Build Solution.
      2. -
    -
- -

LIMITATIONS

- -

This sample driver should not be used in a production -environment.

- -

 

- -

Kcs is designed for Windows 7 -and later versions of Windows.

- -

 

- -

FILE LIST

- -

kcs.h

- -

makefile

- -

sources

- -

kcs.c

- -

kcs.rc

- -

 

- -

LOCATION

- -

The files that comprise Kcs are -included in the Windows DDK in the \src\general\perfcounters\kcs directory.

- -

 

- -

FEEDBACK

- -

Top of page

- - - - - -
-

 

-
- -

© -Microsoft Corporation -

- -
- - - - diff --git a/general/toaster/toastpkg/toastpkg.htm b/general/toaster/toastpkg/toastpkg.htm deleted file mode 100644 index cd780261..00000000 --- a/general/toaster/toastpkg/toastpkg.htm +++ /dev/null @@ -1,186 +0,0 @@ - - - - -Toaster Installation Package - - - -

Toaster Installation Package

- - - -

SUMMARY

-This document discusses the different approaches that end users take when adding new hardware to their computer, and describes an approach that addresses these scenarios in a consistent, robust manner that works cooperatively with Plug and Play in Windows 2000 and Windows XP. It also outlines the mechanisms provided to facilitate additional vendor requirements such as the installation of value-added software. - -

INTRODUCTION

-The installation of software to support an instance of a given device (known as "device installation" or "driver installation") is done in a device-centric fashion in Windows operating systems. A device INF that matches up with one of the device's hardware or compatible IDs is used to identify the required driver file(s), registry modifications, etc., that are needed to make the device fully operational. This INF, along with the files copied thereby and a catalog that contains the digital signatures of the INF and these other files, constitute what is known as a "driver package". - -

-Because device installation is done for a specific instance of a device, the "natural" method of adding devices to a computer running a Plug and Play operating system is by plugging in the device first, letting Plug and Play find the device and automatically initiate an installation for that device. The device installation may then proceed using a driver package supplied with the OS, or a "3rd-party" driver package (supplied via CD-ROM, the Internet, or some other distribution mechanism). When the device installation is initiated by the addition of hardware, this is termed a "hardware-first" device -installation. - -

-Users may, however, take an alternate approach to adding hardware to their computer. In this scenario, they first run a setup program (perhaps launched as an autorun application when the vendor-supplied CD-ROM is inserted). This setup program may perform installation activities, and then prompt the user to insert their hardware. Upon the hardware's insertion, the vendor-supplied driver package (which was "pre-installed" by the setup program) is then found by Plug and Play, and the installation proceeds as in the hardware-first scenario. When the device installation is initiated by running a setup program, this is termed a "software-first" device installation. This approach to adding new hardware is just as valid as the hardware-first scenario, and some vendors may even instruct their users (via documentation that ships with the hardware) that this is the preferred method. - -

-Vendors must support the hardware-first scenario (by providing a driver package that may be supplied to the "Found New Hardware" wizard with no -"pre-configuration" performed by a setup program or other mechanism). Vendors may optionally support the software-first scenario as well, but the -actual installation of the device instance is done by Plug and Play upon the device's arrival, as described above. - -

-Vendors may also wish to perform additional activities as part of the device installation. For example, the vendor may want to allow the user to optionally install one or more applications that ship with the device (e.g., a scanner that ships with an image processing application). Such software is termed "value-added software". Value-added software is distinct from the files that comprise the driver package because, unlike the core driver files, the device does not require value-added software to function properly. In the previous example of a scanner, for instance, perhaps the user already has an image processing application that they prefer. The user should be given the option of whether or not they want to install any value-added software. Additional activities (such as allowing the user to select value-added software offerings) may be accomplished by using a vendor-supplied -device-specific co-installer. - - -

INTRODUCTION TO THE TOASTER INSTALLATION SAMPLE

-This sample contains inf, toastapp, toastcd, toastco, and toastva directories. The following summary describes the directories and key files. -

- -inf -

-This directory contains the device INF (toastpkg.inf) that is used in device installation of toaster devices enumerated by the toaster bus enumerator. It registers a device-specific co-installer (tostrco2.dll) that provides additional functionality during the installation. - -

-Also contained in this directory is the autorun.inf file that would be placed in the root of the vendor's setup media (e.g., CD-ROM). This INF will launch the toastva.exe application (described below) when the media is inserted in an autorun-capable drive, or when the user double-clicks on the drive icon in Explorer. Additionally, this INF illustrates the [DeviceInstall] section that is a new feature introduced in Windows XP for -autorun INF files: - -

-

-[DeviceInstall] -

-DriverPath=\ -

- -

-The DriverPath entry in a [DeviceInstall] section indicates to the Found New Hardware and Update Driver wizards that Plug and Play should search for -device INFs in the specified directory only. This provides a performance improvement for media layouts that contain many subdirectories, since the default -behavior is for Plug and Play to recursively search the entire CD. Additionally, specifying no DriverPath entry in this section indicates that the CD contains no drivers, thus Plug and Play can quickly determine that it can ignore this media. Absence of the [DeviceInstall] section will cause the media to be treated as it was in previous versions of Windows (e.g., as in Windows Me and Windows 2000, the entire media will be searched recursively for applicable INFs). -

- -toastapp
-This directory contains the source code for the toastapp.exe program that is used as value-added software that may optionally be installed by the user as part of device installation. This program is installed via the InstallShield(tm) (Microsoft Installer-based) setup program in the toastcd\ToastApp directory. -
- -toastcd
-This directory contains the CD image that would be used by the vendor to distribute the toaster package. In the root of the image, we have the -autorun.inf which launches either the x86 or ia64 version of toastva.exe (depending on platform). Also in the root we have the device INF, -toastpkg.inf, and the two associated catalogs, tostx86.cat and tostia64.cat, for the x86 and ia64 platforms respectively. Finally, -in the root we also have the zero-length tag file toastpkg.tag, which is used to identify the media in case it must be prompted for. This tagfile is -referenced in the SourceDisksNames sections of toastpkg.inf: - -
-

-[SourceDisksNames.x86] -

-1 = %DiskId1%, toastpkg.tag,,\i386 -

-[SourceDisksNames.ia64] -

-1 = %DiskId1%, toastpkg.tag,,\ia64 -

- -

-The i386 and ia64 subdirectories contain the driver files that, along with the INF and CAT, constitute the driver package. These files are -toaster.sys, tostrcls.dll, and tostrco2.dll. Their corresponding debug (.PDB) files are located there as well, although -these aren’t installed. Additionally, as mentioned above, the toastva.exe program (and its .PDB file) is located here. Note that this -is not part of the driver package—it is merely used to facilitate software-first installation. Since this executable is not part of the driver -package, it may be modified without affecting the digital signature of the package. - -

-Finally, the ToastApp subdirectory contains the setup.exe program that installs the value-added software package, toastapp.exe. This -setup.exe is a standalone package that contains the files it installs within this single binary. This is meant to represent an example of the kind -of software that might be supplied to a vendor by an ISV for distribution with that vendor's hardware. While this particular setup program was authored -with InstallShield(tm), other installation methods are equally valid. For example, the setup program could have been written using C/C++, directly -leveraging the Microsoft Installer (MSI) application programming interfaces (API). - -

-The tostrco2.dll module is constructed so that there is no requirement on how the value-added software is installed--it simply creates a process to initiate the setup program, then waits for that process to terminate before continuing. For the sample, the description of the value-added software offerings and details of launching the value-added setup application are hard-coded, but in a real-world scenario, the value-added software supplied might be listed in some sort of data file (perhaps an INF file) and the value-added software selection page would be completely data driven, using the information contained in that data file. This would be advantageous, for example, because a vendor could submit just their core driver package for Windows Logo testing without any value-added software (and without this data file). The vendor could then construct setup media containing the core driver package plus value-added software as they see fit. The contents of their setup media could be modified at any time by adding or removing value-added software, and no changes to the core driver package would be required (hence, no need to re-submit for Windows Logo testing). This works because the data file containing details about the -value-added software offerings isn't a part of the driver package, and thus can be changed without affecting that package. A co-installer DLL written -to accommodate such a scheme could have default behavior that would not display the value-added software selection page in the absence of this data file. -

- -toastco
-This directory contains the co-installer, tostrco2.dll, which is used during device installation of toaster devices enumerated by the toaster bus enumerator. This co-installer supplies a finish-install wizard page that allows the user to select the value-added software, if any, that they wish to install. It does not supply a finish-install wizard page if the user has previously responded to the wizard page (whether or not they opted to install value-added software) so that the user isn't prompted multiple times in the case where they plug in multiple toasters (or the same toaster is plugged into multiple ports, which will appear to Plug and Play as different instances of that device). - -

-This DLL also supplies the same value-added software selection page for use by the toastva.exe setup program. This avoids code duplication and ensures a consistent user experience for the hardware-first and software-first scenarios. - -

-Finally, this co-installer performs the same function as its version 1 counterpart (in the coinstaller directory under the main toaster directory). It provides a friendly name for the device that incorporates its serial number. However, this version retrieves the friendly name template from the INF, and since the template is stored in the [Strings] section, it may be localized for other languages. - -

-The reason this co-installer’s filename includes version number is to illustrate the technique that must be used when updating the driver for a device that may already have a previous version of the co-installer installed. If the name is not changed, then the old co-installer will be loaded early-on during the processing of DIF codes, and the updated version won’t be able to “get in the loop” to perform its new actions when installing the device. Thus, co-installers should include a version number in their filename, so that the new version can be copied and can participate in the device installation. -

- -toastva
-This directory contains the autorun installation application, toastva.exe, which is launched when the user inserts the vendor-provided CD-ROM. This application is used to "pre-install" the necessary INF and catalog, along with any value-added software the user chooses. In addition, it uses the UpdateDriverForPlugAndPlayDevices API to update the existing installed drivers for any toasters that may already be present. Examples of scenarios where this would apply are: -
    -
  1. -The user previously plugged in a toaster, and there was no in-box support (i.e., no supporting driver was included with Windows) for it. The user didn't supply a vendor provided driver package at that time (perhaps because they didn't have the media), so no driver was installed for the device (this is sometimes referred to as a "null driver install"). -
  2. -The user previously plugged in a toaster, and there was in-box support for it (perhaps using an older or reduced-functionality driver). -
  3. -The user previously plugged in a toaster, and at that time supplied an older version of the driver provided by the vendor. - -

    -In all the above cases, the UpdateDriverForPlugAndPlayDevices API will seek out any toaster device instances matching the specified hardware or compatible ID, and determine whether the specified driver package is "better" (i.e., lower rank or newer). If so, the device instance will be updated with the specified driver package. -

- -

BUILDING THE SAMPLE

-To build the Toaster Installation Sample components, you must first set up the DDK environment on your host machine. The “Installation and Release Notes” -topic in the Windows XP DDK has a complete description on how to do this. - -

-Run the build –cZ command in the toastpkg directory to build tostrco2.dll, toastapp.exe, and toastva.exe. Run the build –cZ -command in the classinstaller and func subdirectories of the main Toaster directory (parent of the toastpkg directory) to build -tostrcls.dll and toaster.sys. The toastcd directory contains all these components already built with full debugging information. The -reason is so that the sample could be digitally signed (thus exactly reproducing the ideal user experience). - -

-To experiment with certain behaviors of this package (e.g., toastva.exe launched via CD autorun), it is necessary to copy the entire contents of the toastcd tree onto a writeable CD. -

- -

RUNNING THE SAMPLE

-The sample can be run in two different ways, corresponding to the hardware-first and software-first scenarios. -

-Hardware-First Device Installation Walk-Through -

-Simulate the plugging in of a toaster by typing the following at a command prompt (see the documentation for the toaster sample driver for more information on setting up the toaster bus enumerator and using the "enum" application to simulate plugging and unplugging of toaster devices): - -

-

-C:\>enum -p 1 -

- -

-Since there is no in-box driver for this device, the Found New Hardware wizard will appear, prompting for a driver package. If you constructed the setup image on autorun-capable media (e.g., writeable CD or DVD), you may insert that media in the drive, and Windows XP will automatically initiate a driver search on that media. On Windows 2000, you must click "Next" to initiate the driver search on that media. If you constructed the setup image in a directory on your hard disk, then you must click the "Install from a list or specific location (Advanced)" radio button, then click "Next". On the next page, click the "Include this location in the search:" checkbox, and type the path to the directory. Clicking "Next" will then initiate a driver search in the directory you specified. - -

-The install will proceed using the toastpkg.inf file in the root of the install location. The co-installer, tostrco2.dll, will assign the device a friendly name during DIF_INSTALLDEVICE, and will supply a value-add software selection wizard page in response to DIF_NEWDEVICEWIZARD_FINISHINSTALL. This page will only be supplied if the user hasn’t been given the option previously of selecting value-added software (of if they’ve since uninstalled said software). This allows subsequent toasters to be installed server-side, without any user interaction whatsoever (even if a non-admin user or no user is logged in). - -

-Software-First Device Installation Walk-Through -

-If you constructed the setup image on auto-run capable media (e.g., writeable CD or DVD), you can simply insert the media, and the toastva.exe program will automatically launch. Note that toastva.exe suppresses itself when invoked while a device installation is in progress, which is why this application doesn’t appear during the hardware-first scenario described above. - -

-After the Welcome page, the wizard will attempt to update the driver for any existing toaster devices (via the UpdateDriverForPlugAndPlayDevices) API. -If there aren’t any, it will instead “pre-install” the INF using the SetupCopyOEMInf API so that Plug and Play will automatically find a match when -the hardware is subsequently inserted. SetupCopyOEMInf also stores away information that allows Plug and Play to know where the INF came from, thus allowing the Found New Hardware wizard to prompt for media in the correct location if it ever needs to. In this scenario, it is presumed that the user will plug in their toaster upon completion of the wizard, when they’re instructed to do so. As such, they should never actually be prompted to reinsert the CD, since they wouldn’t have removed it. However, if they had removed it, Plug and Play would prompt them to reinsert it. It is possible to “pre-install” all the driver files as well so that the user would never be prompted, even if they did remove the CD. The Windows XP DDK has a discussion of this technique in the section titled “Writing a Device Installation Application” in the Device Installation chapter. - -

-Next, the wizard displays the same value-add software selection page as the user would receive if they’d performed a hardware-first install, as described above. After clicking “Next” on this page, any selected applications are installed (the wizard is hidden while these setup processes run), then the Finish wizard page appears. If the wizard didn’t find any devices during its call to UpdateDriverForPlugAndPlayDevices, it prompts the user to plug in their hardware now. When the user does plug in the hardware (i.e., by typing “enum –p 1” as described above), then the install will proceed without requiring any user interaction. - -

FEEDBACK

-

We welcome your comments, problem reports and wish-list requests. Please - submit them by pointing your Internet browser to http://www.microsoft.com/whdc/default.mspx. -

- - -

-

© 2005 Microsoft Corporation

- diff --git a/general/tracing/evntdrv/evntdrv.htm b/general/tracing/evntdrv/evntdrv.htm deleted file mode 100644 index 0d89619d..00000000 --- a/general/tracing/evntdrv/evntdrv.htm +++ /dev/null @@ -1,189 +0,0 @@ - - - - - -Eventdrv - - - - - - - -
- -
- -
- -

 

- -

Eventdrv

- -

Summary

- - - -

Eventdrv is a sample kernel mode trace -provider/driver. The driver does not control any hardware; it simply generates -trace events. It is designed to demonstrate the use of ETW tracing in a driver.

- -

Eventdrv registers as a provider by calling -the EtwRegister API. If successful, it logs a StartEvent event with the -device’s name, the length of the name, and the status code. Then, when it -receives a DeviceIOControl call, it logs a SampleEventA event. Finally, when -the driver gets unloaded, it logs an UnloadEvent event with a pointer to the -device object. Note that Windows Pre-Processor (WPP) Tracing tools such -as TraceView.exe cannot be used to start/stop and view traces.

- -

  

- -

Using the Sample

- - - -

 To test the Eventdrv event tracing provider, use the following -procedure:

- -

1. Build the Eventdrv sample -driver (in evntdrv\Eventdrv) by using the -cZg switch.

- -

2.   -Install the manifest located in the evntdrv\Eventdrv folder by using the -following command:

- -

      -wevtutil im evntdrv.xml
-
-Installing the manifest will create registry keys which allows tools to be able -to find the resource and message file(s) which contains event provider -information. Search MSDN for further details on the wevtutil tool.

- -

3. Build the evntctrl executable -file (in evntdrv\evntctrl) by using the -cZg switch. Evntctrl sends IOCTLs to -Eventdrv, which then generates trace messages when it receives the IOCTLs.

- -

4. Make a folder in the system directory called -ETWDriverSample. For example, C:\ETWDriverSample. Copy Eventdrv.sys -and evntctrl.exe to this folder. Also, copy Tracelog.exe from the tools\tracing -folder in the Driver Kit to this folder. This directory must be created because -the path to the resource file specified in the manifest evntdrv.xml points to -the %systemroot%\ETWDriverSample folder. If this folder is not created and the -Evntdrv.sys binary is not copied, decoding tools will not be able to find the -event information to decode the trace file.

- -

5. Use Tracelog to start a trace -session that is called “TestEventdrv”. The following command starts the trace -session and creates a trace log file, Eventdrv.etl, in the local directory.
-
-Tracelog -start TestEventdrv -guid #b5a0bda9-50fe-4d0e-a83d-bae3f58c94d6 --f Eventdrv.etl

- -

6. To generate trace messages, run -Evntctrl.exe. This executable file is built in step 3. Each time you type a -character other than Q or q, Evntctrl sends an IOCTL to the driver that signals -it to generate trace messages. To stop Evntctrl, type Q or q.

- - - -

7. To stop the trace session, use -the following Tracelog command:
-
-tracelog -stop TestEventdrv

- -

8. To display the trace messages -in the Tracedrv.etl file, use Tracerpt. Type the following
-command:
-
-tracerpt Eventdrv.etl

- -

      -This creates two files: summary.txt and dumpfile.xml. Dumpfile.xml will contain -the event information in an XML format. For additional options, do tracerpt /?.

- -

9.   To uninstall the manifest, use the following command:

- -

      -wevtutil um evntdrv.xml
- 

- - - -

Limitations

- - - -

Eventdrv is designed for Windows Vista and -later versions of Windows.
-This sample driver should not be used in a production environment.

- -

 

- -

File List

- - - -

Eventdrv
-Drvioctl.h
-Evntdrv.c
-Evntdrv.xml
-Makefile
-Makefile.inc
-Sources

- -

Evntctrl
-Install.c
-Install.h
-Makefile
-Sources
-Tracectl.c

- -

 

- -

Location

- -

The files that comprise Eventdrv are included -in the Windows Driver Kit in the \src\general\tracing\evntdrv folder.

- -

 

- -
- -
- -
- - - - - diff --git a/general/tracing/tracedriver/tracedrv.htm b/general/tracing/tracedriver/tracedrv.htm deleted file mode 100644 index 0d3dc032..00000000 --- a/general/tracing/tracedriver/tracedrv.htm +++ /dev/null @@ -1,1052 +0,0 @@ - - - - - - - - -TraceDrv - - - - - - - - - -
- -

Tracedrv -

- -

SUMMARY

- -

Tracedrv is a sample driver -instrumented for software tracing. The driver does not control any hardware; it -simply generates trace messages. It is designed to show how to use WPP software -tracing macros in a driver.

- -

 

- -

Tracedrv initializes tracing (by -using WPP_INIT_TRACING) and, when it receives a DeviceIOControl -call, it starts a thread that logs 100 trace messages. The WPP software tracing -directives, calls, and macros in the code are accompanied by comments that explain -their purpose.

- -

 

- -

While examining Tracedrv, read the -"WPP Software Tracing" section of the Windows Driver Development Kit -(DDK) documentation (in Driver Development Tools, Tools for Software Tracing, -WPP Software Tracing). This section includes a reference section that describes -the directives, macros, and calls required for WPP software tracing. It also -includes "Sample WPP Software Tracing Code," a section that uses the Tracedrv sample to demonstrate the use of the WPP software -tracing elements.

- -

 

- -

USING THE SAMPLE

- -

To test the Tracedrv event tracing -provider, use the following procedure. The tools used in this procedure are -included in the DDK and located in the \tools\tracing subdirectory. For more -information about the tracing tools, see the "Tools for Software -Tracing" section of the WDK documentation.

- -
    -
  1. Build - the Tracedrv sample driver and the Tracectl executable file.
    2. -
      -
    1. Click tracedrv.sln to open the sample.
      2. -
    2. Right click project "tracectl", - select Properties, goto Linker -> Manifest - File, make sure "Generate - Manifest" is "No".
      3. -
    3. You can press "F7" or choose Build->Build - Solution.
      4. -
    -
  2. Copy - the Tracectl.exe file that was created in step 1 from the Tracectl directory (\src\general\tracing\tracedrv\tracectl\platform) - to the Tracedrv directory (\src\general\tracing\tracedrv\tracedrv\platform).
    3. -
  3. Use Tracepdb - to create a trace message format (TMF) file and a trace message control - (TMC) file from the Tracedrv.pdb file. Tracepdb - is located in the \bin\platform subdirectory of the WDK. The PDB - file that is used in this command is created by the Build utility in step - 1. From the \tools\tracing\platform subdirectory, type the - following command:
    4. -
- -

tracepdb -f <path>\tracedrv.pdb

- -
    -
  1. Create a control GUID - file for Tracedrv by opening a text file, adding - the following content, and saving the file as Tracedrv.ctl. -
    2. -
- -

      -d58c126f-b309-11d1-969e-0000f875a5bc

- -
    -
  1. Use Tracelog - to start a trace session that is called "TestTracedrv". - Tracelog is located in the \tools\tracing\platform - subdirectory of the DDK. The Tracedrv.ctl - file that is used in this command was created in step 4. The following - command starts a trace session and creates a trace log file, tracedrv.etl, in the local directory.
    2. -
- -

      tracelog -start TestTracedrv --guid tracedrv.ctl -f tracedrv.etl -flag 1

- -

Note: Without the -flag parameter, Tracedrv will not generate any trace messages.

- -
    -
  1. To - generate trace messages, run Tracectl.exe. This executable file is - built in step 2. Each time you type a character, other than Q or q, - Tracectl sends an IOCTL to the driver that - signals it to generate trace messages. To stop Tracectl, - type Q or q.
    2. -
  2. To stop the trace - session, use the following Tracelog command.
    3. -
- -

      tracelog -stop TestTracedrv

- -
    -
  1. To display the trace - messages in the Tracedrv.etl file, use Tracefmt. Tracefmt is - located in the \tools\tracing subdirectory of the DDK. The TMF file used - in this command was created by Tracepdb in step - 3. Type the following command:
    2. -
- -

      tracefmt tracedrv.etl -p -<Path to TMF file> -o Tracedrv.out

- -

The resulting Tracedrv.out file is a -human-readable text file of the Tracedrv trace -messages. To interpret the trace messages, in the Tracedrv.c -file, search for the DoTraceMessage macros.

- -

 

- -

LIMITATIONS

- -

This sample driver should not be used in a production -environment.

- -

 

- -

Tracedrv is designed for -Windows XP and later versions of Windows. It does not demonstrate how to -add WPP software tracing to a Windows 2000 driver. (For information about -adding WPP software tracing to a Windows 2000 driver, see the Tracing FAQ -topic in the Windows WDK documentation.)

- -

 

- -

Also, because it is not a Plug and Play driver, Tracedrv does not demonstrate tracing in a Plug and Play -environment.

- -

 

- -

Tracedrv demonstrates the basic -elements required for software tracing. It does not demonstrate more advanced -tracing techniques, such as writing customized tracing calls (variations of DoTraceMessage), or the use of WMI calls for -software tracing.

- -

 

- -

FILE LIST

- -

drvioctl.h

- -

makefile

- -

sources

- -

tracedrv.c

- -

tracedrv.ctl

- -

tracedrv.rc

- -

 

- -

LOCATION

- -

The files that comprise Tracedrv -are included in the Windows DDK in the \src\general\tracing\tracedrv directory.

- -

 

- -

FEEDBACK

- -

We welcome -your comments, problem reports, and wish-list requests. Please submit them by -visiting the Windows -DDK Web site.

- -

Top -of page

- - - - - -
-

 

-
- -

© Microsoft -Corporation 2005 -

- -
- - - - diff --git a/hid/firefly/firefly.htm b/hid/firefly/firefly.htm deleted file mode 100644 index c74ee2a9..00000000 --- a/hid/firefly/firefly.htm +++ /dev/null @@ -1,101 +0,0 @@ - - - - -Firefly - - - -

Firefly

- - - -

SUMMARY

-Firefly is a filter driver for an HID device. Along with illustrating how to write a filter driver, this sample shows how to use remote I/O target interfaces to open a HID collection in kernel-mode and send IOCTL requests to set and get feature reports, how an application can use WMI interfaces to send commands to a filter driver. - -

Introduction to firefly sample

- -Firefly sample is installed as an upper filter driver of Microsoft USB Intellimouse Optical. An application provided with the sample can cause the light of the optical mouse to blink by sending commands to the filter driver using WMI interface. The sample consists of: -

-Driver (firefly.sys): It's an upper device filter driver of mouse (mouhid.sys). This is a generic filter driver based on toaster filter driver sample available in this DDK. During start device, the driver registers a WMI class (FireflyDeviceInformation). The usermode application connects to WMI namespace (root\wmi) and opens this class using COM interfaces and makes call to set or get dataitem value (TailLit) of this class. In response to set WMI request, driver opens the HID collection using IoTarget and sends IOCTL_HID_GET_COLLECTION_INFORMATION & IOCTL_HID_GET_COLLECTION_DESCRIPTOR ioctls to get the preparsed data. It then calls HidP_GetCaps using the preparsed data to get the capabilities of the device. After getting the capabilities of the device, the driver creates a feature report to set or clear the feature that causes the light to toggle. -

-Library (luminous.lib): The sources for this file is located in the WINDDK\\src\wdm\hid\firefly\lib folder. You will need to build it before using it. This is shared by the WDM and WDF sample. All the interfaces required to access the WMI is defined in this library and exposed as CLuminous class. -

-Application (flicker.exe): The sources for this file is located in the WINDDK\\src\wdm\hid\firefly\app folder. You will need to build it before using it. This is shared by the WDM and WDF sample. The application links to luminous lib to open the WMI interfaces and send set request to toggle the light. -

-Sauron (sauron.dll): The sources for this file is located in the WINDDK\\src\wdm\hid\firefly\sauron folder. You will need to build it before using it. This is shared by the WDM and WDF sample. This is a windows media player visualization DLL. This DLL is created based on a sample from the Windows Media player SDK kit. By using this DLL, you can cause the mouse lights to blink to the beats of the music. Fun stuff to try out. -

- - -

BUILDING THE SAMPLE

-To build the sample driver and test applications, you must first set up the DDK environment on your host machine. The WDK documentation has complete description on how to do this. -

    -
  1. -Once the build environment is set up, run the build –ceZ command in the firefly directory. This will build the luminous.lib, firefly.sys, flicker.exe, and sauron.dll and place all these bits under the appropriate target build and platform specific sub directories of firefly/disk directory.

    -

  2. -Copy the KMDF coinstaller (wdfcoinstallerMMmmm.dll), .sys, .exe and the INF file (firefly.inf) to a floppy disk or a temporary directory on the target system. -
-

- - -

INSTALLING THE SAMPLE

-To install the driver on Windows XP and later operating systems:

-

    -
  1. Get Microsoft's USB Optical mouse and plug that into your target machine and make sure the mouse works. The drivers for this mouse comes with the operating system so the device will start working automatically when you plug in. -
  2. Copy the firefly.sys and the INF file (firefly.inf) to a floppy disk or a temporary directory on the target system. -
  3. Bring up the device manager (type devmgmt.msc in the Start/Run window and press enter). -
  4. Find the Microsoft Optical mouse under "Mice and other pointing devices" -
  5. Right click on the device and choose "Update Driver..." -
  6. Select the "Install from a list of specific location (Advanced)", and click Next. -
  7. Select "Don't search. I will choose the driver to Install" and click Next. -
  8. Click on "Have Disk..." and specify the floppy or temporary directory where the INF and the sys files are present. -
  9. The system will show "Shiny Things Firefly mouse" in the list of compatible hardware. Choose that and click Next. -
  10. You will get a warning about installing a driver that the system cannot verify whether it's compatible with your hardware. Ignore that and say Yes to installing the driver. -
  11. The system will go ahead and install the driver. At this point, you will get a warning dialog about installing an unsigned driver. Ignore that and click on "Continue Anyway" button. -
  12. The system will copy all the files and restart the mouse device to install the upper filter. Click on Finish button and you are ready to run the test app. -
- - -To install the driver on Windows 2000:

- -

    -
  1. Find the mouse device in the Device manager. On Windows 2000, this device might come up as a "HID compliant mouse" under "Mice and other pointing devices". -
  2. Double click on the device to bring up the properties dialog. -
  3. Go to the Driver Tab and click on "Update Driver..." button. Click Next. -
  4. Select "Display a list of the known driver..." option and click Next. -
  5. Click on "Have Disk..." and specify the floppy or temporary directory where the INF and the sys files are present. -
  6. Click Next. You will get warning about installing an unsigned driver. Click on Yes to continue the driver installation. -
  7. The system will copy all the files and restart the mouse device to install the upper filter. Click on Finish and close the Device manager property dialog. You are ready to run the test app. -
- -

TESTING THE SAMPLE

- -Copy the flicker.exe to the target machine and run it from command line. The usage is: -

-Usage: Flicker <-0 | -1 | -2>
- -0 turns off light
- -1 turns on light
- -2 flashes light -
-

-Testing the DLL: -

    -
  1. Copy the sauron.dll to the Windows Media player Visualization directory (C:\Program Files\Windows Media Player\Visualizations). -
  2. Register the DLL with COM by calling "regsvr32 sauron.dll" in command shell. -
  3. Start the Windows Media player and click on "Now Playing". -
  4. Right click on the Visualization window and you will see a menu item called "Sauron". -
  5. Choose either Firefly Bars or Firefly Flash and play some music. -
  6. You will see the mouse light dancing to the tune of the music. -
  7. You can unregister the DLL by calling "regsvr32 -u sauron.dll". -
- -

-

Top of page

- - - -
-

- -

© Microsoft Corporation 2007

- \ No newline at end of file diff --git a/hid/hclient/hclient.htm b/hid/hclient/hclient.htm deleted file mode 100644 index de1fa7b6..00000000 --- a/hid/hclient/hclient.htm +++ /dev/null @@ -1,775 +0,0 @@ - - - - - - - - -HCLIENT - - - - - - - - - - - - -
- -

HCLIENT

- -

SUMMARY

- -

This document and -associated sample code describe how to write a user-mode client application to -communicate with devices that conform to the HID device class specification. -This article is useful to application writers who need to develop a user-mode -application that communicates with and extracts information from an -HID-compatible device. This sample illustrates the method for detecting HID -devices, opening those HID devices for communication, and extracting and -formatting the data into or from device reports.

- -

The HID class consists -primarily of devices that are used by humans to control the operation of -computer systems. Typical HID devices include keyboards, mice, and joysticks. -Non-typical devices might include front-panel controls (knobs, switches, or -buttons) or controls found on devices such as telephones, VCR remote controls, -games, and simulation devices. The underlying common feature of all HID devices -is the need for guaranteed delivery of small amounts of non-periodic data.

- -

The basic communication -mechanism for HID class devices is the HID report. Every HID device must supply -a report descriptor that details the format of the different reports that it -creates for its device. The HID class drivers and HID.DLL is provide -an interface for extracting the relevant data from these reports.

- -

Although the HClient sample is a user-mode application, many of the -functions available in HID.DLL are available to kernel-mode HID clients as -well. The functions exported by HID.DLL have a prefix of either HidD_ or HidP_. All functions -with a HidP_ prefix are available to kernel-mode -clients. However, the mechanism for opening HID devices and obtaining the -necessary information such as preparsed data is -different in this context.

- -

BUILDING THE SAMPLE

- -

To build the HClient.exe -sample, follow these instructions.

- -
    -
  1. Run the standard Windows NT®/Windows® 2000 DDK build - environment (checked or free)
    2. -
  2. Change to the .\src\wdm\hid\hclient - directory
    3. -
  3. Execute build
    4. -
  4. The built HClient.exe will be found in - .\lib\<i386|alpha>\<checked|free>
    5. -
- -

The HClient -sources are dependent on the following system include files and libraries.

- -
        HIDSDI.H       User-mode only definitions and declarations
        HIDPI.H        Definitions and declarations for user-mode and kernel-mode HID clients
        HIDUSAGE.H     Macro definitions for predefined usage table and usage values as 
                       defined in the HID Spec 1.0 and HID Usage Table Spec 1.0
        HID.LIB        Library file needed to resolve exported HID.DLL functions
- -

Kernel-mode clients may -also need the following files:

- -
        HIDPDDI.H      Declarations and definitions for features available through the HID ioctl interface
        HIDPARSE.LIB   Library file needed to resolve exported HIDPARSE.SYS functions
- -

TOOLS

- -

The only tools needed to -work with HClient are HID devices. In the Windows -NT/Windows 2000 system, file handles cannot be opened on mice and keyboards. -However, all other HID devices will be available and recognized by HClient for testing purposes.

- -

RESOURCES

- -

See the Universal Serial Bus Device Class Definition for -Human Interface Devices (HID) Version 1.0 and Universal Serial Bus HID Usage -Tables 1.0.

- -

CODE TOUR

- -

File Manifest

- -
Files         Description
 
HCLIENT.HTM    The documentation for this sample (this file)
SOURCES        The generic file for building the code sample
BUFFERS.C      Code for displaying HID report buffers in the extended calls 
               dialog box.            
BUFFERS.H      Function and structure declaration visible to other modules
DEBUG.C        Contains the function definitions for debug memory allocation tracking      
DEBUG.H        Contains public macro definitions and function declarations for 
               the debugging routines to deal with asserts, traps, and memory allocations
ECDISP.C       Code to handle the extended calls dialog box
ECDISP.H       Contains public declarations for the extended calls dialog
               box
HCLIENT.C      Code for handling HClient's main dialog box 
HCLIENT.H      Contains public declarations and definitions for HCLIENT.C and
               visible to other modules
HCLIENT.RC     Visual C++ generated resource file for HClient
HID.H          Contains declarations and definitions for handling devices and
               data within HClient
LIST.H         Contains public macro definitions for manipulating doubly-linked lists
LOGPNP.C       Code for finding, loading and building logical HID device 
               structures 
LOGPNP.H       Contains public function declarations for LOGPNP.C
MAKEFILE       NT DDK build environment makefile     
PNP.C          Contains the code for finding, adding, removing, and
               identifying hid devices.
REPORT.C       Contains the code for reading/writing hid reports and
               translating those HID reports into useful information.
RESOURCE.H     Visual C++ generated resource definition file
STRINGS.C      Code for converting data buffers and integer values
               to and from string representation for display.
STRINGS.H      Contains public function definitions for STRINGS.C
- -

Programming Tour

- -

The core functionality -relevant to HID client applications is contained in the files REPORT.C and -PNP.C. The code in these files implements the basic features that most clients -will require. Most of the other source files contain code for handling the user -interface and calling the main tasks that are in the above two files. This -section covers those relevant topics.

- -

The major topics covered -in this tour are:

- -
    -
  • Detecting Installed HID devices
    • -
  • Opening HID Devices
    • -
  • Communicating with HID Devices
    • -
  • Building/Interpreting HID Reports
    • -
- -

Detecting Installed -HID Devices

- -

A necessary component of -a HID client application is the detection of installed HID devices. The -function FindKnownHidDevices() in PNP.C details how to do that work. The basic steps for -identifying attached HID devices are:

- -
    -
  • Call HidD_GetHidGuid() – - Get the HID device class GUID
    • -
  • Call SetupDiGetClassDevs() - – Get a handle to a set of devices which implement the HID interface
    • -
  • Call SetupDiEnumDeviceInterfaces() – For each device in the returned set of devices, - obtain the interface information for all exposed HID interfaces.
    • -
  • Call SetupDiGetDeviceInterfaceDetail() – For each interface obtained in the previous call, - get the detailed information block for that interface. This detailed - information includes the string that can be passed to CreateFile() - to open a handle to the device
    • -
  • Call SetupDiDestroyDeviceInfoList() – Free up the device information set that was - obtained in the call to SetupDiGetClassDevs().
    • -
- -

The remainder of the code -implemented in the function deals with creating a list of HID_DEVICE structures -which contain information for each HID device in the system. This sample client -accesses all HID devices in the system. A more specific implementation may only -be looking for a certain type of HID device such as a joystick/gamepad.

- -

Opening HID Devices

- -

After detecting a HID -device, HClient proceeds to open that device. When -opening the device, HClient creates a HID_DEVICE -structure to contain any information about the device that further routines -might use. HID_DEVICE is defined as follows in HID.H:

- -
- - - - - -
 typedef struct _HID_DEVICE {   
    HANDLE               HidDevice; // A file handle to the hid device.
    PHIDP_PREPARSED_DATA Ppd;       // The opaque parser info describing this device
    HIDP_CAPS            Caps;      // The Capabilities of this hid device.
    HIDD_ATTRIBUTES      Attributes;
 
    PCHAR                InputReportBuffer;
    PHID_DATA            InputData;       // array of hid data structures
    ULONG                InputDataLength; // Num elements in this array.
    PHIDP_BUTTON_CAPS    InputButtonCaps;
    PHIDP_VALUE_CAPS     InputValueCaps;
 
    PCHAR                OutputReportBuffer;
    PHID_DATA            OutputData;
    ULONG                OutputDataLength;
    PHIDP_BUTTON_CAPS    OutputButtonCaps;
    PHIDP_VALUE_CAPS     OutputValueCaps;
 
    PCHAR                FeatureReportBuffer;
    PHID_DATA            FeatureData;
    ULONG                FeatureDataLength;
    PHIDP_BUTTON_CAPS    FeatureButtonCaps;
    PHIDP_VALUE_CAPS     FeatureValueCaps;
 
} HID_DEVICE, *PHID_DEVICE;
- -
- -

In addition to storing -the basic HID structures as defined in HIDPI.H and HIDSDI.H, the HID_DEVICE -structure also maintains an array of HID_DATA structures for each report type. -These structures contain the most recent value used for each of the controls -defined in the HIDP_VALUE_CAPS list and HIDP_BUTTON_CAPS list for the given -report type. The fields within this structure are used by routines that -pack/unpack data reports. The usage of these fields is discussed further in the -section entitled Building/Interpreting HID Reports.

- -

The function OpenHidDevice() -in PNP.C performs the necessary steps to fill a HID_DEVICE structure for a -device. In order to do so, it performs the following steps:

- -
    -
  • Call CreateFile() – Open a handle to the specific HID device. In this - case, we request read/write access to the device, allow the device to be - shared, and synchronize access to the device handle (no OVERLAPPED flag).
    • -
  • Call HidD_GetPreparsedData() – Get the preparsed data - for the device. The preparsed data is a HID - parser specific block of data used for processing HID reports. The memory - for this structure is allocated by the HID.DLL function and must be freed - when no longer needed with HidD_FreePreparsedData().
    • -
  • Call HidD_GetAttributes() – Get the attributes of the device. The attributes - structure contains the vendor ID, product ID and version number of the - given HID device
    • -
  • Call HidD_GetCaps() – Get the capabilities of the device. The device - capabilities include the usage page and usage of the device, the required - buffer length for the different reports on the device, the number of link - collection nodes on the device and a count of the number of buttons and - values for each of the different report types.
    • -
  • Call FillDeviceInfo() – Fill in the rest of the HID_DEVICE structure. This - function allocates space for and retrieves the link collection nodes, the - value caps, and the button caps for the device.
    • -
- -

A given client application -may not need to perform all of the above steps. For instance, if a client -application only operates with a specific HID device (ie. -vendor ID/product ID), it may forego any more processing after retrieving the -attributes if the device it is currently opening is not the one it’s interested -in.

- -

A client application may -also work only for a given usage page/usage combination. For example, a monitor -control application would only need to open devices that match the monitor -usage page and usage combination.

- -

Lastly, a HID client may -require only a subset of the detailed information currently stored in the -HID_DEVICE structure. This sample application performs a broad range of -functionality to provide a detailed sample.

- -

Communicating with HID -Devices

- -

As mentioned above, a HID -device’s basic method of communication is through reports. A HID device can -contain as many as 255 reports for each report type (Input, Output, and -Feature). In order to properly communicate with a device, a client application -must be able to create reports (when sending data) or extract data from reports -(when receiving data). See the section titled: Building/Interpreting HID -Reports for information on how to manipulate these report buffers.

- -

A HID device reports -information to the host through Input reports or Feature Reports. Typically, -input reports contain the data generated by user interaction, such as a button -press. Feature reports, on the other hand, report the current state or settings -for a device. The methods for obtaining these two different reports are -implemented in the functions Read() and GetFeature() in REPORT.C.

- -

In order to receive data, -HClient must use the file handle created in OpenHidDevice that has READ access and the buffer allocated -for the given report type. For input reports, Read() -calls the Win32 API ReadFile() and waits for the -device to return a report. For feature reports, GetFeature() sets the first -byte of the report buffer to the desired report ID and calls HidD_GetFeature() to obtain that feature report. After -receiving a report back from the underlying drivers, these routines call UnpackReport() -to fill in the corresponding HID_DATA structures.

- -

Outputting data to a -device is a bit more complicated. Once again, there are two different types of -reports that can be sent to a device, Output and Feature. The corresponding -functions for outputting data are Write() and SetFeature() in REPORT.C.

- -

The first step that both -of these functions perform is creating the desired report buffer. First, the -HID_DATA structure with the desired report ID value is found. Then, these -functions call PackReport() to set the data values within the allocated report buffer -for that report ID. Once the report buffer has been created, either WriteFile() -or HidD_SetFeature() is called to send the report -packet to the device.

- -

It is important to -understand that all access to a HID device file handle is synchronized. -Therefore, all threads using that handle will block until all previous requests -to the device have completed. One possible client implementation would have one -thread continuously read input reports while another thread sends or receives -feature reports. Since the HidD_GetFeature() and HidD_SetFeature functions -are implemented as DeviceIoControl calls, they are -also synchronized with ReadFile and WriteFile(). There are two solutions to this scenario. One solutions uses overlapped I/O for asynchronous control. The -second is to open two handles for the device, one for the read thread and one -for the feature thread.

- -

Building/Interpreting -HID Reports

- -

The last important idea -when dealing with reports is extracting/setting data values from/in a given -report buffer. The section covers the details of the functions PackReport() -and UnpackReport() as implemented in REPORT.C.

- -

As mentioned above, in -order to communicate with a HID device, the client application must be able to -either create the appropriate report to send to the device or extract the -relevant information from a report received from the device. When Hclient initially opened the HID device and created the -HID_DEVICE structure for that device, it also created an array of HID_DATA -structures for each of the report types. The format of this HID_DATA structure -is as follows:

- -
- - - - - -
 typedef struct _HID_DATA {
   BOOLEAN     IsButtonData;
   UCHAR       Reserved;
   USAGE       UsagePage;   // The usage page for which we are looking.
   ULONG       Status;      // The last status returned from the accessor function
                            // when updating this field.
   ULONG       ReportID;    // ReportID for this given data structure
   BOOLEAN     IsDataSet;   // Variable to track whether a given data structure
                            //  has already been added to a report structure
 
   union {
      struct {
         ULONG       UsageMin;       // Variables to track the usage minimum and max
         ULONG       UsageMax;       // If equal, then only a single usage
         ULONG       MaxUsageLength; // Usages buffer length.
         PUSAGE      Usages;         // list of usages (buttons ``down'' on the device.
 
      } ButtonData;
      struct {
         USAGE       Usage; // The usage describing this value;
         USHORT      Reserved;
 
         ULONG       Value;
         LONG        ScaledValue;
      } ValueData;
   };
} HID_DATA, *PHID_DATA;
- -
- -

When creating the HID -reports for sending to the device, the function PackReport() is used. PackReport takes as input a pointer to a HID_DATA structure -and the appropriate report buffer. The pointer should point to the first -HID_DATA structure in the array that contains the report ID for the report to -be created. With this information, PackReport() performs the following steps:

- -
    -
  • Zeroes out the current report buffer
    • -
  • Searches the array of HID_DATA structures looking all - data values that match the report ID
    • -
  • For each data value structure found, it calls HidP_SetUsageValue to set the value currently stored - in the structure into the report.
    • -
  • For each button structure found, it calls HidP_SetUsages with the corresponding usage value to - set the button state in the report to "On".
    • -
- -

After having looped -through the array of HID_DATA structures, the report buffer will have the -appropriate report ID set as the first byte in the buffer and is ready to be -sent to the device.

- -

In a similar manner, UnpackReport() -extracts data from a given report. Like PackReport(), this function receives a report buffer returned by the -device and an array of HID_DATA structures that could possibly be filled in. -This routine performs the following steps:

- -
    -
  • Extracts the report ID from the first byte of the - report buffer
    • -
  • Searches the array of HID_DATA structures looking for - all structures that match the report ID
    • -
  • For each data value structure found, it call HidP_GetUsageValue and HidP_GetScaledUsageValue to set the Value and ScaledValue fields.
    • -
  • For each button structure, UnpackReport() calls HidP_GetUsages() to retrieve all the "On" - buttons for that data structure.
    • -
- -

Once finished, the array -of HID_DATA structures will contain the new settings based on the information -returned in the report buffer.

- -

Top of page

- - - - - -
-

 

-
- -

© 2004 Microsoft -Corporation

- -
- - - - diff --git a/input/kbfiltr/kbfiltr.htm b/input/kbfiltr/kbfiltr.htm deleted file mode 100644 index b282cca4..00000000 --- a/input/kbfiltr/kbfiltr.htm +++ /dev/null @@ -1,465 +0,0 @@ - - - - - - - - -Kbfiltr - - - - - - - -
- -

Kbfiltr

- -

SUMMARY

- -

This sample is WDF -version of WDM filter driver. The WDM version of this filter has been deprecated. This is an upper device filter driver sample for -PS/2 keyboard. This driver layers in between the KbdClass -driver and i8042prt driver and hooks the callback routine that moves keyboard -inputs from the port driver to class driver. In its current state, it only -hooks into the keyboard packet report chain, the keyboard initialization -function, and the keyboard ISR, but does not do any processing of the data that -it sees. (The hooking of the initialization function and ISR is only available -in the i8042prt stack.) With additions to this current filter-only code base, -the filter could conceivably add, remove, or modify input as needed.

- -

This sample also creates -a raw PDO and registers an interface so that application can talk to the filter -driver directly without going thru the PS/2 devicestack. -The reason for providing this additional interface is because the keyboard -device is an exclusive secure device and it's not possible to open the device -from usermode and send custom ioctls -through it.

- -

This driver filters input -for a particular keyboard on the system. If you want to filter keyboard inputs -from all the keyboards plugged into the system then you can install this driver -as a class filter below the kbdclass filter driver by -adding the service name of this filter driver before the kbdclass -filter in the registry at "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96B-E325-11CE-BFC1-08002BE10318}\UpperFilters". -

- -

BUILDING THE SAMPLE

- -

Click the Free Build -Environment or Checked Build Environment icon under Development Kits program -group to set basic environment variables.

- -

Change to the directory -containing the device source code, such as CD src\input\kbfiltr. -

- -

Run build -ceZ, or use the macro BLD. This command invokes -the Microsoft make routines to build the components. If the build succeeds, you will find the driver, -kbfiltr.sys, -in the binary output directory specified for the build environment. You can get the output path from the buildxxx.log file. If it fails you can find errors and warnings in the buildxxx.err -and buildxxx.wrn respectively, where xxx is either chk or fre -depending on the build environment.

- -

INSTALLATION

- -

-Copy the KMDF coinstaller (wdfcoinstallerMMmmm.dll), driver binary and the kbfiltr.inf file to a floppy disk or a temp folder.

- -

This sample is installed -via an .inf file. The .inf -file included in this sample is designed to filter a PS/2 keyboard.

- -

Use the following rules -regarding the .inf file that installs the filter -driver.

- -

·  The .inf -file must install the class driver (Kbdclass) and the -port driver (i8042prt, Kbdhid, etc.) by using Keyboard.inf and the INF directives "Needs" and -"Include".

- -

·  The .inf -file must add the correct registry values for the class and port driver, as -well as using the new directives.

- -

To -install this filter, follow these steps:

- -
    -
  1. Open the Device Manager.
    2. -
  2. Open the Properties of the PS/2 keyboard - installed on the system.
    3. -
  3. Click the Driver tab, and then click Update - Driver.
    4. -
  4. Click the Browse my computer for drivers software.
    5. -
  5. Click the Let me pick from a list of device drivers on my computer.
    6. -
  6. Click Have Disk and point to the location of - the .inf file.
    7. -
  7. Proceed through the rest of the install. You will - need to reboot the machine if you are filtering a PS/2 device.
    8. -
- -

To install this driver as -a class filter, you have to use registry APIs to directly update the registry -with an installer and reboot your machine.

- -

Once -built, the sample produces Kbfiltr.sys and Kbftest.exe.

- -

 

- -

NULL INF file for Windows 2000:

- -

 

- -

On -Windows 2000, you have to provide an INF file to install a NULL driver for the -RAW PDO enumerated by the filter driver for sideband communication from usermode. Without this INF file, the raw PDO wouldn’t get -started. On XP and later OSes, you don’t need to -provide an INF. Here are steps for installing the NULL driver:

- -
    -
  1. Open the Device - Manager.
    2. -
  2. Select “Show Hidden Devices” in View Menu.
    3. -
  3. Find the ‘Keyboard_Filter_nnn’ - device with a yellow “!” in “Other” class of devices. ‘nnn’ stands for the instance number of the - device.
    4. -
  4. Double click on the device to open the properties.
    5. -
  5. Click the Driver tab, and then click Update Driver.
    6. -
  6. Follow the wizard's prompts, and when prompted, select - the Search for a suitable driver - for my device (recommended) option, and then click Next.
    7. -
  7. Select Specify - a location, clear the other choices, and click Next. Point to the location of the sideband.inf file.
    8. -
  8. Proceed through the rest of the install.
    9. -
  9. After install, you should see the Keyboard device - under “Sample Device” class in the device manager.
    10. -
- -

CODE TOUR

- -

File Manifest

- -
File           Description
 
 
Kbfiltr.htm    The documentation for this sample (this file)
Kbfiltr.c      Hooks into the reporting chain, the initialization of a PS/2 keyboard, and the PS/2 keyboard ISR
Kbfiltr.h      Definitions
public.h       Shared definitions with the exe
Kbfiltr.rc     Resources
Kbfiltr.inx    Sample .inf file 
Sideband.inf   INF to install a NULL driver for the Raw PDO on Windows 2000
Kbftest.c      Simple test application
Makefile.inc   A makefile that defines custom build actions.  This includes the conversion of the .INX file into a .INF file
-
 
 
 
- -

Top of page -

- -
 
- - - - - -
-

 

-
- -
 
 
- -

© -Microsoft Corporation 1999

- -
- - - - diff --git a/input/moufiltr/Moufiltr.htm b/input/moufiltr/Moufiltr.htm deleted file mode 100644 index 85faea72..00000000 --- a/input/moufiltr/Moufiltr.htm +++ /dev/null @@ -1,699 +0,0 @@ - - - - - - - - -Moufiltr - - - - - - - - - -
- -

Moufiltr

- -

SUMMARY

- -

This sample is WDF version of WDM -filter driver sample. The WDM version of this sample has been deprecated.

- -

This driver filters input for a -particular mouse on the system. In its current state, it only hooks into the -mouse packet report chain and the mouse ISR, and does not do any processing of -the data that it sees. (The hooking of the ISR is only available in the -i8042prt stack.) With additions to this current filter-only code base, the -filter could conceivably add, remove, or modify input as needed.

- -

BUILDING THE SAMPLE

- -

Click the Free Build -Environment or Checked Build Environment icon under Development Kits program -group to set basic environment variables.

- -

Change to the directory -containing the device source code, such as CD src\input\moufiltr. -

- -

Run build -ceZ, or use the macro BLD. This command invokes -the Microsoft make routines to build the components. If the build succeeds, you will find the driver, -moufiltr.sys, -in the binary output directory specified for the build environment. You can get the output path from the buildxxx.log file. If it fails you can find errors and warnings in the buildxxx.err -and buildxxx.wrn respectively, where xxx is either chk or fre -depending on the build environment.

- -

INSTALLATION

- -

-Copy the KMDF coinstaller (wdfcoinstallerMMmmm.dll), driver binary and the moufiltr.inf file to a floppy disk or a temp folder.

- -

This -sample is installed via an .inf file. The .inf file included in this sample is designed to filter a -PS/2 mouse.

- -

Use the -following rules regarding the .inf file that installs -the filter driver.

- -
    -
  • The .inf file - must install the class driver (Mouclass) and the - port driver (i8042prt, Mouhid, Sermouse, etc.) by using Msmouse.inf and the INF - directives "Needs" and "Include".
    • -
  • The .inf - file must add the correct registry values for the class and port driver, - as well as using the new directives.
    • -
- -

To -install this filter, follow these steps:

- -
    -
  1. Open the Device Manager.
    2. -
  2. Open the Properties of the PS/2 mouse - installed on the system.
    3. -
  3. Click the Driver tab, and then click Update - Driver.
    4. -
  4. Click the Browse my computer for drivers software.
    5. -
  5. Click the Let me pick from a list of device drivers on my computer.
    6. -
  6. Click Have Disk and point to the location of - the .inf file.
    7. -
  7. Proceed through the rest of the install. You will - need to reboot the machine if you are filtering a PS/2 device.
    8. -
- -

CODE TOUR

- -

File Manifest

- -
File           Description
 
Moufiltr.htm   The documentation for this sample (this file).
-
Moufiltr.c     Hooks into the reporting chain, the initialization of a PS/2 mouse, and the PS/2 ISR
-
Moufiltr.h     Definitions
-
Moufiltr.rc    Resources
-
Moufiltr.inx   Sample .inx file
-
Makefile.inc   A makefile that defines custom build actions.  This includes the conversion of the .INX file into a .INF file
-
 
- -

Top of page

- -
 
- - - - - -
-

 

-
- -
 
 
- -

© 2004 Microsoft Corporation

- -
- - - - diff --git a/network/config/bindview/bindview.htm b/network/config/bindview/bindview.htm deleted file mode 100644 index c28f6190..00000000 --- a/network/config/bindview/bindview.htm +++ /dev/null @@ -1,345 +0,0 @@ - - - - - - - - -BINDVIEW: Network Configuration/Installation Sample - - - - - - - -
- -

BINDVIEW: Network -Configuration/Installation Sample

- -

SUMMARY

- -

This sample demonstrates -how to use INetCfg APIs to enumerate, install, -uninstall, bind and unbind network components.

- -

The sample compiles -properly for 64-bit systems and builds properly with Microsoft® Visual C® 6.0.

- -

BUILDING THE SAMPLE

- -

To build the sample, type build. This command produces the binary -bindview.exe.

- -

INSTALLING THE SAMPLE

- -

Copy the -binary bindview.exe to the directory from which you want to run the sample.

- -

RUNNING THE SAMPLE

- -

Type bindview.exe at the command prompt to run the program. You can perform the following -operations.

- -

 

- -
    -
  • Install a network protocol, - service or client component.
    • -
  • Uninstall a network protocol, - service or client component.
    • -
  • By clicking the right mouse - button on a network protocol, service or client, you can perform the - following operations.
    • -
      -
    • Bind the network component - to another component.
      • -
    • Unbind the network component - from another component that is bound to it.
      • -
    -
  • By clicking the right mouse - button on a binding path, you can perform the following operations.
    • -
      -
    • Disable the binding path if - it is enabled.
      • -
    • Enable the binding path if - it is disabled.
      • -
    -
  • Save the binding information - to a file.
    • -
- -

CODE TOUR

- -

File Manifest

- -
File           Description
BINDVIEW.CPP   Contains WinMain and dialog box related functions.
NetCfgAPI.cpp  Contains INetCfg functions.
BINDING.CPP    Contains binding path related functions. 
Component.cpp  Contains network component related functions.
RESOURCE.H     Resource header.
BINDVIEW.H     Contains function prototypes.
NetCfgAPI.h    Contains function prototypes for NetCfgAPI.cpp
BindView.rc    Resources for Bindview
BindView.ico   Icon for the sample.
 
 
 
- -

Top of page

- - - - - -
-

 

-
- -

© 2004 Microsoft Corporation

- -
- - - - diff --git a/network/modem/fakemodem/fakemodem.htm b/network/modem/fakemodem/fakemodem.htm deleted file mode 100644 index add195f7..00000000 --- a/network/modem/fakemodem/fakemodem.htm +++ /dev/null @@ -1,926 +0,0 @@ - - - - - - - -UNIMODEM sample controller-less modem driver (fakemodem) - - - - - - - - - -
- -

UNIMODEM sample controller-less modem driver (Fakemodem)

- -

SUMMARY         

- -

This -sample demonstrates a simple controller-less modem driver. This -driver supports sending and receiving AT commands using the ReadFile/WriteFile calls or via a TAPI interface using an -application such as HyperTerminal.

- -

BUILDING THE SAMPLE

- -

Click -the Free Build Environment or Checked Build Environment icon under Development -Kits program group to set basic environment variables.

- -

Change -to the directory containing the device source code, such as CD src\wdf\fakemodem. -

- -

Run build --ceZ, or use the macro BLD. This command -invokes the Microsoft make routines to build the components. If the build succeeds, you will find the driver, fakemodem.sys, placed in a platform -specific subdirectory -src\network\modem\fakemodem\$(OBJ_PATH)\$O. If it fails you can find errors and warnings in the -buildxxx.err and buildxxx.err respectively, where xxx is either chk or fre depending on the build -environment.

- -

INSTALLATION

- -

To -install and test this driver, you do not need any real hardware. You can -install this driver either using Devcon.exe (ddk\tools\devcon) utility from the DDK or using toaster bus driver -sample.

- -

To install the bus driver on Windows XP and Windows Server 2003:

- -
    -
  • Double-click the ‘Add Hardware’ - wizard in Control Panel.
    • -
  • At the 'Welcome to the Add - Hardware Wizard', click ‘Next’.
    • -
  • Select 'Yes, I have already - connected the hardware', then click Next.
    • -
  • Select ‘Add a new hardware - device’ from the list, then click Next.
    • -
  • Select ‘Install the hardware - that I manually select from a list(Advanced),' and then click next.
    • -
  • Select ‘Modems’, then click - Next.
    • -
  • Check the box which says - "Don't detect my modems; I will select it from a list.", then - click Next.
    • -
  • Click 'Have Disk', make sure - that 'A:\' is in the "Copy manufacturer's files from:" box, and - click OK.
    • -
  • Click on the desired entry, and - then click Next.
    • -
  • At 'The wizard is ready to - install your hardware', click Next.
    • -
  • Click Finish at 'Completing the - Add/Remove Hardware Wizard.'
    • -
- -

To install the -driver using toaster bus:

- -

·         -Install the toaster bus driver. -Information on how to install the toaster bus driver is given in src\general\toaster\toaster.htm readme file.

- -

·         -Run the notify.exe (src\general\toaster\exe\notify) and choose Plug In a device -in the Bus menu.

- -

·         -In the plug in dialog, specify -{b85b7c50-6a01-11d2-b841-00c04fad5171}\fakemodem as -the Hardware Id and click okay.

- -

The bus driver will enumerate a -device with the hardware id provided by the application. At this point:

- -

On -Windows XP and later:

- -
    -
  • "Found New Hardware Wizard" - dialog box will appear. Here select the radio button labeled "Install - from a list of specific location (Advanced)" and then hit the - "Next" button.
    • -
  • In the following screen select the - radio button labeled " Search the best driver in these - locations" and then select "Include this location in the search - path" and specify the target media or the directory where the KMDF - coinstaller (wdfcoinstallerMMmmm.dll), INF and SYS files are copied and - then hit the "Next" button.
    • -
  • The system will scan the directory and - pick up the matching INF and start the installation. You will get a - Hardware Installation Warning dialog stating that your driver has not - passed Windows Logo Testing. Hit "Continue Anyway" button.
    • -
  • The system will copy the driver, INF - file, load the driver and start the device. If every thing goes fine, you - will get "Completing the Found New Hardware Wizard". Hit the - "Finish" button and the installation is complete.
    • -
  • You should be able to see the device - in the Device manager under "Modems"
    • -
- -

On -Windows 2000:

- -
    -
  • "Found New Hardware Wizard" - dialog box will appear with the description of the device. Here click - "Next" button.
    • -
  • In the following screen "Install - Hardware Device Driver", select the radio button labeled "Display - a list of known drivers for this device..." and then click - "Next" button.
    • -
  • In the following dialog on - "Hardware Type", select "Other Devices" from the list - and click "Next".
    • -
  • In the dialog on "Select a Device - Driver", click on "Have Disk".
    • -
  • Specify the target media or the - directory where the KMDF coinstaller (wdfcoinstallerMMmmm.dll), INF and - SYS files are copied and then hit the "Okay" button.
    • -
  • Select "OSR" in the - Manufacture section selection and click "Next".
    • -
  • Click "Next" on the - "Start Device Driver Installation" dialog.
    • -
  • Click Finish at 'Completing the - Add/Remove Hardware Wizard.'
    • -
- -

Note that if you get a warning dialog with -regards to Windows Logo, or unsigned drivers, testing then click on continue.

- -

USAGE

- -

Once -installed, you can talk to the fakemodem driver -through HyperTerminal, or via ReadFile/WriteFile calls.  The -AT command set supported by fakemodem includes:

- -

          AT                         returns OK
-
-          ATA                       returns CONNECT

- -

            ATD<number>                  returns CONNECT

- -

CODE -TOUR

- -

File -Manifest

- -
File           Description
readwrit.c    Routines for receiving and sending text. This includes processing AT commands.
Driver.c              Fakemodem driver initialization entry points and for handling Plug & Play events.
ioctl.c               Routines to handle IOCTL messages.
mdmfake.inf   INF file for installing the fakemodem driver
- -

Top -of page

- - - - - -
-

 

-
- -

© Microsoft -Corporation 2000 -

- -
- - - - diff --git a/network/ndis/filter/filter.htm b/network/ndis/filter/filter.htm deleted file mode 100644 index 998c5b49..00000000 --- a/network/ndis/filter/filter.htm +++ /dev/null @@ -1,152 +0,0 @@ - - - - - -NDISLWF - - - - -

NDISLWF.SYS - Sample NDIS 6.0 Filter Driver

- -

Note: the sample driver contains some extra code for demonstration purposes. -You should remove unneeded optional sections from a production driver.

- -

SUMMARY

- -

Ndislwf NDIS 6.0 Filter Driver

- -

The Ndislwf sample is currently a do-nothing pass-through NDIS 6 filter -driver that demonstrates the basic principles underlying an NDIS 6.0 Filter -driver. The sample is a replacement of NDIS 5 Sample Intermediate -Driver (Passthru driver).

- -

Although the filter driver is a Modifying filter driver, the filter driver -currently doesn’t modify any packets and it only re-packages and sends down all -OID requests. You may easily update this filter driver to change packets -before passing them along. Or you may use the filter to originate new packets -to send or receive. For example, the filter could encrypt/compress outgoing and -decrypt/decompress incoming data.

- -

BUILDING THE SAMPLE

- -

Run the build command from this directory to build the -sample—it creates the binary Ndislwf.sys.

- -

To install this driver on Windows Vista (or above), use netlwf.INF also -found in this DDK.

- -

INSTALLING THE SAMPLE

- -

Ndislwf is installed as a service (called “NDIS Sample LightWeight Filter” -in the supplied INF). To install, follow the steps below:

- -
    - -
  1. Prepare a an installation directory that contains these files: netlwf.inf -and ndislwf.sys.
    2. - -
  2. On the desktop, click Start, then open Control Panel, then -open Network and Internet Connections, then open Network -Connections, then right-click on the relevant Local Area Connection icon -and choose Properties.
    3. - -
  3. Click Install, then Service, then Add, then Have -Disk.
    4. - -
  4. Browse to the drive/directory containing the files listed above. Click -OK. This should show “NDIS Sample LightWeight Filter” in a list of -Network Services. Highlight this and click OK. This should install the -Ndislwf filter driver.
    5. - -
  5. Click OK or Yes each time if the system prompts with a warning -regarding installation of unsigned files. This is necessary because binaries -generated via the LDK build environment are not signed.
    6. - -
- -

CODE TOUR

- -

File Manifest

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
FileDescription
makefileUsed during compilation to create the object and sys -files
filter.cFilter driver entry points and related functions in -the Ndislwf filter driver
netlwf.infInstallation INF for the service
device.cVirtual device related routines such as registering a -device and handling IOCTLs
filter.hPrototypes of all functions and data structures used -by the Ndislwf driver
filter.htmDocumentation for the filter driver (this - file)
filter.rcResource file for the Ndislwf driver
precomp.hPrecompile header file
flt_dbg.cDebug-related code
flt_dbg.hDebug code definitions and structures
sourcesList of source files that are compiled and linked to -create the ndislwf driver.
- -

Programming Tour

- -

Basic steps in attaching and detaching of Ndislwf driver:

- -
    - -
  1. During DriverEntry, the ndislwf driver registers as a NDIS 6 filter -driver.
    2. - -
  2. Later on, NDIS calls Ndislwf FilterAttach handler, for each underlying NDIS -adapter on which it is configured to attach.
    3. - -
  3. In the context of FilterAttach Handler, filter driver call NdisFAttribute -to register its filter module context with NDIS. After that, filter driver can -read its own setting in registry by calling NdisOpenConfigurationEx, and calls -NdisXXX functions.
    4. - -
  4. After FilterAttach successfully returns, NDIS restarts the filter later by -calling FilterRestart handler. FilterRestart should prepare to handle -send/receive data. After restart return successfully, filter driver should be -able to process send/receive.
    5. - -
  5. All requests and sends coming from overlying drivers for the Ndislwf filter -driver are repackaged if necessary and sent down to NDIS, to be passed to the -underlying NDIS driver.
    6. - -
  6. All indications arriving from an underlying NDIS driver are forwarded up by -Ndislwf filter driver.
    7. - -
  7. NDIS call FilterPause handler when NDIS needs to detach the filter from the -stack or there is some configuration changes in the stack. In processing the -pause request from NDIS, the Ndislwf driver waits for all its own outstanding -requests to be completed before it completes the pause request.
    8. - -
  8. NDIS calls the Ndislwf driver’s FilterDetach entry point when NDIS needs to -detach a filter module from NDIS stack. FilterDetach handler should free all -the memory allocation done in FilterAttach, and undo the operations it did in -FilterAttach Handler.
    9. - -
- -

© Microsoft Corporation

- - - - diff --git a/network/ndis/mux/driver/60/mux.htm b/network/ndis/mux/driver/60/mux.htm deleted file mode 100644 index 8a590061..00000000 --- a/network/ndis/mux/driver/60/mux.htm +++ /dev/null @@ -1,617 +0,0 @@ - - - - - - - - -MUX Intermediate Miniport Driver Help - - - - - - - - - - - - -
- -

MUX.SYS - Sample NDIS -MUX Intermediate Driver

- -

SUMMARY

- -

MUX Intermediate Miniport Driver

- -

The MUX Intermediate -Miniport (IM) driver is an NDIS 6.0 driver that demonstrates the operation of -an “N:1” MUX driver, i.e. one which creates multiple -virtual network devices on top of a single lower adapter. Protocols bind to -these virtual adapters as if they are real adapters. Examples of Intermediate Miniport drivers that can use this -framework are Virtual LAN (VLAN) drivers.

- -

This sample implements -IEEE 802.1Q VLAN tagging, which is enabled by changing the default VLAN ID to a -non-zero valid value (see “Configuring VLANs” below).

- -

Operation

- -

The driver binds to -Ethernet (NdisMedium802_3) adapters as a protocol, and exposes one or more -virtual Ethernet devices over each lower adapter, based on its configuration. -The term “VELAN” is used to denote a Virtual Ethernet LAN adapter implemented -by this driver.

- -

When it binds to a lower -adapter, MUX reads the standard “UpperBind” key to obtain a list of VELANs -configured over this adapter. For each such VELAN, it calls NdisIMInitializeDeviceInstanceEx() -to instantiate the NDIS miniport for the VELAN. NDIS then calls the driver’s -MiniportInitialize (MPInitialize) routine to start the VELAN miniport.

- -

The MUX driver supports -configuring the MAC address for each VELAN miniport using the standard -“NetworkAddress” key that it reads from its MiniportInitialize routine. If this -is not configured, it computes a “locally significant” MAC address for the -VELAN using the MAC address of the lower adapter. The MUX driver sets its lower -adapter to promiscuous mode in order to be able to receive frames directed to -any of the VELAN MAC addresses. However it does implement -packet-filtering (and multicast address filtering) logic for all its VELAN -miniports so that it only passes up relevant frames on each VELAN. This -aspect of the driver may be modified if, for example, your driver design uses -the same MAC address as that of the lower adapter on all VELANs. With such a -modification, it is not required to set the lower adapter to promiscuous mode -and incur the costs of receiving all packets on the network.

- -

It supports dynamic -addition and deletion of VELANs in conjunction with its -notify object (related sample). If a VELAN is deleted, the virtual device -corresponding to the VELAN is stopped and removed, which in turn results in -NDIS halting the miniport instance for the VELAN (see MPHalt). If a -VELAN is added, NDIS sends a global reconfiguration event to the protocol edge -of this driver. The handler function for this event, PtPNPHandler, goes through -all lower adapters to see if any new VELANs have been added, i.e. if any of the -“UpperBind” keys have been modified.

- -

Since the driver -implements a virtual device, it does not simply pass through most NDIS -queries/sets. It keeps its own device view that is reflected in its responses -to queries/sets. However it does pass through queries/sets for certain OIDs -that are best handled by the lower adapter driver.

- -

The driver supports Power -Management in the sense that it allows Wake-On-LAN and related functionality, -if supported by the lower adapter, to continue to function. It does so by -appropriately forwarding OID_PNP_XXX queries/sets to the lower adapter.

- -

IEEE -802.1Q VLAN Operation

- -

The driver supports -configuring a VLAN ID on each VELAN. It then inserts a tag header containing -this VLAN ID on all outgoing frames. For incoming frames that contain a tag -header, it verifies that a matching VLAN ID is present before indicating it up -to protocols. It removes the tag header, if present, from all indicated frames. -In all cases, received frames that do not contain tag headers are always handed -up to protocols.

- -

With the default -configured VLAN ID of zero, the driver does not insert tag header information -on sent packets, except for sent packets that contain non-zero Ieee8021QInfo -per-packet information, for which the driver does insert corresponding tag -headers. Receive-side filtering on VLAN ID is enabled only with a non-zero -configured VLAN ID, in which case only received frames containing a matching -VLAN ID are passed up. With the default configured VLAN ID of zero, the driver -does not check the VLAN ID on received frames.

- -

BUILDING THE SAMPLE

- -

Run the build -command from this directory to build the sample—it creates the binary mux.sys. -To disable IEEE VLAN support, comment out the following line in the sources -file before building:

- -

C_DEFINES=$(C_DEFINES) -–DIEEE_VLAN_SUPPORT=1

- -

To install this driver on -Windows® codename Whistler, use the MUX sample notification object and INFs, -also found in this DDK.

- -

INSTALLING THE SAMPLE

- -

MUX is installed as a -protocol (called “Sample Mux-IM Protocol Driver” in -the supplied INFs/notification object). To install, follow the steps below.

- -

Prepare a floppy disk (or -installation directory) that contains these files: muxp.inf, -mux_mp.inf, mux.sys and mux.dll (notification object -DLL, built in this DDK at network\ndis\mux\notifyob).

- -

On the desktop, -right-click the My Network Places icon and choose Properties.

- -

Right-click on the -relevant Local Area Connection icon and choose Properties.

- -

Click Install, -then Protocol, then Add, then Have -Disk.

- -

Browse to the -drive/directory containing the files listed above. Click OK. This should -show “Sample Mux-IM Protocol Driver” in a list of -Network Protocols. Highlight this and click OK. This should install the -MUX driver.

- -

Click OK or Yes each time the system prompts with a warning -regarding installation of unsigned files. This is necessary because binaries -generated via the DDK build environment are not signed.

- -

Two .INF files are needed -rather than one because MUX is installed both as a protocol and a miniport.

- -

Configuring -VLANs

- -

The VLAN ID for each -VELAN (virtual miniport) can be configured as follows. Right-click on the -virtual miniport Local Area Connection icon and choose Properties. Click on the Configure -button to bring up the Device Manager UI for the virtual device. Select the Advanced property sheet – this should -contain a “VLAN ID” parameter that is configurable to the desired VLAN ID. -Choosing a value of 0 (zero) disables receive-side filtering based on VLAN ID.

- -

CODE TOUR

- -

File Manifest

- -
File           Description
 
Makefile       Used during compilation to create the object and sys files
Miniport.c     Miniport related routines for the MUX driver
Mux.c          DriverEntry routine and any routines common to the MUX miniport and protocol 
Mux.h          Prototypes of all functions and data structures used by the MUX driver
Mux.htm        Documentation for the MUX driver (this file)
Mux.rc         Resource file for the MUX driver
Muxp.inf       Installation INF for the service (protocol side installation)
Mux_mp.inf     Installation INF for the miniport (virtual device installation)
Precomp.h      Precompile header file
Protocol.c     Protocol related routines for the MUX driver
Sources        List of source files that are compiled and linked to create the MUX driver. This can be modified to create binaries that operate on previous Windows versions (e.g. Windows 2000).
- -

Programming Tour

- -

When it loads, i.e. from its DriverEntry -function, the MUX driver registers as an Intermediate miniport driver and as a -protocol, in that order.

- -

Binding and VELAN Creation

- -

NDIS calls MUX’s BindAdapter -function, PtBindAdapter, for each underlying NDIS adapter to which it is -configured to bind. This function allocates an ADAPT structure to represent the -lower adapter, and calls NdisOpenAdapter to set up a binding to it. In the -context of BindAdapterHandler, after successfully opening a binding to the -underlying adapter, the driver queries the reserved keyword -"UpperBindings" to get a list of device names for the virtual -adapters that this particular binding is to expose – see PtBootStrapVElans -for more details. Note that the MUX driver does not create bindings (i.e. call -NdisOpenAdapter) from any context other than its BindAdapter function – this is -recommended behavior for all drivers of this type.

- -

For each device name specified in -the “UpperBindings” key, the MUX driver allocates a VELAN data structure to -represent the virtual miniport, calls NdisIMInitializeDeviceInstanceEx. In -response, NDIS eventually calls the MUX miniport’s MiniportInitialize entry -point, MPInitialize, for each VELAN. After MPInitialize -successfully returns, NDIS takes care of getting upper-layer protocols to bind -to the newly created virtual adapter(s).

- -

Unbinding and Halting

- -

NDIS calls MUX’s UnbindAdapter -handler, PtUnbindAdapter, to request it to unbind from a lower adapter. -In processing this, MUX calls NdisIMDeInitializeDeviceInstance for each VELAN -instantiated on the indicated adapter – see PtStopVElan for details. -This call results in NDIS first unbinding any protocols bound to the indicated -VELAN, and then calling the MiniportHalt routine, MPHalt, for that -VELAN. MPHalt waits for any outstanding receives/sends on the VELAN to -finish before unlinking the VELAN from the ADAPT.

- -

PtUnbindAdapter itself blocks until all VELANs -associated with the ADAPT structure have been unlinked from it. This is to make -sure that no thread running in the context of a miniport-edge entry point for a -VELAN will ever access an invalid lower binding handle. Once all VELANs have -been unlinked, PtUnbindAdapter closes the lower binding by calling -NdisCloseAdapter. Note that the MUX driver does not close its lower binding -from any context other than its UnbindAdapter function – this is recommended -behavior for all drivers of this type.

- -

MPHalt may also be called if the VELAN -device is disabled, e.g. from the Network Connections Folder. There is no -special code within MPHalt to handle this condition. However, PtUnbindAdapter -takes care to not attempt to deinitialize a VELAN miniport (via -NdisIMDeInitializeDeviceInstance) that has already been halted.

- -

Handling Queries

- -

MPRequest is the MUX driver’s function that -handles queries for OID values on VELAN miniports. Most of the “Ethernet” type -information for the virtual miniport is stored in the VELAN structure itself, -and the driver returns information from this structure. The queries that are -forwarded are OID_GEN_MEDIA_CONNECT_STATUS, OID_PNP_CAPABILITIES and -OID_PNP_WAKE_UP_PATTERN_LIST. See “Handling Power Management” below for more -information about the latter two OIDs.

- -

Handling Sets

- -

MPRequest handles setting OID values on -VELAN miniports. Data management OIDs handled by the MUX driver are -OID_802_3_MULTICAST_LIST and OID_GEN_CURRENT_PACKET_FILTER. The multicast list -is handled entirely within the MUX driver – it just stores the set of multicast -addresses in the VELAN structure, for reference during receive-side data -processing. The packet filter is handled in a different way – the MUX driver -combines the packet filter settings (bitwise OR) of all VELANs associated with -the same lower adapter. If the combined packet filter is non-zero, MUX sends a -Set request with a value of NDIS_PACKET_TYPE_PROMISCUOUS for -OID_GEN_CURRENT_PACKET_FILTER to start receives on the lower adapter. If the -combined packet filter is zero, MUX sets the lower adapter’s packet filter to 0 -(turns off all receives if there aren’t any interested protocols).

- -

Note that setting the lower -adapter to promiscuous mode is only done here in order to be able to receive unicast frames directed to multiple MAC addresses. If, for -example, all VELANs are assigned the same MAC address (which is identical to -the address of the lower adapter), then the MUX driver should only pass down -the combined (bitwise OR) setting of packet filter settings of all VELANs.

- -

Some power management OIDs are -forwarded to the lower miniport. See “Handling Power Management” below for -details.

- -

Sending Data

- -

Data sent down on a VELAN miniport -is forwarded to the lower adapter. The MUX driver itself does not generate any -data of its own. The MUX driver clones a NET_BUFFER_LIST for each NetBufferList passed to its MPSendNetBufferLists -function, and saves a pointer to the original NET_BUFFER_LIST in the reserved -area of the NET_BUFFER_LIST structure. When the lower adapter completes the -send (PtSendNBLComplete), MUX picks up the -original packet and calls NdisMSendNetBufferListsComplete -to complete the original send request.

- -

If a non-zero VLAN ID is -configured for the VELAN, and/or the packet has non-zero Ieee8021QInfo -per-packet information, then the MUX driver inserts an NDIS buffer containing a -tag header to the front of the packet before sending it down – see function MPHandleSendTagging for details.

- -

Receiving Data

- -

Data received from a lower adapter -is indicated up on zero or more VELANs. The PtReceiveNBL -function is called for each NetBufferList received -from the lower adapter. The received data is checked for matches with the -packet filter and multicast list for each VELAN associated with the adapter -(see PtMatchPacketToVElan). Whenever a match is found, a new NET_BUFFER_LIST -is allocated and set to point to the received data. A pointer to the original -received NET_BUFFER_LIST (if any) is also stored in the new NET_BUFFER_LIST’s -reserved area. This packet is indicated up via NdisMIndicateReceiveNetBufferLists -to all interested protocols on that VELAN.

- -

The driver’s MPReturnNetBufferLists -function is called either by NDIS or by MUX itself when protocols are done with -a received NET_BUFFER_LIST. This function returns the original NET_BUFFER_LIST -indicated by the lower driver, if any, by calling NdisReturnNetBufferLists.

- -

The driver indicates up received -frames that do not have an IEEE 802.1Q tag header in them – see function PtHandleRcvTagging. It always strips off -tag headers, if present, on received frames. If a non-zero VLAN ID is -configured, then it checks received frames that contain tag headers for -matching VLAN Ids – only matching frames are indicated up to protocols. Any -VLAN/priority information present in incoming frames is copied to per-packet -information fields of indicated NET_BUFFER_LIST structures.

- -

Status Indications

- -

The only status indications that -are forwarded up by MUX are media connect status indications. See PtStatus -for more details.

- -

Handling Power Management

- -

During initialization (MPInitialize), -the MUX miniport sets the attribute NDIS_ATTRIBUTE_NO_HALT_ON_SUSPEND in -its call to NdisMSetMiniportAttributes. When the MUX -miniport is requested to report its Plug and Play capabilities -(OID_PNP_CAPABILITIES), the MUX miniport forwards the request to the underlying -miniport. If this request succeeds, then the MUX miniport overwrites the -following fields before successfully completing the original request:

- -

NDIS_DEVICE_POWER_STATE          MinMagicPacketWakeUp = -NdisDeviceStateUnspecified;

- -

NDIS_DEVICE_POWER_STATE          MinPatternWakeUp= -NdisDeviceStateUnspecified;

- -

NDIS_DEVICE_POWER_STATE          MinLinkChangeWakeUp=NdisDeviceStateUnspecified

- -

See PtPostProcessPnPCapabilities -for details.

- -

OID_PNP_SET_POWER and -OID_PNP_QUERY_POWER are not passed to the lower adapter, since the lower layer -miniport will receive independent requests from NDIS.

- -

NDIS calls the MUX driver’s -ProtocolPnPEvent function (PtPNPHandler) whenever the underlying adapter -is transitioned to a different power state. If the underlying adapter is -transitioning to a low power state, the driver waits for all outstanding sends -and requests to complete.

- -

Queries/sets received on a VELAN -miniport that are to be forwarded to the underlying adapter are queued on the -VELAN if the underlying adapter is at a low power state. These are picked up -for processing on receiving a notification that the underlying adapter is back -to a powered-up state.

- -

Handling Global Reconfiguration

- -

All modifications to VELAN -configuration are accompanied by PnP reconfigure notifications, i.e. -NetEventReconfigure events passed to the MUX’s PnPEventHandler, PtPNPHandler. -This driver takes a broad approach to handling reconfiguration, which is to -simply re-examine all the “UpperBindings” keys for all currently bound -adapters, and start off VELANs for any that do not exist – see PtBootStrapVElans -for details.

- -

Canceling Sends: MUX propagates send -cancellations from protocols above it to lower miniports.

- -

 

- -

Top of page

- - - - - -
-

 

-
- -

© 1999 Microsoft -Corporation

- -
- - - - diff --git a/network/ndis/mux/notifyob/notify.htm b/network/ndis/mux/notifyob/notify.htm deleted file mode 100644 index 6fe84b68..00000000 --- a/network/ndis/mux/notifyob/notify.htm +++ /dev/null @@ -1,552 +0,0 @@ - - - - - - - - -Mux.dll - Sample Notify Object - - - - - - - - - - -
- -

MUX.DLL – Sample Notify Object

- -

SUMMARY

- -

MUX Notify Object

- -

This sample demonstrates -how to write a notify object for installing and configuring an NDIS MUX intermediate -miniport (IM) driver that implements an N:1 relationship between upper and -lower bindings, i.e. it creates multiple virtual network devices on top of a -single lower adapter. Protocols bind to these virtual adapters as if they are -real adapters. Examples of Intermediate - Miniport drivers that can -use this type of notify object are Virtual LAN (VLAN) -drivers.

- -

Operation

- -

During installation, the -notify object performs the following operations.

- -

·         -It -creates one virtual adapter for each physical adapter the MUX protocol edge -binds to.

- -

·         -It -disables the bindings of other protocols such as TCP/IP to physical adapters if -it has been compiled with DISABLE_PROTOCOLS_TO_PHYSICAL defined in the Sources -file. This is the most commonly desired behavior for N:1 MUX drivers.

- -

·         -It -disables the bindings of the protocol edge of the MUX IM driver with all its -virtual adapters.

- -

The notify object -provides a custom property page for the MUX IM driver. The custom property page -allows the user to add one or more virtual adapters on top of a physical -adapter or delete an existing virtual adapter.

- -

When the MUX IM driver is -uninstalled, or binding is disabled, or the user deletes all the virtual -adapters on top of a physical adapter, the notify object restores the bindings -of other protocols to the physical adapter if it has been compiled with the -preprocessor flag DISABLE_PROTOCOLS_TO_PHYSICAL defined in the Sources file.

- -

Windows 2000 Specific

- -

During the installation, -the notify object copies the INF file for the virtual adapter from the -installation media to the system INF directory by using the SetupCopyOEMInf -function. This is done because Windows 2000 does not support the CopyINF directive to copy INF files from another INF file.

- -

BUILDING THE SAMPLE

- -

To -build the sample, type build -ceZ. This command produces the binary -mux.dll, which is the sample notify object.

- -

The sample compiles -properly for 32-bit and 64-bit systems, and builds properly with Microsoft® -Visual C® 6.0.

- -

Preprocessor Flags:

- -

DISABLE_PROTOCOLS_TO_PHYSICAL

- -

When this flag is defined -in the Sources file, the notify object disables the bindings of other protocols -such as TCP/IP to the physical adapters during the installation. When all the -virtual adapters are removed either through the custom property page or as a -result of uninstalling the MUX driver, the notify object re-enables those -bindings.

- -

PASSTHRU_NOTIFY

- -

This flag is defined to -allow the MUX driver to be used in a passthru mode. When this flag is defined, -the notify object:

- -

1)     -Creates -only one virtual miniport for every physical adapter the MUX protocol edge -binds to.

- -

2)     -Disables -the property page to prevent adding of additional virtual miniports.

- -

3)     -Stores -the device name of the virtual adapter in REG_SZ registry value under -HKLM\System\CurrentControlSet\Services\muxp\Parameters\Adapters\{PhysicalAdaptersInstanceGuid}\UpperBindings, -because there is one to one binding. In the MUX mode (when this flag is not -defined), the notify object stores the device name in a REG_MULTI_SZ registry -value as there could be more than one virtual miniports.

- -

You -can also use this notify object with the Passthru driver by doing the -following:

- -

1)     -Change -the protocol name in file src\network\ndis\passthru\passthru.c -from PASSTHRU to MUXP.

- -

2)     -Change -the driver name from Passthru to MUX in the sources file.

- -

3)     -Rebuild -the driver to obtain a mux.sys driver binary.

- -

4)     -Build -the MUX notify object with PASSTHRU_NOTIFY defined.

- -

5)     -Use -the MUX inf files, muxp.inf and mux_mp.inf, to -install the driver and dll.

- -

The benefit of using -techniques in the MUX notify object for a 1:1 intermediate driver (e.g. -Passthru) is to be able to exercise higher level of control over the bindings -of MUX with other components in the system, which is not possible with the IM -filter driver.

- -

CUSTOM_EVENTS

- -

When this macro is -defined, the notify object shows how to send custom events to the MUX IM driver -when a virtual miniport is added or removed.

- -

CODE TOUR

- -

File Manifest

- -
File           Description
Dllmain.cpp    File containing implementations of DLL entry point and exports. 
Implinc.cpp    File including source code for ATL utilities.
mux.htm        The documentation for this sample.
Pch.h          Pre-compiled header file.
Resource.h     The resource header.
notify.cpp     Notify object implementation.
virtual.cpp    Virtual adapter class implementation.
adapter.cpp    Physical adapter class implementation.
common.cpp     Global functions, variables and macro definitions.
mux.def        The sample's linker definition file.
mux.h          The header file for mux.cpp.
virtual.h      Virtual adapter class declaration.
Adapter.h      Physical adapter class declaration.
notify.rc      The resource file.
notify.rgs     Script-based registry.
notifyn.idl    The notify object's .idl file.
setupdi.cpp    Functions to copy the miniport INF file to the system.
 
- -

Top of page

- - - - - -
-

 

-
- -

© 2004 Microsoft -Corporation

- -
- - - - - \ No newline at end of file diff --git a/network/ndis/ndisprot/6x/ndisprot.htm b/network/ndis/ndisprot/6x/ndisprot.htm deleted file mode 100644 index 3e854693..00000000 --- a/network/ndis/ndisprot/6x/ndisprot.htm +++ /dev/null @@ -1,393 +0,0 @@ - - - - - - - - -Sample NDIS connection-less protocol driver sample - - - - - - - -
- -

NDIS connection-less protocol driver -sample

- -

SUMMARY

- -

This sample demonstrates -a connection-less NDIS 6.0 protocol. The driver supports sending and receiving -raw Ethernet frames using ReadFile/WriteFile calls from user-mode. It only -receives frames with a specific EtherType field. As an NDIS protocol, it -illustrates how to establish and tear down bindings to Ethernet adapters, i.e. -those that export medium type NdisMedium802_3. It shows how to set a -packet filter, send and receive data, and handle plug-and-play events.

- -

BUILDING THE SAMPLE

- -

From the -Free or Checked Build environment, execute build -ceZ in the ndisprot -directory.

- -

INSTALLATION

- -

The driver is installed -using the INF file ndisprot.inf, which is provided in the driver directory. In -Network Connections UI, select an adapter and open Properties.

- -

Click Install, -then Protocol, then Add, and then Have disk. Then point to -the location of the .inf and driver.

- -

Select Sample NDIS -Protocol Driver and click OK. After installing the protocol, copy -over the test application prottest.exe to a convenient location. Please note -that the driver service has been set to manual start in the INF file. As a -result, it doesn't get loaded automatically when you install.

- -

USAGE

- -

To start -the driver, type

- -

          Net start ndisprot

- -

 

- -

To stop -the driver, type

- -

          Net stop ndisprot

- -

 

- -

To test -the driver, run prottest. For help on usage, run prottest -?

- -

 

- -
usage: PROTTEST [options] <devicename>
options:
       -e: Enumerate devices
       -r: Read
       -w: Write (default)
       -l <length>: length of each packet (default: 100)
       -n <count>: number of packets (defaults to infinity)
       -m <MAC address> (defaults to local MAC)
- -

 

- -

Prottest exercises the IOCTLs supported -by NDISPROT, and sends and/or receives data on the selected device. In order to -use prottest, the user must have administrative privilege. Users should pass -down a big enough buffer in order to receive the entire received data. If the -length of the buffer passed down is smaller than the length of the received -data, NDISPROT will only copy part of the data and discard the rest when the -given buffer is full.

- -

 

- -

 

- -

Use the –e option to enumerate all -devices to which NDISPROT is bound:

- -
C:\prot>prottest -e
 0. \DEVICE\{9273DA7D-5275-4B9A-AC56-68A49D121F1F}
     - Intel-Based 10/100 Ethernet Card
- -

 

- -

The -following command sends and receives 2 packets on a device). Since these packets are sent to -the local MAC address (default), both packets are received. The device -name parameter to prottest is picked up from the output of prottest –e (see -above).

- -

 

- -
C:\prot>prottest -n 2 \DEVICE\{9273DA7D-5275-4B9A-AC56-68A49D121F1F}
DoWriteProc: finished sending 2 packets of 100 bytes each
DoReadProc finished: read 2 packets
- -

For -security reasons, this driver does not allow packets with fake MAC addresses to -be sent from usermode applications.

- -

TIPS

- -

With a checked version of -ndisprot.sys, you can control the volume of debug information generated by -changing the variable ndisprotDebugLevel. Refer to debug.h for more -information.

- -

CODE TOUR

- -

File Manifest

- -
Directory: Test

-

-
 
 
 
 
 
 
 
 
 
File             Description      
prottest.c       User-mode test application
 
 
Directory: Sys

-

-
 
 
 
 
 
 
 
 
 
File             Description      
debug.c          Routines to aid debugging
debug.h          Debug macro definitions
macros.h         Spinlock, event, referencing macros
ndisbind.c       NDIS protocol entry points to handle binding/unbinding from adapters
ndisprot.h       Data structure definitions
ndisprot.inf     INF file for installing NDISPROT
ntdisp.c         NT Entry points and dispatch routines for NDISPROT
protuser.h       IOCTL and associated structure definitions
recv.c           NDIS protocol entry points for receiving data, and IRP_MJ_READ processing
send.c           NDIS protocol routines for sending data, and IRP_MJ_WRITE processing
 
- -

Top of page

- - - - - -
-

 

-
- -

© Microsoft Corporation -2000

- -
- - - - diff --git a/network/ndis/ndisprot_kmdf/ndisprot.htm b/network/ndis/ndisprot_kmdf/ndisprot.htm deleted file mode 100644 index 88dc4d38..00000000 --- a/network/ndis/ndisprot_kmdf/ndisprot.htm +++ /dev/null @@ -1,197 +0,0 @@ - - - -Sample NDIS connection-less protocol driver sample - - - - -
- -

NDIS connection-less protocol driver sample

- -

SUMMARY

- -

This sample demonstrates a connection-less -NDIS 5.0, 5.1 or 6.0 protocol driver. The driver supports sending and receiving raw Ethernet -frames using ReadFile/WriteFile calls from user-mode. As an NDIS protocol, it illustrates how to -establish and tear down bindings to Ethernet adapters, i.e. those that export medium type -NdisMedium802_3. It shows how to set a packet filter, send and receive data, and handle -plug-and-play events.

- -

The sample works on Windows 2000 and later -platforms.

- -

The sample also demonstrates how to write -a Notify Object dll. The Notify Object is used for calling into the Wdf Coinstaller to install -and load the framework library.

- -

BUILDING THE SAMPLE

- -

From the Free or Checked Build environment, -execute build -ceZ in the ndisprot directory.

-

-

Depending on the build environment, the 50 -subdirectory produces either NDIS5.0 or NDIS 5.1 compatible driver. If built in the Windows 2000 -build environment, it will produce NDIS 5.0 compatible driver. If it's built in the Windows XP or -Window Server 2003 build environment, it will produce NDIS 5.1 compatible driver.

-

-

The 60 subdirectory can be built only in the -Windows Vista build environment. The sample built in this sub directory will be NDIS 6.0 compatible -and will work on Windows Vista and later operating systems.

- - -

INSTALLATION

- -

The driver is installed using the INF file -ndisprot.inf, which is provided in the driver directory. In Network Connections UI, select an -adapter and open Properties.

- -

Click Install, then Protocol, -then Add, and then Have disk. Then point to the location of the .inf and driver.

- -

Select Sample NDIS Protocol Driver and -click OK. After installing the protocol, copy over the test application files uiotest.exe and -protest.exe to a convenient location. Please note that the driver service has been set to manual -start in the INF file. As a result, it doesn't get loaded automatically when you install.

- -

USAGE

- -

To start the driver, type
-          Net start ndisprot

- -

To stop the driver, type
-          Net stop ndisprot

- -

To test the NDIS 5.x driver, run uiotest. -For help on usage, run uiotest -?

- -
-usage: UIOTEST [options] <devicename>
-options:
-       -e: Enumerate devices
-       -r: Read
-       -w: Write (default)
-       -l <length>: length of each packet (default: 100)
-       -n <count>: number of packets (defaults to infinity)
-       -m <MAC address> (defaults to local MAC)
- -

To test the NDIS 6.0 driver, run prottest. -For help on usage, run prottest -?

- -
-usage: PROTTEST [options] <devicename>
-options:
-       -e: Enumerate devices
-       -r: Read
-       -w: Write (default)
-       -l <length>: length of each packet (default: 100)
-       -n <count>: number of packets (defaults to infinity)
-       -m <MAC address> (defaults to local MAC)
- -

Uiotest/Prottest exercises the IOCTLs supported by -NDISPROT, and sends and/or receives data on the selected device. In order to use uiotest/prottest, the -user must have administrative privilege. Users should pass down a big enough buffer in order to receive -the entire received data. If the length of the buffer passed down is smaller than the length of the -received data, NDISPROT will only copy part of the data and discard the rest when the given buffer is -full.

- -

For NDIS 5.x driver, use the –e option on uiotest -to enumerate all devices to which NDISPROT is bound:

- -
-C:\uio>uiotest -e
- 0. \DEVICE\{9273DA7D-5275-4B9A-AC56-68A49D121F1F}
-     - Intel-Based 10/100 Ethernet Card
- -

The following command sends and receives 2 packets -on a device. Since these packets are sent to the local MAC address (default), both packets are received. -The device name parameter to uiotest is picked up from the output of uiotest –e (see above).

- -
-C:\uio>uiotest -n 2 \DEVICE\{9273DA7D-5275-4B9A-AC56-68A49D121F1F}
-DoWriteProc: finished sending 2 packets of 100 bytes each
-DoReadProc finished: read 2 packets
- -

For NDIS 6.0 driver, use the –e option on prottest -to enumerate all devices to which NDISPROT is bound:

- -
-C:\prot>prottest -e
- 0. \DEVICE\{9273DA7D-5275-4B9A-AC56-68A49D121F1F}
-     - Intel-Based 10/100 Ethernet Card
- -

The following command sends and receives 2 packets -on a device. Since these packets are sent to the local MAC address (default), both packets are received. -The device name parameter to prottest is picked up from the output of protest –e (see above).

- -
-C:\prot>prottest -n 2 \DEVICE\{9273DA7D-5275-4B9A-AC56-68A49D121F1F}
-DoWriteProc: finished sending 2 packets of 100 bytes each
-DoReadProc finished: read 2 packets
- -

For security reasons, this driver does not allow -packets with fake MAC addresses to be sent from usermode applications.

- - -

TIPS

- -

With a checked version of ndisprot.sys, you can -control the volume of debug information generated by changing the variable ndisprotDebugLevel. Refer to -debug.h for more information.

- -

CODE TOUR

- -

File Manifest

- -
Directory: 50, 60
-File             Description
-debug.c          Routines to aid debugging
-debug.h          Debug macro definitions
-excallbk.c       Handles load order dependency between this sample and NDISWDM sample
-macros.h         Spinlock, event, referencing macros
-ndisbind.c       NDIS protocol entry points to handle binding/unbinding from adapters
-ndisprot.h       Data structure definitions
-precomp.h        Contains the  precompiled headers
-protuser.h       Has the definitions of ioctls issued by protuser.exe application used on NDIS 6.0  
-nuiouser.h       Has the definitions of ioctls issued by nuiouser.exe application used on NDIS 5.0  
-ndisprot.inf     INF file for installing NDISPROT
-ntdisp.c         NT Entry points and dispatch routines for NDISPROT
-recv.c           NDIS protocol entry points for receiving data, and IRP_MJ_READ processing
-send.c           NDIS protocol routines for sending data, and IRP_MJ_WRITE processing
- -
Directory: NotifyOb
-File             Description
-Common.hpp       Header file containing the common include files for the project
-dllmain.cpp      Handles loading/unloading of Wdf Coinstaller and the notify object dll
-ProtNotify.cpp   Handles loading/unloading the WDF loader during the device installation/removal
-ProtNotify.idl   Defines the interfaces for the notify object dll
-ProtNotify.def   Defines the exports of notify object dll
-
-ProtNotify.rc    Resource file for the notify object dll
-resource.h       Defines the resource ids used by the notify object
- -

Top of page

- - - - - -
-

 

-
- -

© Microsoft Corporation -2000

- -
- - - - - - diff --git a/nfp/net/NetNfpProvider.htm b/nfp/net/NetNfpProvider.htm deleted file mode 100644 index 0c3efbef..00000000 --- a/nfp/net/NetNfpProvider.htm +++ /dev/null @@ -1,1240 +0,0 @@ - - - - - - - - - - - - - - - - - - -
- -

NetNfpProvider

- -

SUMMARY

- -

This -sample demonstrates how to use the User-Mode Driver Framework to write a Near -Field Proximity driver and demonstrates best practices. Typically, a Near Field -Proximity driver would use Near Field technologies like “NFC”, “TransferJet”, or “Bump”. However, this sample uses a -TCP/IPv6 network connection and a static configuration between two machines to -allow simulation of Near Field interaction.

- -

BUILDING THE SAMPLE

- -

Load the NetNfpProvider Visual Studio project file in to Visual -Studio. Use Visual Studio to build the sample. If the build succeeds, you will -find the driver, NetNfpProvider.dll in the binary output directory specified -for the build environment.

- -

INSTALLATION

- -

To install the NetNfpProvider driver:

- -
- -
    -
  1. First - copy the driver binary and the NetNfpProvider.inf file to a directory on - your test machine (for example c:\NetNfpProvider.)
    2. -
  2. Change - to the directory containing the inf and binaries - (for example cd /d c:\NetNfpProvider.)
    3. -
  3. Next - run devcon.exe as follows:
    4. -
- -
- -

devcon.exe install -NetNfpProvider.inf WUDF\NetNfpProvider

- -

DevCon can be found in -the tools directory of your WDK enlistment (for example: -c:\winddk\<bld>\tools\devcon\i386\devcon.exe.)

- -
- -
    -
  1. Create a Windows Firewall rule to allow the NetNfpProvider to receive proximity simulation - requests over the network:
    - Run WF.msc
    - Create a new inbound rule that opens port 9299
    2. -
- -
- -

To update -the NetNfpProvider driver after making any changes:

- -
- -
    -
  1. Increment - the version number found in the INF.  While this is not strictly - necessary, it will help ensure PnP selects your new driver as a better - match for the device.
    2. -
  2. Copy - the updated driver binary and the NetNfpProvider.inf file to a directory - on your test machine (for example c:\ NetNfpProvider.)
    3. -
  3. Change - to the directory containing the inf and binaries - (for example cd /d c:\ NetNfpProvider.)
    4. -
  4. Next - run devcon.exe as follows:
    5. -
- -
- -

devcon.exe update -NetNfpProvider.inf WUDF\NetNfpProvider

- -
- -
- -

TESTING

- -

To test -the NetNfpProvider driver, you can run -NetNfpControl.exe which is built from the src\nfp\net\exe.

- -

First -install the device as described above. Then run NetNfpControl.exe from one -command window.

- -

NetNfpControl console app allows -control of the NetNfpProvider test driver. Both the -local and remote machine must have the NetNfpProvider -driver installed.

- -

USAGE:

- -

Windows Near-field -Proximity Test tool. Designed for simulating proximity hardware.

- -

NetNfpControl.exe -[<remoteMachine>] [/k]

- -

Example: NetNfpControl.exe John-PC1
-The first operating mode allows the user to specify a remote machine name (or -IPv6 address) that the local machine should connect to and simulate proximity -with. After it's connected, a simple key-press ends the simulated proximity -link. The console app then exits.

- -

Example: NetNfpControl.exe John-PC1 -/k
-A second operating mode keeps the console app running with a Ctrl-F1 hotkey -registered (even when running in the background). When the hot key is -intercepted, a near-field proximity event is simulated directly with the -specified remote machine.
-Note: The console app needs to be running (only on one machine) to intercept -the system hot key.

- -

Example: NetNfpControl.exe /k
-A third operating mode also keeps the console app running with a Ctrl-F1 hotkey -registered. However, you'll have to run this on two or more machines at the -same time. Pressing Ctrl-F1 on any two machines at the same time causes the -machines to exchange their network name via a file on a private share with a -special file name.

- -

·         -The -server share used is hard coded to: \\scratch2\scratch\travm\proxrendezvous\

- -

o    -Either -create a file server with these folders shared, or change this to match yours.

- -

·         -The -file has an effective lifetime of 2 seconds.

- -

·         -In -the event of a collision (two clients posting an event during the same -interval), only one client 'wins'.

- -

CODE TOUR

- -

File Manifest

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

File

- 		-

Description

-
-

NetNfpProvider.htm

- 		-

Documentation for this sample - (this file).

-
-

dllsup.cpp

- 		-

DLL - Support code - provides the DLL's entry point as well as the single required - export (DllGetClassObject).

-
-

Exports.def

- 		-

This file lists the functions that - the driver DLL exports.

-
-

Internal.h

- 		-

This is the main header file for - this driver.

-
-

Driver.cpp & Driver.h

- 		-

DriverEntry and events on the Driver Object.

-
-

Device.cpp & Device.h

- 		-

Events on the Device Object.

-
-

Queue.cpp & Queue.h

- 		-

Contains events on the I/O Queue - Objects. IOCTL handlers and filename parsing.

-
-

connection.cpp & connection.h

- 		-

Contains events on the connection - object created per simulated proximity link. This contains the code for - socket client.

-
-

Socketlistener.cpp &

-

Socketlistener.h

- 		-

Contains - a socket listener for accepting inbound proximity simulation requests.

-
-

FileContext.cpp and FileContext.h

- 		-

Defines the context associated with the file object. Per file context - stores per connection information, publications, and subscriptions.

-
-

NetNfpProvider.rc

- 		-

Resource file for the driver.

-
-

NetNfpProvider.inx

- 		-

File that describes the - installation of this driver. The build process converts this into an INF - file.

-
-

WppDefs.h

- 		-

A header used to generate WPP - Macros for this project. Note, with WPP, some comments are actually compiled - by the pre-processor. Thread Local Storage is used to properly indent logs.

-
- -

Top -of Page

- -

© 2012 Microsoft -Corporation

- -
- - - - diff --git a/print/autoconfig/AutoConfig.htm b/print/autoconfig/AutoConfig.htm deleted file mode 100644 index 5a32268c..00000000 --- a/print/autoconfig/AutoConfig.htm +++ /dev/null @@ -1,367 +0,0 @@ - - - - -Auto-Configuration Samples - - - - - -

Auto-Configuration Samples

-

Summary

-

-AutoConfig sample -demonstrates how to implement Unidrv-based and PScript5-based drivers to -leverage the inbox support for auto-configuration.

-

-The sample -works only when used with the standard TCP/IP port monitor or the -Network-Connected Device (NCD) port monitor.

-

 

-

-Note: The -sample is provided here only as a proof of concept.

-

 

-

The -table shown below identifies which operating systems this sample will build and -work on.

-

 

-

 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

- Operating System

 -

- Can sample be - built in the OS? -

-

- Does sample work - in the OS?

 -

- - Can sample be used in a production environment for the OS?

-

- Windows Vista

 -

- Yes

 -

- Yes

 -

- No

-

- Windows Server - 2003

 -

- No

 -

- No

 -

- No

-

- Windows XP

 -

- No

 -

- No

 -

- No

-

- Windows 2000

 -

- No

 -

- No

 -

- No

-

- Windows Me

 -

- No

 -

- No

 -

- No

-

- Windows 98 SE

 -

- No

 -

- No

 -

- No

-

 

-

Auto-Configuration -Basics

-

Prior -to Microsoft® Windows® Vista, the settings of a print queue are set initially to -the driver's default settings, rather than to the appropriate settings based on -the device. For Unidrv or Pscript5, this means that static default values -specified in the GPD or PPD file are used for the initial print queue setup. -This static set of defaults necessarily must represent the minimum configuration -that a printer can ship with. For instance, if a stapling unit is optional for a -device, then by default, such a device cannot have stapling capability enabled, -otherwise the user interface for devices without the stapling unit would show -stapling as an option. A customer who selected the stapling option but found -that it did not work would likely be confused.

-

For any device that -comes with features not present in the basic model, a user or administrator must -manually configure these features on the print queue after installation. This -can at times be a confusing and non-intuitive experience. The configuration -process is easy to get wrong, particularly with regard to internal parameters -such as memory and hard disk size, which significantly can affect printing speed -and quality.

-

Auto-configuration -solves this problem by -automatically configuring the print queue according to the installable features -on the device, rather than simply using the driver's static default settings. -The main target for auto-configuration is network printers. They are the most -likely ones to have multiple optional features and require more manual -configuration.

-

Auto-configuration -works by means of -bi-directional printer communication (also known as bidi communication) between -the print subsystem and the printer. In order for auto-configuration to work, -the printer must be able to:

-

-·                  - -Understand a -query sent by the port monitor.

-

-·                  - -Generate the -appropriate response to the query.

-

To support -auto-configuration, both the printer driver and the port monitor must be -modified.

-

A printer driver -must:

-

-·                  - -Be aware of -the Bidi Notification Schema.

-

-·                  - -Be able to -receive notifications about device configuration changes using the Bidi -Notification Schema.

-

-·                  - -Be able to -solicit configuration data from the printer using the Bidi Communication -Interfaces, and specifically the IBidiSpl2 COM interface (described in -the Platform SDK documentation).

-

A port monitor -must:

-

-·                  - -Support a -device protocol capable of querying the printer's configuration.

-

-·                  - -Be able to -receive unsolicited status messages from the printer.

-

-·                  - -Convert -unsolicited status messages to an appropriate driver notification.

-

-·                  - -Keep all of -the device status and configuration data up-to date by means of polling or -alerts.

-

-·                  - -Inform the -driver or application of any configuration changes in the device.

-

Unidrv-based and -PScript5-based drivers using the standard TCP/IP port monitor or the -Network-Connected Device (NCD) port monitor provide support for -auto-configuration.

-

CODE TOUR

-

 

-

-Unidrv - -Auto-Configuration Sample

-

- 

-

The main part of the -sample is the auto-configuration GDL file ACnfgUni.GDL. This file implements -the  *BidiQuery, *BidiResponse and *Option elements that correspond to the -Memory, DuplexUnit and PrinterHardDisk features in AutoCnfg.GPD file. The -Feature and Option names in the auto-configuration GDL file should exaclty match -the corresponding Feature and Option names in the GPD file. The -auto-configuration GDL file is specified in the GPD file using the *BidiQueryFile -keyword. The auto-configuration GDL content can also be contained directly -inside the GPD file itself instead of in a separate GDL file, in which case the -*BidiQueryFile keyword should specify the GPD file name.

-

 

-

-PScript5 Auto-Configuration -Sample

-

 

-

The -main part of the sample is the auto-configuration GDL file ACnfgPS.GDL. This -file implements the *BidiQuery, *BidiResponse and *Option elements that -corresponds to the InstalledMemory, DuplexUnit and HardDisk features in -AutoCnfg.PPD file. As mentioned for the Unidrv sample, the Feature and Option -names should exactly match. Please note that the GPD and PPD files do not have -the same Feature and Option names. That is why the two GDL files are not -identical. The auto-configuration GDL file is specified in the PPD file using -the *MSBidiQueryFile keyword.

-

INSTALLING/TESTING THE SAMPLE

-

The samples don’t have -any binaries to be built. They may be installed by using Add Printer Wizard and -supplying the AutoCnfg.INF as the INF file. To test the auto-configuration -feature you need to install the driver to a Standard TCP/IP port.  You need a -printer, which understands and responds to the bidi SNMP queries, connected to -the port. The tcpbidi.xml file located in system32 directory has information -about the SNMP OIDs used for each query. The installable options in the device -settings will reflect the information obtained by querying the printer. -

-

File Manifest 

-
 
-
Root:
-
 
-
Files                  Description
-
 
-

AutoConfig.htm      The documentation for this sample -(this file)

-

AutoCnfg.INF        The printer INF that will install -Unidrv and PScript5 auto-configuration samples

-

AutoCnfg.GPD        The GPD file for the Unidrv -auto-configuration sample

-

AutoCnfg.PPD        The PPD file for the PScript5 -auto-configuration sample

-

ACnfgUni.GDL        The GDL file for the Unidrv -auto-configuration sample

-

ACnfgPS.GDL         The GDL file for the PScript5 -auto-configuration sample

-

Resources

-

For -the latest release of the Windows Device Driver Development Kit, see - -http://www.microsoft.com/whdc/ddk/winddk.mspx.

-

 

-

If -you have questions on using or adapting this sample for your project, you can -either contact - -Microsoft Technical Support or post your questions in the - -Microsoft driver development newsgroup.

- - - - diff --git a/print/cpsuisam/cpsui.htm b/print/cpsuisam/cpsui.htm deleted file mode 100644 index a79cb228..00000000 --- a/print/cpsuisam/cpsui.htm +++ /dev/null @@ -1,236 +0,0 @@ - - - - - - - - -CPSUI - - - - - - - - - -
- -

CPSUI

- -

SUMMARY

- -

The Common Property Sheet -User Interface (CPSUI) is a user-mode dynamic link library that enables -developers to create property sheet pages that have a standard appearance.

- -

This application causes -CPSUI to call the Windows® 2000/Windows® XP/Windows® Server 2003 print spooler -to create property sheet pages for the system's default printer. Note that printer -interface DLLs should not do this. The application then creates an additional -property sheet page to illustrate some of the techniques that can be employed when -using CPSUI to create a new page.

- -

BUILDING THE SAMPLE

- -

This sample requires that -the Windows® 2000/Windows® XP/Windows® Server 2003 Software Development Kit and -Driver Development Kit be installed so that the required headers and libs are available.

- -

To build the samples, run -build from this directory. The DLL will be placed in the appropriate -platform directory.

- -

Once built, the sample -produces one binary: Cpsuisam.exe. The sample is 64-bit compliant and compiles -properly with Microsoft® Visual C® 6.0.

- -

CODE TOUR

- -

File Manifest

- -
 
 
Files          Description
Apple.ico      The resource file for a sample icon
Cpsuidat.cpp   The source file that contains all the predefined data
Cpsuidat.h     The header file for CPSUIDAT.cpp
Cpsuisam.c     The source file that implements the sample for the Windows 2000 CPSUI
Cpsuisam.def   The file that lists the exported functions
Cpsuisam.dlg   The resource file for the dialogs
Cpsuisam.h     The header file for CPSUISAM.c
Cpsuisam.ico   The resource file for a sample icon
Debug.c        The source file for debugging functions
Debug.h        The header for Debug.c
Makefile       The generic file for building the code sample
Precomp.h      The header that includes the headers to pre-compile
Cpsui.htm      The documentation for this sample (this file)
Res.rc         The resource file for the module
Sources        The generic file for building the code sample
- -

Top of page

- - - - - -
-

 

-
- -

© 2004 Microsoft -Corporation

- -
- - - - diff --git a/sd/sdiomars/sdiosample.htm b/sd/sdiomars/sdiosample.htm deleted file mode 100644 index e2e24da9..00000000 --- a/sd/sdiomars/sdiosample.htm +++ /dev/null @@ -1,356 +0,0 @@ - - - - - - - - -SDIO Sample Driver - - - - - - - - - -
- -

Driver Framework SDIO Sample Driver

- -

Description

- -

This is a sample for a functional Secure Digital (SD) IO driver. The driver is written using the Kernel Mode Driver Framework. It is a driver for a generic mars development board that implements the SDIO protocol without additional functionality.

- -

Theory of Operation

-

The mars board driver exemplifies several different functions that are essential for writing an SDIO driver that leverages KDMF and the SDBUS API. It will show how to: -
- Install and start an SDIO device. -
- Release an SDIO device. -
- Perform data transfers. -
- Alter the settings that the SDIO device uses to communicate with the SD Host Controller. -

- -

The driver building and -installation instructions given here apply only to Windows® XP and later operating systems.

- -

Note: This sample provides an example -of a minimal driver. Neither the driver nor the sample programs are intended -for use in a production environment. Rather, they are intended for educational -purposes and as a skeleton driver.

- -

Building -the Sample

- -

Click the Free Build -Environment or Checked Build Environment icon under your Development Kits program -group to set basic environment variables needed by the build utility.

- -

Change to the directory -containing the device source code, such as src\sd\sdiomars

- -

Run build -ceZ, or -use the macro BLD. This behavior invokes the Microsoft make routines -that produce log files called Buildxxx.log, and also Buildxxx.wrn and -Buildxxx.err if there are any warnings or errors. Where xxx stands for fre -or chk depending on the environment chosen. If the build succeeds, the -driver mars.sys and the generated inf file mars.inf will be placed in a platform specific subdirectory of your %TargetPath% -directory specified in the Sources file.

- -

Installing -the Sample

- -

To install the bus driver on Windows XP and later operating systems:

- -
    -
  1. Copy mars.sys, mars.inf, kmdfsamples.cat & WDF Coinstaller (wdfcoinstallerMMmmm.dll) to a disk.
    2. -
  2. Double-click the ‘Add Hardware’ wizard in - Control Panel.
    3. -
  3. At the 'Welcome to the Add Hardware Wizard', - click ‘Next’.
    4. -
  4. Select 'Yes, I have already connected the - hardware', then click Next.
    5. -
  5. Select ‘Add a new hardware device’ from the - list, then click Next.
    6. -
  6. Select ‘Install the hardware that I manually - select from a list(Advanced),' and then click next.
    7. -
  7. Select ‘Show All Devices’, then click Next.
    8. -
  8. Click 'Have Disk', make sure that 'A:\' is in - the "Copy manufacturer's files from:" box, and click OK.
    9. -
  9. Click on the desired entry, and then click - Next.
    10. -
  10. At 'The wizard is ready to install your - hardware', click Next.
    11. -
  11. Click Finish at 'Completing the Add/Remove - Hardware Wizard.'
    12. -
-
-

Alternatively, you can -use the DEVCON.EXE from the DDK to install the driver programmatically.

- -

c:\>DEVCON.EXE -INSTALL mars.inf "SD\vid_0388&pid_0000"

- -

The system copies the -mars.sys file to %systemroot%\system32\drivers directory and loads the -driver.

- -

CODE -TOUR

- -

File Manifest

- -
File              Description
 
-
ntddmars.h           Header containing global definitions
-
mars.inx             Device Installation File
-
mars.h               Header containing driver specific definitions
-
mars.c               Source code for driver functions
-
Sources              Generic file for building the code sample.
-
makefile             The file merely indirects to the real makefile that is shared by all the driver components of the windows Driver Kit.
-
makefile.inc         The file stamps the inx file with kmdf version and generates the inf file.
-
sdiosample.htm       Sample Tour documentation for this sample (this file).
- -

 

- -

 

- -
- - - - diff --git a/security/elam/elamsample.htm b/security/elam/elamsample.htm deleted file mode 100644 index 2c93d624..00000000 --- a/security/elam/elamsample.htm +++ /dev/null @@ -1,1110 +0,0 @@ - - - - - - - - - - - - - - - - - - - - -
- -

ELAMSAMPLE

- -

SUMMARY

- -

This -sample demonstrates how to use the APIs IoRegisterBootDriverCallback -and IoUnRegisterBootDriverCallback from an Early -Launch Anti-Malware driver, to receive notifications about the initialization -of regular boot start drivers

- -

The -building and installation instructions given here apply to Windows® 8 and later -operating systems.

- -

This -sample driver is a minimal driver meant to demonstrate the usage of the APIs -mentioned above. It is not intended for use in a production environment.

- -

BUILDING THE SAMPLE

- -

Click the -Free Build Environment or Checked Build Environment icon under Development Kits -program group to set basic environment variables.

- -

Change to -the directory containing the device source code, such as “src\security\elam”.

- -

Run build --ceZ, or use the macro BLD. This command -invokes the Microsoft make routines to build the components. If the build succeeds, you will -find the driver, elamsample.sys, in the binary output directory specified for -the build environment. You can get the output path from the buildxxx.log file. -If it fails you can find errors and warnings in the buildxxx.err -and buildxxx.wrn respectively.

- -

SIGNING THE SAMPLE

- -

Early Launch -drivers are required to be signed with a code-signing certificate that also -contains the Early Launch EKU "1.3.6.1.4.1.311.61.4.1". -In a production environment, Early Launch drivers are signed by Microsoft for -qualifying Anti-Malware vendors with a WHQL certificate that contains this EKU. -The makecert.exe tool can be used to generate a self-signed test certificate -that contains both the Early Launch EKU and the “1.3.6.1.5.5.7.3.3” Code -Signing EKU. Once a certificate of this form has been created, signtool.exe can -be used to sign elamsample.sys.

- -

INSTALLATION

- -

1.    -Copy -the signed elamsample.sys file to the %WINDIR%\System32\Drivers directory on -your test machine.

- -

2.    -Use -the sc.exe tool present in Windows to install the driver:

- -
sc create ElamSample binpath=%windir%\system32\drivers\elamsample.sys type=kernel start=boot error=critical group=Early-Launch
 
- -

3.    -Enable -test signing:

- -

 

- -

bcdedit /set testsigning -on

- -

CODE -TOUR

- -

DriverEntry - Creates a framework driver object and -calls IoRegisterBootDriverCallback to register to -boot driver status callbacks.

- -

ElamSampleEvtDriverUnload: Calls IoUnregisterBootDriverCallback -to unregister for callbacks when elamsample.sys is about to be unloaded.

- -

ElamSampleBootDriverCallback: Dispatches to other -functions to process the specific callback types.

- -

ElamSampleProcessStatusUpdate: Displays callback BdCbStatusUpdate information, such as when dependencies and -drivers are about to be initialized, or when the ELAM driver is about to be -unload.

- -

ElamSampleProcessInitializeImage: Displays callback BdCbInitializeImage information, such as the driver image -name and the name of the entity that signed the driver.

- -

ElamSamplePrintHex: A utility function to display a -buffer in hexadecimal form.

- -

TESTING

- -

After installing the driver, attach the Kernel -Debugger and reboot your test machine. If ELAMSAMPLE_TRACE_LEVEL is set to DPFLTR_ERROR_LEVEL, -traces will be output to the debugger automatically. For example:

- -

ElamSample is being initialized.

- -

ElamSample reports the following dependency is about to be initialized:

- -

ElamSample:    Image name "\FileSystem\RAW"

- -

ElamSample:    Not signed.

- -

 

- -

ElamSample reports that Boot Start driver dependencies are being initialized.

- -

 

- -

ElamSample reports the following dependency is about to be initialized:

- -

ElamSample:    Image name "\SystemRoot\system32\PSHED.dll"

- -

ElamSample:    Image hash algorithm = -0x0000800c.

- -

ElamSample:    Image hash:

- -

ElamSample:    21 29 88 ca 88 ab dc 0f c3 f1 c0 74 df e0 29 58

- -

ElamSample:    2e cd 41 5e 56 bd 77 53 39 9b d9 d7 f4 47 65 d8

- -

ElamSample:    Image is signed by -"Microsoft Windows".

- -

ElamSample:    Certificate issued by -"MSIT Test CodeSign CA 3".

- -

ElamSample:    Certificate thumb print -algorithm = 0x0000800c.

- -

ElamSample:    Certificate thumb print:

- -

ElamSample:    93 29 d5 f2 e2 7a c9 79 41 -b2 6d c0 78 35 2a d3

- -

ElamSample:    da 2d 7e 72 f0 05 5f 8b 63 -8c 7b a2 6b 37 5c 4f

- -

 

- -

ElamSample reports that Boot Start drivers are about to be initialized.

- -

 

- -

ElamSample reports the following Boot Start driver is about to be initialized:

- -

ElamSample:    Image name "\SystemRoot\System32\drivers\rdyboost.sys"

- -

ElamSample:    Registry path -"\Registry\Machine\System\CurrentControlSet\Services\rdyboost"

- -

ElamSample:    Image hash algorithm = -0x0000800c.

- -

ElamSample:    Image hash:

- -

ElamSample:    9e 91 b2 e1 29 97 af e9 ac 6c 48 24 01 43 c8 b4

- -

ElamSample:    f6 81 bf 57 df 80 0b 05 4d 58 bb e6 d9 83 a9 -08

- -

ElamSample:    Image is signed by -"Microsoft Windows".

- -

ElamSample:    Certificate issued by -"MSIT Test CodeSign CA 3".

- -

ElamSample:    Certificate thumb print -algorithm = 0x0000800c.

- -

ElamSample:    Certificate thumb print:

- -

ElamSample:    93 29 d5 f2 e2 7a c9 79 41 -b2 6d c0 78 35 2a d3

- -

ElamSample:    da 2d 7e 72 f0 05 5f 8b 63 -8c 7b a2 6b 37 5c 4f

- -

 

- -

ElamSample reports that all Boot Start drivers have been initialized and that ElamSample is about to be unloaded

- -

ElamSample is being unloaded.

- -

File Manifest

- -
File                           Description
 
ElamSample.htm                 Documentation for this sample (this file).
 
ElamSample.c                   DriverEntry and Callback processing.
ElamSample.h                   Header file with definitions and prototypes.
ElamSample.rc                  Resource file for the sample.
Sources                        Generic file that lists source files and all the build options.
- -

Top -of page -

- - - - - -
-

 

-
- -

© 2011 Microsoft Corporation

- -
- - - - diff --git a/serial/serenum/serenum.htm b/serial/serenum/serenum.htm deleted file mode 100644 index 79387f4e..00000000 --- a/serial/serenum/serenum.htm +++ /dev/null @@ -1,203 +0,0 @@ - - - - - - - - -Serenum - - - - - - - - - -
- -

Serenum

- -

SUMMARY

- -

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.

- -

BUILDING THE SAMPLE

- -

To build the sample, run -the build command. Once built, the sample produces one binary: Serenum.sys. The sample is 64-bit compliant, works on both -x86 and Alpha platforms, and supports both Plug and Play and Power Management. -There is no one Inf for serenum because it is loaded as a filter driver in -different driver stacks. An example of this can be found in %WINDIR%\inf\msports.inf.

- -

CODE TOUR

- -

File Manifest

- -
File           Description
 
Enum.c          Functions that enumerate external serial devices—the main purpose of this driver
Makefile        Makefile for building 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, etc
Serenum.rc      Resource script
Sources         Data file for build.exe
String.c        String handling support; mainly ASCII to UNICODE functionality
 
 
- -

Top of page -

- -
 
- - - - - -
-

 

-
- -
 
 
- -

© -2004 Microsoft Corporation

- -
- - - - diff --git a/setup/devcon/devcon.htm b/setup/devcon/devcon.htm deleted file mode 100644 index 200ecf21..00000000 --- a/setup/devcon/devcon.htm +++ /dev/null @@ -1,680 +0,0 @@ - - - - - - - - -DevCon Sample - - - - - - - -
- -

DevCon Sample

- -

DEVCON

- -

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 Windows DDK.

- -

ABOUT THIS DOCUMENT

- -

This document describes -the DevCon source code, which is included in the -Windows DDK in the /src/setup/devcon directory. It -explains the DevCon design, and describes 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 in the DDK -documentation in Driver Development Tools/Tools for Testing Drivers/DevCon.

- -

SCOPE

- -

These instructions -pertain to Windows XP and Windows Server 2003. DevCon -was designed for use on Windows 2000, Windows XP, and Windows Server 2003. It -will not work on Windows 95, Windows 98, or Windows ME.

- -

HOW IT 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.  -A description of some of the more interesting functions and the APIs they use -follows:

- -

cmdClasses

- -

This command demonstrates -the use of SetupDiBuildClassInfoListEx to enumerate -all device class GUID's. The function SetupDiClassNameFromGuidEx and SetupDiGetClassDescriptionEx -are used to obtain more information about each device class.

- -

cmdListClass

- -

This command demonstrates -the use of SetupDiClassGuidsFromNameEx to enumerate -one or more class GUID's that match the class name. -This command also demonstrates the use of SetupDiGetClassDevsEx -to list all the devices for each class GUID.

- -

cmdFind cmdFindAll cmdStatus

- -

A simple use of EnumerateDevices (explained below) to list devices and -display different levels of information about each device. Note that all but cmdFindAll use DIGCF_PRESENT to only list information about -devices that are currently present. The main functionality for these and -related devices is done inside FindCallback.

- -

cmdEnable cmdDisable cmdRestart

- -

These commands show -how to issue DIF_PROPERTYCHANGE to enable a device, disable a device, or -restart a device. The main functionality for each of these commands is done -inside ControlCallback.

- -

These operations cannot -be done on a remote machine or in the context of Wow64. CFGMGR32 API's should -not be used as they skip class and co-installers.

- -

cmdUpdate

- -

This command shows how to -use UpdateDriverForPlugAndPlayDevices 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

- -

A variation of cmdUpdate to install a driver when there is no associated -hardware. It creates a new root-enumerated device instance and associates it -with a made up hardware ID specified on the command line (which should -correspond to a hardware ID in the INF). This cannot be done on a remote -machine or in the context of Wow64.

- -

cmdRemove

- -

A -command to remove devices. Plug & Play devices that are removed will reappear in -response to cmdRescan. The main functionality of this -command is in RemoveCallback that demonstrates the -use of DIF_REMOVE. This cannot be done on a remote machine or in the context of -Wow64. CFGMGR32 API's should not be used as they skip class and co-installers.

- -

cmdRescan

- -

This command shows the -correct way to rescan for all Plug & Play devices that may have previously -been removed, or that otherwise require a rescan to detect them.

- -

cmdDPAdd

- -

This -command allows you to add a Driver Package to the machine.  The main functionality of this command -demonstrates the use of SetupCopyOEMInf. 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. -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 functionality is not available in Windows 2000 or -earlier.

- -

cmdDPEnum

- -

This -command allows you to enumerate all of the 3rd party Driver Packages -currently installed on the machine and also shows you how to get some common -properties from a Driver Package (Provider, Class description, DriverVer date and version).

- -

cmdDPEnumLegacy

- -

This -command shows you how to enumerate 3rd party Driver Packages on -Windows Server 2003 and earlier operating systems.

- -

Reboot

- -

This function shows how -to correctly reboot the machine from a hardware install program. In particular -it passes flags to ExitWindowsEx that cause the -reboot to be associated with hardware installation. You should never reboot the machine unnecessarily.

- -

EnumerateDevices

- -

Demonstrates -the use of SetupDiGetClassDevsEx to enumerate all -devices or all present devices, either globally or limited to a specific setup -class. -Demonstrates the use of SetupDiCreateDeviceInfoListEx -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 to add a device instance -into a device info list. These last two API's are ideal to obtain a DeviceInfoData structure from a device instance and machine -name when mixing CFGMGR32 API's with SETUPAPI API's. SetupDiGetDeviceInfoListDetail -is called to obtain a remote machine handle that may be passed into CFGMGR32 -API's. 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, -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.

- -

GetDeviceDescription

- -

Shows -how to obtain descriptive information about a device. The friendly name is used if it exists, otherwise the device description is used.

- -

DumpDeviceWithInfo

- -

Shows -how to obtain an instance ID (or use any CFGMGR32 API) given HDEVINFO (device -info list) and PSP_DEVINFO_DATA (device info data).

- -

DumpDeviceStatus

- -

Shows -how to interpret the information returned by CM_Get_DevNode_Status_Ex. -Refer to cfg.h for information returned by this API.

- -

DumpDeviceResources

- -

Shows -how to obtain information about resources used by a device.

- -

DumpDeviceDriverFiles

- -

Provided as a debugging -aid, obtains information about the files apparently being used for a device. It -uses 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. -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 -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 to obtain the list of -compatible drivers. In this case, all drivers are enumerated, however typically -DIF_SELECTBESTCOMPATDRV and SetupDiGetSelectedDriver -would be used together to find which driver the OS would consider to be the -best.

- -

DumpDeviceStack

- -

This function determines -class and device upper and lower filters.

- -

BUILDING THE DEVCON SAMPLE

- -
To build the devcon -sample:
- -

1.      Click the Build Environment icon -of choice in the Development Kits Build Environments sub-menu. This will set up -the correct build environment to build this sample. Note that this sample will -build in the 64-bit environments as well as the 32-bit environments.

- -

2.      In a command window, change to the -directory containing the DevCon source code. For -example:

- -
- -

cd src\setup\devcon

- -
- -

3.      Use the macro BLD or run the -following from the command prompt:

- -
- -

build –c

- -

This invokes the -Microsoft make routines that produce the Build.log, Build.wrn, and Build.err log -files.

- -

When the build completes, -the executable will be placed in the ObjXXX\I386 subdirectory of the -<TARGETPATH> directory specified in the Sources file (depending on build -environment chosen).

- -

If the build does not -succeed, check for these errors: 1) the build environment is not set up -properly, or 2) modifications made to the sample source code introduced errors. -

- -
- -

USING DEVCON

- -

DevCon is provided in ready-to-run form -in tools\devcon. For usage, refer to the document -provided with devcon.exe. DevCon is a command line -utility with built-in documentation available by typing "devcon help".

- -

TESTING

- -

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 *PNP05*" to list status of -all COM ports.

- -

CODE TOUR

- -

File Manifest

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

File

- 		-

Description

-
-

DevCon.htm

- 		-

Sample tour documentation for this binary (this file).

-
-

DevCon.cpp

- 		-

Source file for tmain entry - point and utility functions.

-
-

Cmds.cpp

- 		-

Source file for supported commands.

-
-

Dump.cpp

- 		-

Source file for functions that output information about - devices.

-
-

DevCon.h

- 		-

Header file for sample.

-
-

DevCon.rc

- 		-

Resource file containing some - strings and version information.

-
-

rc_ids.h

- 		-

Header file for resources.

-
-

Msg.mc

- 		-

Message file that is used to build msg.rc - and msg.h used for help texts and other messages.

-
-

Sources

- 		-

Generic file that lists source files and all the build - options.

-
-

Makefile

- 		-

File that redirects to the real make file that is shared - by all the driver components of the Windows DDK.

-
- -

FEEDBACK

- -

We welcome your comments, problem reports -and wish-list requests. Please submit them by pointing your Internet browser to -http://www.microsoft.com/ddk.

- -

Top of page

- - - - - -
-

 

-
- -

© 2004 Microsoft Corporation

- -
- - - - diff --git a/smartcrd/pscr/pscr.htm b/smartcrd/pscr/pscr.htm deleted file mode 100644 index 934a4c0e..00000000 --- a/smartcrd/pscr/pscr.htm +++ /dev/null @@ -1,867 +0,0 @@ - - - - - - - - -PSCR.SYS—PCMCIA Smart Card Driver - - - - - - - - - - -
- -

PSCR.SYS—PCMCIA -Smart Card Driver

- -

SUMMARY

- -

The PCMCIA -Smart Card Driver is used for the SCM PCMCIA smart card reader. This -driver is written using Kernel-Mode Driver Framework.

- -

This -driver implements Plug and Play and Power Management and is compliant with -64-bit versions of Microsoft® Windows®.

- -

BUILDING PSCR.SYS

- -

To build -the Pscr.sys driver, select either the checked or free DDK environment, -navigate to the Bulltlp3 directory, and type build. This driver -uses services provided by the smart card driver library (Smclib.sys), which are -explained in detail in the accompanying documentation.

- -

INSTALLING PSCR.SYS

- -

The -PSCR.SYS driver is included in-box in the Windows Operating Systems. Therefore, -when the SCM 488 PCMCIA reader is inserted, the system will automatically -install the in-box driver. However, if you want to customize the source code of -this driver and would like to replace the in-box driver with your driver, you -can follow the instructions below.

- -

To install -your driver, you will need to provide the INF file (on a disk), WDF coinstaller from the %BASEDIR%\redist\wdf\ directory and the driver file, which will be copied to -your System32\Drivers directory. The INF file makes a reference to the WDF coinstaller.

- -

1.    Launch “Device -Manager” by clicking the “Windows” button and type “devmgmt.msc” in the “Search -programs and files” box.

- -

2.    Locate the SCM 488 -Smartcard reader device from the “Smart cards readers” category.

- -

3.    Right click on the -reader device and select “Update Driver Software…”.

- -

4.    Select “Browse my -computer for driver software”.

- -

5.    Select “Let me pick -from a list of device drivers on my computer”.

- -

6.    Click the “Have -Disk…” button and point it to the folder that contains your driver, INF and -coinstaller.

- -

7.    Follow the -instructions of the device installation wizard to finish the installation.

- -

TOOLS

- -

Microsoft -offers a test tool (Ifdtest.exe) that allows you to use a smart card reader -directly from the command line. Normally, the smart card resource manager is -connected to a reader. To use Ifdtest.exe, you must stop the smart card -resource manager (Scardsvr.exe) by typing net stop scardsvr -at the command line. Ifdtest.exe is also used for the smart card reader logo -test.

- -

The driver -will not unload as long as you have Ifdtest.exe running and connected to the -driver.

- -

You can -download Ifdtest.exe from http://www.microsoft.com/whdc/whql/default.mspx by following the -links for smart cards. You need to order special test smart cards to have your -smart card reader qualify for the "Designed for Windows" logo. You -can find ordering information at http://www.microsoft.com/whdc/whql/default.mspx.  

- -

RESOURCES

- -

ISO 7816 -Part 3 describes smart cards and smart card protocols in detail. Refer to the -PC99 Handbook for smart card reader requirements.

- -

CODE TOUR

- -

File Manifest

- -
Files         Description
PSCR.HTM      The documentation for this sample (this file).
PSCR.RC       Resource definition file for driver.
SOURCES       The generic file for building the code sample.
MAKEFILE      Makefile required to build the driver.
PSCR.INF      The INF file for installing the code sample.
PSCRCB.C      Source file that contains the callback functions for the smart card library.
PSCRCB.H      Function prototypes for the previous file.
PSCRCMD.C     Implements the reader commands.
PSCRCMD.H     Function prototypes for the previous file.
PSCRLOG.MC    Error messages for this driver.
PSCRNT.C      The main source file (load, unload, Plug and Play, Power Management).
PSCRNT.H      Data definitions and prototypes for the previous file.
PSCRRDWR.C    Implements read/write operations.
PSCRRDWR.H    Data definitions and constant definitions for this reader.
PSCRVERS.H    Driver-specific version information.
- -

Programming -Tour

- -

Driver Design

- -

This driver in its -original form was written in WDM. It was converted to KMDF to avail all the -benefits provided by KMDF in terms of reducing complexity and making it robust. -Since this driver still had to work with the existing smartcard library to -handle smartcard specific processing, I couldn’t restrict the driver to using -only KMDF interfaces. I have to escape out of KMDF for processing I/O requests -to get the underlying IRPs and provide that to smartcard library, and use -advanced IRP handling techniques to work around the limitations imposed by -smartcard library. Except for this quirk, the driver as a whole is fully -functional KMDF driver. As a sample, it also makes it easier for somebody to -adapt this driver for USB devices because KMDF has good support for interfacing -with USB devices.

- -

Power Management

- - - -

Power Management is -described in detail in the DDK documentation. There is, however, one situation -that is specific to smart card readers: how to deal with smart card insertions -and removals while the system is in standby or hibernation mode.

- -

Your reader will -not see any card insertion or removal events in these modes, because the bus -might not even have power. You must save the card state before your reader goes -into standby or hibernation mode. After the system returns from these modes, -you need to determine what the state of the card is. You must complete card -tracking calls whenever there was a card in the reader before standby or -hibernation mode or whenever there is a card in the reader after these -modes. This step is necessary because the user could have changed the card -while the system was in a low-power mode.

- -

 

- -

Top -of page -

- - - - - -
-

 

-
- -

© 2004 Microsoft -Corporation -

- -
- - - - - diff --git a/spb/SpbTestTool/SpbTestTool.htm b/spb/SpbTestTool/SpbTestTool.htm deleted file mode 100644 index 5cab8aaa..00000000 --- a/spb/SpbTestTool/SpbTestTool.htm +++ /dev/null @@ -1,2688 +0,0 @@ - - - - - - - - - - - - - - - - - - -
- -

SpbTestTool

- -

Summary

- -

The SpbTestTool sample serves two purposes.  One, it demonstrates how to open a handle to -the SPB controller, use the SPB interface from a KMDF driver, and employ GPIO -passive-level interrupts.  Two, it allows -for communication with a peripheral using SPB commands to aide in debugging.

- -

This sample is incomplete as a driver and merely -demonstrates use of the SPB API and GPIO interrupts.  It is not intended for use in a production -environment.

- -

Building the Sample

- -

Peripheral driver

- -

1.       -Navigate to src\SPB\SpbTestTool\sys and launch -the vcxproj file

- -

2.       -Modify SpbTestTool.inx

- -

a.       -Replace ACPI\SpbTestTool with appropriate -peripheral HWID

- -

b.      -Set the “ConnectInterrupt registery” setting to -1 to connect the first interrupt resource found, otherwise leave at 0 to leave -disconnected.  See SpbTestTool_AddReg -section.

- -

3.       -Build the project in Visual Studio

- -

a.       -Produces SpbTestTool.inf and SpbTestTool.sys

- -

Application

- -

1.       -Navigate to src\SPB\SpbTestTool\exe and launch -the vcxproj file

- -

2.       -Build the project in Visual Studio

- -

a.       -Produces SpbTestTool.exe

- -

Installation

- -

To install the SpbTestTool driver:

- -

1.       -Ensure that the driver builds without errors

- -

2.       -Copy the SYS and INF files to a separate folder

- -

3.       -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.

- -

a.       -devcon.exe -update SpbTestTool.inf ACPI\<hwid>

- -

Code Tour

- -

The following are relevant functions in the SpbTestTool -peripheral 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

- 		-

Closes the handle to the SPB controller.

-
-

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.

-
-

SpbPeripheralFullDuplex

- 		-

Builds a full duplex IO and sends - IOCTL_SPB_FULL_DUPLEX to the SPB controller.

-
-

SpbPeripheralOnComplete

- 		-

Completion callback for all IO.

-
- -

 

- -

The following are relevant functions in the SpbTestTool -peripheral 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.

-
- -

Application Walkthrough

- -

Launching the app

- -

To launch the SpbTestTool application:

- -

1.       -Navigate to the directory with SpbTestTool.exe

- -

2.       -Type the following command in the command -window:

- -

a.       -SpbTestTool.exe

- -

3.       -An alternate peripheral driver path can also be -used.  Note, this driver must implement -the private SpbTestTool interface

- -

a.       -SpbTestTool.exe -/p \\.\<alternate_path>

- -

4.       -An input script can used instead of an -interactive prompt.  The format is one -command per line.  See below for -commands.

- -

a.       -SpbTestTool.exe -/i <script.txt>

- -

Executing commands

- -

The application will loop indefinitely waiting for one of -the following commands.  The commands are -translated to the appropriate SPB API action without any state tracking in the -driver.  Transfer status, buffers, and -error codes are returned as necessary.  -Type ‘help’ at any time to display this 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 primitive is used to synchronize with op-region accesses by firmware.

-
-

unlockconn

- 		-

Unlock the shared connection

-
-

write {}

- 		-

Write byte array to peripherl

-

  > write - {01, 02, 03}

-
-

read <numBytes>

- 		-

Read <numBytes> from peripheral

-

  > read 5

-
-

writeread {} <numBytes>

- 		-

Atomically write byte array to peripheral and read - <numBytes> back

-

  > - writeread {01, 02, 03} 5

-
-

fullduplex {} <numBytes>

- 		-

Simultaneously write byte array to peripheral and - read <numBytes> back

-

  > full - duplex {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.

-
- -

File Manifest

- -

Peripheral driver (spbtesttool.sys)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

File

- 		-

Description

-
-

driver.h, driver.cpp

- 		-

DriverEntry and Events on the Driver Object.

-
-

device.h, device.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

-
-

makefile.inc

- 		-

Defines custom build actions.  Includes the conversion of the .INX file - into a .INF file

-
-

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 a .INF

-
-

trace.h

- 		-

Sets up WPP tracing

-
- -

Application (spbtesttool.exe)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

File

- 		-

Description

-
-

command.h, command.cpp

- 		-

Classes respresenting each of the SpbTestTool - commands.  See Executing commands above

-
-

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

-
- -

 

- -

Copyright © Microsoft Corporation.  All Rights Reserved.

- -
- - - - diff --git a/storage/class/cdrom/src/cdrom.htm b/storage/class/cdrom/src/cdrom.htm deleted file mode 100644 index 483d3c85..00000000 --- a/storage/class/cdrom/src/cdrom.htm +++ /dev/null @@ -1,86 +0,0 @@ - - - - -CD ROM - - - -

CD ROM

- -

SUMMARY

-The CD ROM driver is used to provide access to CD, DVD and Blu-ray drives. It supports Plug and Play, Power Management, and AutoRun (media change notification). It is a 64-bit compliant driver. - -

BUILDING THE SAMPLE

-To build cdrom.sys, you must first set up the DDK/WDK environment on your host machine. The "Installation and Release Notes" in the Windows 2000/XP/Server 2003/Vista/Server 2008/Windows 7 DDK/WDK has a complete description on how to do this. -

    -
  • Click the Free Build Environment or Checked Build Environment icon under your Windows Driver Kit program group to set basic environment variables need by the build utility.
    • -
  • Change to the directory containing the driver source code, such as "cd src\storage\class\cdrom".
    • -
  • Build the driver by typing BLD.
    • -
- -Macro BLD invokes the Microsoft make routines that produce log file called buildxxx_yyy_zzz.log, and also buildxxx_yyy_zzz.wrn and buildxxx_yyy_zzz.err if there are any warnings or errors, where xxx stands for fre or chk depending on the environment chosen, yyy stands for the OS version (W2k, WXP, Wnet or Win7), and zzz stands for platform version (x86, ia64 or amd64). - -

If the build succeeds, the driver will be placed in the binary output directory specified for the build environment. You can get the output path from the buildxxx_yyy_zzz.log file. - -

INSTALLATION

-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. -

    -
  • Click the Free Build Environment or Checked Build Environment icon under your Windows Driver Kit program group to set basic environment variables need by the build utility.
    • -
  • Change to the directory containing the driver source code, such as "cd src\storage\class\cdrom".
    • -
  • Update the "sources" file by changing the "TARGETNAME" from "cdrom" to "mycdrom".
    • -
  • Build the driver by typing BLD.
    • -
  • Locate the "cdrom.inf" file in the binary output directory, and update the file by replacing all "cdrom.sys" occurrences with "mycdrom.sys".
    • -
  • Rename the "cdrom.inf" file to "mycdrom.inf".
    • -
  • Copy "mycdrom.sys" and "mycdrom.inf" from the binary output directory to the test machine, if applicable.
    • -
  • Launch the Device Manager (by clicking on Windows Start, Run option and typing "devmgmt.msc").
    • -
  • Select the appropriate device under the "DVD/CD-ROM drives" category.
    • -
  • On the right-click menu, select "Update Driver Software...".
    • -
  • Select "Browse my computer for driver software".
    • -
  • Select "Let me pick from a list of device drivers on my computer".
    • -
  • Click "Have Disk...", and point to the directory that contains "mycdrom.inf" and "mycdrom.sys".
    • -
  • Click "Next". If you get a warning dialog about installing unsigned driver, click "Yes".
    • -
  • Click "Next" to complete the driver upgrade.
    • -
- -NOTE: After installation completes successfully, "mycdrom.sys" will be the effective driver for the device, "cdrom.sys" will no longer be used. - -

CODE TOUR

-

File Manifest

-
File			Description
-
-
-aacs.c			The CDROM class driver implementation of handling AACS IOCTLs
-autorun.c		Code for supporting media change detection in the cd/dvd driver
-cdrom.c			Main code base
-cdrom.h			Main header file for cdrom.sys
-cdrom.htm		This file
-cdrom.inf		The CDROM class driver configuration file
-cdrom.rc		Resource file
-cdromp.h		Private header file for cdrom.sys modules
-common.c		Shared private routines for cdrom.sys
-data.c			Global data definitions
-guid.c			GUIDs needed for cdrom.sys
-init.c			Initialization routines for cdrom.sys
-ioctl.c			Ioctl dispatch handlers
-ioctl.h			Ioctl dispatch handlers - header file
-makefile		Makefile
-makefile.inc		Makefile used to generate custom targets required by the module
-mmc.c			All functions related to MMC
-mmc.h			All functions related to MMC - header file
-pnppower.c		Functions to handle PnP and Power IRPs
-scratch.c		Functions for using common scratch buffer
-scratch.h		Functions for using common scratch buffer - header file
-sense.c			Functions needed to accurately determine how to retry requests on CDROM device types
-sources			Macro definitions that are recognized by the Build utility
-
-
-
Top of page 

-
-
-
-

-

-
-
© 2008 Microsoft Corporation 

-
diff --git a/storage/class/classpnp/src/classpnp.htm b/storage/class/classpnp/src/classpnp.htm
deleted file mode 100644
index 4c2b159e..00000000
--- a/storage/class/classpnp/src/classpnp.htm
+++ /dev/null
@@ -1,273 +0,0 @@
-
-
-
-
-
-
-
-
-ClassPnP
-
-
-
-
-
-
-
-
-
-

-
-
ClassPnP 

-
-
Summary

-
-
This is the library for
-all storage drivers. It simplifies writing a storage driver by implementing 90 percent
-of the code required to support Plug and Play, Power Management, et cetera.
-This library is used by disk.sys, cdrom.sys
-and the tape class drivers.

-
-
No INF file is needed to
-install this library. The library is 64-bit compliant.

-
-
Building the Sample

-
-
To build the sample, run build.
-Once built, one binary will be created: classpnp.sys.
-This sample is based on live source code, and only builds in the current OS
-build environment.  

-
-
CODE TOUR

-
-
File Manifest

-
-
File                   Description
 
Autorun.c              Media change notification (MCN) code
Class.c                Main code base
Class.rc               Resource file
Class.src              Exports
Classp.h               Private header
Classwmi.c             WMI functionality
Clntirp.c              Client IRP queuing code
Create.c               Create IRP code
Data.c                 Static driver data
Debug.c                Debug code and data
Debug.h                Debug header file
Dictlib.c              File system dictionary code
Lock.c                 Storage remove lock implementation
Makefile               Makefile
Obsolete.c             Obsolete code used by legacy drivers
Power.c                Power code
Retry.c                Transfer packet retry code
Sources                Sources file
Utils.c                Utility code
Xferpkt.c              Transfer packet processing code
 
 

-
-
Top of page
-

-
-
 

-
-
- 
-  
- 
-

-  
 

-  

-
-
 
 

-
-
©
-2004 Microsoft Corporation 

-
-

-
-
-
-
diff --git a/storage/class/disk/src/disk.htm b/storage/class/disk/src/disk.htm
deleted file mode 100644
index bb77f1fd..00000000
--- a/storage/class/disk/src/disk.htm
+++ /dev/null
@@ -1,42 +0,0 @@
-
-
-
-
-Disk
-
-
-
-
Disk 

-
-
Summary

-The Disk sample is used with Classpnp.sys as disk driver. The sample supports Plug and Play, Power Management, WMI, and failure prediction (S.M.A.R.T.), and it is 64-bit compliant.
-
-
Building the Sample

-To build the sample, run the build command. Once built, this sample will create one binary: Disk.sys.
-
-
CODE TOUR

-
File Manifest

-
File			Description
-
-Data.c		List of workarounds for some drives (no code)
-Disk.c		Main code base
-Disk.h		Private header files
-Disk.rc		Resource file
-Diskwmi.c		S.M.A.R.T. WMI implementation
-Drivesup.c		No longer used
-Drivesup.h		No longer used
-Enum.c		Enumeration routines for disk drives
-Makefile		Makefile
-Pnp.c		Start/add/pnp code
-Sources		Sources
-
-
-
Top of page 

-
-
-
-

-

-
-
© 1999 Microsoft Corporation 

-
diff --git a/storage/filters/addfilter/src/addfiltr.htm b/storage/filters/addfilter/src/addfiltr.htm
deleted file mode 100644
index c5a6d676..00000000
--- a/storage/filters/addfilter/src/addfiltr.htm
+++ /dev/null
@@ -1,245 +0,0 @@
-
-
-
-
-
-
-
-
-Addfilter 
-
-
-
-
-
-
-
-

-
-
Addfilter 

-
-
SUMMARY

-
-
Addfilter is a command-line application which
-adds and removes filter drivers for a given drive or volume. It is intended to
-demonstrate how to insert a filter driver into the driver stack of a device.
-The sample illustrates how to do this by using the SetupDi
-APIs. The sample works on the x86 platform. It has
-only been tested in a 32-bit environment. Since Addfilter
-is not a driver, it does not deal with Plug and Play or Power Management. 

-
-
No INF file is needed to
-install this application. 

-
-
BUILDING THE SAMPLE

-
-
Enter the checked or free
-build environment. Then, while in the Addfilter
-sample directory, type build. A successful build produces the executable
-Addfilter.exe. 

-
-
RELEASE NOTES

-
-
1. This initial sample
-does not check the filter for validity before it is added to the driver stack.
-If an invalid filter is added, the specified device may no longer be
-accessible. 

-
-

-
-
Important: If you attempt to add a
-non-existent filter to a boot device and then reboot, the system may show the
-error message INACCESSIBLE_BOOT_DEVICE. If this happens, you will be unable to
-start the computer. To fix this, when the boot menu is displayed at startup, go
-to the Advanced Options screen and select Use Last Known Good Profile. 

-
-

-
-
If you attempt to add a
-non-existent filter to a normal (non-boot) device (CD drive, floppy drive,
-etc.), you will need to go into the Device Manager, uninstall the device,
-reboot, and re-add the device from Add Hardware. Also, be careful not to add a
-filter to a driver with which it is not designed to operate. Unpredictable
-results may ensue. 

-
-
2. The sample is intended
-for use with upper filter drivers only. 

-
-
3. When you add a filter
-to a device, that device needs to be restarted. Depending on the device, this
-may necessitate restarting your computer. The RestartDevice
-function (in Addfilter.c) stops the specified device
-and then restarts it. If the device has been stopped but not restarted, and the
-machine is restarted, the reboot will not necessarily restart the device. You
-will need to call the RestartDevice function
-to restart your device. 

-
-
4. Since the sample
-currently enumerates only disk devices, the sample can only operate on devices
-of this class. One way in which you could extend this sample code is by adding
-another command-line argument that handles other device types. 

-
-
5. The sample runs in
-user mode only. 

-
-
Usage: 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. 

-
-
CODE TOUR

-
-
File Manifest

-
-
File           Description
 
Addfilter.c    Main source file
Addfilter.rc   Version resource file
Sources        Sources file
Makefile       Makefile
 
 

-
-
Top of page
-

-
-
 

-
-
- 
-  
- 
-

-  
 

-  

-
-
 
 

-
-
©
-2004 Microsoft Corporation 

-
-

-
-
-
-
diff --git a/storage/sfloppy/src/sfloppy.htm b/storage/sfloppy/src/sfloppy.htm
deleted file mode 100644
index d46a7567..00000000
--- a/storage/sfloppy/src/sfloppy.htm
+++ /dev/null
@@ -1,187 +0,0 @@
-
-
-
-
-
-
-
-
-SFloppy
-
-
-
-
-
-
-
-

-
-
Sfloppy

-
-
SUMMARY

-
-
The sfloppy
-sample is a super floppy driver that resides in the directory
-\\Ntddk\Src\Storage\sfloppy. It is a class driver for Super Floppy disk drives.
-It sits a level above the port driver (ATAPI, USB, etc) in the driver stack,
-and brokers communication between the application level and the port driver.
-The floppy driver takes requests from filesystem
-drivers and then sends the appropriate SCSI_REQUEST_BLOCK (SRB) to the port
-driver. It is compatible with x86 and IA64 platforms.

-
-
BUILDING THE SAMPLE

-
-
Type build in the
-\\Ntddk\Src\Storage\Sfloppy directory. A successful build produces sfloppy.sys 

-
-
CODE TOUR

-
-
File Manifest

-
-
File           Description
 
Floppy.c       Super Floppy diskette driver  
SFloppy.rc     Resource file
Sources        Sources for build
Sfloppy.inf    INF file super floppy driver

-
-
 

-
-
Top of page
-

-
-
 

-
-
- 
-  
- 
-

-  
 

-  

-
-
 
 

-
-
©
-2004 Microsoft Corporation 

-
-

-
-
-
-
diff --git a/storage/tools/spti/src/spti.htm b/storage/tools/spti/src/spti.htm
deleted file mode 100644
index 17da4a11..00000000
Binary files a/storage/tools/spti/src/spti.htm and /dev/null differ
diff --git a/usb/usbview/usbview.htm b/usb/usbview/usbview.htm
deleted file mode 100644
index 442cdff2..00000000
--- a/usb/usbview/usbview.htm
+++ /dev/null
@@ -1,400 +0,0 @@
-
-
-
-
-
-
-
-
-USBVIEW
-
-
-
-
-
-
-
-

-
-
USBVIEW

-
-
SUMMARY

-
-
Usbview.exe is a Windows
-GUI application that allows you to browse all USB controllers and connected USB
-devices on your system. The left pane in the main application window displays a
-connection-oriented tree view, and the right pane displays the USB data
-structures pertaining to the selected USB device, such as the Device,
-Configuration, Interface, and Endpoint Descriptors, as well as the current
-device configuration.

-
-
This functional
-application sample demonstrates how a user-mode application can enumerate USB
-host controllers, USB hubs, and attached USB devices, and query information
-about the devices from the registry and through USB requests to the devices.

-
-
The IOCTL calls (see the
-system include file USBIOCTL.H) demonstrated by this sample include:

-
-
    
- 
  • IOCTL_GET_HCD_DRIVERKEY_NAME 
    • 
- 
  • IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTION 
    • 
- 
  • IOCTL_USB_GET_NODE_CONNECTION_DRIVERKEY_NAME 
    • 
- 
  • IOCTL_USB_GET_NODE_CONNECTION_INFORMATION 
    • 
- 
  • IOCTL_USB_GET_NODE_CONNECTION_NAME 
    • 
- 
  • IOCTL_USB_GET_NODE_INFORMATION 
    • 
- 
  • IOCTL_USB_GET_ROOT_HUB_NAME
    • 
-

-
-
BUILDING THE SAMPLE

-
-
The Usbview
-sample compiles and links in the standard DDK build environment with Microsoft®
-Visual C® 6.0 on both X86 and Alpha systems, producing a single executable
-binary Usbview.exe. Both free and checked versions can be built, with assertion
-error messages enabled in the checked build to indicate unexpected error
-conditions.

-
-
CODE TOUR

-
-
File Manifest

-
-
Files         Description
Usbview.htm    Documentation for this sample (this file)
Sources        Generic build-compatible sources file for this sample
Resource.h     ID definitions for GUI controls
Usbdesc.h      USB descriptor type definitions
Usbview.h      Main header file for this sample
Vndrlist.h     List of USB Vendor IDs and vendor names
Debug.c        Assertion routines for the checked build
Devnode.c      Routines for accessing DevNode information
Dispaud.c      Routines for displaying USB audio class device information
Display.c      Routines for displaying USB device information
Enum.c         Routines for enumerating host controllers, hubs, and devices
Usbview.c      Entry point and GUI handling routines
Usbview.rc     Menu and dialog definitions
Split.cur      Cursor file
Usb.ico        Application icon file
bang.ico               Application icon file
hub.ico        Application icon file
monitor.ico            Application icon file
port.ico               Application icon file
makefile               DDK build environment makefile
 
 

-
-
Programming Tour

-
-
The major topics covered
-in this tour are: 

-
-
    
- 
  • GUI handling routines 
    • 
- 
  • Device enumeration routines
    • 
- 
  • Device information display routines
    • 
-

-
-
The file Usbview.c contains the sample application entry point and
-GUI handling routines. On entry, the main application window is created, which
-is actually a dialog box as defined in Usbview.rc.
-The dialog box consists of a split window with a tree view control on the left
-side and an edit control on the right side. 

-
-
The routine RefreshTree()
-is called to enumerate USB host controller, hubs, and attached devices and to
-populate the device tree view control. RefreshTree() calls the routine EnumerateHostControllers()
-in Enum.c to enumerate USB host controller, hubs, and
-attached devices. After the device tree view control has been populated, USBView_OnNotify()
-is called when an item is selected in the device tree view control. This calls UpdateEditControl() in Display.c to display
-information about the selected item in the edit control.

-
-
The file Enum.c contains the routines that enumerate the USB bus and
-populate the tree view control. The USB device enumeration and information
-collection process is the main point of this sample application. The
-enumeration process starts at EnumerateHostControllers() and goes like this:

-
-
(1) Enumerate Host
-Controllers and Root Hubs. Host controllers have symbolic link names of the
-form HCDx, where x starts at 0. Use CreateFile()
-to open each host controller symbolic link. Create a node in the tree view to
-represent each host controller. After a host controller has been opened, send
-the host controller an IOCTL_USB_GET_ROOT_HUB_NAME request to get the symbolic
-link name of the root hub that is part of the host controller.

-
-
(2) Enumerate Hubs (Root
-Hubs and External Hubs). Given the name of a hub, use CreateFile() to open the
-hub. Send the hub an IOCTL_USB_GET_NODE_INFORMATION request to get info about
-the hub, such as the number of downstream ports. Create a node in the tree view
-to represent each hub.

-
-
(3) Enumerate Downstream
-Ports. Given a handle to an open hub and the number of downstream ports on the
-hub, send the hub an IOCTL_USB_GET_NODE_CONNECTION_INFORMATION request for each
-downstream port of the hub to get info about the device (if any) attached to
-each port. If there is a device attached to a port, send the hub an
-IOCTL_USB_GET_NODE_CONNECTION_NAME request to get the symbolic link name of the
-hub attached to the downstream port. If there is a hub attached to the
-downstream port, recurse to step (2). Create a node
-in the tree view to represent each hub port and attached device. USB
-configuration and string descriptors are retrieved from attached devices in GetConfigDescriptor() and GetStringDescriptor() by
-sending an IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTION() to the hub to which
-the device is attached.

-
-
The file Display.c contains routines that display information about
-selected devices in the application edit control. Information about the device
-was collected during the enumeration of the device tree. This information
-includes USB device, configuration, and string descriptors and connection and configuration
-information that is maintained by the USB stack. The routines in this file
-simply parse and print the data structures for the device that were collected
-when it was enumerated. The file Dispaud.c parses and
-prints data structures that are specific to USB audio class devices.

-
-
Top of page 

-
-
- 
-  
- 
-

-  
 

-  

-
-
© 2004 Microsoft
-Corporation 

-
-

-
-
-
-
diff --git a/wpd/WpdHelloWorldDriver/WpdHelloWorldDriver.htm b/wpd/WpdHelloWorldDriver/WpdHelloWorldDriver.htm
deleted file mode 100644
index a26ab340..00000000
--- a/wpd/WpdHelloWorldDriver/WpdHelloWorldDriver.htm
+++ /dev/null
@@ -1,536 +0,0 @@
-
-
-
-
-
-
-
-
-WPD Sample Driver
-
-
-
-
-
-
-
-
-
-

-
-
Windows Portable Device (WPD) “Hello
-World” Sample Driver 

-
-
Summary

-
-
This sample contains
-working source code for a WPD driver. 
-WPD Drivers are built using the Windows User-Mode Driver Foundation with
-special processing added to handle WPD messages.

-
-
Building a new WPD Driver

-
-
You are encouraged to use
-this sample code to start building your own WPD Driver. Modify the sample to
-add your own features.

-
-
The following is a
-suggested roadmap to developing your driver:

-
-
*       Create WPD driver shell 

-
-
*       Use sample driver as base

-
-
*       Update the INF to install this
-driver for your device (it will not actually do anything with the device yet)

-
-
*       Start implementing
-functionality.  This is where the driver
-will start interacting with the device:

-
-
*       Object Enumeration

-
-
*       WPD_CATEGORY_OBJECT_ENUMERATION

-
-
*       Properties

-
-
*       Implement Reads, Writes

-
-
*       WPD_CATEGORY_OBJECT_PROPERTIES

-
-
*       Transfer

-
-
*       Implement Resource enumeration,
-reads, writes

-
-
*       WPD_CATEGORY_OBJECT_RESOURCES

-
-
*       Capabilities

-
-
*       WPD_CATEGORY_CAPABILITIES

-
-
*       Remaining commands

-
-
Building the Sample

-
-
Open a free or checked
-DDK build environment, go to this directory, and run build. This creates
-WpdHelloWorldDriver.dll in the Objfre or Objchk directory. Before the sample can be used, it must be
-installed by running the “Add Hardware” Wizard from Control Panel:

-
-
1. Launch the Windows
-"Control Panel".

-
-
2. Double Click the
-"Add Hardware" icon (Click “Classic View” link on the left hand pane
-if you can’t find it).

-
-
3. The "Add
-hardware" Wizard should launch, press the "Next" button. (The
-wizard will do a quick search for devices already installed on the system.  It may take a minute or two.)

-
-
4. Choose the
-"Install the hardware that I manually select from a list (Advanced)"
-option and press the "Next" button.

-
-
5. A list of device
-categories will be shown.  Scroll to the
-very end of the list and select "Windows Portable Devices" option,
-and click “Next”.

-
-
6. Press the "Have
-Disk" button and browse to the location of the device .INF file.

-
-
7. Choose the appropriate
-device to install ("Microsoft WPD Sample” for example) and press the
-"Next" button.

-
-
8. After the files have
-been copied to the system, the device should be installed (you can verify this
-by looking in “Device Manager”).  You can
-now run WPD applications.

-
-
Testing the WPD Driver

-
-
To test the WPD Driver,
-double click the appropriate WPD device icon in “My Computer” to start browsing
-the sample device contents.  Or use the WpdInfo
-development tool included in this kit.

-
-
Supported Configurations

-
-
The WPD DDK sample driver
-has been tested in checked and free builds for both 32 and 64-bit platforms.

-
-
CODE TOUR

-
-
File Manifest

-
-
File                                Description
Device.cpp                          Driver's IWDFDevice implementation
Device.h                            Header file for driver's IWDFDevice implementation
Driver.cpp                          Driver’s IDriverEntry implementation 
Driver.h                            Header file for driver's IDriverEntry implementation
helpers.cpp                         Miscellaneous helper functions
helpers.h                           Miscellaneous helper function definitions
MAKEFILE                            Makefile
makefile.inc                        Makefile
Queue.cpp                           Driver's queue implementation
Queue.h                             Header file for driver’s queue implementation
resource.h                          Resource header
sources                             Sources file
stdafx.h                            Precompiled header file
WpdBaseDriver.cpp                   Implements the main WPD message handler which unpacks and dispatches WPD messages
WpdBaseDriver.h                     Header file for the main WPD message handler
WpdCapabilities.cpp                 Implements the commands related to Capabilities
WpdCapabilities.h                   Header file for Capabilities implementation
WpdObjectEnum.cpp                   Implements the commands related to enumerating contents
WpdObjectEnum.h                     Header file for content enumeration implementation
WpdObjectProperties.cpp             Implements the commands related to handling object meta-data
WpdObjectProperties.h               Header file for commands related to handling object meta-data
WpdObjectResources.cpp              Implements the commands related to transferring data
WpdObjectResources.h                Header file for commands related to transferring data
WpdHelloWorldDriver.cpp             Main DLL file
WpdHelloWorldDriver.def             Exports
WpdHelloWorldDriver.idl             Component Interface file
WpdHelloWorldDriver.inf             Sample Device INF file
WpdHelloWorldDriver.rc              Resource file
WpdHelloWorldDriver.rgs             ATL Self registration file
 
 

-
-
Top of page
-

-
-
 

-
-
- 
-  
- 
-

-  
 

-  

-
-
 
 

-
-
©
-2006 Microsoft Corporation 

-
-

-
-
-
-
diff --git a/wpd/WpdMultiTransportDriver/WpdMultiTransportDriver.htm b/wpd/WpdMultiTransportDriver/WpdMultiTransportDriver.htm
deleted file mode 100644
index ad2abad3..00000000
--- a/wpd/WpdMultiTransportDriver/WpdMultiTransportDriver.htm
+++ /dev/null
@@ -1,535 +0,0 @@
-
-
-
-
-
-
-
-
-WPD Sample Driver
-
-
-
-
-
-
-
-
-
-

-
-
Windows Portable Device (WPD) Multi-Transport Sample Driver 

-
-
Summary

-
-
This sample contains
-working source code for a WPD driver. 
-WPD Drivers are built using the Windows User-Mode Driver Foundation with
-special processing added to handle WPD messages.

-
-
Building a new WPD Driver

-
-
You are encouraged to use
-this sample code to start building your own WPD Driver. Modify the sample to
-add your own features.

-
-
The following is a
-suggested roadmap to developing your driver:

-
-
*       Create WPD driver shell 

-
-
*       Use sample driver as base

-
-
*       Update the INF to install this
-driver for your device (it will not actually do anything with the device yet)

-
-
*       Start implementing
-functionality.  This is where the driver
-will start interacting with the device:

-
-
*       Object Enumeration

-
-
*       WPD_CATEGORY_OBJECT_ENUMERATION

-
-
*       Properties

-
-
*       Implement Reads, Writes

-
-
*       WPD_CATEGORY_OBJECT_PROPERTIES

-
-
*       Transfer

-
-
*       Implement Resource enumeration,
-reads, writes

-
-
*       WPD_CATEGORY_OBJECT_RESOURCES

-
-
*       Capabilities

-
-
*       WPD_CATEGORY_CAPABILITIES

-
-
*       Remaining commands

-
-
Building the Sample

-
-
Open a free or checked
-DDK build environment, go to this directory, and run build. This creates
-WpdMultiTransportDriver.dll in the Objfre or Objchk directory. Before the sample can be used, it must be
-installed by running the “Add Hardware” Wizard from Control Panel:

-
-
1. Launch the Windows
-"Control Panel".

-
-
2. Double Click the
-"Add Hardware" icon (Click “Classic View” link on the left hand pane
-if you can’t find it).

-
-
3. The "Add
-hardware" Wizard should launch, press the "Next" button. (The
-wizard will do a quick search for devices already installed on the system.  It may take a minute or two.)

-
-
4. Choose the
-"Install the hardware that I manually select from a list (Advanced)"
-option and press the "Next" button.

-
-
5. A list of device
-categories will be shown.  Scroll to the
-very end of the list and select "Windows Portable Devices" option,
-and click “Next”.

-
-
6. Press the "Have
-Disk" button and browse to the location of the device .INF file.

-
-
7. Choose the appropriate
-device to install ("Microsoft WPD Sample” for example) and press the
-"Next" button.

-
-
8. After the files have
-been copied to the system, the device should be installed (you can verify this
-by looking in “Device Manager”).  You can
-now run WPD applications.

-
-
Testing the WPD Driver

-
-
To test the WPD Driver,
-double click the appropriate WPD device icon in “My Computer” to start browsing
-the sample device contents.  Or use the WpdInfo
-development tool included in this kit.

-
-
Supported Configurations

-
-
The WPD DDK sample driver
-has been tested in checked and free builds for both 32 and 64-bit platforms.

-
-
CODE TOUR

-
-
File Manifest

-
-
File                                Description
Device.cpp                          Driver's IWDFDevice implementation
Device.h                            Header file for driver's IWDFDevice implementation
Driver.cpp                          Driver’s IDriverEntry implementation 
Driver.h                            Header file for driver's IDriverEntry implementation
helpers.cpp                         Miscellaneous helper functions
helpers.h                           Miscellaneous helper function definitions
MAKEFILE                            Makefile
makefile.inc                        Makefile
Queue.cpp                           Driver's queue implementation
Queue.h                             Header file for driver’s queue implementation
resource.h                          Resource header
sources                             Sources file
stdafx.h                            Precompiled header file
WpdBaseDriver.cpp                   Implements the main WPD message handler which unpacks and dispatches WPD messages
WpdBaseDriver.h                     Header file for the main WPD message handler
WpdCapabilities.cpp                 Implements the commands related to Capabilities
WpdCapabilities.h                   Header file for Capabilities implementation
WpdObjectEnum.cpp                   Implements the commands related to enumerating contents
WpdObjectEnum.h                     Header file for content enumeration implementation
WpdObjectProperties.cpp             Implements the commands related to handling object meta-data
WpdObjectProperties.h               Header file for commands related to handling object meta-data
WpdObjectResources.cpp              Implements the commands related to transferring data
WpdObjectResources.h                Header file for commands related to transferring data
WpdMultiTransportDriver.cpp             Main DLL file
WpdMultiTransportDriver.def             Exports
WpdMultiTransportDriver.idl             Component Interface file
WpdMultiTransportDriver.inf             Sample Device INF file
WpdMultiTransportDriver.rc              Resource file
WpdMultiTransportDriver.rgs             ATL Self registration file
 
 

-
-
Top of page
-

-
-
 

-
-
- 
-  
- 
-

-  
 

-  

-
-
 
 

-
-
©
-2006 Microsoft Corporation 

-
-

-
-
-
-
diff --git a/wpd/WpdWudfSampleDriver/WpdWudfSampleDriver.htm b/wpd/WpdWudfSampleDriver/WpdWudfSampleDriver.htm
deleted file mode 100644
index 6468554e..00000000
--- a/wpd/WpdWudfSampleDriver/WpdWudfSampleDriver.htm
+++ /dev/null
@@ -1,496 +0,0 @@
-
-
-
-
-
-
-
-
-WPD Sample Driver
-
-
-
-
-
-
-
-
-
-

-
-
Windows Portable Device (WPD) Sample
-Driver 

-
-
Summary

-
-
This sample contains
-working source code for a WPD driver. 
-WPD Drivers are built using the Windows User-Mode Driver Foundation with
-special processing added to handle WPD messages.

-
-
Building a new WPD Driver

-
-
You are encouraged to use
-this sample code to start building your own WPD Driver. Modify the sample to
-add your own features.

-
-
The following is a
-suggested roadmap to developing your driver:

-
-
*      
-Create
-WPD driver shell 

-
-
*      
-Use
-sample driver as base

-
-
*      
-Update
-the INF to install this driver for your device (it will not actually do
-anything with the device yet)

-
-
*      
-Start
-implementing functionality.  This is
-where the driver will start interacting with the device:

-
-
*      
-Object
-Enumeration

-
-
*      
-WPD_CATEGORY_OBJECT_ENUMERATION

-
-
*      
-Properties

-
-
*      
-Implement
-Reads, Writes

-
-
*      
-WPD_CATEGORY_OBJECT_PROPERTIES

-
-
*      
-Transfer

-
-
*      
-Implement
-Resource enumeration, reads, writes

-
-
*      
-WPD_CATEGORY_OBJECT_RESOURCES

-
-
*      
-Capabilities

-
-
*      
-WPD_CATEGORY_CAPABILITIES

-
-
*      
-Remaining
-commands

-
-
Building the Sample

-
-
Open a free or checked
-DDK build environment, go to this directory, and run build. This creates
-WpdWudfSampleDriver.dll in the Objfre or Objchk directory. Before the sample can be used, it must be
-installed by running the “Add Hardware” Wizard from Control Panel:

-
-
1. Launch the Windows
-"Control Panel".

-
-
2. Double Click the
-"Add Hardware" icon (Click “Classic View” link on the left hand pane
-if you can’t find it).

-
-
3. The "Add
-hardware" Wizard should launch, press the "Next" button. (The
-wizard will do a quick search for devices already installed on the system.  It may take a minute or two.)

-
-
4. Choose the
-"Install the hardware that I manually select from a list (Advanced)"
-option and press the "Next" button.

-
-
5. A list of device
-categories will be shown.  Scroll to the
-very end of the list and select "Windows Portable Devices" option,
-and click “Next”.

-
-
6. Press the "Have
-Disk" button and browse to the location of the device .INF file.

-
-
7. Choose the appropriate
-device to install ("Microsoft WPD Sample” for example) and press the
-"Next" button.

-
-
8. After the files have
-been copied to the system, the device should be installed (you can verify this
-by looking in “Device Manager”).  You can
-now run WPD applications.

-
-
Testing the WPD Driver

-
-
To test the WPD Driver, double
-click the appropriate WPD device icon in “My Computer” to start browsing the
-sample device contents.  Or use the WpdInfo
-development tool included in this kit.

-
-
Supported Configurations

-
-
The WPD DDK sample driver
-has been tested in checked and free builds for both 32 and 64-bit platforms.

-
-
CODE TOUR

-
-
File Manifest

-
-
File                                Description
ContextMap.h                        Data structure for storing and retrieving driver contexts
Device.cpp                          Driver's IWDFDevice implementation
Device.h                            Header file for driver's IWDFDevice implementation
DeviceObjectFakeContent.h           Encapsulates the WPD device object
Driver.cpp                          Driver’s IDriverEntry implementation 
Driver.h                            Header file for driver's IDriverEntry implementation
FakeContactContent.h                Encapsulates a contact entry
FakeContent.h                       Encapsulates a generic entry
FakeDevice.h                        Implementation of an abstract device (this sample does not talk to real hardware)
FakeImageContent.h                  Encapsulates an image data entry
FakeMusicContent.h                  Encapsulates a music data entry
FakeVideoContent.h                  Encapsulates a video data entry
helpers.cpp                         Miscellaneous helper functions
helpers.h                           Miscellaneous helper function definitions
MAKEFILE                            Makefile
makefile.inc                        Makefile
Queue.cpp                           Driver's queue implementation
NetworkConfigFakeContent.h          Encapsulates a NetworkConfiguration functional object
Queue.h                             Header file for driver’s queue implementation
RenderingInformationFakeContent.h   Encapsulates a RenderinfInformation functional object
resource.h                          Resource header
SampleAudioAnnotation.wav           Sample audio annotation data
SampleContactPhoto.png              Sample photo for a contact
SampleDeviceIcon.ico                Sample device icon
SampleExternalStorageIcon.ico       Sample storage icon
SampleImage.jpg                     Sample image data
SampleImageThumbnail.jpg            Sample thumbnail
SampleInternalStorageIcon.ico       Sample storage icon
SampleMusic.wma                     Sample music data
SampleVideo.wmv                     Sample video data
sources                             Sources file
stdafx.h                            Precompiled header file
StorageObjectFakeContent.h          Encapsulates the behavior for a Storage functional object
WpdBaseDriver.cpp                   Implements the main WPD message handler which unpacks and dispatches WPD messages
WpdBaseDriver.h                     Header file for the main WPD message handler
WpdCapabilities.cpp                 Implements the commands related to Capabilities
WpdCapabilities.h                   Header file for Capabilities implementation
WpdNetworkConfig.cpp                Implements the commands related to Network Configuration functional object
WpdNetworkConfig.h                  Header file for commands related to Network Configuration functional object
WpdObjectEnum.cpp                   Implements the commands related to enumerating contents
WpdObjectEnum.h                     Header file for content enumeration implementation
WpdObjectManagement.cpp             Implements the commands related to managing contents
WpdObjectManagement.h               Header file for commands related to managing contents
WpdObjectProperties.cpp             Implements the commands related to handling object meta-data
WpdObjectProperties.h               Header file for commands related to handling object meta-data
WpdObjectPropertiesBulk.cpp         Implements the commands related to bulk handling of object meta-data
WpdObjectPropertiesBulk.h           Header file for commands related to bulk handling of object meta-data
WpdObjectResources.cpp              Implements the commands related to transferring data
WpdObjectResources.h                Header file for commands related to transferring data
WpdStorage.cpp                      Implements the commands related to Storage functional object
WpdStorage.h                        Header file for commands related to Storage functional object
WpdWudfSampleDriver.cpp             Main DLL file
WpdWudfSampleDriver.def             Exports
WpdWudfSampleDriver.idl             Component Interface file
WpdWudfSampleDriver.inf             Sample Device INF file
WpdWudfSampleDriver.rc              Resource file
WpdWudfSampleDriver.rgs             ATL Self registration file
 
 

-
-
Top of page
-

-
-
 

-
-
- 
-  
- 
-

-  
 

-  

-
-
 
 

-
-
©
-1999 Microsoft Corporation 

-
-

-
-
-
-
-- 
cgit v1.3.1