共用方式為


Windows 媒體裝置管理員架構

Windows Media 裝置管理員可讓應用程式或外掛程式與裝置通訊。 應用程式可以要求裝置中繼資料、列舉和探索連接的裝置,以及傳送或接收 (資料夾、檔案、播放清單等) 的物件。 Windows Media 裝置管理員為呼叫應用程式提供單一 API,不論呼叫的裝置類型為何, (MTP 或大量儲存體類別,建置在 10 版或以舊版 Windows Media 裝置管理員) 為基礎的服務提供者。

Windows Media 裝置管理員做為系統三個主要元件的間取用專案:應用程式會針對資訊提出要求 (、讀取或寫入資料) 等等;安全的內容提供者,這是處理與 DRM 保護檔案通訊的元件;以及服務提供者,它會接收來自應用程式的要求,並與裝置通訊來執行這些要求。 應用程式和服務提供者都是建置在 Windows 媒體裝置管理員 SDK 上。

下圖顯示傳統型應用程式如何使用 Windows Media 裝置管理員 11 與裝置通訊。

此圖顯示與四種不同裝置類型通訊的應用程式。

上圖顯示與四種不同裝置類型通訊的應用程式,每個裝置都有自己的服務提供者。 每個服務提供者都是設計來與特定類型的裝置通訊;此圖顯示三個 Microsoft 提供的服務提供者 (大量儲存類別裝置、RAPI 裝置和 MTP 裝置的泛型類別驅動程式) ,以及協力廠商所建置專屬裝置的自訂服務提供者。 當裝置連線時,Windows Media 裝置管理員具現化已註冊該裝置之服務提供者的實例。 服務提供者會透過其實作的 Windows Media 裝置管理員介面,從應用程式取得要求、使用適當的驅動程式與裝置通訊,並傳回適當的結果。 服務提供者與裝置之間的通訊不在 Windows 媒體裝置管理員網域之外。

應用程式看不到服務提供者;應用程式只會看到「裝置」清單,因為 Windows Media 裝置管理員公開所有裝置的標準方法和介面集。 如果製造商建立自訂服務提供者,如果應用程式能夠使用裝置,則必須處理所有標準 Windows Media 裝置管理員方法。

此圖也會顯示 SCP) 模組 (安全的內容提供者。 此課程模組負責處理 DRM) 受保護內容 (數位版權管理。 Microsoft 提供 SCP 模組,可處理受 DRM 保護的 WMA 和 WMV 檔案。 如果應用程式或裝置想要處理其他受保護的格式,則必須提供自己的 SCP 模組。 應用程式或服務提供者都不會直接處理 SCP。

應用程式和服務提供者都是建置在 Windows Media 裝置管理員上,它會路由應用程式與裝置的適當服務提供者之間的呼叫;服務提供者負責直接與裝置通訊。 Windows Media 裝置管理員會執行某些動作 (,例如列舉連線的裝置、路由呼叫和處理元件驗證) ;不過,大部分的工作都是由服務提供者完成,而服務提供者會接收來自應用程式的要求,並與裝置通訊。

以 Windows Media 裝置管理員為基礎的應用程式可以與舊版 Windows 媒體裝置管理員上建置的裝置和服務提供者通訊;不過,這些較舊的裝置將會透過 9 系列元件執行, (未顯示) ,且不支援最新的功能,特別是更進階的數位版權管理技術。

裝置的架構

下圖顯示簡化的裝置和儲存體階層,如使用 Windows Media 裝置管理員的應用程式所見。

顯示裝置上儲存體的圖表。

上圖顯示已連線快閃磁片磁碟機的簡化版本,如 Windows 媒體裝置管理員應用程式所見。 快閃磁片磁碟機具有屬性和屬性,例如序號和支援的格式設定。 Flash 裝置的立即子系是根儲存物件,其中包含資料夾,其本身包含影像和歌曲。

應用程式會呼叫根 IWMDeviceManager 介面公開的列舉方法,以列舉已連結裝置的清單。 裝置是由 IWMDMDevice (或衍生) 介面來表示。 此介面會公開方法來擷取裝置名稱、格式功能、序號等等,以及列舉裝置上 儲存體 的方法。 在 Windows Media 裝置管理員中,儲存體是裝置上任何類型的物件,不論它是否為實際的資料 Blob。 例如:音訊檔案、文字檔、資料夾、儲存為檔案的播放清單,以及儲存為中繼資料的播放清單全都被視為儲存體,即使資料夾和中繼資料專案可能不代表實體檔案。 您可以呼叫 GetAttributes (或 GetMetadata來擷取儲存體的類型 (或格式) ,要求儲存體) 的格式。

裝置上的儲存體會以階層方式儲存,而所有裝置都有根儲存體。 每個儲存體都可以保存零個或多個子物件,方法是呼叫該儲存體的 IWMDMStorage::EnumStorage 方法來列舉。

請注意,圖表中的每個儲存體都有與其相關聯的屬性和中繼資料, (不會顯示所有值) 。 屬性很簡單,布林值資訊通常會描述管理或導覽資訊 (,例如「具有資料夾」或「可以刪除」) ,而中繼資料可以是字串值、數位或複雜資訊 (,例如轉譯功能) 。 屬性是由 SDK 所定義的旗標集所描述,並藉由呼叫IWMDMStorage::GetAttributes 或 IWMDMStorage2::GetAttributes2 來擷取。 中繼資料值是以唯一名稱擷取;SDK 會定義裝置應該支援的一些中繼資料值,但裝置可以定義自己的 中繼資料常數。 不過,如果裝置或服務提供者定義新的中繼資料常數,除非應用程式開發人員知道這個新的常數,否則應用程式將無法要求或設定此值。 服務提供者必須支援 IWMDMStorage3 或更新版本,才能支援擷取或設定中繼資料。 如需詳細資訊,請參閱 取得和設定中繼資料和屬性

服務提供者

服務提供者會作為應用程式與裝置之間的中間人。 應用程式開發人員看不到服務提供者,因此應用程式開發人員不需要知道開發服務提供者的任何專案。 不過,這是執行與裝置通訊工作的服務提供者。

服務提供者是建置在 Windows Media 裝置管理員上的 COM DLL,可接收來自應用程式的要求,並與裝置通訊以執行這些要求。 與桌面應用程式的通訊是由 Windows Media 裝置管理員所媒體處理;與裝置的通訊受到服務提供者的控制。

服務提供者會接收來自應用程式的要求來列舉裝置內容、裝置功能的要求、讀取或寫入資料的要求等等。 它必須知道裝置的設計夠好,才能以適當的格式和通訊協定傳送命令。 它也應該能夠隱藏裝置特定的需求,例如播放清單所需的副檔名,讓應用程式不需要知道這些需求才能使用裝置。

Microsoft 提供許多標準裝置類型的服務提供者,包括一般 MTP 裝置、大量儲存類別裝置和 RAPI 裝置。 裝置設計工具應該建立自訂服務提供者的唯一原因是,如果裝置有一些標準服務提供者未處理的特定或不尋常的資料儲存需求,例如,如果檔案必須儲存在特定位置,且裝置作業系統不會自動處理此情況。

當裝置連線到電腦時,作業系統會為每個 Windows Media 裝置管理員 應用程式建立一個適當的服務提供者實例。 如果第二個 Windows Media 裝置管理員應用程式啟動時,將會載入服務提供者的第二個實例。 不過,每個服務提供者都可以處理多個裝置。 下圖顯示這個關係。

顯示兩個 mtp 裝置與兩個應用程式通訊的圖表。

上圖顯示兩個不同的應用程式與兩個 MTP 裝置通訊。 裝置使用相同的服務提供者類別,但每個應用程式都有自己的相同服務提供者實例。 每個服務提供者實例都會與裝置通訊。 服務提供者的不同實例不會彼此察覺。

許多應用程式方法都有對應的具名服務提供者方法。 當應用程式呼叫方法時,Windows Media 裝置管理員將呼叫路由傳送至服務提供者上的對應方法, (不過它可能會先執行一些額外的內部動作) 。 例如,當應用程式呼叫IWMDMDevice3::GetProperty時,Windows Media 裝置管理員會將此呼叫路由傳送至服務提供者的IMDSPDevice3::GetProperty 實作。 (大部分的應用程式介面都是以 IWMDM 開頭,而對應的服務提供者介面則以 IMDSP) 開頭。 服務提供者預期會處理這個方法呼叫,並傳回適當的結果。

除非應用程式呼叫 IWMDMDevice3::D eviceIoControlIWMDMStorage::SendOpaqueCommand) ,否則應用程式永遠不會 (直接探索或與裝置通訊;應用程式會與服務提供者通訊,這必須以最邏輯且簡單的方式代表裝置。 當應用程式要求裝置的相關資訊,或列舉裝置上的物件時,服務提供者會以適當的方式查詢裝置,並取得並傳回適當的資訊。 它可能會公開裝置上的檔案組織,與裝置上實際儲存的方式不同,如果適當的話。 不過,它會公開裝置,它應該以一致、邏輯的方式,讓應用程式找出所需的內容,並處理它所傳送的命令。 良好的服務提供者將會隱藏裝置特定的特性,例如,如果裝置實際將播放清單儲存為具有自訂副檔名的檔案,服務提供者應該在應用程式在裝置上建立播放清單時自動新增該擴充功能;它不應該預期應用程式在建立播放清單物件時知道適當的延伸模組。

服務提供者會在呼叫應用程式的程式中執行。 唯一的例外是 MTP 服務提供者,其會在自己的進程中執行。 因此,封鎖服務提供者會造成呼叫應用程式遭到封鎖的一些風險。 因此,服務提供者的設計應該是強固且防止封鎖,而且應用程式應該設計為避免在特定方法呼叫未快速傳回時停止。

快速入門