C9::GoingNative 2: the Windows Runtime Library (WRL)

C9::GoingNative 2: the Windows Runtime Library (WRL)

Rate This
  • Comments 23

Click to watch the episode in Channel 9We're back with the third installment of C9::GoingNative.

At the recent //BUILD conference, we introduced a series of technologies targeting the upcoming version of the Windows platform. One of those consists in some extensions to the C++ language, intended to help developers bridge their C++ logic to the Windows Runtime (WinRT) environment.

C++/CX (the name of these extensions) is a lightweight syntax for COM creation, being COM the framework that allows components written in different languages to interoperate in Windows. In practice, it allows the user interface to be designed with ad hoc tools like MS Expression (XAML) or any HTML5 editor, while adding application behavior in C++.

The reception of C++/CX is mixed so far. It’s being appreciated for those developers who considered COM a complex technology despite its usefulness. It’s not much liked by developers who dealt with COM or the Active Template Library (ATL), an abstraction layer to make COM creation easier.

These last ones asked about an approach that doesn’t involve non-standard language extensions but an API that encapsulated COM complexities. Such API is called Windows Runtime Library (WRL) and follows the principles of ATL, re-implementing those for the Windows Runtime though.

In this episode, we interviewed Sridhar Madhugiri, one of the authors of the WRL, who answered for us questions like When would you use WRL? Why would you use WRL? How do you use WRL?

Prior to that Tarek Madkour, a leader on the VC++ team, shares some wise perspectives on modern C++ for Windows 8 (Metro style apps). Enjoy this episode!!

Leave a Comment
  • Please add 2 and 8 and type the answer here:
  • Post
  • I heard that WRL will only be accessible to Windows Store applications.

    Is this true?

  • WRL is a alternative technology to C++/CX for building Metro style apps, whether they are in the store or not.



  • Diegum,

    There´s any chance of more C++11 features suppport with the final build of Visual Studio ?

  • Can use C++/CX to replace ATL in non-WinRT application for simplified COM operation  ?

  • Must one use script to do layout or may one use real, compiled-to-he-man-bits code to do layout?

  • For crying out loud.

    That's not c++ it's c++/cli. Managed .net crap.

    Microsoft just wants to lure more devs over to .net, and this is the transition drug. Disgusting !

    Please stop this already.

    You should have spent more time on the c++11 features then this but as we all know your prioritization is messed up.

  • @James:

    It is neither. That was actually made pretty clear in this video (if you'd bothered to watch it) and quite a few other places.

    It is not CLI, it does not load or use the .NET runtime *at all*.

    It is a proprietary nonstandard C++ dialect which reuses C++/CLI syntax, but is used to interop with WinRT, and not .NET.

    I too disagree with their prioritization, but let's stick with the facts, shall we? This is not in any way a gateway drug to .NET, because it is 100% unrelated to .NET.

  • @jalf If I may, I was thinking about it for a while and I think that MS will ditch .NET in near/not so near future, but they want their users to stay with them. That's why this familiar to them syntax. There is over 6 millions of C# devs at the moment. Microsoft wants them and in order to keep them and make their transition from 'will be ditched' technology to 'this is new hot stuff' there introduced this syntax. As everyone of us already knows there is no C++11. Why? Just guessing but again, those C# devs aren't bothered by not having C++11 stuff. What they need is familiar syntax so they can start using new technology. And C++11 will be implemented... who cares!!! Those losers (I'm amongst them) who program in C++ are not their (MS) problem. MS has loyal C# crowd and needs to accommodate them.

  • I think the primary inflammatory factor is that MS is advocating the use of the C++/CX extensions in .cpp and .h files.  Herb Sutter has advocated limiting the C++/CX to a thin interoperability layer, which seems prudent to me, but when C++/CX and ISO-C++ use the same file extensions, it makes it very likely that the extensions (or at least, dependencies on them) will find their way into otherwise standard code.  If MS introduced a new file extension like they did for C# (.cs), I don't think anyone would care.

  • @S. Colcord:

    "If MS introduced a new file extension like they did for C# (.cs), I don't think anyone would care."

    I think there are two distinct reasons people are up in arms:

    1. Almost complete lack of progress on C++11, which is very desired.

    2. Yet another extension to C++, which many (me included) don't want.

    People feel betrayed due to 1, disappointed due to 2 (various reasons: many see the new language extensions as another attempt at vendor lock-in, many think that the extensions are not sufficiently justified as simply packing the relevant functionality into a clever set of C++ libraries would do the job much better, many are non-plussed by the fact that this set of extensions is no less than a third, with the previous two sets not doing very good in terms of support and adoption, etc), People also feel appalled by Microsoft's attempts to paint the combination of 1 and 2 as 'C++ renaissance' (there's very little C++ in there).

    If Microsoft would introduce a new file extension and change their rhetoric for 'C++ renaissance' to 'C++/CX renaissance', that would perhaps solve the third issue (less people feeling appalled), but not the former two.

  • @Alex Ionescu: yesterday, Dr. Dobb's published an interview to our C++ Principal Architect Herb Sutter. He reiterates what he told last month during the //BUILD conference (that while the next release won't include variadic templates and other C++11 features, you won't have to wait for a whole release cycle to get those).


    @jerry7: No. The extended syntax is restricted to Metro style apps.


    @Jerimiah: XAML and HTML5 are the two core technologies for layouting components in Metro style apps.


    @James: jalf is right. This is neither .NET nor an attempt to lock you in: the extended syntax helps you build WinRT components without falling into the details of the Windows component architecture (COM). C++/CX is not more proprietary than COM.

    Your opinion about our prioritization (widely shared by others) is legitimate, though. Let me ask: if we announced the Metro style programming model with only .NET and JavaScript as alternatives, but not C++, would we have avoided the discomfort? I’m just curious because the Windows Phone 7 tools we released hadn’t considered native development and that wasn’t well received either. By then, our coverage of C++0x was good enough. Looks like every time we choose we’ll get people unhappy. The good news is that new C++11 won’t have to wait until VC++ v12 (check my answer to Alex).


    @Knowing me: not at all. No conspiracy theories apply here. In fact, C++/CX was pretty well received by .NET developers who were glad to see that they can learn C++ (both, ISO and our extended syntax) as they feel that they could get more of their code running “on the metal” (Check these tweets: 1, 2, 3, 4). This doesn’t mean an end of .NET either; I consider important this clarification because I found people concerned in the .NET camp about whether the C++ Renaissance meant an end of managed development. That’s totally wrong as well.


    @S. Colcord, @PleaseFixYourBugs: interesting thoughts both of you. Check the 2nd paragraph in my answer to James, though: if we shipped C++11 features but no way to make Metro style apps in the upcoming Windows 8, wouldn’t the community feel “betrayed” as well?

  • @Diego Thank you for your answer.

    But just to clarify, I didn't mean that it is some conspiracy theory. What I meant is that policies are made in order to ease shift for C# programmers to native coding (which I do not see as a bad thing by the way).

    No conspiracies - just politics.

  • @Diego:  "...if we shipped C++11 features but no way to make Metro style apps in the upcoming Windows 8, wouldn’t the community feel “betrayed” as well?"

    To be clear, I have no objection to the existence of the C++/CX extensions.  However, I do feel that it was inappropriate to enable the extensions by default in normal C++ code.  Microsoft should have used a different file extension for C++/CX header and source files to avoid the risk of confusing C++/CX code with ISO C++.

  • @Diego Dagum - MSFT:

    "...if we shipped C++11 features but no way to make Metro style apps in the upcoming Windows 8, wouldn’t the community feel “betrayed” as well?"

    If you did this, people would be unhappy too.

    I am not sure what you are trying to get to: that whatever you do, someone would feel unhappy, and thus you are partly or entirely justified in ignoring the outcries? If so, I find this line of reasoning unappealing. Outcries are different. This particular outcry is very valid, you did manage to fool C++ developers into believing you are working on C++11 while you were working on something else completely (something that many of us actively *don't* want, too). People who think you have betrayed them are justified in doing so.

  • @Knowing me: sorry for my confusion. It may be understood like the intention was to make easier for .NET devs to build COM. In fact was not thinking on .NET devs in particular but also the many C++ devs -so devs in general- who found COM way too complicated, even with ATL (which shorten the lines of code count but doesn’t hide completely some details, so you need to learn COM anyway). .NET devs still need to learn ISO C++ for the components core (STL, by-value vs. by-reference, probably also concepts like RAII, etc.), because the /CX extensions make sense just for the interop part.

    @S. Colcord: crystal clear.

    @PleaseFixYourBugs: I’m not justifying the lack of much C++11 progress with that question. If possible, I’d like you to be more explicit in what you say that “you did manage to fool C++ developers into believing you are working on C++11”.  I got some news from the VS Debugger team about the bugs we filed. The one that had been fixed, they are at this time investigating what failed in the process as they reconfirmed me that the fix should have been shipped in the CTP. Will keep you posted. About the other one, I’m procuring them to explain better in the proper place (the Connect bug) the reasons they decided to keep it in the backlog.

Page 1 of 2 (23 items) 12