Visual C++ in Visual Studio 11 for Windows Developer Preview has a new programming model for creating Metro style apps and components. One of the primary features of the new model is the abstract binary interface, or ABI, which defines an interface for inter-language communication. In Windows Developer Preview, native C++ can communicate across the ABI with JavaScript and with the managed .NET languages C# and Visual Basic. This means you can create high-performance components in native C++ and consume themdirectly from one of these other languages. It also means you can consume Windows Runtime types directly in native C++, without having to interop with a managed layer as when you consume .NET Framework types.

At a low level, the new programming model is based on an updated version of COM, but the way that you program against this new model is more simple and natural than old-style COM programming. When you create a consumable Windows Runtime components or Metro style apps in native C++ you work primarily with classes and members just as in standard C++. JavaScript or .NET code instantiates your object by using new (or New) and the object is destroyed according to the mechanisms of the client language. When native C++ consumes a Windows Runtime object, destruction is handled by means of reference counting.

To understand the simplicity of the new programming model, consider the following example, which is all the code you need to write to create a COM object, or what is now called a Windows Runtime component:

public ref class MyClass sealed
{
    public:
    MyClass(){}
    ~MyClass(){}
    int MethodA(int i) { return i * i};
}

In this example, you will immediatelynotice some keywords that are not part of standard C++. Visual C++ defines a few Component Extensions that, in a Metro style app,are essentially syntactic sugar over the underlying COM calls involved in creating and consuming Windows Runtime types. You typically use these extensions in the public interfaces where your code is passing Windows Runtime types back and forth across the ABI to JavaScript, C#, or Visual Basic (or even another C++ module). Visual C++ provides a variety of implicit conversions between Windows Runtime types and standard C++ types. The typical pattern is to use standard C++ types and libraries internally as usual, and convert to Windows Runtime types in the public interfaces.

If you are familiar with C++/CLI, you will notice that the Component Extensions look very similar to C++/CLI syntax. However, in a Metro style app or Windows Runtime component, all the C++ code is native. The /Zw compiler option causes the Component Extensions to be compiled for Windows Runtime. The /cli compiler option causes them to be compiled for C++/CLI. Currently, C++/CLI is not supported for Metro style apps

The extensions for Windows Runtime components serve five basic functions:

• map C++ patterns (such as constructors) to COM interfaces

• map between exceptions and HRESULT values

• map between output parameters and return values

• provide automatic reference counting of pointers to Windows Runtime objects

• read and write metadata

The other topics in this section describe how to use Visual C++ to access and manipulate Windows Runtime types and how to perform tasks such as event handling and exception handling.