Games for Windows and the DirectX SDK blog

Technical tips, tricks, and news about game development for Microsoft platforms including desktop, Xbox, and UWP


Project maintained by walbourn Hosted on GitHub Pages — Theme by mattgraham
Home | Posts by Tag | Posts by Month

Who moved my Windows Media Cheese?

win7, win8

Originally posted to Chuck Walbourn's Blog on MSDN,

Since the release of Windows XP Service Pack 2, support for the Windows Media codec (WMV) has been built into the OS, so developers have come to rely on it being there particularly for DirectShow playback of cutscenes or video textures. On Windows Vista, we introduced the Windows Media Foundation APIs as well. Much like the core of DirectX becoming part of the OS, these components being present on all modern versions of Windows simplifies the deployment story for applications.

Alas, the European Commission and the Korea Fair Trade Commission has made that story a bit more complicated…

For games that make use of the Windows Media codec (WMV), Windows Media Foundation, Windows Media Player, the WMP ActiveX control, or other aspects of the Windows Media Format SDK Runtime, you will need to provide some guideance for users with the N or KN editions of Windows.

For Windows 7, there are two options for restoring these components to the system

  • The Windows Media Feature Pack (KB 968211) installs all the Windows Media components. This is required for applications that make use of the Windows Media Foundation, Windows Media Player, or the WMP ActiveX Control.

-or-

  • The Windows Media Format Feature Pack (KB 968212) installs the Windows Media Format SDK Runtime support for the WMV codec. This is sufficient for applications that use the WMV codec through DirectShow. Note that these components are also included in the KB 968211 update.

For Windows Vista or Windows XP N editions, installing Windows Media Player is the easiest way to restore this functionality.

Putting a note about these editions in your release notes or on your support website should be sufficient. If, however, you are looking for a way to programmatically detect N or KN editions, you should first use existing techniques for trying to use the feature but gracefully handle it not being available (i.e. try to create the COM object or use explicit linking via LoadLibrary). Only if that fails should you look at generating a message to the user. For Win32 desktop applications, you could then use the GetProductInfo function (KN editions identify as N editions that are localized to the Korean language) when handling the error case to verify that is the likely problem. Note this function is only available on Windows Vista or later, so you should use explicit linking for that API as well if you are trying to maintain code compatibility with Windows XP. While there are in fact Windows XP N Editions, they were sold in very low numbers so you are unlikely to have any significant number of users in this situation.

This reliance on Windows Media components is not limited to just gamers, so it is likely that most users will already have installed one of these updates to enable other applications to function. With fresh installs of the OS, particularly if you are explicitly testing with the N or KN editions of Windows, it is important to apply the appropriate Feature Pack.

Windows 8.0, Windows 8.1, and Windows 10: See KB 3145500 for which Media Feature Pack to install for your OS.

Windows 10 / Windows 11: As of Windows 10 Version 1903 (Build 18362) or later, the “Media Feature Pack” is available as a Windows optional feature.

Note that both Window Vista and Windows 7 N and KN editions excluded MFPLAT.DLL, but for Windows 8.x there is handling for systems without the Media Feature Pack installed that returns E_NOTIMPL when you call MFStartup. This simplifies handling for Windows Store apps and UWP apps which cannot make use of explicit linking to system DLLs. Windows Store apps and UWP apps should therefore make use of delay loading (using dloadhelper.lib) for all Media Foundation DLLs.