Managed for all New Apps?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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 said:
For all new desktop apps is managed/CLR recommended?

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.
I.e. Native MFC/Win32 not recommended in general for
new desktop apps? Speaking in general, not
referring to exceptions (e.g. drivers)

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

Regards,
Will
 
If the .Net platform provides everything one needs
Even if it doesn't. with C++ you can also use native libraries as needed so
this has little/no impact on the decision.
if the skills of those tasked with developing the new applications coincide with what is required
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.
if it provides all of the performance necessary
Again with C++ can use native as needed so again this is a NOP.
if all of the target machines have the platform installed
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 said:
So, I'll repeat my original question. Is .NET recommended in general
for new desktop applications instead of MFC etc.?

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
 
Greg said:
So, I'll repeat my original question. Is .NET recommended in general for new
desktop applications instead of MFC etc.?

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

-Don Kim
 
Don Kim said:
For a video driver to output complex graphics in a video game or CAD
application, I'd go native C++/Win32/MFC.

Carl Daniel said:
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.

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 said:
Even if it doesn't. with C++ you can also use native libraries as needed
so
this has little/no impact on the decision.

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

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.
Again with C++ can use native as needed so again this is a NOP.

Not so. The transitions have a measurable cost.
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.

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.
I'll repeat my original question. Is .NET recommended in general for new
desktop applications instead of MFC etc.?

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

Regards,
Will
 
Greg said:
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.

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
 
Hi Will and Thank You,
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?
Is it recommended that an app be 95% native?
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.
So this is a definite maybe :-)
Not so. The transitions have a measurable cost.
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.
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.
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.
If you are waiting for a simplistic answer to a complicated issue you will
be waiting long after this thread dies.
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 said:
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.

Exactly right on both counts.

Regards,
Will
 
Greg said:
Hi Will and Thank You,

You are welcome.
Is it recommended that an app be 95% native?

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.
So this is a definite maybe :-)

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.
No pun intended on the "managed"? :-)

No, I missed that.
If the company strategy calls for .NET, then IT should accommodate.

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

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

Regards,
Will
 
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.

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.
(e-mail address removed)
Remove only "_nos_pam"
 
Back
Top