Designing great devices and drivers 9/15/2018 1:44 AM HW-322T Designing great devices and drivers Jim Cavalaris Principal Development Lead Microsoft Corporation © 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Customer and Partner Connections Customer and Partner Connections Device Life-cycle Customer and Partner Connections Design and Develop Assess and Certify Customer and Partner Connections Design and Develop Assess and Certify

Agenda Windows 8: Device experiences re-visited Elements of device and driver design Device Interface design Designing app experiences Putting it all together You’ll leave with an understanding of Device and driver design, from setup to software Best practices that enable a first-class device experience

Great devices don’t just happen Great devices don’t just happen. The best experiences are designed from setup to software.

Windows 8 introduces a new opportunity to design great device experiences.

Coming up… Device discovery and association Driver design and development Driver distribution and installation Built-in experiences, custom apps App design and development App distribution and installation App startup and best practices

Elements of device and driver design

Windows, meet my device.

Device discovery and association How Windows detects devices and intention to use Connected devices always detected, association implicit Loosely coupled devices may require user action Connectivity requirements influence bus and protocol design USB, Bluetooth, Wi-Fi/Wired Ethernet Bus and protocol design impact discovery and association Bluetooth, PnP-X discovery pairing ceremonies

Types of driver support Class driver (“inbox”) Custom driver supporting class protocols and interfaces Custom driver with custom interfaces

Class driver Best Practice Built-in support for common bus and protocol classes We’ve done all the work for you Integrated and consistent Windows experiences Compatible devices identified with bus-defined “class codes” PCI\CC_0300, USB\Class_08&SubClass_06&Prot_50 USB\COMPOSITE, HID_DEVICE, USB\MS_COMP_WINUSB umb\urn:microsoft-com:device:mtp:1

Custom driver with class support Implements well-known protocols, application interfaces Supports integrated Windows experiences Optional alternative to class driver for custom experiences Devices should still be compatible with inbox class drivers

Custom Driver with Custom Interfaces Implements custom interface Required when no established protocols or interfaces apply No Windows support for integrated experiences Typically requires custom app experiences

Developing custom drivers Device class may determine driver model, other restrictions Established frameworks for class support, miniport models, etc. Use the Windows Driver Frameworks (WDF) for custom drivers Really, why wouldn’t you? User-mode drivers provide best isolation for users (and developers!) Supported for many peripheral devices

Identify your device Hardware IDs describe a specific model of device USB\VID_vvvv&PID_dddd&REV_rrrr USB\VID_vvvv&PID_dddd Hint: Let’s look at vehicles. Think: “Make, Model, Year” AUTO\Chevy&Chevelle&Malibu&Coupe&1968 Compatible IDs describe class, determine inbox compatibility USB\Class_dd&SubClass_ss&Prot_pp Hint: For vehicles, we might think “Vehicle Type, Class, Attributes” AUTO\Car&Midsize&2Door

Best practices for using device IDs Target broadest Hardware ID possible to get the job done Drivers and device metadata Modify revision ID for driver-compatible devices Same driver, different metadata or minor configuration tweaks Hint: Think “Same basic auto parts, different styling, minor part differences” Modify product number when a new configuration is required Prevents previously released drivers from matching new IDs Hint: Think “New parts inventory”

Device interface design

Device interfaces Export device and driver functionality to other components Describes a “functional contract” supported by a device Typically an I/O contract implemented by driver Contract is known and shared between participants Devices may support more than one contract Feature discovery is implicit in device discovery

Device Interfaces are how devices are discovered in both desktop experiences and Metro style apps.

Class driver Class Compatible Apps Built-in Experiences Class driver defined Built-in Experiences Class Compatible Apps Windows built-in Device Interface {Class} Class Driver

Custom driver with class support Class driver defined Built-in Experiences Class Compatible Apps Custom Apps Windows built-in Custom driver defined Device vendor provided Device Interface {Class} + {Custom} Custom Driver

Custom driver with custom app Built-in Experiences Class Compatible Apps Custom Apps Custom driver defined Device vendor provided Device Interface {Custom} Custom Driver

Defining device interfaces Define new custom interface classes for … New custom feature set Extended feature set that fully encapsulates an existing contract Extend existing custom interface classes for … Incremental additions to feature set (new IOCTLs) Design individual methods to be extended Consider versioned data structures Drivers and apps should be backwards compatible with each other

Device interfaces and apps Apps negotiate with drivers to discover available functionality Maintain backwards compatibility in both drivers and apps Keep functional contracts abstract from specific app models Drivers may interact with both desktop and Metro style apps

Designing app experiences

Windows 8 introduces a new way of thinking about device app experiences. Let Windows deliver the experience for you.

Delivering the app experience: Windows 7 Custom Desktop App Fixed app experience Download and setup of combined driver and app can be a lengthy process {Custom} Custom Driver Driver Package

Metro style apps for devices Automatic download and setup, Windows does it all for you Built-in experiences for common device classes Support for custom apps Portable devices, Print, Mass Storage, etc. Custom drivers with custom interfaces Windows optimizes system resources when not in-use

Delivering the app experience: Windows 8 Metro style app for Devices Automatic download and setup of Metro style apps for devices {Custom} Custom Driver Faster download of simpler driver package Driver Package

Installing Metro style apps for devices Download and setup happens automatically on first connect (Yeah, that’s it)

Desktop apps and other software Did I mention Metro style apps for devices? Download and setup not so straight-forward Desktop app experiences only when necessary Admin management tasks Required infrastructure for integration with built-in experiences

Installing desktop apps and other software Package desktop apps separate from drivers Avoid co-installers to auto-install apps, please Why? Driver’s role is hardware support, too low to define user experiences Apps get “stale” more quickly than drivers Assumes fixed Windows feature set, potential compatibility issues Assumes a specific experience, users may want a different one Future-proof your experience [desktop, Metro style apps, ...???] Windows scales everywhere client to server, devices should too

Installing desktop apps and other software OK to package required components with driver Driver files, COM components, Services, simple Control Panel items Only as necessary for minimal functionality with built-in experiences Use only native INF directives, avoid run-time installers Install Services using AddService Simple Control Panel items using AddReg [HKLM, HKCR] Register COM components using AddReg [HKCR] Avoid Co-installers, Class installers, please

When you keep your package simple… Driver package download is fast Device configuration is really really fast on Windows 8! Go to Chalk Talk session [888] to learn how we did it Put the user in control over the experience Metro style app for the device downloaded, if available User decides if they need a desktop app experience OK, so how should you package a desktop app experience?

Request software indirectly from the INF Simple INF directive: RequestAdditionalSoftware [ControlFlags] RequestAdditionalSoftware=* applies to all devices installed by the driver package, or … RequestAdditionalSoftware=device-identification-string[,device-identification-string] ... only to specific devices. Available on Windows 7 and later.

How RequestAdditionalSoftware works… Puts the user in control over the experience they want Device INF indicates that software may exist for the device Partner solutions can be submitted at any time Can be updated to stay current and compatible Windows Problem Report is created during device installation Action Center notifies user of a Solution Solution URL links to latest app on vendor website User may choose to download the app On their own time, on connected power, over cheap bandwidth, etc.

Delivering the app experience: Windows 8 Metro style app for Devices Custom Desktop App {Custom} Custom Driver User in control of Desktop app setup Driver Package

Delivering the app experience: Tomorrow? Metro style app for Devices ??? Custom Desktop App {Custom} Future-proof your experiences by de-coupling driver and apps Custom Driver Driver Package

Best practices for desktop software Avoid Startup apps, always-running services Why? Your device may not be around But not me, right? Yes!, even you PCI, and other internal chassis devices Windows To Go changes the game Windows now roams to multiple PCs Even devices inside a PC can be “unplugged”

Starting desktop software Run only when your device is present Let Windows take care of starting desktop apps and services Device interface arrival as trigger-start event for desktop services Custom driver ETW events as trigger-start for apps and services Shutdown when you’re done Register for device notifications Stop services and apps when idle, when device is removed

Putting it all together

Key takeaways, devices and drivers Design great device experience start from setup to software Choose appropriate connectivity, bus, protocol Identify your device to match best driver Use class drivers, custom drivers if needed Design abstract device interface contracts for custom drivers Keep driver packages simple for best setup experiences

Key takeaways, apps Develop Metro style apps for devices Separate other apps from driver package Put user in control over experience Follow best practices for running desktop apps

Got all the pieces? Great! Go to these sessions to learn more…

Related sessions [HW-903T] Best practices for packaging and distributing device drivers [HW-328T] Using the Windows Driver Framework to build better drivers [HW-747T] Building Metro style apps that connect to specialized devices

Further reading and documentation Choosing a driver model Advantages of Writing UMDF Drivers Windows Hardware Dev Center Windows Dev Center

Further reading and documentation Device Interfaces Overview RequestAdditionalSoftware INF [ControlFlags] directive Trigger-Start Service

thank you Feedback and questions http://forums.dev.windows.com Session feedback http://bldw.in/SessionFeedback

9/15/2018 1:44 AM © 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION. © 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.