WPD and WMDM Side-by-side: An Application Development Perspective
This post will compare WPD and the latest version of Windows Media Device Manager (WMDM), from an application developer's point of view.
Availability (aka SDK and Runtime Requirements)
The Windows SDK contains the complete build environment (headers, libs, sample code ...) for developing a WPD application for both 32 and 64-bit.
The Windows Media Format 11 SDK (WMFSDK11) provides headers and libs for WMDM 11. Since WMFSDK11 is released in 32-bit, only 32-bit WMDM applications can be built. On 64-bit Windows, a 32-bit WMDM application will run in SysWOW mode.
WMDM 11 | WPD | |
Operating Systems | Windows XP + Windows Media Format 11 Redistributable, Windows Vista | Windows XP + Windows Media Format 11 Redistributable, Windows Vista |
Processors | X86, AMD64 (SysWOW mode only) | X86, AMD64 |
SDKs | Windows Media Format SDK 11 | Windows SDK |
Common Device-level Operations
Both WPD and WMDM support basic device-level operations: enumeration of connected devices, managing device-level properties, and querying of static device capabilities.
WMDM's IWMDMDeviceControl operations internally delegate to the service provider (through IMDSPDeviceControl), and would require the service provider to support these operations. While device playback control is not natively supported by the WPD API, WPD's extensibility mechanism makes it easy to add this as a custom command to your driver. For example, your WPD driver can support a custom Playback command that your application can invoke using IPortableDevice::SendCommand.
Operation | Example WMDM API | Suggested WPD API |
Enumerate attached devices | IWMDeviceManager2::EnumDevices2 | IPortableDeviceManager::GetDevices |
Enumerating device content | IWMDMDevice::EnumStorage | IPortableDeviceContent::EnumObjects |
Examine device capabilities | IWMDMDevice::GetFormatSupport, IWMDMDevice2::GetFormatCapability | IPortableDeviceCapabilities:: GetSupportedContentTypes, GetSupportFormats |
Retrieve device properties |
IWMDMDevice::GetManufacturer | IPortableDeviceManager:: GetDeviceManufacturer OR IPortableDeviceProperties::GetValues(WPD_DEVICE_OBJECT_ID) |
Write device properties | IWMDMDevice3::SetProperty | IPortableDeviceProperties::SetValues(WPD_DEVICE_OBJECT_ID) |
Controlling device playback | IWMDMDeviceControl::Play | - |
Common Object-level Operations
A WPD object is analogous to a WMDM storage, and most WMDM storage operations have their equivalent WPD API. WPD is ObjectID-based, so each interface method that supports object-level operations receives an Object Identifier as a parameter. WMDM is interface-based, IWMDMStorage represents a storage or a file, and IWMDMStorageControl implements the operations on a storage or a file.
For data object creation, both WPD and WMDM support transfer of protected Windows Media Digital Rights Management (WMDRM) content.
Operation | Example WMDM API | Suggested WPD API |
Enumerating objects | IWMDMDevice::EnumStorage, IWMDMEnumStorage::Next | IPortableDeviceContent::EnumObjects, IEnumPortableDeviceObjectIDs::Next |
Create a folder object | IWMDMStorageControl::Insert3 | IPortableDeviceContent:: CreateObjectWithPropertiesOnly |
Create a data object | IWMDMStorageControl::Insert3 | IPortableDeviceContent:: CreateObjectWithPropertiesAndData |
Transfer object data from device | IWMDMStorageControl::Read | IPortableDeviceResources::GetStream |
Move objects | IWMDMStorageControl::Move | IPortableDeviceContent::Move |
Copy objects | - | IPortableDeviceContent::Copy |
Delete objects | IWMDMStorageControl::Delete | IPortableDeviceContent::Delete |
Retrieve object properties | IWMDMStorage4::GetSpecifiedMetadata | IPortableDeviceProperties::GetValues |
Write object properties | IWMDMStorage3::SetMetadata | IPortableDeviceProperties::SetValues |
Delete object properties | - | IPortableDeviceProperties::Delete |
Device Events
There are only 4 events that WMDM applications can receive: media arrival/removal, and device arrival/removal. WPD supports device-level and the more granular object-level events, plus built-in extensibility for custom events.
Operation | Example WMDM API | Suggested WPD API |
Monitor object-level property changes | - | IPortableDeviceEventCallback::OnEvent (WPD_EVENT_OBJECT_UPDATED) |
Monitor object-level arrival and removal | - | IPortableDeviceEventCallback::OnEvent (WPD_EVENT_OBJECT_ADDED, WPD_EVENT_OBJECT_REMOVED) |
Monitor media arrival and removal | IWMDMNotification::WMDMMessage (WMDM_MSG_MEDIA_ARRIVAL, WMDM_MSG_MEDIA_REMOVAL) | IPortableDeviceEventCallback::OnEvent (WPD_EVENT_OBJECT_ADDED, WPD_EVENT_OBJECT_REMOVED) |
Monitor device removal | IWMDMNotification::WMDMMessage (WMDM_MSG_DEVICE_REMOVAL) | IPortableDeviceEventCallback::OnEvent (WPD_EVENT_DEVICE_REMOVED) |
Monitor device arrival |
IWMDMNotification::WMDMMessage (WMDM_MSG_DEVICE_ARRIVAL) | Subscribe to WPD interface arrival PnP event |
Advanced Operations
Both WPD and WMDM provide some extensibility mechanism for sending device-specific commands. IWMDMDevice3::DeviceIoControl is used for packaging and sending commands only to Media Transfer Protocol (MTP) portable media players.
WPD API methods that map to Command GUIDs internally delegate to IPortableDevice::SendCommand. Applications can invoke these commands with additional options or parameters, such as the use of Read or Write IOCTLs for access control.
In addition, for better performance, WPD supports batching of property writes and retrievals across multiple objects, either per format or using a list of Object Identifiers.
Operation | Example WMDM API | Suggested WPD API |
Retrieve properties of multiple objects | - | IPortableDevicePropertiesBulk:: QueueGetValuesByObjectList, OR QueueGetValuesByObjectFormat |
Set properties of multiple objects | - | IPortableDevicePropertiesBulk:: QueueSetValuesByObjectList |
Send device-specific commands | IWMDMDevice::SendOpaqueCommand OR IWMDMDevice3::DeviceIoControl | IPortableDevice::SendCommand |
Cancel an operation | - | IPortableDevice*::Cancel, e.g. IPortableDeviceProperties::Cancel |
Stability
WMDM loads registered service providers (SPs) within the same process as the application. Any crash or instability in the device driver or SP could cause undue crashes in the application process, or worse, trigger bluescreens if kernel mode drivers are involved.
WPD drivers are sandboxed in the User Mode Driver Framework (UMDF) host process, and gain the stability and security benefits of a UMDF driver. If a WPD driver crashes, only the sandbox process will be affected; the WPD application process is isolated from the driver instability. In a similar way, a WPD driver's process is not affected when a WPD client application crashes.
The Verdict
WPD and WMDM have a lot of overlap in terms of the device operations that each enables. WMDM is geared specifically towards portable media player applications and scenarios, with media-centric metadata schema, support for device playback control, and direct access to Windows Media Digital Rights Management (WMDRM) application interfaces. WPD supports much of what WMDM does (including WMDRM transfers), plus many key advantages over WMDM, including stability, UMDF integration, comprehensive property and content type schema (beyond portable media devices), extensibility for custom device solutions, broader device support, and not to mention, great development tools.
For applications that would like to connect to, control, and manage content across a wide range of devices (digital still cameras, portable media players, cellular phones, third-party device classes, and more), WPD is the clear choice.
This posting is provided "AS IS" with no warranties and confers no rights.
- Anonymous
June 01, 2009
PingBack from http://portablegreenhousesite.info/story.php?id=14422