Windows Development with C + +: Windows Runtime Application Model

Our lives are full of abstraction. As a developer, if we don't understand the abstract definition to use it, it usually gets us into trouble. Abstractions are sometimes fragmented and cannot completely hide the underlying complexity. Don't get me wrong, but abstraction is very useful. They can help users and developers, and you'll benefit if you delve deeper into the abstractions that you typically rely on to understand how they work. In addition, a library that acknowledges this reality is generally more successful than a library that does not recognize this reality, partly because it allows you to bypass abstraction if necessary.

The Windows runtime (WinRT) is an abstraction that, in this month's column, will illustrate this abstraction by studying the WinRT core application model. This abstraction is centered on the Corewindow class, and each "new" Windows Store and Windows Phone application contains an instance of the class. But few developers know the existence of the instance, not to mention how it works. This may be the best proof of abstract success.

Since the Windows 8 API was first released in 2011, there have been a number of reports and articles about various language projections that provide abstraction through Windows runtime. However, the best way to understand the Windows runtime is to avoid various language projections (including C++/CX) and use standard C + + and classic COM. Only C + + can let you see the actual situation through the appearance (technically, C also can, but will cause some unnecessary trouble). You can still choose to use one or another language projection (hopefully c++/cx), because you might want to do so, but at least you need to get a clearer picture of the reality.

To start this operation, open visual Studio 2012 and create a new Visual C + + project for the Windows Store or Windows Phone application. Use whatever template you want. After loading, go to Solution Explorer and remove all unimportant content. If you select a XAML based template, all XAML files are deleted. You can also delete all C + + source files. You may want to keep the precompiled headers, but be sure to remove all the content contained therein. The content that should be retained is the package assets required to deploy applications, images, certificates, and XML manifests.

Next, open the project's property page and select the compiler properties-the C/p + + node on the left side of the tree. Locate the row for the/ZW compiler option called "Use Windows Runtime extensions" and select "No" to disable the C++/cx language extension. This way, you can make sure that there is nothing more mysterious than the standard C + + compiler. In this step, you can also set the compiler's warning level to/W4.

If you attempt to compile the project, you should receive a linker error informing you that the WinMain entry point function for the project could not be found. To add a new C + + source file to your project, the first thing you do is add the missing WinMain function:

int __stdcall wWinMain (hinstance, HINSTANCE, pwstr, int)
{
}

As you can see, this is the old WinMain function for Windows applications based on the C Run-time Library (CRT). Of course, hinstance and pwstr are not basic C + + types, so you will need to include Windows headers:

#include <windows.h>

If you keep the precompiled header for your project, you can include it here. In addition, since I will also use the comptr in the Windows runtime C + + Template Library (WRL), it is best to include it now:

#include <wrl.h>

In the next few columns, I'll introduce WRL in more detail. Now I'm going to use the Comptr class template to maintain the COM interface pointers. In this phase, you only need to remember that WRL comptr is just a COM interface smart pointer. Although it provides some features that are specific to the Windows runtime, I will not explore these features in this month's column. You can easily use either the Active Template Library (ATL) CComPtr or any of the COM interface smart pointers you choose. The WRL comptr is defined in the MICROSOFT::WRL namespace:

using namespace MICROSOFT::WRL;

I will also use ASSERT macros and HR functions for error handling. Since I've discussed this before, I'm not going to tell you here. If you are unsure of these steps, please refer to my column "Direct2D 1.1" (msdn.microsoft.com/magazine/dn198239), which I wrote in May 2013.

Finally, to use any of the WinRT functions mentioned in this column, you need to provide the name of the. lib file for the linker:

#pragma comment (lib, "RuntimeObject.lib")