Groups | Blog | Home
all groups > visual c > february 2006 >

visual c : Managed for all New Apps?


Greg
2/27/2006 7:41:27 PM
For all new desktop apps is managed/CLR recommended? I.e. Native MFC/Win32
not recommended in general for new desktop apps? Speaking in general, not
referring to exceptions (e.g. drivers)
--
Greg McPherran
Greg
2/27/2006 8:27:15 PM
[quoted text, click to view]
Even if it doesn't. with C++ you can also use native libraries as needed so
this has little/no impact on the decision.

[quoted text, click to view]
If .NET is considered the new recommendation (which is what I am originally
asking), what company is going to use an outdated old technology just because
people may need to come up to speed? Again, this has little/no impact.

[quoted text, click to view]
Again with C++ can use native as needed so again this is a NOP.

[quoted text, click to view]
Again, so a company is going to develop an app based on an outdated
technology instead of installing the freely available Framework!! The
framework can even be deployed with the install and auto-detect on install.
Again a NOP.

So, I'll repeat my original question. Is .NET recommended in general for new
desktop applications instead of MFC etc.?


--
Greg McPherran
www.McPherran.com


[quoted text, click to view]
Carl Daniel [VC++ MVP]
2/27/2006 9:16:34 PM
[quoted text, click to view]

Recommended by whom? I'm sure the C# team would recommend that. I'm not so
sure about the C++ team.

Seriously though, WinForms 2.0 alleviates many of the shortcomings of 1.x.
We're developing an end-user GUI application with Winforms and have no
significant performance issues that can be traced to the CLR. For many
apps, it's good enough. MFC is still better in terms of what you can
ultimately do and the performance you'll get, but most apps don't need to be
the very fastest or to have pixel by pixel control of their GUI appearance.

For some desktop apps, I'd go .NET, for others, I'd still go MFC (or WTL).

-cd

Don Kim
2/27/2006 9:17:38 PM
[quoted text, click to view]

Depends on the problem space. To create a quick UI to view data in a
local or remote database server, I'd recommend .net. Web services, yes.
For a video driver to output complex graphics in a video game or CAD
application, I'd go native C++/Win32/MFC.

But then again, this is in very general terms. As was posted by the
previous person, it also depends on the team or individual. If your
already highly productive with C++/Win32/MFC, then do that route. If
not, try .net, or even better, with C++/CLI, you can do the best of
both. :-)

Greg
2/27/2006 9:46:28 PM
[quoted text, click to view]

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_m/directx/directx9m.asp

The above link states that using managed DirectX improves perfomance because
it bypasses the COM layer.
Greg
2/27/2006 10:20:27 PM
Hi Will and Thank You,

[quoted text, click to view]
Is it recommended that an app be 95% native?

[quoted text, click to view]
So this is a definite maybe :-)

[quoted text, click to view]
No problem if your intelligent about it and minimize transitions i.e. not
chatty. Could still do a hefty recursive math algorithm in native that takes
5 seconds (FFT for example) whereas the interop could be a negligible 1ms or
less of the 5 seconds.

[quoted text, click to view]
No pun intended on the "managed"? :-)
If the company strategy calls for .NET, then IT should accommodate. If a
CEO/CTO lets IT dictate product development strategy, good luck to that
company staying in business.

[quoted text, click to view]
That's why I emphasize "in general". In general, is .NET Framework
recommended for new apps as opposed to MFC etc.? I don't get the impression
that Microsoft is promoting .NET for web apps only but that .NET is promoted
for desktop apps as well.
Greg
2/27/2006 10:37:28 PM
[quoted text, click to view]
Good point.

However, in this video the MS engineer responsible for Managed DirectX
states that the performance of Managed DirectX is only about 2% less than
native DirectX and indicates that the productivity benefits are significant.

http://msdn.microsoft.com/theshow/episode.aspx?xml=theshow/en/Episode037/manifest.xml
William DePalo [MVP VC++]
2/27/2006 11:03:54 PM
[quoted text, click to view]

Recommended for whom? On what platforms? Using what set of assumptions.

If the .Net platform provides everything one needs, if the skills of those
tasked with developing the new applications coincide with what is required,
if all of the target machines have the platform installed, if it provides
all of the performance necessary, it seems it would make sense to use it.

[quoted text, click to view]

I think that the world is far too complicated for this to be a binary
proposition - drivers C, applications C++/CLI.

Regards,
Will



Bruno van Dooren
2/27/2006 11:55:25 PM
[quoted text, click to view]

The CxO can say all he wants, but nothing gets done in large companies with
approval of IT.

If have witnessed gloabl communications breakdown in a fortune 500 company
because the US division upgrade their IBM notes servers to a slightly newer
version without running the normal procedures.
There was no incoming or outgoing email for 3 days. Afterwards there was
hell to pay.

even for large desktop software roll-out there is a testing phase,
verification phase a roll-out plan and a roll-back plan.

switching to .NEt may not be trivial. lots os mission critical stuff is
running on AS400, SUN, MIPS, mainframes...
It can take LOTS of time to analyse this.

For these companies the software is a means to an end. if .NET does not fit,
or it is too expensive to switch over you have to use native applications.
My point is made by the fact that there are still lots of large companies
using old mainframes and VAX machines running cobol or whatever.
So there is no 'general' answer to your question. it all depends on the
situation.

--

Kind regards,
Bruno.
bruno_nos_pam_van_dooren@hotmail.com
Remove only "_nos_pam"
William DePalo [MVP VC++]
2/28/2006 12:48:11 AM
[quoted text, click to view]

Huh? You mean if your application was divided, with say, 95% of it native
and 5% .Net that that that would have little impact on your decision? If so,
then we are talking more about religion than technology.

[quoted text, click to view]

Well, for technologies which succeed it is a matter of when to take the
plunge. As I see it, with Windows the tipping point came with the
introduction of version 3.1. We are only a couple of months past the
introduction of version 2 of the framework. Is now the right time? It
doesn't seem to me to be a foregone conclusion in every instance.

[quoted text, click to view]

Not so. The transitions have a measurable cost.

[quoted text, click to view]

Nope. It still depends. In a corporate environment desktops tend to be
managed. There, tens of megabytes do not get installed without _lots_ of
advance planning. And most users don't have the administrative privilege to
run dotnetfx.exe in any case.

[quoted text, click to view]

If you are waiting for a simplistic answer to a complicated issue you will
be waiting long after this thread dies.

Regards,
Will

William DePalo [MVP VC++]
2/28/2006 1:14:41 AM
[quoted text, click to view]

Improves performance over what?

Surely it improves performance over a solution built with .Net that uses
COM-callable wrappers or IJW to access the native API. But does it improve
performance over the native version? I think not.

In this article

http://msdn.microsoft.com/msdnmag/issues/03/07/DirectX90/

which introduced Managed DirectX a couple of years ago there is this:

<quote>
Managed Direct3D, part of the DirectX Graphics component of DirectX 9.0,
provides a great opportunity for developers targeting the .NET Framework to
add 3D capability to their applications. Not only is managed Direct3D nearly
as efficient as its unmanaged counterpart, but when used in conjunction with
the high-level shading language, it provides a great future for
high-performance RAD game development.
</quote>

And at this link

http://msdn.microsoft.com/msdnmag/issues/05/08/EndBracket/

you'll find this:

<quote>
It seems that at least twice a week, I am asked about poor performance in
Managed DirectX®. This frequency is actually a big improvement over the 5-10
times a week I was asked a few years ago when the technology first came out.
</quote>

The author goes on to explain that the poor performance has more to do with
the way in which the managed libraries were used than with inherent
slowness. And that reinforces the notion that matching a technology to the
skill set of the developers is important. Native DirectX has been around
longer and there is much more collective wisdom about it for others to read
than the newer technology.

Regards,
Will











William DePalo [MVP VC++]
2/28/2006 1:50:40 AM
[quoted text, click to view]

Exactly right on both counts.

Regards,
Will

William DePalo [MVP VC++]
2/28/2006 2:12:24 AM
[quoted text, click to view]

You are welcome.

[quoted text, click to view]

It is recommended that the implementation fit the task at hand. It is to
address so many classes of apllications that there are so many compilers in
VS.Net 2005.

[quoted text, click to view]

Right. I don't think that you will find a regular here, in or out of the big
house, who will presume to tell you that there is a single recommendation
for all classes of desktop applications today. If I am wrong about that, I
expect someone will say so shortly.

[quoted text, click to view]

No, I missed that.

[quoted text, click to view]

Of course.

But for the vast majority of companies, technology is not their main
business. Rather the technology is employed to achieve a business objective.
To the extent that a properly trained and competent developer can do more in
less time, transitioning from native to managed may well be the goal in many
enterprises. And if the volume of newsgroup posts is any indication, it
would seem that .Net development with C# has got a _lot_ of traction there.

[quoted text, click to view]

Your impression is correct. The framework includes far more than web-service
style applications support.

Regards,
Will

AddThis Social Bookmark Button