From ef7ec4ec9ff7ce3c53d60e1c8906915966e17e01 Mon Sep 17 00:00:00 2001 From: Barry Golden Date: Tue, 12 Mar 2019 14:02:43 -0700 Subject: [PATCH] Update README.md for samples portal (#358) * Update README.md for samples portal * Update README.md for samples portal * Removed installwdf * Update fork (#2) * Fix typo ture -> true * Remove InstallWdf sample * Fix typo (#340) ture -> true * Readme typo fix (#349) * Update langid --- TrEE/README.md | 12 + TrEE/tree.yml | 12 - audio/sysvad/README.md | 13 +- audio/sysvad/audio-sysvad.yml | 12 - avstream/avscamera/README.md | 18 +- avstream/avscamera/avstream-avscamera.yml | 12 - avstream/avscamera/mft0/README.md | 34 +++ avstream/avshws/README.md | 13 +- avstream/avshws/avstream-avshws.yml | 12 - avstream/avssamp/README.md | 13 +- avstream/avssamp/avstream-avssamp.yml | 12 - avstream/sampledevicemft/README.md | 14 +- .../avstream-sampledevicemft.yml | 12 - avstream/samplemft0/README.md | 13 +- avstream/samplemft0/avstream-samplemft0.yml | 12 - biometrics/README.md | 35 +-- biometrics/biometrics.yml | 12 - bluetooth/bthecho/bluetooth-bthecho.yml | 12 - bluetooth/bthecho/bthsrv/README.md | 231 ++++++++++++++++++ bluetooth/serialhcibus/README.md | 14 +- .../serialhcibus/bluetooth-serialhcibus.yml | 12 - filesys/cdfs/README.md | 14 +- filesys/cdfs/filesys-cdfs.yml | 12 - filesys/fastfat/README.md | 15 +- filesys/fastfat/filesys-fastfat.yml | 12 - filesys/miniFilter/MetadataManager/README.md | 19 +- .../filesys-minifilter-metadatamanager.yml | 12 - filesys/miniFilter/NameChanger/README.md | 14 +- .../filesys-minifilter-namechanger.yml | 12 - filesys/miniFilter/avscan/README.md | 14 +- .../avscan/filesys-minifilter-avscan.yml | 12 - filesys/miniFilter/cancelSafe/README.md | 14 +- .../filesys-minifilter-cancelsafe.yml | 12 - filesys/miniFilter/cdo/README.md | 15 +- .../miniFilter/cdo/filesys-minifilter-cdo.yml | 12 - filesys/miniFilter/change/README.md | 24 +- .../change/filesys-minifilter-change.yml | 12 - filesys/miniFilter/ctx/README.md | 18 +- .../miniFilter/ctx/filesys-minifilter-ctx.yml | 12 - filesys/miniFilter/delete/README.md | 17 +- .../delete/filesys-minifilter-delete.yml | 12 - filesys/miniFilter/minispy/README.md | 19 +- .../minispy/filesys-minifilter-minispy.yml | 12 - filesys/miniFilter/nullFilter/README.md | 18 +- .../filesys-minifilter-nullfilter.yml | 12 - filesys/miniFilter/passThrough/README.md | 19 +- .../filesys-minifilter-passthrough.yml | 12 - filesys/miniFilter/scanner/README.md | 19 +- .../scanner/filesys-minifilter-scanner.yml | 12 - filesys/miniFilter/simrep/README.md | 19 +- .../simrep/filesys-minifilter-simrep.yml | 12 - filesys/miniFilter/swapBuffers/README.md | 19 +- .../filesys-minifilter-swapbuffers.yml | 12 - general/DCHU/README.md | 24 +- general/DCHU/general-dchu.yml | 11 - general/PLX9x5x/README.md | 31 ++- general/PLX9x5x/general-plx9x5x.yml | 12 - general/SystemDma/wdm/README.md | 18 +- .../SystemDma/wdm/general-systemdma-wdm.yml | 12 - general/WinHEC 2017 Lab/README.md | 11 + .../general-winhec-2017-lab.yml | 11 - general/cancel/README.md | 19 +- general/cancel/general-cancel.yml | 12 - general/echo/kmdf/README.md | 28 ++- general/echo/kmdf/general-echo-kmdf.yml | 12 - general/echo/umdf/README.md | 18 +- general/echo/umdf/general-echo-umdf.yml | 12 - general/echo/umdf2/README.md | 31 ++- general/echo/umdf2/general-echo-umdf2.yml | 12 - general/echo/umdfSocketEcho/README.md | 37 +-- .../general-echo-umdfsocketecho.yml | 12 - general/event/README.md | 21 +- general/event/general-event.yml | 12 - general/filehistory/README.md | 19 +- general/filehistory/general-filehistory.yml | 12 - general/ioctl/kmdf/README.md | 31 ++- general/ioctl/kmdf/general-ioctl-kmdf.yml | 12 - general/ioctl/wdm/README.md | 19 +- general/ioctl/wdm/general-ioctl-wdm.yml | 12 - general/obcallback/README.md | 18 +- general/obcallback/general-obcallback.yml | 12 - general/pcidrv/README.md | 97 ++++---- general/pcidrv/general-pcidrv.yml | 12 - general/perfcounters/kcs/README.md | 17 +- .../kcs/general-perfcounters-kcs.yml | 12 - general/registry/regfltr/README.md | 35 +-- .../regfltr/general-registry-regfltr.yml | 12 - general/registry/regfltr/sys/regfltr.c | 2 +- general/toaster/toastDrv/README.md | 50 ++-- .../toastDrv/general-toaster-toastdrv.yml | 12 - general/toaster/toastpkg/README.md | 50 ++-- .../toastpkg/general-toaster-toastpkg.yml | 12 - general/toaster/umdf2/README.md | 38 +-- .../toaster/umdf2/general-toaster-umdf2.yml | 12 - general/tracing/SystemTraceControl/README.md | 15 +- .../general-tracing-systemtracecontrol.yml | 12 - general/tracing/evntdrv/README.md | 38 +-- .../evntdrv/general-tracing-evntdrv.yml | 12 - general/tracing/tracedriver/README.md | 35 +-- .../general-tracing-tracedriver.yml | 12 - general/umdfSkeleton/README.md | 15 +- general/umdfSkeleton/general-umdfskeleton.yml | 12 - gnss/ReadMe.md | 76 +++--- gnss/gnss.yaml | 10 - gpio/samples/README.md | 14 +- gpio/samples/gpio-samples.yml | 12 - hid/firefly/README.md | 89 +++---- hid/firefly/hid-firefly.yml | 12 - hid/hclient/README.md | 18 +- hid/hclient/hid-hclient.yml | 12 - hid/hidusbfx2/README.md | 14 +- hid/hidusbfx2/hid-hidusbfx2.yml | 12 - hid/vhidmini2/README.md | 21 +- hid/vhidmini2/hid-vhidmini2.yml | 12 - input/kbfiltr/README.md | 16 +- input/kbfiltr/input-kbfiltr.yml | 12 - input/layout/README.md | 15 +- input/layout/input-layout.yml | 12 - input/moufiltr/README.md | 18 +- input/moufiltr/input-moufiltr.yml | 12 - network/config/bindview/README.md | 15 +- .../bindview/network-config-bindview.yml | 12 - network/modem/fakemodem/README.md | 15 +- .../fakemodem/network-modem-fakemodem.yml | 12 - network/ndis/extension/README.md | 19 +- .../ndis/extension/network-ndis-extension.yml | 12 - network/ndis/filter/README.md | 15 +- network/ndis/filter/network-ndis-filter.yml | 12 - network/ndis/mux/README.md | 14 +- network/ndis/mux/network-ndis-mux.yml | 12 - network/ndis/ndisprot/6x/README.md | 22 +- .../ndisprot/6x/network-ndis-ndisprot-6x.yml | 12 - network/ndis/ndisprot_kmdf/README.md | 14 +- .../network-ndis-ndisprot-kmdf.yml | 12 - network/ndis/netvmini/6x/README.md | 15 +- .../netvmini/6x/network-ndis-netvmini-6x.yml | 12 - network/radio/HidSwitchDriverSample/README.md | 25 +- .../network-radio-hidswitchdriversample.yml | 12 - network/radio/RadioManagerSample/README.md | 14 +- .../network-radio-radiomanagersample.yml | 12 - network/trans/WFPSampler/README.md | 14 +- .../WFPSampler/network-trans-wfpsampler.yml | 12 - network/trans/ddproxy/README.md | 15 +- .../trans/ddproxy/network-trans-ddproxy.yml | 12 - network/trans/inspect/README.md | 14 +- .../trans/inspect/network-trans-inspect.yml | 12 - network/trans/msnmntr/README.md | 14 +- .../trans/msnmntr/network-trans-msnmntr.yml | 12 - network/trans/stmedit/README.md | 15 +- .../trans/stmedit/network-trans-stmedit.yml | 12 - network/wlan/WDI/COMMON/ChannelInfo.c | 2 +- network/wlan/WDI/COMMON/MgntActQueryParam.h | 2 +- network/wlan/WDI/PLATFORM/NDIS6/N63C_Oids.c | 4 +- network/wlan/WDI/PLATFORM/NDIS6/N63C_Oids.h | 2 +- network/wlan/WDI/README.md | 12 + network/wlan/WDI/network-wlan-wdi.yml | 12 - network/wlan/ihvsampleui/README.md | 12 + .../ihvsampleui/network-wlan-ihvsampleui.yml | 11 - network/wsk/echosrv/README.md | 14 +- network/wsk/echosrv/network-wsk-echosrv.yml | 12 - nfc/NfcCxSample/README.md | 9 +- nfp/net/inc/README.md | 28 +++ nfp/net/nfp-net.yml | 12 - pofx/PEP/README.md | 19 +- pofx/PEP/pofx-pep.yml | 12 - pofx/UMDF2/README.md | 16 +- pofx/UMDF2/pofx-umdf2.yml | 12 - pofx/WDF/README.md | 18 +- pofx/WDF/pofx-wdf.yml | 12 - pos/drivers/MagneticStripeReader/README.md | 15 +- .../pos-drivers-magneticstripereader.yml | 12 - pos/drivers/barcodescanner/README.md | 15 +- .../pos-drivers-barcodescanner.yml | 12 - .../README.md | 70 ++++-- ...-printer-customization-plug-in-samples.yml | 12 - print/SampleOpenXPS/README.md | 14 +- print/SampleOpenXPS/print-sampleopenxps.yml | 12 - print/SampleXPS/README.md | 15 +- print/SampleXPS/print-samplexps.yml | 12 - print/SimplePipelineFilter/README.md | 15 +- .../print-simplepipelinefilter.yml | 12 - print/XPSDrvSmpl/README.md | 156 ++++++------ print/XPSDrvSmpl/print-xpsdrvsmpl.yml | 12 - print/XpsRasFilter/README.md | 38 +-- print/XpsRasFilter/print-xpsrasfilter.yml | 12 - print/autoconfig/README.md | 26 +- print/autoconfig/print-autoconfig.yml | 12 - print/cpsuisam/README.md | 15 +- print/cpsuisam/print-cpsuisam.yml | 12 - .../PrinterExtensionSample/README.md | 18 +- ...ntdriversamples-printerextensionsample.yml | 12 - .../v4PrintDriver-ConstraintScript/README.md | 22 +- ...samples-v4printdriver-constraintscript.yml | 12 - .../README.md | 51 ++-- ...es-v4printdriver-hostbasedsampledriver.yml | 13 - .../README.md | 29 ++- ...es-v4printdriver-usbmon-bidi-extension.yml | 13 - .../README.md | 35 +-- ...es-v4printdriver-wsdmon-bidi-extension.yml | 12 - sd/miniport/sdhc/README.md | 17 +- sd/miniport/sdhc/sd-miniport-sdhc.yml | 12 - security/elam/README.md | 32 ++- security/elam/security-elam.yml | 12 - sensors/ADXL345Acc/readme.md | 10 + sensors/ADXL345Acc/sensors-adxl345acc.yml | 12 - sensors/Activity/readme.md | 12 +- sensors/Activity/sensors-activity.yml | 12 - sensors/CustomSensors/readme.md | 10 + .../CustomSensors/sensors-customsensors.yml | 12 - sensors/Fusion/readme.md | 12 +- sensors/Fusion/sensors-fusion.yml | 12 - sensors/Pedometer/readme.md | 12 +- sensors/Pedometer/sensors-pedometer.yml | 12 - sensors/SensorsComboDriver/readme.md | 12 +- .../sensors-sensorscombodriver.yml | 12 - .../SimpleDeviceOrientationSensor/readme.md | 12 +- .../sensors-simpledeviceorientationsensor.yml | 12 - serial/VirtualSerial/README.md | 68 +++--- serial/VirtualSerial/serial-virtualserial.yml | 12 - serial/VirtualSerial2/README.md | 69 ++++-- .../VirtualSerial2/serial-virtualserial2.yml | 12 - serial/serenum/README.md | 21 +- serial/serenum/serial-serenum.yml | 12 - serial/serial/README.md | 43 ++-- serial/serial/serial-serial.yml | 12 - setup/devcon/README.md | 109 +++++---- setup/devcon/setup-devcon.yml | 12 - simbatt/README.md | 15 +- simbatt/simbatt.yml | 12 - smartcrd/README.md | 33 +-- smartcrd/smartcrd.yml | 12 - spb/SkeletonI2C/README.md | 44 ++-- spb/SkeletonI2C/spb-skeletoni2c.yml | 12 - spb/SpbTestTool/README.md | 50 ++-- spb/SpbTestTool/spb-spbtesttool.yml | 12 - storage/class/cdrom/README.md | 70 +++--- storage/class/cdrom/storage-class-cdrom.yml | 12 - storage/class/classpnp/README.md | 21 +- .../class/classpnp/storage-class-classpnp.yml | 12 - storage/class/disk/README.md | 46 ++-- storage/class/disk/storage-class-disk.yml | 12 - storage/filters/addfilter/README.md | 20 +- .../addfilter/storage-filters-addfilter.yml | 12 - storage/iscsi/README.md | 22 +- storage/iscsi/storage-iscsi.yml | 12 - storage/miniports/lsi_u3/README.md | 23 +- .../lsi_u3/storage-miniports-lsi-u3.yml | 12 - storage/miniports/storahci/README.md | 18 +- .../storahci/storage-miniports-storahci.yml | 12 - storage/msdsm/README.md | 69 +++--- storage/msdsm/storage-msdsm.yml | 12 - storage/sfloppy/README.md | 21 +- storage/sfloppy/storage-sfloppy.yml | 12 - storage/tools/spti/README.md | 18 +- storage/tools/spti/storage-tools-spti.yml | 12 - thermal/simsensor/README.md | 15 +- thermal/simsensor/thermal-simsensor.yml | 12 - thermal/thermalclient/README.md | 15 +- .../thermalclient/thermal-thermalclient.yml | 12 - tools/dv/samples/DV-FailDriver-WDM/README.md | 32 ++- .../tools-dv-samples-dv-faildriver-wdm.yml | 12 - .../sdv/samples/SDV-FailDriver-KMDF/README.md | 45 ++-- .../tools-sdv-samples-sdv-faildriver-kmdf.yml | 12 - .../sdv/samples/SDV-FailDriver-NDIS/README.md | 37 +-- .../tools-sdv-samples-sdv-faildriver-ndis.yml | 12 - .../samples/SDV-FailDriver-STORPORT/README.md | 43 ++-- ...ls-sdv-samples-sdv-faildriver-storport.yml | 12 - .../sdv/samples/SDV-FailDriver-WDM/README.md | 37 +-- .../tools-sdv-samples-sdv-faildriver-wdm.yml | 12 - usb/UcmCxUcsi/README.md | 48 ++-- usb/UcmCxUcsi/usb-ucmcxucsi.yml | 12 - usb/UcmTcpciCxClientSample/README.md | 100 ++++---- .../usb-ucmtcpcicxclientsample.yml | 12 - usb/UcmUcsiAcpiSample/README.md | 38 ++- .../usb-ucmucsiacpisample.yml | 12 - usb/kmdf_enumswitches/README.md | 67 ++--- .../usb-kmdf-enumswitches.yml | 12 - usb/kmdf_fx2/README.md | 15 +- usb/kmdf_fx2/usb-kmdf-fx2.yml | 12 - usb/ufxclientsample/README.md | 39 +-- usb/ufxclientsample/usb-ufxclientsample.yml | 12 - usb/umdf2_fx2/README.md | 45 ++-- usb/umdf2_fx2/usb-umdf2-fx2.yml | 12 - usb/umdf_filter_kmdf/README.md | 90 ++++--- usb/umdf_filter_kmdf/usb-umdf-filter-kmdf.yml | 12 - usb/umdf_filter_umdf/README.md | 61 ++--- usb/umdf_filter_umdf/usb-umdf-filter-umdf.yml | 12 - usb/umdf_fx2/README.md | 87 +++---- usb/umdf_fx2/usb-umdf-fx2.yml | 12 - usb/usbsamp/README.md | 89 ++++--- usb/usbsamp/usb-usbsamp.yml | 12 - usb/usbview/README.md | 87 +++---- usb/usbview/usb-usbview.yml | 12 - usb/wdf_osrfx2_lab/README.md | 14 +- usb/wdf_osrfx2_lab/usb-wdf-osrfx2-lab.yml | 12 - video/KMDOD/README.md | 36 +-- video/KMDOD/video-kmdod.yml | 12 - video/pixlib/README.md | 15 +- video/pixlib/video-pixlib.yml | 12 - wia/README.md | 48 ++-- wia/wia.yml | 12 - wmi/wmiacpi/README.md | 66 ++--- wmi/wmiacpi/wmi-wmiacpi.yml | 12 - wmi/wmisamp/README.md | 37 +-- wmi/wmisamp/wmi-wmisamp.yml | 12 - wpd/WpdBasicHardwareDriver/README.md | 30 +-- .../wpd-wpdbasichardwaredriver.yml | 12 - wpd/WpdHelloWorldDriver/README.md | 71 +++--- .../wpd-wpdhelloworlddriver.yml | 12 - wpd/WpdMultiTransportDriver/README.md | 17 +- .../wpd-wpdmultitransportdriver.yml | 12 - wpd/WpdServiceSampleDriver/README.md | 17 +- .../wpd-wpdwudfsampledriver.yml | 12 - wpd/WpdWudfSampleDriver/README.md | 18 +- .../wpd-wpdservicesampledriver.yml | 12 - 315 files changed, 3096 insertions(+), 3614 deletions(-) delete mode 100644 TrEE/tree.yml delete mode 100644 audio/sysvad/audio-sysvad.yml delete mode 100644 avstream/avscamera/avstream-avscamera.yml create mode 100644 avstream/avscamera/mft0/README.md delete mode 100644 avstream/avshws/avstream-avshws.yml delete mode 100644 avstream/avssamp/avstream-avssamp.yml delete mode 100644 avstream/sampledevicemft/avstream-sampledevicemft.yml delete mode 100644 avstream/samplemft0/avstream-samplemft0.yml delete mode 100644 biometrics/biometrics.yml delete mode 100644 bluetooth/bthecho/bluetooth-bthecho.yml create mode 100644 bluetooth/bthecho/bthsrv/README.md delete mode 100644 bluetooth/serialhcibus/bluetooth-serialhcibus.yml delete mode 100644 filesys/cdfs/filesys-cdfs.yml delete mode 100644 filesys/fastfat/filesys-fastfat.yml delete mode 100644 filesys/miniFilter/MetadataManager/filesys-minifilter-metadatamanager.yml delete mode 100644 filesys/miniFilter/NameChanger/filesys-minifilter-namechanger.yml delete mode 100644 filesys/miniFilter/avscan/filesys-minifilter-avscan.yml delete mode 100644 filesys/miniFilter/cancelSafe/filesys-minifilter-cancelsafe.yml delete mode 100644 filesys/miniFilter/cdo/filesys-minifilter-cdo.yml delete mode 100644 filesys/miniFilter/change/filesys-minifilter-change.yml delete mode 100644 filesys/miniFilter/ctx/filesys-minifilter-ctx.yml delete mode 100644 filesys/miniFilter/delete/filesys-minifilter-delete.yml delete mode 100644 filesys/miniFilter/minispy/filesys-minifilter-minispy.yml delete mode 100644 filesys/miniFilter/nullFilter/filesys-minifilter-nullfilter.yml delete mode 100644 filesys/miniFilter/passThrough/filesys-minifilter-passthrough.yml delete mode 100644 filesys/miniFilter/scanner/filesys-minifilter-scanner.yml delete mode 100644 filesys/miniFilter/simrep/filesys-minifilter-simrep.yml delete mode 100644 filesys/miniFilter/swapBuffers/filesys-minifilter-swapbuffers.yml delete mode 100644 general/DCHU/general-dchu.yml delete mode 100644 general/PLX9x5x/general-plx9x5x.yml delete mode 100644 general/SystemDma/wdm/general-systemdma-wdm.yml delete mode 100644 general/WinHEC 2017 Lab/general-winhec-2017-lab.yml delete mode 100644 general/cancel/general-cancel.yml delete mode 100644 general/echo/kmdf/general-echo-kmdf.yml delete mode 100644 general/echo/umdf/general-echo-umdf.yml delete mode 100644 general/echo/umdf2/general-echo-umdf2.yml delete mode 100644 general/echo/umdfSocketEcho/general-echo-umdfsocketecho.yml delete mode 100644 general/event/general-event.yml delete mode 100644 general/filehistory/general-filehistory.yml delete mode 100644 general/ioctl/kmdf/general-ioctl-kmdf.yml delete mode 100644 general/ioctl/wdm/general-ioctl-wdm.yml delete mode 100644 general/obcallback/general-obcallback.yml delete mode 100644 general/pcidrv/general-pcidrv.yml delete mode 100644 general/perfcounters/kcs/general-perfcounters-kcs.yml delete mode 100644 general/registry/regfltr/general-registry-regfltr.yml delete mode 100644 general/toaster/toastDrv/general-toaster-toastdrv.yml delete mode 100644 general/toaster/toastpkg/general-toaster-toastpkg.yml delete mode 100644 general/toaster/umdf2/general-toaster-umdf2.yml delete mode 100644 general/tracing/SystemTraceControl/general-tracing-systemtracecontrol.yml delete mode 100644 general/tracing/evntdrv/general-tracing-evntdrv.yml delete mode 100644 general/tracing/tracedriver/general-tracing-tracedriver.yml delete mode 100644 general/umdfSkeleton/general-umdfskeleton.yml delete mode 100644 gnss/gnss.yaml delete mode 100644 gpio/samples/gpio-samples.yml delete mode 100644 hid/firefly/hid-firefly.yml delete mode 100644 hid/hclient/hid-hclient.yml delete mode 100644 hid/hidusbfx2/hid-hidusbfx2.yml delete mode 100644 hid/vhidmini2/hid-vhidmini2.yml delete mode 100644 input/kbfiltr/input-kbfiltr.yml delete mode 100644 input/layout/input-layout.yml delete mode 100644 input/moufiltr/input-moufiltr.yml delete mode 100644 network/config/bindview/network-config-bindview.yml delete mode 100644 network/modem/fakemodem/network-modem-fakemodem.yml delete mode 100644 network/ndis/extension/network-ndis-extension.yml delete mode 100644 network/ndis/filter/network-ndis-filter.yml delete mode 100644 network/ndis/mux/network-ndis-mux.yml delete mode 100644 network/ndis/ndisprot/6x/network-ndis-ndisprot-6x.yml delete mode 100644 network/ndis/ndisprot_kmdf/network-ndis-ndisprot-kmdf.yml delete mode 100644 network/ndis/netvmini/6x/network-ndis-netvmini-6x.yml delete mode 100644 network/radio/HidSwitchDriverSample/network-radio-hidswitchdriversample.yml delete mode 100644 network/radio/RadioManagerSample/network-radio-radiomanagersample.yml delete mode 100644 network/trans/WFPSampler/network-trans-wfpsampler.yml delete mode 100644 network/trans/ddproxy/network-trans-ddproxy.yml delete mode 100644 network/trans/inspect/network-trans-inspect.yml delete mode 100644 network/trans/msnmntr/network-trans-msnmntr.yml delete mode 100644 network/trans/stmedit/network-trans-stmedit.yml delete mode 100644 network/wlan/WDI/network-wlan-wdi.yml delete mode 100644 network/wlan/ihvsampleui/network-wlan-ihvsampleui.yml delete mode 100644 network/wsk/echosrv/network-wsk-echosrv.yml create mode 100644 nfp/net/inc/README.md delete mode 100644 nfp/net/nfp-net.yml delete mode 100644 pofx/PEP/pofx-pep.yml delete mode 100644 pofx/UMDF2/pofx-umdf2.yml delete mode 100644 pofx/WDF/pofx-wdf.yml delete mode 100644 pos/drivers/MagneticStripeReader/pos-drivers-magneticstripereader.yml delete mode 100644 pos/drivers/barcodescanner/pos-drivers-barcodescanner.yml delete mode 100644 print/OEM Printer Customization Plug-in Samples/print-oem-printer-customization-plug-in-samples.yml delete mode 100644 print/SampleOpenXPS/print-sampleopenxps.yml delete mode 100644 print/SampleXPS/print-samplexps.yml delete mode 100644 print/SimplePipelineFilter/print-simplepipelinefilter.yml delete mode 100644 print/XPSDrvSmpl/print-xpsdrvsmpl.yml delete mode 100644 print/XpsRasFilter/print-xpsrasfilter.yml delete mode 100644 print/autoconfig/print-autoconfig.yml delete mode 100644 print/cpsuisam/print-cpsuisam.yml delete mode 100644 print/v4PrintDriverSamples/PrinterExtensionSample/print-v4printdriversamples-printerextensionsample.yml delete mode 100644 print/v4PrintDriverSamples/v4PrintDriver-ConstraintScript/print-v4printdriversamples-v4printdriver-constraintscript.yml delete mode 100644 print/v4PrintDriverSamples/v4PrintDriver-HostBasedSampleDriver/print-v4printdriversamples-v4printdriver-hostbasedsampledriver.yml delete mode 100644 print/v4PrintDriverSamples/v4PrintDriver-USBMon-Bidi-Extension/print-v4printdriversamples-v4printdriver-usbmon-bidi-extension.yml delete mode 100644 print/v4PrintDriverSamples/v4PrintDriver-WSDMon-Bidi-Extension/print-v4printdriversamples-v4printdriver-wsdmon-bidi-extension.yml delete mode 100644 sd/miniport/sdhc/sd-miniport-sdhc.yml delete mode 100644 security/elam/security-elam.yml delete mode 100644 sensors/ADXL345Acc/sensors-adxl345acc.yml delete mode 100644 sensors/Activity/sensors-activity.yml delete mode 100644 sensors/CustomSensors/sensors-customsensors.yml delete mode 100644 sensors/Fusion/sensors-fusion.yml delete mode 100644 sensors/Pedometer/sensors-pedometer.yml delete mode 100644 sensors/SensorsComboDriver/sensors-sensorscombodriver.yml delete mode 100644 sensors/SimpleDeviceOrientationSensor/sensors-simpledeviceorientationsensor.yml delete mode 100644 serial/VirtualSerial/serial-virtualserial.yml delete mode 100644 serial/VirtualSerial2/serial-virtualserial2.yml delete mode 100644 serial/serenum/serial-serenum.yml delete mode 100644 serial/serial/serial-serial.yml delete mode 100644 setup/devcon/setup-devcon.yml delete mode 100644 simbatt/simbatt.yml delete mode 100644 smartcrd/smartcrd.yml delete mode 100644 spb/SkeletonI2C/spb-skeletoni2c.yml delete mode 100644 spb/SpbTestTool/spb-spbtesttool.yml delete mode 100644 storage/class/cdrom/storage-class-cdrom.yml delete mode 100644 storage/class/classpnp/storage-class-classpnp.yml delete mode 100644 storage/class/disk/storage-class-disk.yml delete mode 100644 storage/filters/addfilter/storage-filters-addfilter.yml delete mode 100644 storage/iscsi/storage-iscsi.yml delete mode 100644 storage/miniports/lsi_u3/storage-miniports-lsi-u3.yml delete mode 100644 storage/miniports/storahci/storage-miniports-storahci.yml delete mode 100644 storage/msdsm/storage-msdsm.yml delete mode 100644 storage/sfloppy/storage-sfloppy.yml delete mode 100644 storage/tools/spti/storage-tools-spti.yml delete mode 100644 thermal/simsensor/thermal-simsensor.yml delete mode 100644 thermal/thermalclient/thermal-thermalclient.yml delete mode 100644 tools/dv/samples/DV-FailDriver-WDM/tools-dv-samples-dv-faildriver-wdm.yml delete mode 100644 tools/sdv/samples/SDV-FailDriver-KMDF/tools-sdv-samples-sdv-faildriver-kmdf.yml delete mode 100644 tools/sdv/samples/SDV-FailDriver-NDIS/tools-sdv-samples-sdv-faildriver-ndis.yml delete mode 100644 tools/sdv/samples/SDV-FailDriver-STORPORT/tools-sdv-samples-sdv-faildriver-storport.yml delete mode 100644 tools/sdv/samples/SDV-FailDriver-WDM/tools-sdv-samples-sdv-faildriver-wdm.yml delete mode 100644 usb/UcmCxUcsi/usb-ucmcxucsi.yml delete mode 100644 usb/UcmTcpciCxClientSample/usb-ucmtcpcicxclientsample.yml delete mode 100644 usb/UcmUcsiAcpiSample/usb-ucmucsiacpisample.yml delete mode 100644 usb/kmdf_enumswitches/usb-kmdf-enumswitches.yml delete mode 100644 usb/kmdf_fx2/usb-kmdf-fx2.yml delete mode 100644 usb/ufxclientsample/usb-ufxclientsample.yml delete mode 100644 usb/umdf2_fx2/usb-umdf2-fx2.yml delete mode 100644 usb/umdf_filter_kmdf/usb-umdf-filter-kmdf.yml delete mode 100644 usb/umdf_filter_umdf/usb-umdf-filter-umdf.yml delete mode 100644 usb/umdf_fx2/usb-umdf-fx2.yml delete mode 100644 usb/usbsamp/usb-usbsamp.yml delete mode 100644 usb/usbview/usb-usbview.yml delete mode 100644 usb/wdf_osrfx2_lab/usb-wdf-osrfx2-lab.yml delete mode 100644 video/KMDOD/video-kmdod.yml delete mode 100644 video/pixlib/video-pixlib.yml delete mode 100644 wia/wia.yml delete mode 100644 wmi/wmiacpi/wmi-wmiacpi.yml delete mode 100644 wmi/wmisamp/wmi-wmisamp.yml delete mode 100644 wpd/WpdBasicHardwareDriver/wpd-wpdbasichardwaredriver.yml delete mode 100644 wpd/WpdHelloWorldDriver/wpd-wpdhelloworlddriver.yml delete mode 100644 wpd/WpdMultiTransportDriver/wpd-wpdmultitransportdriver.yml delete mode 100644 wpd/WpdServiceSampleDriver/wpd-wpdwudfsampledriver.yml delete mode 100644 wpd/WpdWudfSampleDriver/wpd-wpdservicesampledriver.yml diff --git a/TrEE/README.md b/TrEE/README.md index 0ae0c52d..3d1f0067 100644 --- a/TrEE/README.md +++ b/TrEE/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: TrEE sample +description: The Trusted Execution Environment (TrEE) sample. +languages: + - cpp +products: + - windows +--- + # TrEE sample + +The Trusted Execution Environment (TrEE) sample. diff --git a/TrEE/tree.yml b/TrEE/tree.yml deleted file mode 100644 index 018a7537..00000000 --- a/TrEE/tree.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: TrEE sample - description: TrEE sample - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /TrEE/TrEESample.sln diff --git a/audio/sysvad/README.md b/audio/sysvad/README.md index 43fd6f3e..6ca6017e 100644 --- a/audio/sysvad/README.md +++ b/audio/sysvad/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: SysVAD Virtual Audio Device Driver Sample +description: The Microsoft SysVAD Virtual Audio Device Driver (SYSVAD) shows how to develop a WDM audio driver that exposes support for multiple audio devices. +languages: + - cpp +products: + - windows +--- + -SysVAD Virtual Audio Device Driver Sample -======================================== +# SysVAD Virtual Audio Device Driver Sample The Microsoft SysVAD Virtual Audio Device Driver (SYSVAD) shows how to develop a WDM audio driver that exposes support for multiple audio devices. diff --git a/audio/sysvad/audio-sysvad.yml b/audio/sysvad/audio-sysvad.yml deleted file mode 100644 index 7ef714a3..00000000 --- a/audio/sysvad/audio-sysvad.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: SysVAD Virtual Audio Device Driver Sample - description: The Microsoft SysVAD Virtual Audio Device Driver (SYSVAD) shows how to develop a WDM audio driver that exposes support for multiple audio devices. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /audio/sysvad/sysvad.sln diff --git a/avstream/avscamera/README.md b/avstream/avscamera/README.md index ef956c88..8a76bfc4 100644 --- a/avstream/avscamera/README.md +++ b/avstream/avscamera/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: AvsCamera - AVStream Camera Sample Driver +description: Provides a pin-centric AVStream capture driver for a simulated front and back camera that performs simulated captures at 320x240 or 640x480 in RGB24, RGB32, YUY2 and NV12 formats at various frame rates. +languages: + - cpp +products: + - windows +--- + -AvsCamera: AVStream Camera Sample Driver -======================================== +# AvsCamera: AVStream Camera Sample Driver + The AvsCamera sample provides a pin-centric AVStream capture driver for a simulated front and back camera. The driver performs simulated captures at 320x240 or 640x480 in RGB24, RGB32, YUY2 and NV12 formats at various frame rates. The purpose of the sample is to demonstrate how to write a fully functional AVStream camera driver. This sample features strong parameter validation and overflow detection. It provides validation and simulation logic for all advanced camera controls in the CCaptureFilter class. A real camera driver would replace the filter automation table and CSensor and CSynthesizer class hierarchies to produce a new camera driver. @@ -16,7 +26,9 @@ This sample features strong parameter validation and overflow detection. It pro The sample comes with its own MFT0 called AvsCameraMft0.dll. This MFT0 is used to parse metadata supplied in the AvsCamera driver samples. The metadata communications from the driver is primarily a private channel to its MFT0. The MFT0 is responsible for reformatting that information for the capture pipeline. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. The sample works on 32-bit and 64-bit x86, amd64 and arm platforms. Once installed, the simulated camera should show in the Windows Inbox camera app. ## Building the sample -The AvsCamera sample can be built by opening the AvsCamera.sln solution file. A successful build produces AvsCamera.sys, AvsCameraMft0.dll, AvsCamera.inf and AvsCamera.cat. + +The AvsCamera sample can be built by opening the AvsCamera.sln solution file. A successful build produces AvsCamera.sys, AvsCameraMft0.dll, AvsCamera.inf and AvsCamera.cat. diff --git a/avstream/avscamera/avstream-avscamera.yml b/avstream/avscamera/avstream-avscamera.yml deleted file mode 100644 index 25e4b8e9..00000000 --- a/avstream/avscamera/avstream-avscamera.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: AvsCamera - AVStream Camera Sample Driver - description: Provides a pin-centric AVStream capture driver for a simulated front and back camera that performs simulated captures at 320x240 or 640x480 in RGB24, RGB32, YUY2 and NV12 formats at various frame rates. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /avstream/avscamera/avscamera.sln diff --git a/avstream/avscamera/mft0/README.md b/avstream/avscamera/mft0/README.md new file mode 100644 index 00000000..8a76bfc4 --- /dev/null +++ b/avstream/avscamera/mft0/README.md @@ -0,0 +1,34 @@ +--- +topic: sample +name: AvsCamera - AVStream Camera Sample Driver +description: Provides a pin-centric AVStream capture driver for a simulated front and back camera that performs simulated captures at 320x240 or 640x480 in RGB24, RGB32, YUY2 and NV12 formats at various frame rates. +languages: + - cpp +products: + - windows +--- + + + +# AvsCamera: AVStream Camera Sample Driver + +The AvsCamera sample provides a pin-centric AVStream capture driver for a simulated front and back camera. The driver performs simulated captures at 320x240 or 640x480 in RGB24, RGB32, YUY2 and NV12 formats at various frame rates. The purpose of the sample is to demonstrate how to write a fully functional AVStream camera driver. + +This sample features strong parameter validation and overflow detection. It provides validation and simulation logic for all advanced camera controls in the CCaptureFilter class. A real camera driver would replace the filter automation table and CSensor and CSynthesizer class hierarchies to produce a new camera driver. + +The sample comes with its own MFT0 called AvsCameraMft0.dll. This MFT0 is used to parse metadata supplied in the AvsCamera driver samples. The metadata communications from the driver is primarily a private channel to its MFT0. The MFT0 is responsible for reformatting that information for the capture pipeline. + +## Universal Windows Driver Compliant + +This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. The sample works on 32-bit and 64-bit x86, amd64 and arm platforms. Once installed, the simulated camera should show in the Windows Inbox camera app. + +## Building the sample + +The AvsCamera sample can be built by opening the AvsCamera.sln solution file. A successful build produces AvsCamera.sys, AvsCameraMft0.dll, AvsCamera.inf and AvsCamera.cat. diff --git a/avstream/avshws/README.md b/avstream/avshws/README.md index 9474ae60..4571ce5e 100644 --- a/avstream/avshws/README.md +++ b/avstream/avshws/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: AVStream simulated hardware sample driver (Avshws) +description: A simulated hardware sample driver providing a pin-centric capture driver to simulate AV capture hardware. +languages: + - cpp +products: + - windows +--- + -AVStream simulated hardware sample driver (Avshws) -================================================== +# AVStream simulated hardware sample driver (Avshws) The AVStream simulated hardware sample driver (Avshws) provides a pin-centric [AVStream](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554240) capture driver for a simulated piece of hardware. This streaming media driver performs video captures at 320 x 240 pixels in either RGB24 or YUV422 format using direct memory access (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 the AVStream class driver. diff --git a/avstream/avshws/avstream-avshws.yml b/avstream/avshws/avstream-avshws.yml deleted file mode 100644 index fb3799fc..00000000 --- a/avstream/avshws/avstream-avshws.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: AVStream simulated hardware sample driver (Avshws) - description: A simulated hardware sample driver providing a pin-centric capture driver to simulate AV capture hardware. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /avstream/avshws/avshws.sln diff --git a/avstream/avssamp/README.md b/avstream/avssamp/README.md index 979dda3c..ec5b07e4 100644 --- a/avstream/avssamp/README.md +++ b/avstream/avssamp/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: AVStream filter-centric simulated capture sample driver (Avssamp) +description: An AVStream filter-centric simulated capture sample driver with functional audio. +languages: + - cpp +products: + - windows +--- + -AVStream filter-centric simulated capture sample driver (Avssamp) -================================================================= +# AVStream filter-centric simulated capture sample driver (Avssamp) The AVStream filter-centric simulated capture sample driver (Avssamp) provides a filter-centric [AVStream](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554240) capture driver with functional audio. This streaming media driver performs video captures at 320 x 240 pixel resolution in RGB24 or YUV422 format while playing a user-provided Pulse Code Modulation (PCM) wave audio file in a loop. The sample demonstrates how to write a filter-centric AVStream minidriver. diff --git a/avstream/avssamp/avstream-avssamp.yml b/avstream/avssamp/avstream-avssamp.yml deleted file mode 100644 index 9b36d54b..00000000 --- a/avstream/avssamp/avstream-avssamp.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: AVStream filter-centric simulated capture sample driver (Avssamp) - description: An AVStream filter-centric simulated capture sample driver with functional audio. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /avstream/avssamp/avssamp.sln diff --git a/avstream/sampledevicemft/README.md b/avstream/sampledevicemft/README.md index 79ddc9f0..ecb5e9c6 100644 --- a/avstream/sampledevicemft/README.md +++ b/avstream/sampledevicemft/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Driver Device Transform Sample +description: A driver device transform which loads in a process streaming an Avstream based camera device using Media Foundation. +languages: + - cpp +products: + - windows +--- + -Driver Device Transform Sample -============================== +# Driver Device Transform Sample + Illustrative example for a *Driver Device Transform* which loads in a process streaming an Avstream based camera device using Media Foundation. A *Driver Device Transform* is a new kind of a transform that's used with a specific camera when capturing video. The *Driver Device Transform* is also known as DeviceMFT because it is the first Device Transform applied to the video source. This *Driver Device Transform* is an alternative to the Driver MFT i.e. MFT0 in that, it caters to the source rather than the streams . An N stream source supporting DeviceMFT will have a single instance of the *Device Driver Transform* loaded, while MFT0 will have *N* instances for each pipeline process. The DeviceMFT can advertise multiple streams at the output, which can differ from the number of streams advertised by the source. This is analogous to having a user mode driver in the MF pipeline which intercepts and processes commands before they enter/ leave the Kernel mode driver loaded for the streaming source. diff --git a/avstream/sampledevicemft/avstream-sampledevicemft.yml b/avstream/sampledevicemft/avstream-sampledevicemft.yml deleted file mode 100644 index 84ffd6d0..00000000 --- a/avstream/sampledevicemft/avstream-sampledevicemft.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Driver Device Transform Sample - description: A driver device transform which loads in a process streaming an Avstream based camera device using Media Foundation. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /avstream/sampledevicemft/SampleDeviceMft.sln diff --git a/avstream/samplemft0/README.md b/avstream/samplemft0/README.md index 111d4073..f7be80e5 100644 --- a/avstream/samplemft0/README.md +++ b/avstream/samplemft0/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Driver MFT Sample +description: A driver MFT for use with a camera's Windows device app. +languages: + - cpp +products: + - windows +--- + -Driver MFT Sample -================= +# Driver MFT Sample Provides a *driver MFT* for use with a camera's UWP device app.A *driver MFT* is a Media Foundation Transform that's used with a specific camera when capturing video. The driver MFT is also known as MFT0 because it is the first MFT applied to the video stream captured from the camera. This MFT can provide a video effect or other processing when capturing photos or video from the camera. It can be distributed along with the driver package for a camera. diff --git a/avstream/samplemft0/avstream-samplemft0.yml b/avstream/samplemft0/avstream-samplemft0.yml deleted file mode 100644 index 5a4e4c0a..00000000 --- a/avstream/samplemft0/avstream-samplemft0.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Driver MFT Sample - description: A driver MFT for use with a camera's Windows device app. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /avstream/samplemft0/SampleMft0.sln diff --git a/biometrics/README.md b/biometrics/README.md index 102a94b8..f7debb2e 100644 --- a/biometrics/README.md +++ b/biometrics/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Windows Biometric Driver Samples (UMDF Version 1) +description: Contains the Windows Biometric Driver Interface sample and the Windows Biometric Service Adapter samples. +languages: + - cpp +products: + - windows +--- + - -Windows Biometric Driver Samples (UMDF Version 1) -================================================= +# Windows Biometric Driver Samples (UMDF Version 1) The Windows Biometric Driver Samples contain the Windows Biometric Driver Interface sample and the Windows Biometric Service Adapter samples. @@ -52,11 +60,11 @@ Design and Operation This sample is taken from the UMDF FX2 sample and has been modified to expose WBDI. It has the necessary hooks to make this a WBDI driver: -- Installs WBDI driver, including correct class GUID settings and icons, and registry settings for Windows Biometric Framework configuration. -- Publishes WBDI device interface. -- Supports all the mandatory [WBDI IOCTLs](http://msdn.microsoft.com/en-us/library/windows/hardware/ff536414). -- Supports cancellation. -- Can be opened with exclusivity. +- Installs WBDI driver, including correct class GUID settings and icons, and registry settings for Windows Biometric Framework configuration. +- Publishes WBDI device interface. +- Supports all the mandatory [WBDI IOCTLs](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/_biometric/#ioctls). +- Supports cancellation. +- Can be opened with exclusivity. All of these things are required for the Windows Biometric Framework service to recognize this device as a biometric device and set up a Biometric Unit. It allows the service to properly control the device. @@ -68,7 +76,7 @@ It uses device level-locking to simplify internal thread synchronization. This m It supports cancellation of any IOCTL which may be I/O intensive, particularly a capture IOCTL. This sample does not have a real capture mechanism, so it is simulated by a 5 second delay returning a capture IOCTL. Cancellation is supported through the mechanism exposed by WUDF, with a callback for a request object. Cancellation support is required for all IOCTLs. -There are hooks for all [WBDI IOCTLs](http://msdn.microsoft.com/en-us/library/windows/hardware/ff536414), including the optional IOCTLs. +There are hooks for all [WBDI IOCTLs](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/_biometric/#ioctls), including the optional IOCTLs. PnP is very simple for this driver. It needs to only implement **OnPrepareHardware** and **OnReleaseHardware** from **IPnpCallbackHardware**. @@ -78,11 +86,10 @@ Some device drivers may need to keep several pending reads to the WinUsb I/O tar WinBio Adapters are plug-in components that provide a standard interface layer between the Windows Biometric Service and a biometric device. The WinBio Service recognizes three types of Adapters: -- Sensor Adapters - expose the sample-capture capabilities of the biometric device. -- Engine Adapters - expose the sample manipulation, template generation, and matching capabilities of the device. -- Storage Adapters - expose the template storage and retrieval capabilities of the device. +- Sensor Adapters - expose the sample-capture capabilities of the biometric device. +- Engine Adapters - expose the sample manipulation, template generation, and matching capabilities of the device. +- Storage Adapters - expose the template storage and retrieval capabilities of the device. For many simple biometric devices, it will only be necessary to write a WBDI driver for the device plus an Engine Adapter to perform matching operations. Consult the programming guidelines in the WinBio Service documentation for more details. -Each Adapter sample contains a well-known interface-discovery function, whose job is to return the address of a function dispatch table. When the WinBio Service loads an Adapter plug-in, it uses the interface-discovery function to locate the dispatch table, and then calls various methods in the table to communicate with the biometric device. The purpose, arguments, and return codes of each Adapter method are described in the WinBio Service programming guidelines. More information on adapter plug-ins is available at [WBDI Plug-in Reference](http://msdn.microsoft.com/en-us/library/windows/desktop/dd401553(v=vs.85).aspx). - +Each Adapter sample contains a well-known interface-discovery function, whose job is to return the address of a function dispatch table. When the WinBio Service loads an Adapter plug-in, it uses the interface-discovery function to locate the dispatch table, and then calls various methods in the table to communicate with the biometric device. The purpose, arguments, and return codes of each Adapter method are described in the WinBio Service programming guidelines. More information on adapter plug-ins is available at [WBDI Plug-in Reference](https://docs.microsoft.com/windows/desktop/SecBioMet/plug-in-reference). diff --git a/biometrics/biometrics.yml b/biometrics/biometrics.yml deleted file mode 100644 index c4d427f7..00000000 --- a/biometrics/biometrics.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Windows Biometric Driver Samples (UMDF Version 1) - description: Contains the Windows Biometric Driver Interface sample and the Windows Biometric Service Adapter samples. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /biometrics/WBDIsample.sln diff --git a/bluetooth/bthecho/bluetooth-bthecho.yml b/bluetooth/bthecho/bluetooth-bthecho.yml deleted file mode 100644 index 7e128d10..00000000 --- a/bluetooth/bthecho/bluetooth-bthecho.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Bluetooth Echo L2CAP Profile Driver - description: Demonstrates development of Bluetooth L2CAP profile drivers using the Bluetooth L2CAP DDIs. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /bluetooth/bthecho/bthecho.sln diff --git a/bluetooth/bthecho/bthsrv/README.md b/bluetooth/bthecho/bthsrv/README.md new file mode 100644 index 00000000..6d3c7215 --- /dev/null +++ b/bluetooth/bthecho/bthsrv/README.md @@ -0,0 +1,231 @@ +--- +topic: sample +name: Bluetooth Echo L2CAP Profile Driver +description: Demonstrates development of Bluetooth L2CAP profile drivers using the Bluetooth L2CAP DDIs. +languages: + - cpp +products: + - windows +--- + + + +# Bluetooth Echo L2CAP Profile Driver + +This sample demonstrates developing [Bluetooth L2CAP profile drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff536598) using [Bluetooth L2CAP DDIs](http://msdn.microsoft.com/en-us/library/windows/hardware/ff536585).The sample includes two drivers. One for a device that acts as an L2CAP server and another for a device that acts as an L2CAP client. The server simply echoes back any data that it receives from client on the same L2CA channel. These drivers can be used with devices that can be installed with bth.inf. Such devices get installed as 'Generic Bluetooth Radio'. Examples of such devices are Bluetooth USB dongles such as (but not limited to): + +``` +Generic Bluetooth Radio=\ + BthUsb, USB\Vid_0a12&Pid_0001 +CSR Nanosira=\ + BthUsb, USB\Vid_0a12&Pid_0003 +CSR Nanosira WHQL Reference Radio=\ + BthUsb, USB\Vid_0a12&Pid_0004 +CSR Nanosira-Multimedia=\ + BthUsb, USB\Vid_0a12&Pid_0005 +CSR Nanosira-Multimedia WHQL Reference Radio=\ + BthUsb, USB\Vid_0a12&Pid_0006 +``` + +Please refer to bth.inf for the complete list of devices. The installation steps below describe how to install echo server and client with such a device. Please note that RFCOMM based profiles must be developed and accessed using user-mode socket APIs. + +Build the sample +---------------- + +You can build the sample in two ways: using the Visual Studio Integrated Development Environment (IDE) or from the command line using the Visual Studio Command Prompt window and the Microsoft Build Engine (MSBuild.exe). + +**Building the sample using Visual Studio** + +1. Open Visual Studio. From the **File** menu, select **Open Project/Solution** and open the bthecho.sln project file. +2. Right-click the solution in the **Solution Explorer** and select **Configuration Manager**. +3. From the **Configuration Manager**, select the **Active Solution Configuration** and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. +4. From the **Build** menu, click **Build Solution** (Ctrl+Shift+B). + +**Building the sample using the command line (MSBuild)** + +1. Open a Visual Studio Command Prompt window. Click **Start** and search for **Developer Command Prompt**. If your project is under %PROGRAMFILES%, you need to open the command prompt window using elevated permissions (**Run as administrator**). From this window you can use MsBuild.exe to build any Visual Studio project by specifying the project (.VcxProj) or solutions (.Sln) file. +2. Navigate to each of the respective project directories and enter the appropriate **MSbuild** command for your target. For example, to perform a clean build of a Visual Studio driver project called BthEcho.vcxproj, navigate to the samples\\bluetooth\\bthecho\\bthcli\\sys project directory and enter the following MSBuild command: **msbuild /t:clean /t:build .\\BthEchoSampleCli.vcxproj**. +3. If the build succeeds, you will find the driver (BthEchoSampleCli.sys) in the binary output directory corresponding to the target platform. + +Run the sample +-------------- + +**INSTALLATION** + +**Note**: Bluetooth echo server device and echo client device must be installed on two different machines, as described below. + +**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). + +3. Step \#2 causes BthEnum.sys to create a PDO. Consequently hardware installation wizard gets launched. Either go through the UI and point it to the temporary directory where you copied the binaries in step \#1, or using devcon.exe from the tools\\devcon folder, run the following command from the temporary directory: + + ``` + 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. + +**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) | + -------------------- + ^ + | (Bth port driver loaded by bthusb.sys) + | --------------------- ---------------------- + -----| bthport.SYS |<--->| 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. In the **Bluetooth Devices** window, click the **Add a device** button. + +5. In the Add a Device wizard select the server machine (the machine where you installed the echo server) as a Bluetooth device. If the server machine does not appear, please check the echo server installation and make sure that you have enabled 'Allow Bluetooth device to find this computer' on the server machine as explained above. When the server machine is correctly displayed, select it and pick 'Next'. + +6. The wizard should default to a numeric compare ceremony for pairing the machines. When this happens, ensure the numbers match on both the client and the server, select 'Yes' on both machines to indicate they match, and click 'Next' on both machines to complete the pairing. + +7. 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** + + +- 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. + +**CODE TOUR** + +**Common code** + +**Connection object**: The common code contains implementation of a connection object (in connection.\*) that is utilized by both client and the server. Client uses this object to maintain the information about opened connection and the server uses this object to maintain information about the accepted connection. Connection object also supports continuous reader which is utilized by server to read the data sent by client. Connection object is implemented as a WDF user object. Connection details are maintained in BTHECHO\_CONNECTION structure. This structure is used as the context for WDF user object. Passive dispose is used to make the connection object cleanup wait for disconnect completion and continuous reader rundown. Please see WDF documentation for WDF user object and passive dispose (see WdfObjectCreate). + +**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). + +**Shutdown**: Server removes the SDP record and unregisters L2CAP server and PSM in BthEchoSrvEvtDeviceSelfManagedIoCleanup (this callback is invoked by WDF during device removal). It also disconnects any open connections (see Connection rundown above). + +**Client** + +**Startup**: Client retrieves local and server Bluetooth address in BthEchoSrvEvtDeviceSelfManagedIoInit (this callback is invoked by WDF during device start). Please note that server Bluetooth address would be available regardless of presence of the server. Thus echo client device start doesn't fail even if echo server is not available. + +**Connecting to server**: Client connects to echo server when application opens a handle to it (BthEchoCliEvtDeviceFileCreate) and closes the connection on file close (BthEchoCliEvtFileClose). + +**Sending and receiving data from server**: When application writes data to the client, client sends this data to server on the connection opened for the given handle. Server would echo back this data. This data is retrieved by the application using a read operation. Echo Sample Client doesn't do any draining of echoed data on its own. Application read/write are handled using a parallel WDF I/O queue. + +**Shutdown**: Client doesn't need any specific shutdown code as connection open/close and read/write are done within the context of application's handle open. + + diff --git a/bluetooth/serialhcibus/README.md b/bluetooth/serialhcibus/README.md index 9fc965b6..8e585493 100644 --- a/bluetooth/serialhcibus/README.md +++ b/bluetooth/serialhcibus/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Bluetooth Serial HCI Bus Driver +description: Demonstrates how to implement a basic bus driver to support the new Bluetooth Extensibility transport DDIs over the UART transport. +languages: + - cpp +products: + - windows +--- + -Bluetooth Serial HCI Bus Driver -=============================== +# Bluetooth Serial HCI Bus Driver The purpose of this sample is to demonstrate how to implement a basic bus driver to support the new [Bluetooth Extensibility transport DDIs](http://msdn.microsoft.com/en-us/library/windows/hardware/ff536585) 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. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. **Note** This sample driver is generic. It is not designed for a specific device and allows for a vendor to adopt and enhance it for supporting Bluetooth. diff --git a/bluetooth/serialhcibus/bluetooth-serialhcibus.yml b/bluetooth/serialhcibus/bluetooth-serialhcibus.yml deleted file mode 100644 index 9c2f19fb..00000000 --- a/bluetooth/serialhcibus/bluetooth-serialhcibus.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Bluetooth Serial HCI Bus Driver - description: Demonstrates how to implement a basic bus driver to support the new Bluetooth Extensibility transport DDIs over the UART transport. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /bluetooth/serialhcibus/serialhcibus.sln diff --git a/filesys/cdfs/README.md b/filesys/cdfs/README.md index cbe8e4c4..ff09194b 100644 --- a/filesys/cdfs/README.md +++ b/filesys/cdfs/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: CDFS File System Driver +description: The CD-ROM file system driver (cdfs) sample is a file system driver for removable media. +languages: + - cpp +products: + - windows +--- + - -CDFS File System Driver -======================= +# CDFS File System Driver The CD-ROM file system driver (cdfs) sample is a sample file system driver that you can use to write new file systems. diff --git a/filesys/cdfs/filesys-cdfs.yml b/filesys/cdfs/filesys-cdfs.yml deleted file mode 100644 index 077aabec..00000000 --- a/filesys/cdfs/filesys-cdfs.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: CDFS File System Driver - description: The CD-ROM file system driver (cdfs) sample is a file system driver for removable media. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /filesys/cdfs/cdfs.sln diff --git a/filesys/fastfat/README.md b/filesys/fastfat/README.md index 801e3f73..6988b362 100644 --- a/filesys/fastfat/README.md +++ b/filesys/fastfat/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: fastfat File System Driver +description: A file system driver based on the Windows inbox FastFAT file system used as a model for new file systems. +languages: + - cpp +products: + - windows +--- + - - -fastfat File System Driver -========================== +# fastfat File System Driver The *fastfat* sample is file system driver that you can use as a model to write new file systems. diff --git a/filesys/fastfat/filesys-fastfat.yml b/filesys/fastfat/filesys-fastfat.yml deleted file mode 100644 index 168a8169..00000000 --- a/filesys/fastfat/filesys-fastfat.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: fastfat File System Driver - description: A file system driver based on the Windows inbox FastFAT file system used as a model for new file systems. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /filesys/fastfat/fastfat.sln diff --git a/filesys/miniFilter/MetadataManager/README.md b/filesys/miniFilter/MetadataManager/README.md index 2c56f719..31676011 100644 --- a/filesys/miniFilter/MetadataManager/README.md +++ b/filesys/miniFilter/MetadataManager/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Metadata Manager File System Minifilter Driver +description: An example of how to use files for storing metadata that corresponds to minifilters. +languages: + - cpp +products: + - windows +--- + - -Metadata Manager File System Minifilter Driver -============================================== +# Metadata Manager File System Minifilter Driver The Metadata Manager minifilter sample serves as an example if you want to use files for storing metadata that corresponds to your minifilters. The implementation of this sample depicts scenarios in which modifications to the file might have to be blocked or the minifilter might be required to close the file temporarily. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. -Design and Operation --------------------- +## Design and Operation The Metadata Manager minifilter opens a file when it is first loaded. After that, the minifilter monitors open, close, file control, device control, and Plug and Play (PnP) operations to identify scenarios in which it should close its metadata file or block all writes to it. Applications such as chkdsk obtain implicit or explicit exclusive locks on the volume, and the metadata minifilter demonstrates how to maintain a metadata file without interfering with such lock acquisitions. @@ -28,4 +36,3 @@ Similarly, the minifilter might close its metadata file if it sees an explicit F The metadata minifilter also handles the case when a snapshot of its volume object is being taken. In this scenario, the minifilter acquires a shared exclusive lock on the metadata resource object while calling the callback that corresponds to the pre-device control operation for IOCTL\_VOLSNAP\_FLUSH\_AND\_HOLD\_WRITES. The lock is later released in the callback that corresponds to the post-device control operation for IOCTL\_VOLSNAP\_FLUSH\_AND\_HOLD\_WRITES. The lock is acquired to prevent any modifications on the metadata file while the snapshot is being taken. For more information on file system minifilter design, start with the [File System Minifilter Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540402) section in the Installable File Systems Design Guide. - diff --git a/filesys/miniFilter/MetadataManager/filesys-minifilter-metadatamanager.yml b/filesys/miniFilter/MetadataManager/filesys-minifilter-metadatamanager.yml deleted file mode 100644 index 11dddd29..00000000 --- a/filesys/miniFilter/MetadataManager/filesys-minifilter-metadatamanager.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Metadata Manager File System Minifilter Driver - description: An example of how to use files for storing metadata that corresponds to minifilters. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /filesys/miniFilter/MetadataManager/MetadataManager.sln diff --git a/filesys/miniFilter/NameChanger/README.md b/filesys/miniFilter/NameChanger/README.md index 71b857ef..b4257d91 100644 --- a/filesys/miniFilter/NameChanger/README.md +++ b/filesys/miniFilter/NameChanger/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: NameChanger File System Minifilter Driver +description: Grafts a directory from one part of a volume's namespace to another part using a mapping. +languages: + - cpp +products: + - windows +--- + - -NameChanger File System Minifilter Driver -========================================= +# NameChanger File System Minifilter Driver The *NameChanger* minifilter grafts a directory from one part of a volume's namespace to another part using a mapping. The minifilter maintains this illusion by acting as a name provider, injecting entries into directory enumerations and forwarding directory change notifications. diff --git a/filesys/miniFilter/NameChanger/filesys-minifilter-namechanger.yml b/filesys/miniFilter/NameChanger/filesys-minifilter-namechanger.yml deleted file mode 100644 index c8448c80..00000000 --- a/filesys/miniFilter/NameChanger/filesys-minifilter-namechanger.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: NameChanger File System Minifilter Driver - description: Grafts a directory from one part of a volume's namespace to another part using a mapping. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /filesys/miniFilter/NameChanger/NameChanger.sln diff --git a/filesys/miniFilter/avscan/README.md b/filesys/miniFilter/avscan/README.md index d1159670..2086c987 100644 --- a/filesys/miniFilter/avscan/README.md +++ b/filesys/miniFilter/avscan/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: AvScan File System Minifilter Driver +description: This filter is a transaction-aware file scanner that examines data in files. +languages: + - cpp +products: + - windows +--- + - -AvScan File System Minifilter Driver -==================================== +# AvScan File System Minifilter Driver The AvScan minifilter is a transaction-aware file scanner. This is an example for developers who intend to write filters that examine data in files. Typically, anti-virus products fall into this category. diff --git a/filesys/miniFilter/avscan/filesys-minifilter-avscan.yml b/filesys/miniFilter/avscan/filesys-minifilter-avscan.yml deleted file mode 100644 index 4dc19a30..00000000 --- a/filesys/miniFilter/avscan/filesys-minifilter-avscan.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: AvScan File System Minifilter Driver - description: This filter is a transaction-aware file scanner that examines data in files. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /filesys/miniFilter/avscan/avscan.sln diff --git a/filesys/miniFilter/cancelSafe/README.md b/filesys/miniFilter/cancelSafe/README.md index 3e4c7b06..93aebaaa 100644 --- a/filesys/miniFilter/cancelSafe/README.md +++ b/filesys/miniFilter/cancelSafe/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: CancelSafe File System Minifilter Driver +description: A minifilter demonstrating the use of cancel-safe queues. +languages: + - cpp +products: + - windows +--- + - -CancelSafe File System Minifilter Driver -======================================== +# CancelSafe File System Minifilter Driver The CancelSafe filter is a sample minifilter that you use if you want to use cancel-safe queues. diff --git a/filesys/miniFilter/cancelSafe/filesys-minifilter-cancelsafe.yml b/filesys/miniFilter/cancelSafe/filesys-minifilter-cancelsafe.yml deleted file mode 100644 index 3219f608..00000000 --- a/filesys/miniFilter/cancelSafe/filesys-minifilter-cancelsafe.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: CancelSafe File System Minifilter Driver - description: A minifilter demonstrating the use of cancel-safe queues. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /filesys/miniFilter/cancelSafe/cancelSafe.sln diff --git a/filesys/miniFilter/cdo/README.md b/filesys/miniFilter/cdo/README.md index 2c0a03fa..bdbea50d 100644 --- a/filesys/miniFilter/cdo/README.md +++ b/filesys/miniFilter/cdo/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: CDO File System Minifilter Driver +description: An example of using a control device object (CDO) with a minifilter. +languages: + - cpp +products: + - windows +--- + - -CDO File System Minifilter Driver -================================= +# CDO File System Minifilter Driver The CDO minifilter sample is an example if you intend to use a control device object (CDO) with your minifilters. Although the filter manager infrastructure provides a message interface for communication between applications and minifilters, you might need explicit CDOs while the minifilters interface with legacy software. This sample shows how to create and use a CDO with minifilters. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. Design and Operation diff --git a/filesys/miniFilter/cdo/filesys-minifilter-cdo.yml b/filesys/miniFilter/cdo/filesys-minifilter-cdo.yml deleted file mode 100644 index ee34df68..00000000 --- a/filesys/miniFilter/cdo/filesys-minifilter-cdo.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: CDO File System Minifilter Driver - description: An example of using a control device object (CDO) with a minifilter. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /filesys/miniFilter/cdo/cdo.sln diff --git a/filesys/miniFilter/change/README.md b/filesys/miniFilter/change/README.md index 3e4af1db..8a2e39ad 100644 --- a/filesys/miniFilter/change/README.md +++ b/filesys/miniFilter/change/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Change File System Minifilter Driver +description: A transaction-aware filter that monitors file changes in real time. +languages: + - cpp +products: + - windows +--- + - -Change File System Minifilter Driver -==================================== +# Change File System Minifilter Driver The Change minifilter is a transaction-aware filter that monitors file changes in real time. @@ -17,11 +25,11 @@ This filter tracks if the files are 'dirty' by intercepting write I/O requests. The primary tasks of the filter for tracking a transacted file are the following: -1. In the post create callback, if a transacted file is open with attribute FILE\_WRITE\_DATA or FILE\_APPEND\_DATA, then enlist its file context into the transaction context. -2. In the pre-operation callback, if the operation needs to be dirty, such as IRP\_MJ\_WRITE and the file is part of a transaction, update the transacted dirty record instead of the non-transacted dirty record. -3. In the kernel transaction manager (KTM) notification callback, if the transaction is committed, then propagate the dirty information from the transacted dirty record to the non-transacted dirty record; if rollback, do not propagate. -4. Properly remove the context structure in the TransactionContextCleanup routine. +1. In the post create callback, if a transacted file is open with attribute FILE\_WRITE\_DATA or FILE\_APPEND\_DATA, then enlist its file context into the transaction context. +1. In the pre-operation callback, if the operation needs to be dirty, such as IRP\_MJ\_WRITE and the file is part of a transaction, update the transacted dirty record instead of the non-transacted dirty record. +1. In the kernel transaction manager (KTM) notification callback, if the transaction is committed, then propagate the dirty information from the transacted dirty record to the non-transacted dirty record; if rollback, do not propagate. +1. Properly remove the context structure in the TransactionContextCleanup routine. ## Universal Windows Driver Compliant -This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. +This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. diff --git a/filesys/miniFilter/change/filesys-minifilter-change.yml b/filesys/miniFilter/change/filesys-minifilter-change.yml deleted file mode 100644 index 5096faf3..00000000 --- a/filesys/miniFilter/change/filesys-minifilter-change.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Change File System Minifilter Driver - description: A transaction-aware filter that monitors file changes in real time. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /filesys/miniFilter/change/change.sln diff --git a/filesys/miniFilter/ctx/README.md b/filesys/miniFilter/ctx/README.md index 326c9221..e01f1e3b 100644 --- a/filesys/miniFilter/ctx/README.md +++ b/filesys/miniFilter/ctx/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Ctx File System Minifilter Driver +description: Demonstrates how to attach contexts to instances, files, streams, and stream handles in your minifilter. +languages: + - cpp +products: + - windows +--- + - -Ctx File System Minifilter Driver -================================= +# Ctx File System Minifilter Drive The Ctx minifilter is an example that demonstrates how to attach contexts to instances, files, streams, and stream handles in your minifilter. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. -Design and Operation --------------------- +## Design and Operation The *Ctx* minifilter demonstrates how to attach and remove contexts from instances, files, steams, and stream handles. *Ctx* attaches a context whenever one of these objects is created. While attaching a context to a file, the sample also creates a stream and stream handle context. All contexts are ultimately deleted by the filter manager using the callback function that the *Ctx* minifilter provides. diff --git a/filesys/miniFilter/ctx/filesys-minifilter-ctx.yml b/filesys/miniFilter/ctx/filesys-minifilter-ctx.yml deleted file mode 100644 index 4e81b18f..00000000 --- a/filesys/miniFilter/ctx/filesys-minifilter-ctx.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Ctx File System Minifilter Driver - description: Demonstrates how to attach contexts to instances, files, streams, and stream handles in your minifilter. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /filesys/miniFilter/ctx/ctx.sln diff --git a/filesys/miniFilter/delete/README.md b/filesys/miniFilter/delete/README.md index b56eded0..70ebf09f 100644 --- a/filesys/miniFilter/delete/README.md +++ b/filesys/miniFilter/delete/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Delete File System Minifilter Driver +description: Demonstrates how to detect deletions of files or streams. +languages: + - cpp +products: + - windows +--- + -Delete File System Minifilter Driver -==================================== +# Delete File System Minifilter Driver The Delete minifilter is an example that demonstrates how to detect deletions of files or streams. Deletions are reported as debug output. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. -Design and Operation --------------------- +## Design and Operation The *delete* minifilter illustrates how to detect deletion of files and streams. It monitors IRP\_MJ\_CREATE requests for the FILE\_DELETE\_ON\_CLOSE flag. Also, it detects IRP\_MJ\_SET\_INFORMATION requests for setting FileDispositionInformation/FileDispositionInformationEx. The sample also illustrates how to handle racing deletes (in the form of multiple parallel IRP\_MJ\_SET\_INFORMATION operations), and how to distinguish deletion of an entire file from deletion of just one stream of the file. diff --git a/filesys/miniFilter/delete/filesys-minifilter-delete.yml b/filesys/miniFilter/delete/filesys-minifilter-delete.yml deleted file mode 100644 index a9c31962..00000000 --- a/filesys/miniFilter/delete/filesys-minifilter-delete.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Delete File System Minifilter Driver - description: Demonstrates how to detect deletions of files or streams. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /filesys/miniFilter/delete/delete.sln diff --git a/filesys/miniFilter/minispy/README.md b/filesys/miniFilter/minispy/README.md index 075675b7..e487235b 100644 --- a/filesys/miniFilter/minispy/README.md +++ b/filesys/miniFilter/minispy/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Minispy File System Minifilter Driver +description: A tool to monitor and log any I/O and transaction activity that occurs in the system. +languages: + - cpp +products: + - windows +--- + - -Minispy File System Minifilter Driver -===================================== +# Minispy File System Minifilter Driver The Minispy sample is a tool to monitor and log any I/O and transaction activity that occurs in the system. Minispy is implemented as a minifilter. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. -Design and Operation --------------------- +## Design and Operation Minispy consists of both user-mode and kernel-mode components. The kernel-mode component registers callback functions that correspond to various I/O and transaction operations with the filter manager. These callback functions help Minispy record any I/O and transaction activity occurring in the system. When a user can request the recorded information, the recorded information is passed to the user-mode component, which can either output it on screen or log it to a file on disk. To observe I/O activity on a device, you must explicitly attach Minispy to that device by using the Minispy user-mode component. Similarly, you can request Minispy to stop logging data for a particular device. For more information on file system minifilter design, start with the [File System Minifilter Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540402) section in the Installable File Systems Design Guide. - diff --git a/filesys/miniFilter/minispy/filesys-minifilter-minispy.yml b/filesys/miniFilter/minispy/filesys-minifilter-minispy.yml deleted file mode 100644 index 783502e2..00000000 --- a/filesys/miniFilter/minispy/filesys-minifilter-minispy.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Minispy File System Minifilter Driver - description: A tool to monitor and log any I/O and transaction activity that occurs in the system. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /filesys/miniFilter/minispy/minispy.sln diff --git a/filesys/miniFilter/nullFilter/README.md b/filesys/miniFilter/nullFilter/README.md index e0c2ff2e..8a2f1a04 100644 --- a/filesys/miniFilter/nullFilter/README.md +++ b/filesys/miniFilter/nullFilter/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: NullFilter File System Minifilter Driver +description: A minifilter that demonstrates registration with the filter manager. +languages: + - cpp +products: + - windows +--- + -NullFilter File System Minifilter Driver -======================================== +# NullFilter File System Minifilter Driver The NullFilter minifilter is a sample minifilter that shows how to register a minifilter with the filter manager. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. -Design and Operation --------------------- +## Design and Operation The *NullFilter* minifilter is a simple minifilter that registers itself with the filter manager for no callback operations. For more information on file system minifilter design, start with the [File System Minifilter Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540402) section in the Installable File Systems Design Guide. - diff --git a/filesys/miniFilter/nullFilter/filesys-minifilter-nullfilter.yml b/filesys/miniFilter/nullFilter/filesys-minifilter-nullfilter.yml deleted file mode 100644 index 2d9b6729..00000000 --- a/filesys/miniFilter/nullFilter/filesys-minifilter-nullfilter.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: NullFilter File System Minifilter Driver - description: A minifilter that demonstrates registration with the filter manager. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /filesys/miniFilter/nullFilter/nullFilter.sln diff --git a/filesys/miniFilter/passThrough/README.md b/filesys/miniFilter/passThrough/README.md index 7400c146..f7f2a520 100644 --- a/filesys/miniFilter/passThrough/README.md +++ b/filesys/miniFilter/passThrough/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: PassThrough File System Minifilter Driver +description: Demonstrates how to specify callback functions for different types of I/O requests. +languages: + - cpp +products: + - windows +--- + - -PassThrough File System Minifilter Driver -========================================= +# PassThrough File System Minifilter Driver The PassThrough minifilter demonstrates how to specify callback functions for different types of I/O requests. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. -Design and Operation --------------------- +## Design and Operation The *PassThrough* minifilter does not have any real functionality. For each type of I/O operation, the same pre and post callback functions are called. These callback functions simply forward the I/O request to the next filter on the stack. For more information on file system minifilter design, start with the [File System Minifilter Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540402) section in the Installable File Systems Design Guide. - diff --git a/filesys/miniFilter/passThrough/filesys-minifilter-passthrough.yml b/filesys/miniFilter/passThrough/filesys-minifilter-passthrough.yml deleted file mode 100644 index b42596b2..00000000 --- a/filesys/miniFilter/passThrough/filesys-minifilter-passthrough.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: PassThrough File System Minifilter Driver - description: Demonstrates how to specify callback functions for different types of I/O requests. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /filesys/miniFilter/passThrough/passThrough.sln diff --git a/filesys/miniFilter/scanner/README.md b/filesys/miniFilter/scanner/README.md index eb9d2bcd..fa2559e2 100644 --- a/filesys/miniFilter/scanner/README.md +++ b/filesys/miniFilter/scanner/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Scanner File System Minifilter Driver +description: A file data scanner example. Typically, anti-virus filters are of this type. +languages: + - cpp +products: + - windows +--- + - -Scanner File System Minifilter Driver -===================================== +# Scanner File System Minifilter Driver The Scanner minifilter is an example for developers who intend to write filters that examine data in files. Typically, antivirus products fall into this category. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. -Design and Operation --------------------- +## Design and Operation The Scanner minifilter comprises both kernel-mode and user-mode components. The kernel-mode component recognizes appropriate moments for scanning a file's data and passes it to the user-mode component for further validation. The user-mode component creates a number of threads that await validation requests and corresponding data from the kernel-mode component. After scanning the data for occurrences of a "foul" string, the user-mode component sends an appropriate response to the kernel-mode component. The kernel-mode component scans files with specific extensions only. The file is first scanned on a successful open. If the file was opened with write access, it is scanned again before a close. Scanning is also performed on data that is about to be written to a file. Writes will be rejected if any occurrences of a "foul" string are found in the data. If a "foul" string is detected during the closing of a file, a debug message is printed. For more information on file system minifilter design, start with the [File System Minifilter Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540402) section in the Installable File Systems Design Guide. - diff --git a/filesys/miniFilter/scanner/filesys-minifilter-scanner.yml b/filesys/miniFilter/scanner/filesys-minifilter-scanner.yml deleted file mode 100644 index 85be9e86..00000000 --- a/filesys/miniFilter/scanner/filesys-minifilter-scanner.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Scanner File System Minifilter Driver - description: A file data scanner example. Typically, anti-virus filters are of this type. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /filesys/miniFilter/scanner/scanner.sln diff --git a/filesys/miniFilter/simrep/README.md b/filesys/miniFilter/simrep/README.md index df02b1f5..60f16a60 100644 --- a/filesys/miniFilter/simrep/README.md +++ b/filesys/miniFilter/simrep/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: SimRep File System Minifilter Driver +description: Demonstrates how a file system filter can simulate file-system like reparse-point behavior to redirect a file open to an alternate path. +languages: + - cpp +products: + - windows +--- + - -SimRep File System Minifilter Driver -==================================== +# SimRep File System Minifilter Driver SimRep is a sample filter that demonstrates how a file system filter can simulate file-system like reparse-point behavior to redirect a file open to an alternate path. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. -Design and Operation --------------------- +## Design and Operation Normally, if the file-system sees an open for a file with a reparse-point on it, the filesystem fills out the tag buffer and returns STATUS\_REPARSE. Minifilters see the post-operation callback for this create. As the create travels up file system filter stack in post-create path, each minifilter has the opportunity to interpret the reparse point if they own the tag. If no file system filter claims the tag, IO Manager will attempt to interpret the tag based on tags known to and serviced by IO Manager. If the tag is unknown to IO manager then the create is failed with STATUS\_IO\_REPARSE\_TAG\_NOT\_HANDLED. SimRep does not demonstrate how to handle the case where the file system hits a reparse-point on the file. Instead it "fakes" encountering a reparse point before the create reaches the filesystem. When SimRep detects a create for a path that it is redirecting, SimRep replaces the file name in the file object and completes the open with STATUS\_REPARSE. This means we reparse without actually going to the file system. @@ -26,4 +34,3 @@ SimRep decides to reparse according to a mapping. The mapping is made up of a "N It is important to note that SimRep does not take long and short names into account. It literally does a string comparison to detect overlap with the mapping paths. SimRep also handles IRP\_MJ\_NETWORK\_QUERY\_OPEN. Because network query opens are FastIo operations, they cannot be reparsed. This means network query opens which need to be redirected must be failed with FLT\_PREOP\_DISALLOW\_FASTIO. This will cause the Io Manager to reissue the open as a regular IRP based open. To prevent performance regression, SimRep only fails network query opens which need to be reparsed. For more information on file system minifilter design, start with the [File System Minifilter Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540402) section in the Installable File Systems Design Guide. - diff --git a/filesys/miniFilter/simrep/filesys-minifilter-simrep.yml b/filesys/miniFilter/simrep/filesys-minifilter-simrep.yml deleted file mode 100644 index c5d82551..00000000 --- a/filesys/miniFilter/simrep/filesys-minifilter-simrep.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: SimRep File System Minifilter Driver - description: Demonstrates how a file system filter can simulate file-system like reparse-point behavior to redirect a file open to an alternate path. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /filesys/miniFilter/simrep/simrep.sln diff --git a/filesys/miniFilter/swapBuffers/README.md b/filesys/miniFilter/swapBuffers/README.md index f2c48181..b94292e8 100644 --- a/filesys/miniFilter/swapBuffers/README.md +++ b/filesys/miniFilter/swapBuffers/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: SwapBuffer File System Minifilter Driver +description: Demonstrates how to switch buffers between reads and writes of data. This technique is particularly useful for encryption filters. +languages: + - cpp +products: + - windows +--- + - -SwapBuffer File System Minifilter Driver -======================================== +# SwapBuffer File System Minifilter Driver The SwapBuffers minifilter demonstrates how to switch buffers between reads and writes of data. This technique is particularly useful for encryption filters because they have to encrypt data before writing it to disk and decrypt it after reading it from disk. Because encryption/decryption has to be done transparently, you cannot use system-supplied buffers directly, so intermediate buffers have to be introduced. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. -Design and Operation --------------------- +## Design and Operation The *SwapBuffers* minifilter introduces a new buffer before a read/write or directory control operations. The corresponding operation is then performed on the new buffer instead of the buffer that was originally provided. After the operation completes, the contents of the new buffer are copied back in to the original buffer. For more information on file system minifilter design, start with the [File System Minifilter Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540402) section in the Installable File Systems Design Guide. - diff --git a/filesys/miniFilter/swapBuffers/filesys-minifilter-swapbuffers.yml b/filesys/miniFilter/swapBuffers/filesys-minifilter-swapbuffers.yml deleted file mode 100644 index 0f206567..00000000 --- a/filesys/miniFilter/swapBuffers/filesys-minifilter-swapbuffers.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: SwapBuffer File System Minifilter Driver - description: Demonstrates how to switch buffers between reads and writes of data. This technique is particularly useful for encryption filters. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /filesys/miniFilter/swapBuffers/swapBuffers.sln diff --git a/general/DCHU/README.md b/general/DCHU/README.md index bf74d451..e9214f8b 100644 --- a/general/DCHU/README.md +++ b/general/DCHU/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: DHCU - Driver package installation toolkit for universal drivers +description: Illustrates DCHU principles of universal driver design. +languages: + - cpp +products: + - windows +--- + - # Driver package installation toolkit for universal drivers This sample illustrates the DCHU principles of universal driver design. The sample uses the [OSR FX2 learning kit](http://store.osr.com/product/osr-usb-fx2-learning-kit-v2/). For a detailed code walkthrough, see [Universal Driver Scenarios](https://docs.microsoft.com/windows-hardware/drivers/develop/universal-driver-scenarios). There are three Visual Studio solutions in this sample. Each one represents a single submission on the [Windows Hardware Dev Center dashboard](https://developer.microsoft.com/windows/hardware/dashboard-sign-in). The solutions are split into the following subdirectories: -* `osrfx2_DCHU_base` : The driver for the OSR FX2 Learning Kit. This includes the device driver, an upper filter driver for the device (a no-op), a Win32 User Service that controls lights on the device, and a console app that can control the device. +* `osrfx2_DCHU_base` : The driver for the OSR FX2 Learning Kit. This includes the device driver, an upper filter driver for the device (a no-op), a Win32 User Service that controls lights on the device, and a console app that can control the device. -* `osrfx2_DCHU_extension_loose`: An extension INF for the OSR FX2 device. This extension modifies some registry settings originally specified by the base driver (`osrfx2_DCHU_base`) and also uses AddComponent to create a Software Component. There is also a component INF project that would be a separate submission to DevCenter, which runs some simple software. These two projects are loosely coupled, and can be installed in any order on the machine. +* `osrfx2_DCHU_extension_loose`: An extension INF for the OSR FX2 device. This extension modifies some registry settings originally specified by the base driver (`osrfx2_DCHU_base`) and also uses AddComponent to create a Software Component. There is also a component INF project that would be a separate submission to DevCenter, which runs some simple software. These two projects are loosely coupled, and can be installed in any order on the machine. -* `osrfx2_DCHU_extension_tight`: An extension INF for the OSR FX2 device. This extension mimics the behavior of `osrfx2_DCHU_extension_loose`; however, it does so in a tightly coupled manner. Using CopyINF, both the extension and component INF are placed into one driver package (and one submission to DevCenter). Here there is less flexibility with the base/component/extension relationship, but it ensures that the component INF is applied at the same time as the extension. +* `osrfx2_DCHU_extension_tight`: An extension INF for the OSR FX2 device. This extension mimics the behavior of `osrfx2_DCHU_extension_loose`; however, it does so in a tightly coupled manner. Using CopyINF, both the extension and component INF are placed into one driver package (and one submission to DevCenter). Here there is less flexibility with the base/component/extension relationship, but it ensures that the component INF is applied at the same time as the extension. Both `osrfx2_DCHU_extension_loose` and `osrfx2_DCHU_extension_tight` provide the same functionality, so installing both on the same OSR FX2 device is unnecessary. They are intended to show a different way to use extension and component INF's depending on a project's needs. @@ -33,9 +42,8 @@ To install these driver packages, make sure that the target machine is in Test M Then, use `pnputil /i /a ` to install each of the desired driver packages. They should be installed in the following order: -* `osrfx2_DCHU_base` -* `osrfx2_DCHU_extension` -* `osrfx2_DCHU_component` +* `osrfx2_DCHU_base` +* `osrfx2_DCHU_extension` +* `osrfx2_DCHU_component` Technically the order of `osrfx2_DCHU_extension` and `osrfx2_DCHU_component` doesn't matter, but the software within `osrfx2_DCHU_component` will read the registry set by the extension to show that an extension INF's settings are applied *after* the base INF's. - diff --git a/general/DCHU/general-dchu.yml b/general/DCHU/general-dchu.yml deleted file mode 100644 index 2276cd93..00000000 --- a/general/DCHU/general-dchu.yml +++ /dev/null @@ -1,11 +0,0 @@ -### YamlMime:Sample -sample: -- name: DHCU - Driver package installation toolkit for universal drivers - description: Illustrates DCHU principles of universal driver design. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows diff --git a/general/PLX9x5x/README.md b/general/PLX9x5x/README.md index e665839b..090f4ab7 100644 --- a/general/PLX9x5x/README.md +++ b/general/PLX9x5x/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: PLX9x5x PCI Driver +description: Demonstrates how to write a driver for a generic PCI device using Windows Driver Frameworks (WDF). +languages: + - cpp +products: + - windows +--- + - -PLX9x5x PCI Driver -================== +# PLX9x5x PCI Driver This sample demonstrates how to write driver for a generic PCI device using Windows Driver Framework. The target hardware for this driver is PLX9656/9653RDK-LITE board. The product kit and the hardware specification are available at . @@ -17,17 +25,14 @@ For more information, see [Peripheral Component Interconnect (PCI) Bus Drivers]( The device is a PCI device with port, memory, interrupt and DMA resources. Device can be stopped and started at run-time and also supports low power states. The driver is capable of doing concurrent read and write operations to the device but it can handle only one read or write request at any time. The following lists the driver framework interfaces demonstrated in this sample: -- Handling PnP & Power Events -- Registering a Device Interface -- Hardware resource mapping: Port, Memory & Interrupt -- DMA Interfaces -- Serialized Default Queue for Write requests -- Serialized custom Queue for Read requests -- Handling Interrupt & DPC +- Handling PnP & Power Events +- Registering a Device Interface +- Hardware resource mapping: Port, Memory & Interrupt +- DMA Interfaces +- Serialized Default Queue for Write requests +- Serialized custom Queue for Read requests +- Handling Interrupt & DPC To test the driver, run the PLX.EXE test application. This sample driver is a minimal driver meant to demonstrate the usage of the Windows Driver Framework. It is not intended for use in a production environment. - - - diff --git a/general/PLX9x5x/general-plx9x5x.yml b/general/PLX9x5x/general-plx9x5x.yml deleted file mode 100644 index 6deebe96..00000000 --- a/general/PLX9x5x/general-plx9x5x.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: PLX9x5x PCI Driver - description: Demonstrates how to write a driver for a generic PCI device using Windows Driver Frameworks (WDF). - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/PLX9x5x/PLX9x5x.sln diff --git a/general/SystemDma/wdm/README.md b/general/SystemDma/wdm/README.md index ad7d9dbc..979f0ab4 100644 --- a/general/SystemDma/wdm/README.md +++ b/general/SystemDma/wdm/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: System DMA sample +description: Demonstrates how a driver could use a system DMA controller to write data to a hardware location using V3 System DMA. +languages: + - cpp +products: + - windows +--- + - -System DMA -========== +# System DMA 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. @@ -17,8 +25,6 @@ The sample consists of a legacy device driver and a Win32 console mode test appl **Note** 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. -Run the sample --------------- +## Run the sample 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. - diff --git a/general/SystemDma/wdm/general-systemdma-wdm.yml b/general/SystemDma/wdm/general-systemdma-wdm.yml deleted file mode 100644 index aed5b8f2..00000000 --- a/general/SystemDma/wdm/general-systemdma-wdm.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: System DMA sample - description: Demonstrates how a driver could use a system DMA controller to write data to a hardware location using V3 System DMA. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/SystemDma/wdm/SystemDma.sln diff --git a/general/WinHEC 2017 Lab/README.md b/general/WinHEC 2017 Lab/README.md index 7214c3fc..87cc729f 100644 --- a/general/WinHEC 2017 Lab/README.md +++ b/general/WinHEC 2017 Lab/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: WinHEC 2017 Lab +description: WinHEC 2017 Lab +languages: + - cpp +products: + - windows +--- + - -Cancel-Safe IRP Queue Sample -============================ +# Cancel-Safe IRP Queue Sample This sample demonstrates the use of the cancel-safe queue routines [**IoCsqInitialize**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549054), [**IoCsqInsertIrp**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549066), [**IoCsqRemoveIrp**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549070), [**IoCsqRemoveNextIrp**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549072). These routines were introduced in Windows for queuing IRPs in the driver's internal device queue. By using these routines, driver developers do not have to worry about IRP cancellation race conditions. A common problem with cancellation of IRPs in a driver is synchronization between the cancel lock or the InterlockedExchange in the I/O Manager with the driver's queue lock. The **IoCsq*Xxx*** routines abstract the cancel logic while allowing the driver to implement the queue and associated synchronization. @@ -23,13 +31,10 @@ Look in the Startio directory for another version of the sample driver that show For more information, see [Cancel-Safe IRP Queues](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540755). - -Run the sample --------------- +## Run the sample To test this driver, run Testapp.exe, which is a simple Win32 multithreaded console application. The driver will automatically load and start. When you exit the application, the driver will stop and be removed. `Usage: testapp ` **Note** The `NumberOfThreads` command-line parameter is limited to a maximum of 10 threads; the default value if no parameter is specified is 1. The main thread waits for user input. If you press Q, the application exits gracefully; otherwise, it exits the process abruptly and forces all the threads to be terminated and all pending I/O operations to be canceled. Other threads perform I/O asynchronously in a loop. After every overlapped read, the thread goes into an alertable sleep and wakes as soon as the completion routine runs, which occurs when the driver completes the read IRP. You should run multiple instances of the application to stress test the driver. - diff --git a/general/cancel/general-cancel.yml b/general/cancel/general-cancel.yml deleted file mode 100644 index 7c38e259..00000000 --- a/general/cancel/general-cancel.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Cancel-Safe IRP Queue Sample - description: Demonstrates the use of the cancel-safe queue routines. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/cancel/cancel.sln diff --git a/general/echo/kmdf/README.md b/general/echo/kmdf/README.md index 2ed4518a..0ac0596f 100644 --- a/general/echo/kmdf/README.md +++ b/general/echo/kmdf/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: KMDF Echo Sample +description: Demonstrates how to use a sequential queue to serialize read and write requests presented to the driver. +languages: + - cpp +products: + - windows +--- + - -KMDF Echo Sample -================ +# KMDF Echo Sample The ECHO (KMDF) sample demonstrates how to use a sequential queue to serialize read and write requests presented to the driver. It also shows how to synchronize execution of these events with other asynchronous events such as request cancellation and DPC. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. -Related technologies --------------------- +## Related technologies [Kernel-Mode Driver Framework](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544396) -Code Tour ---------- +## Code Tour DriverEntry - Creates a framework driver object. @@ -40,8 +47,7 @@ EvtIoRead: Retrieves request memory buffer and copies the data from the buffer c Since the queue is a sequential queue, only one request is outstanding in the driver. -Testing -------- +## Testing **Usage:** @@ -51,8 +57,7 @@ Echoapp.exe -Async --- Send 100 reads and writes asynchronously Exit the app anytime by pressing Ctrl-C -File Manifest -------------- +## File Manifest File @@ -91,4 +96,3 @@ This file merely redirects to the real makefile that is shared by all the driver Sources Generic file that lists source files and all the build options. - diff --git a/general/echo/kmdf/general-echo-kmdf.yml b/general/echo/kmdf/general-echo-kmdf.yml deleted file mode 100644 index bc1d383b..00000000 --- a/general/echo/kmdf/general-echo-kmdf.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: KMDF Echo Sample - description: Demonstrates how to use a sequential queue to serialize read and write requests presented to the driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/echo/kmdf/kmdfecho.sln diff --git a/general/echo/umdf/README.md b/general/echo/umdf/README.md index af4818d4..7be15c05 100644 --- a/general/echo/umdf/README.md +++ b/general/echo/umdf/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Echo Sample (UMDF Version 1) +description: Demonstrates how to use UMDF version 1 to write a driver and demonstrates best practices. +languages: + - cpp +products: + - windows +--- + - -Echo Sample (UMDF Version 1) -============================ +# Echo Sample (UMDF Version 1) This sample demonstrates how to use User-Mode Driver Framework (UMDF) version 1 to write a driver and demonstrates best practices. @@ -17,7 +25,6 @@ It also demonstrates the use of a default Serial Dispatch I/O Queue, its request This sample driver is a minimal driver meant to demonstrate the usage of the User-Mode Driver Framework. It is not intended for use in a production environment. - Related technologies -------------------- @@ -30,7 +37,7 @@ To test the Echo driver, you can run echoapp.exe which is built from \\echo\\exe First install the device as described above. Then run echoapp.exe. -``` +```cmd D:\>echoapp /? Usage: Echoapp.exe --- Send single write and read request synchronously @@ -124,4 +131,3 @@ File Manifest - This file lists the WPP trace control GUID(s) for the sample driver. This file can be used with the tracelog command's -guid flag to enable the collection of these trace events within an established trace session. - These GUIDs must remain in sync with the trace control GUIDs defined in internal.h. - diff --git a/general/echo/umdf/general-echo-umdf.yml b/general/echo/umdf/general-echo-umdf.yml deleted file mode 100644 index 9a9b9f23..00000000 --- a/general/echo/umdf/general-echo-umdf.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Echo Sample (UMDF Version 1) - description: Demonstrates how to use UMDF version 1 to write a driver and demonstrates best practices. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/echo/umdf/echo.sln diff --git a/general/echo/umdf2/README.md b/general/echo/umdf2/README.md index a9ec9e76..30bbd454 100644 --- a/general/echo/umdf2/README.md +++ b/general/echo/umdf2/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Echo Sample (UMDF Version 2) +description: Demonstrates how to use UMDF 2 to write a driver and to employ best practices. +languages: + - cpp +products: + - windows +--- + -Echo Sample (UMDF Version 2) -============================ +# Echo Sample (UMDF Version 2) The ECHO (UMDF version 2) sample demonstrates how to use a sequential queue to serialize read and write requests presented to the driver. It also shows how to synchronize execution of these events with other asynchronous events such as request cancellation and DPC. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. Related technologies @@ -22,7 +32,6 @@ Related technologies [User-Mode Driver Framework](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560456) - Open the driver solution in Visual Studio ----------------------------------------- @@ -31,13 +40,12 @@ In Microsoft Visual Studio, open the solution file (umdf2echo.sln). Choose **Sol Set the configuration and platform in Visual Studio --------------------------------------------------- -In Visual Studio, in Solution Explorer, right click **Solution**, and choose **Configuration Manager**. Set the configuration and the platform. Make sure that the configuration and platform are the same for both the driver project and the package project. Do not check the **Deploy** boxes. - +In Visual Studio, in Solution Explorer, right click **Solution**, and choose **Configuration Manager**. Set the configuration and the platform. Make sure that the configuration and platform are the same for both the driver project and the package project. Do not check the **Deploy** boxes. Locate the built driver package ------------------------------- -In File Explorer, navigate to the folder that contains your built driver package. The location of this folder varies depending on what you set for configuration and platform. +In File Explorer, navigate to the folder that contains your built driver package. The location of this folder varies depending on what you set for configuration and platform. Run the sample -------------- @@ -50,16 +58,16 @@ The process of moving the driver package to the target computer and installing t Before you automatically deploy a driver, you must provision the target computer. For instructions, see [Configuring a Computer for Driver Deployment, Testing, and Debugging](http://msdn.microsoft.com/en-us/library/windows/hardware/). -1. On the host computer, in Visual Studio, in Solution Explorer, right click **package** (lower case), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**. -2. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, select the name of a target computer that you provisioned previously. Select **Hardware ID Driver Update**, and enter **root\\ECHO** for the hardware ID. Click **OK**. -3. On the **Build** menu, choose **Build Solution**. +1. On the host computer, in Visual Studio, in Solution Explorer, right click **package** (lower case), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**. +1. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, select the name of a target computer that you provisioned previously. Select **Hardware ID Driver Update**, and enter **root\\ECHO** for the hardware ID. Click **OK**. +1. On the **Build** menu, choose **Build Solution**. ### Manual deployment (root enumerated) Before you manually deploy a driver, you must turn on test signing and install a certificate on the target computer. You also need to copy the [DevCon](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544707) tool to the target computer. For instructions, see [Preparing a Computer for Manual Driver Deployment](http://msdn.microsoft.com/en-us/library/windows/hardware/dn265571). -1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\umdf2echoPkg). -2. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter the following command: +1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\umdf2echoPkg). +1. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter the following command: **devcon install echoum.inf root\\ECHO** @@ -77,4 +85,3 @@ As an alternative to building the driver sample in Visual Studio, you can build **msbuild /p:configuration="Release" /p:platform="Win32" umdf2echo.sln** For more information about using MSBuild to build a driver package, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644). - diff --git a/general/echo/umdf2/general-echo-umdf2.yml b/general/echo/umdf2/general-echo-umdf2.yml deleted file mode 100644 index 62d719f3..00000000 --- a/general/echo/umdf2/general-echo-umdf2.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Echo Sample (UMDF Version 2) - description: Demonstrates how to use UMDF 2 to write a driver and to employ best practices. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/echo/umdf2/umdf2echo.sln diff --git a/general/echo/umdfSocketEcho/README.md b/general/echo/umdfSocketEcho/README.md index 26cd5a7e..ea01b037 100644 --- a/general/echo/umdfSocketEcho/README.md +++ b/general/echo/umdfSocketEcho/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: UMDF SocketEcho Sample (UMDF Version 1) +description: Demonstrates how to use UMDF version 1 to write a driver and demonstrates best practices. +languages: + - cpp +products: + - windows +--- + - -UMDF SocketEcho Sample (UMDF Version 1) -======================================= +# UMDF SocketEcho Sample (UMDF Version 1) The UMDF SocketEcho sample demonstrates how to use the User-Mode Driver Framework (UMDF) to write a driver and demonstrates best practices. @@ -38,13 +46,13 @@ To test this sample, you must have a test computer. This test computer can be a To install the UMDF Echo sample driver from the command line, do the following: -1. Copy the driver binary and the socketecho.inf file to a directory on your test computer (for example, C:\\ socketechoSample.) +1. Copy the driver binary and the socketecho.inf file to a directory on your test computer (for example, C:\\ socketechoSample.) -2. Copy the UMDF coinstaller, WUDFUpdate\_*MMmmmm*.dll, from the \\redist\\wdf\\\ directory to the same directory (for example, C:\\socketechoSample). +1. Copy the UMDF coinstaller, WUDFUpdate\_*MMmmmm*.dll, from the \\redist\\wdf\\\ directory to the same directory (for example, C:\\socketechoSample). **Note** You can obtain redistributable framework updates by downloading the *wdfcoinstaller.msi* package from [WDK 8 Redistributable Components](http://go.microsoft.com/fwlink/p/?LinkID=226396). This package performs a silent install into the directory of your Windows Driver Kit (WDK) installation. You will see no confirmation that the installation has completed. You can verify that the redistributables have been installed on top of the WDK by ensuring there is a redist\\wdf directory under the root directory of the WDK, %ProgramFiles(x86)%\\Windows Kits\\8.0. -3. Navigate to the directory that contains the INF file and binaries (for example, cd /d c:\\socketechoSample), and run DevCon.exe as follows: +1. Navigate to the directory that contains the INF file and binaries (for example, cd /d c:\\socketechoSample), and run DevCon.exe as follows: `devcon.exe install socketecho.inf WUDF\\socketecho` @@ -52,21 +60,21 @@ To install the UMDF Echo sample driver from the command line, do the following: To update the socketecho driver after you make any changes, do the following: -1. Increment the version number in the INF file. This change is not necessary, but it will help ensure that Plug and Play (PnP) selects your new driver as a better match for the device. +1. Increment the version number in the INF file. This change is not necessary, but it will help ensure that Plug and Play (PnP) selects your new driver as a better match for the device. -2. Copy the updated driver binary and the socketecho.inf file to a directory on your test computer (for example, C:\\ socketechoSample.) +1. Copy the updated driver binary and the socketecho.inf file to a directory on your test computer (for example, C:\\ socketechoSample.) -3. Navigate to the directory that contains the INF file and binaries (for example, cd /d c:\\ socketechoSample), and run devcon.exe as follows: +1. Navigate to the directory that contains the INF file and binaries (for example, cd /d c:\\ socketechoSample), and run devcon.exe as follows: `devcon.exe update socketecho.inf WUDF\\socketecho` To test this sample drivers on a checked operating system that you have installed (in contrast to the standard retail installations), you must modify the INF file to use the checked version of the UMDF co-installer. That is, you must do the following: -1. In the INX file, replace all occurrences of WudfUpdate\_*MMmmmm*.dll with WudfUpdate\_*MMmmmm*\_chk.dll. +1. In the INX file, replace all occurrences of WudfUpdate\_*MMmmmm*.dll with WudfUpdate\_*MMmmmm*\_chk.dll. -2. Copy the WudfUpdate\_*MMmmmm*\_chk.dll file from the \\redist\\wdf\\\ directory to your driver package instead of WudfUpdate\_*MMmmmm*.dll. +1. Copy the WudfUpdate\_*MMmmmm*\_chk.dll file from the \\redist\\wdf\\\ directory to your driver package instead of WudfUpdate\_*MMmmmm*.dll. -3. If WdfCoinstaller*MMmmmm*.dll or WinUsbCoinstaller.dll is included in your driver package, repeat step 1 and step 2 for them. +1. If WdfCoinstaller*MMmmmm*.dll or WinUsbCoinstaller.dll is included in your driver package, repeat step 1 and step 2 for them. Testing ------- @@ -79,7 +87,8 @@ First, you must install the device as described earlier. Then, run socketechoser Usage ------ -``` + +```cmd socketechoserver Display Usage socketechoserver -h Display Usage @@ -167,5 +176,3 @@ File Manifest ------------- **Dllsup.cpp**: The DLL support code that provides the DLL's entry point and the single required export (DllGetClassObject). - - diff --git a/general/echo/umdfSocketEcho/general-echo-umdfsocketecho.yml b/general/echo/umdfSocketEcho/general-echo-umdfsocketecho.yml deleted file mode 100644 index 06962f42..00000000 --- a/general/echo/umdfSocketEcho/general-echo-umdfsocketecho.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: UMDF SocketEcho Sample (UMDF Version 1) - description: Demonstrates how to use UMDF version 1 to write a driver and demonstrates best practices. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/echo/umdfSocketEcho/umdfsocketecho.sln diff --git a/general/event/README.md b/general/event/README.md index 68da1666..1033d3d2 100644 --- a/general/event/README.md +++ b/general/event/README.md @@ -1,4 +1,14 @@ - - -Hardware Event Sample -===================== +# Hardware Event Sample This sample demonstrates two different ways a Windows kernel-mode driver can notify an application about a hardware event. One way uses an event-based method, and the other uses an IRP-based method. Because 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. Additionally, the test application specifies a relative time at which the DPC timer must fire. @@ -21,9 +29,7 @@ There are two advantages of IRP-based approach over the event-based approach. Fi **Note** This sample driver is not a Plug and Play driver. This is a minimal driver meant to demonstrate a feature of the operating system. Neither this driver nor its sample programs are intended for use in a production environment. Rather, they are intended for educational purposes and as a skeleton driver. - -Run the sample --------------- +## Run the sample To test this driver, copy the test application, 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. @@ -32,4 +38,3 @@ To run the test application, enter the following command in the command window: `C:\>event.exe <0|1>` The first command-line parameter, `Delay`, equals the time, in seconds, to delay the event signal. For the second command-line parameter, specify 0 for IRP-based notification and 1 for event-based notification. - diff --git a/general/event/general-event.yml b/general/event/general-event.yml deleted file mode 100644 index 35ff1a45..00000000 --- a/general/event/general-event.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Hardware Event Sample - description: Demonstrates different ways a kernel-mode driver can notify an application about a hardware event. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/event/eventsample.sln diff --git a/general/filehistory/README.md b/general/filehistory/README.md index 7ed723d8..a169e322 100644 --- a/general/filehistory/README.md +++ b/general/filehistory/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: File History Sample +description: A console application that starts the file history service, if it is stopped, and schedules regular backups. +languages: + - cpp +products: + - windows +--- + - -File History Sample -================== +# File History Sample The FileHistory sample is a console application that starts the file history service, if it is stopped, and schedules regular backups. The application requires, as a command-line parameter, the path name of a storage device to use as the default backup target. This sample application uses the [File History API](http://msdn.microsoft.com/en-us/library/windows/hardware/hh829789). The File History API enables third parties to automatically configure the File History feature on a Windows platform and customize it in accordance with their unique needs. - -Run the sample --------------- +## Run the sample The name of the built sample application is Fhsetup.exe. To run this application, open a command window and enter a command that has the following format: @@ -30,4 +36,3 @@ The `path` command-line parameter is the path name of a storage device to use as `fhsetup \\server\share` If the specified target is inaccessible, read-only, an invalid drive type (such as a CD), already being used for file history, or part of the protected namespace, the application fails the request and does not enable file history on the target. - diff --git a/general/filehistory/general-filehistory.yml b/general/filehistory/general-filehistory.yml deleted file mode 100644 index 3a2327fa..00000000 --- a/general/filehistory/general-filehistory.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: File History Sample - description: A console application that starts the file history service, if it is stopped, and schedules regular backups. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/filehistory/filehistory.sln diff --git a/general/ioctl/kmdf/README.md b/general/ioctl/kmdf/README.md index 9c3d80d4..bbc0be9f 100644 --- a/general/ioctl/kmdf/README.md +++ b/general/ioctl/kmdf/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Non-PnP Driver Sample +description: Demonstrates how to write a non-PnP driver using the Kernel Mode Driver Framework. +languages: + - cpp +products: + - windows +--- + - -Non-PnP Driver Sample -==================== +# Non-PnP Driver Sample This sample is primarily meant to demonstrate how to write a NON-PNP driver using the Kernel Mode Driver Framework. @@ -19,25 +27,23 @@ This sample would be useful for writing a driver that does not interact with any (Examples: FileMon, Regmon, DeviceTree are examples of tools that use this type of driver.) -- How to Write a NON PNP driver +- How to Write a NON PNP driver -- How to register EvtPreProcessCallback to handle requests in the context of the calling thread +- How to register EvtPreProcessCallback to handle requests in the context of the calling thread -- Show how to probe and lock buffers in the preprocess callback for METHOD\_NEITHER IOCTL requests +- Show how to probe and lock buffers in the preprocess callback for METHOD\_NEITHER IOCTL requests -- Also show how to handle other 3 types of IOCTLs (METHOD\_BUFFERED, METHOD\_IN\_DIRECT & METHOD\_OUT\_DIRECT) +- Also show how to handle other 3 types of IOCTLs (METHOD\_BUFFERED, METHOD\_IN\_DIRECT & METHOD\_OUT\_DIRECT) -- How to open a file in Kernel-mode and Read & Write to it +- How to open a file in Kernel-mode and Read & Write to it -- Finally show event tracing and dumping variable length data in the tracelog using HEXDUMP format. +- Finally show event tracing and dumping variable length data in the tracelog using HEXDUMP format. The sample is accompanied by a simple multithreaded Win32 console application to test the driver. *Disclaimer*: 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. - -Build the sample ----------------- +## Build the sample For information on how to build a driver solution using Microsoft Visual Studio, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644). @@ -70,4 +76,3 @@ KmdfService = \, \ For example, for V1.0 KmdfLibraryVersion is "1.0" - diff --git a/general/ioctl/kmdf/general-ioctl-kmdf.yml b/general/ioctl/kmdf/general-ioctl-kmdf.yml deleted file mode 100644 index 8a4f4251..00000000 --- a/general/ioctl/kmdf/general-ioctl-kmdf.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Non-PnP Driver Sample - description: Demonstrates how to write a non-PnP driver using the Kernel Mode Driver Framework. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/ioctl/kmdf/ioctl.sln diff --git a/general/ioctl/wdm/README.md b/general/ioctl/wdm/README.md index e9e2e57d..5b3831e9 100644 --- a/general/ioctl/wdm/README.md +++ b/general/ioctl/wdm/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: IOCTL +description: Demonstrates usage of four different types of IOCTLs. +languages: + - cpp +products: + - windows +--- + - -IOCTL -===== +# IOCTL This sample demonstrates the usage of four different types of IOCTLs (METHOD\_IN\_DIRECT, METHOD\_OUT\_DIRECT, METHOD\_NEITHER, and METHOD\_BUFFERED). @@ -19,9 +27,6 @@ The sample consists of a legacy device driver and a Win32 console test applicati **Note** This sample driver is not a Plug and Play driver. This is a minimal driver meant to demonstrate a feature of the operating system. Neither this driver nor its sample programs are intended for use in a production environment. Instead, they are intended for educational purposes and as a skeleton driver. - -Run the sample --------------- +# Run the sample 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 application, the driver will be stopped, unloaded and removed. - diff --git a/general/ioctl/wdm/general-ioctl-wdm.yml b/general/ioctl/wdm/general-ioctl-wdm.yml deleted file mode 100644 index f527d17c..00000000 --- a/general/ioctl/wdm/general-ioctl-wdm.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: IOCTL - description: Demonstrates usage of four different types of IOCTLs - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/ioctl/wdm/ioctl.sln diff --git a/general/obcallback/README.md b/general/obcallback/README.md index 37326565..f4ab23fe 100644 --- a/general/obcallback/README.md +++ b/general/obcallback/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: ObCallback Callback Registration Driver +description: Demonstrates the use of registered callbacks for process protection. +languages: + - cpp +products: + - windows +--- + - -ObCallback Callback Registration Driver -======================================= +# ObCallback Callback Registration Driver The ObCallback sample driver demonstrates the use of registered callbacks for process protection. The driver registers control callbacks which are called at process creation. - -Design and Operation --------------------- +## Design and Operation The sample exercises both the [**PsSetCreateProcessNotifyRoutineEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff559951) and the [**ObRegisterCallbacks**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff558692) routines. The first example uses the **ObRegisterCallbacks** routine and a callback to restrict requested access rights during a open process action. The second example uses the **PsSetCreateProcessNotifyRoutineEx** routine to reject a process creation by examining the command line. diff --git a/general/obcallback/general-obcallback.yml b/general/obcallback/general-obcallback.yml deleted file mode 100644 index 67ea5fa1..00000000 --- a/general/obcallback/general-obcallback.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: ObCallback Callback Registration Driver - description: Demonstrates the use of registered callbacks for process protection. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/obcallback/obcallback.sln diff --git a/general/pcidrv/README.md b/general/pcidrv/README.md index 2fa15558..f1ea2b26 100644 --- a/general/pcidrv/README.md +++ b/general/pcidrv/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: PCIDRV - WDF Driver for PCI Device +description: Demonstrates how to write a KMDF driver for a PCI device. +languages: + - cpp +products: + - windows +--- + - -PCIDRV - WDF Driver for PCI Device -================================== +# PCIDRV - WDF Driver for PCI Device This sample demonstrates how to write a KMDF driver for a PCI device. The sample works with the Intel 82557/82558 based PCI Ethernet Adapter (10/100) and Intel compatibles. This adapter supports scatter-gather DMA, wake on external event (Wait-Wake), and idle power down. The hardware specification is publicly available, and the source code to interface with the hardware is included in the WDK. - -Overview --------- +## Overview The following is a list of key KMDF interfaces demonstrated in this sample: -- Handling PnP & Power Events +- Handling PnP & Power Events -- Registering Device Interface +- Registering Device Interface -- Hardware resource mapping: Port, Memory & Interrupt +- Hardware resource mapping: Port, Memory & Interrupt -- DMA Interfaces +- DMA Interfaces -- Parallel default queue for write requests. If the write cannot be satisfied immediately, the request is put into a manual parallel queue. +- Parallel default queue for write requests. If the write cannot be satisfied immediately, the request is put into a manual parallel queue. -- Parallel manual queue for Read requests +- Parallel manual queue for Read requests -- Parallelc default queue for IOCTL requests. If the ioctl cannot be satisfied immediately, the request is put into a manual parallel queue. +- Parallelc default queue for IOCTL requests. If the ioctl cannot be satisfied immediately, the request is put into a manual parallel queue. -- Request cancelation +- Request cancelation -- Handling Interrupt & DPC +- Handling Interrupt & DPC -- Watchdog Timer DPC to monitor the device state. +- Watchdog Timer DPC to monitor the device state. -- Event Tracing & HEXDUMP +- Event Tracing & HEXDUMP -- Reading & Writing to the registry +- Reading & Writing to the registry Note: This sample provides an example of a minimal driver intended for educational purposes. Neither the driver nor its sample test programs are intended for use in a production environment. @@ -65,8 +71,7 @@ Intel(R) PRO/100 VM Network Connection | PCI\VEN_8086&DEV_1031&REV_42 Intel(R) PRO/100 VE Network Connection | PCI\VEN_8086&DEV_1038&REV_41 Intel(R) PRO/100 SR Mobile Adapter | PCI\VEN_8086&DEV_1229 -Using this sample as a standalone driver ----------------------------------------- +## Using this sample as a standalone driver ``` --------------------- @@ -98,8 +103,7 @@ You can install the driver as a standalone driver of a custom setup class, calle The PCIDRV sample acts as a power policy owner of the device and implements all the wait-wake and idle detection logic. -INSTALLATION ------------- +## INSTALLATION The driver can be installed as a Net class driver or as a standalone driver (user defined class). The KMDF versions of the INF files are dynamically generated from .INX file. In addition to the driver files, you have to include the WDF coinstaller DLL from the \\redist\\wdf folder of the WDK. @@ -109,65 +113,60 @@ You can obtain redistributable framework updates by downloading the *wdfcoinstal To test standalone driver configuration: You should use the specially developed ping application, called MYPING that comes with the sample. The Ping.exe provided in the system will not work because in this configuration, the test card is not bound to any network protocol - it's not seen as Net device by the system. Currently the test application doesn't have ability to get an IP address from a network DHCP server. As a result, it is better to connect the network device to a private hub and ping another machine connected to that hub. For example, let us say you have a test machine A and another machine B (development box). -- Connect machine A and Machine B to a local hub. +- Connect machine A and Machine B to a local hub. -- Assign a static IP address, say 128.0.0.1 to the NIC on machine B. +- Assign a static IP address, say 128.0.0.1 to the NIC on machine B. -- Clear the ARP table on machine B by running **Arp -d** on the command line +- Clear the ARP table on machine B by running **Arp -d** on the command line -- Now run Myping.exe. This application enumerates GUID\_DEVINTERFACE\_PCIDRV and displays the name of the devices with an index number. This number will be used in identifying the interface when you invoke ping dialog. +- Now run Myping.exe. This application enumerates GUID\_DEVINTERFACE\_PCIDRV and displays the name of the devices with an index number. This number will be used in identifying the interface when you invoke ping dialog. -- In the ping dialog specify the following and click okay: +- In the ping dialog specify the following and click okay: -- Device Index: 1 \<- number displayed in the list window +- Device Index: 1 \<- number displayed in the list window -- Source Ip Address: 128.0.0.4 \<- You can make up any valid IP address for test Machine A +- Source Ip Address: 128.0.0.4 \<- You can make up any valid IP address for test Machine A -- Destination IP Address: 128.0.0.1 \<- IP address of machine B +- Destination IP Address: 128.0.0.1 \<- IP address of machine B -- Packet Size: 1428 \<- Default max size of ping payload. Minimum value is 32 bytes. +- Packet Size: 1428 \<- Default max size of ping payload. Minimum value is 32 bytes. If the machine B has more than one adapter and if the second adapter is connected to the internet (Corporate Network), instead of assigning static IP address to the adapter that's connected to the test machine, you can install Internet Connection Sharing (ICS) on it and get an IP address for ICS. This would let you use the test machine to browse the internet when the sample is installed in the miniport configuration and also in the standalone mode without making up or stealing somebody's IP address. For example, let us say the machine B has two adapters NIC1 and NIC2. NIC1 is connected to the CorpNet and NIC2 is connected to the private hub. Install ICS on NIC2 as described below: -- Select the NIC2 in the Network Connections Applet. +- Select the NIC2 in the Network Connections Applet. -- Click the **Properties** button. +- Click the **Properties** button. -- Go to the Advanced Tab and Check the box "Allow Other network users to connect through this computers internet connection" in the Internet Connection Sharing choice. +- Go to the Advanced Tab and Check the box "Allow Other network users to connect through this computers internet connection" in the Internet Connection Sharing choice. -- This will assign 192.168.0.1 IP address to NIC2. +- This will assign 192.168.0.1 IP address to NIC2. -- Now on machine B, you can assume 192.168.0.2 as the local IP address and run Myping.exe . Or, you can install the sample in the miniport configuration and browse the internet. +- Now on machine B, you can assume 192.168.0.2 as the local IP address and run Myping.exe . Or, you can install the sample in the miniport configuration and browse the internet. Other menu options of myping applications are: -- Reenumerate All Device: This command lets you terminate active ping threads and close handle to all the device and reenumerate the devices again and display their names with index numbers. This might cause the devices to have new index numbers. +- Reenumerate All Device: This command lets you terminate active ping threads and close handle to all the device and reenumerate the devices again and display their names with index numbers. This might cause the devices to have new index numbers. -- Cleanup: This command terminates ping threads and closes handles to all the devices. +- Cleanup: This command terminates ping threads and closes handles to all the devices. -- Clear Display: Clears the window. +- Clear Display: Clears the window. -- Verbose: Let you get more debug messages. +- Verbose: Let you get more debug messages. -- Exit: Terminate the application. +- Exit: Terminate the application. **Note** You can use this application only on a device installed in the standalone configuration. If you run it on a device that's installed as a miniport, you will get an error message. For such devices, you can use the system provided ping.exe. -RESOURCES ---------- +## RESOURCES -For the latest release of the Windows Driver Kit, see http://www.microsoft.com/whdc/. +For the latest release of the Windows Driver Kit, see [Download the Windows Driver Kit (WDK)](https://docs.microsoft.com/windows-hardware/drivers/download-the-wdk). 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. -FILE MANIFEST -------------- +## FILE MANIFEST File | Description -----|------------ KMDF | Contains the driver. KMDF\HW | Contains hardware specific code. TEST | Contains source of test application (MYPING). - - - diff --git a/general/pcidrv/general-pcidrv.yml b/general/pcidrv/general-pcidrv.yml deleted file mode 100644 index 67df668f..00000000 --- a/general/pcidrv/general-pcidrv.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: PCIDRV - WDF Driver for PCI Device - description: Demonstrates how to write a KMDF driver for a PCI device. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/pcidrv/pcidrv.sln diff --git a/general/perfcounters/kcs/README.md b/general/perfcounters/kcs/README.md index 2e7553e5..54ad9fc1 100644 --- a/general/perfcounters/kcs/README.md +++ b/general/perfcounters/kcs/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Kernel Counter Sample (Kcs) +description: Demonstrates the use of the kernel-mode performance library. +languages: + - cpp +products: + - windows +--- + - -Kernel Counter Sample (Kcs) -=========================== +# Kernel Counter Sample (Kcs) The Kcs sample driver demonstrates the use of the [kernel-mode performance library](http://msdn.microsoft.com/en-us/library/windows/hardware/ff548159). The sample driver does not control any hardware; it simply provides example code that demonstrates how to provide counter data from a kernel-mode driver. The code contains comments to explain what each function does. The sample creates geometric wave and trigonometric wave counter sets. @@ -18,6 +26,3 @@ This module contains sample code to demonstrate how to provide counter data from This sample driver should not be used in a production environment. The Microsoft Windows operating system allows system components and third parties to expose performance metrics in a standard way by using [Performance Counters](http://msdn.microsoft.com/en-us/library/windows/hardware/aa373083). Kernel-mode PCW providers are installed in the system as Performance Counter Library (PERFLIB) (Version 2 providers), which allows their counters to be browsed, and allows for data collection and instance enumeration. Consumers can query KM PCW providers by using PDH and PERFLIB Version 1 without any modification to the consumer code. - - - diff --git a/general/perfcounters/kcs/general-perfcounters-kcs.yml b/general/perfcounters/kcs/general-perfcounters-kcs.yml deleted file mode 100644 index 05746590..00000000 --- a/general/perfcounters/kcs/general-perfcounters-kcs.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Kernel Counter Sample (Kcs) - description: Demonstrates the use of the kernel-mode performance library. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/perfcounters/kcs/kcs.sln diff --git a/general/registry/regfltr/README.md b/general/registry/regfltr/README.md index 40fe7011..78c903e8 100644 --- a/general/registry/regfltr/README.md +++ b/general/registry/regfltr/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: RegFltr Sample Driver +description: Demonstrates how to write a registry filter driver. +languages: + - cpp +products: + - windows +--- + - -RegFltr Sample Driver -===================== +# RegFltr Sample Driver The RegFltr sample shows how to write a [registry filter driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff545879).In addition to providing some basic examples, this sample demonstrates the following: -- How to handle transactional registry operations. -- How and when to capture input parameters. -- Issues and workarounds for version 1.0 of registry filtering. -- Changes in version 1.1 of registry filtering. -- How to use version 1 of the [**REG\_CREATE\_KEY\_INFORMATION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560920) and [**REG\_OPEN\_KEY\_INFORMATION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560957) data structures. +- How to handle transactional registry operations. +- How and when to capture input parameters. +- Issues and workarounds for version 1.0 of registry filtering. +- Changes in version 1.1 of registry filtering. +- How to use version 1 of the [**REG\_CREATE\_KEY\_INFORMATION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560920) and [**REG\_OPEN\_KEY\_INFORMATION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560957) data structures. The RegFltr sample contains several examples of user-mode and kernel-mode registry-filtering operations. Each example comes with its own corresponding registry callback routine, and performs the following steps: -1. Does some setup work. -2. Registers the callback routine. -3. Performs one or more registry operations. -4. Unregisters the callback routine. -5. Verifies that the sample completed correctly. +1. Does some setup work. +1. Registers the callback routine. +1. Performs one or more registry operations. +1. Unregisters the callback routine. +1. Verifies that the sample completed correctly. The sample driver is a minimal driver that is not intended to be used on production systems. To keep the samples simple, the registry callback routines provided do not check for all possible situations and error conditions. This sample is designed to demonstrate typical scenarios and no other registry filtering driver is expected to be active. - diff --git a/general/registry/regfltr/general-registry-regfltr.yml b/general/registry/regfltr/general-registry-regfltr.yml deleted file mode 100644 index 999500f8..00000000 --- a/general/registry/regfltr/general-registry-regfltr.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: RegFltr Sample Driver - description: Demonstrates how to write a registry filter driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/registry/regfltr/regfltr.sln diff --git a/general/registry/regfltr/sys/regfltr.c b/general/registry/regfltr/sys/regfltr.c index 730459b2..e7895ef3 100644 --- a/general/registry/regfltr/sys/regfltr.c +++ b/general/registry/regfltr/sys/regfltr.c @@ -106,7 +106,7 @@ Return Value: // CallbackCtx. // - if (Argument2 == NULL) { + if (Argument2 == NULL) { // // This should never happen but the sal annotation on the callback diff --git a/general/toaster/toastDrv/README.md b/general/toaster/toastDrv/README.md index 9e9a469a..5cf3aff3 100644 --- a/general/toaster/toastDrv/README.md +++ b/general/toaster/toastDrv/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Toaster Sample Driver +description: An iterative series of samples that demonstrate KDMF and UDMF1 driver development. +languages: + - cpp +products: + - windows +--- + +# Toaster Sample Driver -Toaster Sample Driver -===================== The Toaster collection is an iterative series of samples that demonstrate fundamental aspects of Windows driver development for both Kernel-Mode Driver Framework (KMDF) and User-Mode Driver Framework (UMDF) version 1. All the samples work with a hypothetical toaster bus, over which toaster devices can be connected to a PC. The Toaster sample collection comprises driver projects (.vcxproj files) that are contained in the toaster.sln solution file (in general\\toaster\\toastdrv). -Related technologies --------------------- +## Related technologies + [Windows Driver Frameworks](http://msdn.microsoft.com/en-us/library/windows/hardware/ff557565) For detailed descriptions and code walkthroughs of each project, see [Sample Toaster Driver Programming Tour](http://msdn.microsoft.com/en-us/library/windows/hardware/dn569312). To learn how to build and run the samples, read on. +## Run the sample -Run the sample --------------- The computer where you install the driver is called the *target computer* or the *test computer*. Typically this is a separate computer from where you develop and build the driver package. The computer where you develop and build the driver is called the *host computer*. The process of moving the driver package to the target computer and installing the driver is called *deploying the driver*. You can deploy components of the Toaster Sample automatically or manually. Here, we install the wdfsimple driver on the target computer. @@ -33,25 +41,25 @@ The process of moving the driver package to the target computer and installing t Before doing this, you should back up your package.vcxproj file, located in your sample directory, for example C:\\Toaster\\C++\\Package. -1. In the Properties for the package project, navigate to **Common Properties \> References**. -2. Remove all references except WdfSimple. (Use the **Remove Reference** button at the bottom.) +1. In the Properties for the package project, navigate to **Common Properties \> References**. +1. Remove all references except WdfSimple. (Use the **Remove Reference** button at the bottom.) ### Automatic deployment (root enumerated) Before you automatically deploy a driver, you must provision the target computer. For instructions, see [Configuring a Computer for Driver Deployment, Testing, and Debugging](http://msdn.microsoft.com/en-us/library/windows/hardware/). -1. On the host computer, in Visual Studio, in Solution Explorer, right click the **package** project (within the package folder), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**. -2. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, use the drop down to select the name of a target computer that you provisioned previously. Select **Hardware ID Driver Update**, and enter **{b85b7c50-6a01-11d2-b841-00c04fad5171}\\MsToaster** for the hardware ID. (You can find this value in the WdfSimple.inx file.) Click **Apply** and **OK**. -3. Because this solution contains many projects, you may find it easier to remove some of them before you build and deploy a driver package. To do so, right click **package** (lower case), and choose **Properties**. Navigate to **Common Properties-\>References** and click **Remove Reference** to remove projects you don't want. (You can add them back later by using **Add New Reference**.) Click **OK**. -4. On the **Build** menu, choose **Build Solution** or **Rebuild Solution** (if you removed references). -5. If you removed references and deployment does not succeed, try deleting the contents of the c:\\DriverTest\\Drivers folder on the target machine, and then retry deployment. +1. On the host computer, in Visual Studio, in Solution Explorer, right click the **package** project (within the package folder), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**. +1. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, use the drop down to select the name of a target computer that you provisioned previously. Select **Hardware ID Driver Update**, and enter **{b85b7c50-6a01-11d2-b841-00c04fad5171}\\MsToaster** for the hardware ID. (You can find this value in the WdfSimple.inx file.) Click **Apply** and **OK**. +1. Because this solution contains many projects, you may find it easier to remove some of them before you build and deploy a driver package. To do so, right click **package** (lower case), and choose **Properties**. Navigate to **Common Properties-\>References** and click **Remove Reference** to remove projects you don't want. (You can add them back later by using **Add New Reference**.) Click **OK**. +1. On the **Build** menu, choose **Build Solution** or **Rebuild Solution** (if you removed references). +1. If you removed references and deployment does not succeed, try deleting the contents of the c:\\DriverTest\\Drivers folder on the target machine, and then retry deployment. ### Manual deployment (root enumerated) Before you manually deploy a driver, you must turn on test signing and install a certificate on the target computer. You also need to copy the [DevCon](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544707) tool to the target computer. For instructions, see [Preparing a Computer for Manual Driver Deployment](http://msdn.microsoft.com/en-us/library/windows/hardware/dn265571). -1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\WdfSimplePackage). -2. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter the following command: +1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\WdfSimplePackage). +1. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter the following command: **devcon install WdfSimple.inf {b85b7c50-6a01-11d2-b841-00c04fad5171}\\MsToaster** @@ -61,8 +69,7 @@ On the target computer, in a Command Prompt window, enter **devmgmt** to open De In Device Manager, on the **View** menu, choose **Devices by connection**. Locate **Microsoft WDF Simple Toaster (No Class Installer)** as a child of the root node of the device tree. -Build the sample using MSBuild ------------------------------- +## Build the sample using MSBuild As an alternative to building the Toaster sample in Visual Studio, you can build it in a Visual Studio Command Prompt window. In Visual Studio, on the **Tools** menu, choose **Visual Studio Command Prompt**. In the Visual Studio Command Prompt window, navigate to the folder that has the solution file, Toaster.sln. Use the MSBuild command to build the solution. Here are some examples: @@ -72,8 +79,8 @@ As an alternative to building the Toaster sample in Visual Studio, you can build For more information about using MSBuild to build a driver package, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644). -UMDF Toaster File Manifest --------------------------- +## UMDF Toaster File Manifest + #### WUDFToaster.idl Component Interface file @@ -105,8 +112,8 @@ Sample INF for installing the sample WUDF Toaster driver under the Toaster class This file lists the WPP trace control GUID(s) for the sample driver. This file can be used with the tracelog command's -guid flag to enable the collection of these trace events within an established trace session. These GUIDs must remain in sync with the trace control guids defined in internal.h. -Toastmon File Manifest ----------------------- +## Toastmon File Manifest + #### comsup.cpp & comsup.h Boilerplate COM Support code - specifically base classes which provide implementations for the standard COM interfaces IUnknown and IClassFactory which are used throughout the sample. The implementation of IClassFactory is designed to create instances of the CMyDriver class. If you should change the name of your base driver class, you would also need to modify this file. @@ -141,4 +148,3 @@ This file defines resource information for the ToastMon sample driver. #### UMDFToastMon.inf Sample INF for installing the Skeleton driver to control a root enumerated device with a hardware ID of UMDFSamples\\ToastMon - diff --git a/general/toaster/toastDrv/general-toaster-toastdrv.yml b/general/toaster/toastDrv/general-toaster-toastdrv.yml deleted file mode 100644 index 5c5fcef1..00000000 --- a/general/toaster/toastDrv/general-toaster-toastdrv.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Toaster Sample Driver - description: An iterative series of samples that demonstrate KDMF and UDMF1 driver development. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/toaster/toastDrv/toaster.sln diff --git a/general/toaster/toastpkg/README.md b/general/toaster/toastpkg/README.md index a4763177..b06f76db 100644 --- a/general/toaster/toastpkg/README.md +++ b/general/toaster/toastpkg/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Toaster Package Sample Driver +description: Simulates hardware-first and software-first installation of the toaster sample driver. +languages: + - cpp +products: + - windows +--- + +# Toaster Package Sample Driver -Toaster Package Sample Driver -============================= The Toaster collection is an iterative series of samples that demonstrate fundamental aspects of Windows driver development for both Kernel-Mode Driver Framework (KMDF) and User-Mode Driver Framework (UMDF) version 1. All the samples work with a hypothetical toaster bus, over which toaster devices can be connected to a PC. The Toaster sample collection comprises driver projects (.vcxproj files) that are contained in the toaster.sln solution file (in general\\toaster\\toastdrv). -Related technologies --------------------- +## Related technologies + [Windows Driver Frameworks](http://msdn.microsoft.com/en-us/library/windows/hardware/ff557565) For detailed descriptions and code walkthroughs of each project, see [Sample Toaster Driver Programming Tour](http://msdn.microsoft.com/en-us/library/windows/hardware/dn569312). To learn how to build and run the samples, read on. +## Run the sample -Run the sample --------------- The computer where you install the driver is called the *target computer* or the *test computer*. Typically this is a separate computer from where you develop and build the driver package. The computer where you develop and build the driver is called the *host computer*. The process of moving the driver package to the target computer and installing the driver is called *deploying the driver*. You can deploy components of the Toaster Sample automatically or manually. Here, we install the wdfsimple driver on the target computer. @@ -33,25 +41,25 @@ The process of moving the driver package to the target computer and installing t Before doing this, you should back up your package.vcxproj file, located in your sample directory, for example C:\\Toaster\\C++\\Package. -1. In the Properties for the package project, navigate to **Common Properties \> References**. -2. Remove all references except WdfSimple. (Use the **Remove Reference** button at the bottom.) +1. In the Properties for the package project, navigate to **Common Properties \> References**. +1. Remove all references except WdfSimple. (Use the **Remove Reference** button at the bottom.) ### Automatic deployment (root enumerated) Before you automatically deploy a driver, you must provision the target computer. For instructions, see [Configuring a Computer for Driver Deployment, Testing, and Debugging](http://msdn.microsoft.com/en-us/library/windows/hardware/). -1. On the host computer, in Visual Studio, in Solution Explorer, right click the **package** project (within the package folder), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**. -2. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, use the drop down to select the name of a target computer that you provisioned previously. Select **Hardware ID Driver Update**, and enter **{b85b7c50-6a01-11d2-b841-00c04fad5171}\\MsToaster** for the hardware ID. (You can find this value in the WdfSimple.inx file.) Click **Apply** and **OK**. -3. Because this solution contains many projects, you may find it easier to remove some of them before you build and deploy a driver package. To do so, right click **package** (lower case), and choose **Properties**. Navigate to **Common Properties-\>References** and click **Remove Reference** to remove projects you don't want. (You can add them back later by using **Add New Reference**.) Click **OK**. -4. On the **Build** menu, choose **Build Solution** or **Rebuild Solution** (if you removed references). -5. If you removed references and deployment does not succeed, try deleting the contents of the c:\\DriverTest\\Drivers folder on the target machine, and then retry deployment. +1. On the host computer, in Visual Studio, in Solution Explorer, right click the **package** project (within the package folder), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**. +1. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, use the drop down to select the name of a target computer that you provisioned previously. Select **Hardware ID Driver Update**, and enter **{b85b7c50-6a01-11d2-b841-00c04fad5171}\\MsToaster** for the hardware ID. (You can find this value in the WdfSimple.inx file.) Click **Apply** and **OK**. +1. Because this solution contains many projects, you may find it easier to remove some of them before you build and deploy a driver package. To do so, right click **package** (lower case), and choose **Properties**. Navigate to **Common Properties-\>References** and click **Remove Reference** to remove projects you don't want. (You can add them back later by using **Add New Reference**.) Click **OK**. +1. On the **Build** menu, choose **Build Solution** or **Rebuild Solution** (if you removed references). +1. If you removed references and deployment does not succeed, try deleting the contents of the c:\\DriverTest\\Drivers folder on the target machine, and then retry deployment. ### Manual deployment (root enumerated) Before you manually deploy a driver, you must turn on test signing and install a certificate on the target computer. You also need to copy the [DevCon](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544707) tool to the target computer. For instructions, see [Preparing a Computer for Manual Driver Deployment](http://msdn.microsoft.com/en-us/library/windows/hardware/dn265571). -1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\WdfSimplePackage). -2. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter the following command: +1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\WdfSimplePackage). +1. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter the following command: **devcon install WdfSimple.inf {b85b7c50-6a01-11d2-b841-00c04fad5171}\\MsToaster** @@ -61,8 +69,7 @@ On the target computer, in a Command Prompt window, enter **devmgmt** to open De In Device Manager, on the **View** menu, choose **Devices by connection**. Locate **Microsoft WDF Simple Toaster (No Class Installer)** as a child of the root node of the device tree. -Build the sample using MSBuild ------------------------------- +## Build the sample using MSBuild As an alternative to building the Toaster sample in Visual Studio, you can build it in a Visual Studio Command Prompt window. In Visual Studio, on the **Tools** menu, choose **Visual Studio Command Prompt**. In the Visual Studio Command Prompt window, navigate to the folder that has the solution file, Toaster.sln. Use the MSBuild command to build the solution. Here are some examples: @@ -72,8 +79,8 @@ As an alternative to building the Toaster sample in Visual Studio, you can build For more information about using MSBuild to build a driver package, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644). -UMDF Toaster File Manifest --------------------------- +## UMDF Toaster File Manifest + #### WUDFToaster.idl Component Interface file @@ -105,8 +112,8 @@ Sample INF for installing the sample WUDF Toaster driver under the Toaster class This file lists the WPP trace control GUID(s) for the sample driver. This file can be used with the tracelog command's -guid flag to enable the collection of these trace events within an established trace session. These GUIDs must remain in sync with the trace control guids defined in internal.h. -Toastmon File Manifest ----------------------- +## Toastmon File Manifest + #### comsup.cpp & comsup.h Boilerplate COM Support code - specifically base classes which provide implementations for the standard COM interfaces IUnknown and IClassFactory which are used throughout the sample. The implementation of IClassFactory is designed to create instances of the CMyDriver class. If you should change the name of your base driver class, you would also need to modify this file. @@ -141,4 +148,3 @@ This file defines resource information for the ToastMon sample driver. #### UMDFToastMon.inf Sample INF for installing the Skeleton driver to control a root enumerated device with a hardware ID of UMDFSamples\\ToastMon - diff --git a/general/toaster/toastpkg/general-toaster-toastpkg.yml b/general/toaster/toastpkg/general-toaster-toastpkg.yml deleted file mode 100644 index 2698b119..00000000 --- a/general/toaster/toastpkg/general-toaster-toastpkg.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Toaster Package Sample Driver - description: Simulates hardware-first and software-first installation of the toaster sample driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/toaster/toastpkg/toastpkg.sln diff --git a/general/toaster/umdf2/README.md b/general/toaster/umdf2/README.md index 75cf882b..2b3f5e2f 100644 --- a/general/toaster/umdf2/README.md +++ b/general/toaster/umdf2/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Toaster Sample (UMDF version 2) +description: An iterative series of samples that demonstrate driver development using UMDF version 2. +languages: + - cpp +products: + - windows +--- + +# Toaster Sample (UMDF Version 2) -Toaster Sample (UMDF Version 2) -=============================== The Toaster (UMDF version 2) sample is an iterative series of samples that demonstrate fundamental aspects of Windows driver development. The Toaster sample collection is comprised of driver projects (.vcxproj files) that are contained in the umdf2toaster.sln solution file. +## Related technologies -Related technologies --------------------- [User-Mode Driver Framework](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560456) +## Run the sample -Run the sample --------------- The computer where you install the driver is called the *target computer* or the *test computer*. Typically this is a separate computer from where you develop and build the driver package. The computer where you develop and build the driver is called the *host computer*. The process of moving the driver package to the target computer and installing the driver is called *deploying the driver*. You can deploy a driver sample automatically or manually. @@ -30,18 +37,18 @@ The process of moving the driver package to the target computer and installing t Before you automatically deploy a driver, you must provision the target computer. For instructions, see [Configuring a Computer for Driver Deployment, Testing, and Debugging](http://msdn.microsoft.com/en-us/library/windows/hardware/). -1. On the host computer, in Visual Studio, in Solution Explorer, right click **package** (lower case), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**. -2. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, select the name of a target computer that you provisioned previously. Select **Hardware ID Driver Update**, and enter **root\\toaster** for the hardware ID. Click **OK**. -3. Because this solution contains many projects, you may find it easier to remove some of them before you build and deploy a driver package. To do so, right click **package** (lower case), and choose **Properties**. Navigate to **Common Properties-\>References** and click **Remove Reference** to remove projects you don't want. (You can add them back later by using **Add New Reference**.) Click **OK**. -4. On the **Build** menu, choose **Build Solution** or **Rebuild Solution** (if you removed references). -5. If you removed references and deployment does not succeed, try deleting the contents of the c:\\DriverTest\\Drivers folder on the target machine, and then retry deployment. +1. On the host computer, in Visual Studio, in Solution Explorer, right click **package** (lower case), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**. +1. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, select the name of a target computer that you provisioned previously. Select **Hardware ID Driver Update**, and enter **root\\toaster** for the hardware ID. Click **OK**. +1. Because this solution contains many projects, you may find it easier to remove some of them before you build and deploy a driver package. To do so, right click **package** (lower case), and choose **Properties**. Navigate to **Common Properties-\>References** and click **Remove Reference** to remove projects you don't want. (You can add them back later by using **Add New Reference**.) Click **OK**. +1. On the **Build** menu, choose **Build Solution** or **Rebuild Solution** (if you removed references). +1. If you removed references and deployment does not succeed, try deleting the contents of the c:\\DriverTest\\Drivers folder on the target machine, and then retry deployment. ### Manual deployment (root enumerated) Before you manually deploy a driver, you must turn on test signing and install a certificate on the target computer. You also need to copy the [DevCon](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544707) tool to the target computer. For instructions, see [Preparing a Computer for Manual Driver Deployment](http://msdn.microsoft.com/en-us/library/windows/hardware/dn265571). -1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\Umdf2toaster). -2. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter a command such as: +1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\Umdf2toaster). +1. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter a command such as: **devcon install wdfsimpleum.inf root\\toaster** @@ -51,11 +58,10 @@ On the target computer, in a Command Prompt window, enter **devmgmt** to open De In Device Manager, on the **View** menu, choose **Devices by connection**. Locate **Sample WDF Toaster Service + Filter** as a child of the root node of the device tree. -Build the sample using MSBuild ------------------------------- +## Build the sample using MSBuild + As an alternative to building the driver sample in Visual Studio, you can build it in a Visual Studio Command Prompt window. In Visual Studio, on the **Tools** menu, choose **Visual Studio Command Prompt**. In the Visual Studio Command Prompt window, navigate to the folder that has the solution file, Umdf2toaster.sln. Use the MSBuild command to build the solution. Here is an example: **msbuild /p:configuration="Release" /p:platform="Win32" Umdf2toaster.sln** For more information about using MSBuild to build a driver package, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644). - diff --git a/general/toaster/umdf2/general-toaster-umdf2.yml b/general/toaster/umdf2/general-toaster-umdf2.yml deleted file mode 100644 index 9ccf446f..00000000 --- a/general/toaster/umdf2/general-toaster-umdf2.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Toaster Sample (UMDF version 2) - description: An iterative series of samples that demonstrate driver development using UMDF version 2. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/toaster/umdf2/umdf2toaster.sln diff --git a/general/tracing/SystemTraceControl/README.md b/general/tracing/SystemTraceControl/README.md index b45ae788..d6bb9f2f 100644 --- a/general/tracing/SystemTraceControl/README.md +++ b/general/tracing/SystemTraceControl/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: System Trace Control +description: Demonstrates how to use event tracing control APIs to collect events from the system trace provider. +languages: + - cpp +products: + - windows +--- + - -SystemTraceProvider -=================== +# SystemTraceProvider This sample application demonstrates how to use event tracing control APIs to collect events from the system trace provider. @@ -18,4 +26,3 @@ The sample code provided shows how to start an [Event Tracing](http://msdn.micro You can process the Systemtrace.etl file using Tracerpt.exe, a command-line trace tool included in Windows that formats trace events. It also analyzes the events and generates summary reports. For more information about how to use this tool, see [Tracerpt](http://go.microsoft.com/fwlink/p/?linkid=179389) topic on the TechNet website. You can also process the file using the [Windows Performance Toolkit](http://go.microsoft.com/fwlink/p/?linkid=250774) (WPT), which is available in the SDK. - diff --git a/general/tracing/SystemTraceControl/general-tracing-systemtracecontrol.yml b/general/tracing/SystemTraceControl/general-tracing-systemtracecontrol.yml deleted file mode 100644 index 1d54d1da..00000000 --- a/general/tracing/SystemTraceControl/general-tracing-systemtracecontrol.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: System Trace Control - description: Demonstrates how to use event tracing control APIs to collect events from the system trace provider. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/tracing/SystemTraceControl/SystemTraceControl.sln diff --git a/general/tracing/evntdrv/README.md b/general/tracing/evntdrv/README.md index 41359ad1..99eb0c11 100644 --- a/general/tracing/evntdrv/README.md +++ b/general/tracing/evntdrv/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Eventdrv +description: Demonstrates the use of the Event Tracing for Windows (ETW) API in a driver. +languages: + - cpp +products: + - windows +--- + - -Eventdrv -======== +# Eventdrv Eventdrv is a sample kernel-mode trace provider and driver. The driver does not control any hardware; it simply generates trace events. It is designed to demonstrate the use of the [Event Tracing for Windows (ETW)](http://msdn.microsoft.com/en-us/library/windows/hardware/ff545699) API in a driver. @@ -17,41 +25,39 @@ Evntdrv registers as a provider by calling the [**EtwRegister**](http://msdn.mic **Note** The Windows Pre-Processor (WPP) Tracing tools such as TraceView.exe cannot be used to start, stop, or view traces. +## Run the sample -Run the sample --------------- - -1. Install the manifest (Evntdrv.xml), which is located in the Evntdrv\\Eventdrv folder. Open a Visual Studio Command window (Run as administrator) and use the following command: +1. Install the manifest (Evntdrv.xml), which is located in the Evntdrv\\Eventdrv folder. Open a Visual Studio Command window (Run as administrator) and use the following command: ``` wevtutil im evntdrv.xml ``` Installing the manifest creates registry keys that enable tools to find the resource and message files that contain event provider information. For further details about the WevtUtil.exe tool, see the MSDN Library. - + **Note** Using a Visual Studio Command windows sets up the environment variables you need to run the tracing tools for this sample. -2. Make a folder in the system directory called ETWDriverSample (for example, C:\\ETWDriverSample). +1. Make a folder in the system directory called ETWDriverSample (for example, C:\\ETWDriverSample). Copy Eventdrv.sys and Evntctrl.exe to the ETWDriverSample folder. The ETWDriverSample directory must be created because the path to the resource file that is specified in the evntdrv.xml manifest points to the %SystemRoot%\\ETWDriverSample folder. If this folder is not created and the Eventdrv.sys binary is not copied, decoding tools cannot find the event information to decode the trace file. -3. Use Tracelog to start a trace session that is called "TestEventdrv." The following command starts the trace session and creates a trace log file, Eventdrv.etl, in the local directory. +1. 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 ``` -4. To generate trace messages, run Evntctrl.exe. 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**. +1. To generate trace messages, run Evntctrl.exe. 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**. -5. To stop the trace session, run the following command: +1. To stop the trace session, run the following command: ``` tracelog -stop TestEventdrv ``` -6. To display the traces collected in the Tracedrv.etl file, run the following command: +1. To display the traces collected in the Tracedrv.etl file, run the following command: ``` tracerpt Eventdrv.etl @@ -59,14 +65,12 @@ Run the sample This command creates two files: Summary.txt and Dumpfile.xml. Dumpfile.xml will contain the event information in an XML format. -7. To uninstall the manifest, run the following command: +1. To uninstall the manifest, run the following command: ``` wevtutil um evntdrv.xml ``` -Notes ------ +## Notes If you are building the Eventdrv sample to test on a 64-bit version of Windows, you need to sign the driver. All 64-bit versions of Windows require driver code to have a digital signature for the driver to load. See [Signing a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554809) and [Signing a Driver During Development and Testing](http://msdn.microsoft.com/en-us/library/windows/hardware/hh967733). You might also need to configure the test computer so that it can load test-signed kernel mode code, see [The TESTSIGNING Boot Configuration Option](http://msdn.microsoft.com/en-us/library/windows/hardware/ff553484) and [**BCDEdit /set**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff542202). - diff --git a/general/tracing/evntdrv/general-tracing-evntdrv.yml b/general/tracing/evntdrv/general-tracing-evntdrv.yml deleted file mode 100644 index 9acd3683..00000000 --- a/general/tracing/evntdrv/general-tracing-evntdrv.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Eventdrv - description: Demonstrates the use of the Event Tracing for Windows (ETW) API in a driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/tracing/evntdrv/eventdrv.sln diff --git a/general/tracing/tracedriver/README.md b/general/tracing/tracedriver/README.md index 358053a1..efbd2095 100644 --- a/general/tracing/tracedriver/README.md +++ b/general/tracing/tracedriver/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Tracedrv +description: A sample driver instrumented for software tracing. +languages: + - cpp +products: + - windows +--- + - -Tracedrv -======== +# Tracedrv 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. @@ -17,23 +25,22 @@ Tracedrv initializes tracing (by using WPP\_INIT\_TRACING) and, when it receives While examining Tracedrv, read the [WPP Software Tracing](http://msdn.microsoft.com/en-us/library/windows/hardware/ff556204) in the Windows Driver Kit (WDK). This section includes a reference section that describes the directives, macros, and calls required for WPP software tracing. -Run the sample --------------- +## Run the sample To test the Tracedrv event tracing provider, use the following procedure. -1. Copy the Tracectl.exe file that was created when you built the Tracedrv solution from the Tracectl directory (for example, \\Documents\\Visual Studio 2015\\Projects\\tracedrv\\tracectl\\*platform*) to the Tracedrv directory (for example, \\Documents\\Visual Studio 2015\\Projects\\tracedrv\\tracedrv\\*platform*). -2. Use Tracepdb to create a trace message format (TMF) file and a trace message control (TMC) file from the Tracedrv.pdb file. Tracepdb is located in the C:\\Program Files (x86)\\Windows Kits\\10\\bin\\*platform* directory. The PDB file that is used in this command is created when you the build the solution. Open a Visual Studio Command prompt window and navigate to the target build platform and configuration directory. Type the following command: +1. Copy the Tracectl.exe file that was created when you built the Tracedrv solution from the Tracectl directory (for example, \\Documents\\Visual Studio 2015\\Projects\\tracedrv\\tracectl\\*platform*) to the Tracedrv directory (for example, \\Documents\\Visual Studio 2015\\Projects\\tracedrv\\tracedrv\\*platform*). +1. Use Tracepdb to create a trace message format (TMF) file and a trace message control (TMC) file from the Tracedrv.pdb file. Tracepdb is located in the C:\\Program Files (x86)\\Windows Kits\\10\\bin\\*platform* directory. The PDB file that is used in this command is created when you the build the solution. Open a Visual Studio Command prompt window and navigate to the target build platform and configuration directory. Type the following command: **tracepdb -f tracedrv.pdb** -3. In the same Tracedrv target build directory, create a control GUID file for Tracedrv by opening a text file, adding the following content, and saving the file as Tracedrv.ctl. +1. In the same Tracedrv target build directory, create a control GUID file for Tracedrv by opening a text file, adding the following content, and saving the file as Tracedrv.ctl. ```txt d58c126f-b309-11d1-969e-0000f875a5bc ``` -4. Use Tracelog to start a trace session that is called *TestTracedrv*. Tracelog is located in the C:\\Program Files (x86)\\Windows Kits\\10\\bin\\*platform* directory. The Tracedrv.ctl file that is used in this command was created in the previous step. The following command starts a trace session and creates a trace log file, tracedrv.etl, in the local directory. +1. Use Tracelog to start a trace session that is called *TestTracedrv*. Tracelog is located in the C:\\Program Files (x86)\\Windows Kits\\10\\bin\\*platform* directory. The Tracedrv.ctl file that is used in this command was created in the previous step. The following command starts a trace session and creates a trace log file, tracedrv.etl, in the local directory. ``` tracelog -start TestTracedrv -guid tracedrv.ctl -f tracedrv.etl -flag 1 @@ -41,14 +48,14 @@ To test the Tracedrv event tracing provider, use the following procedure. **Note** Without the -flag parameter, Tracedrv will not generate any trace messages. -5. To generate trace messages, run Tracectl.exe. This executable file is built when you build the solution. Each time you type a character, other than **Q** or **q**, Tracectl sends an IOCTL to the driver that signals it to generate trace messages. To stop Tracectl, type **Q** or **q**. -6. To stop the trace session, use the following Tracelog command. +1. To generate trace messages, run Tracectl.exe. This executable file is built when you build the solution. Each time you type a character, other than **Q** or **q**, Tracectl sends an IOCTL to the driver that signals it to generate trace messages. To stop Tracectl, type **Q** or **q**. +1. To stop the trace session, use the following Tracelog command. ``` tracelog -stop TestTracedrv ``` -7. To display the trace messages in the Tracedrv.etl file, use Tracefmt.exe. Tracefmt.exe is located in the C:\\Program Files (x86)\\Windows Kits\\10\\bin\\*platform*. The TMF file used in this command was created by Tracepdb.exe in step 2. The **-p** option specifies the directory of the TMF file. In this case, the TMF file is in the current directory. Type the following command: +1. To display the trace messages in the Tracedrv.etl file, use Tracefmt.exe. Tracefmt.exe is located in the C:\\Program Files (x86)\\Windows Kits\\10\\bin\\*platform*. The TMF file used in this command was created by Tracepdb.exe in step 2. The **-p** option specifies the directory of the TMF file. In this case, the TMF file is in the current directory. Type the following command: ``` tracefmt tracedrv.etl -p . -o Tracedrv.out @@ -56,8 +63,7 @@ To test the Tracedrv event tracing provider, use the following procedure. The resulting Tracedrv.out file is a human-readable text file of the Tracedrv trace messages. To interpret the trace messages, in the Tracedrv.c file, search for the [**DoTraceMessage**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544918) macros. -Notes ------ +## Notes This sample driver should not be used in a production environment. @@ -66,4 +72,3 @@ Also, because it is not a Plug and Play driver, Tracedrv does not demonstrate tr Tracedrv demonstrates the basic elements required for software tracing. It does not demonstrate more advanced tracing techniques, such as writing customized tracing calls (variations of [**DoTraceMessage**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544918)), or the use of WMI calls for software tracing. If you are building the Tracedrv sample to test on a 64-bit version of Windows, you need to sign the driver. All 64-bit versions of Windows require driver code to have a digital signature for the driver to load. See [Signing a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554809) and [Signing a Driver During Development and Testing](http://msdn.microsoft.com/en-us/library/windows/hardware/hh967733). You might also need to configure the test computer so that it can load test-signed kernel mode code, see [The TESTSIGNING Boot Configuration Option](http://msdn.microsoft.com/en-us/library/windows/hardware/ff553484) and [**BCDEdit /set**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff542202). - diff --git a/general/tracing/tracedriver/general-tracing-tracedriver.yml b/general/tracing/tracedriver/general-tracing-tracedriver.yml deleted file mode 100644 index ad383818..00000000 --- a/general/tracing/tracedriver/general-tracing-tracedriver.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Tracedrv - description: A sample driver instrumented for software tracing. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/tracing/tracedriver/tracedrv.sln diff --git a/general/umdfSkeleton/README.md b/general/umdfSkeleton/README.md index 022722c1..fa594f39 100644 --- a/general/umdfSkeleton/README.md +++ b/general/umdfSkeleton/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: UMDF Driver Skeleton Sample (UMDF version 1) +description: Demonstrates how to use UDMF to write a minimal driver. +languages: + - cpp +products: + - windows +--- + - -UMDF Driver Skeleton Sample (UMDF Version 1) -============================================ +# UMDF Driver Skeleton Sample (UMDF Version 1) This sample demonstrates how to use version 1 of the User-Mode Driver Framework to write a minimal driver. The Skeleton driver will successfully load on a device (either root enumerated or a real hardware device) but does not support any I/O operations. - diff --git a/general/umdfSkeleton/general-umdfskeleton.yml b/general/umdfSkeleton/general-umdfskeleton.yml deleted file mode 100644 index 9acc8543..00000000 --- a/general/umdfSkeleton/general-umdfskeleton.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: UMDF Driver Skeleton Sample (UMDF version 1) - description: Demonstrates how to use UDMF to write a minimal driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /general/umdfSkeleton/umdfSkeleton.sln diff --git a/gnss/ReadMe.md b/gnss/ReadMe.md index deaca7a6..dabd1d44 100644 --- a/gnss/ReadMe.md +++ b/gnss/ReadMe.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: GNSS UMDF Sample Driver (UMDF Version 2) +description: Provides base sample driver that IHVs and partners can use to extend to build their custom Windows GPS/GNSS drivers. +languages: + - cpp +products: + - windows +--- + +# GNSS UMDF Sample Driver (UMDF Version 2) -GNSS UMDF Sample Driver (UMDF Version 2) -============================================================================== +Provides a base sample driver that IHVs and partners can use to extend to build their custom Windows GPS/GNSS drivers. -# Overview +## Overview -## What is covered? +### What is covered -* This is a sample that adheres to GNSS driver design for Windows 10 with this MSDN link: https://docs.microsoft.com/en-us/windows-hardware/drivers/gnss/gnss-driver-design-guide-for-windows-10 +* This is a sample that adheres to GNSS driver design for Windows 10 outlined in the [GNSS driver design guide for Windows 10](https://docs.microsoft.com/windows-hardware/drivers/gnss/gnss-driver-design-guide-for-windows-10). * Serves as base sample driver that IHVs and partners can use as a template and guidance to extend to build their custom Windows GNSS drivers. * Follows the WDF guidelines and best practices around PnP device arrival/removal, power management and driver installation/uninstallation. * Supports the GNSS DDI mandatory requirements. * This driver successfully passes HLK tests and WDF tests provided by Visual studio. -## What is not covered? +### What is not covered * This sample currently doesn't support Geofence, SUPL, and AGNSS, as this is not mandatory GNSS DDI functionality. * SUPL and AGNSS are mandatory only if required by mobile operator, and the sample does not support them currently. * Not a production driver. -## What Partner needs to do? +### What a Partner needs to do * Customer can install WDK and run Location HLK tests to validate their driver. All test cases should be either pass or skip without failure. * Partner owns the following: - - Installing the driver. - - Adding certificate and driver signing. - - Updating manufacturer name driver version etc. (the code has comments to update). + * Installing the driver. + * Adding certificate and driver signing. + * Updating manufacturer name driver version etc. (the code has comments to update). * The GNSS sample code has "FIX ME" comments. Partner should update them accordingly. - -# Design +## Design * The sample demonstrates a very basic software only driver that meets the minimum requirements from the GNSS DDI. * The sample currently always returns a fake hardcoded location. Driver developers can extend this to fetch fake positions from a file or inject through a custom IOCTL or instead implement getting real positions from GNSS hardware. * Driver developer can extend this to pull the fake positions from a file or through custom IOCTLs if needed. - -# Trace Logging +## Trace Logging * The sample code provides Trace logging WPRP file. * To capture trace log, copy GnssUmdfSampleDriver.wprp in the solution folder into the device under test. On command line (MyLog.etl is an example file name below): - ```sh + + ```cmd wpr -start GnssUmdfSampleDriver.wprp -filemode wpr -stop MyLog.etl ``` + * Inspect MyLog.etl with trace file analyzer. Note that corresponding PDB file is needed to decode the logging information. - -# Test Plan +## Test Plan Customer should validate their driver after customizing it. - -#### Test method 1 + +### Test method 1 * This tests WDF fundamental functionality (PnP etc.), rather than Location-specific features. * Run Visual studio built-in run-time test for WDF. -* General information: https://docs.microsoft.com/en-us/windows-hardware/drivers/develop/testing-a-driver-at-runtime +* General information available at [](https://docs.microsoft.com/windows-hardware/drivers/develop/testing-a-driver-at-runtime). * Expected result / Pass criteria: Pass rate 100% -#### Test method 2 +### Test method 2 * This tests Location-specific functionality (Getting fix etc.). -* Run HLK tests with existing and standard GNSS driver tests. -* General information: https://docs.microsoft.com/en-us/windows-hardware/test/hlk/windows-hardware-lab-kit +* Run [HLK](https://docs.microsoft.com/windows-hardware/test/hlk/windows-hardware-lab-kit) tests with existing and standard GNSS driver tests. * Run "TE.exe GNSSDriverTest.dll". * Expected result / Pass criteria: Pass rate 100% * Note that this sample does not support AGNSS, SUPL and Geofencing currently. Based on the capability of driver, HLK skips them automatically. -#### Test method 3 +### Test method 3 -* This tests from Windows Geolocation API (https://docs.microsoft.com/en-us/windows/desktop/locationapi/windows-location-api-portal) layer on real apps. +* Test the [Windows Geolocation API](https://docs.microsoft.com/en-us/windows/desktop/locationapi/windows-location-api-portal) layer on real apps. * Get current location by clicking on "Show my location" from the In-box Windows Maps app. -* Run tracking scenario from Geolocation Sample app (Download from https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/Geolocation). +* Run the tracking scenario from the [Geolocation Sample app](https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/Geolocation). * Get current location by clicking on "Start" from GPS Satellite app in Windows Store. +## Resources -# Resources - -* GNSS DDI reference - - https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/gnssdriver/index -* Getting started with Windows drivers - - https://docs.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/ -* Windows Driver Kit documentation - - https://docs.microsoft.com/en-us/windows-hardware/drivers/ -* NMEA format documentation - - http://navspark.mybigcommerce.com/content/NMEA_Format_v0.1.pdf - \ No newline at end of file +* [GNSS DDI reference](https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/gnssdriver/index) +* [Getting started with Windows drivers](https://docs.microsoft.com/en-us/windows-hardware/drivers/gettingstarted) +* [Windows Driver Kit documentation](https://docs.microsoft.com/en-us/windows-hardware/drivers) +* [NMEA format documentation](http://navspark.mybigcommerce.com/content/NMEA_Format_v0.1.pdf) diff --git a/gnss/gnss.yaml b/gnss/gnss.yaml deleted file mode 100644 index e53b2045..00000000 --- a/gnss/gnss.yaml +++ /dev/null @@ -1,10 +0,0 @@ -### YamlMime:Sample -sample: -- name: GPS/GNSS UMDF V2 Device Driver Sample - description: Demonstrates how to write a device driver that IHVs and partners can use to extend to build their custom drivers - generateZip: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows diff --git a/gpio/samples/README.md b/gpio/samples/README.md index ba05c2f6..c4c2d428 100644 --- a/gpio/samples/README.md +++ b/gpio/samples/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: GPIO Sample Drivers +description: Illustrates how to write a GPIO controller driver that works in conjunction with the GPIO framework extension (GpioClx). +languages: + - cpp +products: + - windows +--- + - -GPIO Sample Drivers -=================== +# GPIO Sample Drivers The GPIO samples contain annotated code to illustrate how to write a [GPIO controller driver](http://msdn.microsoft.com/en-us/library/windows/hardware/hh439509) that works in conjunction with the [GPIO framework extension](http://msdn.microsoft.com/en-us/library/windows/hardware/hh439512) (GpioClx) to handle GPIO I/O control requests, and a peripheral driver that runs in kernel mode and uses GPIO resources. For a sample that shows how to write a GPIO peripheral driver that runs in user mode, please refer to the SPB accelerometer sample driver (SPB\\peripherals\\accelerometer). diff --git a/gpio/samples/gpio-samples.yml b/gpio/samples/gpio-samples.yml deleted file mode 100644 index 069fff47..00000000 --- a/gpio/samples/gpio-samples.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: GPIO Sample Drivers - description: Illustrates how to write a GPIO controller driver that works in conjunction with the GPIO framework extension (GpioClx). - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /gpio/samples/sim.sln diff --git a/hid/firefly/README.md b/hid/firefly/README.md index cd526150..49f6b011 100644 --- a/hid/firefly/README.md +++ b/hid/firefly/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: KMDF filter driver for a HID device +description: Illustrates using remote I/O target interfaces to open a HID collection in kernel-mode and send IOCTL requests to set and get feature reports. +languages: + - cpp +products: + - windows +--- + +# KMDF filter driver for a HID device -KMDF filter driver for a HID device -=================================== Firefly is a KMDF-based filter driver for a 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, as well as how an application can use WMI interfaces to send commands to a filter driver. -Related topics --------------- +## Related topics [Human Input Devices Design Guide](http://msdn.microsoft.com/en-us/library/windows/hardware/ff539952) [Human Input Devices Reference](http://msdn.microsoft.com/en-us/library/windows/hardware/ff539956) -Related technologies --------------------- +## Related technologies [Creating Framework-based HID Minidrivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540774) - -Build the sample ----------------- +## Build the sample For information on how to build a driver using Microsoft Visual Studio, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644). When you build the sample, MSBuild.exe creates luminous.lib, firefly.sys, flicker.exe, and sauron.dll. Copy these files as well as the KMDF coinstaller (wdfcoinstallerMMmmm.dll) and the INF file (firefly.inf) to a floppy disk or a temporary directory on the target system. **Note** You can obtain redistributable framework updates by downloading the **wdfcoinstaller.msi** package from [WDK 8 Redistributable Components](http://go.microsoft.com/fwlink/p/?LinkID=226396). This package performs a silent install into the directory of your Windows Driver Kit (WDK) installation. You will see no confirmation that the installation has completed. You can verify that the redistributables have been installed on top of the WDK by ensuring there is a redist\\wdf directory under the root directory of the WDK, %ProgramFiles(x86)%\\Windows Kits\\8.0. -Installation ------------- +## Installation To install the driver: -1. Plug the Microsoft USB Optical mouse into your target machine and verify that the mouse works. The drivers for this mouse come with the operating system so the device will start working automatically when you plug in. -2. You may need to make Group Policy changes in order to replace the existing mouse driver. If you are unable to perform steps 3-9, do the following: - 1. Open **gpedit.msd**. - 2. In the Group Policy Object Editor navigation pane, open the Computer Configuration folder. Then open Administrative Templates, open System, open Device Installation, and then open Device Installation Restrictions. - 3. Enable *Prevent installation of devices not described by other policy settings*. This will prevent Windows from automatically installing the default mouse driver so that you can then install Firefly. - 4. Enable *Allow administrators to override device installation policy*. This will allow you to bypass the ""The installation of this device is forbidden by system policy" error that you may otherwise receive when you attempt to install Firefly. - 5. You may need to reboot. +1. Plug the Microsoft USB Optical mouse into your target machine and verify that the mouse works. The drivers for this mouse come with the operating system so the device will start working automatically when you plug in. +1. You may need to make Group Policy changes in order to replace the existing mouse driver. If you are unable to perform steps 3-9, do the following: + 1. Open **gpedit.msd**. + 1. In the Group Policy Object Editor navigation pane, open the Computer Configuration folder. Then open Administrative Templates, open System, open Device Installation, and then open Device Installation Restrictions. + 1. Enable *Prevent installation of devices not described by other policy settings*. This will prevent Windows from automatically installing the default mouse driver so that you can then install Firefly. + 1. Enable *Allow administrators to override device installation policy*. This will allow you to bypass the ""The installation of this device is forbidden by system policy" error that you may otherwise receive when you attempt to install Firefly. + 1. You may need to reboot. -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 Software." -6. Select "Browse my computer for driver software." -7. Browse to the temporary folder you created earlier. Click Next. Click through the warning. -8. You will see "Windows has successfully updated your driver software" for the "Shiny Things Firefly Mouse" device. -9. The system will copy all the files and restart the mouse device to install the upper filter. Click Close and you are ready to run the test app. +1. Bring up the Device Manager (type **devmgmt.msc** in the Start/Run window and press enter). +1. Find the Microsoft Optical mouse under "Mice and other pointing devices" +1. Right click on the device and choose "Update Driver Software." +1. Select "Browse my computer for driver software." +1. Browse to the temporary folder you created earlier. Click Next. Click through the warning. +1. You will see "Windows has successfully updated your driver software" for the "Shiny Things Firefly Mouse" device. +1. The system will copy all the files and restart the mouse device to install the upper filter. Click Close and you are ready to run the test app. -Testing the Sample ------------------- +## Testing the Sample Copy the flicker.exe to the target machine and run it from an elevated command prompt. The usage is: @@ -66,28 +69,26 @@ Usage: Flicker \<-0 | -1 | -2\> -2 flashes light +### Testing the DLL + The following description applies to Windows Media Player 12 running on Windows 7: -**Testing the DLL** +1. Copy the sauron.dll to the Windows Media player Visualization directory (C:\\Program Files\\Windows Media Player\\Visualizations). +1. Register the DLL with COM by calling "regsvr32 sauron.dll" in command shell. +1. Run Windows Media Player *as administrator*. +1. Click on the "Switch to Now Playing" button in the lower right of the application. +1. Right click, select Visualizations, and you will see a menu item called "Sauron." +1. Choose either Firefly Bars or Firefly Flash and play some music. +1. You will see the mouse light dancing to the tune of the music. +1. You can unregister the DLL by calling "regsvr32 -u sauron.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. Run Windows Media Player *as administrator*. -4. Click on the "Switch to Now Playing" button in the lower right of the application. -5. Right click, select Visualizations, and you will see a menu item called "Sauron." -6. Choose either Firefly Bars or Firefly Flash and play some music. -7. You will see the mouse light dancing to the tune of the music. -8. You can unregister the DLL by calling "regsvr32 -u sauron.dll". - -Programming Tour ----------------- +## Programming Tour The Firefly sample is installed as an upper filter driver for the 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 the WMI interface. The sample consists of: -- Driver (firefly.sys): The Firefly driver is an upper device filter driver for the mouse driver (mouhid.sys). Firefly is a generic filter driver based on the toaster filter driver sample available in the WDK. During start device, the driver registers a WMI class (FireflyDeviceInformation). The user mode application connects to the WMI namespace (root\\wmi) and opens this class using COM interfaces. Then the application can make requests to read ("get") or change ("set") the current value of the TailLit data value from this class. In response to a set WMI request, the driver opens the HID collection using IoTarget and sends [**IOCTL\_HID\_GET\_COLLECTION\_INFORMATION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff541092) and [**IOCTL\_HID\_GET\_COLLECTION\_DESCRIPTOR**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff541089) requests to get the preparsed data. The driver then calls [**HidP\_GetCaps**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff539715) using the preparsed data to retrieve 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 are located in the \\hid\\firefly\\lib folder. You will need to build the library before using it. This library is shared by the WDM and WDF samples. 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 are located in the \\hid\\firefly\\app folder. You will need to build the application before using it. This application is shared by the WDM and WDF samples. The application links to luminous.lib to open the WMI interfaces and send set requests to toggle the light. -- Sauron (sauron.dll): The sources for this file are located in the \\hid\\firefly\\sauron folder. You will need to build this dll before using it. The library is shared by the WDM and WDF samples. Sauron is a Windows Media Player visualization DLL, and is 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. - +- Driver (firefly.sys): The Firefly driver is an upper device filter driver for the mouse driver (mouhid.sys). Firefly is a generic filter driver based on the toaster filter driver sample available in the WDK. During start device, the driver registers a WMI class (FireflyDeviceInformation). The user mode application connects to the WMI namespace (root\\wmi) and opens this class using COM interfaces. Then the application can make requests to read ("get") or change ("set") the current value of the TailLit data value from this class. In response to a set WMI request, the driver opens the HID collection using IoTarget and sends [**IOCTL\_HID\_GET\_COLLECTION\_INFORMATION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff541092) and [**IOCTL\_HID\_GET\_COLLECTION\_DESCRIPTOR**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff541089) requests to get the preparsed data. The driver then calls [**HidP\_GetCaps**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff539715) using the preparsed data to retrieve 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 are located in the \\hid\\firefly\\lib folder. You will need to build the library before using it. This library is shared by the WDM and WDF samples. 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 are located in the \\hid\\firefly\\app folder. You will need to build the application before using it. This application is shared by the WDM and WDF samples. The application links to luminous.lib to open the WMI interfaces and send set requests to toggle the light. +- Sauron (sauron.dll): The sources for this file are located in the \\hid\\firefly\\sauron folder. You will need to build this dll before using it. The library is shared by the WDM and WDF samples. Sauron is a Windows Media Player visualization DLL, and is 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. diff --git a/hid/firefly/hid-firefly.yml b/hid/firefly/hid-firefly.yml deleted file mode 100644 index 7a57b1cd..00000000 --- a/hid/firefly/hid-firefly.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: KMDF filter driver for a HID device - description: Illustrates using remote I/O target interfaces to open a HID collection in kernel-mode and send IOCTL requests to set and get feature reports. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /hid/firefly/firefly.sln diff --git a/hid/hclient/README.md b/hid/hclient/README.md index 192f4f90..5d925e46 100644 --- a/hid/hclient/README.md +++ b/hid/hclient/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: HClient sample application +description: Demonstrates how to write a user-mode client application that communicates with HID devices. +languages: + - cpp +products: + - windows +--- + - -HClient sample application -========================== +# HClient sample application The *HClient* sample demonstrates how to write a user-mode client application that communicates with HID devices. (These are devices that conform to the HID device class specification.) You will find this sample useful if you need to develop an application that communicates with, or extracts information from, a HID device. This sample illustrates a method for detecting a connected HID, opening that device for communication, and extracting or formatting the data into, or from, device reports. -Related topics --------------- +## Related topics [Human Input Devices Design Guide](http://msdn.microsoft.com/en-us/library/windows/hardware/ff539952) [Human Input Devices Reference](http://msdn.microsoft.com/en-us/library/windows/hardware/ff539956) - diff --git a/hid/hclient/hid-hclient.yml b/hid/hclient/hid-hclient.yml deleted file mode 100644 index 50177e19..00000000 --- a/hid/hclient/hid-hclient.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: HClient sample application - description: Demonstrates how to write a user-mode client application that communicates with HID devices. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /hid/hclient/hclient.sln diff --git a/hid/hidusbfx2/README.md b/hid/hidusbfx2/README.md index 20eb2001..f35b42b1 100644 --- a/hid/hidusbfx2/README.md +++ b/hid/hidusbfx2/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: HIDUSBFX2 sample driver +description: Demonstrates mapping of a non-HID USB device to a HID device. +languages: + - cpp +products: + - windows +--- + +# HIDUSBFX2 sample driver - -HIDUSBFX2 sample driver -======================= The HIDUSBFX2 sample driver (hidusbfx2.sys) demonstrates how to map a non-HID USB device to a HID device. The sample also demonstrates how to write a HID minidriver using Windows Driver Frameworks (WDF). The minidriver is written for the [OSR USB-FX2 Learning Kit](http://www.osronline.com/hardware/OSRFX2_32.pdf). Although the device is not HID-compliant, the sample exposes it as a HID device. diff --git a/hid/hidusbfx2/hid-hidusbfx2.yml b/hid/hidusbfx2/hid-hidusbfx2.yml deleted file mode 100644 index d47eb14c..00000000 --- a/hid/hidusbfx2/hid-hidusbfx2.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: HIDUSBFX2 sample driver - description: TBDemonstrates mapping of a non-HID USB device to a HID device.D - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /hid/hidusbfx2/hidusbfx2.sln diff --git a/hid/vhidmini2/README.md b/hid/vhidmini2/README.md index bd6ea894..beed5a28 100644 --- a/hid/vhidmini2/README.md +++ b/hid/vhidmini2/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: HID Minidriver Sample (UMDF version 2) +description: Demonstrates how to write a HID minidriver using User-Mode Driver Framework (UMDF). +languages: + - cpp +products: + - windows +--- + -HID Minidriver Sample (UMDF version 2) -====================================== +# HID Minidriver Sample (UMDF version 2) + The *HID minidriver* sample demonstrates how to write a HID minidriver using User-Mode Driver Framework (UMDF). -The sample demonstrates how to communicate with an HID minidriver from an HID client using a custom-feature item in order to control certain features of the HID minidriver. This is needed since other conventional modes for communicating with a driver, like custom IOCTL or WMI, do not work with the HID minidriver. The sample also is useful in testing the correctness of a HID report descriptor without using a physical device. +The sample demonstrates how to communicate with an HID minidriver from an HID client using a custom-feature item in order to control certain features of the HID minidriver. This is needed since other conventional modes for communicating with a driver, like custom IOCTL or WMI, do not work with the HID minidriver. The sample also is useful in testing the correctness of a HID report descriptor without using a physical device. - -Related topics --------------- +## Related topics [Creating UMDF-based HID Minidrivers](http://msdn.microsoft.com/en-us/library/windows/hardware/hh439579) @@ -24,4 +32,3 @@ Related topics [Human Input Devices Reference](http://msdn.microsoft.com/en-us/library/windows/hardware/ff539956) [UMDF HID Minidriver IOCTLs](http://msdn.microsoft.com/en-us/library/windows/hardware/hh463977) - diff --git a/hid/vhidmini2/hid-vhidmini2.yml b/hid/vhidmini2/hid-vhidmini2.yml deleted file mode 100644 index b85ad8aa..00000000 --- a/hid/vhidmini2/hid-vhidmini2.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: HID Minidriver Sample (UMDF version 2) - description: Demonstrates how to write a HID minidriver using User-Mode Driver Framework (UMDF). - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /hid/vhidmini2/vhidmini2.sln diff --git a/input/kbfiltr/README.md b/input/kbfiltr/README.md index f570c5cb..86996233 100644 --- a/input/kbfiltr/README.md +++ b/input/kbfiltr/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Keyboard Input WDF Filter Driver (Kbfiltr) +description: A WDF example of a keyboard input filter driver. +languages: + - cpp +products: + - windows +--- + - -Keyboard Input WDF Filter Driver (Kbfiltr) -========================================== +# Keyboard Input WDF Filter Driver (Kbfiltr) The Kbdfltr sample is an example of a keyboard input filter driver. @@ -23,6 +31,7 @@ This driver filters input for a particular keyboard on the system. If you want t `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96B-E325-11CE-BFC1-08002BE10318}\UpperFilters` ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. Set the hardware ID in the inx file @@ -110,4 +119,3 @@ Testing To use the test application provided with the sample, it must be copied to the target computer manually. Save the kbftest.exe file from the folder where the build result is placed (for example, exe\\Debug). This file is copied somewhere on the target, possibly where the driver package files are located. The test application is the executed on the target computer in a Command Prompt using **kbftest** as the command. **Tip** To avoid DLL dependencies for kbftext.exe, and the need to copy additional files, select the statically linked run-time library when building. - diff --git a/input/kbfiltr/input-kbfiltr.yml b/input/kbfiltr/input-kbfiltr.yml deleted file mode 100644 index 67f42ce3..00000000 --- a/input/kbfiltr/input-kbfiltr.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Keyboard Input WDF Filter Driver (Kbfiltr) - description: A WDF example of a keyboard input filter driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /input/kbfiltr/kbfiltr.sln diff --git a/input/layout/README.md b/input/layout/README.md index d998e379..4f0069db 100644 --- a/input/layout/README.md +++ b/input/layout/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Keyboard Layout Samples +description: Demonstrates how to generate layouts for various keyboards and locales. +languages: + - cpp +products: + - windows +--- + - -Keyboard Layout Samples -======================= +# Keyboard Layout Samples The keyboard layout samples demonstrate how to generate layouts for various keyboards and locales. @@ -89,4 +97,3 @@ Loading the Sample In order to load the layout DLLs, you may need to turn to the Regional and Language Options application in Control Panel and add input locales that use the keyboard layouts you installed. You may also choose to do it programmatically. LoadKeyboardLayout API can be used to load the keyboard layouts. To activate the keyboard layout, you may choose to specify KLF\_ACTIVATE flag to LoadKeyboardLayout API, or you may need to call ActivateKeyboardLayout API. - diff --git a/input/layout/input-layout.yml b/input/layout/input-layout.yml deleted file mode 100644 index 99199482..00000000 --- a/input/layout/input-layout.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Keyboard Layout Samples - description: Demonstrates how to generate layouts for various keyboards and locales. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /input/layout/kbd.sln diff --git a/input/moufiltr/README.md b/input/moufiltr/README.md index 6cf5c585..e8fe100f 100644 --- a/input/moufiltr/README.md +++ b/input/moufiltr/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Mouse Input WDF Filter Driver (Moufiltr) +description: A WDF example of a mouse input filter driver. +languages: + - cpp +products: + - windows +--- + +# Mouse Input WDF Filter Driver (Moufiltr) -Mouse Input WDF Filter Driver (Moufiltr) -======================================== The Moufiltr sample is an example of a mouse input filter driver. This sample is WDF version of the original WDM filter driver sample. The WDM version of this sample has been deprecated. @@ -17,14 +26,13 @@ This sample is WDF version of the original WDM filter driver sample. The WDM ver 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. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. -Installation ------------- +## Installation This sample is installed via an .inf file. The .inf file included in this sample is designed to filter a PS/2 mouse. 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. - diff --git a/input/moufiltr/input-moufiltr.yml b/input/moufiltr/input-moufiltr.yml deleted file mode 100644 index 900d70c3..00000000 --- a/input/moufiltr/input-moufiltr.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Mouse Input WDF Filter Driver (Moufiltr) - description: A WDF example of a mouse input filter driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /input/moufiltr/moufiltr.sln diff --git a/network/config/bindview/README.md b/network/config/bindview/README.md index b239b700..1f168493 100644 --- a/network/config/bindview/README.md +++ b/network/config/bindview/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Bindview Network Configuration Utility +description: An application that demonstrates how to use INetCfg APIs to enumerate, install, uninstall, bind and unbind network components. +languages: + - cpp +products: + - windows +--- + - -Bindview Network Configuration Utility -====================================== +# Bindview Network Configuration Utility The Bindview sample demonstrates how to use INetCfg APIs to enumerate, install, uninstall, bind and unbind network components. For more information on the INetCfg interface, see [Network Configuration Interfaces](http://msdn.microsoft.com/en-us/library/windows/hardware/ff559080). - diff --git a/network/config/bindview/network-config-bindview.yml b/network/config/bindview/network-config-bindview.yml deleted file mode 100644 index a43c64bf..00000000 --- a/network/config/bindview/network-config-bindview.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Bindview Network Configuration Utility - description: An application that demonstrates how to use INetCfg APIs to enumerate, install, uninstall, bind and unbind network components. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /network/config/bindview/bindview.sln diff --git a/network/modem/fakemodem/README.md b/network/modem/fakemodem/README.md index 3734a95a..b202d8a3 100644 --- a/network/modem/fakemodem/README.md +++ b/network/modem/fakemodem/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Fakemodem Driver +description: Demonstrates a simple controller-less modem driver. +languages: + - cpp +products: + - windows +--- + -Fakemodem Driver -================ +# Fakemodem Driver The Fakemodem 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.* ## Universal Windows Driver Compliant -This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. +This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. diff --git a/network/modem/fakemodem/network-modem-fakemodem.yml b/network/modem/fakemodem/network-modem-fakemodem.yml deleted file mode 100644 index ac15da5c..00000000 --- a/network/modem/fakemodem/network-modem-fakemodem.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Fakemodem Driver - description: Demonstrates a simple controller-less modem driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /network/modem/fakemodem/fakemodem.sln diff --git a/network/ndis/extension/README.md b/network/ndis/extension/README.md index df154559..ee57d16b 100644 --- a/network/ndis/extension/README.md +++ b/network/ndis/extension/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Hyper-V Extensible Switch extension filter driver +description: A base library used to implement a Hyper-V Extensible Switch extension filter driver. +languages: + - cpp +products: + - windows +--- + - -Hyper-V Extensible Switch extension filter driver -================================================= +# Hyper-V Extensible Switch extension filter driver This sample contains a base library used to implement a Hyper-V Extensible Switch extension filter driver. This sample also contains two different extension filter drivers that were developed by using the library. @@ -21,11 +29,8 @@ MsPassthroughExt is a basic filtering extension filter driver that is implemente MsForwardExt is a basic forwarding extension filter driver that is implemented by using *SxBase.lib*. MsForwardExt uses basic MAC forwarding and custom switch policy to allow sends from given MAC addresses. This forwarding sample implements Hybrid Forwarding, which means that the destination table is not populated by this sample if the packet is flagged as a Hyper-V Network Virtualization (HNV) packet. HNV flagged packets' destination tables are computed by the vSwitch HNV policies instead. If this extension filter driver is unconfigured, it will block sends from all VMs, but will maintain connectivity to the host. Each switch policy, which is defined in *MsForwardExtPolicy.mof*, is a MAC address. Applying a switch policy to MsForwardExt allows packets to be sent from the MAC address that is defined in the policy. - -Installation ------------- +## Installation Use the *install.cmd* script provided with each extension filter driver. The *install.cmd* uses **netcfg** to install the extension and **mofcomp** to register any required mof files. The PowerShell cmdlet *Enable-VmSwitchExtension* can then be used to enable the extension filter driver on a Hyper-V Extensible Switch. For more information on Hyper-V Extensible Switch extensions, see [Hyper-V Extensible Switch](http://msdn.microsoft.com/en-us/library/windows/hardware/hh598161). - diff --git a/network/ndis/extension/network-ndis-extension.yml b/network/ndis/extension/network-ndis-extension.yml deleted file mode 100644 index 0494f22b..00000000 --- a/network/ndis/extension/network-ndis-extension.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Hyper-V Extensible Switch extension filter driver - description: A base library used to implement a Hyper-V Extensible Switch extension filter driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /network/ndis/extension/extensions.sln diff --git a/network/ndis/filter/README.md b/network/ndis/filter/README.md index 274287bc..a5e41f19 100644 --- a/network/ndis/filter/README.md +++ b/network/ndis/filter/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: NDIS 6.0 Filter Driver +description: A pass-through NDIS 6 filter driver demonstrating the basic principles of an NDIS 6.0 Filter driver. +languages: + - cpp +products: + - windows +--- + - -NDIS 6.0 Filter Driver -====================== +# NDIS 6.0 Filter Driver The Ndislwf sample is a do-nothing pass-through NDIS 6 filter driver that demonstrates the basic principles underlying an NDIS 6.0 Filter driver. The sample replaces the NDIS 5 Sample Intermediate Driver (Passthru driver). Although this sample filter driver is installed as a modifying filter driver, it doesn't modify any packets; it only repackages and sends down all OID requests. You can modify this filter driver to change packets before passing them along. Or you can use the filter to originate new packets to send or receive. For example, the filter could encrypt/compress outgoing and decrypt/decompress incoming data. - For more information, see [NDIS Filter Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff565492) in the network devices design guide. diff --git a/network/ndis/filter/network-ndis-filter.yml b/network/ndis/filter/network-ndis-filter.yml deleted file mode 100644 index cef3ec90..00000000 --- a/network/ndis/filter/network-ndis-filter.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: NDIS 6.0 Filter Driver - description: A pass-through NDIS 6 filter driver demonstrating the basic principles of an NDIS 6.0 Filter driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /network/ndis/filter/filter.sln diff --git a/network/ndis/mux/README.md b/network/ndis/mux/README.md index cf9a112c..f9086d39 100644 --- a/network/ndis/mux/README.md +++ b/network/ndis/mux/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: NDIS MUX Intermediate Driver and Notify Object +description: An NDIS 6.0 driver that demonstrates the operation of an N:1 MUX driver. +languages: + - cpp +products: + - windows +--- + - -NDIS MUX Intermediate Driver and Notify Object -============================================== +# NDIS MUX Intermediate Driver and Notify Object The MUX Intermediate Miniport (IM) driver is an NDIS 6.0 driver that demonstrates the operation of an "N:1" MUX driver.The sample demonstrates creating 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. Included in the project is a sample Notify Object that 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, for example, 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. diff --git a/network/ndis/mux/network-ndis-mux.yml b/network/ndis/mux/network-ndis-mux.yml deleted file mode 100644 index d3dfdc31..00000000 --- a/network/ndis/mux/network-ndis-mux.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: NDIS MUX Intermediate Driver and Notify Object - description: An NDIS 6.0 driver that demonstrates the operation of an N:1 MUX driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /network/ndis/mux/mux.sln diff --git a/network/ndis/ndisprot/6x/README.md b/network/ndis/ndisprot/6x/README.md index 211a8721..31afd6b9 100644 --- a/network/ndis/ndisprot/6x/README.md +++ b/network/ndis/ndisprot/6x/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: NDIS Connection-less Protocol WDM Driver Sample +description: Demonstrates a connection-less NDIS 6.0 protocol WDM driver. +languages: + - cpp +products: + - windows +--- + - -NDIS Connection-less Protocol WDM Driver Sample -=============================================== +# NDIS Connection-less Protocol WDM Driver Sample This sample demonstrates a connection-less NDIS 6.0 protocol WDM driver. The driver supports sending and receiving raw Ethernet frames using `ReadFile`/`WriteFile` calls from user-mode. It only receives frames with a specific EtherType field. As an NDIS protocol, it illustrates how to establish and tear down bindings to Ethernet adapters, i.e. those that export medium type **NdisMedium802\_3**. It shows how to set a packet filter, send and receive data, and handle plug-and-play events. -### INSTALLATION +## Installation The driver is installed using the INF file ndisprot.inf, which is provided in the driver directory. In Network Connections UI, select an adapter and open **Properties.** @@ -21,7 +29,7 @@ Click **Install**, then **Protocol**, then **Add**, and then **Have disk**. Then Select **Sample NDIS Protocol Driver** and click **OK**. After installing the protocol, copy over the test application prottest.exe to a convenient location. Please note that the driver service has been set to manual start in the INF file. As a result, it doesn't get loaded automatically when you install. -### Usage +## Usage To start the driver, type **Net start ndisprot**. @@ -54,7 +62,7 @@ Use the **-e** option to enumerate all devices to which NDISPROT is bound: For more information, see [NDIS Protocol Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff566821) in the network devices design guide. -### File Manifest +## File Manifest File | Description -----|------------ @@ -69,5 +77,3 @@ ntdisp.c | NT Entry points and dispatch routines for NDISPROT protuser.h | IOCTL and associated structure definitions recv.c | NDIS protocol entry points for receiving data, and IRP_MJ_READ processing send.c | NDIS protocol routines for sending data, and IRP_MJ_WRITE processing - - diff --git a/network/ndis/ndisprot/6x/network-ndis-ndisprot-6x.yml b/network/ndis/ndisprot/6x/network-ndis-ndisprot-6x.yml deleted file mode 100644 index 657790e4..00000000 --- a/network/ndis/ndisprot/6x/network-ndis-ndisprot-6x.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: NDIS Connection-less Protocol WDM Driver Sample - description: Demonstrates a connection-less NDIS 6.0 protocol WDM driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /network/ndis/ndisprot/6x/ndisprot60.sln diff --git a/network/ndis/ndisprot_kmdf/README.md b/network/ndis/ndisprot_kmdf/README.md index 0f2ceb23..bbe1b812 100644 --- a/network/ndis/ndisprot_kmdf/README.md +++ b/network/ndis/ndisprot_kmdf/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Connection-less NDIS 6.0 Protocol KMDF Sample Driver +description: Demonstrates a connection-less NDIS 6.0 protocol KMDF driver. +languages: + - cpp +products: + - windows +--- + - -Connection-less NDIS 6.0 Protocol KMDF Sample Driver -==================================================== +# Connection-less NDIS 6.0 Protocol KMDF Sample Driver This sample demonstrates a connection-less NDIS 6.0 protocol KMDF driver. diff --git a/network/ndis/ndisprot_kmdf/network-ndis-ndisprot-kmdf.yml b/network/ndis/ndisprot_kmdf/network-ndis-ndisprot-kmdf.yml deleted file mode 100644 index 129a1693..00000000 --- a/network/ndis/ndisprot_kmdf/network-ndis-ndisprot-kmdf.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Connection-less NDIS 6.0 Protocol KMDF Sample Driver - description: Demonstrates a connection-less NDIS 6.0 protocol KMDF driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /network/ndis/ndisprot_kmdf/ndisprot_kmdf.sln diff --git a/network/ndis/netvmini/6x/README.md b/network/ndis/netvmini/6x/README.md index 023e1674..8235ee35 100644 --- a/network/ndis/netvmini/6x/README.md +++ b/network/ndis/netvmini/6x/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: NDIS Virtual Miniport Driver +description: Demonstrates the functionality of an NDIS miniport driver without requiring a physical network adapter. +languages: + - cpp +products: + - windows +--- + - -NDIS Virtual Miniport Driver -============================ +# NDIS Virtual Miniport Driver The NDIS Virtual Miniport Driver sample illustrates the functionality of an NDIS miniport driver without requiring a physical network adapter. @@ -22,4 +30,3 @@ To test the miniport driver, install more than one miniport driver instance. You **Note** This sample provides an example of minimal driver intended for education purposes. The driver and its sample test programs are not intended for use in a production environment. For more information on creating NDIS Miniport Drivers, see [NDIS Miniport Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff565949). - diff --git a/network/ndis/netvmini/6x/network-ndis-netvmini-6x.yml b/network/ndis/netvmini/6x/network-ndis-netvmini-6x.yml deleted file mode 100644 index 6cd74b8a..00000000 --- a/network/ndis/netvmini/6x/network-ndis-netvmini-6x.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: NDIS Virtual Miniport Driver - description: Demonstrates the functionality of an NDIS miniport driver without requiring a physical network adapter. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /network/ndis/netvmini/6x/netvmini.sln diff --git a/network/radio/HidSwitchDriverSample/README.md b/network/radio/HidSwitchDriverSample/README.md index 9726babf..05e394f4 100644 --- a/network/radio/HidSwitchDriverSample/README.md +++ b/network/radio/HidSwitchDriverSample/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Radio Switch Test Driver for OSR USB-FX2 Development Board +description: Demonstrates how to structure a HID driver for radio switches for the OSR USB-FX2 Development Board. +languages: + - cpp +products: + - windows +--- + - -Radio Switch Test Driver for OSR USB-FX2 Development Board -========================================================== +# Radio Switch Test Driver for OSR USB-FX2 Development Board This sample demonstrates how to structure a HID driver for radio switches for the OSR USB-FX2 Development Board. The hardware switch or button to control wireless transmission and the global software switch (Airplane mode switch) in the Radio Management User Interface must be synchronized. To ensure the hardware and software switches that control radio transmission are synchronized, the hardware switch or button must have a HID-compliant driver. -Switch Pack Mapping -------------------- +## Switch Pack Mapping ### Switch Mapping + 1 | 2 | 3 | 4 | 5 | 7 | 8 ---|---|---|---|---|---|--- Mode Select Bit 3 | Mode Select Bit 2 | Mode Select Bit 1 | - | - | - | Radio Switch -Testing -------- +## Testing ### Testing Modes The driver supports five modes representing the valid combinations of HID descriptors that we have defined for the USB forum. Modes are selected using switches 1, 2, and 3 on the switch pack. -### Switch Mapping +### Switch Mapping Modes 1 | 2 | 3 | Mode ---|---|---|----- @@ -43,7 +50,6 @@ The driver supports five modes representing the valid combinations of HID descri 1 | 1 | 0 | Mode 1 1 | 1 | 1 | Mode 1 - ### Mode 1 Radio Push Button In this mode the radio switch (switch 8 on the switch pack) represents a momentary push button. A HID report is generated when the switch transitions to the On state (switch down). @@ -63,4 +69,3 @@ In this mode the radio switch (switch 8 on the switch pack) represents an A-B sl ### Mode 5 LED only In this mode the radio switch (switch 8 on the switch pack) is ignored. The LED array will reflect the state of the Radio LED: either all on or all off (note that the top 2 LEDs never illuminate as these are not wired in). - diff --git a/network/radio/HidSwitchDriverSample/network-radio-hidswitchdriversample.yml b/network/radio/HidSwitchDriverSample/network-radio-hidswitchdriversample.yml deleted file mode 100644 index d106b9d1..00000000 --- a/network/radio/HidSwitchDriverSample/network-radio-hidswitchdriversample.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Radio Switch Test Driver for OSR USB-FX2 Development Board - description: Demonstrates how to structure a HID driver for radio switches for the OSR USB-FX2 Development Board. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /network/radio/HidSwitchDriverSample/HidSwitchDriverSample.sln diff --git a/network/radio/RadioManagerSample/README.md b/network/radio/RadioManagerSample/README.md index 3cac53e9..5822727f 100644 --- a/network/radio/RadioManagerSample/README.md +++ b/network/radio/RadioManagerSample/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Windows Radio Management Sample +description: Demonstrates how to structure a Radio Manager for use with the Windows Radio Management APIs. +languages: + - cpp +products: + - windows +--- + - -Windows Radio Management Sample -=============================== +# Windows Radio Management Sample The Radio Manager sample demonstrates how to structure a Radio Manager for use with the Windows Radio Management APIs. diff --git a/network/radio/RadioManagerSample/network-radio-radiomanagersample.yml b/network/radio/RadioManagerSample/network-radio-radiomanagersample.yml deleted file mode 100644 index 82a05e36..00000000 --- a/network/radio/RadioManagerSample/network-radio-radiomanagersample.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Windows Radio Management Sample - description: Demonstrates how to structure a Radio Manager for use with the Windows Radio Management APIs. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /network/radio/RadioManagerSample/RadioManagerSample.sln diff --git a/network/trans/WFPSampler/README.md b/network/trans/WFPSampler/README.md index 84621bcd..977d42db 100644 --- a/network/trans/WFPSampler/README.md +++ b/network/trans/WFPSampler/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Windows Filtering Platform Sample +description: A sample firewall that has a command-line interface which allows adding filters at various WFP layers. +languages: + - cpp +products: + - windows +--- + - -Windows Filtering Platform Sample -================================= +# Windows Filtering Platform Sample The WFPSampler sample driver is a sample firewall. It has a command-line interface which allows adding filters at various WFP layers with a wide variety of conditions. Additionally it exposes callout functions for injection, basic action, proxying, and stream inspection. diff --git a/network/trans/WFPSampler/network-trans-wfpsampler.yml b/network/trans/WFPSampler/network-trans-wfpsampler.yml deleted file mode 100644 index ad4e75d0..00000000 --- a/network/trans/WFPSampler/network-trans-wfpsampler.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Windows Filtering Platform Sample - description: A sample firewall that has a command-line interface which allows adding filters at various WFP layers. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /network/trans/WFPSampler/WFPSampler.sln diff --git a/network/trans/ddproxy/README.md b/network/trans/ddproxy/README.md index 45a122d9..7331a807 100644 --- a/network/trans/ddproxy/README.md +++ b/network/trans/ddproxy/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Windows Filtering Platform Packet Modification Sample +description: Demonstrates the packet modification capabilities of the Windows Filtering Platform (WFP). +languages: + - cpp +products: + - windows +--- + - -Windows Filtering Platform Packet Modification Sample -===================================================== +# Windows Filtering Platform Packet Modification Sample The sample driver demonstrates the packet modification capabilities of the Windows Filtering Platform (WFP). ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. Run the sample diff --git a/network/trans/ddproxy/network-trans-ddproxy.yml b/network/trans/ddproxy/network-trans-ddproxy.yml deleted file mode 100644 index 2ceb94a7..00000000 --- a/network/trans/ddproxy/network-trans-ddproxy.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Windows Filtering Platform Packet Modification Sample - description: Demonstrates the packet modification capabilities of the Windows Filtering Platform (WFP). - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /network/trans/ddproxy/ddproxy.sln diff --git a/network/trans/inspect/README.md b/network/trans/inspect/README.md index 2c197c4f..2bd8d98e 100644 --- a/network/trans/inspect/README.md +++ b/network/trans/inspect/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Windows Filtering Platform Traffic Inspection Sample +description: Demonstrates the traffic inspection capabilities of the Windows Filtering Platform (WFP). +languages: + - cpp +products: + - windows +--- + +# Windows Filtering Platform Traffic Inspection Sample -Windows Filtering Platform Traffic Inspection Sample -==================================================== This sample driver demonstrates the traffic inspection capabilities of the Windows Filtering Platform (WFP). @@ -22,6 +31,7 @@ Inspect.sys implements the `ClassifyFn` callout functions for the ALE Connect, R Connect/Packet inspection is done out-of-band by a system worker thread by using the reference-drop-clone-reinject mechanism as well as the ALE pend/complete mechanism. Therefore, the sample can serve as a basis for scenarios in which a filtering decision cannot be made within the `classifyFn()` callout and instead must be made, for example, by a user-mode application. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. Automatic deployment diff --git a/network/trans/inspect/network-trans-inspect.yml b/network/trans/inspect/network-trans-inspect.yml deleted file mode 100644 index 464fabdc..00000000 --- a/network/trans/inspect/network-trans-inspect.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Windows Filtering Platform Traffic Inspection Sample - description: Demonstrates the traffic inspection capabilities of the Windows Filtering Platform (WFP). - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /network/trans/inspect/inspect.sln diff --git a/network/trans/msnmntr/README.md b/network/trans/msnmntr/README.md index 14127cbc..bdb146de 100644 --- a/network/trans/msnmntr/README.md +++ b/network/trans/msnmntr/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Windows Filtering Platform MSN Messenger Monitor Sample +description: Demonstrates the stream inspection capabilities of the Windows Filtering Platform (WFP). +languages: + - cpp +products: + - windows +--- + - -Windows Filtering Platform MSN Messenger Monitor Sample -======================================================= +# Windows Filtering Platform MSN Messenger Monitor Sample This sample application and driver demonstrate the stream inspection capabilities of the Windows Filtering Platform (WFP). diff --git a/network/trans/msnmntr/network-trans-msnmntr.yml b/network/trans/msnmntr/network-trans-msnmntr.yml deleted file mode 100644 index 6c6cdde9..00000000 --- a/network/trans/msnmntr/network-trans-msnmntr.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Windows Filtering Platform MSN Messenger Monitor Sample - description: Demonstrates the stream inspection capabilities of the Windows Filtering Platform (WFP). - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /network/trans/msnmntr/msnmntr.sln diff --git a/network/trans/stmedit/README.md b/network/trans/stmedit/README.md index 67905639..936b122c 100644 --- a/network/trans/stmedit/README.md +++ b/network/trans/stmedit/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Windows Filtering Platform Stream Edit Sample +description: Demonstrates replacing a string pattern for a Transmission Control Protocol (TCP) connection using the Windows Filtering Platform (WFP). +languages: + - cpp +products: + - windows +--- + - -Windows Filtering Platform Stream Edit Sample -============================================= +# Windows Filtering Platform Stream Edit Sample This sample driver demonstrates replacing a string pattern for a Transmission Control Protocol (TCP) connection using the Windows Filtering Platform (WFP). ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. The sample consists of a kernel-mode Windows Filtering Platform (WFP) callout driver (Stmedit.sys) that can operate in one of the following modes: diff --git a/network/trans/stmedit/network-trans-stmedit.yml b/network/trans/stmedit/network-trans-stmedit.yml deleted file mode 100644 index c3101e05..00000000 --- a/network/trans/stmedit/network-trans-stmedit.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Windows Filtering Platform Stream Edit Sample - description: Demonstrates replacing a string pattern for a Transmission Control Protocol (TCP) connection using the Windows Filtering Platform (WFP). - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /network/trans/stmedit/stmedit.sln diff --git a/network/wlan/WDI/COMMON/ChannelInfo.c b/network/wlan/WDI/COMMON/ChannelInfo.c index 71ff6490..40ec119b 100644 --- a/network/wlan/WDI/COMMON/ChannelInfo.c +++ b/network/wlan/WDI/COMMON/ChannelInfo.c @@ -306,7 +306,7 @@ CHNL_ChangeBwChnlFromPeerWorkitemCallBack( if(pExtAdapter->bAPChannelInprogressForNewconnected) { RT_DISP(FCHNL, FCHNL_ERROR, ("%s: AP change channel in progress , return \n", __FUNCTION__)); - return; + return; } } diff --git a/network/wlan/WDI/COMMON/MgntActQueryParam.h b/network/wlan/WDI/COMMON/MgntActQueryParam.h index f5d11f9e..603a00ad 100644 --- a/network/wlan/WDI/COMMON/MgntActQueryParam.h +++ b/network/wlan/WDI/COMMON/MgntActQueryParam.h @@ -248,7 +248,7 @@ MgntActQuery_P2PChannelList( IN u4Byte ChannelListBufLen, OUT pu1Byte pChennelListLen, OUT pu1Byte pChannelList - ); + ); VOID MgntActQuery_P2PListenChannel( diff --git a/network/wlan/WDI/PLATFORM/NDIS6/N63C_Oids.c b/network/wlan/WDI/PLATFORM/NDIS6/N63C_Oids.c index 5812f010..263648b9 100644 --- a/network/wlan/WDI/PLATFORM/NDIS6/N63C_Oids.c +++ b/network/wlan/WDI/PLATFORM/NDIS6/N63C_Oids.c @@ -387,7 +387,7 @@ n63c_SendP2pRspActionFrameStateCb( if(N63C_P2P_ACTION_FRAME_GO_NEGOTIATION_CONFIRM == ctx->rspType) { n63c_IndicateRxP2pRspActionFrame(pAdapter, ctx); - } + } } else if(OFF_CHNL_TX_STATE_RETRY == state) @@ -427,7 +427,7 @@ n63c_SendP2pReqActionFrameStateCb( ) { n63c_IndicateRxP2pRspActionFrame(pAdapter, ctx); - } + } if(N63C_P2P_ACTION_FRAME_GO_NEGOTIATION_RESPONSE == ctx->rspType) diff --git a/network/wlan/WDI/PLATFORM/NDIS6/N63C_Oids.h b/network/wlan/WDI/PLATFORM/NDIS6/N63C_Oids.h index 39e4b17f..116c8bc8 100644 --- a/network/wlan/WDI/PLATFORM/NDIS6/N63C_Oids.h +++ b/network/wlan/WDI/PLATFORM/NDIS6/N63C_Oids.h @@ -23,7 +23,7 @@ typedef enum _P2P_ROLE P2P_ROLE, * PP2P_ROLE; // For resetting the Wifi-Direct port typedef enum _RESET_LEVEL -{ +{ RESET_LEVEL_P2P_ONLY = 0, RESET_LEVEL_FULL }RESET_LEVEL, * PRESET_LEVEL; diff --git a/network/wlan/WDI/README.md b/network/wlan/WDI/README.md index 414cf30c..21aa108a 100644 --- a/network/wlan/WDI/README.md +++ b/network/wlan/WDI/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: WDI samples +description: Demonstrates use of the WLAN WDI. +languages: + - cpp +products: + - windows +--- + # WDI samples + +This sample demonstrates use of the WLAN WDI. diff --git a/network/wlan/WDI/network-wlan-wdi.yml b/network/wlan/WDI/network-wlan-wdi.yml deleted file mode 100644 index 216f3449..00000000 --- a/network/wlan/WDI/network-wlan-wdi.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: WDI samples - description: WDI samples - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /network/wlan/WDI/windows.msbuild.rtwssample.sln diff --git a/network/wlan/ihvsampleui/README.md b/network/wlan/ihvsampleui/README.md index 957396ed..564b1199 100644 --- a/network/wlan/ihvsampleui/README.md +++ b/network/wlan/ihvsampleui/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: IHV Sample UI +description: Demonstrates the WLAN IHV UI. +languages: + - cpp +products: + - windows +--- + # IHV Sample UI + +This sample demonstrates the WLAN IHV UI. diff --git a/network/wlan/ihvsampleui/network-wlan-ihvsampleui.yml b/network/wlan/ihvsampleui/network-wlan-ihvsampleui.yml deleted file mode 100644 index eb043ec0..00000000 --- a/network/wlan/ihvsampleui/network-wlan-ihvsampleui.yml +++ /dev/null @@ -1,11 +0,0 @@ -### YamlMime:Sample -sample: -- name: IHV Sample UI - description: IHV Sample UI - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows diff --git a/network/wsk/echosrv/README.md b/network/wsk/echosrv/README.md index 96cc02d5..ee48299d 100644 --- a/network/wsk/echosrv/README.md +++ b/network/wsk/echosrv/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: WSK TCP Echo Server +description: A minimal sample driver to demonstrate the usage of the Winsock Kernel (WSK) programming interface. +languages: + - cpp +products: + - windows +--- + - -WSK TCP Echo Server -=================== +# WSK TCP Echo Server This sample driver is a minimal driver meant to demonstrate the usage of the Winsock Kernel (WSK) programming interface. diff --git a/network/wsk/echosrv/network-wsk-echosrv.yml b/network/wsk/echosrv/network-wsk-echosrv.yml deleted file mode 100644 index e0aa241f..00000000 --- a/network/wsk/echosrv/network-wsk-echosrv.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: WSK TCP Echo Server - description: A minimal sample driver to demonstrate the usage of the Winsock Kernel (WSK) programming interface. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /network/wsk/echosrv/echosrv.sln diff --git a/nfc/NfcCxSample/README.md b/nfc/NfcCxSample/README.md index fe2abbc8..165c97b4 100644 --- a/nfc/NfcCxSample/README.md +++ b/nfc/NfcCxSample/README.md @@ -2,15 +2,10 @@ topic: sample name: NFC CX client driver sample description: Sample code for creating a NFC driver using the NFC Class Extension. -generateZip: true -author: windows-driver-content languages: -- cpp + - cpp products: -- windows -technologies: -- WDF -- UMDF2 + - windows --- # NFC CX client driver sample diff --git a/nfp/net/inc/README.md b/nfp/net/inc/README.md new file mode 100644 index 00000000..6e261d3f --- /dev/null +++ b/nfp/net/inc/README.md @@ -0,0 +1,28 @@ +--- +topic: sample +name: Near-Field Proximity Sample Driver (UMDF Version 1) +description: Demonstrates how to use UMDF version 1 to write a near-field proximity driver. +languages: + - cpp +products: + - windows +--- + + + +# Near-Field Proximity Sample Driver (UMDF Version 1) + +This sample demonstrates how to use User-Mode Driver Framework (UMDF) version 1 to write a near-field proximity driver. + +Typically, a near-field proximity driver would use near-field technologies such as Near Field Communication (NFC), TransferJet, or Bump. However, this sample uses a TCP/IPv6 network connection and a static configuration between two machines to simulate near-field interaction. + +## Related technologies + +[User-Mode Driver Framework](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560456) diff --git a/nfp/net/nfp-net.yml b/nfp/net/nfp-net.yml deleted file mode 100644 index 04291841..00000000 --- a/nfp/net/nfp-net.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Near-Field Proximity Sample Driver (UMDF Version 1) - description: Demonstrates how to use UMDF version 1 to write a near-field proximity driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /nfp/net/netnfp.sln diff --git a/pofx/PEP/README.md b/pofx/PEP/README.md index 079dbec6..da0082ca 100644 --- a/pofx/PEP/README.md +++ b/pofx/PEP/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Power Engine Plugin (PEP) ACPI Sample +description: Demonstrates an interface which allows PEP to implement ACPI runtime methods natively via a driver. +languages: + - cpp +products: + - windows +--- + - -PEP ACPI Sample -=============== +# PEP ACPI Sample The Power Engine Plugin (PEP) provides interfaces for platform power management including device power management (DPM), processor power management (PPM), and, starting with Windows 10, ACPI runtime methods. This sample documents the latter: an interface which allows a PEP to implement ACPI runtime methods natively via a Windows driver rather than firmware (AML). A PEP using the ACPI interface is often called a Platform Extension. Note that this interface can be used independently or in conjunction with the DPM and/or PPM interfaces as appropriate. Use the PEP ACPI interface if: + * You want to write peripheral (off-SoC) device power management in C rather than in ACPI Source Language (ASL). -* You need to override an ACPI method which exists in a platform's DSDT or SSDT firmware tables. -* Shipping, maintaining, and updating a driver binary suits your platform better than firmware updates (note you'll still need FADT, MADT, DBG2, etc. in firmware - this interface is only for runtime methods). +* You need to override an ACPI method which exists in a platform's DSDT or SSDT firmware tables. +* Shipping, maintaining, and updating a driver binary suits your platform better than firmware updates (note that you will still need FADT, MADT, DBG2, and so on in firmware - this interface is only for runtime methods). diff --git a/pofx/PEP/pofx-pep.yml b/pofx/PEP/pofx-pep.yml deleted file mode 100644 index fefc0757..00000000 --- a/pofx/PEP/pofx-pep.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Power Engine Plugin (PEP) ACPI Sample - description: Demonstrates an interface which allows PEP to implement ACPI runtime methods natively via a driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /pofx/PEP/pepsamples.sln diff --git a/pofx/UMDF2/README.md b/pofx/UMDF2/README.md index 78cf1f40..8810bb7c 100644 --- a/pofx/UMDF2/README.md +++ b/pofx/UMDF2/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Power Framework (PoFx) Sample (UMDF Version 2) +description: Demonstrates how a UMDF version 2 driver can implement F-state-based power management. +languages: + - cpp +products: + - windows +--- + - -Power Framework (PoFx) Sample (UMDF Version 2) -============================================== +# Power Framework (PoFx) Sample (UMDF Version 2) This solution demonstrates how a User-Mode Driver Framework (UMDF) version 2 driver can implement F-state-based power management. The SingleComp project demonstrates how a UMDF version 2 driver can implement F-state-based power management for a device that has only a single component. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. Related technologies @@ -60,4 +69,3 @@ As an alternative to building the driver sample in Visual Studio, you can build **msbuild /p:configuration="Release" /p:platform="Win32" PoFx.sln** For more information about using MSBuild to build a driver package, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644). - diff --git a/pofx/UMDF2/pofx-umdf2.yml b/pofx/UMDF2/pofx-umdf2.yml deleted file mode 100644 index 0d981467..00000000 --- a/pofx/UMDF2/pofx-umdf2.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Power Framework (PoFx) Sample (UMDF Version 2) - description: Demonstrates how a UMDF version 2 driver can implement F-state-based power management. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /pofx/UMDF2/pofx.sln diff --git a/pofx/WDF/README.md b/pofx/WDF/README.md index 7915dbd7..d3f37f84 100644 --- a/pofx/WDF/README.md +++ b/pofx/WDF/README.md @@ -1,3 +1,16 @@ +--- +topic: sample +name: KMDF Power Framework (PoFx) Sample +description: Demonstrate how a KMDF driver can implement F-state-based power management. + + + +languages: + - cpp +products: + - windows +--- + - -KMDF Power Framework (PoFx) Sample -================================== +# KMDF Power Framework (PoFx) Sample This solution consists of two samples that demonstrate how a KMDF driver can implement F-state-based power management. The SingleComp sample demonstrates how a KMDF driver can implement F-state-based power management for a device that has only a single component. The MultiComp sample demonstrates how a KMDF driver can implement F-state-based power management for a device that has an arbitrary number of components that can be individually power-managed. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. Related technologies diff --git a/pofx/WDF/pofx-wdf.yml b/pofx/WDF/pofx-wdf.yml deleted file mode 100644 index 9e048157..00000000 --- a/pofx/WDF/pofx-wdf.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: KMDF Power Framework (PoFx) Sample - description: Demonstrate how a KMDF driver can implement F-state-based power management. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /pofx/WDF/pofx.sln diff --git a/pos/drivers/MagneticStripeReader/README.md b/pos/drivers/MagneticStripeReader/README.md index 4e8d8088..ec9ae3af 100644 --- a/pos/drivers/MagneticStripeReader/README.md +++ b/pos/drivers/MagneticStripeReader/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Magnetic Stripe Reader Driver Sample +description: This UMDF version 2 sample serves as a template for creating a new Magnetic Stripe Reader driver. +languages: + - cpp +products: + - windows +--- + +# Magnetic Stripe Reader Driver Sample -Magnetic Stripe Reader Driver Sample -==================================== This sample serves as a template for creating a new Magnetic Stripe Reader driver. This sample uses UMDF 2.0 and enables basic functionality such as claiming and enabling the device for exclusive access. -It serves as an example of how to include the libraries necessary to develop a PointOfService driver. Once a driver is developed using this template it can be compiled for, deployed, and used on x86, amd64, and ARM platforms. \ No newline at end of file +It serves as an example of how to include the libraries necessary to develop a PointOfService driver. Once a driver is developed using this template it can be compiled for, deployed, and used on x86, amd64, and ARM platforms. diff --git a/pos/drivers/MagneticStripeReader/pos-drivers-magneticstripereader.yml b/pos/drivers/MagneticStripeReader/pos-drivers-magneticstripereader.yml deleted file mode 100644 index de4c8a60..00000000 --- a/pos/drivers/MagneticStripeReader/pos-drivers-magneticstripereader.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Magnetic Stripe Reader Driver Sample - description: This UMDF version 2 sample serves as a template for creating a new Magnetic Stripe Reader driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /pos/drivers/MagneticStripeReader/MagneticStripeReader.sln diff --git a/pos/drivers/barcodescanner/README.md b/pos/drivers/barcodescanner/README.md index f6d7926b..70181312 100644 --- a/pos/drivers/barcodescanner/README.md +++ b/pos/drivers/barcodescanner/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Barcode Scanner Driver Sample +description: This UDMF version 2 sample serves as a template for creating a new Barcode Scanner driver. +languages: + - cpp +products: + - windows +--- + +# Barcode Scanner Driver Sample -Barcode Scanner Driver Sample -==================================== This sample serves as a template for creating a new Barcode Scanner driver. This sample uses UMDF 2.0 and enables basic functionality such as claiming and enabling the device for exclusive access. -It serves as an example of how to include the libraries necessary to develop a PointOfService driver. Once a driver is developed using this template it can be compiled for, deployed, and used on x86, amd64, and ARM platforms. \ No newline at end of file +It serves as an example of how to include the libraries necessary to develop a PointOfService driver. Once a driver is developed using this template it can be compiled for, deployed, and used on x86, amd64, and ARM platforms. diff --git a/pos/drivers/barcodescanner/pos-drivers-barcodescanner.yml b/pos/drivers/barcodescanner/pos-drivers-barcodescanner.yml deleted file mode 100644 index b51c7aef..00000000 --- a/pos/drivers/barcodescanner/pos-drivers-barcodescanner.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Barcode Scanner Driver Sample - description: This UDMF version 2 sample serves as a template for creating a new Barcode Scanner driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /pos/drivers/barcodescanner/BarcodeScanner.sln diff --git a/print/OEM Printer Customization Plug-in Samples/README.md b/print/OEM Printer Customization Plug-in Samples/README.md index aa686ea6..864864a4 100644 --- a/print/OEM Printer Customization Plug-in Samples/README.md +++ b/print/OEM Printer Customization Plug-in Samples/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: OEM Printer Customization Plug-in Samples +description: Provides examples of how to build OEM printer customization plug-ins. +languages: + - cpp +products: + - windows +--- + - -OpenXPS Documents Print Sample -============================== +# OpenXPS Documents Print Sample This sample contains a set of documents that were generated from a variety of sources, including those generated from the Windows Presentation Foundation in the .NET Framework, from Office 2007, and from the Microsoft XPS Document Writer (MXDW). A few of the documents were either hand-built from scratch or hand-modified from another source. They have been included to provide you with a few documents that exercise a variety of features of the XML Paper Specification. diff --git a/print/SampleOpenXPS/print-sampleopenxps.yml b/print/SampleOpenXPS/print-sampleopenxps.yml deleted file mode 100644 index 4c4a323d..00000000 --- a/print/SampleOpenXPS/print-sampleopenxps.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: OpenXPS Documents Print Sample - description: Contains a set of documents that exercise a variety of features of OpenXPS. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /print/SampleOpenXPS/SampleOpenXPS.sln diff --git a/print/SampleXPS/README.md b/print/SampleXPS/README.md index b1c39d3e..d0415a63 100644 --- a/print/SampleXPS/README.md +++ b/print/SampleXPS/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: XPS Documents Print Sample +description: Contains a set of documents that exercise a variety of features of the XML Paper Specification. +languages: + - cpp +products: + - windows +--- + - -XPS Documents Print Sample -========================== +# XPS Documents Print Sample This sample is a set of documents that were generated from a variety of sources, including those generated from the Windows Presentation Foundation in the .NET Framework, from Office 2007, and from the Microsoft XPS Document Writer (MXDW). The set of documents also includes documents that were either hand-built from scratch or hand-modified from another source. They have been included to provide you with a few documents that exercise a variety of features of the XML Paper Specification. In addition, a few high-quality documents have been provided in the Showcase directory to highlight some of the XPS advantages in terms of screen-to-print fidelity. There are also some documents that are intended to fail by violating at least one conformance rule. These are in the ConformanceViolations directory. For information about XPS in Windows, see [XPS Printing Features](http://msdn.microsoft.com/en-us/library/windows/hardware/ff564299(v=vs.85).aspx). - diff --git a/print/SampleXPS/print-samplexps.yml b/print/SampleXPS/print-samplexps.yml deleted file mode 100644 index 610c0d84..00000000 --- a/print/SampleXPS/print-samplexps.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: XPS Documents Print Sample - description: Contains a set of documents that exercise a variety of features of the XML Paper Specification. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /print/SampleXPS/SampleXPS.sln diff --git a/print/SimplePipelineFilter/README.md b/print/SimplePipelineFilter/README.md index c7a92e48..323072a7 100644 --- a/print/SimplePipelineFilter/README.md +++ b/print/SimplePipelineFilter/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Print Pipeline Simple Filter +description: This sample shows how to use the print pipeline's filter interfaces. +languages: + - cpp +products: + - windows +--- + - -Print Pipeline Simple Filter -============================ +# Print Pipeline Simple Filter The printing system supports a print filter pipeline. The pipeline is run when a print job is consumed by the print spooler and sent to the device. This sample shows how to use the print pipeline's filter interfaces. The filters in the print pipeline consume a certain data type and produce a certain data type. This information is specified in the pipeline configuration file on a per printer driver basis. The WDK print filter sample contains two filter samples: one that consumes and produces XPS data type, and the other one consumes and produces opaque byte stream. For more information, see the [XpsDrv](http://msdn.microsoft.com/en-us/windows/hardware/gg463364) whitepaper. - diff --git a/print/SimplePipelineFilter/print-simplepipelinefilter.yml b/print/SimplePipelineFilter/print-simplepipelinefilter.yml deleted file mode 100644 index 48f292df..00000000 --- a/print/SimplePipelineFilter/print-simplepipelinefilter.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Print Pipeline Simple Filter - description: This sample shows how to use the print pipeline's filter interfaces. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /print/SimplePipelineFilter/SimplePipelineFilter.sln diff --git a/print/XPSDrvSmpl/README.md b/print/XPSDrvSmpl/README.md index 1d1eb790..2088900a 100644 --- a/print/XPSDrvSmpl/README.md +++ b/print/XPSDrvSmpl/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: XPSDrv Driver and Filter Sample +description: Provide a starting point for developing XPSDrv printer drivers and to illustrate the facility and potential of an XPSDrv print driver. +languages: + - cpp +products: + - windows +--- + - -XPSDrv Driver and Filter Sample -=============================== +# XPSDrv Driver and Filter Sample This sample is intended to provide a starting point for developing XPSDrv printer drivers and to illustrate the facility and potential of an XPSDrv print driver. This goal is accomplished by implementing a number of real-world features within a set of XPS print pipeline filters that are configured through a configuration plug-in that supports custom UI content and PrintTicket handling. @@ -19,44 +27,41 @@ This sample is intended to provide a starting point for developing XPSDrv printe The sample broadly consists of three components: a set of filters, a configuration plug-in for handling custom UI content, and a configuration plug-in for handling more advanced PrintTicket features. For more information, see [XPS Printing Features](https://docs.microsoft.com/en-us/windows-hardware/drivers/print/xps-printing-features). - -Build the sample ----------------- +## Build the sample To build a driver solution using Windows Driver Kit (WDK) 10 and Visual Studio 2017, perform the following steps. 1. Open the solution file in Visual Studio 2017. -2. Add all non-binary files (usually located in the \\install directory of the sample) to the Package project: +1. Add all non-binary files (usually located in the \\install directory of the sample) to the Package project: 1. In the **Solution Explorer**, expand the **package** project and right click **Driver Files** - 2. Select **Add**, then click **Existing Item** - 3. Navigate to the location to which you downloaded the sample, and select all the files in the **install** directory, or the equivalent set of non-binary files such as INFs, INIs, GPD, PPD files, etc. - 4. Click **Add** -3. Configure these files to be added into the driver package: + 1. Select **Add**, then click **Existing Item** + 1. Navigate to the location to which you downloaded the sample, and select all the files in the **install** directory, or the equivalent set of non-binary files such as INFs, INIs, GPD, PPD files, etc. + 1. Click **Add** +1. Configure these files to be added into the driver package: 1. In the **Solution Explorer**, right click on the solution and choose **Add** > **New Project**. Choose **Driver Install Package** under Visual C++/Windows Driver/Package. - 2. In the **Solution Explorer**, right click the **Driver Package** project and select **Properties**. - 3. In the left pane, click **Configuration Properties** \> **Driver Install** \> **Package Files**. (If **Package Files** is not available, you may need to re-install the **Windows Driver Kit**.) - 4. In the right pane, click **** and use the ellipsis button (...) to browse to the set of files that needs to be added to the driver package. All of the data files added in **Step 2.iii**, except the INF file, should be added. This configuration is per architecture, so this configuration must be repeated for each architecture that will be built. - 5. Click **OK**. -4. Add a reference to the driver package. + 1. In the **Solution Explorer**, right click the **Driver Package** project and select **Properties**. + 1. In the left pane, click **Configuration Properties** \> **Driver Install** \> **Package Files**. (If **Package Files** is not available, you may need to re-install the **Windows Driver Kit**.) + 1. In the right pane, click **** and use the ellipsis button (...) to browse to the set of files that needs to be added to the driver package. All of the data files added in **Step 2.iii**, except the INF file, should be added. This configuration is per architecture, so this configuration must be repeated for each architecture that will be built. + 1. Click **OK**. +1. Add a reference to the driver package. 1. In the **Solution Explorer**, right click the **package** project and select **Add Reference**. - 2. In the right pane, check the **Driver Package** created in step 3. - 3. Click **OK**. -5. Open the INF file and edit it to match the built output. + 1. In the right pane, check the **Driver Package** created in step 3. + 1. Click **OK**. +1. Open the INF file and edit it to match the built output. 1. Open the INF file. - 2. In the Version section, add a reference to a catalog file like this: CatalogFile=XpsDrvSmpl.cat. - 3. In the SourceDisksFiles section, change the location of the DLL files you are building to =1. This indicates that there is no architecture specific directory in this driver. If you ship multiple architectures simultaneously, you will need to collate the driver INF manually. + 1. In the Version section, add a reference to a catalog file like this: CatalogFile=XpsDrvSmpl.cat. + 1. In the SourceDisksFiles section, change the location of the DLL files you are building to =1. This indicates that there is no architecture specific directory in this driver. If you ship multiple architectures simultaneously, you will need to collate the driver INF manually. At this point, Visual Studio 2017 will be able to build a driver package and output the files to disk. In order to configure driver signing and deployment, see [Developing, Testing, and Deploying Drivers](https://docs.microsoft.com/en-us/windows-hardware/drivers/develop/). **Note** If you compile your sample driver with Microsoft Visual Studio version 10, or 11 with the \_DEBUG flag set, then you should not use CComVariant on the following two XPS Print Filter Pipeline properties: -- XPS\_FP\_USER\_TOKEN -- XPS\_FP\_PRINTER\_HANDLE +- XPS\_FP\_USER\_TOKEN +- XPS\_FP\_PRINTER\_HANDLE There is a known issue with the current implementation of the Print Filter Pipeline, where the variant type for these two properties is set to VT\_BYREF. And as a result of this known issue, any filter binary that is compiled with the \_DEBUG flag set will experience the ATLASSERT() failure. This is because when you use the CComVariant, its destructor checks the returned value from the Clear() function, as shown: - -```c_cpp +```cpp ~CComVariant() throw() { HRESULT hr = Clear(); @@ -67,18 +72,16 @@ There is a known issue with the current implementation of the Print Filter Pipel When you compile this sample driver with Visual Studio version 9, you don't experience this problem because the destructor for CComVariant doesn't perform this check on the returned value from the Clear() function. -Installation ------------- +## Installation The sample has the following prerequisites: -- Microsoft XPS Document Writer print driver and the XPS filter-pipeline infrastructure. -- Microsoft MSXML 6.0 +- Microsoft XPS Document Writer print driver and the XPS filter-pipeline infrastructure. +- Microsoft MSXML 6.0 Install the driver through the **Add Printer Wizard** by selecting \\\install as the source for the driver install. -Design and Operation --------------------- +## Design and Operation ### Overview @@ -88,9 +91,9 @@ The Page Scaling filter is written by using the stream interface to attempt to d Two interfaces are defined in *ipkarch.h* and *ipkfile.h* that need support from an additional PK archive handling module called pkarch.dll. Pkarch.dll is a file that is included in the [PKWare SDK](http://www.pkware.com/software/developer-tools/sdk/pkzip-standard-toolkit). If this module is not present, the page scaling filter sample will revert to merely copying the data from the read stream to the write stream. Developers who are using this sample can choose one of the following options: -- Simplify the scaling filter to use the XPS interfaces (like the other four filters) -- License the third-party zip library that is used in the sample -- Modify the sample to use another ZIP library. For example, you can modify the sample to use the [Packaging API Reference](https://docs.microsoft.com/en-us/previous-versions/windows/desktop/opc/packaging-programming-reference) +- Simplify the scaling filter to use the XPS interfaces (like the other four filters) +- License the third-party zip library that is used in the sample +- Modify the sample to use another ZIP library. For example, you can modify the sample to use the [Packaging API Reference](https://docs.microsoft.com/en-us/previous-versions/windows/desktop/opc/packaging-programming-reference) IPKArch defines an interface for initializing, controlling, and accessing the PK archive. IPKFile defines an interface that abstracts the details of a PK archive file header record from the XPS container handling. Access to the files within the archive is provided through a map between the file name and file objects that support the IPKFile interface. This allows the XPS processing code to retrieve file data by name (a convenience as the interaction between parts and relationships between parts is defined using the part name). @@ -100,10 +103,10 @@ There are five filters that are split into two types: four use the XPS filter in The four filters that use the XPS interface provide support for the following: -- The Watermark Filter is responsible for adding mark-up to Fixed Page content to express textual, bitmap, and vector-based watermarks. -- The Booklet Filter is responsible for page re-ordering and padding page insertion to create booklets from the XPS document. Note that this filter re-uses the NUp filter to provide appropriate page transformation. -- The NUp Filter is responsible for transforming and combining logical pages onto physical pages to provide multiple page per sheet support. -- The Color Management Filter is responsible for constructing and applying color transforms to Fixed Page content. +- The Watermark Filter is responsible for adding mark-up to Fixed Page content to express textual, bitmap, and vector-based watermarks. +- The Booklet Filter is responsible for page re-ordering and padding page insertion to create booklets from the XPS document. Note that this filter re-uses the NUp filter to provide appropriate page transformation. +- The NUp Filter is responsible for transforming and combining logical pages onto physical pages to provide multiple page per sheet support. +- The Color Management Filter is responsible for constructing and applying color transforms to Fixed Page content. The stream interface filter provides Page Scaling support (that is, wrapping content with the appropriate transforms to scale from a source Fixed Page to the destination). @@ -139,9 +142,9 @@ The Watermark filter is intended to demonstrate adding presentation content to t The filter is configured by parsing an input PrintTicket by using DOM to extract the relevant features and options. If the functionality is enabled, the filter processes the document as required. The PrintTicket is constructed through the following algorithm to provide settings at the appropriate scope (Fixed Document Sequence, Fixed Document and Fixed Page): -1. Validate and merge the print ticket from the FDS with the default PrintTicket converted from the default DevMode in the property bag. The resultant ticket will be the Job level ticket. -2. Validate and merge the print ticket from the current FD with the Job level ticket from step 1. The resultant ticket will be the document level ticket. -3. Validate and merge the print ticket from the current FP with the Doc level ticket from step 2. The resultant ticket will be the page level ticket. +1. Validate and merge the print ticket from the FDS with the default PrintTicket converted from the default DevMode in the property bag. The resultant ticket will be the Job level ticket. +1. Validate and merge the print ticket from the current FD with the Job level ticket from step 1. The resultant ticket will be the document level ticket. +1. Validate and merge the print ticket from the current FP with the Doc level ticket from step 2. The resultant ticket will be the page level ticket. When a watermark is enabled in the PrintTicket, the filter creates a watermark of the appropriate type (text, raster, or vector). This is returned as a generic watermark interface that abstracts the watermark type from the filter. The filter then calls the watermark object to send any resources that it may require to the filter pipeline (the font for text, the bitmap for raster, and none for vector). All resources are added through a resource cache that enables the watermark object to ignore any problems with sending repeated resources (the cache checks if the resource is present and only sends it if it has not seen the resource before). With the resource in place, the filter instantiates a SAX handler passing the watermark object. The SAX handler is used to parse the Fixed Page, allowing the filter to control when it inserts the watermark into the Fixed Page; when underlay is required, the mark-up is inserted when the FixedPage start element is encountered and when overlay is required the mark-up is inserted when FixedPage end element is encountered. By passing the abstracted watermark object, the SAX handler can be re-used for any watermark as it merely requests appropriate mark-up from the watermark object and inserts it into the Fixed Page mark-up as appropriate. @@ -149,16 +152,16 @@ When a watermark is enabled in the PrintTicket, the filter creates a watermark o XPS documents can contain a range of vector elements that contain color data that describes how the elements should be rendered on a specific device. The following elements support color data: -- Color -- Fill -- Stroke +- Color +- Fill +- Stroke When any of these elements are found in a fixed page, the SAX handler passes the associated color data to a color conversion object. This uses the following algorithm to convert the color: -1. The XML mark-up is broken down into color channel values, color channel value types, color format, and any other color details contained in the color mark-up string. -2. The resulting values are color transformed in conjunction with preferences defined in the PrintTicket. The result is a new set of color values. -3. These new values are used to reconstructs a color reference containing the new color values. -4. The newly constructed color reference is used in place of the original color reference, resulting in the transformed color output. +1. The XML mark-up is broken down into color channel values, color channel value types, color format, and any other color details contained in the color mark-up string. +1. The resulting values are color transformed in conjunction with preferences defined in the PrintTicket. The result is a new set of color values. +1. These new values are used to reconstructs a color reference containing the new color values. +1. The newly constructed color reference is used in place of the original color reference, resulting in the transformed color output. ### Bitmap Resources @@ -170,11 +173,11 @@ After the color managed bitmap object is created, the object is passed to a reso If a bitmap has not been handled yet, the caching manager calls a write data method in the color bitmap object to indicate that the bitmap should write itself out to the filter pipeline. The write process also includes the application of a color transform to the bitmap. The following steps occur to apply the transform: -1. A stream is created to the bitmap itself and the bitmap is loaded into memory. -2. A bitmap codec object is created that takes the bitmap and uses an appropriate codec to decompress the bitmap and present the bitmap data and values. -3. The bitmap data is then converted by using a color transform supplied by the color profile management class. -4. The bitmap codec object re-encodes the bitmap by using a matching codec to that used to decode the bitmap. -5. The encoded bitmap is streamed back out to the container. +1. A stream is created to the bitmap itself and the bitmap is loaded into memory. +1. A bitmap codec object is created that takes the bitmap and uses an appropriate codec to decompress the bitmap and present the bitmap data and values. +1. The bitmap data is then converted by using a color transform supplied by the color profile management class. +1. The bitmap codec object re-encodes the bitmap by using a matching codec to that used to decode the bitmap. +1. The encoded bitmap is streamed back out to the container. ### Booklet Filter @@ -196,58 +199,53 @@ New canvases are added to the new fixed page mark-up until the document contains In addition to the NUp feature processing, the NUp filter is re-used to apply the 2-Up processing required for booklet printing. This is achieved by looking for a valid binding option in the PrintTicket and applying 2-Up as appropriate. -Page Scaling Filter -------------------- +## Page Scaling Filter The page scaling filter is intended to demonstrate how a filter can transform vector mark-up within a XPS container by using the stream interface as the source of the XPS document. The PrintTicket can contain page scaling preferences that the filter uses to amend page dimension values in each fixed page processed. Within the filter, SAX is used to parse the XPS container with each fixed page being read, amended, and written back out. The modification of the fixed page mark-up begins by modifying the fixed page dimensions to match the target page size specified in the print ticket for the current fixed page. Subsequently, the fixed page content is scaled to correctly fit the target scale by applying a canvas around the source content that includes a transformation matrix. The SAX handler is supported by a page scale class which manages the creation of a transformation matrix and the presentation of the matrix correctly formatted for use in the fixed page. -XPS Container Handling ----------------------- +## XPS Container Handling The stream filter is required to handle the Open Packaging conventions that are used by an XPS document. These conventions can be thought of as the document structure above that of the PK archive itself. Sources for a set of classes are provided that support processing of the XPS document in terms of the constituent files in the PK archive. This includes: -- Initiating the document processing based on the root relationships part defined in the package. -- Validation of the parts within the package against their content type and usage. -- Processing of Fixed Document Sequence and all resources associated with it. -- Processing of the Fixed Documents within the Fixed Document Sequence and all resources associated with them. -- Processing of the Fixed Page parts with the Fixed Documents and all resources associated with them. -- Passing Fixed Page content processing to a registered FP handler for modification. -- Passing all parts on to a PK archive handling module with valid ordering. +- Initiating the document processing based on the root relationships part defined in the package. +- Validation of the parts within the package against their content type and usage. +- Processing of Fixed Document Sequence and all resources associated with it. +- Processing of the Fixed Documents within the Fixed Document Sequence and all resources associated with them. +- Processing of the Fixed Page parts with the Fixed Documents and all resources associated with them. +- Passing Fixed Page content processing to a registered FP handler for modification. +- Passing all parts on to a PK archive handling module with valid ordering. The XPS processor is not responsible for extracting or decompressing part data from the PK archive. This task is the responsibility of an additional module that implements an interface known to the XPS container handling code. -UI Plug-in ----------- +## UI Plug-in details The UI Plug-in is intended to demonstrate how to extend the standard Unidrv UI to add additional property sheets and controls and to provide support for custom features that are not supported by the core Unidrv UI. Three new pages have been added that allow control of the sample filters: -- Color--enables configuration of the color conversion filter. -- Watermarks--enables a watermark to be selected and enable configuration of its properties for use in the watermark filter. -- Features--includes controls to configure the page scaling, booklet, and NUp filters. In addition, the standard driver settings--duplex, intent, and page borders--can also be modified. +- Color--enables configuration of the color conversion filter. +- Watermarks--enables a watermark to be selected and enable configuration of its properties for use in the watermark filter. +- Features--includes controls to configure the page scaling, booklet, and NUp filters. In addition, the standard driver settings--duplex, intent, and page borders--can also be modified. Various UI control types have been implemented on these property pages to enable a user to modify settings in the driver. The UI supports the following control types: -- Check-box -- Combo-box -- List-Box -- Edit-Box -- Edit number (with buddy up/down control) +- Check-box +- Combo-box +- List-Box +- Edit-Box +- Edit number (with buddy up/down control) The settings that associated with each of these controls are stored as one the following types: -- GPD options. These settings are defined in the sample driver GPD configuration file and are handled by the Unidrv core via the CPSUI interface. All GPD options that are managed from the UI plug-in are hidden from the standard Unidrv Treeview dialog box. -- OEM private DevMode. These settings are settings that cannot be represented in the GPD file format (for example, numerical values and strings). They are instead added to the DevMode at a private offset. +- GPD options. These settings are defined in the sample driver GPD configuration file and are handled by the Unidrv core via the CPSUI interface. All GPD options that are managed from the UI plug-in are hidden from the standard Unidrv Treeview dialog box. +- OEM private DevMode. These settings are settings that cannot be represented in the GPD file format (for example, numerical values and strings). They are instead added to the DevMode at a private offset. The Unidrv UI Plug-in interface includes methods that allow additional property pages to be inserted into the drivers property sheet. In the sample, only additional document property pages are implemented because there are no device property pages required. A collection of property page objects are stored at the plug-in interface level, each of which is responsible for the three property pages (Color, Watermarks, and Features). Each property page object creates a Microsoft Windows property page from a dialog resource and handles all Windows Messages that are received through a common dialog procedure. A collection of UI control objects are stored in the property page, one for each Windows control on the page. When a property page receives a message for a control, it looks up the relevant control in the collection (by using the resource identifier) and calls the appropriate method in the control interface, given the Windows message. Each control object is responsible for handling its own initialization and any user input through the appropriate get and set functions. The sample get and set functions provide an interface to read and update the GPD options and OEM private DevMode. -PrintTicket Provider Plug-in ----------------------------- +## PrintTicket Provider Plug-in The sample Print Ticket Provider plug-in is intended to demonstrate how to validate and map driver settings from a DevMode description to a Print Ticket description and back again. The driver allows configuration of custom settings through a custom user interface. These custom settings are represented as either GPD options or in the OEM private DevMode and are mapped to and from the Print Ticket using an XML schema. To support Print Ticket handling, the Unidrv UI Plug-in Print Ticket Provider Interface is utilized. The Unidrv UI Plug-in interface includes methods that allow mapping of DevMode to and from a Print Ticket Schema. A collection of feature conversion objects are stored at the plug-in interface level, each of which is responsible for the conversion of a specific feature (Color, Watermark, Booklet, Scaling, and NUp). Whenever the Unidrv core calls through the external interface of the plug-in to convert from DevMode to Print Ticket or Print Ticket to DevMode, the collection is iterated through calling each conversion object in turn; each then perform its own DevMode/Print Ticket mapping via the appropriate get and set functions. The sample get and set functions provide an interface to read and write the GPD options, OEM private DevMode, and Print Ticket keyword value pairs. - diff --git a/print/XPSDrvSmpl/print-xpsdrvsmpl.yml b/print/XPSDrvSmpl/print-xpsdrvsmpl.yml deleted file mode 100644 index 94a5eb05..00000000 --- a/print/XPSDrvSmpl/print-xpsdrvsmpl.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: XPSDrv Driver and Filter Sample - description: Provide a starting point for developing XPSDrv printer drivers and to illustrate the facility and potential of an XPSDrv print driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /print/XPSDrvSmpl/XPSDrvSmpl.sln diff --git a/print/XpsRasFilter/README.md b/print/XpsRasFilter/README.md index 344c6bf9..af8342a1 100644 --- a/print/XpsRasFilter/README.md +++ b/print/XpsRasFilter/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: XPS Rasterization Filter Service Sample +description: Implements an XPSDrv filter that rasterizes fixed pages in an XPS document. +languages: + - cpp +products: + - windows +--- + - - -XPS Rasterization Filter Service Sample -======================================= +# XPS Rasterization Filter Service Sample This sample implements an XPSDrv filter that rasterizes fixed pages in an XPS document. Hardware vendors can modify this sample to build an XPSDrv filter that produces bitmap images for their printers or other display devices. The sample uses the XPS Rasterization Service that creates rasterizer objects for use by XPSDrv filters. A rasterizer object takes an XPS Object Model (XPS OM) page object and creates a bitmap of a specified region of the page. The sample implements an XPSDrv filter (xpsrasfilter.dll) that can be inserted into the XPS Filter Pipeline. For each fixed page in an XPS document, the sample filter does the following: -- Uses the XPS rasterization service to create a rasterizer object for the fixed page. -- Partitions the fixed page into several horizontal bands. -- Uses the rasterizer object to render each horizontal band as a bitmap image. +- Uses the XPS rasterization service to create a rasterizer object for the fixed page. +- Partitions the fixed page into several horizontal bands. +- Uses the rasterizer object to render each horizontal band as a bitmap image. -The Print Filter Pipeline is part of the XPS Print Path [Windows Print Path Overview](print.windows_print_path_overview). Fixed pages are sent as an XPS data stream from the XPS Spooler to the print filter pipeline. The print filter pipeline manager takes the XPS fixed page, calls each filter in the order defined in the pipeline configuration file, and then sends either Fixed Page OM objects or a data stream to each filter as required. The filters process the data and return either Fixed Page OM objects or a data stream back to the print filter pipeline manager. (See MSDN entry for Filter Pipeline Interfaces items IXpsDocumentProvider, IXpsDocumentConsumer, IPrintWriteStream, and IPrintReadStream.) +The Print Filter Pipeline is part of the XPS Print Path [Windows Print Path Overview](https://docs.microsoft.com/windows-hardware/drivers/print/windows-print-path-overview). Fixed pages are sent as an XPS data stream from the XPS Spooler to the print filter pipeline. The print filter pipeline manager takes the XPS fixed page, calls each filter in the order defined in the pipeline configuration file, and then sends either Fixed Page OM objects or a data stream to each filter as required. The filters process the data and return either Fixed Page OM objects or a data stream back to the print filter pipeline manager. (See MSDN entry for Filter Pipeline Interfaces items IXpsDocumentProvider, IXpsDocumentConsumer, IPrintWriteStream, and IPrintReadStream.) As a print filter pipeline service, the XPS Rasterization Service can be loaded into the filter pipeline when the pipeline is initialized by adding a filter service provider tag to the configuration XML file (for example, \). The service is then available to be called by the filters when they are initialized and called by the print filter pipeline manager. The XPS Rasterization Service operates as follows: -- The calling filter initializes an instance of the rasterizer by passing in the XPS OM for the fixed page. -- The calling filter calls the RasterizeRect method of the rasterizer to render a specified rectangle area of the fixed page. -- RasterizeRect writes the WIC (Windows Imaging Component) bitmap data to memory. (The address is specified as a parameter to RasterizeRect.) +- The calling filter initializes an instance of the rasterizer by passing in the XPS OM for the fixed page. +- The calling filter calls the RasterizeRect method of the rasterizer to render a specified rectangle area of the fixed page. +- RasterizeRect writes the WIC (Windows Imaging Component) bitmap data to memory. (The address is specified as a parameter to RasterizeRect.) The default parameters in this sample are as follows: -- Letter-sized physical page (can override in print ticket). -- 0.25-inch margins (creating an 8-inch by 10.5-inch imageable area). -- Scaling is set to FitApplicationBleedSizeToImageableSize. -- Destination resolution set to 96 dpi (can override in print ticket). - +- Letter-sized physical page (can override in print ticket). +- 0.25-inch margins (creating an 8-inch by 10.5-inch imageable area). +- Scaling is set to FitApplicationBleedSizeToImageableSize. +- Destination resolution set to 96 dpi (can override in print ticket). diff --git a/print/XpsRasFilter/print-xpsrasfilter.yml b/print/XpsRasFilter/print-xpsrasfilter.yml deleted file mode 100644 index 17ca1420..00000000 --- a/print/XpsRasFilter/print-xpsrasfilter.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: XPS Rasterization Filter Service Sample - description: Implements an XPSDrv filter that rasterizes fixed pages in an XPS document. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /print/XpsRasFilter/XpsRasFilter.sln diff --git a/print/autoconfig/README.md b/print/autoconfig/README.md index 38a442e2..3185a42f 100644 --- a/print/autoconfig/README.md +++ b/print/autoconfig/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Print auto-configuration sample +description: Demonstrates how to implement auto-configuration in v4 print drivers. +languages: + - cpp +products: + - windows +--- + +# Print auto-configuration sample -Print auto-configuration sample -=============================== +This sample demonstrates how to implement auto-configuration in v4 print drivers. -This sample demonstrates how to implement auto-configuration in v4 print drivers. - -**Auto-configuration basics** +## Auto-configuration basics Many printers ship with optional components which are not present in all versions of the printer. For these printers, it's important that the driver only shows options which are enabled by the currently installed hardware. For example, if a stapling unit is optional for a particular printer, then the driver shouldn't expose the stapling feature to the end user if that unit is not installed. @@ -23,9 +31,7 @@ For more information on auto-configuration, see [Printer Autoconfiguration](http For more information on the Bidi Schema, see [Bidirectional Communication Schema](https://msdn.microsoft.com/en-us/library/windows/hardware/ff545169(v=vs.85).aspx). - -Build the sample ----------------- +## Build the sample The auto-configuration sample doesn't have any binaries to be built. It may be installed by using **Add Printer Wizard** and supplying the AutoCnfg.INF as the INF file. @@ -43,8 +49,6 @@ At this point, Visual Studio will be able to build a driver package and output t For more information about how to build a driver solution using Microsoft Visual Studio, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644). -Run the sample --------------- +## Run the sample To run the auto-configuration sample, you must install this driver to support a printer which is installed against either a WSD port, or TCP/IP port. Additionally, USB printers may be supported if the driver is updated to incorporate USB Bidi Javascript, as described here: [Print Driver USB Monitor and Bidi Sample](https://github.com/Microsoft/Windows-driver-samples/tree/master/print/v4PrintDriverSamples/v4PrintDriver-USBMon-Bidi-Extension). - diff --git a/print/autoconfig/print-autoconfig.yml b/print/autoconfig/print-autoconfig.yml deleted file mode 100644 index db71bffc..00000000 --- a/print/autoconfig/print-autoconfig.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Print auto-configuration sample - description: Demonstrates how to implement auto-configuration in v4 print drivers. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /print/autoconfig/AutoConfig.sln diff --git a/print/cpsuisam/README.md b/print/cpsuisam/README.md index b289ad82..4ad88a9b 100644 --- a/print/cpsuisam/README.md +++ b/print/cpsuisam/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Common Property Sheet User Interface (CPSUI) Sample +description: The CPSUISAM application causes the CPSUI to call the print spooler to create property sheet pages for the default printer. +languages: + - cpp +products: + - windows +--- + - -Common Property Sheet UI Sample -=============================== +# Common Property Sheet UI Sample The CPSUISAM application causes the Common Property Sheet User Interface (CPSUI) to call the Windows print spooler to create property sheet pages for the system's default printer. @@ -20,4 +28,3 @@ The application then creates an additional property sheet page to illustrate som CPSUI is a user-mode DLL that enables you to create property sheet pages that have a standard appearance. CPSUIAM causes CPSUI to call the Windows print spooler to create property sheet pages for the system's default printer. The application then creates an additional property sheet page to illustrate some of the techniques that you can use when you are using CPSUI to create a new page. For more information, see [Common Property Sheet User Interface](http://msdn.microsoft.com/en-us/library/windows/hardware/ff546163(v=vs.85).aspx). - diff --git a/print/cpsuisam/print-cpsuisam.yml b/print/cpsuisam/print-cpsuisam.yml deleted file mode 100644 index 02862cb1..00000000 --- a/print/cpsuisam/print-cpsuisam.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Common Property Sheet User Interface (CPSUI) Sample - description: The CPSUISAM application causes the CPSUI to call the print spooler to create property sheet pages for the default printer. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /print/cpsuisam/cpsuisam.sln diff --git a/print/v4PrintDriverSamples/PrinterExtensionSample/README.md b/print/v4PrintDriverSamples/PrinterExtensionSample/README.md index c76f31d8..f4680018 100644 --- a/print/v4PrintDriverSamples/PrinterExtensionSample/README.md +++ b/print/v4PrintDriverSamples/PrinterExtensionSample/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Printer Extension Sample +description: Demonstrates how to use .NET to build a customized, desktop UI for a v4 print driver. +languages: +- csharp +products: + - windows +--- + - -Printer Extension Sample -======================== +# Printer Extension Sample This sample demonstrates how to use .NET to build a customized, desktop UI for a v4 print driver. This .NET app uses PrintTicket, PrintCapabilities and Bidi in order to communicate with the print system and is suitable for inclusion in a v4 print driver. **Note** This sample is for the v4 print driver model. -Related topics --------------- +# Related topics [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644) [v4 Print Driver Interfaces and Enumerations](http://msdn.microsoft.com/en-us/library/hh464103(v=vs.85).aspx) - diff --git a/print/v4PrintDriverSamples/PrinterExtensionSample/print-v4printdriversamples-printerextensionsample.yml b/print/v4PrintDriverSamples/PrinterExtensionSample/print-v4printdriversamples-printerextensionsample.yml deleted file mode 100644 index 3dcc5d76..00000000 --- a/print/v4PrintDriverSamples/PrinterExtensionSample/print-v4printdriversamples-printerextensionsample.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Printer Extension Sample - description: Demonstrates how to use .NET to build a customized, desktop UI for a v4 print driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - csharp - technologies: - - windows - vssolution: /print/v4PrintDriverSamples/PrinterExtensionSample/PrinterExtensionSample.sln diff --git a/print/v4PrintDriverSamples/v4PrintDriver-ConstraintScript/README.md b/print/v4PrintDriverSamples/v4PrintDriver-ConstraintScript/README.md index f0f64424..c5048b0b 100644 --- a/print/v4PrintDriverSamples/v4PrintDriver-ConstraintScript/README.md +++ b/print/v4PrintDriverSamples/v4PrintDriver-ConstraintScript/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Print Driver Constraints Sample +description: Demonstrates how to implement advanced constraint handling and PrintTicket/PrintCapabilities handling using JavaScript. +languages: + - javascript +products: + - windows +--- + - -Print Driver Constraints Sample -=============================== +# Print Driver Constraints Sample This sample demonstrates how to implement advanced constraint handling, and also PrintTicket/PrintCapabilities handling using JavaScript. The Constraints.js file in this sample demonstrates the implementation of JavaScript-based constraints to be used with a v4 print driver. The file implements the following two of the four functions used by JavaScript constraint files, as well as several helper functions: -- **ValidatePrintTicket** takes a given [IPrintSchemaTicket](http://msdn.microsoft.com/en-us/library/hh451398(v=vs.85).aspx) object and validates it for the current printer. The function may determine that the Print Ticket was already valid, modify the Print Ticket to make it valid, or determine that the Print Ticket is invalid and could not be made valid. -- **CompletePrintCapabilities** takes a given **IPrintSchemaTicket** object and the [IPrintSchemaCapabilities](http://msdn.microsoft.com/en-us/library/hh451256(v=vs.85).aspx) object that was produced by the configuration module and augments it as needed. This can be used to establish positive constraint situations. +- **ValidatePrintTicket** takes a given [IPrintSchemaTicket](http://msdn.microsoft.com/en-us/library/hh451398(v=vs.85).aspx) object and validates it for the current printer. The function may determine that the Print Ticket was already valid, modify the Print Ticket to make it valid, or determine that the Print Ticket is invalid and could not be made valid. +- **CompletePrintCapabilities** takes a given **IPrintSchemaTicket** object and the [IPrintSchemaCapabilities](http://msdn.microsoft.com/en-us/library/hh451256(v=vs.85).aspx) object that was produced by the configuration module and augments it as needed. This can be used to establish positive constraint situations. This sample does not demonstrate **ConvertPrintTicketToDevMode** or **ConvertDevModeToPrintTicket**, which utilize a property bag to store data in the private section of the DEVMODE structure. **Note** This sample is for the v4 print driver model. -Related topics --------------- +# Related topics [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644) [IPrintSchemaCapabilities](http://msdn.microsoft.com/en-us/library/hh451256(v=vs.85).aspx) [IPrintSchemaTicket](http://msdn.microsoft.com/en-us/library/hh451398(v=vs.85).aspx) - diff --git a/print/v4PrintDriverSamples/v4PrintDriver-ConstraintScript/print-v4printdriversamples-v4printdriver-constraintscript.yml b/print/v4PrintDriverSamples/v4PrintDriver-ConstraintScript/print-v4printdriversamples-v4printdriver-constraintscript.yml deleted file mode 100644 index 837aa248..00000000 --- a/print/v4PrintDriverSamples/v4PrintDriver-ConstraintScript/print-v4printdriversamples-v4printdriver-constraintscript.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Print Driver Constraints Sample - description: Demonstrates how to implement advanced constraint handling and PrintTicket/PrintCapabilities handling using JavaScript. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - javascript - technologies: - - windows - vssolution: /print/v4PrintDriverSamples/v4PrintDriver-ConstraintScript/ConstraintScript.sln diff --git a/print/v4PrintDriverSamples/v4PrintDriver-HostBasedSampleDriver/README.md b/print/v4PrintDriverSamples/v4PrintDriver-HostBasedSampleDriver/README.md index fee078b0..608eac8b 100644 --- a/print/v4PrintDriverSamples/v4PrintDriver-HostBasedSampleDriver/README.md +++ b/print/v4PrintDriverSamples/v4PrintDriver-HostBasedSampleDriver/README.md @@ -1,3 +1,14 @@ +--- +topic: sample +name: USB Host-Based Print Driver Sample +description: Demonstrates how to support host-based devices that use the v4 print driver model and are connected via USB. +languages: + - javascript + - xml +products: + - windows +--- + - - -USB Host-Based Print Driver Sample -================================== +# USB Host-Based Print Driver Sample This driver sample demonstrates how to support host-based devices that use the v4 print driver model, and are connected via USB. @@ -28,44 +36,35 @@ The Bidi schema is a hierarchy of printer attributes, some of which are properti *Property* -A property is a node in the schema hierarchy. A property can have one or more children, and these children can be other properties or values. +- A property is a node in the schema hierarchy. A property can have one or more children, and these children can be other properties or values. *Value* -A value is a leaf in the schema hierarchy that represents either a single data item or a list of related data items. A value has a name, a data type, and a data value. A value cannot have child elements. +- A value is a leaf in the schema hierarchy that represents either a single data item or a list of related data items. A value has a name, a data type, and a data value. A value cannot have child elements. For more information, see [USB Bidi Extender](http://msdn.microsoft.com/en-us/library/windows/hardware/jj659903(v=vs.85).aspx) and [Bidi Communication Schema](http://msdn.microsoft.com/en-us/library/windows/hardware/ff545169(v=vs.85).aspx). Here are the core files that you will find in this sample: -File name +**usb\_host\_based\_sample.js** -Description +- A USB Bidi Extension JavaScript file which includes support for controlling printing for host-based devices. This is the only code in the driver sample. It is invoked by USBMon and it communicates with the device to do the following: + - Determine if the device is ready to receive data + - Check to see if there is an error condition + - Read the device status -usb\_host\_based\_sample.js +**usb\_host\_based\_sample\_events.xml** -A USB Bidi Extension JavaScript file which includes support for controlling printing for host-based devices. This is the only code in the driver sample. It is invoked by USBMon and it communicates with the device to do the following: +- A 'driver events' XML file that specifies an event which detects when the user needs to flip over the paper in the tray. -- Determine if the device is ready to receive data -- Check to see if there is an error condition -- Read the device status +**usb\_host\_based\_sample\_extension.xml** -usb\_host\_based\_sample\_events.xml +- A USB Bidi Extension XML file that specifies the supported Bidi Schema elements for this driver. -A 'driver events' XML file that specifies an event which detects when the user needs to flip over the paper in the tray. - -usb\_host\_based\_sample\_extension.xml - -A USB Bidi Extension XML file that specifies the supported Bidi Schema elements for this driver. - - -Build the sample ----------------- +## Build the sample For information and instructions about how to test and deploy drivers, see [Developing, Testing, and Deploying Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554651(v=vs.85).aspx). -Run the sample --------------- +## Run the sample To understand how to run this sample as a Windows driver, see the [v4 Printer Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/hh706306(v=vs.85).aspx) collection of topics. - diff --git a/print/v4PrintDriverSamples/v4PrintDriver-HostBasedSampleDriver/print-v4printdriversamples-v4printdriver-hostbasedsampledriver.yml b/print/v4PrintDriverSamples/v4PrintDriver-HostBasedSampleDriver/print-v4printdriversamples-v4printdriver-hostbasedsampledriver.yml deleted file mode 100644 index 844de91b..00000000 --- a/print/v4PrintDriverSamples/v4PrintDriver-HostBasedSampleDriver/print-v4printdriversamples-v4printdriver-hostbasedsampledriver.yml +++ /dev/null @@ -1,13 +0,0 @@ -### YamlMime:Sample -sample: -- name: USB Host-Based Print Driver Sample - description: Demonstrates how to support host-based devices that use the v4 print driver model and are connected via USB. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - javascript - - xml - technologies: - - windows - vssolution: /print/v4PrintDriverSamples/v4PrintDriver-HostBasedSampleDriver/HostBasedSampleDriver.sln diff --git a/print/v4PrintDriverSamples/v4PrintDriver-USBMon-Bidi-Extension/README.md b/print/v4PrintDriverSamples/v4PrintDriver-USBMon-Bidi-Extension/README.md index cebf8145..fc4ab7ba 100644 --- a/print/v4PrintDriverSamples/v4PrintDriver-USBMon-Bidi-Extension/README.md +++ b/print/v4PrintDriverSamples/v4PrintDriver-USBMon-Bidi-Extension/README.md @@ -1,3 +1,14 @@ +--- +topic: sample +name: Print Driver USB Monitor and Bidi Sample +description: Demonstrates how to support bidirectional (Bidi) communication over the USB bus using JavaScript and XML. +languages: + - javascript + - xml +products: + - windows +--- + - -Print Driver USB Monitor and Bidi Sample -======================================== +# Print Driver USB Monitor and Bidi Sample This sample demonstrates how to support bidirectional (Bidi) communication over the USB bus, using JavaScript and XML. This sample supports bidirectional status while not printing, and unsolicited status from the printer while printing. The following files are included in the sample: -- USBMON\_Bidi\_JavaScript\_File.js. This JavaScript file demonstrates the implementation of a Bidi support for USBMon with a v4 print driver. The JavaScript file supports three functions: getSchemas() is used to make Bidi GET queries to a device, setSchema() is used to make a single Bidi SET query to the device, and getStatus() is called repeatedly during printing in order to retrieve unsolicited status from the printer using the data from the read channel of the device. -- USBMON\_Bidi\_XML\_File.xml. This XML file demonstrates how to build a Bidi Schema extension for USB. It describes the supported schema elements that can be queried or set, along with their restrictions. +**USBMON\_Bidi\_JavaScript\_File.js** + +- This JavaScript file demonstrates the implementation of a Bidi support for USBMon with a v4 print driver. The JavaScript file supports three functions: getSchemas() is used to make Bidi GET queries to a device, setSchema() is used to make a single Bidi SET query to the device, and getStatus() is called repeatedly during printing in order to retrieve unsolicited status from the printer using the data from the read channel of the device. + +**USBMON\_Bidi\_XML\_File.xml** + +- This XML file demonstrates how to build a Bidi Schema extension for USB. It describes the supported schema elements that can be queried or set, along with their restrictions. For more information, see [USB Bidi Extender](http://msdn.microsoft.com/en-us/library/windows/hardware/jj659903(v=vs.85).aspx). @@ -24,7 +38,7 @@ For more information, see [USB Bidi Extender](http://msdn.microsoft.com/en-us/li **Note** When you make calls to printerStream.read() in the sample, the printer returns an array which includes an additional element that represents the array length. The following JavaScript code can be used to copy the returned array into a new array, and also to remove the additional element. -``` +```js var readBuffer = []; var readBytes = 0; var readSize = 4096; @@ -33,9 +47,8 @@ readBuffer = printerStream.read( readSize ); readBytes = readBuffer.length; var cleanArray = []; - + for ( i = 0; i < readBytes; i++ ) { cleanArray[i] = readBuffer.shift(); } ``` - diff --git a/print/v4PrintDriverSamples/v4PrintDriver-USBMon-Bidi-Extension/print-v4printdriversamples-v4printdriver-usbmon-bidi-extension.yml b/print/v4PrintDriverSamples/v4PrintDriver-USBMon-Bidi-Extension/print-v4printdriversamples-v4printdriver-usbmon-bidi-extension.yml deleted file mode 100644 index 3cbf769c..00000000 --- a/print/v4PrintDriverSamples/v4PrintDriver-USBMon-Bidi-Extension/print-v4printdriversamples-v4printdriver-usbmon-bidi-extension.yml +++ /dev/null @@ -1,13 +0,0 @@ -### YamlMime:Sample -sample: -- name: Print Driver USB Monitor and Bidi Sample - description: Demonstrates how to support bidirectional (Bidi) communication over the USB bus using JavaScript and XML. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - javascript - - xml - technologies: - - windows - vssolution: /print/v4PrintDriverSamples/v4PrintDriver-USBMon-Bidi-Extension/USBMon-Bidi-Extension.sln diff --git a/print/v4PrintDriverSamples/v4PrintDriver-WSDMon-Bidi-Extension/README.md b/print/v4PrintDriverSamples/v4PrintDriver-WSDMon-Bidi-Extension/README.md index 385002c0..c6752730 100644 --- a/print/v4PrintDriverSamples/v4PrintDriver-WSDMon-Bidi-Extension/README.md +++ b/print/v4PrintDriverSamples/v4PrintDriver-WSDMon-Bidi-Extension/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: WSDMon Bidi Extension Sample +description: Demonstrates how to use an XML extension file to support bidirectional (Bidi) communication with a WSD connected printer. +languages: + - xml +products: + - windows +--- + - -WSDMon Bidi Extension Sample -============================ +# WSDMon Bidi Extension Sample This sample demonstrates how to use an XML extension file to support bidirectional (Bidi) communication with a WSD connected printer. @@ -27,29 +35,28 @@ A *value* is a leaf in the schema hierarchy that represents either a single data The WSDMON port monitor can: -- Discover network printers and install them. +- Discover network printers and install them. -- Send jobs to WSD printers. +- Send jobs to WSD printers. -- Monitor the status and configuration of the WSD printers and update the printer object status accordingly. +- Monitor the status and configuration of the WSD printers and update the printer object status accordingly. -- Respond to bidirectional (bidi) queries for supported bidi schemas. +- Respond to bidirectional (bidi) queries for supported bidi schemas. -- Monitor bidi Schema value changes and send notifications. +- Monitor bidi Schema value changes and send notifications. WSDMON supports the following Xcv commands: -- CleanupPort +- CleanupPort -- DeviceID +- DeviceID -- PnPXID +- PnPXID -- ResetCommunication +- ResetCommunication -- ServiceID +- ServiceID **Note** This sample is for the v4 print driver model. For more information, see [V4 Driver Connectivity Architecture](http://msdn.microsoft.com/en-us/library/windows/hardware/) and [Bidirectional Communication Schema](http://msdn.microsoft.com/en-us/library/windows/hardware/ff545169(v=vs.85).aspx). - diff --git a/print/v4PrintDriverSamples/v4PrintDriver-WSDMon-Bidi-Extension/print-v4printdriversamples-v4printdriver-wsdmon-bidi-extension.yml b/print/v4PrintDriverSamples/v4PrintDriver-WSDMon-Bidi-Extension/print-v4printdriversamples-v4printdriver-wsdmon-bidi-extension.yml deleted file mode 100644 index c14153ff..00000000 --- a/print/v4PrintDriverSamples/v4PrintDriver-WSDMon-Bidi-Extension/print-v4printdriversamples-v4printdriver-wsdmon-bidi-extension.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: WSDMon Bidi Extension Sample - description: Demonstrates how to use an XML extension file to support bidirectional (Bidi) communication with a WSD connected printer. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - xml - technologies: - - windows - vssolution: /print/v4PrintDriverSamples/v4PrintDriver-WSDMon-Bidi-Extension/WSDMon-Bidi-Extension.sln diff --git a/sd/miniport/sdhc/README.md b/sd/miniport/sdhc/README.md index a1e81cde..78360be1 100644 --- a/sd/miniport/sdhc/README.md +++ b/sd/miniport/sdhc/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Standard SD Host Controller Miniport +description: Provides a functional miniport implementation for a standard SD host controller. +languages: + - cpp +products: + - windows +--- + - -Standard SD Host Controller Miniport -==================================== +# Standard SD Host Controller Miniport This is a sample for a Secure Digital (SD) Host Controller miniport driver. The driver works in conjunction with sdport.sys, which implements SD/SDIO/eMMC protocol and WDM interfaces, to provide the host register interface. ## Universal Compliant + This sample builds a Windows Universal driver. It uses only APIs and DDIs that are included in Windows Core. This driver, sdhc.sys, provides a functional miniport implementation for a standard SD host controller. However, it does not have support for many more recent features such as: - UHS-I speed modes. - HS400 -- SD 4.0 \ No newline at end of file +- SD 4.0 diff --git a/sd/miniport/sdhc/sd-miniport-sdhc.yml b/sd/miniport/sdhc/sd-miniport-sdhc.yml deleted file mode 100644 index 0f2925ec..00000000 --- a/sd/miniport/sdhc/sd-miniport-sdhc.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Standard SD Host Controller Miniport - description: Provides a functional miniport implementation for a standard SD host controller. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /sd/miniport/sdhc/sdhc.sln diff --git a/security/elam/README.md b/security/elam/README.md index bbd5b772..ff09abf2 100644 --- a/security/elam/README.md +++ b/security/elam/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Early Launch Anti-Malware Driver +description: Demonstrates how to receive notifications about the initialization of regular boot start drivers in an Early Launch Anti-Malware driver. +languages: + - cpp +products: + - windows +--- + - -Early Launch Anti-Malware Driver -================================ +# Early Launch Anti-Malware Driver This sample demonstrates how to use the [**IoRegisterBootDriverCallback**](http://msdn.microsoft.com/en-us/library/windows/hardware/hh439379) and [**IoUnRegisterBootDriverCallback**](http://msdn.microsoft.com/en-us/library/windows/hardware/hh439394) DDIs from an Early Launch Anti-Malware driver, to receive notifications about the initialization of regular boot start drivers. This sample driver is a minimal driver meant to demonstrate the usage of the APIs mentioned above. It is not intended for use in a production environment. -**SIGNING THE SAMPLE** +## Signing the sample Early Launch drivers are required to be signed with a code-signing certificate that also contains the Early Launch EKU "1.3.6.1.4.1.311.61.4.1". In a production environment, Early Launch drivers are signed by Microsoft for qualifying Anti-Malware vendors with a WHQL certificate that contains this EKU. The makecert.exe tool can be used to generate a self-signed test certificate that contains both the Early Launch EKU and the "1.3.6.1.5.5.7.3.3" Code Signing EKU. Once a certificate of this form has been created, signtool.exe can be used to sign elamsample.sys. +## Run the sample -Run the sample --------------- - -**INSTALLING THE SAMPLE** +### Installing the sample 1. Copy the signed elamsample.sys file to the %WINDIR%\\System32\\Drivers directory on your test machine. 2. Use the sc.exe tool present in Windows to install the driver: - `sc create ElamSample binpath=%windir%\\system32\\drivers\\elamsample.sys type=kernel start=boot error=critical group=Early-Launch` + `sc create ElamSample binpath=%windir%\\system32\\drivers\\elamsample.sys type=kernel start=boot error=critical group=Early-Launch` 3. Enable test signing: - `bcdedit /set testsigning on` + `bcdedit /set testsigning on` -**CODE TOUR** +## Code tour **DriverEntry:** Creates a framework driver object and calls IoRegisterBootDriverCallback to register to boot driver status callbacks. @@ -49,11 +55,11 @@ Run the sample **ElamSamplePrintHex:** A utility function to display a buffer in hexadecimal form. -**TESTING** +## Testing After installing the driver, attach the Kernel Debugger and reboot your test machine. If ELAMSAMPLE\_TRACE\_LEVEL is set to DPFLTR\_ERROR\_LEVEL, traces will be output to the debugger automatically. For example: -``` +```cmd ElamSample is being initialized. ElamSample reports the following dependency is about to be initialized: ElamSample: diff --git a/security/elam/security-elam.yml b/security/elam/security-elam.yml deleted file mode 100644 index 8a338784..00000000 --- a/security/elam/security-elam.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Early Launch Anti-Malware Driver - description: Demonstrates how to receive notifications about the initialization of regular boot start drivers in an Early Launch Anti-Malware driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /security/elam/elam.sln diff --git a/sensors/ADXL345Acc/readme.md b/sensors/ADXL345Acc/readme.md index 3d49e89f..d0f13f55 100644 --- a/sensors/ADXL345Acc/readme.md +++ b/sensors/ADXL345Acc/readme.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: ADXL345 Accelerometer Sample Driver +description: Demonstrates how to write a UMDF v2 driver to control an ADXL345 accelerometer chip. +languages: + - cpp +products: + - windows +--- + - -Virtual serial driver sample -============================ +# Virtual serial driver sample This sample demonstrates these two serial drivers: -- A simple virtual serial driver (ComPort) -- A controller-less modem driver (FakeModem).This driver supports sending and receiving AT commands using the ReadFile and WriteFile calls or via a TAPI interface using an application such as, HyperTerminal. +- A simple virtual serial driver (ComPort) +- A controller-less modem driver (FakeModem).This driver supports sending and receiving AT commands using the ReadFile and WriteFile calls or via a TAPI interface using an application such as, HyperTerminal. This sample driver is a minimal driver meant to demonstrate the usage of the User-Mode Driver Framework. It is not intended for use in a production environment. For more information, see [Serial Controller and Device Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff546939) in the WDK documentation. -Code tour ---------- +## Code tour -File manifest +### comsup.cpp & comsup.h -Description +- COM Support code - specifically base classes which provide implementations for the standard COM interfaces **IUnknown** and **IClassFactory** which are used throughout the sample. +- The implementation of **IClassFactory** is designed to create instances of the CMyDriver class. If you should change the name of your base driver class, you would also need to modify this file. -comsup.cpp & comsup.h +### dllsup.cpp -COM Support code - specifically base classes which provide implementations for the standard COM interfaces **IUnknown** and **IClassFactory** which are used throughout the sample. +- DLL Support code - provides the DLL's entry point as well as the single required export (**DllGetClassObject**). +- These depend on comsup.cpp to perform the necessary class creation. -The implementation of **IClassFactory** is designed to create instances of the CMyDriver class. If you should change the name of your base driver class, you would also need to modify this file. +### exports.def -dllsup.cpp +- This file lists the functions that the driver DLL exports. -DLL Support code - provides the DLL's entry point as well as the single required export (**DllGetClassObject**). +### internal.h -These depend on comsup.cpp to perform the necessary class creation. +- This is the main header file for the sample driver. -exports.def +### driver.cpp & driver.h -This file lists the functions that the driver DLL exports. +- Definition and implementation of the driver callback class (CMyDriver) for the sample. This includes **DriverEntry** and events on the framework driver object. -internal.h +### device.cpp & driver.h -This is the main header file for the sample driver. +- Definition and implementation of the device callback class (CMyDriver) for the sample. This includes events on the framework device object. -driver.cpp & driver.h +### queue.cpp & queue.h -Definition and implementation of the driver callback class (CMyDriver) for the sample. This includes **DriverEntry** and events on the framework driver object. +- Definition and implementation of the base queue callback class (CMyQueue). This includes events on the framework I/O queue object. -device.cpp & driver.h +### VirtualSerial.rc /FakeModem.rc -Definition and implementation of the device callback class (CMyDriver) for the sample. This includes events on the framework device object. +- This file defines resource information for the sample driver. -queue.cpp & queue.h - -Definition and implementation of the base queue callback class (CMyQueue). This includes events on the framework I/O queue object. - -VirtualSerial.rc /FakeModem.rc - -This file defines resource information for the sample driver. - -VirtualSerial.inf / FakeModem.inf - -INF file that contains installation information for this driver. +### VirtualSerial.inf / FakeModem.inf +- INF file that contains installation information for this driver. diff --git a/serial/VirtualSerial/serial-virtualserial.yml b/serial/VirtualSerial/serial-virtualserial.yml deleted file mode 100644 index 7b33b547..00000000 --- a/serial/VirtualSerial/serial-virtualserial.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: The Serial (16550-based RS-232) sample driver is a WDF version of the inbox Serial.sys driver. - description: Demonstrates a simple virtual serial driver (ComPort) and a controller-less modem driver (FakeModem). - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /serial/VirtualSerial/VirtualSerial.sln diff --git a/serial/VirtualSerial2/README.md b/serial/VirtualSerial2/README.md index 81405d15..23e8b170 100644 --- a/serial/VirtualSerial2/README.md +++ b/serial/VirtualSerial2/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Virtual serial driver sample (UMDF version 2) +description: Demonstrates UMDF version 2 serial drivers and includes a simple virtual serial driver (ComPort) and a controller-less modem driver (FakeModem). +languages: + - cpp +products: + - windows +--- + - -Virtual serial driver sample -============================ +# Virtual serial driver sample This sample demonstrates these two serial drivers: -- A simple virtual serial driver (ComPort) -- A controller-less modem driver (FakeModem).This driver supports sending and receiving AT commands using the ReadFile and WriteFile calls or via a TAPI interface using an application such as, HyperTerminal. +- A simple virtual serial driver (ComPort) +- A controller-less modem driver (FakeModem).This driver supports sending and receiving AT commands using the ReadFile and WriteFile calls or via a TAPI interface using an application such as, HyperTerminal. This sample driver is a minimal driver meant to demonstrate the usage of the User-Mode Driver Framework. It is not intended for use in a production environment. For more information, see [Serial Controller and Device Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff546939) in the WDK documentation. -Code tour ---------- +## Code tour -#### comsup.cpp & comsup.h -COM Support code - specifically base classes which provide implementations for the standard COM interfaces **IUnknown** and **IClassFactory** which are used throughout the sample. -The implementation of **IClassFactory** is designed to create instances of the CMyDriver class. If you should change the name of your base driver class, you would also need to modify this file. +### comsup.cpp & comsup.h -#### dllsup.cpp -DLL Support code - provides the DLL's entry point as well as the single required export (**DllGetClassObject**). -These depend on comsup.cpp to perform the necessary class creation. +- COM Support code - specifically base classes which provide implementations for the standard COM interfaces **IUnknown** and **IClassFactory** which are used throughout the sample. +- The implementation of **IClassFactory** is designed to create instances of the CMyDriver class. If you should change the name of your base driver class, you would also need to modify this file. -#### exports.def -This file lists the functions that the driver DLL exports. +### dllsup.cpp -#### internal.h -This is the main header file for the sample driver. +- DLL Support code - provides the DLL's entry point as well as the single required export (**DllGetClassObject**). +- These depend on comsup.cpp to perform the necessary class creation. -#### driver.cpp & driver.h -Definition and implementation of the driver callback class (CMyDriver) for the sample. This includes **DriverEntry** and events on the framework driver object. +### exports.def -#### device.cpp & driver.h -Definition and implementation of the device callback class (CMyDriver) for the sample. This includes events on the framework device object. +- This file lists the functions that the driver DLL exports. -#### queue.cpp & queue.h -Definition and implementation of the base queue callback class (CMyQueue). This includes events on the framework I/O queue object. +### internal.h -#### VirtualSerial.rc /FakeModem.rc -This file defines resource information for the sample driver. +- This is the main header file for the sample driver. -#### VirtualSerial.inf / FakeModem.inf -INF file that contains installation information for this driver. +### driver.cpp & driver.h +- Definition and implementation of the driver callback class (CMyDriver) for the sample. This includes **DriverEntry** and events on the framework driver object. + +### device.cpp & driver.h + +- Definition and implementation of the device callback class (CMyDriver) for the sample. This includes events on the framework device object. + +### queue.cpp & queue.h + +- Definition and implementation of the base queue callback class (CMyQueue). This includes events on the framework I/O queue object. + +### VirtualSerial.rc /FakeModem.rc + +- This file defines resource information for the sample driver. + +### VirtualSerial.inf / FakeModem.inf + +- INF file that contains installation information for this driver. diff --git a/serial/VirtualSerial2/serial-virtualserial2.yml b/serial/VirtualSerial2/serial-virtualserial2.yml deleted file mode 100644 index aff10eda..00000000 --- a/serial/VirtualSerial2/serial-virtualserial2.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Virtual serial driver sample (UMDF version 2) - description: Demonstrates UMDF version 2 serial drivers and includes a simple virtual serial driver (ComPort) and a controller-less modem driver (FakeModem). - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /serial/VirtualSerial2/VirtualSerial.sln diff --git a/serial/serenum/README.md b/serial/serenum/README.md index c4690bbf..035f59a2 100644 --- a/serial/serenum/README.md +++ b/serial/serenum/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Serenum sample +description: Enumerates Plug-n-Play RS-232 devices that are compliant with the current revision of Plug and Play External COM Device. +languages: + - cpp +products: + - windows +--- + - -Serenum sample -============== +# Serenum sample Serenum enumerates Plug-n-Play RS-232 devices that are compliant with the current revision of Plug and Play External COM Device. It loads as an upper filter driver to many different RS-232 device drivers that are compliant with its requirements and performs this service for them. @@ -17,14 +25,14 @@ Serenum implements the Serenum service; its executable image is serenum.sys. Serenum is an upper-level device filter driver that is used with a serial port function driver to enumerate the following types of devices that are connected to an RS-232 port: -- Plug and Play serial devices that comply with Plug and Play External COM Device Specification, Version 1.00, February 28, 1995. -- Pointer devices that comply with legacy mouse detection in Windows. +- Plug and Play serial devices that comply with Plug and Play External COM Device Specification, Version 1.00, February 28, 1995. +- Pointer devices that comply with legacy mouse detection in Windows. The combined operation of Serial and Serenum provides the function of a Plug and Play bus driver for an RS-232 port. Serenum supports Plug and Play and power management. Windows provides Serenum to support Serial and other serial port function drivers that need to enumerate an RS-232 port. Hardware vendors do not have to create their own enumerator for RS-232 ports. For example, a device driver can use Serenum to enumerate the devices that are attached to the individual RS-232 ports on a multiport device. -### File Manifest +## File Manifest File | Description -----|------------ @@ -37,4 +45,3 @@ String.c | String handling support; mainly ASCII to UNICODE functionality Serenum.rc | Resource script For more information, see [Features of Serial and Serenum](http://msdn.microsoft.com/en-us/library/windows/hardware/ff546505). - diff --git a/serial/serenum/serial-serenum.yml b/serial/serenum/serial-serenum.yml deleted file mode 100644 index c3638f32..00000000 --- a/serial/serenum/serial-serenum.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Serenum sample - description: Enumerates Plug-n-Play RS-232 devices that are compliant with the current revision of Plug and Play External COM Device. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /serial/serenum/serenum.sln diff --git a/serial/serial/README.md b/serial/serial/README.md index 583e9cae..335a7134 100644 --- a/serial/serial/README.md +++ b/serial/serial/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Serial Port Driver +description: The Serial (16550-based RS-232) sample driver is a WDF version of the inbox Serial.sys driver. +languages: + - cpp +products: + - windows +--- + - -Serial Port Driver -================== +# Serial Port Driver The Serial (16550-based RS-232) sample driver is a WDF version of the inbox Serial.sys driver in %WINDIR%\\system32\\drivers. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. This sample driver is functionally equivalent to the inbox driver, with these two exceptions: -1. This sample does not support multi-function serial devices. -2. This sample does not support legacy serial ports. Legacy ports are not detected by the BIOS, and are, therefore, not enumerated by the operating system. +1. This sample does not support multi-function serial devices. +2. This sample does not support legacy serial ports. Legacy ports are not detected by the BIOS, and are, therefore, not enumerated by the operating system. The Serial sample driver runs in kernel mode. @@ -29,17 +38,17 @@ For more information, see [Features of Serial and Serenum](http://msdn.microsoft This sample can be used for these hardware IDs without any modification to the .inx file included in the project. -- PNP0501 -- PNP0500 +- PNP0501 +- PNP0500 - If you have other hardware such as an add-in card, then you must add the hardware ID in the .inx as shown in this example. Then, you must build the project as per the instructions given in the Building the sample section in this readme. +If you have other hardware such as an add-in card, then you must add the hardware ID in the .inx as shown in this example. Then, you must build the project as per the instructions given in the Building the sample section in this readme. - ``` - ; For XP and later - [MSFT.NTamd64] - ; DisplayName Section DeviceId - ; ----------- ------- -------- - %PNP0500.DevDesc%= Serial_Inst, *PNP0500, *PNP0501 ; Communications Port - %PNP0501.DevDesc%= Serial_Inst, *PNP0501, *PNP0500 ; Communications Port - %PNP0501.DevDesc%= Serial_Inst, MF\PCI9710_COM ; Communications Port - ``` +```inf +; For XP and later +[MSFT.NTamd64] +; DisplayName Section DeviceId +; ----------- ------- -------- +%PNP0500.DevDesc%= Serial_Inst, *PNP0500, *PNP0501 ; Communications Port +%PNP0501.DevDesc%= Serial_Inst, *PNP0501, *PNP0500 ; Communications Port +%PNP0501.DevDesc%= Serial_Inst, MF\PCI9710_COM ; Communications Port +``` diff --git a/serial/serial/serial-serial.yml b/serial/serial/serial-serial.yml deleted file mode 100644 index c9146bfb..00000000 --- a/serial/serial/serial-serial.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Serial Port Driver - description: The Serial (16550-based RS-232) sample driver is a WDF version of the inbox Serial.sys driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /serial/serial/serial.sln diff --git a/setup/devcon/README.md b/setup/devcon/README.md index 60e79702..09c8ff3c 100644 --- a/setup/devcon/README.md +++ b/setup/devcon/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Device Console (DevCon) Tool +description: DevCon enables, disables, installs, configures, and removes devices on the local computer and displays detailed information about devices on local and remote computers. +languages: + - cpp +products: + - windows +--- + - -Device Console (DevCon) Tool -============================ +# Device Console (DevCon) Tool [DevCon](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544707) is a command-line tool that displays detailed information about devices, and lets you search for and manipulate devices from the command line. DevCon enables, disables, installs, configures, and removes devices on the local computer and displays detailed information about devices on local and remote computers. DevCon is included in the WDK. @@ -17,28 +25,26 @@ This document explains the DevCon design, and how to use the SetupAPI and device 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". -Build the sample -------------------------------- +## Build the sample You can build the sample in two ways: using the Visual Studio Integrated Development Environment (IDE) or from the command line using the Visual Studio Command Prompt window and the Microsoft Build Engine (MSBuild.exe). -**Building the sample using Visual Studio** +### Building the sample using Visual Studio -1. Open Visual Studio. From the **File** menu, select **Open Project/Solution**. Navigate to the DevCon sample folder and open the devcon.sln project file. -2. Right-click the solution in the **Solution Explorer** and select **Configuration Manager**. -3. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Debug or Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. -4. From the **Build** menu, click **Build Solution** (Ctrl+Shift+B). +1. Open Visual Studio. From the **File** menu, select **Open Project/Solution**. Navigate to the DevCon sample folder and open the devcon.sln project file. +1. Right-click the solution in the **Solution Explorer** and select **Configuration Manager**. +1. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Debug or Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. +1. From the **Build** menu, click **Build Solution** (Ctrl+Shift+B). Previous versions of the WDK used the Windows Build utility (Build.exe) and provided separate build environment windows for each of the supported build configurations. You can use the Visual Studio Command Prompt window for all build configurations. -**Building the sample using the command line (MSBuild)** +### Building the sample using the command line (MSBuild) -1. Open a Visual Studio Command Prompt window. Click **Start** and search for **Developer Command Prompt**. If your project is under %PROGRAMFILES%, you need to open the command prompt window using elevated permissions (**Run as administrator**). From this window you can use MsBuild.exe to build any Visual Studio project by specifying the project (.VcxProj) or solutions (.Sln) file. -2. Navigate to the project directory and enter the **MSbuild** command for your target. For example, to perform a clean build of a Visual Studio driver project called devcon.vcxproj, navigate to the project directory and enter the following MSBuild command: **msbuild /t:clean /t:build .\\devcon.vcxproj**. -3. If the build succeeds, you will find the tools (devcon.exe) in the binary output directory corresponding to the target platform, for example samples\\setup\\devcon\\Debug. +1. Open a Visual Studio Command Prompt window. Click **Start** and search for **Developer Command Prompt**. If your project is under %PROGRAMFILES%, you need to open the command prompt window using elevated permissions (**Run as administrator**). From this window you can use MsBuild.exe to build any Visual Studio project by specifying the project (.VcxProj) or solutions (.Sln) file. +1. Navigate to the project directory and enter the **MSbuild** command for your target. For example, to perform a clean build of a Visual Studio driver project called devcon.vcxproj, navigate to the project directory and enter the following MSBuild command: **msbuild /t:clean /t:build .\\devcon.vcxproj**. +1. If the build succeeds, you will find the tools (devcon.exe) in the binary output directory corresponding to the target platform, for example samples\\setup\\devcon\\Debug. -Run the sample --------------- +## Run the sample Type "devcon find \*" to list device instances of all present devices on the local machine. @@ -46,71 +52,92 @@ Type "devcon status @root\\rdp\_mou\\0000" to list status of the terminal server Type "devcon status \*PNP05\*" to list status of all COM ports. -How DevCon works: +### How DevCon works -Running "devcon help" will provide a list of commands along with short descriptions of what each command does. "devcon help \" 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: +Running "devcon help" will provide a list of commands along with short descriptions of what each command does. "devcon help \" will give more detailed help on that command. The interpretation of each command is done via a dispatch table "DispatchTable" that is at the bottom of "cmds.cpp". Some of the commands make use of a generic device enumerator "EnumerateDevices". A few of these commands will work when given a remote target computer, and will also work if using the 32-bit devcon on Wow64. + +A description of some of the more interesting functions and the APIs they use follows: cmdClasses -This command demonstrates the use of [**SetupDiBuildClassInfoListEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550911) to enumerate all device class GUID's. The function [**SetupDiClassNameFromGuidEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550950) and [**SetupDiGetClassDescriptionEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551058) are used to obtain more information about each device class. + +- This command demonstrates the use of [**SetupDiBuildClassInfoListEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550911) to enumerate all device class GUID's. The function [**SetupDiClassNameFromGuidEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550950) and [**SetupDiGetClassDescriptionEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551058) are used to obtain more information about each device class. cmdListClass -This command demonstrates the use of [**SetupDiClassGuidsFromNameEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550941) to enumerate one or more class GUID's that match the class name. This command also demonstrates the use of [**SetupDiGetClassDevsEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551072) to list all the devices for each class GUID. + +- This command demonstrates the use of [**SetupDiClassGuidsFromNameEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550941) to enumerate one or more class GUID's that match the class name. This command also demonstrates the use of [**SetupDiGetClassDevsEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551072) to list all the devices for each class GUID. 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. +- 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**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff553534) to update the driver for all devices to a specific driver. Normally INSTALLFLAG\_FORCE would not be specified allowing **UpdateDriverForPlugAndPlayDevices** to determine if there is a better match already known. It's specified in DevCon to allow DevCon to be used more effectively as a debugging/testing tool. This cannot be done on a remote machine or in the context of Wow64. + +- This command shows how to use [**UpdateDriverForPlugAndPlayDevices**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff553534) to update the driver for all devices to a specific driver. Normally INSTALLFLAG\_FORCE would not be specified allowing **UpdateDriverForPlugAndPlayDevices** to determine if there is a better match already known. It's specified in DevCon to allow DevCon to be used more effectively as a debugging/testing tool. This cannot be done on a remote machine or in the context of Wow64. 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. + +- 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. + +- 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. + +- 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**](http://msdn.microsoft.com/en-us/library/windows/hardware/). Adding a Driver Package to the machine doesn't mean the drivers are installed on devices, it simply means the drivers are available automatically when a new device is plugged in or a existing device is updated. + +- This command allows you to add a Driver Package to the machine. The main functionality of this command demonstrates the use of [**SetupCopyOEMInf**](http://msdn.microsoft.com/en-us/library/windows/hardware/). Adding a Driver Package to the machine doesn't mean the drivers are installed on devices, it simply means the drivers are available automatically when a new device is plugged in or a existing device is updated. cmdDPDelete -This command allows you to uninstall a Driver Package from the machine. The main functionality of this command demonstrates the use of [**SetupUninstallOEMInf**](http://msdn.microsoft.com/en-us/library/windows/hardware/). Removing a Driver Package from the machine does not uninstall the drivers associated with a device. If you want to accomplish both then use *cmdRemove* on all the devices using a given Driver Package and then *cmdDPDelete* to remove the Driver Package itself from the machine. + +- This command allows you to uninstall a Driver Package from the machine. The main functionality of this command demonstrates the use of [**SetupUninstallOEMInf**](http://msdn.microsoft.com/en-us/library/windows/hardware/). Removing a Driver Package from the machine does not uninstall the drivers associated with a device. If you want to accomplish both then use *cmdRemove* on all the devices using a given Driver Package and then *cmdDPDelete* to remove the Driver Package itself from the machine. 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). + +- 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). 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. + +- 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**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551072) to enumerate all devices or all present devices, either globally or limited to a specific setup class. Demonstrates the use of [**SetupDiCreateDeviceInfoListEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550958) to create a blank list associated with a class or not (for most cases, a blank list need not be associated with a class). Demonstrates the use of [**SetupDiOpenDeviceInfo**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552071) to add a device instance into a device info list. These last two API's are ideal to obtain a [SP\_DEVINFO\_DATA](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552344) structure from a device instance and machine name when mixing CFGMGR32 API's with SETUPAPI API's. [**SetupDiGetDeviceInfoListDetail**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551103) is called to obtain a remote machine handle that may be passed into CFGMGR32 API's. [**SetupDiEnumDeviceInfo**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551010) is called to enumerate each and every device that is in the device info list (either explicitly added, or determined by the call to **SetupDiGetClassDevsEx**). The instance ID is obtained by calling [**CM\_Get\_Device\_ID\_Ex**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff538411), using information in devInfo (obtained from **SetupDiEnumerateDeviceInfo**) and devInfoListDetail (obtained from **SetupDiGetDeviceInfoListDetail**). *GetHwIds* is called to obtain a list of hardware and compatible ID's (explained below). Once an interesting device has been determined (typically by checking hardware ID's) then the callback is called to operate on that individual device. + +- Demonstrates the use of [**SetupDiGetClassDevsEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551072) to enumerate all devices or all present devices, either globally or limited to a specific setup class. Demonstrates the use of [**SetupDiCreateDeviceInfoListEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550958) to create a blank list associated with a class or not (for most cases, a blank list need not be associated with a class). Demonstrates the use of [**SetupDiOpenDeviceInfo**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552071) to add a device instance into a device info list. These last two API's are ideal to obtain a [SP\_DEVINFO\_DATA](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552344) structure from a device instance and machine name when mixing CFGMGR32 API's with SETUPAPI API's. [**SetupDiGetDeviceInfoListDetail**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551103) is called to obtain a remote machine handle that may be passed into CFGMGR32 API's. [**SetupDiEnumDeviceInfo**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551010) is called to enumerate each and every device that is in the device info list (either explicitly added, or determined by the call to **SetupDiGetClassDevsEx**). The instance ID is obtained by calling [**CM\_Get\_Device\_ID\_Ex**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff538411), using information in devInfo (obtained from **SetupDiEnumerateDeviceInfo**) and devInfoListDetail (obtained from **SetupDiGetDeviceInfoListDetail**). *GetHwIds* is called to obtain a list of hardware and compatible ID's (explained below). Once an interesting device has been determined (typically by checking hardware ID's) then the callback is called to operate on that individual device. GetHwIds -Shows how to get the complete list of hardware ID's or compatible ID's for a device using [**SetupDiGetDeviceRegistryProperty**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551967). + +- Shows how to get the complete list of hardware ID's or compatible ID's for a device using [**SetupDiGetDeviceRegistryProperty**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551967). GetDeviceDescription -Shows how to obtain descriptive information about a device. The friendly name is used if it exists, otherwise the device description is used. + +- 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](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552344) (device info data). + +- Shows how to obtain an instance ID (or use any CFGMGR32 API) given HDEVINFO (device info list) and [PSP\_DEVINFO\_DATA](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552344) (device info data). DumpDeviceStatus -Shows how to interpret the information returned by [**CM\_Get\_DevNode\_Status\_Ex**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff538517). Refer to *cfg.h* for information returned by this API. + +- Shows how to interpret the information returned by [**CM\_Get\_DevNode\_Status\_Ex**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff538517). Refer to *cfg.h* for information returned by this API. DumpDeviceResources -Shows how to obtain information about resources used by a device. + +- 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**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550917) to obtain information about the driver being used for the specified device. The driver list associated with a device may be enumerated by calling [**SetupDiEnumDriverInfo**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551018). In this case, there will be no more than one driver listed. This function proceeds to obtain a list of files that would normally be copied for this driver using DIF\_INSTALLDEVICEFILES. [**SetupScanFileQueue**](http://msdn.microsoft.com/en-us/library/windows/hardware/) is used to enumerate the file queue to display the list of files that are associated with the driver. + +- Provided as a debugging aid, obtains information about the files apparently being used for a device. It uses [**SetupDiBuildDriverInfoList**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550917) to obtain information about the driver being used for the specified device. The driver list associated with a device may be enumerated by calling [**SetupDiEnumDriverInfo**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551018). In this case, there will be no more than one driver listed. This function proceeds to obtain a list of files that would normally be copied for this driver using DIF\_INSTALLDEVICEFILES. [**SetupScanFileQueue**](http://msdn.microsoft.com/en-us/library/windows/hardware/) is used to enumerate the file queue to display the list of files that are associated with the driver. DumpDeviceDriverNodes -Provided as a debugging aid, this function determines the list of compatible drivers for a device. It uses [**SetupDiBuildDriverInfoList**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550917) to obtain the list of compatible drivers. In this case, all drivers are enumerated, however typically DIF\_SELECTBESTCOMPATDRV and [**SetupDiGetSelectedDriver**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552013) would be used together to find which driver the OS would consider to be the best. + +- Provided as a debugging aid, this function determines the list of compatible drivers for a device. It uses [**SetupDiBuildDriverInfoList**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550917) to obtain the list of compatible drivers. In this case, all drivers are enumerated, however typically DIF\_SELECTBESTCOMPATDRV and [**SetupDiGetSelectedDriver**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552013) would be used together to find which driver the OS would consider to be the best. DumpDeviceStack -This function determines class and device upper and lower filters. - +- This function determines class and device upper and lower filters. diff --git a/setup/devcon/setup-devcon.yml b/setup/devcon/setup-devcon.yml deleted file mode 100644 index 41547d72..00000000 --- a/setup/devcon/setup-devcon.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Device Console (DevCon) Tool - description: DevCon enables, disables, installs, configures, and removes devices on the local computer and displays detailed information about devices on local and remote computers. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /setup/devcon/devcon.sln diff --git a/simbatt/README.md b/simbatt/README.md index 24332b56..11dfcf98 100644 --- a/simbatt/README.md +++ b/simbatt/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Simulated Battery Driver Sample +description: Demonstrates a KMDF-based implementation of Windows battery driver interfaces. +languages: + - cpp +products: + - windows +--- + +# SimBatt: Simulated Battery Driver Sample -SimBatt: Simulated Battery Driver Sample -====================================== -SimBatt is simulated battery device driver, this source code is intended to demonstrate implementation of Windows battery driver interfaces. This is a KMDF based sample. You may use this sample as a starting point to implement a battery miniport specific to your needs. \ No newline at end of file +SimBatt is simulated battery device driver, this source code is intended to demonstrate implementation of Windows battery driver interfaces. This is a KMDF based sample. You may use this sample as a starting point to implement a battery miniport specific to your needs. diff --git a/simbatt/simbatt.yml b/simbatt/simbatt.yml deleted file mode 100644 index a78ba609..00000000 --- a/simbatt/simbatt.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Simulated Battery Driver Sample - description: Demonstrates a KMDF-based implementation of Windows battery driver interfaces. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /simbatt/func/simbatt.sln diff --git a/smartcrd/README.md b/smartcrd/README.md index c3b5ca74..2b138313 100644 --- a/smartcrd/README.md +++ b/smartcrd/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: PCMCIA Smart Card Driver +description: Demonstrates how to write a KMDF driver for the SCM Microsystems PCMCIA smart card reader. +languages: + - cpp +products: + - windows +--- + +# PCMCIA Smart Card Driver -PCMCIA Smart Card Driver -======================== - -**Warning, this sample and its documentation are known to be out of date. They will be updated soon. Please be aware that some functionality may not work as expected.** +**Warning: This sample and its documentation are known to be out of date. They will be updated soon. Please be aware that some functionality may not work as expected.** The PCMCIA Smart Card Driver is used for the SCM PCMCIA smart card reader. This driver is written using Kernel-Mode Driver Framework. @@ -21,33 +29,26 @@ Power Management is described in detail in the WDK documentation. There is, howe A card reader will not see any card insertion or removal events in these modes, because the bus might not even have power. The card state must be saved before the reader goes into standby or hibernation mode. After the system returns from these modes, it is necessary to determine what the state of the card is. Card tracking calls must complete whenever there was a card in the reader before standby or hibernation mode or whenever there is a card in the reader after these modes. This step is necessary because the user could have changed the card while the system was in a low-power mode. - -Build the sample ----------------- +## Build the sample For information on how to build a driver solution using Microsoft Visual Studio, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644). **Note** You can obtain the co-installers by downloading the *wdfcoinstaller.msi* package from [WDK 8 Redistributable Components](http://go.microsoft.com/fwlink/p/?LinkID=226396). -Run the sample --------------- +## Run the sample -Installation ------------- +### Installation The PSCR.SYS driver is available from Windows Update. Therefore, when the SCM 488 PCMCIA reader is inserted, the system will automatically install the driver. However, if you want to customize the source code of this driver and replace the driver from Windows Update with your driver, use the supplied INF file. -Tools ------ +## 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. -Resources ---------- +## Resources ISO 7816 Part 3 describes smart cards and smart card protocols in detail. Refer to the PC99 Handbook for smart card reader requirements. For more information about Windows smart card reader drivers, see [Smart Card Reader Devices Design Guide](http://msdn.microsoft.com/en-us/library/windows/hardware/). - diff --git a/smartcrd/smartcrd.yml b/smartcrd/smartcrd.yml deleted file mode 100644 index b9820593..00000000 --- a/smartcrd/smartcrd.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: PCMCIA Smart Card Driver - description: Demonstrates how to write a KMDF driver for the SCM Microsystems PCMCIA smart card reader. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /smartcrd/smartcrd.sln diff --git a/spb/SkeletonI2C/README.md b/spb/SkeletonI2C/README.md index 2e639a9d..02e5002d 100644 --- a/spb/SkeletonI2C/README.md +++ b/spb/SkeletonI2C/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Skeleton I2C Sample Driver +description: Demonstrates how to design a KMDF controller driver for Windows that conforms to the simple peripheral bus (SPB) device driver interface (DDI). +languages: + - cpp +products: + - windows +--- + - -Skeleton I2C Sample Driver -========================== +# Skeleton I2C Sample Driver The SkeletonI2C sample demonstrates how to design a KMDF controller driver for Windows that conforms to the [simple peripheral bus](http://msdn.microsoft.com/en-us/library/windows/hardware/hh450903) (SPB) device driver interface (DDI). SPB is an abstraction for low-speed serial buses (for example, I2C and SPI) that allows peripheral drivers to be developed for cross-platform use without any knowledge of the underlying bus hardware or device connections. While this sample implements an empty I2C driver, it could just as easily be the starting point for an SPI driver with only minor modifications. @@ -17,27 +25,23 @@ Note that the SkeletonI2C sample is simplified to show the overall structure of The simplified structure of the SkeletonI2C sample driver makes it a convenient starting point for development of a real SPB controller driver that manages the hardware functions in an SPB controller. -Modifying the sample --------------------- +## Modifying the sample Here are some high-level points to consider when modifying the SkeletonI2C sample for use on real hardware: -- Edit (and likely rename) Skeletoni2c.h to describe your hardware's register set. -- Modify Controller.cpp and Device.cpp to translate the SPB DDI and primitives into I2C or SPI protocol for your hardware. This includes initialization, I/O configuration, and interrupt processing. -- Address any comments marked with "TODO" in the sample, especially those that short circuit the I/O path to complete requests synchronously. -- Modify the HWID (`ACPI\skeletoni2c`) in Skeletoni2c.inf to match the device node in your firmware. -- Generate and specify a unique trace GUID in I2ctrace.h. -- Refactor the driver name, functions, comments, etc., to better describe your implementation. +- Edit (and likely rename) Skeletoni2c.h to describe your hardware's register set. +- Modify Controller.cpp and Device.cpp to translate the SPB DDI and primitives into I2C or SPI protocol for your hardware. This includes initialization, I/O configuration, and interrupt processing. +- Address any comments marked with "TODO" in the sample, especially those that short circuit the I/O path to complete requests synchronously. +- Modify the HWID (`ACPI\skeletoni2c`) in Skeletoni2c.inf to match the device node in your firmware. +- Generate and specify a unique trace GUID in I2ctrace.h. +- Refactor the driver name, functions, comments, etc., to better describe your implementation. -Code tour ---------- +## Code tour + +### Implementing the SPB DDI The following are relevant functions in the SkeletonI2C driver for implementing the SPB DDI. -Function - -Description - INITIALIZATION `OnDeviceAdd` @@ -90,12 +94,10 @@ Sets the number of bytes completed for a request and invokes the [**SpbRequestCo \*An atomic transfer in SPB is implemented using Sequence or a Lock/Unlock pair. For I2C, this means a set of reads and writes with restarts in between. For SPI, this means a set of reads and writes with the chip select-line asserted throughout. +### Implementing controller-specific I2C protocol + The following are relevant functions in the SkeletonI2C driver for implementing controller-specific I2C protocol. For the most part, these are placeholders and must be filled in appropriately. -Function - -Description - INITIALIZATION `ControllerInitialize` diff --git a/spb/SkeletonI2C/spb-skeletoni2c.yml b/spb/SkeletonI2C/spb-skeletoni2c.yml deleted file mode 100644 index cf7791ae..00000000 --- a/spb/SkeletonI2C/spb-skeletoni2c.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Skeleton I2C Sample Driver - description: Demonstrates how to design a KMDF controller driver for Windows that conforms to the simple peripheral bus (SPB) device driver interface (DDI). - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /spb/SkeletonI2C/SkeletonI2C.sln diff --git a/spb/SpbTestTool/README.md b/spb/SpbTestTool/README.md index fbee4e70..62759b4a 100644 --- a/spb/SpbTestTool/README.md +++ b/spb/SpbTestTool/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: SpbTestTool sample +description: Demonstrates how to open a handle to the SPB controller, use the SPB interface from a KMDF driver, and employ GPIO. +languages: + - cpp +products: + - windows +--- + - -SpbTestTool -=========== +# SpbTestTool The SpbTestTool sample serves two purposes. First, it demonstrates how to open a handle to the [SPB controller](http://msdn.microsoft.com/en-us/library/windows/hardware/hh698220), use the SPB interface from a KMDF driver, and employ GPIO [passive-level interrupts](http://msdn.microsoft.com/en-us/library/windows/hardware/hh451035). Second, it implements a set of commands for communicating with a peripheral device to aid in debugging. This sample is incomplete as a driver and merely demonstrates use of the [SPB I/O request interface](http://msdn.microsoft.com/en-us/library/windows/hardware/hh698224) and [GPIO interrupts](http://msdn.microsoft.com/en-us/library/windows/hardware/hh406467). It is not intended for use in a production environment. -### Run the sample +## Run the sample To install the SpbTestTool peripheral driver, follow these steps: -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: +1. Ensure that the driver builds without errors. +1. Copy the SYS and INF files to a separate folder. +1. Run Devcon.exe. You can find this program in the tools\\devcon folder where you installed the WDK. Type the following command in the command window: `devcon.exe update SpbTestTool.inf ACPI\` To launch the SpbTestTool application, follow these steps: -1. Navigate to the directory that contains SpbTestTool.exe. +1. Navigate to the directory that contains SpbTestTool.exe. -2. Type the following command in the command window: +1. Type the following command in the command window: `SpbTestTool.exe` -3. By default, the SpbTestTool application uses the SpbTestTool sample driver. However, an alternate peripheral driver can be used instead. To specify an alternate driver, use the following format for the command line: +1. By default, the SpbTestTool application uses the SpbTestTool sample driver. However, an alternate peripheral driver can be used instead. To specify an alternate driver, use the following format for the command line: `SpbTestTool.exe /p \\.\` -4. An input script can used instead of an interactive prompt. The script format requires one command per line. To run the script, use the following format for the command line in the command window: +1. An input script can used instead of an interactive prompt. The script format requires one command per line. To run the script, use the following format for the command line in the command window: `SpbTestTool.exe /i ` -### Executing commands +## Executing commands The SpbTestTool application loops indefinitely waiting for one of the following commands. The commands are translated to the appropriate SPB I/O request without any state tracking in the driver. Transfer status, buffer contents, and error codes are returned as necessary. Type `help` at any time to display this command list. Press Ctrl-C at any time to cancel the current command and exit the application. -Command | Description +Command | Description --------|------------ open | Open handle to SPB controller. close | Close handle to SPB controller. @@ -62,11 +68,11 @@ signal | Inform the SpbTestTool driver that the interrupt has been handled. help | Display the list of supported commands. Ctrl-C | Press Ctrl-C at any time to cancel the outstanding command and exit the application. -### Code tour +## Code tour The following are the relevant functions in the SpbTestTool peripheral driver for using the SPB interface from a KMDF driver. -Function | Description +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. @@ -82,7 +88,7 @@ SpbPeripheralOnComplete | Completion callback for all I/O requests. The following are the relevant functions in the SpbTestTool peripheral driver for managing GPIO passive-level interrupts from a KMDF driver. -Function | Description +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. @@ -90,11 +96,11 @@ SpbPeripheralWaitOnInterrupt | Called to pend a WaitOnInterrupt request in the d SpbPeripheralInterruptNotify | Completes an outstanding WaitOnInterrupt request to inform the SpbTestTool app that an interrupt has occurred. SpbPeripheralSignalInterrupt | Notifies the interrupt service routine that the interrupt has been handled and the ISR should return. -### File manifest +## File manifest The following source files are in the \\SpbTestTool\\sys folder and are used to build the SpbTestTool.sys and SpbTestTool.inf files. -File | Description +File | Description -----|------------ driver.h, driver.cpp | Events on the Device Object, and read, write, and IOCTLs from the SpbTestTool application. Implements the driver's interrupt service routine. internal.h | Common includes and typedefs @@ -110,7 +116,7 @@ trace.h | Sets up WPP tracing. The following source files are in the \\SpbTestTool\\exe folder and are used to build the SpbTestTool.exe file. -File | Description +File | Description -----|------------ command.h, command.cpp | Classes respresenting each of the SpbTestTool commands. For the list of commands, see Executing commands. internal.h | Common includes and function definitions @@ -118,5 +124,3 @@ main.cpp | Application entry point, input parsing, and main execution loop. Also makefile | Redirects to the real makefile that is shared by all components of the WDK. sources | Lists source files and build options. util.cpp | Helper functions - - diff --git a/spb/SpbTestTool/spb-spbtesttool.yml b/spb/SpbTestTool/spb-spbtesttool.yml deleted file mode 100644 index 08f40f4f..00000000 --- a/spb/SpbTestTool/spb-spbtesttool.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: SpbTestTool sample - description: Demonstrates how to open a handle to the SPB controller, use the SPB interface from a KMDF driver, and employ GPIO. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /spb/SpbTestTool/SpbTestTool.sln diff --git a/storage/class/cdrom/README.md b/storage/class/cdrom/README.md index 92ddf79b..c299e01b 100644 --- a/storage/class/cdrom/README.md +++ b/storage/class/cdrom/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: CDROM Storage Class Driver +description: Provide access to CD, DVD and Blu-ray drives, supports Plug and Play, Power Management, and AutoRun (media change notification). +languages: + - cpp +products: + - windows +--- + - -CDROM Storage Class Driver -========================== +# CDROM Storage Class Driver 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). -Build the sample ----------------- +## Build the sample You can build the sample in two ways: using Microsoft Visual Studio or the command line (*MSBuild*). **Note:** When building in Visual Studio, INFVerifer will throw errors. This is intended. Fix those errors with your custom values to build successfully. -Building a Driver Using Visual Studio -------------------------------------- +## Building a Driver Using Visual Studio You build a driver the same way you build any project or solution in Visual Studio. When you create a new driver project using a Windows driver template, the template defines a default (active) project configuration and a default (active) solution build configuration. When you create a project from existing driver sources or convert existing driver code that was built with previous versions of the WDK, the conversion process preserves the target version information (operating systems and platform). The default Solution build configuration is Visual Studio Debug and Win32. -### To select a configuration and build a driver or an application +1. Open the driver project or solution in Visual Studio (find *samplename*.sln or *samplename*.vcxproj). +1. Right-click the solution in the **Solutions Explorer** and select **Configuration Manager**. +1. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Debug or Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. +1. From the Build menu, click **Build Solution** (Ctrl+Shift+B). -1. Open the driver project or solution in Visual Studio (find *samplename*.sln or *samplename*.vcxproj). -2. Right-click the solution in the **Solutions Explorer** and select **Configuration Manager**. -3. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Debug or Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. -4. From the Build menu, click **Build Solution** (Ctrl+Shift+B). - -Building a Driver Using the Command Line (MSBuild) --------------------------------------------------- +## Building a Driver Using the Command Line (MSBuild) You can build a driver from the command line using the Visual Studio Command Prompt window and the Microsoft Build Engine (MSBuild.exe) Previous versions of the WDK used the Windows Build utility (Build.exe) and provided separate build environment windows for each of the supported build configurations. You can now use the Visual Studio Command Prompt window for all build configurations. -### To select a configuration and build a driver or an application +1. Open a Visual Studio Command Prompt window at the **Start** screen. From this window you can use MsBuild.exe to build any Visual Studio project by specifying the project (.VcxProj) or solutions (.Sln) file. +1. Navigate to the project directory and enter the **MSbuild** command for your target. For example, to perform a clean build of a Visual Studio driver project called *filtername*.vcxproj, navigate to the project directory and enter the following MSBuild command: -1. Open a Visual Studio Command Prompt window at the **Start** screen. From this window you can use MsBuild.exe to build any Visual Studio project by specifying the project (.VcxProj) or solutions (.Sln) file. -2. Navigate to the project directory and enter the **MSbuild** command for your target. For example, to perform a clean build of a Visual Studio driver project called *filtername*.vcxproj, navigate to the project directory and enter the following MSBuild command: **msbuild /t:clean /t:build .\\***samplename***.vcxproj**. + **msbuild /t:clean /t:build .\\***samplename***.vcxproj**. -Run the sample --------------- - -Installation and Operation --------------------------- +## Installation and Operation The in-box CD ROM driver is protected by the system, and thus a normal device driver update attempt through the Device Manager will fail. Users are not encouraged to replace the in-box CD ROM driver. The following work-around is provided in case there is a need, but the users are warned that this may harm the system. -1. Locate the "cdrom.inf" file in the binary output directory, and update the file by replacing all "cdrom.sys" occurrences with "mycdrom.sys". -2. Rename the "cdrom.inf" file to "mycdrom.inf". -3. Copy "mycdrom.sys" and "mycdrom.inf" from the binary output directory to the test machine, if applicable. -4. Launch the Device Manager -5. Select the appropriate device under the "DVD/CD-ROM drives" category. -6. On the right-click menu, select "Update Driver Software...". -7. Select "Browse my computer for driver software". -8. Select "Let me pick from a list of device drivers on my computer". -9. Click "Have Disk...", and point to the directory that contains "mycdrom.inf" and "mycdrom.sys". -10. Click "Next". If you get a warning dialog about installing unsigned driver, click "Yes". -11. Click "Next" to complete the driver upgrade. -12. After installation completes successfully, "mycdrom.sys" will be the effective driver for the device, "cdrom.sys" will no longer be used. +1. Locate the "cdrom.inf" file in the binary output directory, and update the file by replacing all "cdrom.sys" occurrences with "mycdrom.sys". +1. Rename the "cdrom.inf" file to "mycdrom.inf". +1. Copy "mycdrom.sys" and "mycdrom.inf" from the binary output directory to the test machine, if applicable. +1. Launch the Device Manager +1. Select the appropriate device under the "DVD/CD-ROM drives" category. +1. On the right-click menu, select "Update Driver Software...". +1. Select "Browse my computer for driver software". +1. Select "Let me pick from a list of device drivers on my computer". +1. Click "Have Disk...", and point to the directory that contains "mycdrom.inf" and "mycdrom.sys". +1. Click "Next". If you get a warning dialog about installing unsigned driver, click "Yes". +1. Click "Next" to complete the driver upgrade. +1. After installation completes successfully, "mycdrom.sys" will be the effective driver for the device, "cdrom.sys" will no longer be used. For more information, see [CD-ROM Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551391) in the storage technologies design guide. - diff --git a/storage/class/cdrom/storage-class-cdrom.yml b/storage/class/cdrom/storage-class-cdrom.yml deleted file mode 100644 index 9a18eaa4..00000000 --- a/storage/class/cdrom/storage-class-cdrom.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: CDROM Storage Class Driver - description: Provide access to CD, DVD and Blu-ray drives, supports Plug and Play, Power Management, and AutoRun (media change notification). - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /storage/class/cdrom/cdrom.sln diff --git a/storage/class/classpnp/README.md b/storage/class/classpnp/README.md index ec3c0e9b..69df73f3 100644 --- a/storage/class/classpnp/README.md +++ b/storage/class/classpnp/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: ClassPnP Class Driver Library +description: A library storage class driver used by disk, CDROM, and the tape class drivers. +languages: + - cpp +products: + - windows +--- + +# ClassPnP Storage Class Driver Library -ClassPnP Storage Class Driver Library -===================================== - -This library is the library for all storage drivers. It simplifies writing a storage class driver by implementing 90 percent of the code that you need to support Plug and Play (PnP), power management, and so on. This library is used by disk, CDROM, and the tape class drivers. +This is the library for all storage drivers. It simplifies writing a storage class driver by implementing 90 percent of the code that you need to support Plug and Play (PnP), power management, and so on. This library is used by disk, CDROM, and the tape class drivers. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. -Installation and Operation --------------------------- +## Installation and Operation The storage class drivers are used to interact with mass storage devices along with appropriate port driver. The class drivers are layered above the port drivers and manage mass storage devices of a specific class, regardless of their bus type. The classpnp sample contains the common routines that are required for all storage class drivers such as PnP and power management. It also provides I/O and error handling support. For more information, see [Introduction to Storage Class Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff559215) in the storage technologies design guide. - diff --git a/storage/class/classpnp/storage-class-classpnp.yml b/storage/class/classpnp/storage-class-classpnp.yml deleted file mode 100644 index 727fcb7b..00000000 --- a/storage/class/classpnp/storage-class-classpnp.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: ClassPnP Class Driver Library - description: A library storage class driver used by disk, CDROM, and the tape class drivers. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /storage/class/classpnp/classpnp.sln diff --git a/storage/class/disk/README.md b/storage/class/disk/README.md index c4032547..bc3de773 100644 --- a/storage/class/disk/README.md +++ b/storage/class/disk/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Disk Class Driver +description: A class driver for disk devices. +languages: + - cpp +products: + - windows +--- + - -Disk Class Driver -================= +# Disk Class Driver The disk class driver sample is used for managing disk devices -Build the sample ----------------- - You can build the sample in two ways: using Microsoft Visual Studio or the command line (*MSBuild*). -Building a Driver Using Visual Studio -------------------------------------- +## Building a Driver Using Visual Studio You build a driver the same way you build any project or solution in Visual Studio. When you create a new driver project using a Windows driver template, the template defines a default (active) project configuration and a default (active) solution build configuration. When you create a project from existing driver sources or convert existing driver code that was built with previous versions of the WDK, the conversion process preserves the target version information (operating systems and platform). The default Solution build configuration is Debug and Win32. -### To select a configuration and build a driver or an application +1. Open the driver project or solution in Visual Studio (find *samplename*.sln or *samplename*.vcxproj). +1. Right-click the solution in the **Solutions Explorer** and select **Configuration Manager**. +1. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Debug or Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. +1. From the Build menu, click **Build Solution** (Ctrl+Shift+B). -1. Open the driver project or solution in Visual Studio (find *samplename*.sln or *samplename*.vcxproj). -2. Right-click the solution in the **Solutions Explorer** and select **Configuration Manager**. -3. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Debug or Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. -4. From the Build menu, click **Build Solution** (Ctrl+Shift+B). - -Building a Driver Using the Command Line (MSBuild) --------------------------------------------------- +## Building a Driver Using the Command Line (MSBuild) You can build a driver from the command line using the Visual Studio Command Prompt window and the Microsoft Build Engine (MSBuild.exe) Previous versions of the WDK used the Windows Build utility (Build.exe) and provided separate build environment windows for each of the supported build configurations. You can now use the Visual Studio Command Prompt window for all build configurations. -### To select a configuration and build a driver or an application +1. Open a Visual Studio Command Prompt window at the **Start** screen. From this window you can use MsBuild.exe to build any Visual Studio project by specifying the project (.VcxProj) or solutions (.Sln) file. +1. Navigate to the project directory and enter the **MSbuild** command for your target. For example, to perform a clean build of a Visual Studio driver project called *filtername*.vcxproj, navigate to the project directory and enter the following MSBuild command: **msbuild /t:clean /t:build .\\***samplename***.vcxproj**. -1. Open a Visual Studio Command Prompt window at the **Start** screen. From this window you can use MsBuild.exe to build any Visual Studio project by specifying the project (.VcxProj) or solutions (.Sln) file. -2. Navigate to the project directory and enter the **MSbuild** command for your target. For example, to perform a clean build of a Visual Studio driver project called *filtername*.vcxproj, navigate to the project directory and enter the following MSBuild command: **msbuild /t:clean /t:build .\\***samplename***.vcxproj**. - -Run the sample --------------- - -Installation and Operation --------------------------- +## Installation and Operation The disk class driver is used to interact with disk devices along with the appropriate port driver. The disk class driver is layered above the port driver and manages disk devices regardless of their bus type. This driver attaches to the disk devices that are enumerated by all of the storage port drivers. This driver exposes the required functionality to the file system drivers to access the disk devices. For more information, see [Introduction to Storage Class Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff559215) in the storage technologies design guide. - diff --git a/storage/class/disk/storage-class-disk.yml b/storage/class/disk/storage-class-disk.yml deleted file mode 100644 index 5b97a768..00000000 --- a/storage/class/disk/storage-class-disk.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Disk Class Driver - description: A class driver for disk devices. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /storage/class/disk/disk.sln diff --git a/storage/filters/addfilter/README.md b/storage/filters/addfilter/README.md index 8d3084c4..df1aabe7 100644 --- a/storage/filters/addfilter/README.md +++ b/storage/filters/addfilter/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: AddFilter Storage Filter Tool +description: A command-line application that adds and removes filter drivers for a given drive or volume. +languages: + - cpp +products: + - windows +--- + - -AddFilter Storage Filter Tool -============================= +# AddFilter Storage Filter Tool Addfilter is a command-line application that adds and removes filter drivers for a given drive or volume. This application demonstrates how to insert a filter driver into the driver stack of a device. The sample illustrates how to insert such a filter driver by using the SetupDi API. -Installation and Operation --------------------------- +## Installation and Operation 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 might no longer be accessible. @@ -30,7 +37,6 @@ Because the sample currently enumerates only disk devices, the sample can operat The following is the command line usage for addfilter: -**addfilter [/listdevices] [/device device\_name] [/add filter] [/remove filter]** + **addfilter [/listdevices] [/device device\_name] [/add filter] [/remove filter]** If the device name is not supplied, settings will apply to all devices. If there is no /add or /remove argument, a list of currently installed drivers will be printed. - diff --git a/storage/filters/addfilter/storage-filters-addfilter.yml b/storage/filters/addfilter/storage-filters-addfilter.yml deleted file mode 100644 index 4b23ef39..00000000 --- a/storage/filters/addfilter/storage-filters-addfilter.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: AddFilter Storage Filter Tool - description: A command-line application that adds and removes filter drivers for a given drive or volume. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /storage/filters/addfilter/addfilter.sln diff --git a/storage/iscsi/README.md b/storage/iscsi/README.md index 320e1206..bcaf036e 100644 --- a/storage/iscsi/README.md +++ b/storage/iscsi/README.md @@ -1,20 +1,26 @@ +--- +topic: sample +name: iSCSI WMI Client +description: A WMI iSCSI miniport that can be tested using the iSCSICLI.exe tool, the iSCSI Initiator Properties page, the WBEMTEST.exe tool, and customized WMI scripts. +languages: + - cpp +products: + - windows +--- + - -iSCSI WMI Client -================ +# iSCSI WMI Client WMI Implementation in an iSCSI miniport can be tested using the iSCSICLI.exe tool, the iSCSI Initiator Properties page, the WBEMTEST.exe tool, and customized WMI scripts -Installation and Operation --------------------------- +## Installation and Operation The iSCSI WMI sample uses the iSCSI WMI Class, and MOF definitions described at [iSCSI WMI Classes](http://msdn.microsoft.com/en-us/library/windows/hardware/ff561578) in the storage WMI classes reference. Their corresponding class structure details are described at [iSCSI Structures](http://msdn.microsoft.com/en-us/library/windows/hardware/ff561569). - diff --git a/storage/iscsi/storage-iscsi.yml b/storage/iscsi/storage-iscsi.yml deleted file mode 100644 index e9759d59..00000000 --- a/storage/iscsi/storage-iscsi.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: iSCSI WMI Client - description: A WMI iSCSI miniport that can be tested using the iSCSICLI.exe tool, the iSCSI Initiator Properties page, the WBEMTEST.exe tool, and customized WMI scripts. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /storage/iscsi/iscsi.sln diff --git a/storage/miniports/lsi_u3/README.md b/storage/miniports/lsi_u3/README.md index 2ca91c64..c9ba64ab 100644 --- a/storage/miniports/lsi_u3/README.md +++ b/storage/miniports/lsi_u3/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: LSI_U3 StorPort Miniport Driver +description: An adapter driver for use with Parallel SCSI Host Bus Adapters or on-motherboard solutions that use the LSI 53C1010 SCSI ASIC. +languages: + - cpp +products: + - windows +--- + - -LSI\_U3 StorPort Miniport Driver -================================ +# LSI\_U3 StorPort Miniport Driver The LSI\_U3 sample is an adapter driver for use with Parallel SCSI Host Bus Adapters or on-motherboard solutions that use the LSI 53C1010 SCSI ASIC.These sources are presented for your education and use with these generally available LSI SCSI-class adapters. The intended use of this sample driver is for this purpose only. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. -Installation and Operation --------------------------- +## Installation and Operation The operation of this sample requires one of the following hardware items: -- Parallel SCSI Host Bus Adapter -- On-motherboard solution that uses the LSI 53C1010 SCSI ASIC +- Parallel SCSI Host Bus Adapter +- On-motherboard solution that uses the LSI 53C1010 SCSI ASIC For more information, see [Storport Miniport Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff567562) in the storage technologies design guide. - diff --git a/storage/miniports/lsi_u3/storage-miniports-lsi-u3.yml b/storage/miniports/lsi_u3/storage-miniports-lsi-u3.yml deleted file mode 100644 index 94391734..00000000 --- a/storage/miniports/lsi_u3/storage-miniports-lsi-u3.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: LSI_U3 StorPort Miniport Driver - description: An adapter driver for use with Parallel SCSI Host Bus Adapters or on-motherboard solutions that use the LSI 53C1010 SCSI ASIC. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /storage/miniports/lsi_u3/lsi_u3.sln diff --git a/storage/miniports/storahci/README.md b/storage/miniports/storahci/README.md index ed65a9ff..f5df95e7 100644 --- a/storage/miniports/storahci/README.md +++ b/storage/miniports/storahci/README.md @@ -1,5 +1,15 @@ +--- +topic: sample +name: StorAHCI StorPort Miniport +description: A sample Storport ACHI miniport driver. +languages: + - cpp +products: + - windows +--- + - -StorAhci StorPort Miniport Driver -================================= +# StorAhci StorPort Miniport Driver The StorAhci sample is a Storport ACHI miniport driver. ## Universal Windows Driver Compliant -This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. +This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. diff --git a/storage/miniports/storahci/storage-miniports-storahci.yml b/storage/miniports/storahci/storage-miniports-storahci.yml deleted file mode 100644 index de494421..00000000 --- a/storage/miniports/storahci/storage-miniports-storahci.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: StorAHCI StorPort Miniport - description: A sample Storport ACHI miniport driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /storage/miniports/storahci/storahci.sln diff --git a/storage/msdsm/README.md b/storage/msdsm/README.md index 599dc963..b2ccd0a8 100644 --- a/storage/msdsm/README.md +++ b/storage/msdsm/README.md @@ -1,5 +1,15 @@ +--- +topic: sample +name: Multipath I/O (MPIO) DSM Sample +description: Provides a sample for building vendor-specific device-specific modules (DSM), supports iSCSI and Fibre Channel devices. +languages: + - cpp +products: + - windows +--- + - -Multipath I/O (MPIO) DSM Sample -=============================== +# Multipath I/O (MPIO) DSM Sample The MPIO DSM Sample is intended to serve as an example to follow when building your own vendor specific device specific modules (DSM). This sample DSM supports iSCSI and Fibre Channel devices. - -Build the sample ----------------- - You can build the sample in two ways: using Microsoft Visual Studio or the command line (*MSBuild*). -Building a Driver Using Visual Studio -------------------------------------- +## Building a Driver Using Visual Studio You build a driver the same way you build any project or solution in Visual Studio. When you create a new driver project using a Windows driver template, the template defines a default (active) project configuration and a default (active) solution build configuration. When you create a project from existing driver sources or convert existing driver code that was built with previous versions of the WDK, the conversion process preserves the target version information (operating systems and platform). The default Solution build configuration is **Debug** and **Win32**. -### To select a configuration and build a driver or an application +1. Open the driver project or solution in Visual Studio (find *samplename*.sln or *samplename*.vcxproj). +1. Right-click the solution in the **Solutions Explorer** and select **Configuration Manager**. +1. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Debug or Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. +1. From the Build menu, click **Build Solution** (Ctrl+Shift+B). -1. Open the driver project or solution in Visual Studio (find *samplename*.sln or *samplename*.vcxproj). -2. Right-click the solution in the **Solutions Explorer** and select **Configuration Manager**. -3. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Debug or Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. -4. From the Build menu, click **Build Solution** (Ctrl+Shift+B). - -Building a Driver Using the Command Line (MSBuild) --------------------------------------------------- +## Building a Driver Using the Command Line (MSBuild) You can build a driver from the command line using the Visual Studio Command Prompt window and the Microsoft Build Engine (MSBuild.exe) Previous versions of the WDK used the Windows Build utility (Build.exe) and provided separate build environment windows for each of the supported build configurations. You can now use the Visual Studio Command Prompt window for all build configurations. -### To select a configuration and build a driver or an application +1. Open a Visual Studio Command Prompt window at the **Start** screen. From this window you can use MsBuild.exe to build any Visual Studio project by specifying the project (.VcxProj) or solutions (.Sln) file. +1. Navigate to the project directory and enter the **MSbuild** command for your target. For example, to perform a clean build of a Visual Studio driver project called *filtername*.vcxproj, navigate to the project directory and enter the following MSBuild command: -1. Open a Visual Studio Command Prompt window at the **Start** screen. From this window you can use MsBuild.exe to build any Visual Studio project by specifying the project (.VcxProj) or solutions (.Sln) file. -2. Navigate to the project directory and enter the **MSbuild** command for your target. For example, to perform a clean build of a Visual Studio driver project called *filtername*.vcxproj, navigate to the project directory and enter the following MSBuild command: - **msbuild /t:clean /t:build .\\<*samplename*>.vcxproj**. -Installation and Operation --------------------------- +## Installation and Operation The installation process depends on proper construction of your DSM's INF as well as an installation program provided by you. These are important aspects of complying with the Designed for Windows logo program. The installation was designed to allow for multiple vendors to easily add DSMs and to eliminate rebooting as much as possible. The installation process will require you to update your installation routines and to use the new .INF files. With the new process, you can only modify your DSM's INF file. @@ -54,7 +51,7 @@ The installer sample only needs to be called one time with the INF/driver source The following annotated DSM INF file illustrates the correct format for your DSM. Replace only those items that are in bold italics. Remember, you must not use "GENDSM" or "MSISCDSM" or "MSDSM" as the name of your DSM. Therefore, you must replace any instances of those strings with the proper name of your DSM. -``` +```inf ; ; Copyright (c) . All rights reserved. ; @@ -62,7 +59,7 @@ The following annotated DSM INF file illustrates the correct format for your DSM In the Version section, make sure the DriverVer is correct for your DSM. Ideally it should match the version in the .rc file. You must specify a different catalog file since the MPIO core drivers now come pre-signed: -``` +```inf [Version] Signature = "$WINDOWS NT$" Class = System @@ -84,7 +81,7 @@ DefaultDestDir = 12 Substitute all instances of "gendsm" with the proper name for your DSM. For example, "mydsm": -``` +```inf [std_mfg] %mydsm_devicedesc% = mydsm_install, Root\MYDSM @@ -110,7 +107,7 @@ This next section contains the Hardware ID strings for your devices. You can hav In this sample, there are two different strings: -``` +```inf ; ; The following cannot be grouped (as above) ; @@ -121,7 +118,7 @@ HKLM, "SYSTEM\CurrentControlSet\Control\MPDEV", "MPIOSupportedDeviceList", %REG_ These are valid samples: -``` +```inf HKLM, "SYSTEM\CurrentControlSet\Control\MPDEV", "MPIOSupportedDeviceList", %REG_MULTI_SZ_APPEND%, "MAXTOR ATLASU320_18_WLS" HKLM, "SYSTEM\CurrentControlSet\Control\MPDEV", "MPIOSupportedDeviceList", %REG_MULTI_SZ_APPEND%, "VENDOR3 PROD_PREFIX" @@ -135,7 +132,7 @@ It is advisable to use this format if your storage devices generate product IDs Add one entry for each WMI GUID that you use in your DSM. This is required: -``` +```inf HKLM, "SYSTEM\CurrentControlSet\Control\WMI\Security", "04517f7e-92bb-4ebe-aed0-54339fa5f544",\%REG_BINARY_NOCLOBBER%,\ 01,00,04,80,14,00,00,00,24,00,00,00,00,00,00,00,\ 34,00,00,00,01,02,00,00,00,00,00,05,20,00,00,00,\ @@ -169,14 +166,16 @@ HKLM, "SYSTEM\CurrentControlSet\Control\WMI\Security", "d6dc1bf0-95fa-4246-afd7- Finally, modify the following strings: -``` +```inf [Strings] VNDR = "Your Company Name Here" std_mfg = "(Standard system devices)" mydsm_devicedesc = " Multi-Path Device Specific Module" ``` + The following string is displayed as the friendly name of your DSM: -``` + +```inf mydsm_desc = " Multi-Path DSM" ; @@ -201,15 +200,15 @@ REG_EXPAND_SZ = 0x00020000 REG_DWORD = 0x00010001 REG_BINARY_NOCLOBBER = 0x00030003 ``` + You should be aware of the following when you install the MPIO DSM sample: -1. The install sample assumes that all necessary files have already been copied over to a vendor specific directory (preferably a folder under Program Files) and takes that path as one of the parameters. This eliminates requests for the original media when new devices appear. +1. The install sample assumes that all necessary files have already been copied over to a vendor specific directory (preferably a folder under Program Files) and takes that path as one of the parameters. This eliminates requests for the original media when new devices appear. -2. As the port filter needs to go on top of every adapter that hosts (or might host) a path to the disk, all SCSI adapters are restarted at the end of the install +1. As the port filter needs to go on top of every adapter that hosts (or might host) a path to the disk, all SCSI adapters are restarted at the end of the install It is expected that the adapter that hosts the system volumes (boot/paging) will not restart, but that should not be problem if you are not multipathing the boot volume. However, if you are multipathing the boot volume, you will need to restart the system. **Note** Other filter drivers installed as port filters may interfere with the proper operation of the MPIO port filter. Microsoft does not recommend the use of such filter drivers which may be supplied by HBA miniport vendors. **Note** Since your DSM binary is not signed, you will get Unsigned Driver Pop-Ups. Ignore these and accept the installation of the new driver. Once your package has been successfully qualified by WHQL, your binaries will get signed and your customers will not get unsigned driver popups. - diff --git a/storage/msdsm/storage-msdsm.yml b/storage/msdsm/storage-msdsm.yml deleted file mode 100644 index 24db8baf..00000000 --- a/storage/msdsm/storage-msdsm.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Multipath I/O (MPIO) DSM Sample - description: Provides a sample for building vendor-specific device-specific modules (DSM), supports iSCSI and Fibre Channel devices. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /storage/msdsm/msdsm.sln diff --git a/storage/sfloppy/README.md b/storage/sfloppy/README.md index f5006d90..051c7e35 100644 --- a/storage/sfloppy/README.md +++ b/storage/sfloppy/README.md @@ -1,25 +1,32 @@ +--- +topic: sample +name: Super Floppy (sfloppy) Storage Class Driver +description: A sample class driver for Super Floppy disk drives. +languages: + - cpp +products: + - windows +--- + - -Super Floppy (sfloppy) Storage Class Driver -=========================================== +# Super Floppy (sfloppy) Storage Class Driver The sfloppy sample is a super floppy driver. This driver is a class driver for Super Floppy disk drives. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. -Installation and Operation --------------------------- +## Installation and Operation This sample sits a level above the port driver (ATAPI, USB, and so on) in the driver stack and controls communication between the application level and the port driver. The floppy driver takes requests from file system drivers and then sends the appropriate [**SCSI\_REQUEST\_BLOCK**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff565393) (SRB) to the port driver. For more information, see [Introduction to Storage Class Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff559215) in the storage technologies design guide. - diff --git a/storage/sfloppy/storage-sfloppy.yml b/storage/sfloppy/storage-sfloppy.yml deleted file mode 100644 index 8945a3c8..00000000 --- a/storage/sfloppy/storage-sfloppy.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Super Floppy (sfloppy) Storage Class Driver - description: A sample class driver for Super Floppy disk drives. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /storage/sfloppy/sfloppy.sln diff --git a/storage/tools/spti/README.md b/storage/tools/spti/README.md index 10037d01..7744177c 100644 --- a/storage/tools/spti/README.md +++ b/storage/tools/spti/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: SCSI Pass-Through Interface Tool +description: Demonstrates how to communicate with a SCSI device using pass-through IOCTLs in an application using DeviceIoControl API. +languages: + - cpp +products: + - windows +--- + - -SCSI Pass-Through Interface Tool -================================ +# SCSI Pass-Through Interface Tool The SCSI Pass Through Interface sample demonstrates how to communicate with a SCSI device from Microsoft Win32 applications by using the **DeviceIoControl** API. -Installation and Operation --------------------------- +## Installation and Operation The storage port drivers provide an interface for Win32 applications to send SCSI CBDs (Command Descriptor Block) to SCSI devices. The interfaces are [**IOCTL\_SCSI\_PASS\_THROUGH**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560519) and [**IOCTL\_SCSI\_PASS\_THROUGH\_DIRECT**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560521). Applications can build a pass-through request and send it to the device by using this IOCTL. Two command line parameters can be used with *SPTI.EXE*. The first parameter is mandatory. It is the name of the device to be opened. Typical values for this are drive letters such as "C:", or device names as defined by a class driver such as Scanner0, or the SCSI port driver name, ScsiN:, where N = 0, 1, 2, etc. The second parameter is optional and is used to set the share mode (note that access mode and share mode are different things) and sector size. The default share mode is (FILE\_SHARE\_READ | FILE\_SHARE\_WRITE) and the default sector size is 512. A parameter of "r" changes the share mode to only FILE\_SHARE\_READ. A parameter of "w" changes the share mode to only FILE\_SHARE\_WRITE. A parameter of "c" changes the share mode to only FILE\_SHARE\_READ and also changes the sector size to 2048. Typically, a CD-ROM device would use the "c" parameter. - diff --git a/storage/tools/spti/storage-tools-spti.yml b/storage/tools/spti/storage-tools-spti.yml deleted file mode 100644 index c8cc5267..00000000 --- a/storage/tools/spti/storage-tools-spti.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: SCSI Pass-Through Interface Tool - description: Demonstrates how to communicate with a SCSI device using pass-through IOCTLs in an application using DeviceIoControl API. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /storage/tools/spti/spti.sln diff --git a/thermal/simsensor/README.md b/thermal/simsensor/README.md index a2537ce5..c46d022a 100644 --- a/thermal/simsensor/README.md +++ b/thermal/simsensor/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: SimSensor - Simulated Temperature Sensor Sample Driver +description: Demonstrates a simulated temperature sensor device. +languages: + - cpp +products: + - windows +--- + - -SimSensor: Simulated Temperature Sensor Sample Driver -===================================================== +# SimSensor: Simulated Temperature Sensor Sample Driver This sample is a driver for a simulated temperature sensor device. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. A hardware platform designer can strategically place temperature sensors in various thermal zones around the platform. The operating system gets the temperature readings from the temperature sensor drivers and uses these readings to regulate the temperatures across the platform. Regulation can be either passive or active. For more information, see [Device-Level Thermal Management](http://msdn.microsoft.com/en-us/library/windows/hardware/hh698236). diff --git a/thermal/simsensor/thermal-simsensor.yml b/thermal/simsensor/thermal-simsensor.yml deleted file mode 100644 index 085e4db6..00000000 --- a/thermal/simsensor/thermal-simsensor.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: SimSensor - Simulated Temperature Sensor Sample Driver - description: Demonstrates a simulated temperature sensor device. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /thermal/simsensor/simsensor.sln diff --git a/thermal/thermalclient/README.md b/thermal/thermalclient/README.md index e5812871..519345b7 100644 --- a/thermal/thermalclient/README.md +++ b/thermal/thermalclient/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: SimThermalClient - Simulated Thermal Client Sample Driver +description: Simulates a device that is a Windows thermal management client. +languages: + - cpp +products: + - windows +--- + - -SimThermalClient: Simulated Thermal Client Sample Driver -======================================================== +# SimThermalClient: Simulated Thermal Client Sample Driver This sample is a driver for a simulated device that is a client of Windows thermal management. This driver publishes a [GUID\_THERMAL\_COOLING\_INTERFACE](http://msdn.microsoft.com/en-us/library/windows/hardware/hh698265) driver interface. Drivers publish this interface so that they can participate in global thermal management under the coordination of the Windows operating system. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. For more information, see [Device-Level Thermal Management](http://msdn.microsoft.com/en-us/library/windows/hardware/hh698236). diff --git a/thermal/thermalclient/thermal-thermalclient.yml b/thermal/thermalclient/thermal-thermalclient.yml deleted file mode 100644 index 1c0f955b..00000000 --- a/thermal/thermalclient/thermal-thermalclient.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: SimThermalClient - Simulated Thermal Client Sample Driver - description: Simulates a device that is a Windows thermal management client. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /thermal/thermalclient/thermalclient.sln diff --git a/tools/dv/samples/DV-FailDriver-WDM/README.md b/tools/dv/samples/DV-FailDriver-WDM/README.md index 9851ff31..f8675419 100644 --- a/tools/dv/samples/DV-FailDriver-WDM/README.md +++ b/tools/dv/samples/DV-FailDriver-WDM/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: DV-FailDriver-WDM +description: Demonstrates how Driver Verifier (DV) can find errors in a WDM driver. +languages: + - cpp +products: + - windows +--- + - -DV-FailDriver-WDM -================= +# DV-FailDriver-WDM The DV-FailDriver-WDM sample driver contains intentional code errors that are designed to show the capabilities and features of [Driver Verifier](https://msdn.microsoft.com/en-us/library/windows/hardware/ff545448) (DV) and the [Device Fundamentals tests](https://msdn.microsoft.com/en-us/library/windows/hardware/jj673011). Driver Verifier is a component of the Windows kernel designed to detect drivers that are behaving poorly and stop their execution via a bugcheck; the Device Fundamentals tests are a series of tests provided in the Windows Driver Kit (WDK) designed to provide a good basic set of tests against a driver. **Caution** This sample driver contains intentional code errors that are designed to show the capabilities and features of DV and SDV. This sample driver is not intended as an example for real driver development projects. -Build the sample for desktop --------------- -1. In the **Solutions Explorer** window, select the driver solution (DV-FailDriver-WDM). +## Build the sample for desktop -2. From the **Build** menu, select **Build Solution**. +1. In the **Solutions Explorer** window, select the driver solution (DV-FailDriver-WDM). + +1. From the **Build** menu, select **Build Solution**. + +## Deploy the sample -Deploy the sample --------------- See [Deploying a Driver to a Test Computer](https://msdn.microsoft.com/en-us/library/windows/hardware/hh454834) for details on how to deploy the sample. -Test the sample --------------- +## Test the sample + See [How to test a driver at runtime](https://msdn.microsoft.com/en-us/library/windows/hardware/ff554820) for details on how to run tests on the Toastmon driver. -To observe the injected defect being caught by DV, you should enable DV on the Toastmon driver, and then run the "DF - PNP Surprise Remove (Development and Integration)" test on the Toastmon sample driver and device. \ No newline at end of file +To observe the injected defect being caught by DV, you should enable DV on the Toastmon driver, and then run the "DF - PNP Surprise Remove (Development and Integration)" test on the Toastmon sample driver and device. diff --git a/tools/dv/samples/DV-FailDriver-WDM/tools-dv-samples-dv-faildriver-wdm.yml b/tools/dv/samples/DV-FailDriver-WDM/tools-dv-samples-dv-faildriver-wdm.yml deleted file mode 100644 index 86c935f6..00000000 --- a/tools/dv/samples/DV-FailDriver-WDM/tools-dv-samples-dv-faildriver-wdm.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: DV-FailDriver-WDM - description: Demonstrates how Driver Verifier (DV) can find errors in a WDM driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /tools/dv/samples/DV-FailDriver-WDM/driver/DV-FailDriver-WDM.sln diff --git a/tools/sdv/samples/SDV-FailDriver-KMDF/README.md b/tools/sdv/samples/SDV-FailDriver-KMDF/README.md index 6d4d71cd..cdabde42 100644 --- a/tools/sdv/samples/SDV-FailDriver-KMDF/README.md +++ b/tools/sdv/samples/SDV-FailDriver-KMDF/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: SDV-FailDriver-KMDF +description: Demonstrates how Static Driver Verifier (SDV) can find errors in a KMDF driver. +languages: + - cpp +products: + - windows +--- + - -SDV-FailDriver-KMDF -=================== +# SDV-FailDriver-KMDF The SDV-FailDriver-KMDF sample driver contains intentional code errors that are designed to show the capabilities and features of [Static Driver Verifier](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552808) (SDV). SDV is a static verification tool that systematically analyzes the source code of Windows kernel-mode drivers. SDV is included in the Windows Driver Kit (WDK) and can be run from Microsoft Visual Studio. The sample demonstrates how SDV can find errors in a KMDF driver. **Caution** These sample drivers contain intentional code errors that are designed to show the capabilities and features of SDV. These sample drivers are not functional and are not intended as examples for real driver development projects. -Run the sample --------------- +## Run the sample -1. In the **Solutions Explorer** window, select the driver project (fail\_driver1). +1. In the **Solutions Explorer** window, select the driver project (fail\_driver1). From the **Driver** menu, click **Launch Static Driver Verifier...**. This opens the Static Driver Verifier application, where you can control, configure, and schedule when Static Driver Verifier performs an analysis. -2. The fail\_driver1 sample driver includes a library. To add the library, click the **Libraries** tab and click **Add Library**. +1. The fail\_driver1 sample driver includes a library. To add the library, click the **Libraries** tab and click **Add Library**. Browse to the sample library directory and select the library project file (fail\_library1.vcxProj). The library must be added before SDV analyzes the driver. For more information, see [Library Processing in Static Driver Verifier](http://msdn.microsoft.com/en-us/library/windows/hardware/ff548182). -3. Click the **Rules** tab to select which driver DDI usage rules to verify when you start the analysis. +1. Click the **Rules** tab to select which driver DDI usage rules to verify when you start the analysis. Static Driver Verifier detects the type of driver you are analyzing (WDF, WDM, NDIS, or Storport) and selects the default set of rules for your driver type. If this is the first time you are running SDV on your driver, you should run the default rule set. To shorten the amount of time it takes to analyze the fail\_driver1 driver sample, you can select the **Custom rule selection**. Use the default rule set, or select **Custom rule selection**, click **Clear All**, and then select the following rules for the KMDF fail\_driver1 sample: - - [DriverCreate](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544957) - - [DeviceInitAPI](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544843) - - [CtlDeviceFinishInitDeviceAdd](http://msdn.microsoft.com/en-us/library/windows/hardware/ff543607) - - [MdlAfterReqCompletedIoctl](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549047) - - [MemAfterReqCompletedIntIoctlA](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549090) - - [MdlAfterReqCompletedIntIoctlA](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549042) - - [MarkCancOnCancReqLocal](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549011) - - [StopAckWithinEvtIoStop](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552846) + - [DriverCreate](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544957) + - [DeviceInitAPI](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544843) + - [CtlDeviceFinishInitDeviceAdd](http://msdn.microsoft.com/en-us/library/windows/hardware/ff543607) + - [MdlAfterReqCompletedIoctl](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549047) + - [MemAfterReqCompletedIntIoctlA](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549090) + - [MdlAfterReqCompletedIntIoctlA](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549042) + - [MarkCancOnCancReqLocal](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549011) + - [StopAckWithinEvtIoStop](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552846) For information about the rules, see [DDI Compliance Rules](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552840). -4. Start the static analysis. Click the **Main** tab, and then click **Start**. When you click **Start**, a message is displayed to let you know that static analysis is scheduled and that the analysis can take a long time to run. Click **OK** to continue. +1. Start the static analysis. Click the **Main** tab, and then click **Start**. When you click **Start**, a message is displayed to let you know that static analysis is scheduled and that the analysis can take a long time to run. Click **OK** to continue. -View and analyze the results ----------------------------- +## View and analyze the results As the static analysis proceeds, SDV reports the status of the analysis. When the analysis is complete, SDV reports the results and statistics. If the driver fails to satisfy a DDI usage rule, the result is reported as a defect. SDV finds 8 defects in this sample. On the **Main** tab, under **Results**, click the **Rules** tab. This tab displays the name of each rule that was verified in the last run and the results of the analysis. To view the reported defects, click the **Defect** link in the **Results** column. This opens the [Static Driver Verifier Report Page](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552834) and the [Trace Viewer](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544659), which displays a trace of the code path to the rule violation. For more information, see [Interpreting Static Driver Verifier Results](http://msdn.microsoft.com/en-us/library/windows/hardware/ff547228). - diff --git a/tools/sdv/samples/SDV-FailDriver-KMDF/tools-sdv-samples-sdv-faildriver-kmdf.yml b/tools/sdv/samples/SDV-FailDriver-KMDF/tools-sdv-samples-sdv-faildriver-kmdf.yml deleted file mode 100644 index 2c6d9197..00000000 --- a/tools/sdv/samples/SDV-FailDriver-KMDF/tools-sdv-samples-sdv-faildriver-kmdf.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: SDV-FailDriver-KMDF - description: Demonstrates how Static Driver Verifier (SDV) can find errors in a KMDF driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /tools/sdv/samples/SDV-FailDriver-KMDF/SDV-FailDriver-KMDF.sln diff --git a/tools/sdv/samples/SDV-FailDriver-NDIS/README.md b/tools/sdv/samples/SDV-FailDriver-NDIS/README.md index eaf5dc56..8d34e009 100644 --- a/tools/sdv/samples/SDV-FailDriver-NDIS/README.md +++ b/tools/sdv/samples/SDV-FailDriver-NDIS/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: SDV-FailDriver-NDIS +description: Demonstrates how Static Driver Verifier (SDV) can find errors in a NDIS driver. +languages: + - cpp +products: + - windows +--- + - -SDV-FailDriver-NDIS -=================== +# SDV-FailDriver-NDIS The SDV-FailDriver-NDIS sample driver contains intentional code errors that are designed to show the capabilities and features of [Static Driver Verifier](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552808) (SDV). SDV is a static verification tool that systematically analyzes the source code of Windows kernel-mode drivers. SDV is included in the Windows Driver Kit (WDK) and can be run from Microsoft Visual Studio. The sample demonstrates how SDV can find errors in an NDIS driver. **Caution** These sample drivers contain intentional code errors that are designed to show the capabilities and features of SDV. These sample drivers are not functional and are not intended as examples for real driver development projects. -Run the sample --------------- +## Run the sample -1. In the **Solutions Explorer** window, select the driver project (sdvmp.vcxProj). +1. In the **Solutions Explorer** window, select the driver project (sdvmp.vcxProj). From the **Driver** menu, click **Launch Static Driver Verifier...**. This opens the Static Driver Verifier application, where you can control, configure, and schedule when Static Driver Verifier performs an analysis. -2. Click the **Rules** tab to select which driver DDI usage rules to verify when you start the analysis. +1. Click the **Rules** tab to select which driver DDI usage rules to verify when you start the analysis. Static Driver Verifier detects the type of driver you are analyzing (WDF, WDM, NDIS, or Storport) and selects the default set of rules for your driver type. If this is the first time you are running SDV on your driver, you should run the default rule set. To shorten the amount of time it takes to analyze the sample driver, you can select the **Custom rule selection**. Use the default rule set, or select **Custom rule selection**, click **Clear All**, and then select the following rules for the NDIS sdvmp sample: - - [NdisAllocateMemoryWithTagPriority](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549326) - - [Init\_RegisterSG](http://msdn.microsoft.com/en-us/library/windows/hardware/ff547153) - - [NdisStallExecution\_Delay](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549332) - - [Flags\_Irql](http://msdn.microsoft.com/en-us/library/windows/hardware/ff546123) - - [Irql\_Synch\_Function](http://msdn.microsoft.com/en-us/library/windows/hardware/ff548015) + - [NdisAllocateMemoryWithTagPriority](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549326) + - [Init\_RegisterSG](http://msdn.microsoft.com/en-us/library/windows/hardware/ff547153) + - [NdisStallExecution\_Delay](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549332) + - [Flags\_Irql](http://msdn.microsoft.com/en-us/library/windows/hardware/ff546123) + - [Irql\_Synch\_Function](http://msdn.microsoft.com/en-us/library/windows/hardware/ff548015) For information about the rules, see [DDI Compliance Rules](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552840). -3. Start the static analysis. Click the **Main** tab, and click **Start**. When you click **Start**, a message is displayed to let you know that static analysis is scheduled and that the analysis can take a long time to run. Click **OK** to continue. +1. Start the static analysis. Click the **Main** tab, and click **Start**. When you click **Start**, a message is displayed to let you know that static analysis is scheduled and that the analysis can take a long time to run. Click **OK** to continue. -View and analyze the results ----------------------------- +## View and analyze the results As the static analysis proceeds, SDV reports the status of the analysis. When the analysis is complete, SDV reports the results and statistics. If the driver fails to satisfy a DDI usage rule, the result is reported as a defect. SDV finds 5 defects in this sample. On the **Main** tab, under **Results**, click the **Rules** tab. This tab displays the name of each rule that was verified in the last run and the results of the analysis. To view the reported defects, click the **Defect** link in the **Results** column. This opens the [Static Driver Verifier Report Page](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552834) and the [Trace Viewer](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544659), which displays a trace of the code path to the rule violation. For more information, see [Interpreting Static Driver Verifier Results](http://msdn.microsoft.com/en-us/library/windows/hardware/ff547228). - diff --git a/tools/sdv/samples/SDV-FailDriver-NDIS/tools-sdv-samples-sdv-faildriver-ndis.yml b/tools/sdv/samples/SDV-FailDriver-NDIS/tools-sdv-samples-sdv-faildriver-ndis.yml deleted file mode 100644 index 13804411..00000000 --- a/tools/sdv/samples/SDV-FailDriver-NDIS/tools-sdv-samples-sdv-faildriver-ndis.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: SDV-FailDriver-NDIS - description: Demonstrates how Static Driver Verifier (SDV) can find errors in a NDIS driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /tools/sdv/samples/SDV-FailDriver-NDIS/SDV-FailDriver-NDIS.sln diff --git a/tools/sdv/samples/SDV-FailDriver-STORPORT/README.md b/tools/sdv/samples/SDV-FailDriver-STORPORT/README.md index 600b0023..e8792507 100644 --- a/tools/sdv/samples/SDV-FailDriver-STORPORT/README.md +++ b/tools/sdv/samples/SDV-FailDriver-STORPORT/README.md @@ -1,51 +1,56 @@ +--- +topic: sample +name: SDV-FailDriver-STORPORT +description: Demonstrates how Static Driver Verifier (SDV) can find errors in a Storport driver. +languages: + - cpp +products: + - windows +--- + - -SDV-FailDriver-STORPORT -======================= +# SDV-FailDriver-STORPORT The SDV-FailDriver-Storport sample driver contains intentional code errors that are designed to show the capabilities and features of [Static Driver Verifier](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552808) (SDV). SDV is a static verification tool that systematically analyzes the source code of Windows kernel-mode drivers. SDV is included in the Windows Driver Kit (WDK) and can be run from Microsoft Visual Studio. The sample demonstrates how SDV can find errors in a Storport driver. **Caution** These sample drivers contain intentional code errors that are designed to show the capabilities and features of SDV. These sample drivers are not functional and are not intended as examples for real driver development projects. -Run the sample --------------- +## Run the sample -1. In the **Solutions Explorer** window, select the driver project (lsi\_u3.vcxProj). +1. In the **Solutions Explorer** window, select the driver project (lsi\_u3.vcxProj). From the **Driver** menu, click **Launch Static Driver Verifier...**. This opens the Static Driver Verifier application, where you can control, configure, and schedule when Static Driver Verifier performs an analysis. -2. Click the **Rules** tab to select which driver DDI usage rules to verify when you start the analysis. +1. Click the **Rules** tab to select which driver DDI usage rules to verify when you start the analysis. Static Driver Verifier detects the type of driver you are analyzing (WDF, WDM, NDIS, or Storport) and selects the default set of rules for your driver type. If this is the first time you are running SDV on your driver, you should run the default rule set. To shorten the amount of time it takes to analyze the sample driver, you can select the **Custom rule selection**. Use the default rule set, or select **Custom rule selection**, click **Clear All**, and then select the following rules for the Storport sample: - - [StorPortAllocatePool2 Rule (Storport)](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454259) - - [StorPortDeprecated Rule (Storport)](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454263) - - [StorPortEnablePassive Rule (Storport)](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454264) - - [StorPortNotification2 Rule (Storport)](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454268) - - [StorPortSpinLock Rule (Storport)](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454273) - - [StorPortStartIo Rule (Storport)](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454274) - - [StorPortStatusPending Rule (Storport)](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454275) + - [StorPortAllocatePool2 Rule (Storport)](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454259) + - [StorPortDeprecated Rule (Storport)](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454263) + - [StorPortEnablePassive Rule (Storport)](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454264) + - [StorPortNotification2 Rule (Storport)](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454268) + - [StorPortSpinLock Rule (Storport)](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454273) + - [StorPortStartIo Rule (Storport)](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454274) + - [StorPortStatusPending Rule (Storport)](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454275) For information about the rules, see [DDI Compliance Rules](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552840). -3. Start the static analysis. Click the **Main** tab, and click **Start**. When you click **Start**, a message is displayed to let you know that static analysis is scheduled and that the analysis can take a long time to run. Click **OK** to continue. +1. Start the static analysis. Click the **Main** tab, and click **Start**. When you click **Start**, a message is displayed to let you know that static analysis is scheduled and that the analysis can take a long time to run. Click **OK** to continue. -View and analyze the results ----------------------------- +## View and analyze the results As the static analysis proceeds, SDV reports the status of the analysis. When the analysis is complete, SDV reports the results and statistics. If the driver fails to satisfy a DDI usage rule, the result is reported as a defect. SDV finds 7 defects in this sample. On the **Main** tab, under **Results**, click the **Rules** tab. This tab displays the name of each rule that was verified in the last run and the results of the analysis. To view the reported defects, click the **Defect** link in the **Results** column. This opens the [Static Driver Verifier Report Page](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552834) and the [Trace Viewer](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544659), which displays a trace of the code path to the rule violation. For more information, see [Interpreting Static Driver Verifier Results](http://msdn.microsoft.com/en-us/library/windows/hardware/ff547228). - diff --git a/tools/sdv/samples/SDV-FailDriver-STORPORT/tools-sdv-samples-sdv-faildriver-storport.yml b/tools/sdv/samples/SDV-FailDriver-STORPORT/tools-sdv-samples-sdv-faildriver-storport.yml deleted file mode 100644 index 81734590..00000000 --- a/tools/sdv/samples/SDV-FailDriver-STORPORT/tools-sdv-samples-sdv-faildriver-storport.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: SDV-FailDriver-STORPORT - description: Demonstrates how Static Driver Verifier (SDV) can find errors in a Storport driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /tools/sdv/samples/SDV-FailDriver-STORPORT/SDV-FailDriver-STORPORT.sln diff --git a/tools/sdv/samples/SDV-FailDriver-WDM/README.md b/tools/sdv/samples/SDV-FailDriver-WDM/README.md index a32fbcf5..00bf64ee 100644 --- a/tools/sdv/samples/SDV-FailDriver-WDM/README.md +++ b/tools/sdv/samples/SDV-FailDriver-WDM/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: SDV-FailDriver-WDM +description: Demonstrates how Static Driver Verifier (SDV) can find errors in a WDM driver. +languages: + - cpp +products: + - windows +--- + - -SDV-FailDriver-WDM -================== +# SDV-FailDriver-WDM The SDV-FailDriver-WDM sample driver contains intentional code errors that are designed to show the capabilities and features of [Static Driver Verifier](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552808) (SDV). SDV is a static verification tool that systematically analyzes the source code of Windows kernel-mode drivers. SDV is included in the Windows Driver Kit (WDK) and can be run from Microsoft Visual Studio. The sample demonstrates how SDV can find errors in a WDM driver. **Caution** These sample drivers contain intentional code errors that are designed to show the capabilities and features of SDV. These sample drivers are not functional and are not intended as examples for real driver development projects. -Run the sample --------------- +## Run the sample -1. In the **Solutions Explorer** window, select the driver project (fail\_driver1). +1. In the **Solutions Explorer** window, select the driver project (fail\_driver1). From the **Driver** menu, click **Launch Static Driver Verifier...**. This opens the Static Driver Verifier application, where you can control, configure, and schedule when Static Driver Verifier performs an analysis. -2. Click the **Rules** tab to select which driver DDI usage rules to verify when you start the analysis. +1. Click the **Rules** tab to select which driver DDI usage rules to verify when you start the analysis. Static Driver Verifier detects the type of driver you are analyzing (WDF, WDM, NDIS, or Storport) and selects the default set of rules for your driver type. If this is the first time you are running SDV on your driver, you should run the default rule set. To shorten the amount of time it takes to analyze the fail\_driver1 driver sample, you can select the **Custom rule selection**. Use the default rule set, or select **Custom rule selection**, click **Clear All**, and then select the following rules for the WDM fail\_driver1 sample: - - [CancelSpinLock](http://msdn.microsoft.com/en-us/library/windows/hardware/ff542478) - - [IrqlIoApcLte](http://msdn.microsoft.com/en-us/library/windows/hardware/ff547759) - - [IrqlKeSetEvent](http://msdn.microsoft.com/en-us/library/windows/hardware/ff547835) - - [LowerDriverReturn](http://msdn.microsoft.com/en-us/library/windows/hardware/ff548273) - - [SpinLock (WDM)](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551861) + - [CancelSpinLock](http://msdn.microsoft.com/en-us/library/windows/hardware/ff542478) + - [IrqlIoApcLte](http://msdn.microsoft.com/en-us/library/windows/hardware/ff547759) + - [IrqlKeSetEvent](http://msdn.microsoft.com/en-us/library/windows/hardware/ff547835) + - [LowerDriverReturn](http://msdn.microsoft.com/en-us/library/windows/hardware/ff548273) + - [SpinLock (WDM)](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551861) For information about the rules, see [DDI Compliance Rules](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552840). -3. Start the static analysis. Click the **Main** tab, and click **Start**. When you click **Start**, a message is displayed to let you know that static analysis is scheduled and that the analysis can take a long time to run. Click **OK** to continue. +1. Start the static analysis. Click the **Main** tab, and click **Start**. When you click **Start**, a message is displayed to let you know that static analysis is scheduled and that the analysis can take a long time to run. Click **OK** to continue. -View and analyze the results ----------------------------- +## View and analyze the results As the static analysis proceeds, SDV reports the status of the analysis. When the analysis is complete, SDV reports the results and statistics. If the driver fails to satisfy a DDI usage rule, the result is reported as a defect. SDV finds 5 defects in this sample. To view specific defects in the [Static Driver Verifier Report](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552834), click the Defect in the **Results** pane. This opens the [Trace Viewer](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544659), which displays a trace of the code path to the rule violation. For more information, see [Interpreting Static Driver Verifier Results](http://msdn.microsoft.com/en-us/library/windows/hardware/ff547228). - diff --git a/tools/sdv/samples/SDV-FailDriver-WDM/tools-sdv-samples-sdv-faildriver-wdm.yml b/tools/sdv/samples/SDV-FailDriver-WDM/tools-sdv-samples-sdv-faildriver-wdm.yml deleted file mode 100644 index a746c40c..00000000 --- a/tools/sdv/samples/SDV-FailDriver-WDM/tools-sdv-samples-sdv-faildriver-wdm.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: SDV-FailDriver-WDM - description: Demonstrates how Static Driver Verifier (SDV) can find errors in a WDM driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /tools/sdv/samples/SDV-FailDriver-WDM/SDV-FailDriver-WDM.sln diff --git a/usb/UcmCxUcsi/README.md b/usb/UcmCxUcsi/README.md index 3ebd5d5d..46fac17e 100644 --- a/usb/UcmCxUcsi/README.md +++ b/usb/UcmCxUcsi/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: UcmTcpciCx Port Controller Client Driver +description: Demonstrates how to create a Windows USB Type-C port controller driver using the USB Connector Manager class extension driver (UcmCx). +languages: + - cpp +products: + - windows +--- + - # UcmTcpciCx Port Controller Client Driver This is a sample driver that shows how to create a Windows USB Type-C port controller driver using the USB Connector Manager class extension driver (UcmCx). The sample is a driver for an embedded controller which is complient with the [USB Type-C Connector System Software Interface (UCSI)](http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html). @@ -22,38 +31,41 @@ Microsoft already provides an inbox UCSI driver, UcmUcsi.sys. This UcmCxUcsi sam This sample demonstrates the following: -- Registration with the USB Connector Manager (UCM) class extension driver. -- Initializing the port controller's Type-C and Power Delivery capabilities. -- Performing data and power role swaps requested by UCM -- Notifying UCM of Type-C and Power Delivery events on the connector. +- Registration with the USB Connector Manager (UCM) class extension driver. +- Initializing the port controller's Type-C and Power Delivery capabilities. +- Performing data and power role swaps requested by UCM +- Notifying UCM of Type-C and Power Delivery events on the connector. ## Customizing the sample for your port controller + This sample is specific to UCSI systems. You may choose to structure your driver in a similar way for your own hardware. Understand the requirements and specification of your own system prior to writing a new UcmCx client driver. In addition to making the logic and functionality suit your specific port controller hardware, you will need to modify the .inf such that it matches your device's information. -### UcmCxUcsi structure +## UcmCxUcsi structure In this sample, UCM-specific interactions are split apart from most of the UCSI-specific operations. -#### UcmCx Interactions +### UcmCx interactions + The following files contain methods that interface with UcmCx. -- UcmCallbacks.cpp - - Contains the implementations [EVT_UCM_CONNECTOR_SET_DATA_ROLE](https://msdn.microsoft.com/en-us/library/windows/hardware/mt187818(v=vs.85).aspx) and [EVT_UCM_CONNECTOR_SET_POWER_ROLE](https://msdn.microsoft.com/en-us/library/windows/hardware/mt187818(v=vs.85).aspx). These are callbacks from UCM which ask the client driver to perform role swaps. -- UcmNotifications.cpp - - Contains methods that communicate with UcmCx using the client driver support methods described in the [USB Type-C connector driver programming reference](https://msdn.microsoft.com/en-us/library/windows/hardware/mt188011(v=vs.85).aspx). +- UcmCallbacks.cpp + - Contains the implementations [EVT_UCM_CONNECTOR_SET_DATA_ROLE](https://msdn.microsoft.com/en-us/library/windows/hardware/mt187818(v=vs.85).aspx) and [EVT_UCM_CONNECTOR_SET_POWER_ROLE](https://msdn.microsoft.com/en-us/library/windows/hardware/mt187818(v=vs.85).aspx). These are callbacks from UCM which ask the client driver to perform role swaps. +- UcmNotifications.cpp + - Contains methods that communicate with UcmCx using the client driver support methods described in the [USB Type-C connector driver programming reference](https://msdn.microsoft.com/en-us/library/windows/hardware/mt188011(v=vs.85).aspx). - Fdo.cpp - - FDO callbacks, functions, and types, most of which do not interface with UCM. However, the method `Fdo_EvtDeviceSelfManagedIoInit` contains the code segment which initializes the device with UCM. + - FDO callbacks, functions, and types, most of which do not interface with UCM. However, the method `Fdo_EvtDeviceSelfManagedIoInit` contains the code segment which initializes the device with UCM. + +### UCSI and WDF Interactions -#### UCSI and WDF Interactions The remainder of the files perform operations for UCSI and WDF, non-specific to UCM. - Acpi.cpp - - ACPI method evaluation helper routines. + - ACPI method evaluation helper routines. - Driver.cpp - - Entry point to the driver. Initializes the driver with WDF. + - Entry point to the driver. Initializes the driver with WDF. - Ppm.cpp - - Type-C Platform Policy Manager. Main interface to talk to the UCSI-compliant hardware. - + - Type-C Platform Policy Manager. Main interface to talk to the UCSI-compliant hardware. ## When to write a UcmCx client driver -UcmCx is intended for system port controller drivers. If you are bringing up a USB Type-C peripheral, you do not need to write a USB Type-C specific driver; a regular USB client driver will suffice. Refer to [Developing Windows client drivers for USB devices](https://msdn.microsoft.com/en-us/library/windows/hardware/hh406260(v=vs.85).aspx) to determine what type of driver, if any, you need to write to make your USB device work with Windows. You may look at [Do I need to write a driver for my USB Type-C hardware?](https://blogs.msdn.microsoft.com/usbcoreblog/2016/06/20/do-i-need-to-write-a-driver-for-my-usb-type-c-hardware/) for a more detailed overview. \ No newline at end of file + +UcmCx is intended for system port controller drivers. If you are bringing up a USB Type-C peripheral, you do not need to write a USB Type-C specific driver; a regular USB client driver will suffice. Refer to [Developing Windows client drivers for USB devices](https://msdn.microsoft.com/en-us/library/windows/hardware/hh406260(v=vs.85).aspx) to determine what type of driver, if any, you need to write to make your USB device work with Windows. You may look at [Do I need to write a driver for my USB Type-C hardware?](https://blogs.msdn.microsoft.com/usbcoreblog/2016/06/20/do-i-need-to-write-a-driver-for-my-usb-type-c-hardware/) for a more detailed overview. diff --git a/usb/UcmCxUcsi/usb-ucmcxucsi.yml b/usb/UcmCxUcsi/usb-ucmcxucsi.yml deleted file mode 100644 index 3b169724..00000000 --- a/usb/UcmCxUcsi/usb-ucmcxucsi.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: UcmTcpciCx Port Controller Client Driver - description: Demonstrates how to create a Windows USB Type-C port controller driver using the USB Connector Manager class extension driver (UcmCx). - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /usb/UcmCxUcsi/UcmCxUcsi.sln diff --git a/usb/UcmTcpciCxClientSample/README.md b/usb/UcmTcpciCxClientSample/README.md index 02d043bf..3f00573c 100644 --- a/usb/UcmTcpciCxClientSample/README.md +++ b/usb/UcmTcpciCxClientSample/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: UcmTcpciCx Port Controller Client Driver +description: Demonstrates how to create a Windows USB Type-C port controller driver using the USB Connector Manager Type-C Port Controller Interface class extension driver (UcmTcpciCx). +languages: + - cpp +products: + - windows +--- + - # UcmTcpciCx Port Controller Client Driver This is a skeleton sample driver that shows how to create a Windows USB Type-C port controller driver using the USB Connector Manager Type-C Port Controller Interface class extension driver (UcmTcpciCx). UcmTcpciCx is currently only availble using the Windows Insider program - documentation for UcmTcpciCx will be available at the next release of Windows. This sample demonstrates the following: -- Registration with the UcmTcpci class extension driver (UcmTcpciCx). -- Initializing the port controller's Type-C and Power Delivery capabilities. -- Initializing the I2C communications channel to the port controller hardware. -- Performing reads/writes over I2C. -- Handling hardware requests from UcmTcpciCx. -- Handling alerts from the port controller hardware and notifying UcmTcpciCx of the alert. -- Power management. -- Platform-level device reset in the case of an unresponsive I2C controller. +- Registration with the UcmTcpci class extension driver (UcmTcpciCx). +- Initializing the port controller's Type-C and Power Delivery capabilities. +- Initializing the I2C communications channel to the port controller hardware. +- Performing reads/writes over I2C. +- Handling hardware requests from UcmTcpciCx. +- Handling alerts from the port controller hardware and notifying UcmTcpciCx of the alert. +- Power management. +- Platform-level device reset in the case of an unresponsive I2C controller. ## Customizing the sample for your port controller + The sample contains a number of comments prefaced with `// TODO` - review them and modify the code as necessary as you are writing your driver. ## Note regarding Type-C port controller hardware + This sample assumes a device that complies with the USB Type-C Port Controller Interface specification, Revision 1.0 (part of the [USB 3.1 specification download](http://usb.org/developers/docs)). Such a device uses a predefined register layout and an I2C communications channel. If your port controller hardware is not exactly compliant with the specification, you will need to make additional modifications to the sample. ## Performing read/writes over I2C + The USB Type-C Port Controller Interface specification defines I2C to be the channel by which software communicates with the port controller hardware. If your port controller hardware is not compliant with the specification and does not use I2C as the communications channel, you will need to make additional modifications to the sample. ## When to write a UcmTcpciCx client driver + UcmTcpciCx is intended for system port controller drivers. If you are bringing up a USB Type-C peripheral, you do not need to write a USB Type-C specific driver; a regular USB client driver will suffice. Refer to [Developing Windows client drivers for USB devices](https://msdn.microsoft.com/en-us/library/windows/hardware/hh406260(v=vs.85).aspx) to determine what type of driver, if any, you need to write to make your USB device work with Windows. +## Testing Your Type-C Port Controller (TCPC) Implementation on Windows 10 with Raspberry Pi -# Testing Your Type-C Port Controller (TCPC) Implementation on Windows 10 with Raspberry Pi - -## Pre-requisites +### Pre-requisites This section outlines a procedure for installing and testing a TCPCI implementation for Windows 10 on a Raspberry Pi computer running Windows 10 IoT Core. You will need a Raspberry Pi 2 or 3, your TCPC device, a USB-to-Serial converter for debugging, and 7 jumper wires to connect your TCPC to the Raspberry Pi (3 for the debug board, 4 for the TCPC). You will also need the Windows 10 IoT Core Insider Preview builds, the IoT tool set and WDK available for download on MSDN, and the UcmTcpciCxClientSample source code. -## Setup +### Setup -### Operating System +#### Operating System Download the latest available Windows 10 IoT Core Insider Preview image here: @@ -60,25 +72,25 @@ Install on your Raspberry Pi 2 or 3 per the following instructions: Note, you will only need to complete the first two steps, “1 Get the tools” and “2 Setup your device” to proceed with the TCPC validation described here. -### PowerShell Connection +#### PowerShell Connection Connect to your Raspberry Pi via a PowerShell remote session. You will use this connection to setup the debugger and install your TCPCI driver package. -### Windows Device Portal +#### Windows Device Portal Open a connection to the Raspberry Pi via the Windows Device Portal. The portal provides a Device Manager view in which you will be able to inspect your TCPC device, as well as remote shutdown and reboot controls. -### Kernel Debugger +#### Kernel Debugger Setup the kernel debugger for your Raspberry Pi according to the instructions at the following location: -## Connect TCPC Hardware +#### Connect TCPC Hardware The following assumes an I2C implementation of your TCPC; if your device uses a different transport, ignore the I2C specific references and connect the transport as appropriate. @@ -90,27 +102,27 @@ First, shutdown and remove power from both the Raspberry Pi and your TCPC hardwa Connect the following pins between your TCPC and the Raspberry Pi: -- GND: many options +- GND: many options -- SDA: pin 3 +- SDA: pin 3 -- SCL: pin 5 +- SCL: pin 5 -- ALERT: can be any GPIO but the sample ACPI is setup to use GPIO 5 (pull-up) which is pin 29 on the RPi2 +- ALERT: can be any GPIO but the sample ACPI is setup to use GPIO 5 (pull-up) which is pin 29 on the RPi2 Note the ACPI sample assumes GPIO5 (pin 29). If you use a different bus or interrupt you will need to update the sample ASL file to reflect the selected configuration. Once these pins are connected, both boards may be powered on. You will not see any changes to the device manager view of the Device Portal yet. -## UcmTcpciCx Client Driver +### UcmTcpciCx Client Driver -### Customize and Build the Driver +#### Customize and Build the Driver Edit the driver source files to add any customizations that your hardware may require. For example, the sample is designed against TCPCI Revision 1.0 Version 1.0, but if your hardware conforms to a later version that repurposes register fields that were reserved in version 1.0 you will need to update the alert handler to recognize and clear those bits accordingly. Edit the INF to set the device path and strings to desired custom values. Build your driver in Visual Studio and copy the INF and the SYS file from the build output. -### Install Driver Package +#### Install Driver Package Follow the instructions at the link below to create a driver package in the form of a CAB file for your custom UcmTcpciCx client driver: @@ -118,15 +130,15 @@ Follow the instructions at the link below to create a driver package in the form Once you have generated the CAB file, see step 3 for instructions on installing the driver package on your Raspberry Pi via the PowerShell connection established earlier. After the package has been installed and the system has rebooted, there is still one more step to getting your driver to load: updating the ACPI tables to describe the device to the platform. -## Update ACPI +### Update ACPI Open sample.asl provided in the UcmTcpciCxClientSample driver sample and modify the following sections as necessary: -- Ensure that the device name matches the device path specified in your INF +- Ensure that the device name matches the device path specified in your INF -- Update the resources section to reflect the actual I2C and Interrupt resources on which your TCPC is connected, default is I2C1 and GPIO5. Specify the I2C address your TCPC uses. +- Update the resources section to reflect the actual I2C and Interrupt resources on which your TCPC is connected, default is I2C1 and GPIO5. Specify the I2C address your TCPC uses. -- Update the connector capabilities section to reflect the capabilities of the connector on your TCPC. +- Update the connector capabilities section to reflect the capabilities of the connector on your TCPC. On a PC with the Windows 10 WDK installed run the following command on your updated ASL file: @@ -138,9 +150,9 @@ This will produce output file ACPITABL.dat. Copy this file to *C:\\Windows\\Syst Once the Raspberry Pi has rebooted, your driver will load on the newly enumerated ACPI device node. -## Testing +### Testing -### USB Type-C Connection Exerciser +#### USB Type-C Connection Exerciser The USB Type-C Connection Exerciser is a tool designed by Microsoft and manufactured by MCCI available for purchase at the link below: @@ -152,23 +164,27 @@ The tools and instructions for deploying testing with this device are available Suggested testing with the Connection Exerciser device is randomized connect/disconnect for long periods of time. -## Debugging +### Debugging The sample driver includes standard WDF logging which can be extracted via the kernel debugger with the following debugger command: -> !wdfkd.wdflogdump <driver name> -d +```cmd +!wdfkd.wdflogdump -d +``` Other useful driver traces are available from *UcmTcpciCx* and *UcmCx*. Driver logs may also be captured via tracelog which is included in the IoT image. Sample trace capture commands using the GUID included by default in the client sample driver is as follows: -> *Tracelog -start ClientSampleTrace -guid* *\#1dc982f3-068f-4577-bcdf-1bc844e457b2 -flags 0x7fffffff -level 0xff -f clientsampletrace.etl -ft 3* -> -> *<reproduce issue of interest>* -> -> *Tracelog -stop ClientSampleTrace* -> -> *Tracelog -remove ClientSampleTrace* +```cmd +Tracelog -start ClientSampleTrace -guid #1dc982f3-068f-4577-bcdf-1bc844e457b2 -flags 0x7fffffff -level 0xff -f clientsampletrace.etl -ft 3 + + + +Tracelog -stop ClientSampleTrace + +Tracelog -remove ClientSampleTrace +``` Other useful driver trace guids: @@ -176,7 +192,7 @@ UcmCx: C5964C90-1824-4835-857A-5E95F8AA33B2 UcmTcpciCx: 8DEAEA72-4C63-49A4-9B8B-25DA24DAE056 -## Resources +### Resources USB Type-C Port Controller Interface Specification (TCPCI), download as part of USB 3.1 Specification: @@ -204,4 +220,4 @@ Microsoft USB Test Tools Tracelog Command Syntax -https://msdn.microsoft.com/en-us/library/windows/hardware/ff553012(v=vs.85).aspx + diff --git a/usb/UcmTcpciCxClientSample/usb-ucmtcpcicxclientsample.yml b/usb/UcmTcpciCxClientSample/usb-ucmtcpcicxclientsample.yml deleted file mode 100644 index f65285df..00000000 --- a/usb/UcmTcpciCxClientSample/usb-ucmtcpcicxclientsample.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: UcmTcpciCx Port Controller Client Driver - description: Demonstrates how to create a Windows USB Type-C port controller driver using the USB Connector Manager Type-C Port Controller Interface class extension driver (UcmTcpciCx). - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /usb/UcmTcpciCxClientSample/UcmTcpciCxClientSample.sln diff --git a/usb/UcmUcsiAcpiSample/README.md b/usb/UcmUcsiAcpiSample/README.md index 592926be..970da954 100644 --- a/usb/UcmUcsiAcpiSample/README.md +++ b/usb/UcmUcsiAcpiSample/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: UcmUcsiCx ACPI Client Driver +description: Demonstrates how to create a Windows USB Type-C port controller driver using the USB Connector Manager class extension driver (UcmCx). +languages: + - cpp +products: + - windows +--- + - -Sample KMDF Bus Driver for OSR USB-FX2 -====================================== +# Sample KMDF Bus Driver for OSR USB-FX2 The kmdf\_enumswitches sample demonstrates how to use Kernel-Mode Driver Framework (KMDF) as a bus driver using the OSR USB-FX2 device. This sample is written for the OSR USB-FX2 Learning Kit. The specification for the device is at . -Testing the Device ------------------- +## Testing the Device To test the device, follow these steps: -1. If you test signed your driver package, you must enable installation of test signed drivers on the target machine. To do so, either press F8 as the target machine comes up from a reboot, or specify **Bcdedit.exe -set TESTSIGNING ON** and reboot. If you use F8, the change only applies until the next reboot. -2. Plug in the OSR USB-FX-2 Learning Kit (must be version 2.00 or later). -3. In Device Manager, select **Update Driver Software**, **Browse my computer for driver software**, **Let me pick from a list of device drivers on my computer**, **Have Disk**. Navigate to the directory that contains your driver package and select the INF file. -4. After the driver installs, verify that the device appears under the **Sample Device** node in Device Manager. -5. Flip the switches on the OSR USB-FX-2 hardware board and watch the raw PDO entries appear and disappear under **Sample Device** in Device Manager. -6. Right-click a raw PDO entry, select **Properties**, and then click the **Events** tab. Under **Information**, examine the hardware ID for the PDO. It should be something like this: +1. If you test signed your driver package, you must enable installation of test signed drivers on the target machine. To do so, either press F8 as the target machine comes up from a reboot, or specify **Bcdedit.exe -set TESTSIGNING ON** and reboot. If you use F8, the change only applies until the next reboot. +1. Plug in the OSR USB-FX-2 Learning Kit (must be version 2.00 or later). +1. In Device Manager, select **Update Driver Software**, **Browse my computer for driver software**, **Let me pick from a list of device drivers on my computer**, **Have Disk**. Navigate to the directory that contains your driver package and select the INF file. +1. After the driver installs, verify that the device appears under the **Sample Device** node in Device Manager. +1. Flip the switches on the OSR USB-FX-2 hardware board and watch the raw PDO entries appear and disappear under **Sample Device** in Device Manager. +1. Right-click a raw PDO entry, select **Properties**, and then click the **Events** tab. Under **Information**, examine the hardware ID for the PDO. It should be something like this: - ``` - 6FDE7521-1B65-48ae-B628-80BE62016026}\OsrUsbFxRawPdo\6&227995e2&0&08 - ``` + **6FDE7521-1B65-48ae-B628-80BE62016026}\OsrUsbFxRawPdo\6&227995e2&0&08** The last digit matches the number of the switch that you toggled. -Hardware Overview ------------------ +## Hardware Overview Here is the overview of the device: -- Device is based on the development board supplied with the Cypress EZ-USB FX2 Development Kit (CY3681). -- Contains 1 interface and 3 endpoints (Interrupt IN, Bulk Out, Bulk IN). -- Firmware supports vendor commands to query or set LED Bar graph display, 7-segment LED display and query toggle switch states. -- Interrupt Endpoint: - - Sends an 8-bit value that represents the state of the switches. - - Sent on startup, resume from suspend, and whenever the switch pack setting changes. - - Firmware does not de-bounce the switch pack. - - One switch change can result in multiple bytes being sent. - - Bits are in the reverse order of the labels on the pack +- Device is based on the development board supplied with the Cypress EZ-USB FX2 Development Kit (CY3681). +- Contains 1 interface and 3 endpoints (Interrupt IN, Bulk Out, Bulk IN). +- Firmware supports vendor commands to query or set LED Bar graph display, 7-segment LED display and query toggle switch states. +- Interrupt Endpoint: - E.g. bit 0x80 is labeled 1 on the pack + - Sends an 8-bit value that represents the state of the switches. + - Sent on startup, resume from suspend, and whenever the switch pack setting changes. + - Firmware does not de-bounce the switch pack. + - One switch change can result in multiple bytes being sent. + - Bits are in the reverse order of the labels on the pack -- Bulk Endpoints are configured for loopback: - - Device moves data from IN endpoint to OUT endpoint. - - Device does not change the values of the data it receives nor does it internally create any data. - - Endpoints are always double buffered. - - Maximum packet size depends on speed (64 Full speed, 512 High speed). + For example, bit 0x80 is labeled 1 on the pack + +- Bulk Endpoints are configured for loopback: + - Device moves data from IN endpoint to OUT endpoint. + - Device does not change the values of the data it receives nor does it internally create any data. + - Endpoints are always double buffered. + - Maximum packet size depends on speed (64 Full speed, 512 High speed). diff --git a/usb/kmdf_enumswitches/usb-kmdf-enumswitches.yml b/usb/kmdf_enumswitches/usb-kmdf-enumswitches.yml deleted file mode 100644 index 251db0e4..00000000 --- a/usb/kmdf_enumswitches/usb-kmdf-enumswitches.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Sample KMDF Bus Driver for OSR USB-FX2 - description: Demonstrates how to use KMDF as a bus driver using the OSR USB-FX2 device. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /usb/kmdf_enumswitches/kmdf_enumswitches.sln diff --git a/usb/kmdf_fx2/README.md b/usb/kmdf_fx2/README.md index dbab6c16..cf4b7c4a 100644 --- a/usb/kmdf_fx2/README.md +++ b/usb/kmdf_fx2/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Sample KMDF Function Driver for OSR USB-FX2 +description: Demonstrates how to use KMDF to perform bulk and interrupt data transfers to a USB device. +languages: + - cpp +products: + - windows +--- + - -Sample KMDF Function Driver for OSR USB-FX2 -=========================================== +# Sample KMDF Function Driver for OSR USB-FX2 The kmdf\_fx2 sample is a Kernel-Mode Driver Framework (KMDF) driver for the OSR USB-FX2 device. It includes a test app and sample device metadata. @@ -18,6 +26,7 @@ In the Windows Driver Kit (WDK), the osrusbfx2 sample demonstrated how to perfor The specification for the device is at . The driver and sample device metadata also work with the [Custom driver access](http://go.microsoft.com/fwlink/p/?LinkID=248288) sample. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. Overview diff --git a/usb/kmdf_fx2/usb-kmdf-fx2.yml b/usb/kmdf_fx2/usb-kmdf-fx2.yml deleted file mode 100644 index dcbf9021..00000000 --- a/usb/kmdf_fx2/usb-kmdf-fx2.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Sample KMDF Function Driver for OSR USB-FX2 - description: Demonstrates how to use KMDF to perform bulk and interrupt data transfers to a USB device. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /usb/kmdf_fx2/kmdf_fx2.sln diff --git a/usb/ufxclientsample/README.md b/usb/ufxclientsample/README.md index 54a2f69f..f7d224aa 100644 --- a/usb/ufxclientsample/README.md +++ b/usb/ufxclientsample/README.md @@ -1,4 +1,14 @@ - - -USB Function Client Driver -========================== +# USB Function Client Driver This is a skeleton sample driver that shows how to create a Windows USB function controller driver using the USB function class extension driver (UFX). This sample demonstrates the following: -- Registration with the UFX class extension driver -- Handling USB transfers -- Handling function controller events -- Handling attach and detach notifications -- Handling charger/port detection -- Power management +- Registration with the UFX class extension driver +- Handling USB transfers +- Handling function controller events +- Handling attach and detach notifications +- Handling charger/port detection +- Power management -Operating system requirements ------------------------------ +## Operating system requirements -Windows 10 Mobile +Windows 10 Mobile -Customizing the sample for your device --------------------------------------- +## Customizing the sample for your device This sample is not a functional driver. It is a skeleton driver intended to illustrate the general design of a UFX client driver. The sample contains a number of comments prefaced with " #### TODO ", which indicates where code will need to be added to perform the controller operation as described in the comment. -Installation Note ------------------ +## Installation Note Installation on Windows 10 Mobile requires the creation of a package. To properly interact with the USB UI on Windows 10 Mobile, the package must include a Security Element that specifies the ID_CAP_USB capability with DEVICE_READ and DEVICE_WRITE rights. diff --git a/usb/ufxclientsample/usb-ufxclientsample.yml b/usb/ufxclientsample/usb-ufxclientsample.yml deleted file mode 100644 index 54c5eea7..00000000 --- a/usb/ufxclientsample/usb-ufxclientsample.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: USB Function Client Driver - description: Demonstrates how to create a Windows USB function controller driver using the USB function class extension driver (UFX). - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /usb/ufxclientsample/ufxclientsample.sln diff --git a/usb/umdf2_fx2/README.md b/usb/umdf2_fx2/README.md index 4200dc73..dccce968 100644 --- a/usb/umdf2_fx2/README.md +++ b/usb/umdf2_fx2/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Sample Function Driver for OSR USB-FX2 (UMDF Version 2) +description: Demonstrates a UMDF version 2 driver for the OSR USB-FX2 device. +languages: + - cpp +products: + - windows +--- + -Sample Function Driver for OSR USB-FX2 (UMDF Version 2) -======================================================= +# Sample Function Driver for OSR USB-FX2 (UMDF Version 2) The umdf2\_fx2 sample is a User-Mode Driver Framework (UMDF) version 2 driver for the OSR USB-FX2 device. The specification for the device can be found at . The driver and sample device metadata also work with the [Custom driver access](http://go.microsoft.com/fwlink/p/?LinkID=248288) sample. - -Related technologies --------------------- +## Related technologies [User-Mode Driver Framework](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560456) - -Run the sample --------------- +## Run the sample The computer where you install the driver is called the *target computer* or the *test computer*. Typically this is a separate computer from where you develop and build the driver package. The computer where you develop and build the driver is called the *host computer*. @@ -32,19 +37,18 @@ The process of moving the driver package to the target computer and installing t Before you automatically deploy a driver, you must provision the target computer. For instructions, see [Configuring a Computer for Driver Deployment, Testing, and Debugging](http://msdn.microsoft.com/en-us/library/windows/hardware/). -1. Plug in the OSR USB-FX2 board to the target computer. -2. On the host computer, in Visual Studio, in Solution Explorer, right click **package** (lower case), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**. -3. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, select the name of a target computer that you provisioned previously. Select **Install and Verify**. Click **OK**. -4. On the **Build** menu, choose **Deploy Package** or **Build Solution**. +1. Plug in the OSR USB-FX2 board to the target computer. +1. On the host computer, in Visual Studio, in Solution Explorer, right click **package** (lower case), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**. +1. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, select the name of a target computer that you provisioned previously. Select **Install and Verify**. Click **OK**. +1. On the **Build** menu, choose **Deploy Package** or **Build Solution**. ### Manual deployment (FX2 board) Before you manually deploy a driver, you must turn on test signing and install a certificate on the target computer. You also need to copy the [DevCon](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544707) tool to the target computer. For instructions, see [Preparing a Computer for Manual Driver Deployment](http://msdn.microsoft.com/en-us/library/windows/hardware/dn265571). -1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\umdf2\_fx2). -2. Plug in the OSR USB-FX2 board to the target computer. Open a Command Prompt window and enter **dvmgmt** to open Device Manager. In Device Manager, locate the node for the OSR USB-FX2 board. Right click the node, and choose **Properties**. In the **Details** tab, under **Properties**, choose **Hardware Ids**. Note the hardware IDs listed for your FX2 board. One of these IDs should match one of the IDs in the osrusbfx2um.inf file. For example, Device Manager might show an ID of USB\\VID\_0547&PID\_1002, which matches one of the IDs in the [Microsoft.*xxx*] section of osrusbfx2um.inf. - -3. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter this command: +1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\umdf2\_fx2). +1. Plug in the OSR USB-FX2 board to the target computer. Open a Command Prompt window and enter **dvmgmt** to open Device Manager. In Device Manager, locate the node for the OSR USB-FX2 board. Right click the node, and choose **Properties**. In the **Details** tab, under **Properties**, choose **Hardware Ids**. Note the hardware IDs listed for your FX2 board. One of these IDs should match one of the IDs in the osrusbfx2um.inf file. For example, Device Manager might show an ID of USB\\VID\_0547&PID\_1002, which matches one of the IDs in the [Microsoft.*xxx*] section of osrusbfx2um.inf. +1. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter this command: **devcon update osrusbfx2um.inf"***HardwareID***"** @@ -52,19 +56,16 @@ Before you manually deploy a driver, you must turn on test signing and install a **devcon update osrusbfx2um.inf "USB\\VID\_0547&PID\_1002"** -View the driver for the OSR USB-FX2 board in Device Manager ------------------------------------------------------------ +## View the driver for the OSR USB-FX2 board in Device Manager On the target computer, in your Command Prompt window, enter **devmgmt** to open Device Manager. In Device Manager, on the **View** menu, choose **Devices by type**. In the device tree, locate **UMDF 2.0 Sample Driver for OSR Fx2 Learning Kit** (for example, this might be under the **Sample Device** node). In Device Manager, on the **View** menu, choose **Devices by connection**. Locate **UMDF 2.0 Sample Driver for OSR Fx2 Learning Kit** as a child of a USB hub node, which may be contained with the **ACPI x64-based PC** node. -Build the sample using MSBuild ------------------------------- +## Build the sample using MSBuild As an alternative to building the driver sample in Visual Studio, you can build it in a Visual Studio Command Prompt window. In Visual Studio, on the **Tools** menu, choose **Visual Studio Command Prompt**. In the Visual Studio Command Prompt window, navigate to the folder that has the solution file, umdf2echo.sln. Use the MSBuild command to build the solution. Here is an example: -**msbuild /p:configuration=�Win8 Release� /p:platform=�Win32� umdf2\_fx2.sln** + **msbuild /p:configuration=Win8 Release /p:platform=Win32 umdf2\_fx2.sln** For more information about using MSBuild to build a driver package, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644). - diff --git a/usb/umdf2_fx2/usb-umdf2-fx2.yml b/usb/umdf2_fx2/usb-umdf2-fx2.yml deleted file mode 100644 index dd64a682..00000000 --- a/usb/umdf2_fx2/usb-umdf2-fx2.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Sample Function Driver for OSR USB-FX2 (UMDF Version 2) - description: Demonstrates a UMDF version 2 driver for the OSR USB-FX2 device. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /usb/umdf2_fx2/umdf2_fx2.sln diff --git a/usb/umdf_filter_kmdf/README.md b/usb/umdf_filter_kmdf/README.md index 5eaf3347..117d32c8 100644 --- a/usb/umdf_filter_kmdf/README.md +++ b/usb/umdf_filter_kmdf/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Sample UMDF Filter above KMDF Function Driver for OSR USB-FX2 (UMDF Version 1) +description: Demonstrates how to load a UMDF filter driver as an upper filter driver above the kmdf_fx2 sample driver. +languages: + - cpp +products: + - windows +--- + - -Sample UMDF Filter above KMDF Function Driver for OSR USB-FX2 (UMDF Version 1) -============================================================================== +# Sample UMDF Filter above KMDF Function Driver for OSR USB-FX2 (UMDF Version 1) The umdf\_filter\_kmdf sample demonstrates how to load a UMDF filter driver as an upper filter driver above the kmdf\_fx2 sample driver. The sample includes Event Tracing for Windows (ETW) tracing support, and is written for the OSR USB-FX2 Learning Kit. The specification for the device is at . -Build the sample ----------------- +## Build the sample The default Solution build configuration is **Debug** and **Win32**. -**To select a configuration and build a driver** +1. Open the driver project or solution in Visual Studio (find *filtername*.sln or *filtername*.vcxproj). +1. Right-click the solution in the **Solutions Explorer** and select **Configuration Manager**. +1. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Debug or Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. +1. From the **Build** menu, click **Build Solution** (Ctrl+Shift+B). -1. Open the driver project or solution in Visual Studio (find *filtername*.sln or *filtername*.vcxproj). -2. Right-click the solution in the **Solutions Explorer** and select **Configuration Manager**. -3. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Debug or Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. -4. From the **Build** menu, click **Build Solution** (Ctrl+Shift+B). +## Overview -Overview --------- +- The device is based on the development board supplied with the Cypress EZ-USB FX2 Development Kit (CY3681). +- It contains 1 interface and 3 endpoints (Interrupt IN, Bulk Out, Bulk IN). +- Firmware supports vendor commands to query or set LED Bar graph display and 7-segment LED display, and to query toggle switch states. +- Interrupt Endpoint: + - Sends an 8-bit value that represents the state of the switches. + - Sent on startup, resume from suspend, and whenever the switch pack setting changes. + - Firmware does not de-bounce the switch pack. + - One switch change can result in multiple bytes being sent. + - Bits are in the reverse order of the labels on the pack (for example, bit 0x80 is labeled 1 on the pack). +- Bulk Endpoints are configured for loopback: + - The device moves data from IN endpoint to OUT endpoint. + - The device does not change the values of the data it receives nor does it internally create any data. + - Endpoints are always double buffered. + - Maximum packet size depends on speed (64 full speed, 512 high speed). +- ETW events: + - Included osrusbfx2.man, which describes events added. + - Three events are targeted to the event log: + - Failure during the add device routine. + - Failure to start the OSR device on a USB 1.1 controller. + - Invocation of the "re-enumerate device" IOCTL. + - Read/write start/stop events can be used to measure the time taken. -Here is the overview of the device: - -- The device is based on the development board supplied with the Cypress EZ-USB FX2 Development Kit (CY3681). -- It contains 1 interface and 3 endpoints (Interrupt IN, Bulk Out, Bulk IN). -- Firmware supports vendor commands to query or set LED Bar graph display and 7-segment LED display, and to query toggle switch states. -- Interrupt Endpoint: - - Sends an 8-bit value that represents the state of the switches. - - Sent on startup, resume from suspend, and whenever the switch pack setting changes. - - Firmware does not de-bounce the switch pack. - - One switch change can result in multiple bytes being sent. - - Bits are in the reverse order of the labels on the pack (for example, bit 0x80 is labeled 1 on the pack). -- Bulk Endpoints are configured for loopback: - - The device moves data from IN endpoint to OUT endpoint. - - The device does not change the values of the data it receives nor does it internally create any data. - - Endpoints are always double buffered. - - Maximum packet size depends on speed (64 full speed, 512 high speed). -- ETW events: - - Included osrusbfx2.man, which describes events added. - - Three events are targeted to the event log: - - Failure during the add device routine. - - Failure to start the OSR device on a USB 1.1 controller. - - Invocation of the "re-enumerate device" IOCTL. - - Read/write start/stop events can be used to measure the time taken. - -Testing the driver ------------------- +## Testing the driver You can test this sample either by using the [Custom driver access](http://go.microsoft.com/fwlink/p/?LinkID=248288) sample application, or by using the osrusbfx2.exe test application. For information on how to build and use the osrusbfx2.exe application, see the test instructions for the [kmdf\_fx2](http://msdn.microsoft.com/en-us/library/windows/hardware/) sample. -Code tour ---------------- - -Folder | Description ------|------------ -usb\umdf_filter_kmdf\kmdf_driver | This directory contains source code for the kmdf_fx2 sample driver. -usb\umdf_filter_kmdf\umdf_filter | This directory contains the UMDF filter driver. - +## Code tour +| Folder | Description | +| --- | --- | +| usb\umdf_filter_kmdf\kmdf_driver | This directory contains source code for the kmdf_fx2 sample driver. | +| usb\umdf_filter_kmdf\umdf_filter | This directory contains the UMDF filter driver. | \ No newline at end of file diff --git a/usb/umdf_filter_kmdf/usb-umdf-filter-kmdf.yml b/usb/umdf_filter_kmdf/usb-umdf-filter-kmdf.yml deleted file mode 100644 index 00a33b2b..00000000 --- a/usb/umdf_filter_kmdf/usb-umdf-filter-kmdf.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Sample UMDF Filter above KMDF Function Driver for OSR USB-FX2 (UMDF Version 1) - description: Demonstrates how to load a UMDF filter driver as an upper filter driver above the kmdf_fx2 sample driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /usb/umdf_filter_kmdf/umdf_filter_kmdf.sln diff --git a/usb/umdf_filter_umdf/README.md b/usb/umdf_filter_umdf/README.md index f4d3dc26..da3d05f7 100644 --- a/usb/umdf_filter_umdf/README.md +++ b/usb/umdf_filter_umdf/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Sample UMDF Filter above UMDF Function Driver for OSR USB-FX2 (UMDF Version 1) +description: Demonstrates how to load a UMDF filter driver as an upper filter driver above the umdf_fx2 sample driver. +languages: + - cpp +products: + - windows +--- + - -Sample UMDF Filter above UMDF Function Driver for OSR USB-FX2 (UMDF Version 1) -============================================================================== +# Sample UMDF Filter above UMDF Function Driver for OSR USB-FX2 (UMDF Version 1) The umdf\_filter\_umdf sample demonstrates how to load a User-Mode Driver Framework (UMDF) filter driver as an upper filter driver above the umdf\_fx2 sample driver. This sample is written for the OSR USB-FX2 Learning Kit. The specification for the device is at . -### Overview +## Overview +- The device is based on the development board supplied with the Cypress EZ-USB FX2 Development Kit (CY3681). +- It contains 1 interface and 3 endpoints (Interrupt IN, Bulk Out, Bulk IN). +- Firmware supports vendor commands to query or set LED Bar graph display and 7-segment LED display, and to query toggle switch states. +- Interrupt Endpoint: + - Sends an 8-bit value that represents the state of the switches. + - Sent on startup, resume from suspend, and whenever the switch pack setting changes. + - Firmware does not de-bounce the switch pack. + - One switch change can result in multiple bytes being sent. + - Bits are in the reverse order of the labels on the pack (for example, bit 0x80 is labeled 1 on the pack). +- Bulk Endpoints are configured for loopback: + - The device moves data from IN endpoint to OUT endpoint. + - The device does not change the values of the data it receives nor does it internally create any data. + - Endpoints are always double buffered. + - Maximum packet size depends on speed (64 full speed, 512 high speed). -Here is the overview of the device: - -- The device is based on the development board supplied with the Cypress EZ-USB FX2 Development Kit (CY3681). -- It contains 1 interface and 3 endpoints (Interrupt IN, Bulk Out, Bulk IN). -- Firmware supports vendor commands to query or set LED Bar graph display and 7-segment LED display, and to query toggle switch states. -- Interrupt Endpoint: - - Sends an 8-bit value that represents the state of the switches. - - Sent on startup, resume from suspend, and whenever the switch pack setting changes. - - Firmware does not de-bounce the switch pack. - - One switch change can result in multiple bytes being sent. - - Bits are in the reverse order of the labels on the pack (for example, bit 0x80 is labeled 1 on the pack). -- Bulk Endpoints are configured for loopback: - - The device moves data from IN endpoint to OUT endpoint. - - The device does not change the values of the data it receives nor does it internally create any data. - - Endpoints are always double buffered. - - Maximum packet size depends on speed (64 full speed, 512 high speed). - -### Testing the driver +## Testing the driver You can test this sample either by using the [Custom driver access](http://go.microsoft.com/fwlink/p/?LinkID=248288) sample application, or by using the osrusbfx2.exe test application. For information on how to build and use the osrusbfx2.exe application, see the test instructions for the [umdf\_fx2](http://msdn.microsoft.com/en-us/library/windows/hardware/) sample. -### Sample Contents - -Folder | Description --------|------------ -usb\umdf_filter_umdf\umdf_driver | This directory contains source code for the umdf_fx2 sample driver. -usb\umdf_filter_umdf\umdf_filter | This directory contains the UMDF filter driver. - +## Sample Contents +| Folder | Description | +| --- | --- | +| usb\umdf_filter_umdf\umdf_driver | This directory contains source code for the umdf_fx2 sample driver. | +| usb\umdf_filter_umdf\umdf_filter | This directory contains the UMDF filter driver. | diff --git a/usb/umdf_filter_umdf/usb-umdf-filter-umdf.yml b/usb/umdf_filter_umdf/usb-umdf-filter-umdf.yml deleted file mode 100644 index 987a1355..00000000 --- a/usb/umdf_filter_umdf/usb-umdf-filter-umdf.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Sample UMDF Filter above UMDF Function Driver for OSR USB-FX2 (UMDF Version 1) - description: Demonstrates how to load a UMDF filter driver as an upper filter driver above the umdf_fx2 sample driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /usb/umdf_filter_umdf/umdf_filter_umdf.sln diff --git a/usb/umdf_fx2/README.md b/usb/umdf_fx2/README.md index 4b707cbe..81ba1692 100644 --- a/usb/umdf_fx2/README.md +++ b/usb/umdf_fx2/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Sample UMDF Function Driver for OSR USB-FX2 (UMDF version 1) +description: A UMDF driver for the OSR USB-FX2 device that includes a test application, sample device metadata, and supports impersonation and idle power down. +languages: + - cpp +products: + - windows +--- + - -Sample UMDF Function Driver for OSR USB-FX2 (UMDF Version 1) -============================================================ +# Sample UMDF Function Driver for OSR USB-FX2 (UMDF Version 1) The umdf\_fx2 sample is a User-Mode Driver Framework (UMDF) driver for the OSR USB-FX2 device. It includes a test app and sample device metadata, and supports impersonation and idle power down. @@ -17,46 +25,39 @@ The sample can also be used with the CustomDeviceAccess MSDK sample. The sample The osrusbfx2 sample is divided into three samples: -- **WDF Sample Driver Learning Lab for OSR USB-FX2**: This sample is a series of iterative drivers that demonstrate how to write a "Hello World" driver and adds additional features in each step. +- **WDF Sample Driver Learning Lab for OSR USB-FX2**: This sample is a series of iterative drivers that demonstrate how to write a "Hello World" driver and adds additional features in each step. -- **kmdf\_fx2**: This sample is the final version of kernel-mode **wdf\_osrfx2** driver. The sample demonstrates KMDF methods. +- **kmdf\_fx2**: This sample is the final version of kernel-mode **wdf\_osrfx2** driver. The sample demonstrates KMDF methods. -- **umdf\_fx2**: This sample is the final version of the user-mode driver **wdf\_osrfx2**. The sample demonstrates UMDF methods. +- **umdf\_fx2**: This sample is the final version of the user-mode driver **wdf\_osrfx2**. The sample demonstrates UMDF methods. -Build the sample ----------------- +## Build the sample -The default Solution build configuration is Debug and Win32. +The default Solution build configuration is Debug and Win32. -**To select a configuration and build a driver** +1. Open the driver project or solution in Visual Studio 2015 (find *filtername*.sln or *filtername*.vcxproj). +1. Right-click the solution in the **Solutions Explorer** and select **Configuration Manager**. +1. From the **Configuration Manager**, select the **Active Solution Configuration** and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. +1. From the **Build** menu, click **Build Solution** (Ctrl+Shift+B). -1. Open the driver project or solution in Visual Studio 2015 (find *filtername*.sln or *filtername*.vcxproj). -2. Right-click the solution in the **Solutions Explorer** and select **Configuration Manager**. -3. From the **Configuration Manager**, select the **Active Solution Configuration** and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. -4. From the **Build** menu, click **Build Solution** (Ctrl+Shift+B). +## Overview -Overview --------- +- The device is based on the development board supplied with the Cypress EZ-USB FX2 Development Kit (CY3681). +- It contains 1 interface and 3 endpoints (Interrupt IN, Bulk Out, Bulk IN). +- Firmware supports vendor commands to query or set LED Bar graph display and 7-segment LED display, and to query toggle switch states. +- Interrupt Endpoint: + - Sends an 8-bit value that represents the state of the switches. + - Sent on startup, resume from suspend, and whenever the switch pack setting changes. + - Firmware does not de-bounce the switch pack. + - One switch change can result in multiple bytes being sent. + - Bits are in the reverse order of the labels on the pack (for example, bit 0x80 is labeled 1 on the pack). +- Bulk Endpoints are configured for loopback: + - The device moves data from IN endpoint to OUT endpoint. + - The device does not change the values of the data it receives nor does it internally create any data. + - Endpoints are always double buffered. + - Maximum packet size depends on speed (64 full speed, 512 high speed). -Here is the overview of the device: - -- The device is based on the development board supplied with the Cypress EZ-USB FX2 Development Kit (CY3681). -- It contains 1 interface and 3 endpoints (Interrupt IN, Bulk Out, Bulk IN). -- Firmware supports vendor commands to query or set LED Bar graph display and 7-segment LED display, and to query toggle switch states. -- Interrupt Endpoint: - - Sends an 8-bit value that represents the state of the switches. - - Sent on startup, resume from suspend, and whenever the switch pack setting changes. - - Firmware does not de-bounce the switch pack. - - One switch change can result in multiple bytes being sent. - - Bits are in the reverse order of the labels on the pack (for example, bit 0x80 is labeled 1 on the pack). -- Bulk Endpoints are configured for loopback: - - The device moves data from IN endpoint to OUT endpoint. - - The device does not change the values of the data it receives nor does it internally create any data. - - Endpoints are always double buffered. - - Maximum packet size depends on speed (64 full speed, 512 high speed). - -Testing the driver ------------------- +## Testing the driver You can use the [Custom driver access](http://go.microsoft.com/fwlink/p/?LinkID=248288) sample to test the umdf\_fx2 sample. @@ -64,14 +65,14 @@ This sample also includes a test application, osrusbfx2.exe, that you can use to Usage for Read/Write test: -- -r [*n*], where *n* is number of bytes to read. -- -w [*n*], where *n* is number of bytes to write. -- -c [*n*], where *n* is number of iterations (default = 1). -- -v, shows verbose read data. -- -p, plays with Bar Display, Dip Switch, 7-Segment Display. -- -a, performs asynchronous I/O operation. -- -u, dumps USB configuration and pipe information. -- -f \<*filename*\> [*interval-seconds*], where *interval-seconds* is a delay in milliseconds, to send a text file to the seven-segment display (UMDF only) +- -r [*n*], where *n* is number of bytes to read. +- -w [*n*], where *n* is number of bytes to write. +- -c [*n*], where *n* is number of iterations (default = 1). +- -v, shows verbose read data. +- -p, plays with Bar Display, Dip Switch, 7-Segment Display. +- -a, performs asynchronous I/O operation. +- -u, dumps USB configuration and pipe information. +- -f \<*filename*\> [*interval-seconds*], where *interval-seconds* is a delay in milliseconds, to send a text file to the seven-segment display (UMDF only) **Playing with the 7 segment display, toggle switches, and bar graph display** diff --git a/usb/umdf_fx2/usb-umdf-fx2.yml b/usb/umdf_fx2/usb-umdf-fx2.yml deleted file mode 100644 index e802c6f5..00000000 --- a/usb/umdf_fx2/usb-umdf-fx2.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Sample UMDF Function Driver for OSR USB-FX2 (UMDF version 1) - description: A UMDF driver for the OSR USB-FX2 device that includes a test application, sample device metadata, and supports impersonation and idle power down. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /usb/umdf_fx2/umdf_fx2.sln diff --git a/usb/usbsamp/README.md b/usb/usbsamp/README.md index 30f46c17..91f950d3 100644 --- a/usb/usbsamp/README.md +++ b/usb/usbsamp/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Usbsamp Generic USB Driver +description: Demonstrates how to perform full speed, high speed, and SuperSpeed transfers to and from bulk and isochronous endpoints of a generic USB device. +languages: + - cpp +products: + - windows +--- + - -Usbsamp Generic USB Driver -========================== +# Usbsamp Generic USB Driver The USBSAMP sample demonstrates how to perform full speed, high speed, and SuperSpeed transfers to and from bulk and isochronous endpoints of a generic USB device. USBSAMP is based on the [Kernel Mode Driver Framework](http://msdn.microsoft.com/en-us/library/windows/hardware/ff557405) (KMDF). Superspeed bulk and isochronous transfers only work when the Microsoft USB 3.0 stack is loaded. @@ -18,46 +26,42 @@ The sample also contains a console test application that initiates bulk (includi For information about USB, see [Universal Serial Bus (USB) Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff538930). ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. -Hardware requirements ---------------------- +## Hardware requirements The sample driver can be loaded as the function driver for any of these devices: -- OSR FX2 learning kit. You can get the kit from [OSR Online](http://www.osronline.com/). -- [MUTT devices](http://msdn.microsoft.com/en-us/library/windows/hardware/dn376873). To order those devices, see [How to get MUTT devices](buses.microsoft_usb_test_tool__mutt__devices#howto). -- Intel 82930 USB test board. +- OSR FX2 learning kit. You can get the kit from [OSR Online](http://www.osronline.com/). +- [MUTT devices](http://msdn.microsoft.com/en-us/library/windows/hardware/dn376873). To order those devices, see [How to get MUTT devices](buses.microsoft_usb_test_tool__mutt__devices#howto). +- Intel 82930 USB test board. If you have a different USB device, you can still use the driver by adding the device's hardware ID to the INX file. Note that the data transfer scenarios will work only with the endpoints supported by the device. -Set the configuration and platform in Visual Studio ---------------------------------------------------- +## Set the configuration and platform in Visual Studio -In Visual Studio, in Solution Explorer, right click **Solution 'usbsamp' (3 projects)**, and choose **Configuration Manager**. Set the configuration and the platform. Make sure that the configuration and platform are the same for both the driver project and the package project. Do not check the **Deploy** boxes. +In Visual Studio, in Solution Explorer, right click **Solution 'usbsamp' (3 projects)**, and choose **Configuration Manager**. Set the configuration and the platform. Make sure that the configuration and platform are the same for both the driver project and the package project. Do not check the **Deploy** boxes. -Build the sample using Visual Studio ------------------------------------- +## Build the sample using Visual Studio In Visual Studio, on the **Build** menu, choose **Build Solution**. For more information about using Visual Studio to build a driver package, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644). -Locate the built driver ------------------------ +## Locate the built driver In File Explorer, navigate to the folder that contains your built driver package. The location of this folder varies depending on what you set for configuration and platform. For example, if your settings are Debug and x64, the driver is in your solution folder under sys\\driver\\Debug\\usbsamp. The driver folder contains these files: -File | Description ------|------------ -usbsamp.sys | The driver file. -usbsamp.inf | An information (INF) file that contains information needed to install the driver. -kmdfsamples.cat | A signed catalog file, which serves as the signature for the entire package. +| File | Description | +| --- | --- | +| usbsamp.sys | The driver file. | +| usbsamp.inf | An information (INF) file that contains information needed to install the driver. | +| kmdfsamples.cat | A signed catalog file, which serves as the signature for the entire package. | -Run the sample --------------- +## Run the sample The computer where you install the driver is called the *target computer* or the *test computer*. Typically this is a separate computer from where you develop and build the driver package. The computer where you develop and build the driver is called the *host computer*. @@ -67,57 +71,54 @@ The process of moving the driver package to the target computer and installing t Before you automatically deploy a driver, you must provision the target computer. For instructions, see [Configuring a Computer for Driver Deployment, Testing, and Debugging](http://msdn.microsoft.com/en-us/library/windows/hardware/). -1. On the host computer, in Visual Studio, in Solution Explorer, right click **package** (lower case), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**. -2. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, select the name of a target computer that you provisioned previously. Select **Install and Verify**. Click **OK**. -3. On the **Build** menu, choose **Deploy Package** or **Build Solution**. +1. On the host computer, in Visual Studio, in Solution Explorer, right click **package** (lower case), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**. +1. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, select the name of a target computer that you provisioned previously. Select **Install and Verify**. Click **OK**. +1. On the **Build** menu, choose **Deploy Package** or **Build Solution**. ### Manual deployment Before you manually deploy a driver, you must turn on test signing and install a certificate on the target computer. You also need to copy the [DevCon](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544707) tool to the target computer. For instructions, see [Preparing a Computer for Manual Driver Deployment](http://msdn.microsoft.com/en-us/library/windows/hardware/dn265571). -1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\Usbsamp). -2. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter the following command: +1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\Usbsamp). +1. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter the following command: **devcon install usbsamp.inf USB\\VID\_045E&PID\_078F** -View the device in Device Manager ---------------------------------- +## View the device in Device Manager On the target computer, in a Command Prompt window, enter **devmgmt** to open Device Manager. In Device Manager, on the **View** menu, choose **Devices by type**. In the device tree, locate the device. For example the device name might be **WDF Sample for FX2 MUTT device** under the**Sample Device** node. -Build the sample using MSBuild ------------------------------- +## Build the sample using MSBuild As an alternative to building the USBSAMP sample in Visual Studio, you can build it in a Visual Studio Command Prompt window. In Visual Studio, on the **Tools** menu, choose **Visual Studio Command Prompt**. In the Visual Studio Command Prompt window, navigate to the folder that has the solution file, Usbsamp.sln. Use the MSBuild command to build the solution. Here are some examples: -**msbuild /p:configuration="Debug" /p:platform="x64" Usbsamp.sln** + **msbuild /p:configuration="Debug" /p:platform="x64" Usbsamp.sln** -**msbuild /p:configuration="Release" /p:platform="Win32" Usbsamp.sln** + **msbuild /p:configuration="Release" /p:platform="Win32" Usbsamp.sln** For more information about using MSBuild to build a driver package, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644). -Testing the sample ------------------- +## Testing the sample The sample includes a test application, usbsamp.exe. This console application enumerates the interface registered by the driver and opens the device to send Read, Write, or DeviceIoControl requests based on the command line options. To test the sample, -1. In Visual Studio, choose **Solution Explorer** from the **View** menu. Locate the application project named **usbsamp**, under the **Exe** folder. -2. Right-click and choose **Build**. For example, if your settings are Debug and x64, the application executable is in your solution folder under the exe\\Debug\\usbsamp.exe. -3. Run the executable on the target machine. +1. In Visual Studio, choose **Solution Explorer** from the **View** menu. Locate the application project named **usbsamp**, under the **Exe** folder. +1. Right-click and choose **Build**. For example, if your settings are Debug and x64, the application executable is in your solution folder under the exe\\Debug\\usbsamp.exe. +1. Run the executable on the target machine. -- To view all descriptors and endpoint information, use the following command. +- To view all descriptors and endpoint information, use the following command. **usbsamp.exe -u** You can use the preceding command to view pipe numbers for read and write requests. -- To send a Read-Write request, use the following command. +- To send a Read-Write request, use the following command. **usbsamp.exe -r 1024 -w 1024 -c 100 -v** The preceding command first writes 1024 bytes of data to bulk out endpoint (pipe 1), then reads 1024 bytes from bulk in endpoint (pipe 0), and compares the read buffer with write buffer to see if they match. If the buffer contents match, it performs this operation 100 times. -- To send Read-Write requests to bulk endpoints, use any of the following commands, simultaneously. If Read-Write requests are sent to a SuperSpeed bulk endpoint with streams, the sample driver always uses the first underlying stream associated with that endpoint. The driver is multi-thread safe so it can handle multiple requests at a time. +- To send Read-Write requests to bulk endpoints, use any of the following commands, simultaneously. If Read-Write requests are sent to a SuperSpeed bulk endpoint with streams, the sample driver always uses the first underlying stream associated with that endpoint. The driver is multi-thread safe so it can handle multiple requests at a time. **usbsamp.exe -r 65536** @@ -135,7 +136,7 @@ The sample includes a test application, usbsamp.exe. This console application en The preceding command writes 65536 bytes to pipe 3. -- To send Read and Write requests to isochronous endpoints you can use one or more of these commands simultaneously. +- To send Read and Write requests to isochronous endpoints you can use one or more of these commands simultaneously. **usbsamp.exe -r 512 -i pipe04** @@ -149,8 +150,6 @@ The sample includes a test application, usbsamp.exe. This console application en The preceding command writes 1024 bytes to pipe 5, then reads 1024 bytes from pipe 4, and compares the buffers to see if they match. If the buffer contents match, it performs this operation 100 times. -- To skip validation of the data to be read or written in a particular request, use the command with **-x** option as follows: +- To skip validation of the data to be read or written in a particular request, use the command with **-x** option as follows: **usbsamp.exe -r 1024 -w 1024 -c 100 -x** - - diff --git a/usb/usbsamp/usb-usbsamp.yml b/usb/usbsamp/usb-usbsamp.yml deleted file mode 100644 index f6c894a8..00000000 --- a/usb/usbsamp/usb-usbsamp.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Usbsamp Generic USB Driver - description: Demonstrates how to perform full speed, high speed, and SuperSpeed transfers to and from bulk and isochronous endpoints of a generic USB device. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /usb/usbsamp/usbsamp.sln diff --git a/usb/usbview/README.md b/usb/usbview/README.md index 7321146d..abee2cef 100644 --- a/usb/usbview/README.md +++ b/usb/usbview/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: USBView sample application +description: Provides an application that allows you to browse all USB controllers and connected USB devices on your system. +languages: + - cpp +products: + - windows +--- + - -USBView sample application -========================== +# USBView sample application 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. @@ -17,59 +25,57 @@ This functional application sample demonstrates how a user-mode application can The IOCTL calls (see the system include file USBIOCTL.H) demonstrated by this sample include: -- [**IOCTL\_GET\_HCD\_DRIVERKEY\_NAME**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff537236) -- [**IOCTL\_USB\_GET\_DESCRIPTOR\_FROM\_NODE\_CONNECTION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff537310) -- [**IOCTL\_USB\_GET\_NODE\_CONNECTION\_DRIVERKEY\_NAME**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff537317) -- [**IOCTL\_USB\_GET\_NODE\_CONNECTION\_INFORMATION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff537319) -- [**IOCTL\_USB\_GET\_NODE\_CONNECTION\_NAME**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff537323) -- [**IOCTL\_USB\_GET\_NODE\_INFORMATION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff537324) -- [**IOCTL\_USB\_GET\_ROOT\_HUB\_NAME**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff537326) +- [**IOCTL\_GET\_HCD\_DRIVERKEY\_NAME**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff537236) +- [**IOCTL\_USB\_GET\_DESCRIPTOR\_FROM\_NODE\_CONNECTION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff537310) +- [**IOCTL\_USB\_GET\_NODE\_CONNECTION\_DRIVERKEY\_NAME**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff537317) +- [**IOCTL\_USB\_GET\_NODE\_CONNECTION\_INFORMATION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff537319) +- [**IOCTL\_USB\_GET\_NODE\_CONNECTION\_NAME**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff537323) +- [**IOCTL\_USB\_GET\_NODE\_INFORMATION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff537324) +- [**IOCTL\_USB\_GET\_ROOT\_HUB\_NAME**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff537326) For information about USB, see [Universal Serial Bus (USB) Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff538930). -Run the sample --------------- +## Run the sample ### Local debugging -1. Change **Debugger** to launch to **Local Windows Debugger**. -2. On the **Debug** menu, select **Start debugging** or hit **F5**. +1. Change **Debugger** to launch to **Local Windows Debugger**. +1. On the **Debug** menu, select **Start debugging** or hit **F5**. ### Manual deployment to a remote target computer If you want to debug the sample app on a remote computer, -1. Copy the executable to a folder on the remote computer. -2. Specify project properties as per the instructions given in [Set Up Remote Debugging for a Visual Studio Project](http://msdn.microsoft.com/en-us/library/8x6by8d2.aspx). -3. Change **Debugger** to launch to **Remote Windows Debugger**. -4. On the **Debug** menu, select **Start debugging** or hit **F5**. +1. Copy the executable to a folder on the remote computer. +1. Specify project properties as per the instructions given in [Set Up Remote Debugging for a Visual Studio Project](http://msdn.microsoft.com/en-us/library/8x6by8d2.aspx). +1. Change **Debugger** to launch to **Remote Windows Debugger**. +1. On the **Debug** menu, select **Start debugging** or hit **F5**. ### View a USB device in Usbview -1. Attach a USB device to one of USB ports on the computer that has Usbview running. -2. In the device tree, locate the device. For example the device might be under the Intel(R) ICH10 Family USB Universal Host Controller - 3A34 \> Root Hub node. -3. View host controller and port properties on the right pane. +1. Attach a USB device to one of USB ports on the computer that has Usbview running. +1. In the device tree, locate the device. For example the device might be under the Intel(R) ICH10 Family USB Universal Host Controller - 3A34 \> Root Hub node. +1. View host controller and port properties on the right pane. -Code tour ---------- +## Code tour -File manifest | Description ---------------|------------ -Resource.h | ID definitions for GUI controls -Usbdesc.h | USB descriptor type definitions -Usbview.h | Main header file for this sample -Vndrlist.h | List of USB Vendor IDs and vendor names -Debug.c | Assertion routines for the checked build -Devnode.c | Routines for accessing DevNode information -Dispaud.c | Routines for displaying USB audio class device information -Enum.c | Routines for displaying USB device information -Usbview.c | Entry point and GUI handling routines +| File manifest | Description | +| --- | --- | +| Resource.h | ID definitions for GUI controls | +| Usbdesc.h | USB descriptor type definitions | +| Usbview.h | Main header file for this sample | +| Vndrlist.h | List of USB Vendor IDs and vendor names | +| Debug.c | Assertion routines for the checked build | +| Devnode.c | Routines for accessing DevNode information | +| Dispaud.c | Routines for displaying USB audio class device information | +| Enum.c | Routines for displaying USB device information | +| Usbview.c | Entry point and GUI handling routines | The major topics covered in this tour are: -- GUI handling routines -- Device enumeration routines -- Device information display routines +- 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. @@ -77,9 +83,8 @@ The routine RefreshTree() is called to enumerate USB host controller, hubs, and 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. +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. +1. 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. +1. 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. - diff --git a/usb/usbview/usb-usbview.yml b/usb/usbview/usb-usbview.yml deleted file mode 100644 index 9cd8ed94..00000000 --- a/usb/usbview/usb-usbview.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: USBView sample application - description: Provides an application that allows you to browse all USB controllers and connected USB devices on your system. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /usb/usbview/usbview.sln diff --git a/usb/wdf_osrfx2_lab/README.md b/usb/wdf_osrfx2_lab/README.md index 14cb90e8..768e0dc1 100644 --- a/usb/wdf_osrfx2_lab/README.md +++ b/usb/wdf_osrfx2_lab/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: WDF Sample Driver Learning Lab for OSR USB-FX2 +description: Contains a console test application and a series of iterative drivers for both KMDF and UMDF version 1. +languages: + - cpp +products: + - windows +--- + - -WDF Sample Driver Learning Lab for OSR USB-FX2 -============================================== +# WDF Sample Driver Learning Lab for OSR USB-FX2 The wdf\_osrfx2\_lab sample contains a console test application and a series of iterative drivers for both Kernel-Mode Driver Framework (KMDF) and User-Mode Driver Framework (UMDF) version 1. diff --git a/usb/wdf_osrfx2_lab/usb-wdf-osrfx2-lab.yml b/usb/wdf_osrfx2_lab/usb-wdf-osrfx2-lab.yml deleted file mode 100644 index 8604f630..00000000 --- a/usb/wdf_osrfx2_lab/usb-wdf-osrfx2-lab.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: WDF Sample Driver Learning Lab for OSR USB-FX2 - description: Contains a console test application and a series of iterative drivers for both KMDF and UMDF version 1. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /usb/wdf_osrfx2_lab/wdf_osrfx2_lab.sln diff --git a/video/KMDOD/README.md b/video/KMDOD/README.md index 6c724af7..2fd3057c 100644 --- a/video/KMDOD/README.md +++ b/video/KMDOD/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: Kernel mode display-only miniport driver (KMDOD) sample +description: Implements most DDIs that a display-only miniport driver should provide to the Windows Display Driver Model (WDDM). +languages: + - cpp +products: + - windows +--- + -Kernel mode display-only miniport driver (KMDOD) sample -======================================================= +# Kernel mode display-only miniport driver (KMDOD) sample The kernel mode display-only miniport driver (KMDOD) sample implements most of the device driver interfaces (DDIs) that a display-only miniport driver should provide to the Windows Display Driver Model (WDDM). The code is useful to understand how to write a miniport driver for a display-only device, or how to develop a full WDDM driver. @@ -22,25 +31,23 @@ The sample driver does not support the *sleep* power state. If it is placed in t If the current display driver is not a WDDM 1.2 compliant driver, the sample driver might fail to install, with error code 43 displayed. The KMDOD driver is actually installed, but it cannot be started. The workaround for this issue is to switch to the Microsoft Basic Display Adapter Driver before installing the KMDOD sample driver, or simply to reboot your system after installing the KMDOD sample. - -Installation ------------- +## Installation In Microsoft Visual Studio, press **F5** to build the sample and then deploy it to a target machine. For more info, see [Deploying a Driver to a Test Computer](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454834). In some cases you might need to install the driver manually, as follows. -1. Add the following files to the directory given by ...\\[x64]\\C++\\Package: - - SampleDriver.cat - - SampleDriver.inf - - SampleDriver.sys - - SampleDriver.cer +1. Add the following files to the directory given by ...\\[x64]\\C++\\Package: + - SampleDriver.cat + - SampleDriver.inf + - SampleDriver.sys + - SampleDriver.cer -2. Unless you've provided a production certificate, you should manually install the SampleDriver.cer digital certificate with the following command: +1. Unless you've provided a production certificate, you should manually install the SampleDriver.cer digital certificate with the following command: `Certutil.exe -addstore root SampleDriver.cer` -3. Then enable test signing by running the following BCDEdit command: +1. Then enable test signing by running the following BCDEdit command: `Bcdedit.exe -set TESTSIGNING ON` @@ -48,13 +55,13 @@ In some cases you might need to install the driver manually, as follows. For more info, see [The TESTSIGNING Boot Configuration Option](http://msdn.microsoft.com/en-us/library/windows/hardware/ff553484). -4. Manually install the driver using Device Manager, which is available from Control Panel. +1. Manually install the driver using Device Manager, which is available from Control Panel. ### ACPI-based GPUs To install the KMDOD sample driver on a GPU that is an Advanced Configuration and Power Interface (ACPI) device, add these lines to the `[MS]`, `[MS.NTamd64]`, and `[MS.NTarm]` sections of the Sampledisplay.inf file: -``` +```inf Text " Kernel mode display only sample driver " = KDODSamp_Inst, ACPI\CLS_0003&SUBCLS_0000 " Kernel mode display only sample driver " = KDODSamp_Inst, ACPI\CLS_0003&SUBCLS_0001 @@ -64,4 +71,3 @@ Text This new code provides generic identifiers for ACPI hardware. You can optionally delete the original lines of code within these sections of the INF file. - diff --git a/video/KMDOD/video-kmdod.yml b/video/KMDOD/video-kmdod.yml deleted file mode 100644 index 70824db6..00000000 --- a/video/KMDOD/video-kmdod.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Kernel mode display-only miniport driver (KMDOD) sample - description: Implements most DDIs that a display-only miniport driver should provide to the Windows Display Driver Model (WDDM). - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /video/KMDOD/KMDOD.sln diff --git a/video/pixlib/README.md b/video/pixlib/README.md index 81258ab7..fa571540 100644 --- a/video/pixlib/README.md +++ b/video/pixlib/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: PixLib sample +description: Demonstrates how to implement the CPixel class for use by a display driver. +languages: + - cpp +products: + - windows +--- + - -PixLib sample -============= +# PixLib sample The PixLib sample demonstrates how to implement the **CPixel** class for use by a display driver. For more information, see the WDK documentation topic, [CPixel Support Methods for Lightweight MIP Maps](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540585). - diff --git a/video/pixlib/video-pixlib.yml b/video/pixlib/video-pixlib.yml deleted file mode 100644 index efff7fdd..00000000 --- a/video/pixlib/video-pixlib.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: PixLib sample - description: Demonstrates how to implement the CPixel class for use by a display driver. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /video/pixlib/pixlib.sln diff --git a/wia/README.md b/wia/README.md index 75df38c3..ba4b0104 100644 --- a/wia/README.md +++ b/wia/README.md @@ -1,4 +1,14 @@ - - -Windows Image Acquisition (WIA) Driver Samples -============================================== +# Windows Image Acquisition (WIA) Driver Samples The Windows Image Acquisition driver sample set contains samples and test tools for Windows Image Acquisition (WIA), a driver architecture and user interface for acquiring images from still image devices such as scanners. -### PRODUCTION SCANNING WIA 2.0 DRIVER +## PRODUCTION SCANNING WIA 2.0 DRIVER + The ProdScan directory contains a sample WIA 2.0 mini-driver. This sample shows how to add Production Scanning features to a WIA 2.0 mini-driver. -### EXTENDED WIA 2.0 MONSTER DRIVER +## EXTENDED WIA 2.0 MONSTER DRIVER + The Wiadriverex directory contains a sample WIA 2.0 mini-driver. This sample shows how to write a WIA 2.0 mini-driver that uses the stream-based WIA 2.0 transfer model. It also shows an implementation of a very simple segmentation filter, image processing filter, and error handling extension for the WIA 2.0 mini-driver. For more information, see [Introduction to WIA](http://msdn.microsoft.com/en-us/library/windows/hardware/ff542835). - -Build the sample ----------------- +## Build the sample You can build the sample in two ways: using the Visual Studio Integrated Development Environment (IDE) or from the command line using the Visual Studio Command Prompt window and the Microsoft Build Engine (MSBuild.exe). -**Building the sample using Visual Studio** +### Building the sample using Visual Studio -1.Open Visual Studio. From the **File** menu, select **Open Project/Solution**. Within your WDK installation, navigate to src\\wia and open the wia.sln project file. +1. Open Visual Studio. From the **File** menu, select **Open Project/Solution**. Within your WDK installation, navigate to src\\wia and open the wia.sln project file. -2.Right-click the solution in the **Solution Explorer** and select **Configuration Manager**. +1. Right-click the solution in the **Solution Explorer** and select **Configuration Manager**. -3.From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Windows 8.1 Debug or Windows 8.1 Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. +1. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Windows 8.1 Debug or Windows 8.1 Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in. -4.From the **Build** menu, click **Build Solution** (Ctrl+Shift+B). +1. From the **Build** menu, click **Build Solution** (Ctrl+Shift+B). Previous versions of the WDK used the Windows Build utility (Build.exe) and provided separate build environment windows for each of the supported build configurations. You can use the Visual Studio Command Prompt window for all build configurations. -**Building the sample using the command line (MSBuild)** +### Building the sample using the command line (MSBuild) -1.Open a Visual Studio Command Prompt window. Click **Start** and search for **Developer Command Prompt**. If your project is under %PROGRAMFILES%, you need to open the command prompt window using elevated permissions (**Run as administrator**). From this window you can use MsBuild.exe to build any Visual Studio project by specifying the project (.VcxProj) or solutions (.Sln) file. +1. Open a Visual Studio Command Prompt window. Click **Start** and search for **Developer Command Prompt**. If your project is under %PROGRAMFILES%, you need to open the command prompt window using elevated permissions (**Run as administrator**). From this window you can use MsBuild.exe to build any Visual Studio project by specifying the project (.VcxProj) or solutions (.Sln) file. -2.Navigate to the project directory and enter the **MSbuild** command for your target. For example, to perform a clean build of a Visual Studio driver project called extend.vcxproj, navigate to the project directory and enter the following MSBuild command: **msbuild /t:clean /t:build .\\extend.vcxproj**. +1. Navigate to the project directory and enter the **MSbuild** command for your target. For example, to perform a clean build of a Visual Studio driver project called extend.vcxproj, navigate to the project directory and enter the following MSBuild command: **msbuild /t:clean /t:build .\\extend.vcxproj**. -3.If the build succeeds, you will find the driver (extend.dll) in the binary output directory corresponding to the target platform, for example src\\wia\\extend\\Windows 8.1 Debug. +1. If the build succeeds, you will find the driver (extend.dll) in the binary output directory corresponding to the target platform, for example src\\wia\\extend\\Windows 8.1 Debug. -Run the sample --------------- +## Run the sample Run the "copywia.cmd” batch file to gather all of the binaries into a subdirectory named “wiabins”. The WIA driver sample can be installed by using the Add Device icon in the Scanners and Cameras control panel. Use the Have Disk button to point to the wiabins\\drivers or wiabins\\drivers folder. Wiatest.exe (from the WDK Tools\\Wia directory), MS Paint, the Scanner and Camera Wizard, or any TWAIN application (through the WIA TWAIN compatibility layer) can be used to test the samples. - diff --git a/wia/wia.yml b/wia/wia.yml deleted file mode 100644 index 036fbde7..00000000 --- a/wia/wia.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: Windows Image Acquisition (WIA) Driver Samples - description: Contains samples and test tools for Windows Image Acquisition (WIA), a driver architecture and user interface for acquiring images from still image devices such as scanners. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /wia/wia.sln diff --git a/wmi/wmiacpi/README.md b/wmi/wmiacpi/README.md index 75b3ef9e..3e38b3e6 100644 --- a/wmi/wmiacpi/README.md +++ b/wmi/wmiacpi/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: WMIACPI Sample +description: Contains ACPI BIOS and WMI sample code that enables instrumentation of the ACPI BIOS from within ACPI Source Language (ASL) code. +languages: + - cpp +products: + - windows +--- + - -WMI ACPI Sample -=============== +# WMI ACPI Sample The WMIACPI sample contains ACPI BIOS and Microsoft Windows Management Instrumentation (WMI) sample code that enables instrumentation of the ACPI BIOS from within ACPI Source Language (ASL) code. ASL code can expose data blocks, methods, and events through WMI by leveraging the ACPI-WMI mapping driver (Wmiacpi.sys). -Operation ---------- +## Operation The WMIACPI sample contains files which allow an ACPI BIOS developer to add instrumentation from within ASL code. ASL code can expose data blocks, methods, and events through WMI by leveraging the Wmiacpi.sys driver. For more information about the mechanics of writing ASL to expose instrumentation, see the *Windows Instrumentation: WMI and ACPI* white paper included in this sample and available on the Windows Hardware Developer Central (WHDC) Web site. The following table lists the files included in the sample and their function: -File +| File | Description| +| --- | --- | +| Device.asl | ASL code that can be included in the ACPI bios that exposes a set of packages, strings, data, methods and events. | +| Acpimof.mof | Managed object format (MOF) file that contains a description of the data blocks, methods, and events that are exposed. This description is required so that WMI can access the data blocks, methods, and events. | +| Acpimof.rc
Acpimof.def | Files that are required to build Acpimof.dll, which is a resource-only DLL. | +| Wmi-Acpi.htm | The *Windows Instrumentation: WMI and ACPI* whitepaper. | +| acpimov.vcxproj | Visual Studio project file for the sample. | +| acpimof.sln | Visual Studio solution file for the sample. | -Description - -Device.asl - -ASL code that can be included in the ACPI bios that exposes a set of packages, strings, data, methods and events. - -Acpimof.mof - -Managed object format (MOF) file that contains a description of the data blocks, methods, and events that are exposed. This description is required so that WMI can access the data blocks, methods, and events. - -Acpimof.rc - -Acpimof.def - -Files that are required to build Acpimof.dll, which is a resource-only DLL. - -Wmi-Acpi.htm - -The *Windows Instrumentation: WMI and ACPI* whitepaper. - -acpimov.vcxproj - -Visual Studio project file for the sample. - -acpimof.sln - -Visual Studio solution file for the sample. - -Installation ------------- +## Installation To add the sample code to your ACPI bios and access through WMI: -1. Include the contents of *Device.asl* to your ASL source and rebuild the DSDT. Update the operating system with the new DSDT through reflashing. -2. Build *Acpimof.dll* in the WMIACPI directory. *Acpimof.dll* is a resource-only DLL that contains the compiled MOF in a form that WMI can import into its schema. -3. Copy *Acpimof.dll* to %windir%\\system32 and add a value named "MofImagePath" under the HKEY\_LOCAL\_MACHINE\\CurrentControlSet\\Services\\WmiAcpi key. The contents of the value should be a path to the *Acpimof.dll* file. -4. Restart your computer. When Plug and Play (PnP) recognizes the new device with a pnpid of pnp0c14, it will install *Wmiacpi.sys* automatically and make the MOF resource in Acpimof.dll available to the WMI schema. +1. Include the contents of *Device.asl* to your ASL source and rebuild the DSDT. Update the operating system with the new DSDT through reflashing. +1. Build *Acpimof.dll* in the WMIACPI directory. *Acpimof.dll* is a resource-only DLL that contains the compiled MOF in a form that WMI can import into its schema. +1. Copy *Acpimof.dll* to %windir%\\system32 and add a value named "MofImagePath" under the HKEY\_LOCAL\_MACHINE\\CurrentControlSet\\Services\\WmiAcpi key. The contents of the value should be a path to the *Acpimof.dll* file. +1. Restart your computer. When Plug and Play (PnP) recognizes the new device with a pnpid of pnp0c14, it will install *Wmiacpi.sys* automatically and make the MOF resource in Acpimof.dll available to the WMI schema. Note that you do not need an INF file because Windows supplies an INF for the ACPI-WMI mapping driver device as part of the operating system. - diff --git a/wmi/wmiacpi/wmi-wmiacpi.yml b/wmi/wmiacpi/wmi-wmiacpi.yml deleted file mode 100644 index fd6a5ab0..00000000 --- a/wmi/wmiacpi/wmi-wmiacpi.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: WMIACPI Sample - description: Contains ACPI BIOS and WMI sample code that enables instrumentation of the ACPI BIOS from within ACPI Source Language (ASL) code. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /wmi/wmiacpi/wmiacpi.sln diff --git a/wmi/wmisamp/README.md b/wmi/wmisamp/README.md index 63f41048..50a27c77 100644 --- a/wmi/wmisamp/README.md +++ b/wmi/wmisamp/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: WmiSamp WMI Provider +description: Demonstrates how to register WMI providers in KMDF, create provider instances, and handle WMI queries sent to a device. +languages: + - cpp +products: + - windows +--- + - -Sample KMDF Driver Implementing a WMI Data Provider -=================================================== +# Sample KMDF Driver Implementing a WMI Data Provider WmiSamp WMI Provider is a sample KMDF driver that implements a WMI data provider. ## Universal Windows Driver Compliant + This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. The sample demonstrates how to register the WMI providers and create provider instances for the Framework device object. It also illustrates how to handle the WMI queries sent to the device. The **Firefly**, **PCIDRV**, and **Toaster** sample drivers also implement WMI data providers. -Installation ------------- +## Installation In Visual Studio, you can press F5 to build the sample and then deploy it to a target machine. For more information, see [Deploying a Driver to a Test Computer](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454834). **Note** You can obtain redistributable framework updates by downloading the *wdfcoinstaller.msi* package from [WDK 8 Redistributable Components](http://go.microsoft.com/fwlink/p/?LinkID=226396). This package performs a silent install into the directory of your Windows Driver Kit (WDK) installation. You will see no confirmation that the installation has completed. You can verify that the redistributables have been installed on top of the WDK by ensuring there is a redist\\wdf directory under the root directory of the WDK, %ProgramFiles(x86)%\\Windows Kits\\8.0. -Testing -------- +## Testing To test the WmiSamp driver, run the generated WmiSamp.vbs script file. This will cause WMI to query all data blocks and properties, and put the result in a .log file. For more sophisticated testing, the VBScript can be extended by hand. The WBEMTest tool (located in %windir%\\system32\\wbem\\) can also be used. - -WMI Mof Check Tool ------------------- +## WMI Mof Check Tool WmiMofCk validates that the classes, properties, methods and events specified in a binary mof file (.bmf) are valid for use with WMI. It also generates useful output files needed to build and test the WMI data provider. -- If the -h parameter is specified, a C language header file is created that defines the GUIDs, data structures, and method indices specified in the MOF file. - -- If the -t parameter is specified, a VBScript applet is created that will query all data blocks and properties specified in the .mof file. This can be useful for testing WMI data providers. - -- If the -x parameter is specified, a text file is created that contains the text representation of the binary .mof data. This can be included in the source of the driver if the driver supports reporting the binary .mof via a WMI query rather than a resource on the driver image file. - -- Usage: wmimofck -h\ -x\ -t\ \ +- If the -h parameter is specified, a C language header file is created that defines the GUIDs, data structures, and method indices specified in the MOF file. +- If the -t parameter is specified, a VBScript applet is created that will query all data blocks and properties specified in the .mof file. This can be useful for testing WMI data providers. +- If the -x parameter is specified, a text file is created that contains the text representation of the binary .mof data. This can be included in the source of the driver if the driver supports reporting the binary .mof via a WMI query rather than a resource on the driver image file. +- Usage: wmimofck -h\ -x\ -t\ \ **Note** A byproduct of compiling the .mof file is a .vbs file. This is a VBScript file that is run from the command line on the target machine running the new device driver. It will cause WMI to query all data blocks and properties, and put the results into a .log file. This can be very useful for testing WMI support in your driver. For more sophisticated testing, the VBScript can be extended by hand. - diff --git a/wmi/wmisamp/wmi-wmisamp.yml b/wmi/wmisamp/wmi-wmisamp.yml deleted file mode 100644 index 50b5446f..00000000 --- a/wmi/wmisamp/wmi-wmisamp.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: WmiSamp WMI Provider - description: Demonstrates how to register WMI providers in KMDF, create provider instances, and handle WMI queries sent to a device. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /wmi/wmisamp/wmisamp.sln diff --git a/wpd/WpdBasicHardwareDriver/README.md b/wpd/WpdBasicHardwareDriver/README.md index cf1b6dc7..191a1605 100644 --- a/wpd/WpdBasicHardwareDriver/README.md +++ b/wpd/WpdBasicHardwareDriver/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: WPD Basic Hardware Sample Driver +description: Supports nine sensor devices that integrate with the Parallax BS2 programmable microcontroller. +languages: + - cpp +products: + - windows +--- + - -WPD Basic Hardware Sample Driver (UMDF Version 1) -================================================= +# WPD Basic Hardware Sample Driver (UMDF Version 1) The WpdBasicHardwareDriver is a WPD driver that supports nine devices. These devices were selected because of their simplicity. This simplicity allowed the sample to focus on the tasks that are common to portable devices without getting bogged down in hardware complexities. @@ -25,9 +33,7 @@ The microcontroller firmware for each of the nine circuits is included in the ** For a complete description of this sample and its underlying code and functionality, refer to the [WPD Basic Hardware Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff597697) description in the Windows Driver Kit documentation. - -Related topics --------------- +## Related topics [WPD Design Guide](http://msdn.microsoft.com/en-us/library/windows/hardware/ff597864) @@ -35,21 +41,17 @@ Related topics [WPD Programming Guide](http://msdn.microsoft.com/en-us/library/windows/hardware/) - -Installation ------------- +## Installation To test this sample, you must have a test computer. This can be a second computer or, if necessary, your development computer. To install the WpdBasicHardwareDriver sample, do the following: -1. Copy the driver binary and the wpdbasichardwaredriver.inf file to a directory on your test computer (for example, C:\\wpdbasichardwaredriver.) - -2. Copy the UMDF coinstaller, WUDFUpdate\_*MMmmmm*.dll, from the \\redist\\wdf\\\ directory to the same directory (for example, C:\\wpdbasichardwaredriver). +1. Copy the driver binary and the wpdbasichardwaredriver.inf file to a directory on your test computer (for example, C:\\wpdbasichardwaredriver.) +1. Copy the UMDF coinstaller, WUDFUpdate\_*MMmmmm*.dll, from the \\redist\\wdf\\\ directory to the same directory (for example, C:\\wpdbasichardwaredriver). **Note** You can obtain the co-installers by downloading and installing the "Windows Driver Framework (WDF)" package from [WDK 8 Redistributable Components](http://go.microsoft.com/fwlink/p/?LinkID=226396). -3. Navigate to the directory that contains the INF file and binaries (for example, cd /d c:\\wpdbasichardwaredriver), and run DevCon.exe as follows: +1. Navigate to the directory that contains the INF file and binaries (for example, cd /d c:\\wpdbasichardwaredriver), and run DevCon.exe as follows: **devcon.exe install wpdbasichardwaredriver.inf WUDF\\WpdBasicHardware** You can find DevCon.exe in the \\tools directory of the WDK (for example, \\tools\\devcon\\i386\\devcon.exe). - diff --git a/wpd/WpdBasicHardwareDriver/wpd-wpdbasichardwaredriver.yml b/wpd/WpdBasicHardwareDriver/wpd-wpdbasichardwaredriver.yml deleted file mode 100644 index 087df718..00000000 --- a/wpd/WpdBasicHardwareDriver/wpd-wpdbasichardwaredriver.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: WPD Basic Hardware Sample Driver - description: Supports nine sensor devices that integrate with the Parallax BS2 programmable microcontroller. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /wpd/WpdBasicHardwareDriver/WpdBasicHardwareDriver.sln diff --git a/wpd/WpdHelloWorldDriver/README.md b/wpd/WpdHelloWorldDriver/README.md index e63159e3..d06cf001 100644 --- a/wpd/WpdHelloWorldDriver/README.md +++ b/wpd/WpdHelloWorldDriver/README.md @@ -1,77 +1,84 @@ +--- +topic: sample +name: WPD Hello World Sample +description: Supports four objects - a device object, a storage object, a folder object, and a file object. +languages: + - cpp +products: + - windows +--- + - -WPDHelloWorld sample driver for portable devices -================================================ +# WPDHelloWorld sample driver for portable devices The WpdHelloWorld sample driver supports four objects: a device object, a storage object, a folder object, and a file object. Each object supports corresponding properties. These properties are defined in the file WpdObjectProperties.h. The sample driver supports a device object that exposes ten read-only properties. These properties, their types, and their values are listed in the following table. -Property name | Property type | Value +Property name | Property type | Value --------------|---------------|------ -DEVICE_PROTOCOL | String | "Hello World Protocol ver 1.00" -DEVICE_FIRMWARE_VERSION | String | "1.0.0.0" -DEVICE_POWER_LEVEL | Integer | 100 -DEVICE_MODEL | String | "Hello World!" -DEVICE_MANUFACTURER | String | "Windows Portable Devices Group" -DEVICE_FRIENDLY | String | "Hello World!" -DEVICE_SERIAL_NUMBER | String | "01234567890123-45676890123456" -DEVICE_SUPPORTS_NONCONSUMABLE | Bool | True -WPD_DEVICE_TYPE | Integer | WPD_DEVICE_TYPE_GENERIC -WPD_FUNCTIONAL_OBJECT_CATEGORY | GUID | WPD_FUNCTIONAL_CATEGORY_STORAGE +DEVICE_PROTOCOL | String | "Hello World Protocol ver 1.00" +DEVICE_FIRMWARE_VERSION | String | "1.0.0.0" +DEVICE_POWER_LEVEL | Integer | 100 +DEVICE_MODEL | String | "Hello World!" +DEVICE_MANUFACTURER | String | "Windows Portable Devices Group" +DEVICE_FRIENDLY | String | "Hello World!" +DEVICE_SERIAL_NUMBER | String | "01234567890123-45676890123456" +DEVICE_SUPPORTS_NONCONSUMABLE | Bool | True +WPD_DEVICE_TYPE | Integer | WPD_DEVICE_TYPE_GENERIC +WPD_FUNCTIONAL_OBJECT_CATEGORY | GUID | WPD_FUNCTIONAL_CATEGORY_STORAGE The driver supports a storage object that exposes seven read-only properties. These properties, their types, and their values are listed in the following table. -Property name | Property type | Value +Property name | Property type | Value --------------|---------------|------ STORAGE_CAPACITY | 64-bit Integer | 1024 * 1024 -STORAGE_FREE_SPACE_IN_BYTES | 64-bit Integer | 1024 * 1024 +STORAGE_FREE_SPACE_IN_BYTES | 64-bit Integer | 1024 * 1024 STORAGE_SERIAL_NUMBER | String | 98765432109876-54321098765432 STORAGE_FILE_SYSTEM_TYPE | String | FAT32 STORAGE_DESCRIPTION | String | Hello World! Memory Storage System -WPD_STORAGE_TYPE | Integer | WPD_STORAGE_TYPE_FIXED_ROM -WPD_FUNCTIONAL_OBJECT_CATEGORY | GUID | WPD_FUNCTIONAL_CATEGORY_STORAGE +WPD_STORAGE_TYPE | Integer | WPD_STORAGE_TYPE_FIXED_ROM +WPD_FUNCTIONAL_OBJECT_CATEGORY | GUID | WPD_FUNCTIONAL_CATEGORY_STORAGE The driver supports a folder object that exposes three read-only properties. These properties, their types, and their values are listed in the following table. -Property name | Property type | Value +Property name | Property type | Value --------------|---------------|------ -WPD_OBJECT_DATE_MODIFIED | Date | 2006/6/26 5:0:0.0 -WPD_OBJECT_DATE_CREATED | Date | 2006/1/25 12:0:0.0 +WPD_OBJECT_DATE_MODIFIED | Date | 2006/6/26 5:0:0.0 +WPD_OBJECT_DATE_CREATED | Date | 2006/1/25 12:0:0.0 WPD_OBJECT_ORIGINAL_FILE_NAME_VALUE | String | Documents The driver supports a file object that exposes three read-only properties. These properties, their types, and their values are listed in the following table. -Property name | Property type | Value +Property name | Property type | Value --------------|---------------|------ -WPD_OBJECT_DATE_MODIFIED | Date | 2006/6/26 5:0:0.0 +WPD_OBJECT_DATE_MODIFIED | Date | 2006/6/26 5:0:0.0 WPD_OBJECT_DATE_CREATED | Date | 2006/1/25 12:0:0.0 -WPD_OBJECT_ORIGINAL_FILE_NAME | String | Readme.txt +WPD_OBJECT_ORIGINAL_FILE_NAME | String | Readme.txt In addition to the above properties, every object (for example, device, storage, folder, or file) also supports seven common WPD object properties. These are read-only properties that contain object-specific values for the most part. These properties, their types, and their values are listed in the following table. -Property name | Property type | Value +Property name | Property type | Value --------------|---------------|------ WPD_OBJECT_ID | String | Object-specific -WPD_OBJECT_PERSISTENT_UNIQUE_ID | String | Object-specific +WPD_OBJECT_PERSISTENT_UNIQUE_ID | String | Object-specific WPD_OBJECT_PARENT_ID | String | Object-specific WPD_OBJECT_NAME | String | Object-specific WPD_OBJECT_FORMAT | GUID | Object-specific -WPD_OBJECT_CONTENT_TYPE | GUID | Object-specific -WPD_OBJECT_CAN_DELETE | Bool | False +WPD_OBJECT_CONTENT_TYPE | GUID | Object-specific +WPD_OBJECT_CAN_DELETE | Bool | False For a complete description of this sample and its underlying code and functionality, refer to the [WPD HelloWorld Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/) description in the Windows Driver Kit documentation. -Related topics --------------- +## Related topics [WPD Design Guide](http://msdn.microsoft.com/en-us/library/windows/hardware/ff597864) diff --git a/wpd/WpdHelloWorldDriver/wpd-wpdhelloworlddriver.yml b/wpd/WpdHelloWorldDriver/wpd-wpdhelloworlddriver.yml deleted file mode 100644 index 3de52214..00000000 --- a/wpd/WpdHelloWorldDriver/wpd-wpdhelloworlddriver.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: WPD Hello World Sample - description: Supports four objects - a device object, a storage object, a folder object, and a file object. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /wpd/WpdHelloWorldDriver/WpdHelloWorldDriver.sln diff --git a/wpd/WpdMultiTransportDriver/README.md b/wpd/WpdMultiTransportDriver/README.md index 81e6bf30..7fe86fe4 100644 --- a/wpd/WpdMultiTransportDriver/README.md +++ b/wpd/WpdMultiTransportDriver/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: WPD multi-transport sample driver +description: Demonstrates how to extend the WpdHelloWorldDriver for a device that supports multiple transports. +languages: + - cpp +products: + - windows +--- + - -WPD multi-transport sample driver -================================= +# WPD multi-transport sample driver The WpdMultiTransportDriver sample demonstrates how you could extend the WpdHelloWorldDriver for a device that supports multiple transports. A transport is a protocol over which a portable device communicates with a computer. Example transports include Internet Protocol (IP), Bluetooth, and USB. @@ -17,8 +25,7 @@ A number of portable devices now support multiple transports. For example, a num For a complete description of this sample and its underlying code and functionality, refer to the [WPD MultiTransport Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff597709) description in the Windows Driver Kit documentation. -Related topics --------------- +## Related topics [WPD Design Guide](http://msdn.microsoft.com/en-us/library/windows/hardware/ff597864) diff --git a/wpd/WpdMultiTransportDriver/wpd-wpdmultitransportdriver.yml b/wpd/WpdMultiTransportDriver/wpd-wpdmultitransportdriver.yml deleted file mode 100644 index 776835d2..00000000 --- a/wpd/WpdMultiTransportDriver/wpd-wpdmultitransportdriver.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: WPD multi-transport sample driver - description: Demonstrates how to extend the WpdHelloWorldDriver for a device that supports multiple transports. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /wpd/WpdMultiTransportDriver/WpdMultiTransportDriver.sln diff --git a/wpd/WpdServiceSampleDriver/README.md b/wpd/WpdServiceSampleDriver/README.md index d946d59d..bf8a692c 100644 --- a/wpd/WpdServiceSampleDriver/README.md +++ b/wpd/WpdServiceSampleDriver/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: WPD service sample driver +description: Demonstrates how to extend the WpdHelloWorldDriver sample so that it supports a simulated device with a Contacts device service. +languages: + - cpp +products: + - windows +--- + - -WPD service sample driver -================================= +# WPD service sample driver Demonstrates how to extend the WpdHelloWorldDriver sample so that it supports a simulated device with a Contacts device service. -Related topics --------------- +## Related topics [WPD Design Guide](http://msdn.microsoft.com/en-us/library/windows/hardware/ff597864) diff --git a/wpd/WpdServiceSampleDriver/wpd-wpdwudfsampledriver.yml b/wpd/WpdServiceSampleDriver/wpd-wpdwudfsampledriver.yml deleted file mode 100644 index 20472a08..00000000 --- a/wpd/WpdServiceSampleDriver/wpd-wpdwudfsampledriver.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: WPD service sample driver - description: Demonstrates how to extend the WpdHelloWorldDriver sample so that it supports a simulated device with a Contacts device service. - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /wpd/WpdServiceSampleDriver/WpdServiceSampleDriver.sln diff --git a/wpd/WpdWudfSampleDriver/README.md b/wpd/WpdWudfSampleDriver/README.md index f325d5da..448e5a58 100644 --- a/wpd/WpdWudfSampleDriver/README.md +++ b/wpd/WpdWudfSampleDriver/README.md @@ -1,3 +1,13 @@ +--- +topic: sample +name: WPD WUDF sample driver +description: Demonstrates virtually all aspects of the WPD device driver interface (DDI). +languages: + - cpp +products: + - windows +--- + - -WPD WUDF sample driver -====================== +# WPD WUDF sample driver The comprehensive WPD sample driver (WpdWudfSampleDriver) demonstrates virtually all aspects of the Microsoft Windows Portable Devides (WPD) device driver interface (DDI). This driver is built as a normal User-Mode Driver Framework (UMDF) driver that also processes the WPD command set. Although this driver does not interact with actual hardware, it simulates communicating with a device that supports phone contacts, pictures, music, and video. @@ -19,9 +27,7 @@ Some of the tasks that are accomplished by the WpdWudfSampleDriver are written f For a complete description of this sample and its underlying code and functionality, refer to the [WPD WUDF Sample Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff597723) description in the Windows Driver Kit documentation. - -Related topics --------------- +## Related topics [WPD Design Guide](http://msdn.microsoft.com/en-us/library/windows/hardware/ff597864) diff --git a/wpd/WpdWudfSampleDriver/wpd-wpdservicesampledriver.yml b/wpd/WpdWudfSampleDriver/wpd-wpdservicesampledriver.yml deleted file mode 100644 index 4a2becbd..00000000 --- a/wpd/WpdWudfSampleDriver/wpd-wpdservicesampledriver.yml +++ /dev/null @@ -1,12 +0,0 @@ -### YamlMime:Sample -sample: -- name: WPD WUDF sample driver - description: Demonstrates virtually all aspects of the WPD device driver interface (DDI). - generateZip: true - preserveParentHierarchy: true - author: windows-driver-samples - languages: - - cpp - technologies: - - windows - vssolution: /wpd/WpdWudfSampleDriver/WpdWudfSampleDriver.sln