uj.

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



Re: Windows Presentation Foundation (WPF) Native WPF

Tim Dawson

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++.






Re: Windows Presentation Foundation (WPF) Native WPF

Dr. WPF

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.)






Re: Windows Presentation Foundation (WPF) Native WPF

Jeremiah Morrill

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





Re: Windows Presentation Foundation (WPF) Native WPF

Jay Beavers

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






Re: Windows Presentation Foundation (WPF) Native WPF

uj.

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++.





Re: Windows Presentation Foundation (WPF) Native WPF

Tim Dawson

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.






Re: Windows Presentation Foundation (WPF) Native WPF

Jay Beavers

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.






Re: Windows Presentation Foundation (WPF) Native WPF

uj.

@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





Re: Windows Presentation Foundation (WPF) Native WPF

Steve Teixeira - MSFT

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++





Re: Windows Presentation Foundation (WPF) Native WPF

uj.

@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.





Re: Windows Presentation Foundation (WPF) Native WPF

Laurent Bugnion

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





Re: Windows Presentation Foundation (WPF) Native WPF

uj.

@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.





Re: Windows Presentation Foundation (WPF) Native WPF

Hoopskier

" 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.





Re: Windows Presentation Foundation (WPF) Native WPF

Dr. WPF

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.