locked
Is there any plan to allow native C++ xaml on desktop apps, ala WPF interop?

    General discussion

  • I realize that there is a new app paradigm with the Metro stuff, but there are great many developers with gigantic applications running on the desktop, and will probably stay that way for the next few years. During that period, we will be building more GUI. Right now the tools available to us on Win32 for building GUI are quite inferior to the experience one gets with WPF/xaml.

    I can't see why it should be hard for Microsoft to allow the native C++ xaml stuff to run side-by-side with Win32, in very much the same way that WPF does right now. The currently supported .NET WPF/native interop ends up being a very expensive route to go down, primarily because the cost of writing all the glue code is high. I started down that route last year but backed out after a few weeks of pain, after realizing that I was spending all my time writing glue, with very little end-user value to show for it.

    What we need on the desktop is a better paradigm than Win32/MFC, and native C++ xaml seems like a perfect fit.

    What is Microsoft's position on this?

    I think you guys owe it to us to make your position clear on the future of Windows desktop app development as soon as possible.

    Thanks,
    Ben

     

     

    Friday, October 07, 2011 8:03 AM

All replies

  • There are 2 separate issues there. (1) Ability to parse WPF/SL Xaml from C++ projects (2) Ability to function as a first class managed language.

    Given that C++ projects can already handle Xaml (because of WinRT), it may not be that complex for the VC++ team to extend that to suport WPF and SL projects as well. But for a few years now C++/CLI has had no improvements, so it's not a first class CLI language today and cannot consume many of the new features added to the CLR since .NET 2.0 (when C++/CLI last had full functional parity with C#). This may make it harder to consume WPF or SL (both managed frameworks).

    Given the new drive for native Windows development, a better approach may be for the Windows team to implement a WinRT-like Xaml based framework for desktop development too. Something like a native COM-based version of Silverlight that works on desktops. Then all the C++ team needs to do is to add thin wrapper/library support for that (won't be too different from what they already did for WinRT) and C++/CX will make the COM-access easier.

    Of course I am not the guy making these decisions. But I just thought I'd throw this here in case anyone wants to get some feedback on this. :-)


    http://blog.voidnish.com
    Friday, October 07, 2011 12:31 PM
  • Just in case I didn't make myself clear:

    I want zero dependence on the .NET VM.

    I want a better way to build GUI for applications written in C++, that compile to native x86/x64 executable code.

    I want to be able to slowly bring these new GUI elements in, without having to throw away all of my existing Win32/MFC code.

    Ben

    Friday, October 07, 2011 1:09 PM
  • I don't see any current or future path to let you "slowly bring these new GUI elements in" to a C++ MFC application.  Even if there was, it probably won't run on WinXpired or Win7.  So stick to your existing code base for another year or two. 

    You might consider a NEW Metro application if you are comfortable with the Metro side of the comparison table in:

    http://msdn.microsoft.com/en-us/library/windows/apps/hh464912(v=VS.85).aspx

     

    Friday, October 07, 2011 1:51 PM
  • I understand that, looking 10 years into the future, we're probably going to be interacting differently with our computers. The display may well be built into our glasses, canonical data will live mostly in the network/cloud, etc.

    However, until that future comes about, there are still going to be a great many people who sit down at a desk for 8 hours a day and create content on their computers with a mouse and a keyboard. The bulk of those content creation apps are written in C++. For the relatively small investment on Microsoft's part, I think they would win a lot of CC app developer's hearts if they gave us a better GUI framework that we can use for the next 10 years or so.

    The Metro stuff has it's place, and I understand that. But that is not my question. My question is more along the lines of "How far is the desktop model from EOL"?

    Friday, October 07, 2011 2:46 PM
  • Can someone from Microsoft please comment on this with links to information now that the Consumer Preview and VS11 Beta is out?

    I am a product developer (CAD/Modeling - not LOB). Our products are desktop products that use Win32/HWNDs & Direct3D heavily, some WinForms, a little MFC, and even less WPF. We're also creating some simpler viewing/markup products that could possibly be Metro/Win8. I got excited when the hackers of early Win8 leaks were talking about a native "DirectUI" layer that supported XAML, and I assumed we were going to be able to use that in desktop products on Win8. However, the native WinRT layer, with language projections, is only available for Metro style, full-screen apps, and the contraints of the Metro style prohibit many desktop products from being migrated (E.g. Office 15 will be a desktop product, even on ARM, and VS11 will remain a desktop product). WPF is a great tool for building desktop LOB apps, and even though it has been criticized over the last few years for of its performance and airspace problems, the situation has improved somewhat with WPF 4/4.5, due in large part to the VS2010 team requirements. But it's not a native framework and still has some performance and airspace issues (Airspace fixes have unfortunately been removed from WPF 4.5). Out-of-browser Silverlight apps have a clear path toward Metro style apps for Win8; give desktop apps the same clear path toward "DirectUI" for outside-of-Microsoft desktop product developers so we can develop XAML-based, native products using the same language projection technology utilized for Metro style apps.

     

    Dan

    Thursday, March 01, 2012 4:17 PM
  • This needs to be answered by the Windows team, not the C++ team. Given the need to enter tablet market right now, i don't think there is any plan for Windows 8 to add Win32 XAML support, but I think something like Windows 7 ribbon is possible in the future, given enough demand. You can start a vote on visual studio uservoice or connect. 


    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP

    Thursday, March 01, 2012 4:33 PM
  • Just want to throw my 2 cents in. I'm in complete agreement that it would be awesome if we could use xaml from native c++ w/out having to go through c# or specifically building a metro app. So awesome in fact that if someone out there makes this possible I have many a high fives to give and maybe a fruit basket or two :) 

    Tuesday, May 15, 2012 5:32 PM
  • Well, technically, I don't think MSFT needs to do a lot to make it happen. People like Jeremiah Morrill have shown that this can be already done today: http://jeremiahmorrill.wordpress.com/2011/09/26/windows-8-dont-worry-nothing-has-changed-for-traditional-desktop-development-and-thats-the-problem/

    Yes, it is not supported by Microsoft. However, this does not seem to be a technical question because it can be done.

    I read somewhere / saw video on Channel9 that almost all APIs could be available to Desktop developers but the Windows Team decides, which set of the new APIs is available or not.

    (conspiracy) It could be that MSFT wants to push full-screen apps as the future way of making apps and leave the legacy (desktop) behind. I would not agree to this approach though.

    - Paul

    Wednesday, May 16, 2012 11:38 AM
  • A "desktop" application uses the Windows API (Win32) with overlapping windows.  A "Metro" application uses WinRT API, can't do overlapping windows, and runs typically full or split screen.  Neither one technically needs to depend on the CPU instruction set.

    However, somebody made a compromise solution:  We support desktop applications on Windows 8 for Intel, but not for ARM.  The theory must be that existing applications must work on some version on Win8, but there must be some devices that don't support desktop applications so that developers must have a good reason to move to Metro applications.  It is similar to King Solomon's half a baby solution.

    Microsoft has a similar kind of problem with having VS11 support Windows XP, they want more developers to use the VS11 compiler improvements, including having Metro development as an option, but they also want Windows Xpired users to join the party.

    Wednesday, May 16, 2012 12:33 PM