Windows Portable Devices Team Blog : MTP

Windows 7 Device Implementation Guidelines for Picture and Video Import

wpdblog — Sat, 14 Nov 2009 00:51:42 GMT

The Guidelines for Picture and Video Import in Windows 7 white paper provides information about the picture and video import feature in Windows 7. The white paper includes guidelines for OEMs designing digital cameras and camera-equipped portable devices compatible with and optimized for Windows 7. The following screenshot shows a Device Stage experience for a cellular phone that supports photo and/or video import. The Windows 7 inbox photo import task appears as one of the many tasks that an end-user can interact with that phone.

This white paper describes the types of devices that are supported in Windows 7 for the picture and video import feature. In addition, this paper discusses device requirements and recommended features for optimal performance during the import of pictures and video from the device.

Topics Covered

Some of the topics covered in this white paper are:

The supported device classes
The supported picture and video formats
Device requirements and recommendations:
- Preventing re-import of videos synchronized with Windows Media Player by implementing Sync ID device property
- Improving import performance by implementing the Hints Device Service
- Enabling a determinate-style progress bar like the one shown below, instead of the default indeterminate progress bar

More Resources

You can find this whitepaper and more related Windows Portable Devices information (for both application and device development) on the Windows Hardware Developer Central portal.

This posting is provided "AS IS" with no warranties and confers no rights.

WPD Platform Update for Windows Vista

wpdblog — Wed, 28 Oct 2009 01:04:58 GMT

Today we are announcing the final release of the Platform Update for Windows Vista, which includes an update to WPD to support new features introduced in Windows 7.

The Platform Update for Windows Vista features a set of runtime libraries which add support for new technologies making it easier for developers to develop for Windows 7 and Windows Vista without impacting their users.

Features

The WPD update adds WPD and MTP Device Services and MTP over Bluetooth features to Windows Vista. The following table identifies the WPD features supported for Windows 7, for Windows Vista, and for Windows Vista with the Platform Update for Windows Vista installed.

Feature	Windows 7	Windows Vista	Windows Vista + Platform Update for Windows Vista
MTP over USB	Yes	Yes	Yes
MTP over IP	Yes	Yes	Yes
MTP over Bluetooth	Yes	No	Yes
WPD and MTP Device Services	Yes	No	Yes
WPD Automation	Yes	No	No
Multi-function/Multi-transport	Yes	No	No
Device Stage	Yes	No	No
Device Sync Platform	Yes	No	No

Availability and installation

The Platform Update for Windows Vista is available for free via Windows Update, Windows Server Update Services and the Microsoft Download Center. Customers running Windows Vista Service Pack 2 with “recommended settings” enabled for Windows Update will automatically receive the update without additional action. The update is also available as a free download on the Microsoft Download Center.

Additional notes about the Platform Update for Windows Vista

All the updated technologies in the Platform Update for Windows Vista are already included in Windows 7. The Platform Update for Windows Vista is not required for Windows 7.

To apply the Platform Update for Windows Vista, you must have Windows Vista Service Pack 2 installed.

More information

For specific details about the Platform Update for Windows Vista, click here.

For more information about MTP Device Services, check out the Introducing Device Services entry.

For more information about MTP transports such as USB, IP, and Bluetooth, check out the MTP Over Various Transports entry.

This posting is provided "AS IS" with no warranties and confers no rights.

The MTP Device Simulator

wpdblog — Sat, 24 Oct 2009 00:52:25 GMT

The Media Transfer Protocol Device Simulator (MTP Simulator) is a fully-featured, self-contained device simulator that emulates an MTP device. Its primary purpose is to enable developers to exercise expected behavior based on the MTP specification by returning appropriate MTP response packets and generating MTP events. The tool’s graphical user interface (GUI) enables easy configuration of MTP parameters and presents MTP traffic and data in a friendly, human-readable format.

The MTP Simulator implements all MTP device capabilities, object properties, and operations that are based on the MTP Specification along with the major features in Windows 7. Additionally, the MTP Simulator also supports Device Stage and loading customizable device profiles.

For transport support, the MTP Simulator runs on multiple transport options such as USB, Software-Simulated USB (SoftSim), Bluetooth, and IP. Last, but not the least, the MTP Simulator runs on both Windows Vista and Windows 7.

Where to get the MTP Simulator

The MTP Simulator is publicly available as part of the Windows 7 Portable Device Enabling Kit for MTP (DEK). The kit also includes support documentation for the MTP Simulator and the MTP Specification Version 1.0 and MTP Device Services for Windows. Included in the DEK is the MTP Device Simulator User Guide which provides a detailed description of the MTP Simulator.

Installing the MTP Simulator

The MTP Device Simulator is installed as part of the Windows 7 Portable Device Enabling Kit for MTP (DEK). Before running the simulator for the first time, you may need to install the Device Simulation Framework (DSF).

To install DSF:

Browse to the folder where the DEK is installed (usually C:\Windows7DEK)
Navigate to the Tools\MTP Device Simulator\Dsf subfolder
Open an elevated command window (i.e. "Run as Administrator”) and launch install.cmd to start the DSF MSI package install.

Once DSF is installed, you can launch the MTP Simulator from C:\WindowsDEK\Tools\MTP Device Simulator\MTPSimUI.exe. Select your desired transport, and click “Connect” to launch an instance of the MTP Simulator. The next section gives an overview of the User Interface.

User Interface

The following screenshot shows the MTP Simulator UI with navigation buttons and configuration options.

MTP Simulator Configuration	Location	Purpose
Connection	Left control tabs and menu options.	Connect, disconnect, or restart MTP Simulator by using the currently selected configuration. You can change the transport type on the Transport tab and change the test mode on the Device Mode tab.
Transport	Left control tabs and menu options.	Select the transport to be used. To simulate a software-only USB device, select the “SoftUSB” transport.
Device mode	Left control tabs and menu options.	Normal Mode should be used. Test Mode is reserved for internal Microsoft testing.
Output windows	Lower-right output window.	This window displays redirected output from stdout. Any output from a printf statement, such as trace—from either MTP Simulator or a plug-in—appears in this window. The output is also saved as mtpsimui.log automatically under the MTP Simulator root directory.

Table 1. MTP Simulator User Controls

Command-Line Options

In addition to the GUI, you can control MTP Simulator at startup by using command-line parameters. This can be useful when you need to perform automated testing. For details, see Appendix C from the MTP Device Simulator User Guide.

Customizing the MTP Simulator

You can control the capabilities that the MTP Simulator reports to Windows by using an XML file (see Appendix F in the MTP Device Simulator User Guide for details). Device capabilities are controlled by DeviceSummary.xml, and service capabilities are controlled by Services.xml.

The DeviceSummary.xml file enables you to customize the contents of the DeviceInfo, StorageInfo, DevicePropDesc, and ObjectPropDesc datasets.

The Services.xml file enables you to specify configurations that are related to device services, including service-supported formats, methods, and events.

Device Profiles

The MTP Simulator also supports loading different device profiles. A device profile contains a set of customized configuration files (i.e. DeviceSummary.xml and Services.xml) describing a sample device. The DEK comes bundled with sample profiles representing each device class (Camera, Cellular Phone, Media Player, etc). Details of how to load the device profiles are outlined in the MTP Device Simulator User Guide.

Device Profile	Description
Fabrikam_Camera	Simulates a sample camera.
Fabrikam_Phone	Simulates a cellular phone.
Fabrikam_PMP	Simulates a portable media player.
MtpSim-FullEnumSync	Simulates a device that supports the Full Enumeration synchronization model, for example for contacts, calendar, tasks, and notes synchronization.
MtpSim-FullEnumSyncSimpleParticipant	Simulates a device that supports the Full Enumeration synchronization model (like MtpSim-FullEnumSync), with additional support for the simple participant feature.

Table 2: Sample MTP Simulator Device Profiles

Each of these profiles has a corresponding Device Stage package. Each of these packages supports the same set of standard Device Stage tasks, with the exception of the Ringtone task which is not supported by the Fabrikam_Camera and Fabrikam_PMP profiles. For more information on authoring Device Stage metadata, refer to the Windows 7 Device Stage Development Guide in the Microsoft Device Experience Development Kit.

Testing Device Stage Packages

The MTP Simulator can also be used to test custom Device Stage packages. The MTP Device Inspector tool can be used to generate a device profile which can be loaded into the Simulator (see the MTP Device Simulator User Guide for details). Once a custom Device Stage metadata package has been authored, the package contains all the files necessary to display a Device Stage experience in Windows 7. The package may be tested by copying it to the PC’s device metadata store and connecting the test device, in this case rapid development can be done using the MTP Simulator. In order to load (unsigned) custom Device Stage metadata the system will need to be boot into test mode. For more details, refer to page 40 of the Windows 7 Device Stage Development Guide document that is included in the Microsoft Device Experience Development Kit for details on testing Device Stage metadata packages.

Want to Learn More?

The MTP Device Simulator User Guide in the Documentation for the Device Enabling Kit contains more information on the features described above.

If you have general questions about the MTP Simulator contact AskMTP at Microsoft dot com.

This posting is provided "AS IS" with no warranties and confers no rights.

Windows 7 Portable Device Development Kits

wpdblog — Sat, 12 Sep 2009 09:58:00 GMT

There are several different resources made available to portable device manufacturers to assist in device firmware and driver development, and to application developers wishing to create applications that interact with these portable devices. These resources are provided and maintained by members of the Windows Portable Devices team.

This post provides a description for the following development kits:

Windows 7 Portable Device Enabling Kit for MTP
Windows Portable Devices SDK
Windows Portable Devices Driver Kit
Windows Media Device Manager SDK
Microsoft Device Experience Development Kit
Windows Logo Kit

Windows 7 Portable Device Enabling Kit for MTP

This development kit is designed to assist portable device manufacturers in the development of Media Transfer Protocol (MTP) device firmware that is compatible with the various MTP device transports that Windows supports, and with Device Services. There are two packages provided for download:

Windows 7 Portable Device Enabling Kit for MTP - Tools
The tools kit includes design documentation and implementation guidelines, a Windows-based reference design, development tools, and the updated MTP Device Simulator.

Windows 7 Portable Device Enabling Kit for MTP - Reference Code
The reference code kit includes the core responder reference source code that is being made available under a separate Berkeley Software Distribution (BSD)–style license.

To download both packages of the Windows 7 Portable Device Enabling Kit for MTP, go to: http://www.microsoft.com/whdc/device/wpd/MTP-DEK_Win7.mspx

You are not required to license the reference code in order to use the tools and resources provided in the tools kit. This kit is free to download and use.

Windows Portable Devices SDK

The WPD SDK includes the WPD Application Programming Interface (API) that is supported in Windows 7, Windows Vista, and Windows XP operating Systems. Developers will use this API to write Windows applications in C++. Being a COM API, the WPD API is also accessible from Managed code, so C# .Net, and Visual Basic .Net applications can use COM Interoperability to invoke the same functionality that the C++ API provides. WPD applications can: explore a device, send and receive content, and even control the device, for example, take a picture or send a text message.

The WPD SDK includes two sample applications for C++/COM developers. The first, WpdApiSample, is a command-line desktop application that demonstrates how you would: enumerate connected devices, explore those devices, query device-objects for properties and attributes, send and retrieve data, and so on. The second sample, WpdServicesApiSample, is a command-line desktop application that demonstrates how you would explore a Contacts service on a device that is attached to your computer.

The WPD SDK also includes an Automation Object Model that is supported in Windows 7. Developers can use the Automation model to write web applications that accomplish tasks similar to those accomplished with the API. We provided an introduction to WPD Automation in this recent post.

The WPD SDK is included in the Windows SDK which can be downloaded from http://www.microsoft.com/downloads/details.aspx?FamilyID=c17ba869-9671-4330-a63e-1fd44e0e2505&displaylang=en

The documentation for the WPD SDK (both the API and Automation Object Model) is found on MSDN at: http://msdn.microsoft.com/en-us/library/dd388998(VS.85).aspx

Windows Portable Devices Driver Kit

The WPD Driver Kit includes a Device Driver Interface (DDI) that is supported in Windows 7, Windows Vista, and Windows XP operating Systems. Developers will use this DDI to write drivers for devices that are not already supported by the MTP or Mass Storage class drivers that Microsoft distributes.

The WPD Driver Kit includes five sample device drivers which are described in the following table. In the next post, we covered each sample in more detail.

Sample Driver	Description
WpdHelloWorldDriver	This is the most basic WPD driver that emulates interaction with hardware. Supports four objects: device, storage, folder, and file. This provides the scaffolding or skeleton for developing a WPD driver.
WpdBasicHardwareDriver	Builds upon the WpdHelloWorldDriver and demonstrates interaction with simple hardware devices. Supports nine sensor devices: 2-axis accelerometer, 3-axis accelerometer, temperature/humidity sensor, pressure sensor, distance sensor, passive infrared sensor, compass, vibration sensor, and light sensor. These sensor devices are simple devices that are controlled by a Parallax BS2 microcontroller attached to the PC. If you plan to develop drivers that integrate sensors with Windows 7, we recommend using the Sensor API and Sensor Driver Model. If you need to develop drivers to integrate sensors with Windows Vista or Windows XP, WPD provides a viable solution.
WpdServiceSampleDriver	Demonstrates how a developer would extend the WpdHelloWorldDriver to support a simulated device with a Contacts device service.(Using this service, WPD applications can discover events, methods, and properties associated with the Contacts stored on the device. This sample emulates interaction with hardware.
WpdMultiTransportDriver	Demonstrates how developers can take advantage of the Windows 7 support for multiple transports. The sample emulates interaction with hardware and demonstrates support for the following transports: IP, Bluetooth, and USB. We covered an overview of Multi-transport support in Windows 7 here.
WpdWudfSampleDriver	A comprehensive sample driver that demonstrates what to enable in the WPD DDI for media transfer scenarios (such as music and photos). This sample supports media synchronization with Windows Media Player, and also emulates interaction with hardware.

The WPD Driver Kit is included in the Windows Driver Kit (WDK). For information about downloading the WDK, see: http://www.microsoft.com/whdc/devtools/wdk/WDKpkg.mspx

The documentation for the WPD Driver Kit is found on MSDN at: http://msdn.microsoft.com/en-us/library/dd419925.aspx

Windows Media Device Manager SDK

The Windows Media Device Manager (WMDM) SDK enables you to build desktop applications and components that can communicate with connected portable devices. WMDM enables your application or component to enumerate, explore, and exchange files with a device, query for metadata, and request play count information. Applications or components built on WMDM have a consistent API for communicating with a wide range of devices including Media Transfer Protocol (MTP), Mass Storage Class (MSC), RAPI, and other devices built on both the latest and previous versions of Windows Media technology.

The Windows Media Device Manager SDK is available at: http://msdn.microsoft.com/en-us/windows/bb190309.aspx.

Microsoft Device Experience Development Kit

The Microsoft Device Experience Development Kit provides detailed information and material that you would need to know in order to develop Device Stage™ experiences for Portable Devices. The development kit includes device development guides, planning worksheets, tutorials, and development samples that you can use when developing a Device Stage experience on Windows 7. For portable devices, Device Stage supports the industry-standard Media Transfer Protocol (MTP) 1.0 with device services that enable a new rich set of features in Windows 7.

The development kit along with other pertinent information to build a complete Windows Device Experience is available at: http://www.microsoft.com/whdc/device/DeviceExperience/default.mspx

The kit is free to download and use.

Windows Logo Kit

The primary use of the Windows Logo Kit (WLK) is for Windows Logo Program device certification. This kit can also be used for product development. We encourage its use during the product development cycle of hardware in order to ensure device compliance with both Windows and industry standards. The kit includes several tests designed to validate device implementation and behavior at multiple levels. There are tests for USB compliance, Media Transfer Protocol (MTP) compliance, and Windows Portable Devices (WPD) platform compliance that also cover device services validation.

There is a significant amount of information available about the WLK, including user guides and video tutorials. For more information about the WLK see: http://www.microsoft.com/whdc/winlogo/WLK/default.mspx

The kit is free to download and use.

Other Resources

Windows Portable Devices node on Windows Hardware Developer Central

http://www.microsoft.com/whdc/device/wpd/default.mspx

Windows Portable Devices on Microsoft Developer Network

http://msdn.microsoft.com/en-us/library/dd388998(VS.85).aspx

This posting is provided "AS IS" with no warranties and confers no rights.

MTP Over Various Transports

wpdblog — Sat, 29 Aug 2009 08:52:00 GMT

Introduction

The Media Transfer Protocol (MTP) was originally created as an extension to the Picture Transfer Protocol but today it also supports media transfer, Device Services, command & control, and many other scenarios. MTP supports three transports: USB, IP, and Bluetooth.

One of most common drivers that WPD applications will interact with is the Media Transfer Protocol (MTP) driver. MTP was introduced in Windows XP with an inbox user mode driver allowing for effortless device installation and connectivity. MTP is standardized through the USB Implementer’s Forum (www.usb.org) and also features Windows-specific extensions.

We introduced a MTP driver for USB in Windows XP. In Windows Vista, we added support for MTP over TCP/IP for devices that use WiFi and LAN connections. In Windows 7, we continue the parade of MTP support with the introduction of Bluetooth.

3 transports, one protocol

MTP includes a protocol definition and several transport definitions. As devices and PCs pick and choose which connectivity transports they support, device & application developers can be assured that the MTP protocol and WPD API will be consistent. Three-transport support gives device manufacturers flexibility to choose wired or wireless, high or low power, faster or slower transfer speed, etc. The MTP driver is also the first multi-transport driver in Windows, which means that a device manufacturer can feel free to implement all three and Windows will choose the best. We’ll talk about that more in our next entry Multi-transport Devices in Windows 7.

USB

Our first MTP transport driver is also the fastest and most powerful way to connect an MTP-enabled device. Windows XP through Windows 7 support USB 1.1 or higher. The binding of MTP to USB is described in the MTP specification itself (http://www.usb.org/developers/devclass_docs/MTP_1.0.zip) and in the Still Imaging Capture Device Definition specification (http://www.usb.org/developers/devclass_docs/usb_still_img10.zip). Windows XP uses the Microsoft OS Descriptor to identify MTP devices; Windows Vista and Windows 7 can identify MTP devices by either the OS Descriptor or the USB Still Image Class Code (Class 6, Subclass 1, Protocol 1). Much of this is detailed in the Windows Portable Device Enabling Kit.

In Windows 7, we also enabled the USB Selective Suspend for the MTP driver, although this option is not enabled by default to preserve maximum ecosystem compatibility.

USB is great for fast file transfer, media synchronization, and charging the device while you’re using it.

In Windows Vista, we implemented MTP over TCP/IP to enable WiFi and networked devices to interact with WPD applications. We used the PTP/IP binding (http://www.cipa.jp/ptp-ip/index_e.html), then used UPnP for pairing and discovery. When devices report their presence on a network via UPnP after the initial pairing, Windows will automatically connect and make the device available to the user.

MTP/IP is ideal for devices with WiFi that can be connected and synchronized anywhere in the home.

Bluetooth

In Windows 7, we introduced Bluetooth as the third transport for MTP. We implemented MTP over the L2CAP protocol for fast, efficient, and secure connections. The specification is available in the Windows Portable Device Enabling Kit. PC users can switch the connection on and off through the Devices & Printers folder, or devices themselves can initiate and terminate connections to the PC.

We also implemented an "auto connect" feature in which Windows attempts to connect to your device every few minutes to maintain a low power connection for automatic synchronization and status updates. When you are holding the device near your PC, you’re connected; when you walk away, the connection breaks and waits silently to reconnect when you return and your device gets back into Bluetooth range.

Applications can use the IPortableDeviceConnect interface to issue connect/disconnect requests to an MTP/Bluetooth device. When a connection request is made, the MTP/Bluetooth link is established, the WPD MTP driver stack will load, and the device becomes visible to WPD applications to connect to using the WPD API.

Windows requires Bluetooth 1.2 or higher with the Microsoft Bluetooth stack installed. For maximum security, Windows also requires that the device is paired securely with a pin code.

MTP/BT is great for low power, low speed scenarios like synchronizing PIM data or a quick file transfer.

Operating System Support

The MTP driver is present in Windows XP with Windows Media Player 10 or higher installed, Windows Vista, and Windows 7.

MTP Driver Support by Operating System

Windows Version

USB 1.1 or higher

Bluetooth 1.2 or higher

Windows XP

Yes, with Windows Media Player 10 or higher

Windows Vista

Yes

Windows Vista + Platform Update for Window Vista

Yes

Windows 7

Yes

This posting is provided "AS IS" with no warranties and confers no rights.

Introducing Device Services

wpdblog — Sat, 15 Aug 2009 07:10:00 GMT

What are Device Services?

"Device Services" is a brand new concept introduced in Windows 7 that provides a framework for device manufacturers to extend device functionality, and new APIs for applications to discover and access that extended functionality using WPD. We decided to call these extensions to device functionality "Device Services" because they foster rich interaction between the PC and devices by providing a model for devices to formalize extension capabilities and make these capabilities accessible to applications.

Device Services are available in Windows 7 and Windows Vista with the Platform Update for Windows Vista.

Why do we need Device Services?

First, a quick historical perspective. Media Transfer Protocol (MTP - one of the protocols supported within WPD) was introduced beginning with Windows Media Player 10 as an extension of the Picture Transfer Protocol (PTP). MTP became a USB standard, and was widely adopted by a myriad of device classes: media players, mobile phones, cameras, Xbox 360s, etc. True to its PTP origins, MTP 1.0 was very media-centric; the scenarios it excelled in revolved around browsing device content and exchanging media files (images, music, and video, etc) between device and the PC.

Enabling PIM Scenarios

With Windows 7, we shifted our focus to enabling more device-to-PC scenarios centered around managing and accessing Personal Information Management (PIM) data (contacts, tasks, calendar, etc.) on the device. These involved more complex operations such as SMS, email and advanced synchronization with Outlook™. Non-media files present additional challenges in accessing and enumerating them efficiently on the device. Unlike an MP3 or a JPEG file, a contact or task may not be represented by a physical file on the device storage. Depending on device implementation, these objects could be stashed anywhere: in databases, in SIM cards, etc.

Honey, where did you put my contacts (and music, and photos, and ...)?

Another common problem is that there was no standardized method for a device to figure out where to put its content. Most applications would have to guess at a location, choose or specify an application-specific location, or crawl the entire device, often just to locate a subset of content. [Aside: In Vista, WPD does support the concept of "Device Hints", where devices/drivers provision a list of known folders that would accept particular content types. Unfortunately, this was not uniformly adopted by devices/drivers, and was limited to known WPD content types].

Crowded MTP 1.0 Extension Space

Last but not the least, MTP 1.0 had inherent limitations for growth and new functionality. The operation codes and property codes were constrained by a DWORD (4 byte) numerical space, with only a small subset allocated for extension codes. Without a notion of vendor-specific namespaces, new extensions must be careful not to collide with existing extensions. This would usually add the overhead of having to publish the codes or risk incompatibilities with applications that rely on existing extensions. And, if the device/application needs to support new types of content, adding a new object format involves updating the MTP Specification, which is not easily revised.

How do Device Services help?

To solve the problems and overcome the limitations described above, we introduced the concept of Device Services to MTP. In a nutshell, "MTP Device Services" is an MTP Extension that defines a set of MTP operations revolving around a new type of object known as a "service."

A service is composed of 3 parts:

The core definition of that service and what it does, including its globally unique identifier (GUID).
The properties of the service itself, and
The properties and capabilities of objects and methods of that service.

Properties are represented by PROPERTYKEYS, and formats are represented by GUIDs, which eliminate the operation and format number space restrictions. Together, these provide the structure that applications would rely on to programmatically discover and use services in a consistent way.

The following describes the most common ways in which Device Services are used today:

Provide a set of properties and events associated with a common scenario. One example is the Status Service, which defines properties for the battery level, the number of missed calls, the number of new voicemail messages, and the number of new pictures acquired by a device. These may be custom properties, and any application that discovers this service can programmatically discover these properties.
Provide a known source and/or sink for content. The Contacts, Calendar, Task, and Notes services are all services that allow applications to access and store PIM data. These are analogous to "virtual storages." The device represents the content in a standard location (as child objects of these services) so that applications do not have to grovel through the device hierarchy to find them. At the same time, this abstraction allows a device implementation greater control over how objects are actually stored on the device. Services are not limited to the known MTP or WPD formats, and may support any arbitrary type of data. For example, devices that wish to provide a Device Stage™ experience upon install can implement a Device Metadata Service that stores *.devicemetadata-ms files.
Provide a set of functionality associated with a common scenario. The Full Enumeration and Anchor Synchronization services support "methods." Methods are like extensions to WPD commands, with the added benefits of being easily discoverable and supporting both synchronous and asynchronous invocation. The Anchor Synchronization Service features a method that allows a synchronization application to retrieve the set of changes to content on the device from a given anchor value (which can be a timestamp or a tick count). Methods also provide a flexible way to access content residing on multiple services. For instance, the Ringtones Service contains a method that allows an application to associate a ringtone (an object within the Ringtones Service) with a contact (an object within the Contacts Service).

How are Device Services used in Windows 7?

After creating Device Services, we put it through its paces in real-life scenarios that are part of Windows 7.

Device Stage™- Uses the Status service to display status on the Branding bar, and on the Taskbar and preview pane.

Windows 7 Synchronization – The Portable Devices Sync Provider uses the Contact Service, Calendar Service, Task Service, and Notes Service to access PIM data on the device. In addition, the Enumeration Synchronization Service and Anchor Synchronization Service are used to determine the level of synchronization capabilities that a device supports.

Windows Media Player and Windows Explorer – Both these applications use WPD Device Hints to determine content locations more efficiently. For MTP devices, WPD Device Hints is now implemented at the MTP layer as a Hints Service. Devices that implement the Hints Service get WPD Device Hints for free.

Ringtone Editor – Uses the Ringtones Service to transfer user-created ringtones to the device, and to associate a ringtone with a contact that is located using the Contacts service.

WPD Class Installer – Uses the Device Metadata Service to retrieve and transfer metadata stored on the device, so that the richer, device-manufacturer-customized, Device Stage experience gets presented to the user after the first time the device is connected and installed.

More Information

We hope this post has given you a taste of what Device Services can do. Here are some additional links for further information.

This posting is provided "AS IS" with no warranties and confers no rights.

New Features for Windows 7

wpdblog — Sat, 08 Aug 2009 01:03:00 GMT

In Windows 7 we introduced several new features that improve how users discover and use devices connected to their PC. These new features simplify how device manufacturers present their devices, applications, and services in Windows. This behavior is exposed in the new Device Stage™ experience (see Better Device Management here).

In the Windows Portable Device (WPD) space the Windows team made significant investments to address concerns raised by device manufacturers. One of the key improvements was the addition of the Device Service. A Device Service is an extension of the functional object that was supported in prior versions of WPD. Applications can use Device Services to discover device capabilities and to interact more efficiently with content.

In addition to the Device Service, WPD was further improved by investing in additional transports: support for MTP over Bluetooth has been added. With multiple transports (USB, IP, and Bluetooth) now available, the next step was to enable a seamless data transfer scenario when the device supports more than one transport.

Now that we have introduced some of the key Windows 7 features for WPD, we’ll take a closer look.

MTP Device Services for Windows 7

MTP has proven to be an excellent protocol for exchanging files and performing device command and control. However, it is not well-suited for newer, more advanced scenarios. These scenarios are now supported with the introduction of the Device Services architecture. This architecture allows applications to locate and use various services and content types on a device.

The new Device Services architecture allows applications to locate, consume, and interact with both content and functionality on the device. Our flagship use of Device Services in Windows 7 is to support Personal Information Management (PIM) data, settings, and restricted-capabilities content types on a device. The resulting architecture is also the means for future extensibility by 3rd parties: An IHV can implement an application (or web script) and a custom service that interoperate (without having to wait for new functionality in the next OS release).

Device Services are identified by Globally Unique Identifiers (GUIDS). These GUIDS allow hardware vendors to specify new device services independently of each other without the risk of conflicts.

The native Windows 7 supported services defined for portable devices are:

Calendar Service - The calendar service contains the data for a calendar, and uses a synchronization service to facilitate synchronization with the PC.

Contact Service - The contact service contains the data for contacts, and can optionally use a synchronization service to facilitate synchronization with the PC.

Notes Service - The notes service uses a synchronization service to sync notes to and from the device.

Task Service - The task service uses a synchronization service to synchronize tasks to and from the device.

Status Service - The status service reports various status properties about the device to the PC.

Hints Service - The hints service enables the device to select preferred storage locations for various content types in legacy storages.

Device Metadata Service - The device metadata service permits the delivery of Device Stage™ metadata by the device during device installation.

Ringtone Service - The ringtone service provides a method to copy ringtones from the PC to the target ringtone storage on the device.

Enumeration Synchronization Service - The enumeration synchronization service describes basic synchronization capabilities for a storage-based device. This is an “abstract” Device Service, which, analogous to an interface in C++, describes the capabilities of a “data” service that supports basic synchronization. For example, a device that supports basic synchronization of contacts will contain a Contacts Service that implements the Enumeration Synchronization Service.

Anchor Synchronization Service - The anchor sync service is another abstract MTP Device Service defined to enable other services to opt in to a sync relationship using anchor-based synchronization semantics. Anchor-based synchronization uses a simple tick-count based mechanism for change detection (e.g. timestamp, tick counts).

Sample implementations of some of these services along with device simulation software is provided in the 7R2 version of the Windows 7 Portable Device Enabling Kit and is now available here.

MTP Device Services Extension

In addition to the pre-defined device services mentioned above, Windows is also capable of supported custom device services that use the newly defined MTP Device Services Extension to MTP. The MTP Device Services Extension enables Windows to locate and use various services and content types located on a device.

In the recent applications of MTP without device services, content is distributed throughout a device, which makes it difficult for the operating system to determine where the useful assets are and how to deploy them. With the creation of the Device Services extension to the MTP protocol, Windows now has the ability to locate, consume, and interact with this content in practical ways based on Microsoft and manufacturer defined services. This feature is particularly useful in accessing device content that is not based on file system data, accessing settings, or that has restricted capabilities. For example, a device manufacturer could define a custom SMS service.

While MTP already supports enumeration by format, it is cumbersome when applying rich semantics to simple hierarchical storage. With Device Services, content and functionality can be combined under a single functional object, resulting in well-scoped access to only the content and functions specific to that service.

Windows Portable Devices (WPD) Platform Enhancements

For Windows 7, in addition to the legacy behavior, Windows Portable Devices (WPD) supports a new Device Services model. A Device Service is an extension of the functional object supported in prior versions of WPD. Applications will use service objects to discover device capabilities and to interact more efficiently with content.

Device Services are available to applications as part of the WPD API. Some Device Services include built-in support by Windows 7. Two examples of operating-system components that use Device Services are the Windows Portable Devices Sync Provider and the Windows Portable Device Status Provider.

The Windows Portable Devices Sync Provider determines whether a cellular phone supports basic contacts synchronization by querying for its implementation of the Enumeration Sync device service on the device. The provider then uses this service to locate all contacts stored on the device without having to search the entire storage hierarchy.

The Windows Portable Device Status Provider retrieves real-time status information from a cellular phone that supports the Status device service, and relays information including battery life, signal strength, unread text messages, and number of missed calls to Device Stage™.

Note that although cellular phones are featured in both sceanrios above, Device Services are not limited to a specific WPD device class. Further examples of Device Services will be covered in a later post.

Device Stage™

Device Stage provides additional customization of the user’s device experience by providing a new way for users to interact with their cell phones, cameras, printers, and portable media players. Device Stage provides a visual interface that makes it easy for users to find and use applications and services for a given device.

Through a new set of XML schemas supported in Windows 7, device makers can:

Provide rich branding and customization for their device
Define applications and services that are specific to each device

Device Stage can be accessed by double clicking a supported device from within the Devices and Printers folder, or for portable devices, by clicking the device icon which appears on the taskbar when the device is connected.

The Device Stage user interface follows the model of any shell view in Windows, and Device Stage devices appear on the Windows taskbar whenever the Device Stage is open.

Device makers may enable additional features by supporting standard and vendor-unique Device Services, and authoring Device Stage tasks that make use of the service. When a device is connected which supports the any of the authored tasks, the tasks will appear within the Device Stage experience. Optionally, additional Partner applications and hosted web tasks may be specified within the Device Stage XML without modifications to device firmware. These custom device experiences (via Hosted Site with Device option) within Device Stage are made possible by enhancements to the WPD API (mentioned above) and driver model which may now be extended via scripting and custom MTP Device Service extensions on the device. To assist device makers in all of this work, Microsoft has released a Portable Device Enabling Kit with documentation and device code samples. The 7R2 version of the kit is now available here.

In the Windows 7 Control Panel, there is a new experience known as the Devices and Printers folder through which users can see all the devices that are connected to their PC. The devices in this folder are physically connected via USB or paired via Wi-Fi or Bluetooth interfaces. (As a general rule, internal PC devices or device functions will not be exposed in this folder.)

Using a new set of XML schemas, device makers can customize how their device is described and presented within the Devices and Printers folder. For more information on developing metadata packages for both the Devices and Printers folder and Device Stage in Windows 7, see the Windows Device Experience topic on WHDC.

Extended Transport Support

In Windows 7 we have expanded support with WPD over other transports. A new class driverhas been introduced to enable MTP over Bluetooth. With the support in Windows 7 for multiple transports the next step was to make Windows multi-transport aware, and the addition of the WPD composite driver provides the bridge between a logical device and the transports it simultaneously supports. The new features and functionality mentioned above are supported across all three of the MTP transports (Bluetooth, IP, and USB).

Resources:

Information on MTP can be found at http://www.usb.org/developers/devclass_docs/MTP_1.0.zip

Details on MTP over Bluetooth and MTP over IP are provided in the documentation that ship in the Windows 7 Portable Device Enabling Kit for MTP and on MSDN. The kit can be downloaded from http://www.microsoft.com/whdc/device/wpd/MTP-DEK_Win7.mspx.

Information on the WPD APIs can also be found on MSDN.

That’s it for now. Stay tuned for more posts diving into the details of the new Windows 7 WPD features.

This posting is provided "AS IS" with no warranties, and confers no rights.

Cancellation Behavior of MTP USB Devices

wpdblog — Sun, 15 Apr 2007 19:01:00 GMT

The MTP Specification contains this definition of the CancelTransaction Event:

G.2.2 CancelTransaction
Event Code: 0x4001
Parameter 1: None
Parameter 2: None
Parameter 3: None

This event is used to initiate the cancellation of a transaction over transports which do not have their own mechanism for canceling transactions. The details of how a transaction is cancelled may be transport-specific. When an initiator or responder receives this event, it should cancel the transaction identified by the TransactionID in the event dataset. If the transaction has already completed, this event should be ignored.

After receiving a CancelTransaction event from the initiator during an object transfer, the responder should send an Transaction_Cancelled response for the transfer which was in progress.

MTP USB Transport Cancellation Behavior

Why then does an MTP/USB device send a Status_OK (0x2001) instead of Transaction_Cancelled (0x201F) response when it receives a CancelTransaction (0x4001) from the application?

The reason is that the MTP USB transport has defined how cancellation is to be implemented. As pointed out in the MTP Specification above, CancelTransaction is intended for "transports which do not have their own mechanism for canceling transactions", and will not apply to MTP/USB devices.

Here are the MTP/USB specifications for each cancellation scenario. In the cases below, "Host" can be a PC running Windows Media Player 11, and "Device" can be a MTP music player or a PTP camera that connects to the PC through USB.

Case A. When the Host Cancels
When the device receives a cancellation request from the host, it should return Device_Busy (0x2019) for a GetDeviceStatus query. The device should then perform cancellation and clean up, and return Status_OK (0x2001) for subsequent GetDeviceStatus requests. The device should NOT send a response for the cancelled transaction through the BULK-IN pipe.

After the host receives a Status_OK response from a GetDeviceStatus query on the device, it may issue the next transaction through the BULK-OUT pipe.

Case B. When the Device Cancels
If the device wants to cancel, it should STALL both BULK-IN and BULK-OUT endpoints. When the device receives a GetDeviceStatus request from host, the device should return Transaction_Cancelled (0x201F) as the reason for the STALL, and the STALL-ed endpoint numbers.

The host may then issue the ClearFeature request to clear the STALL-ed endpoints. The device should clear, get ready for next command, and return Status_OK for next GetDeviceStatus query.

Case C. When the Host and Device Both Cancel
When the device receives a cancel request from the host while it is trying to cancel, it should clear any pending device-initiated cancellations, respond to the host with Device_Busy (0x2019) for subsequent GetDeviceStatus requests, and proceed with normal host-initiated cancellation.

When the device wants to cancel (this could be initiated by the user), it first checks if there are any pending host-initiated cancellation. If yes, the device can simply return. If not, the device should STALL the BULK endpoints.

Cancellation Examples

For cancellation examples, refer to the Picture Transfer Protocol (PTP) Specification - ISO 15740 Annex D: Sections D.7.2.1.2 (for device behavior) and D.9, available on the I3A PTP website.

In addition, the PTP USB Transport specification also contains a definition for the GetDeviceStatus and further descriptions of the BULK cancellation behavior.

This posting is provided "AS IS" with no warranties, and confers no rights.

Getting ERROR_BUSY (0x800700AA) after reading data from an MTP device?

wpdblog — Fri, 09 Mar 2007 22:40:00 GMT

One common cause of the ERROR_BUSY (0x800700AA) in MTP devices is when the application reads resource data from a content object on the portable device using IStream::Read(), and does not complete the read with an IStream::Close(). Subsequent operations that eventually translate into MTP commands into the device could fail with ERROR_BUSY because the resource read operation is not yet complete. Sometimes the failure could appear delayed - after the resource read, there could be several successful WPD API calls before ERROR_BUSY appears, because the interim calls that succeeded were handled by the MTP driver (i.e. do not require the driver to talk to the device).

From the device's perspective, reading resource data translates to a sequence of operations involving the MTP command "GetObject". This has to be completed or cancelled before further MTP commands to the device could proceed.

For example, if your application does the following:


IStream* pObjectDataStream = NULL;

// 1. Open the default resource of an object with read access
HRESULT hr = pIPortableDeviceResources->GetStream(wszObjectID, 
                                                     WPD_RESOURCE_DEFAULT, 
                                                     STGM_READ, 
                                                     &cbOptimalTransferSize,
                                                     &pObjectDataStream);

// 2. Read some data from the resource stream created by GetStream
if (hr == S_OK)
{
  hr = pObjectDataStream->Read(pObjectData, cbOptimalTransferSize, &cbBytesRead);
}

// 3. Do other operations that translate into MTP commands to the device
// and they could result in 0x800700AA as the resource read operation is not complete

To fix this, ensure that IStream::Release() is called to complete or cancel the current read operation before proceeding


IStream* pObjectDataStream = NULL;

// 1. Open the default resource of an object with read access
HRESULT hr = pIPortableDeviceResources->GetStream(wszObjectID, 
                                                     WPD_RESOURCE_DEFAULT, 
                                                     STGM_READ, 
                                                     &cbOptimalTransferSize,
                                                     &pObjectDataStream);

// 2. Read some data from the resource stream created by GetStream
if (hr == S_OK)
{
  hr = pObjectDataStream->Read(pObjectData, cbOptimalTransferSize, &cbBytesRead);
}

// 3. IMPORTANT: Release the IStream if no longer using it to ensure that the read operation
// completes.   
if(pObjectDataStream)
{
    pObjectDataStream->Release();  // If using a CComPtr, set it to NULL
}

// 4. Proceed on to the other operations

If your application is reading resource data from an MTP device, and you are seeing ERROR_BUSY, check that you are always calling Release() on the IStream objects that you have opened. This also applies if you are using smart pointers (e.g. CComPtr<IStream>), in which case you can explicitly set the pointer to NULL to tell the smart pointer to Release() itself before you proceed on to other device operations. This will release the pointer after you have completed your resource read/write operation(s), instead of relying on the IStream smart pointer to get out of scope.

Similarly, if your application is writing resource data to an MTP device, ensure that you're calling IStream::Commit() or IStream::Revert() to complete the write operation.

[June 11, 2007] Thanks to drlily for pointing out that IStream::Close does not actually exist. It should have been IStream::Release for a read IStream, and IStream::Commit, IStream::Revert, or IStream::Release for a write IStream.

This posting is provided "AS IS" with no warranties, and confers no rights.

WIA Camera Support in Windows Vista (Part 2 of 2)

wpdblog — Tue, 13 Feb 2007 21:33:00 GMT

In the previous post, we gave an overview of the WIA-WPD Compatibility Layer and how WIA Applications can register for WIA_EVENT_DEVICE_CONNECTED events.

In this post, we will cover a more advanced topic: customization for PTP and MTP devices. The WIA-WPD Compatibility Layer supports basic extensibility for custom WIA events and WIA properties. These events and properties were provided in the PTP WIA class driver that shipped with Windows XP.

Adding Custom PTP/MTP WIA Event Codes

To specify a list of supported PTP/MTP event codes the 'WiaEventCodes' entry should be provided.

The following example shows 3 custom event codes being reported.

HKR,,"WiaEventCodes",”0x0001,0x0002,0x0003”

For each event code specified in the 'WiaEventCodes' entry, a corresponding 'WiaEventCodeXXX' entry must exist that specifies the name of the event and the GUID to use when reporting the event to WIA applications. The entry should be constructed using the prefix ‘WiaEventCode + the event code specified in WiaEventCodes entry’. If the WiaEventCodeXXX entry is missing, the event will not be reported to WIA applications.

HKR,,"WiaEventCode0x0001”,”{20179E3D-139C-40D3-A0CA-962B33D67EE3},My Custom Event”
HKR,,"WiaEventCode0x0002”,”{259A62CF-D8FE-44D0-A747-B14F54A02133},My Amazing Event”
HKR,,"WiaEventCode0x0003”,”{639F80C6-94D1-48E2-9D8E-6D0F12237E48},My Super Event”

Adding Custom PTP/WIA Property Codes

To specify a list of supported PTP/MTP property codes the ‘WiaPropertyCodes’ entry should be provided. WIA properties will only appear on the root item. These properties are commonly used to control/program the device.

The following example shows 3 custom property codes being reported.

HKR,,"WiaPropertyCodes",”0x0001,0x0002,0x0003”

For each property code specified in the ‘WiaPropertyCodes’ entry, a corresponding ‘WiaPropertyCodeXXX’ entry must exist that specifies the name of the property and the WIA property code to use when reporting the property to WIA applications. The entry should be constructed using the prefix ‘WiaPropertyCode + the property code specified in WiaPropertyCodes entry’. If the WiaPropertyCodeXXX entry is missing, the event will not be reported to WIA applications.

HKR,,"WiaPropertyCode0x0001”,”My Custom Device Property”
HKR,,"WiaPropertyCode0x0002”,”My Amazing Device Property”
HKR,,"WiaPropertyCode0x0003”,”My Super Device Property”

Sending PTP Custom Commands through WIA

PTP extension commands can be sent to the vendor's driver using IWiaItemExtras::Escape. In Windows Vista, the WIA-WPD Compatibility Layer repackages PTP extension commands sent using this method into WPD MTP/PTP extension commands, which are dispatched to the WPD MTP class driver. This mechanism exists to support legacy WIA vendor applications that relied on custom PTP commands from Windows XP.

Sending MTP Custom Commands through WPD

WPD supports sending of custom MTP commands to the MTP driver using the IPortableDevice::SendCommand API. For a step-by-step description, visit DimeBy8's excellent post here.

WIA to WPD Content Type and Format Mapping

The following table maps WIA Item Types to the WPD_OBJECT_CONTENT_TYPE.

In addition to video and image content, the WIA-WPD Compatiliby Layer supports thumbnails and audio annotations for objects that have them. Any data objects that do not fall under these categories (e.g. music files) will not appear in WIA applications.

WPD Object	WPD Content Type	WIA Item	WIA Item Type
Device object	N/A	Root item	(WiaItemTypeFolder \| WiaItemTypeDevice \| WiaItemTypeRoot)
Folder object	WPD_CONTENT_TYPE_FOLDER	Folder Item	WiaItemTypeFolder
Functional Object	WPD_CONTENT_TYPE_FUNCTIONAL_OBJECT	Folder Item	WiaItemTypeFolder
Image Object	WPD_CONTENT_TYPE_IMAGE	Image Item	(WiaItemTypeImage \| WiaItemTypeFile \| WiaItemTypeTransfer)
Video Object	WPD_CONTENT_TYPE_VIDEO	Video Item	(WiaItemTypeVideo \| WiaItemTypeFile \| WiaItemTypeTransfer)
Audio Object (used for annotations)	WPD_CONTENT_TYPE_AUDIO	Audio Item	(WiaItemTypeAudio \| WiaItemTypeFile \| WiaItemTypeTransfer)
Other objects	WPD_CONTENT_TYPE_XXXX	N/A (These are ignored)	N/A (These are ignored)

The following table maps the WIA_IPA_Format property to the WPD_OBJECT_FORMAT property:

WIA_IPA_FORMAT

The formats will be mapped as follows:

WiaImgFmt_EXIF	WPD_OBJECT_FORMAT_EXIF
WiaImgFmt_JPEG	WPD_OBJECT_FORMAT_JFIF
WiaImgFmt_PNG	WPD_OBJECT_FORMAT_PNG
WiaImgFmt_GIF	WPD_OBJECT_FORMAT_GIF
WiaImgFmt_TIFF	WPD_OBJECT_FORMAT_TIFF
WiaAudFmt_WAV	WPD_OBJECT_FORMAT_WAVE
WiaAudFmt_MP3	WPD_OBJECT_FORMAT_MP3
WiaAudFmt_AIFF	WPD_OBJECT_FORMAT_AIFF
WiaAudFmt_WMA	WPD_OBJECT_FORMAT_WMA
WiaImgFmt_MPG	WPD_OBJECT_FORMAT_MPEG
WiaImgFmt_AVI	WPD_OBJECT_FORMAT_AVI
WiaImgFmt_ASF	WPD_OBJECT_FORMAT_ASF

Configuration of the WIA-WPD Compatibility Layer

The following section lists the customization options in the WIA-WPD Compatibility Layer that can be disabled/enabled by the device's INF [AddReg] section:

Report EXIF Image Format as JPG

Some WIA applications expect the EXIF image format to be reported as WiaImgFmt_JPG and not WiaImgFmt_EXIF. To "opt-in" for this functionality, vendors can add the following to your device's INF:

HKR,,"ReportJPGFormatForEXIF",0x10001,1

WIA Item Tree Behavior for DCF

If the WIA-WPD Compatibility layer encounters a storage that supports DCF, it will ‘shift’ the WIA item tree contents closer to the root item so items are easily found. This will reduce the number of folder levels an application or user will have to navigate to get to the image or video content stored on the device. This functionality can be disabled by adding the following to your device’s .INF [AddReg] section.

HKR,,"DisableDCFSpecialProcessing",0x10001,1

This posting is provided "AS IS" with no warranties, and confers no rights.

WIA Camera Support in Windows Vista (Part 1 of 2)

wpdblog — Tue, 13 Feb 2007 11:23:00 GMT

In this two-part post, we will cover WIA support for cameras on Windows Vista, and the migration from WIA to WPD for richer applications.

WIA-WPD Compatibility Layer

On Windows XP, Picture Transfer Protocol (PTP) cameras are accessible through the WIndows Image Acquisition (WIA) infrastructure. This is still supported on Windows Vista through the WIA-WPD Compatibility Layer (PortableDeviceWiaCompat.dll). This component is a WIA mini-driver that communicates to the inbox Media Transfer Protocol (MTP) class driver using the WPD API.

The following classes of devices have the WIA-WPD Compatibility Layer enabled:

1. PTP Cameras

2. MTP devices that report WPD_DEVICE_TYPE_CAMERA (subcomp = 2) or WPD_DEVICE_TYPE_VIDEO (subcomp = 6)

3. WPD devices that support WPD_CONTENT_TYPE_VIDEO or WPD_CONTENT_TYPE_IMAGE, and with the lowest bit set in the EnableLegacySupport entry under Device Parameters. This can be set in the driver INF:

HKR,,"EnableLegacySupport",0x10001,1

WIA Event Registration for Cameras

On Windows Vista, WIA imaging applications communicate to PTP cameras via the WPD-WIA Compatibility Layer and the Media Transfer Protocol (MTP) class driver. Windows Autoplay is supported, third party applications can register for WIA device-connected events and appear in the autoplay dialog. Note that some third-party WIA applications may require Elevation ("Run as Administrator") at first launch to in order to successfully register for WIA events.

1. Only Global WIA Event Registration for WIA_EVENT_DEVICE_CONNECTED is supported. Any WIA application that registers for this event will be listed in the Windows Autoplay dialog when any WIA-compatible PTP camera is connected.

2. Supported registration mechanisms: STI Proxy registration (IStillImage::RegisterLaunchApplication), WIA CLSID registration (IWiaDevMgr::RegisterEventCallbackCLSID), and WIA Program registration (IWiaDevMgr::RegisterEventCallbackProgram).

Custom Vendor Events

To enable Device-Specific WIA Event Registration for custom vendor events, there is an "opt-in" mechanism. There are 2 steps to this:

Step 1: The vendor camera driver INF will need to add the UseWiaAutoPlay setting in the Device Parameters section in the registry. This is a DWORD setting. If set to 1, the WPD-WIA Compatiliby Layer will mark "device connected" and custom vendor events as "action events." If unset, the default value is 0 (WIA autoplay is disabled).

HKR,,"UseWiaAutoPlay",0x10001,1

Step 2: The vendor's application calls the IWiaDevMgr APIs to create a Device-specific WIA event registration for their custom WIA event.

The overall effect of enabling device-specific registration is the WIA Autoplay dialog will appear for the custom event. This XP-style dialog is implemented by the WIA Service. It is recommended that applications only register via Windows Autoplay or WIA Autoplay, but not both. Windows Autoplay registration is preferred.

Image and Video Acquisition

On Windows Vista, the camera image import functionality of the Scanner and Camera Wizard is replaced by the Photo Acquisition Wizard and the Windows Photo Gallery. This is also known as the "Importing Pictures and Videos" dialog.

The Photo Acquisition wizard communciates to PTP cameras using WPD APIs (more specifically, it uses the WPD Namespace Extension). It does not use the WIA APIs.

Video Content Support

Video content support is removed from WIA for Windows Vista. The effect is video content on your device will not appear in WIA applications running on Windows Vista.

To access video content from your device, we recommend migrating your applciation to use the WPD API. WPD provides broader content coverage (supports both video and image content) on Windows Vista for camera devices. For instance, the Vista Photo Acquisition Wizard uses WPD to retrieve pictures and video from PTP devices.

For ease of migration, there is usually a straighforward correlation from WIA metadata to WPD object properties. For example, WiaImgFmt_AVI corresponds to WPD_CONTENT_TYPE_VIDEO and WPD_OBJECT_FORMAT_AVI. For more details, refer to the WPD video properties and video format GUIDs on MSDN.

Next Post...

Watch the next post for more details on custom PTP vendor commands through the WIA Escape mechanism, custom WIA property and event codes.

This posting is provided "AS IS" with no warranties, and confers no rights.

Which Portable Devices?

wpdblog — Sat, 27 Jan 2007 11:46:00 GMT

What devices does WPD support?

A WPD application (e.g. the WPD API Sample) on Windows XP (with the pre-requisites installed) can connect to these devices:

Devices (e.g. portable media players, cameras, some phones) that support Media Transfer Protocol (MTP).
Devices that connect using third party or vendor provided WPD drivers.

A WPD application on Windows Vista can connect to even more devices:

Devices (e.g. portable media players, cameras, some phones) that support MTP.
Devices that connect using third party or vendor provided WPD drivers.
Devices (e.g. cameras, camcorders) that support Picture Transfer Protocol.
USB Mass Storage Devices.
Windows CE devices via IPortableDeviceManager::GetPrivateDevices()

In both cases, the WPD Shell Namespace Extension is also a WPD application, so you can check whether your device is visible to WPD by browsing to it using Explorer ("My Computer").

What about a Smartphone or PocketPC device?

On Windows Vista, Windows CE devices register the private WPD interface GUID, and can be enumerated in WPD by calling IPortableDeviceManager::GetPrivateDevices(). These devices connect to Explorer using the WPD RAPI driver, which provides device browsing functionality. Content sync is implemented through a different channel. The WPD RAPI driver is not available on Windows XP.

On Windows Vista and Windows XP, to enumerate content on a Windows CE device for Windows Media Player applications, you can use the Windows Media Device Manager (WMDM) APIs.

How do I install WPD?

On Windows XP, WPD is available when any one of these pre-requistes are installed:

Windows Media Player 11
The redistributable package bundled with Windows Media Format 11 SDK (see release notes)

On Windows Vista, WPD is supported natively for SKUs that include Windows Media Player (e.g. Home Basic, Home Premium, Ultimate Edition ...)

This posting is provided "AS IS" with no warranties, and confers no rights.

Windows Portable Devices Team Blog : MTP

Windows 7 Device Implementation Guidelines for Picture and Video Import

Topics Covered

More Resources

WPD Platform Update for Windows Vista

Features

Availability and installation

Additional notes about the Platform Update for Windows Vista

More information

The MTP Device Simulator

Where to get the MTP Simulator

Installing the MTP Simulator

User Interface

Table 1. MTP Simulator User Controls

Command-Line Options

Customizing the MTP Simulator

Device Profiles

Table 2: Sample MTP Simulator Device Profiles

Testing Device Stage Packages

Want to Learn More?

Windows 7 Portable Device Development Kits

Windows 7 Portable Device Enabling Kit for MTP

Windows Portable Devices SDK

Windows Portable Devices Driver Kit

Windows Media Device Manager SDK

Microsoft Device Experience Development Kit

Windows Logo Kit

Other Resources

MTP Over Various Transports

Introduction

3 transports, one protocol

USB

IP

Bluetooth

Operating System Support

MTP Driver Support by Operating System

Introducing Device Services

What are Device Services?

Why do we need Device Services?

How do Device Services help?

How are Device Services used in Windows 7?

More Information

Device Services:

Application Development:

Driver Development:

New Features for Windows 7

Cancellation Behavior of MTP USB Devices

Getting ERROR_BUSY (0x800700AA) after reading data from an MTP device?

WIA Camera Support in Windows Vista (Part 2 of 2)

WIA Camera Support in Windows Vista (Part 1 of 2)

Which Portable Devices?