BT

C++ Component Extensions: The New Face of COM

by Jonathan Allen on Sep 14, 2011 |

COM Programming is alive and well on the Windows platform and a new variant of C++ makes it much more approachable. Known as C++ Component Extensions, this new language was used to create the new Windows runtime, WinRT.

Though based on COM, C++ Component Extensions looks more like .NET programming than anything else. To being with, you will work directly with classes and objects rather than through the COM interfaces.

C++ components will start with a public class declared with the signature “public ref class XXX sealed” where XXX is the class name. A class so decorated is known as an “activatable class” and can be consumed by .NET and JavaScript-based applications. The “ref” keyword indicated the class is a “Windows Runtime compatible type”. The “sealed” keyword prevents inheritance, a requirement if the class is to be consumed by JavaScript. Though the documentation is fuzzy on this point, it appears that classes not used from JavaScript do not need to be sealed. For example, the Button class inherits from ButtonBase. In addition to classes, C++ Component Extensions supports structs. However a Windows Runtime struct is limited to just naked data members.

Classes may contain constructors, methods, properties, and events. Outside of the class itself you may find delegates signatures for use by the events. While this isn’t C++/CLI the syntax is remarkably similar complete with the use of the ^ symbol for handles.

Memory in C++ Component Extensions is handled differently depending on the semantics of the language that consumes it. If a C++ application uses the library then objects will be reference counted. .NET consumers will of course use mark-and-sweep garbage collection.

Public methods that are exposed across the ABI or Abstract Binary Interface. Such methods must use Windows Runtime types for parameters. C++ built in types such as int and double will be automatically converted; other types must be declared explicitly. For public methods Platform::String is used, internally Microsoft recommends using the standard C++ string type.

Custom exception types are not supported across the ABI. Developers must throw one of the built-in exception types. If additional information is needed one can throw the generic COMException which takes a HRESULT as a parameter.

While JavaScript supporting classes are sealed, they can at least implement interfaces.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

very good by Java 陈

WinRT is big step for windows8. Some questions?
1. What is the relationship about .Net and WinRT in windows 8? seems .Net on Windows 8 is based on WinRT?
2. Is there any plan to let WinRT to support None-Metro style app?
3. Since it is a new API for windows programming, what about XP, Win 7, any plan to support WIinRT?

Re: very good by Jonathan Allen

> 1. What is the relationship about .Net and WinRT in windows 8?

What we think of as the “.NET Framework" continues to run on top of the Win32 API. A subset known as “.NET Micro” runs on top of embedded devices. Another subset of that known as “Silverlight” runs on top of the browser. A third variant as “Mono” runs on top of the Linux kernel.

Think of Metro the same way. We have yet another subset of .NET that is specific to WinRT and the Metro user interface.

> 2. Is there any plan to let WinRT to support None-Metro style app?

No. All the stuff you need to write non-Metro applications is in Win32 libraries such as GDI. It is a completely different stack and the two were not designed to work together. There are fundamental concepts like overlapping Windows that WinRT simply does not understand. It is like Win32 and WinRT are two completely separate operating systems that happen to be sharing the same hardware and device drivers.

> 3. Since it is a new API for windows programming, what about XP, Win 7, any plan to support WinRT?

Absolutely not. They had to rewrite large parts of the Windows Kernel in order to support the WinRT API.

You have to understand that WinRT isn’t like .NET or Java. It doesn’t just sit on top of the operating system; it effectively is the operating system. There is nothing between it and the kernel itself. As such, there is no way to back-port it to older operating systems without fundamentally altering them in the process.

Re: very good by Java 陈

If so, developers still need to use Win32 or .Net to write traditional desktop app. And I think there should be None-Metro style app in desktop version windows, so MS has no plan to obsolete Win32, right?

In the later windows, there always be 3 programming APIs, WinRT, Win32, .NET, true?

Re: very good by Jonathan Allen

More like this:

* Win32
* Win32 + .NET
* WinRT
* WinRT + .NET
* WinRT + JavaScript

Re: very good by Java 陈

More like this:

* Win32
* Win32 + .NET
* WinRT
* WinRT + .NET
* WinRT + JavaScript


You know, once Apple has Carbon and Cocoa together. Now Apple unify them in a Cocoa world. And Cocoa for Mac OS and Cocoa touch for iOS. It seems there are too many for Windows.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT