MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

The Building your own Windows Runtime components to deliver great apps post on the Windows 8
developer blog gives some examples of this. It shows how to use the System.IO.Compression API in .NET
to work with ZIP files and the XAudio APIs (part of DirectX) to bypass the HTML audio element and
perform native audio playback. In the latter case, you might remember from Chapter 10, in the section
“Playing Sequential Audio,” that no matter how hard we tried to smooth the transition between tracks
with the audio element, there is always some discernible gap. This is due to the time it takes for the
element to translate all of its operations into the native XAudio APIs. By going directly to those same
APIs, you can circumvent the problem entirely. (That said, Microsoft knows about the behavior of the
audio element and will likely improve its performance in the future.)
This approach can also be used to communicate with external hardware that’s not represented in the
WinRT APIs but is represented in Win32/COM. We saw this with the XInput and JavaScript controller
sketch sample in Chapter 15, “Devices and Printing” (also discussed in the blog post above).
Another very simple example would be creating a component to answer an oft-heard question:
“How do I create a GUID in JavaScript?” Although you can implement a routine to construct a GUID
string from random numbers, it’s not a proper GUID in that there is no guarantee of uniqueness (GUID
stands for Globally Unique Identifier, after all). To do the job right, you’d want to use the Win32 API
CoGreatGuid, for which you can create a very simple C++ wrapper.
Overkill? Some developers have commented that going to all the trouble to create a WinRT
component just to call one method like CoCreateGuid sounds like a heavyweight solution. However,
considering the simplicity of a basic WinRT component as we’ve seen in this chapter, all you’re really
doing with a component is setting up a multilanguage structure through which you can use the full
capabilities of each language. The overhead is really quite small: a Release build of the C++ component
in “Quickstart #2” produces a 39K DLL and a 3K .winmd file, for example.
Using a WinRT component in this way applies equally to COM DLLs that contain third-party APIs like
code libraries. You can use these in a Windows Store app provided they meet three requirements:
• The DLL is packaged with the app.
• The DLL uses only those Win32/COM APIs that are allowed for Windows Store apps. Otherwise
the app will not pass Store certification.
• The DLL must implement what is called Regfree COM, meaning that it doesn’t require any
registry entries for its operation. (Windows Store apps do not have access to the registry and
thus cannot register a COM library.) The best reference I’ve found for this is the article Simplify
App Deployment with ClickOnce and Registration-Free COM in MSDN Magazine.
If all of these requirements are met, the app can then use the CoCreateInstanceFromApp function
from a component to instantiate objects from that DLL.
751