Re: Why are .Net UIs slower than C++ or classic VB?
- From: "Cor Ligthert [MVP]" <notmyfirstname@xxxxxxxxx>
- Date: Wed, 3 May 2006 07:06:06 +0200
Carlos,
Almost from the first start of OS or DOS or Computer Management System
whatever names this kind of things have had (The first computers had no OS),
they have existed from layers. The reason for this is simple, by instance
hardware changes should not have to influence the overall system, which was
direct a problem after the first use of OS that did not exist from layers.
Therefore for me it is a very good approach that Net is one of those layers,
they would be crazy to change that.
Problem is maybe that the last 20 years a lot of people are sticked to
Microsoft Systems or other microprocessor driven systems and think that
those are the only ones and use the names of those and are not able to think
in wider use of computers.
Therefore in my opinion the Net should *not* replace the Win32 API, there
should come API's which have a high flexibility to interact with Net; Net
can than always be placed above those API's.
This cost of course time to see the results; you cannot get rid of Win32 in
some years. I never have had any attention to how WinFX is build; however I
assume that this normal way by creating a next generation OS will be the
case.
Just my thought,
Cor
"CMM" <cmm@xxxxxxxxxx> schreef in bericht
news:uFr78nkbGHA.1208@xxxxxxxxxxxxxxxxxxxxxxx
Well I doubt the kernel would be .NET ;-) .... but the .NET Framework
should completely replace the Win32 API. And, I mean COMPLETELY.... not
just a layer over it (that eventually calls down into Win32 for
everything) the way its implemented now.
--
-C. Moya
www.cmoya.com
"Jim Hubbard" <reply@xxxxxxxxxxxxx> wrote in message
news:ZuS5g.8746$QU3.5555@xxxxxxxxxxxxxxxxxxxxxxxxx
IF they ever did, it'd be interesting to see if they used .Net to write
it. I don't think they can. You can't write an OS in entirely managed
code - can you?
I'd love to see them put buffer overflow protection in the OS and keep
the OOP (class designs and the core classes) of .Net while tossing the
framework (i.e. IL code) idea. That should speed things up
significantly.
Anyway, if they did a complete rewrite (slimming it down and speeding it
up) it would definitely be something worth paying to upgrade to.
"CMM" <cmm@xxxxxxxxxx> wrote in message
news:%23UrNjQkbGHA.3348@xxxxxxxxxxxxxxxxxxxxxxx
Despite being a fan of .NET (from a programmer-- ease of development
standpoint) I tend to agree with almost everything you say. Windows is
due for a big rewrite a la MacOS X.... I doubt MS has the guts to do it.
--
-C. Moya
www.cmoya.com
"Jim Hubbard" <reply@xxxxxxxxxxxxx> wrote in message
news:ARK5g.8201$QU3.902@xxxxxxxxxxxxxxxxxxxxxxxxx
"Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xxxxxxxxx> wrote in
message news:xn0elqxcw6fhqt000@xxxxxxxxxxxxxxxxxxxxx
Jim Hubbard wrote:
I've noticed (for quite some time now) that .Net UIs are not as
responsive (see Franklin Covey's PlanPlus for Windows XP or
Symantec's .Net Norton Antivirus or even the .Net version of Paint
done by Washington University vs good old Paint UIs for examples).
They are also not as professional looking as the older applications
and the reaction times of the UIs is not professional looking at all.
Why do you think this is? Is it bad programming or is there
something else going on here?
Winforms is synchronically, and Win32, which it is based on, is
asynchronically. So, say you want to disable a button in .NET, you set
button.Enabled to false, right? Well, under the hood, a message is
send
to the button, and there's a delay when that's handled, the feedback
comes back that the message is handled and hte button is actually
disabled. This is a lot of overhead.
Yes it is.
It seems that Microsoft is simply adding layer upon layer to thier OS -
which would explain the OS bloat and ever-increasing system
requirements.
.Net is an answer to an OS problem anyway. The bufffer overflows that
.Net was meant to handle should be taken care of by the OS....not the
programming langauge and a runtime that lays on top of the OS.
Seems to me that Windows is long overdue for a complete rewrite from
the ground up.
Sure, this would mean breaking backwards compatability with some of the
older stuff, but they could include a personal copy of Virtual PC and
allow the user to run his/her old apps under the old OS while adopting
the new, slimmer, faster, more functional, Windows X and the new
programming that it allows.
For all the people who claim it's better in WPF: I'm sure it is, but
that's still a long time away and it doesn't help the people today.
It's been 5 (IMHO miserable) years with .Net. Nothing really to show
for the effort outside the enterprise (where competition is limited and
comtrols are very tight).
.Net (IMHO) just isn't cutting it as the tool that the COMMUNITY uses
to expand the OS (and that's what you need to build a great OS). It
never should have been written and forced upon us. The problems with
buffer overflows should have been fixed in the OS - then it wouldn't
matter what tool you chose to write your code in.
But......whatever.......
Jim
.
- References:
- Why are .Net UIs slower than C++ or classic VB?
- From: Jim Hubbard
- Re: Why are .Net UIs slower than C++ or classic VB?
- From: Frans Bouma [C# MVP]
- Re: Why are .Net UIs slower than C++ or classic VB?
- From: Jim Hubbard
- Re: Why are .Net UIs slower than C++ or classic VB?
- From: CMM
- Re: Why are .Net UIs slower than C++ or classic VB?
- From: Jim Hubbard
- Re: Why are .Net UIs slower than C++ or classic VB?
- From: CMM
- Why are .Net UIs slower than C++ or classic VB?
- Prev by Date: Re: Redirecting input/output existing console window
- Next by Date: RE: MSDTC error with TransactionScope
- Previous by thread: Re: Why are .Net UIs slower than C++ or classic VB?
- Next by thread: Re: Why are .Net UIs slower than C++ or classic VB?
- Index(es):
Relevant Pages
|
