C++ Component Extensions: The New Face of COM
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.
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.
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
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
In the later windows, there always be 3 programming APIs, WinRT, Win32, .NET, true?
Re: very good
* Win32 + .NET
* WinRT + .NET