GoingNative 2: C++ at BUILD, Windows Runtime Library(WRL), Meet Tarek and Sridhar

Download this episode

Download Video


We're back with the third installment of C9::GoingNative and it's a LONG one Smiley For good reason, of course -> there's SO much to talk about! We all learned at the BUILD conference that Microsoft is fully committed to native developers and C++ on Windows 8 (Please see the C9 Live segment from BUILD where Herb Sutter addresses the C++11 compliance stuff).

BUILD represents the first time in the last 10 or so years that Microsoft has put on a developer conference with C++ front and center (along with managed code and now HTML5...). There's a lot of great native content from BUILD. If you haven't had a chance to watch any of the BUILD C++ sessions, please do!

As you can imagine, Diego and team are busily tracking and responding to the feedback provided by C++ developers who attended BUILD and/or watched the BUILD sessions on Channel 9. In this episode, we aim to clear up some of the confusion we're seeing around C++/CX, Microsoft's committment to ISO C++ (as it relates to Windows 8 app development, specifically), and low level WinRT programming for C++ developers who don't want to use C++/CX or can't use it for various reasons (like not being able to use exceptions).

We're thrilled to be able to meet and talk to Tarek Madkour, a leader on the VC++ team. Tarek shares some very wise perspectives on modern C++ for Windows 8 (Metro style apps). Hint: most of your time will be spent writing ISO C++, not C++/CX, which is the language extension you use to program at the boundary of your Metro application. Tarek also hooks us up with Sridhar Madhugiri, one of the authors of the Windows Runtime Library (WRL), a low level native library for advanced WinRT programming. When would you use WRL? Why would you use WRL? How do you use WRL? Sridhar answers these questions and more in our extended interview with him (it's long, but very well worth your time!).

Table of Contents
(click time code links to navigate player accordingly)

[00:00] GoingNative();
[02:46] Tarek Madkour beams in to talk about C++ at BUILD
[14:40] Sridhar Madhugiri digs into the Windows Runtime Library (WRL)
[01:00:07] ~GoingNative(); //we just call delete() to end it all...

We really want to hear from you, so please tweet feedback to @C9GoingNative (follow us!) and send your requests, ideas, complaints, praises, hate mail, and love letters to C9GoingNative at hotmail com. We will read and respond to all messages! That's how we roll, brothers and sisters. If you are a Facebook user, then please join our C9::GoingNative Facebook group.

Go native!


C++, COM, Windows 8, C++11



Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • User profile image

      1) The C++ specific   "Using Windows Runtime Components in Visual C++" needs to be beefed up, and sample code showing how to use std::wstring with the runtime components added.



      2) The C++ team should not let "Building your first Windows Metro style app using C#, C++, or Visual Basic"  at  http://msdn.microsoft.com/en-us/library/windows/apps/br211380(v=VS.85).aspx#getting_data_into_an_app">http://msdn.microsoft.com/en-us/library/windows/apps/br211380(v=VS.85).aspx#getting_data_into_an_app

      show that a C++ taking twenty times the source code as C# or VB.   Although I'm sure that was not intentional, an introductory METRO sample should be focused on clarity, not the use of language specific features.

    • User profile image

      @bdhc73a: Great feedback. Thank you. The MSDN documentation is also developer preview quality and will absolutely get better and (as in the case of WRL) more accurate.


    • User profile image

      Excelent talk. I have to say I'm one of those who take COM as too complicated/verbose to produce components, now you guys make it much more natural to deal with. Smiley

      For people who wants see more on WRL mixed with the language extensions I recommend take a care look at the DirectX Project Template, the code are awesome for learning, it expose some of the WRL headers, wrappers arround DirectX calls, and exception/errors mixing everything.

    • User profile image

      @Charles This is not the first time I hear about template metaprogramming in of your interviews, it is indeed something incredibly powerful but very hard to write and understand. It would be great if you or someone of the VC++ team could lecture us on that topic!

    • User profile image

      VERY NICE !

      But for lowest level of control on WinRT, maybe you could talk a little bit about ROAPI functions too Smiley

    • User profile image
      Great episode, congratulations! For me having an ABI and metadata that can be used in managed and native languages is the most exciting news from BUILD. I think one of the most productive ways of writing applications today is mixing C#/.NET code for UI, networking, XML etc. and native C++ components for accessing hardware and doing the really performance critical stuff. One big argument for using C# over C++ are the new async and await keywords that make asynchronous programming so much easier, which is especially important for writing responsive UIs. We were using COM for the interface between these two worlds for years now. But writing COM with C++/ATL and handling all the deployment stuff and datatype conversion is no fun at all. C++/CX, WinRT and .winmd seems to make this a lot easier, also making asynchronous operations across the boundary possible. But for our applications we will have to support Windows XP and 7 for a long time to come. So my question is: is there a chance to use this stuff for non metro desktop applications on older OS? I do not want to use any WinRT stuff, just the ABI infrastructure and C++/CX. Bernd
    • User profile image

      I second rab36's request.

      WinRT as ABI layer is a very good technology also for C++ desktop apps, and it would be great if it could be available for WinXP and Win7, too.



    • User profile image

      Actually I've been doing this kind of 'C# for highlevel/C++ for lowlevel' mixed-mode developing a lot now. I use C++/CLI as the 'glue' and its quite good, much better than COM actually.

    • User profile image

      @Matt: I know somebody who could do this rather well Smiley Great suggestion. TMP is certainly advanced and we could all stand to learn much more about this art and science. Noted!


    • User profile image


      You are right, C++/CLI is an option for this specific scenario. Nevertheless, a pure native possibility to publish (and consume) components with a stable ABI would be great. This is missing from C++ for a long time now and WinRT components with C++/CX could be a solution for it. It would enable component based architecture for applications with free choice of the programming languages.

      With C++/CLI you are forced to create mixed moded assemblies and to pull in the .NET framework and GC even when you consume the components from native code. Moreover it is not as easy to use e.g. PPL and ConCRT in C++/CLI (you have to to do a lot of indirection using pImpl all over) as in the the WinRT components. Think about all the pin_ptrs, gcroot<> etc. you have to write. I think C++/CX feels more natural, because it is native.

      But to have C++/CX availabe for metro style apps on Windows 8 only, is a big limitation. I must say, that I am a bit disappointed with the BUILD stuff in total. Metro, WinRT, XAML based UI for C++ and all that is great. And I think that PCs with Windows 8 will have a very good chance to get a huge share from the tablet / touch market beginning next year.

      But I think many of us C++ programmers (very likely the vast majority) will continue to write desktop applications for traditional PCs (because I strongly believe that there will be a large class of applications that cannot be Metro style) and they will have to support Windows XP and Windows 7 for at least 5 years from now.

      For a C++ renaissance on Windows a great UI / general native library (like WinRT for Metro is) to program desktop applications on Win XP and successors is still missing (like the .NET Framework and WPF is for managed applications). And when I have to continue to program against the Win32 library now and know that there is something much bettern than this, but I cannot use it, it is a bit frustrating.


    • User profile image

      1. Regardring V templates. If MS wants to be taken seriously you need to promise SP of FP that will contain v templates. To be released before 1.1.2013
      2. Regarding modern cpp. I liked Herb talk about for_each(begin(cont)) >> for(it=cont.begin())...
      so basically I would like more of those modern cpp TODOs and DONTDOs :P
      3. Bring STL back... I really miss his epic lectures. TMP is cool topic, but please keep it simple, and usable(not just cool aka prime numbers :)).

    • User profile image

      @Ivan: STL will be back! Don't worry. Smiley

    • User profile image

      Like @bernd I think C++/CX for UI only in Metro apps is a huge disappointment. I attended Build and was all excited about WinRT access from C++, especially the XAML-based UI. Since our app currently has a WPF-based UI (built in code with C++/CLI), this seemed like a perfect match.

      Alas, the severe limitations of Metro apps show that our app is definitely NOT going to be a Metro style application. We're more like the Photoshop example.

      So..... please please please let us create Desktop UI with XAML + C++!!

    • User profile image

      @bernd, @jps   +1.  The big missing piece is a modern, fully native UI framework (primarily, though not necessarily entirely, for native languages) that can target desktop applications.  The managed code world has had options like XAML/WPF for some time, but native users are stuck with Win32/MFC still, after all these years.  I was really disappointed to see no change there at Build.  Maybe it is coming eventually, but we are feeling left out in the cold yet again.  CLI is more of a workaround than a solution.  I think all the new stuff for Metro apps is great, but it has very little bearing on my current or future needs.

      +1 to the idea of a template metaprogramming series.  That would be fun.  STL could probably do that readily.  Or you could get some guest lectures from Andrei and blow everybody's mind.

      Thanks for the shows.

    • User profile image

      Agree with the above posters. Apparently this "new focus on C++", "completely new runtime", etc, etc, are mostly for not-yet-written applications that are going to run on something like a smartphone. And I thought we might actually get features that would be useful for our current applications (also Photoshop-like). A serious disappointment here.

    • User profile image
      The Reimaginer

      Nice to see someone at MS choke and chuckle when they got to say "reimagine". :)

    • User profile image
      Brian Jones

      +1 to a Template meta programming series
      +1 to the suggestion at Stephan TL doing the series if he can do it. He's really good at explaining stuff.

      With the WRL having TMP components any extra info on this subject would be greatly appreciated.

      Anyways, nice talk

    • User profile image

      I don't get it, if I use C++/CX  do I have to compile a version of my app for ARM and one for intel?  If not then how can this be native.  Also I created a demo using the c++/cx array and jsut creating a million winrt strings with it.  I did this in c# and in c++/cx.  The c++/cx version does not reclaim memory when control leaves the function scope it is declared and instantiated in.  My memory climbs to somewhere around 100MB and stays like that till the program ends.  The C# version seems to be garbage collected very quickly and does not go above 30MB ever.  I thought the benefit of reference counting was that it would be deleted immediately making the memory available to me.  I'm not an expert c++ guy, is there something I need to do to get better performance than the c# version without "going full native".  I assumed c++/cx was the most performant form of WinRT coding since there is no CLR and GC and all that. 

    • User profile image
      Tarek Madkour

      @xochl, you are right. You need to create a new binary of your app for each machine architecture you intend to support. This is true because it all compiles natively into machine code.

      I am not seeing the issue you're seeing with the string arrays. I tried the example you gave and memory usage goes down again after you exit the function scope. The array does not stick around in memory for the duration of the app. It shouldn't.

      With that said, however, this is still a developer preview and we still have a bit of work going on in optimizing the generated code so it is possible that you're hitting a bug somewhere. It would be great if you can share the code sample you're trying.

    • User profile image

      I think it will be great to invite in the show some folks working in other teams at Microsoft too. As native code is everywhere it should not be hard to find them ;) Windows guys for instance (like the ones evolving in kernel land, the shell, or the runtime)

    • User profile image

      @Matt: Absolutely! ( And you're quite right - Microsoft is powered by native code Smiley )


    • User profile image

      Say we just want to write Metro UI application entirely in C and nobody else is going to use our component, do we need to bear with all the complexity of COM?
      In Win32, I can #include windows.h and RegisterClass and CreateWindow and good to go.

    • User profile image

      I like C++/CX, But I hope Windows Phone 8 at least support C++ development!!!!

    • User profile image
      Kirill Osipov

      Wow! I described a concept similar to "RuntimeClass<IInterface1, IInterface2>" in my article at http://www.codeproject.com/KB/cpp/com_variadic_templates.aspx

    • User profile image

      @ryanb: You mentioned being "stuck with" Win32/MFC while the managed code world has had XAML/WPF for a long time implying that MFC has not changed forever. Not true. There was a big MFC upgrade in VS 2010. They added Ribbon to the resource editor. It is called 'MFC Ribbon' as compared to other implementations of the ribbon technology. MFC 2010's resource editor looks like Blend's design editor, but without the need to view or change the XAML code. I am assuming a 'ribbon' is the main element in what Jensen calls 'Photoshop-like' desktop applications. MFC Ribbon-generated code and ribbon programming code can be mixed in MFC 2010 apps at the statement level. I have no doubt that Microsoft will make MFC 2012 WRL compatible and we will be able to generate WRL MFC apps just like we do ATL MFC apps today.

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you can Contact Us.