locked
Native WPF RRS feed

  • Question

  • I was planning a C++/CLI application that would be predominantely standard native C++ but with the GUI written using WPF. One problem has been to find documentation and code examples on how to use WPF from C++/CLI, but this can be overcome and initial testing shows that this approach works perfectly fine (C++/CLI really is an amazing engineering achievement).

     

    Still I really would like to write the whole application in standard C++ and my question is how come WPF is .NET only? It would have been so easy to make the core WPF native and then supply one wrapper for native use and one wrapper for managed use. In this way the "wealth" of WPF would be distributed equally over both the native and the managed camps. As it stands .NET takes it all.

     

    Say a company has highly educated and experienced C++ professionals who are churning out excellent native Windows applications one after the other. Is it really in MSs best interest to try to force them into using .NET instead? I don't think so. I think MS should reconsider this unsensitive march into .NET dominance. Managed code may very well turn out a fad and why alienate all those who want to stick to standard C++ only for whatever reason?

     

    WPF is an excellent GUI package and it represents the future of Windows so why isn't it available for both native and .NET usage?

     

    Tuesday, October 30, 2007 4:23 PM

Answers

  • In a perfect world, it would be great to have both native and managed version of everything (well, in a *really* perfect world, there would be no hard distinction between using a native or managed API, but that's a different conversation <g>).  However, the reality is that we have to balance the investment required to do this kind of thing versus the customer benefits realized by doing it.  This cost/benefit analysis means that various teams will chose paths that they feel provides the maximal benefit for the cost.  A result of this process is that today we find that some APIs/libraries are managed only (like WPF or WinForms), some native only (like the Vista shell or Win32), and only a handful are both (like DirectX).

     

    I can't speak for all Microsoft teams, but speaking from Visual C++ team's standpoint, we talked to a lot of customers about the very question of how important it was for them to do WPF in C++.  We found that the overwhelming majority of customers were perfectly okay writing their WPF code in C# and creating an interop layer written in C++/CLI to hook this to their native C++ code.  I don't want to completely discount that important minority of customers that would much prefer to do this work in native C++, but in terms of priority it was pretty clear to us that there were other places we could invest our resources that would provide greater benefit to a greater portion of our user base.  To talk specifics, this decision freed up the resources necessary for us to invest in a substantial effort on our compiler front-end that will contribute to an amazing coding-time experience in the Visual Studio 10 timeframe.

     

    Hope that helps.

     

    Steve Teixeira
    Group Program Manager, VC++

    Wednesday, October 31, 2007 11:04 PM

All replies

  • If a company has "highly educated and experienced c++ professionals" those people aren't going to have any difficulty learning C# and being more productive because of it. There is no reason an unmanaged framework around milcore (WPF is the managed framework around it) should be created. WPF is a GUI toolkit, and higher-level languages are very appropriate for GUI toolkits.

     

    Perhaps this move on the part of Microsoft will help convince you .NET isn't a "fad". I haven't heard anyone voice any suspicions about .NET like that for a long time. It's here to stay - at least until the next thing comes along - but the next thing won't be C++.

     

    Tuesday, October 30, 2007 6:13 PM
  • I have to second Tim's comments...

     

    Microsoft made it clear in 2002 with the announcement of the Longhorn API (LAPI) that their strategic direction was to move away from unmanaged code and instead provide a fully managed API for Windows client development.  This decision was not made to enable poorly educated and less experienced professionals to write Windows code (which seems to be your underlying implication).  Rather, the decision was intended to move Windows development into the modern software era. 

     

    The original LAPI announcement portended the eventual demise of Win32 (at least on the user mode side).  I think we'd all agree that it is highly unlikely that Win32 development will ever go away completely, but it is certainly becoming MUCH less prominent.  Eventually, those of us who know those APIs will be as rare as the assembly-level developers who preceded us.

     

    As someone who wrote kernel level code for the majority of my career (and have now been writing Avalon code for nearly 5 years), I strongly support this new direction.  I do miss low-level development from a nostalgic point of view, but not from a practical point of view.  The benefits of the CLR and the sheer elegance of the managed frameworks like WPF that run on top of it far outweigh the negatives.  (And yes, I do acknowledge those too.)

    Tuesday, October 30, 2007 7:00 PM
  • You can certainly do WPF with C++/CLI, you just would not get to use XAML.

     

    If you wish to do a lot of your application in native C++, simply make .NET wrappers for your native code in the same dll using C++/CLI, then write the UI using WPF w/ C# and XAML.

     

    This approach has simplified a lot of applications for me when I needed the speed (or for any other technical reason) of C++ and the power of .NET

     

    I agree with Tim and the Doc, .NET is the way to go moving forward...but it would be nice to see Microsoft release some applications that eat their own dog food.  Flip3D, DWM, Magnifier, even Microsoft Max (you remember that), all use native [and private] C++ milcore calls.  How come they don't use .NET WPF like they make us?

     

    -Jer

     

    Tuesday, October 30, 2007 8:14 PM
  • Speaking as a developer who was on the Microsoft Max team, it most definately was written in C# and used WPF.  It did not use native C++ milcore calls.  There was a little C++ in Max, but much of that was managed C++.

     

    There are plenty of managed, WPF applications under development at Microsoft.  I'm writing code for one of them as we speak.

     

     - jcb

    Wednesday, October 31, 2007 12:21 AM
  • It wasn't my intention to question the virtues of .NET. As I said in my initial post I've written a mixed native/managed test application using C++/CLI and WPF and I'm very impressed with both. But, I see no reason why .NET would exclude the possibility of a native version of WPF.

     

    In fact MS has recently shifted strategy for Visual C++ towards native developments away from the earlier strong focus on .NET. This marked change came about after MS actually went out and asked customers what they wanted Visual C++ to be. Hopefully MS takes this strong cue to further strengthen native developments. The next logical step would be to supply WPF as a native C++ GUI package too.

     

    All arguments presented in this thread so far have been variations on the "I like managed so you cannot have native" theme. It's weak. It doesn't convince at all. Let WPF go native for the benefit of all those who, for whatever reason, want to develop Windows applications in standard native C++.

     

    Wednesday, October 31, 2007 10:24 AM
  • There isn't a snowball's chance in hell of there being a C++ version of WPF. Do you know how many man hours went into the managed version? It's unthinkable that there could be a justification for writing an entirely native version. Let's face it, there aren't many people doing C++ GUI layers these days compared to managed.

     

    Wednesday, October 31, 2007 1:12 PM
  • The specifications for XAML have been submitted to a standards body and Microsoft has actively encouraged other developers to implement independent compilers/parsers of XAML.  This sounds like an excellent opportunity for someone as motivated as you are to deliver such a framework.

    Wednesday, October 31, 2007 2:40 PM
  • @Tim Dawsson

     

    Yes I know it's too late to do anything about is. WPF is forever .NET only. If I want standard native C++ I have three options: either MFC, the Win APIs directly or some third-package like QT or wxWidgets. That's the way it is and will be.

     

    But it's a pity WPF is forever out of reach for native coders especially now that MS is less zealous about .NET. At least they're giving MFC a long overdue overhaul and a Vista update.

     

    @Jay Beavers

     

    How on earth did you come to the conclussion that I want XAML at all? Not even MS seems to want it badly enough to include it in Visual C++.

     

    ------

     

    Well, thanks everybody. I'll have to think carefully about whether to pursue the native/managed combination (using C++/CLI and WPF) or go for some of the native only options.

     

    And to all .NET affectionados I would like to say that don't forget .NET is built on native C++ so pray it won't ever go away. Smile

    Wednesday, October 31, 2007 6:05 PM
  • In a perfect world, it would be great to have both native and managed version of everything (well, in a *really* perfect world, there would be no hard distinction between using a native or managed API, but that's a different conversation <g>).  However, the reality is that we have to balance the investment required to do this kind of thing versus the customer benefits realized by doing it.  This cost/benefit analysis means that various teams will chose paths that they feel provides the maximal benefit for the cost.  A result of this process is that today we find that some APIs/libraries are managed only (like WPF or WinForms), some native only (like the Vista shell or Win32), and only a handful are both (like DirectX).

     

    I can't speak for all Microsoft teams, but speaking from Visual C++ team's standpoint, we talked to a lot of customers about the very question of how important it was for them to do WPF in C++.  We found that the overwhelming majority of customers were perfectly okay writing their WPF code in C# and creating an interop layer written in C++/CLI to hook this to their native C++ code.  I don't want to completely discount that important minority of customers that would much prefer to do this work in native C++, but in terms of priority it was pretty clear to us that there were other places we could invest our resources that would provide greater benefit to a greater portion of our user base.  To talk specifics, this decision freed up the resources necessary for us to invest in a substantial effort on our compiler front-end that will contribute to an amazing coding-time experience in the Visual Studio 10 timeframe.

     

    Hope that helps.

     

    Steve Teixeira
    Group Program Manager, VC++

    Wednesday, October 31, 2007 11:04 PM
  • @Steve Teixeira

     

    I would like to express what I think everybody feels namely that the C++/CLI technology is a marvelous engineering achievement. And I'm grateful to MS for making this effort to take on C++ on the .NET bandwaggon. It allows for a smooth combination of standard native C++ with managed .NET including WPF.

     

    So if C++/CLI gives me, at least functionally, what I was asking for then what's my beef? Let me express it this way; It would have been much better for the C++ language if there were a native WPF. When two large influential corporations like Sun and MS are combining efforts telling everybody managed is much better than native and that's the future then of course it has an impact. If this continuing coersion of programmers away from C++ continues then the risk is that when this new beautiful Visual C++ 10 arrives then there will be no programmers left to enjoy it.

     

    I'm exaggerating somewhat to get my point accross but I happen to think C++ is a much more flexible and versatile language than both Java and C# and its a pity the latter are getting the upper hand just because they were born on a managed runtime. Still I have to accept the state of affairs and I'm looking forward to the upcoming Visual C++.

     

    Thanks.

     

    Thursday, November 1, 2007 8:55 AM
  • Hi,

    Two thoughts came to my mind as I was reading this thread:

    1) If WPF had been written in unmanaged C++, we would still be waiting for it. The experience shows that writing managed code takes at least 30% less time than unmanaged code. The whole WPF development took about 6 years (I think), so 30% of 6 years is ~2 years. That would put the release of WPF around November 2008, one full year from now. That would mean no WPF, no .NET 3.0, no Surface, no Silverlight, no Popfly, no participation in Facebook, etc...

    2) The fact that C++ is a more versatile and flexible language than C# and Java is precisely why it is slowly but surely coming out of scope in modern development environments. As time goes by, and with Microsoft investing a lot in improving the performance of managed code, the trend is definitely towards safe code. C++ is just not safe enough.

    I agree with the Doc, unmanaged C++ development, MFC, Win32 is still here for a while, and obviously C+/CLI too. But the future is into safe code.

    It starts to sound too much like a "VB.NET vs C#" argument :-)

    Laurent
    Thursday, November 1, 2007 12:40 PM
  • @Laurent Bugnion

     

    You're assuming that .NET versus Native is a zero-sum game where any gain made by .NET is paid for by an equivalent loss for Native. Further you're assuming that .NET is inherently superior to Native in all situations under all circumstances with an end result of total dominance for .NET and Native gone extinct.

     

    I don't share this view and fortunately MS doesn't either. Many applications benefit greatly from .NET which will continue to grow but there will always be applications and situations where Native is better or even necessary. One such example is .NET itself which builds on Native.

     

    As I've already said I don't question the virtues of .NET and I realize MS must make trade-offs and that a cost-benefit analysis didn't favour a native version of WPF. And there's always the C++/CLI way to mix standard native C++ with .NET  including WPF.

     

    Thank you all for participating.

     

     

    Friday, November 2, 2007 5:24 PM
  •  

    " Let's face it, there aren't many people doing C++ GUI layers these days compared to managed. "

     

    Except, of course, the entire Windows development team and the entire Office development team...  and let's not forget Photoshop, Acrobat, and pretty much every other Windows app out there.

    Friday, November 2, 2007 6:20 PM
  •  Hoopskier wrote:

    Except, of course, the entire Windows development team and the entire Office development team...  and let's not forget Photoshop, Acrobat, and pretty much every other Windows app out there.

     

    That's just silly.  Clearly, Laurent was not talking about the continued development of legacy applications.  The products you listed, including the OS itself, are unmanaged because they pre-date the managed revolution.  They are the very reason that Win32 development will continue to live on.  (Microsoft has a track record that boggles the imagination when it comes to providing backward compatibility.)

     

    Few people are choosing to develop new applications from the ground up using the native Win32 api.  This is true inside Microsoft, Adobe, and pretty much every other dev shop out there.

     

    And although its true that the CLR (and consequently, managed technologies like WPF, WCF, etc) is actually built on top of Win32, that point is not really germaine.  By definition, a high-level platform builds upon the underlying low-level platform, so that those using it won't have to.

    Friday, November 2, 2007 9:14 PM
  • Hi UJ,

    You make me say a lot of things which I didn't. For the records, it's not OK for you to "assume what I am assuming". When you reply to posts I make, please stick to the facts of what I wrote, and don't try to imagine what I could be assuming.

    I most certainly don't think that .NET is superior to native "in all situations under all circumstances". I also don't think that native will go extinct in the next few years, even though I think that the differences will slowly fade out with time, as managed code gains maturity. I don't believe in extinction, rather in evolution.

    Now I am kind of curious what you'll make me say this time...

    Laurent
    Friday, November 2, 2007 9:23 PM
  • Lots of people bustin' chops in this thread.

     

    Can't we agree that .NET is tight and plays well with C++?  Can't we agree that WPF is the best UI framework in existance, but has some short commings in v1.0?  I admit, I whine (and can be annoying) about trying to voice things I'd like to see changed in the platform...and when that doesn't pan out, maybe I'll try sending gift baskets.

     

    Seems like everyone is arguing for the same side, but argue against each other over semantics.  Oh well, threads like these are a good way to pass the time until WPF v2.0.

     

    -Jer

    Saturday, November 3, 2007 5:43 AM
  • @Laurent Bugnion ("Now I am kind of curious what you'll make me say this time...")

     

    In your post you made predictions both about alternative pasts and possible futures. I'm not privvy to your crystal ball so I don't know if you're right or wrong. I refuse to go into a quarrel with you for example about whether a native WPF would had delayed development and it's only thanks to the qualities of .NET it's here on time. It cannot be decided.

     

    What I can do is draw your argumentation to its logical conclussion and then you end up in the position that .NET vs. Native is a zero-sum game with .NET as attractor. If not you end up in my position (and hopefully MSs), namely that .NET and Native are mutually beneficial with different strengths; No one is inherently better than the other and no one is replacing the other.

     

    Saturday, November 3, 2007 6:38 AM
  • @Dr. WPF ("By definition, a high-level platform builds upon the underlying low-level platform, so that those using it won't have to.")

     

    That's no argument in case. A native WPF would be as high-level as a managed WPF. But of course lacking a native alternative people will tend to flock around the WPF that exists.

     

    And if you consider C# to be higher level than C++ then it would be the case also if C# was native.

     

    The only principal quality managed code brings into the equation is the intermediate language. It can be used to enhance portability (as in the Java case) and it can be used to enhance language inter-operability (as in the .NET case). So the only thing "high-level" that originates in managed code is the ability to more easily mix C# and BASIC. (if you put it bluntly Smile)

     

    Saturday, November 3, 2007 7:40 AM
  • Hi,

    Again, no.

    That native development needs approximately 30% more time than managed development is not a "prediction", it's a value based on industry experience. We do managed code for approximately 6 years now, which is enough to measure (metrics) and to calculate (mathematics). No prediction here.

    I am *not* talking about managed taking over the native side. I am not sure why you keep wanting me to say this. Is it because you're afraid of it? There's nothing to be afraid of. What I am "predicting" (if you want) is the *convergence* of native and managed in direction of a common plaftorm for PC programming. As .NET code will evolve to become faster and the runtime become more and more available, we will have the best of both world.

    You shouldn't be afraid of this. Your skills as native code programmer will still be very much needed then. I see it as a chance: The best of native code (speed, small footprint) and the best of managed (safety, productivity).

    Jeremiah said:
    "Seems like everyone is arguing for the same side, but argue against each other over semantics"

    I totally agree.

    Greetings,
    Laurent
    Saturday, November 3, 2007 9:22 AM
  •  

    Code Block

     

    StringCchCopy( szMsgBuffer, dwSize,

        TEXT( "I am bored." ) );

     

    MessageBox( NULL,

        (LPCTSTR) szMsgBuffer,

        TEXT( "Re: Native WPF" ),

        MB_OK | MB_ICONEXCLAMATION );

     

     

     

    Saturday, November 3, 2007 9:37 AM
  • @Laurent Bugnion ("Again, no")

     

    I've been using Java since 1998 so I'm no stranger to managed code if that's what you think. In fact I've gone from C to Java to C++, so I've experienced the benefits of C++ after having learned the modern "safe" OO language that's Java.

     

    Where do you get this 30% estimate from? Is it a figure you've arrived at from your own experience or do you have some more formal generally accepted back-up for it?

     

    I would say that considering that both .NET and C# was in their infancy 2001 the decision to use it for the development of WPF probably induced a delay of about 100% so we could've had a native WPF already around 2004/5. It's my estimate and it's as good as yours. WPF then would've been another well tested Windows API that .NET could wrap and use now.

    Saturday, November 3, 2007 5:49 PM
  • @Dr. WPF ("I'm bored Re. Native WPF")

     

    Well it didn't exactly go your way did it? Smile. I drive a hard bargain and if you want to discuss with me you got sharpen up. Lazily going with the flow just won't cut it. You got to know what you're talking about.

     

    Saturday, November 3, 2007 5:59 PM
  •  uj wrote:

    Lazily going with the flow just won't cut it. You got to know what you're talking about.

     

    Now, at least, I'm amused.

    Saturday, November 3, 2007 9:23 PM
  •  uj. wrote:

    Where do you get this 30% estimate from? Is it a figure you've arrived at from your own experience or do you have some more formal generally accepted back-up for it?



    Just based on the 13 years of experience working in the firm employing the biggest number of .NET developers worldwide (and quite a good number of C++ and Java developers too). We do a lot of metrics here. Our managers love that kind of things.

    I swore to myself that if I had to work in C++ again, I would look for another job. I just don't have that time to lose. That's why I am really happy to read your posts. I need people like you in the staff to maintain our legacy code.

    And now, back to our regular programming. Good night.

    Laurent
    Saturday, November 3, 2007 9:39 PM
  • I stand by the original poster of this thread.  He's right, why on earth is there no standard entrance into WPF?  You know, many programs out there are cross-compiled for Mac, Linux, as well as Windows.  These codebases rely on macro code to compile across many platforms, and TOTALLY rely on the C/C++ language, because it's a standard across all OS's.  C# is obscured to one platform.  Mono in it's current state cannot play along.

    It is a much better methodology in many cases to use the multi-OS approach, as many developers currently use..  Barring these people off from the WPF only lessens the end user experience, as interfaces will be based upon old Win32 GDI code instead of newer technology.

    Is this what Microsoft really wants?  It seems like a closed, Apple approach to me.  It's no wonder that in it's current state, many developers are flocking to open source practices/libraries/languages as it can reach more users.  Microsoft really dropped the ball here.

    Kyle White
    Thursday, January 22, 2009 5:56 AM
  • ....

     

    .NET is the leading

    Thursday, April 29, 2010 2:18 AM
  • First, sorry for replying to this old post...

    Second, I won't speak about the native WPF, because everything is fine just the way it is... But I will speak about the native vs .net.

    Native will always exist whether you like it or not, because a lot of things still need the native environment, second I don't believe that .net or any other managed technology offers a real advantage in terms of coding to a native one. That is just in the head of the management, and some developers too. It may stop unexperienced developers from making mistakes, but them aren't we creating developers like we create vegetables in a green house? And most of all, are we creating developers for the quantity instead of the quality, that is what is was supposed to be?

    Also, there is a lot of new things that are developed in native form, because even if the development world has embraced the managed technologies and other things related (like functional languages, why the wreck would someone want that, unless you really don't have experience in one of them, and don't know the pain it is to program only with recursion... I still have nightmares when I think of it, the stack overflow of doom...), but the end-users don't know anything about this? And don't tell me that the end-users will install anything just because they are a) dumb, b) techno-lovers, c) the options a and b, because installing a framework just to run a simple application still doesn't sell to a end-user, especially a home based end-user.

    Monday, November 1, 2010 9:58 PM
  • I just came upon this old post (because I was trying to find out if you can use WPF to update a native application's C++ GUI using it) and just had to reply.  Someone said "2) The fact that C++ is a more versatile and flexible language than C# and Java is precisely why it is slowly but surely coming out of scope in modern development environments. As time goes by, and with Microsoft investing a lot in improving the performance of managed code, the trend is definitely towards safe code. C++ is just not safe enough."

    Is .NET the answer to all of your problems and will suddenly magically make all of your design or memory leak or references to deleted objects magical go away? Only the naive and people in marketing believe that.

    The ultimate truth, and this is timeless, is that any serious or large application requires careful design and thought and discipline.  Otherwise problems always manifest in some form, whether you are using .NET or native C++.

    If you write some small dinky application, then sure, it will be easier using Visual Studio Wizard and a few lines of .NET code. Five minutes and everyone is impressed.

    But do not think that .NET makes all your real life serious application problems magically disappear, only proper design and responsible coding does that,  .NET may hide some of your design and coding flaws for you for you but it only do so effectively in smaller or simple applications, and maybe that is not such a good thing. Trust me when you deal with large database objects that should automagically be cleaned up yet still eating up 2 GB of RAM, or when you get COM error codes when you use .NET addins in Excel and Microsoft tells you they have never seen that error code, well then.... Garbage management is nice, and it does work well, on a small scale.

    If Microsoft released a .NET version of Office then I shall reconsider my opinion. If the migration path is so smooth and backwards support so good and .NET so wonderful, why not? Open Office is written in Java. Is there some reason MS Office can't be written in .NET? And if it is because it is written in native code and predates the .NET "revolusion" well then all of Microsoft's big money earners (Windows, Office, SQL Server) are written in guess what... native C++. And most of the code out there in world? Yep, you guessed it. And we can migrate that code which will be around for many years just as non-easily as Microsoft can migrate MS Office to .NET....

    Monday, June 27, 2011 5:46 PM
  • Yes this would be nice. WPF is one of the coolest things in the .NET world. We have invested heavily in a native C++ / MFC data acquisition application and this cannot be turned into a C# / WPF application overnight. Also I do not agree that talented programmers can easily switch to C#/ WPF. Mastering a language/ library / framework takes years of experience. Also it is not attractive to make the presentation layer in WPF and the business layer in C++. There is many communication between those layers and the easiest is to pass the same data types (e.g. string, STL vectors etc.). it would be very expansive to use different languages here; only acceptable if there was little communication (which is not the case).

    • Edited by gast128 Thursday, June 16, 2016 3:42 PM
    Thursday, June 16, 2016 3:40 PM