共用方式為


Windows 媒體設備管理員架構

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

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

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

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

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

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

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

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

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

裝置的架構

下圖顯示使用 Windows 媒體設備管理員的應用程式所見的裝置和記憶體簡化階層。

圖表,顯示裝置上的記憶體。

上圖顯示已連線快閃磁碟驅動器的簡化版本,如 Windows 媒體設備管理器應用程式所見。 快閃磁碟驅動器具有屬性和屬性,例如序號和支援的格式組態。 快閃裝置的直接子系是根記憶體物件,其中包含資料夾,其本身包含影像和歌曲。

應用程式會藉由呼叫根 IWMDeviceManager 介面公開的列舉方法,來列舉附加裝置的清單。 裝置會以 IWMDMDevice(或衍生的)介面來表示。 這個介面會公開方法來擷取裝置名稱、格式功能、序號等,以及列舉裝置上 記憶體 的方法。 在 Windows 媒體設備管理器中,記憶體是裝置上任何類型的物件,不論它是否為實際的數據 Blob。 例如:音訊檔案、文本文件、資料夾、儲存為檔案的播放清單,以及儲存為元數據的播放清單都被視為記憶體,即使資料夾和元數據專案可能不代表實體檔案。 您可以呼叫 getAttributes來擷取記憶體的類型(或格式 GetMetadata,以要求記憶體的格式)。

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

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

服務提供者

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

服務提供者是建置在 Windows Media 設備管理器上的 COM DLL,可接收來自應用程式的要求,並與裝置通訊以執行這些要求。 與傳統型應用程式的通訊是由 Windows 媒體設備管理器所調解;與裝置的通訊由服務提供者控制。

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

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

當裝置連線到計算機時,作系統會為每個 Windows 媒體設備管理員應用程式建立一個適當的服務提供者實例。 如果第二個 Windows 媒體設備管理員應用程式啟動時,則會載入服務提供者的第二個實例。 不過,每個服務提供者都可以處理多個裝置。 下圖說明這一點。

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

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

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

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

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

用戶入門