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

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

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

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

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

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

7. Elements of device and driver design

8. Windows, meet my device.

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

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

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

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

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

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

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

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

17. Device interface design

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

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

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

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

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

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

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

25. Designing app experiences

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

41. Putting it all together

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

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

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

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

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

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

48. thank you Feedback and questions http://forums.dev.windows.com
Session feedback

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