Discussion:
What is the benefit to me of .NET as an end-user?
(too old to reply)
A Programmer
2006-02-26 07:38:05 UTC
Permalink
I think given the other thread, this might be an even better question.

Why do I need .NET as an end user, when my standard Windows stuff is
working just fine.

Especially if I have to download 23.2MB of software from Microsoft
just to be able to run anything someone cooks up with a .NET enabled
compiler?
Uffe Kousgaard
2006-02-26 07:58:11 UTC
Permalink
Post by A Programmer
Why do I need .NET as an end user, when my standard Windows stuff is
working just fine.
You need it because someone has created an application, that you want. Could
be because it is cheaper (faster development) than other alternatives or
because it is the only alternative.

Very simple in fact.

Regards
Uffe
Liz
2006-02-26 07:23:26 UTC
Permalink
Post by Uffe Kousgaard
You need it because someone has created an application, that you
want. Could be because it is cheaper (faster development) than other
alternatives or because it is the only alternative.
Ok, I ask in return how is it faster development?
--
Liz the Brit
Delphi things I have released: http://www.xcalibur.co.uk/DelphiThings
Uffe Kousgaard
2006-02-26 08:30:32 UTC
Permalink
Post by Liz
Ok, I ask in return how is it faster development?
As an end-user I don't have to care :-)

Let the market speak. If the .NET applications are cheaper than win32, then
something in the development phase must be cheaper.

Regards
Uffe
Liz
2006-02-26 08:52:13 UTC
Permalink
Post by Uffe Kousgaard
Let the market speak. If the .NET applications are cheaper than
win32, then something in the development phase must be cheaper.
No, it just means its projected market is bigger.
--
Liz the Brit
Delphi things I have released: http://www.xcalibur.co.uk/DelphiThings
Uffe Kousgaard
2006-02-26 11:36:15 UTC
Permalink
Post by Liz
No, it just means its projected market is bigger.
Do you mean a .NET application can run on platforms, where a win32 can't or

Some organizations turn down win32 application / prefer .NET applications?

Regards
Uffe
Lauchlan M
2006-02-26 16:03:16 UTC
Permalink
Post by Uffe Kousgaard
Post by Liz
No, it just means its projected market is bigger.
Do you mean a .NET application can run on platforms, where a win32 can't or
Some organizations turn down win32 application / prefer .NET applications?
I think she means there is a larger number of potential end-users.

She may have had markets for component developers in mind rather than
end-users though when forming her opinion - I can't see why the market for
.net end-users products is necessarily any bigger or smaller than for native
Windows users products.

Or, she may have felt that something in forthcoming MS OS's (eg security)
will be more friendly to .net applications and that, therefore, that's what
people will buy.

Lauchlan M
John Jacobson
2006-02-26 18:27:33 UTC
Permalink
Uffe Kousgaard <look_at_www.routeware.dk> wrote in message
Post by Uffe Kousgaard
If the .NET applications are cheaper than win32, then
something in the development phase must be cheaper.
Given that prices of software do not seem to be falling, that is obviously a
theoretical situation.
--
***Free Your Mind***

Posted with JSNewsreader Preview 0.9.4.2102
Lauchlan M
2006-02-26 08:29:30 UTC
Permalink
Post by Liz
Post by Uffe Kousgaard
You need it because someone has created an application, that you
want. Could be because it is cheaper (faster development) than other
alternatives or because it is the only alternative.
Ok, I ask in return how is it faster development?
Maybe (speculation):

* That particular developer has skills in .net (it's faster for them)?

* There are components available that suit the project?

* There are websites with examples, code templates, other resources that
facilitate the project?

* MS takes an interest in the particular project and provides help/advice?

* Management likes it (because it's MS) and authorises more resources for
the project (= more developers)

One could invent all sorts of hypothetical reasons to support the
hypothetical scenario that the development is faster in .net in at least
some cases

Lauchlan M
A Programmer
2006-02-26 08:32:55 UTC
Permalink
By using Delphi for Win32 I can be as cheap as the competition, but with
better results for the end user. Fantastic!
Yep. Back to the list of market motivations. A better product for
the user. And cheaper too, since they don't have to upgrade their
hardware!
A Programmer
2006-02-26 08:17:58 UTC
Permalink
On Sun, 26 Feb 2006 08:58:11 +0100, "Uffe Kousgaard"
Post by Uffe Kousgaard
You need it because someone has created an application, that you want. Could
be because it is cheaper (faster development) than other alternatives or
because it is the only alternative.
Then I could either forgo using the application or find a competitor
(and there will be one) that has a Win32 offering. Assuming they're
providing a similar quality product, of course.
Fritz Huber
2006-02-26 08:32:32 UTC
Permalink
Post by A Programmer
Then I could either forgo using the application or find a competitor
(and there will be one) that has a Win32 offering. Assuming they're
providing a similar quality product, of course.
By using Delphi for Win32 I can be as cheap as the competition, but with
better results for the end user. Fantastic!
Shawn B.
2006-02-26 08:28:16 UTC
Permalink
Post by A Programmer
Post by Uffe Kousgaard
You need it because someone has created an application, that you want. Could
be because it is cheaper (faster development) than other alternatives or
because it is the only alternative.
Then I could either forgo using the application or find a competitor
(and there will be one) that has a Win32 offering. Assuming they're
providing a similar quality product, of course.
I've never cared to make a distinction between the two. If someone offers
something useful, I don't really care what platform it targets (Win32, VCL,
.NET, Java, VB6, Etc.) so long as it works. If it requires a 20MB runtime,
who cares? Sooner or later, they'll have to download it anyway because as
more things target the runtime, chances are, they'll need it sooner or
later. You'll actually be doing them a favor since they'll have it when
they need it. Chances are, they may already have it... whether with base
Windows install or some other MS install that requires it or some other
competitor/software vendor that required it. Of course, if you are
targeting Win95, Win16, or Win98 (First Edition) then you'll have a problem
regarding .NET since it isn't supported on those platforms.


Thanks,
Shawn
Shawn B.
2006-02-26 07:54:42 UTC
Permalink
Post by A Programmer
I think given the other thread, this might be an even better question.
Why do I need .NET as an end user, when my standard Windows stuff is
working just fine.
Especially if I have to download 23.2MB of software from Microsoft
just to be able to run anything someone cooks up with a .NET enabled
compiler?
If you don't have a need to migrate, then there's probly no reason to.
However, a single code base written for .NET *should* work on any platform
that supports .NET: 32-Bit Windows, 64-bit Windows, Itanium Windows, WinCE,
Mono (with some restrictions regarding compatibility between Microsoft's
always up-to-date version and Mono's waiting-to-catch-up version).

Also, with .NET, you get all the functionality available in the framework to
use at your disposal; not unlike with the VCL, where you get everything
available with the VCL at your disposal, as well.

As an end user, I don't know if they truly care whether it is .NET or
Delphi/C++ 32/64-bit. The end users really just care that it works.
However, the platform can greatly influence the end-users experience. For
example, with .NET, you get plenty of security features for free (such
memory management, buffer-overrun protection, Code Access Security, etc.).
With Delphi Win32, at least, you can write lower-level code, such as the
SANDRA PC benchmarking utility or the SpyBot Search & Destroy tool (both
written in Delphi I believe, at least they look it)... that would be more
difficult with .NET.

Of course, don't forget, all the new Microsoft vector user interfaces and
application framework will only be available through .NET API's and not to
native C++ programmers. If the user demands those types of interfaces, then
you'll have no choice.

It will still be possible to hybrid develop, but P/Invoke comes with a
performance penalty.

In short, its mostly a developers decision more than the End User, unless
.NET or VCL offers something the other doesn't, that the user demands, then
it is certainly up to the end user.


Thanks,
Shawn
Jim Cooper
2006-02-26 11:05:45 UTC
Permalink
Post by Shawn B.
However, a single code base written for .NET *should* work on any platform
that supports .NET: <snip> WinCE,
Not on this one. It is a bad idea to even think that you should run the same
code on a small device. You might be able to share a certain amount of code, but
you should redesign the app.

Cheers,
Jim Cooper

_____________________________________________

Jim Cooper ***@tabdee.ltd.uk
Skype : jim.cooper
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
_____________________________________________
John Jacobson
2006-02-26 18:37:55 UTC
Permalink
Post by Shawn B.
It will still be possible to hybrid develop, but P/Invoke comes with a
performance penalty.
What about C++/CLI?
--
***Free Your Mind***

Posted with JSNewsreader Preview 0.9.4.2102
A Programmer
2006-02-26 08:26:56 UTC
Permalink
Actually I don't even think that the disk requirement is that bad thing. I
find the performance hit to be much worse. As an end user of Visual C++ for
exaple I find the delays that occur in 2005 hardly bearable (1GB RAM, 3GHz).
We even created a new term for it - the infamous WHITE SCREEN.
I think we have finally arrived at a point where Windows app feel as
"snappy" as Java apps. No difference anymore.
Actually having never observed a .NET app in action, this is a very
interesting thing to know. Yet another strike against it.

I knew people cast performance considerations out the window long ago
(pioneered by Microsoft) to force obsolescence in the computer
hardware market as well, but MAN!

I mentioned the disk requirement for having to go to the trouble to
download that much, which is necessary for Windows ME, and even XP
(Vista is the first Windows that will have it installed with the OS).
And nevermind if we're talking about 1.1 or 2.0 apps - if I have to
run both, with patches, this download requirement goes up to 80MB. Do
I want to put the user to the trouble of doing that? And what of
those on dial-up? I hate it when programs make Internet-tethers for
themselves. I hate it even more when there's huge barriers for entry
in place for a piece of software.

Then again I don't get it either - this has been a pattern of the last
10 years for Microsoft to convince people to do things that are not of
their benefit with their own computers ("Product Activation" being the
latest example).
Shawn B.
2006-02-26 08:53:08 UTC
Permalink
Post by A Programmer
Actually I don't even think that the disk requirement is that bad thing. I
find the performance hit to be much worse. As an end user of Visual C++ for
exaple I find the delays that occur in 2005 hardly bearable (1GB RAM, 3GHz).
We even created a new term for it - the infamous WHITE SCREEN.
If you're talking about the IDE, perhaps there are issues. But with the
actual application produced, I have not noticed any problems with
performance. Granted, I'm not doing heavy numerical crunching or something
that would normally be done in C++ anyway due to extreme performance
concerns. I do, however, write software for insurance company's (C#,
VB.NET, ASP.NET) and we get well over 5 million transactions a day between
all our customers (from the user directly). Of course, we have data centers
and proper load-balancing and clustering and such... but we are not even
operating at 60% of peak. We have had "hickups" using .NET, but nothing
that proper "architecture" hasn't cured. This is just the application side
of our product, on the WebService side and other services that process our
Message Queues and do Batch printing and other types of heavy financial
cruching (I'm responsible for the accounting module), we'll process tens of
millions of transactions (without user intervention) and gigs of XML files
that equate information to be acted upon in some way without even breaking a
sweat.

.NET as a platform has my full trust. The IDE's, I agree, can be really
crappy. But that doesn't mean what they produce is equally as crappy.
Post by A Programmer
I think we have finally arrived at a point where Windows app feel as
"snappy" as Java apps. No difference anymore.
I'd like to respectfully dissagree. My experiences with the .NET IDE's may
be as "snappy" as Esclipse and JBuilder at times, but what they produce, is
of exceptional performance and quality (provided the applications where
designed an implemented soundly). I've never done video codecs or numerical
processing so I can't comment on those uses. I am responsible for an
accounting system that calculates billions on the ledger and year-end
financial data without even breaking a sweat.
Post by A Programmer
Actually having never observed a .NET app in action, this is a very
interesting thing to know. Yet another strike against it.
I don't see any strikes. I've witnessed many Java and .NET applications in
action and I'd say both can perform well and both can suck. My direct
experience with .NET (having worked with it exclusively for the past 5
years) has been nothing less than exhilerating. Sure, C++ can do better,
but when we process over 5 million user transaction per day and over 20
million a day on the back-end services brokers without even breaking a
sweat, very little problems, reliable up-time and so on, I can hardly have
any complaints.
Post by A Programmer
I knew people cast performance considerations out the window long ago
(pioneered by Microsoft) to force obsolescence in the computer
hardware market as well, but MAN!
I mentioned the disk requirement for having to go to the trouble to
download that much, which is necessary for Windows ME, and even XP
(Vista is the first Windows that will have it installed with the OS).
I agree. This is a problem but it isn't going to get any better, not on the
*nix or *dows platforms.
Post by A Programmer
And nevermind if we're talking about 1.1 or 2.0 apps - if I have to
run both, with patches, this download requirement goes up to 80MB. Do
I want to put the user to the trouble of doing that? And what of
those on dial-up? I hate it when programs make Internet-tethers for
Well, the way I see it, sooner or later they will need to download or
install the runtime anyway. Whether for your application or some other. If
they encounter something that requires it than they only choice they have is
to download/install the runtimes or avoid the application. Hopefully, they
will already have it because of some other reason. If they don't, then you
are doing them a favor, IMO.

For those using Dialup, it's a problem indeed. But oh well. The times are
changing, perhaps they should, too.
Post by A Programmer
themselves. I hate it even more when there's huge barriers for entry
in place for a piece of software.
Agreed.
Post by A Programmer
Then again I don't get it either - this has been a pattern of the last
10 years for Microsoft to convince people to do things that are not of
their benefit with their own computers ("Product Activation" being the
latest example).
I'm certainly a Microsoft fanboy. I make a six-figure income working with
their tools developing for their platform. My wife does, too. They have
good technology. It is a joy to work with and the .NET platform is a joy to
work with (most of the time). I will agree, they have this sick compulsion
to have their hands in everything. In many cases, it takes the fun out it.
I'd like to be creative, too, you know; as do others. But they indeed do
many things that are not in the best interest of others. But then, in the
long run, it could very well turn out to be a very good thing.

Ditching VB6 in favor of VB.NET, IMO, wasn't an evil crime that many made it
out to be. I was one of those VB.NET'ers that updated his skills to be
cutting edge. Of course, I've since migrated to C#... but... what was evil
was to just ditch COM in favor of .NET overnight. Although, .NET is the
perfection of their dream for what COM was meant to be and is a natural step
forward, although completely incompatible. Some call it evil, I call it
"progress". The impression I get, after them abandoning GDI for GDI+
(promised to be hardeware accelerated but only software implemented in th
end) then dropping it for Avalon (WPF), then spending more effort on smart
clients than ASP.NET after ASP.NET was harolded to be the savior of our
problems, among other things, leads me to believe they'll change their mind
with or without our concent and that is what scares me. It's hard to trust
them, but in the meantime, what do I really care? I'm on top of things,
change when they do, and find constant employment implementing the
technologies people pay me to do, which is often the most cutting-edge of
the month thing.

Product Activation really sucks. I hate it with a passion. For more
reasons than I care to list on this thread. I pay for my software and hate
Activation all the more because of that. I'm not a thief. But it's life.
Maya, SoftImage, Rational products, Adobe, they all do it. It's a glimpse
of the future. I tend to avoid using software that treats me that way when
there's an option. With MS, I don't have the option, not if I want to
continue being useful to my employers, since I do more learning at home than
at work. With Adobe, there isn't a suitable competitor that I'm happy with.
But with most others, I can do without or there is a suitable competitor
that does not treat me like a thief. I spend less money on software these
days and more money on my realestate and gold investments. I'm almost to
the point where I don't need to work to earn the same income that I get paid
full time. I will take advantage of that when the time comes. But MS
helped me get there, despite all of its evils.


Thanks,
Shawn
JEM
2006-02-26 15:52:53 UTC
Permalink
Post by Shawn B.
For those using Dialup, it's a problem indeed. But oh well. The times are
changing, perhaps they should, too.
Did you ever consider that perhaps they can't?

Not everyone has access to high-speed..last I looked,
approximately 40% did not.
Jon Robertson
2006-02-26 07:53:56 UTC
Permalink
Post by A Programmer
Actually having never observed a .NET app in action, this is a very
interesting thing to know. Yet another strike against it.
There were several demo apps with Win32 and .NET versions in the D2005
examples that DevRel put together. I tried most of them at the time
(.NET 1.0). The .NET versions were *significantly* slower.

Now, I haven't seen anything in .NET 2.0. I know the SQL Server team
had a lot of requirements for .NET 2.0, which was a major reason for
the delay of both products. I would assume .NET 2.0 apps are faster
than equivalent .NET 1.0 apps on the same hardware.
--
Jon Robertson
Borland Certified Advanced Delphi 7 Developer
MedEvolve, Inc
http://www.medevolve.com
Shawn B.
2006-02-26 09:37:44 UTC
Permalink
Post by Jon Robertson
There were several demo apps with Win32 and .NET versions in the D2005
examples that DevRel put together. I tried most of them at the time
(.NET 1.0). The .NET versions were *significantly* slower.
There are many reasons I've seen for NET applications to be slower, even
those used as examples of best-practices. I haven't seen the ones you are
referring to above so I'm not talking specifically about those.

There are many factors why it would be *significantly* slower: concatonating
strings instead of using stringbuilder. Using custom data-types instead of
native types (custom data types are forced to always use a static method to
return a new instance of the type for each operator used upon it in an
expression), bad design/architecture, creating instances of objects in an
inner-loop instead of one instance outside the loop, trying to "outsmart"
the JITer (can sometimes make things worse), try...catch...finally abundance
in loops, catching exceptions rather than accounting for them in advance,
recreating the wheel when something built-in can do the job better... etc.
There are so many reasons. Not to mention, all .NET apps are (by default)
stored as IL and will be compiled each time the application is executed.
That can make it appear slow if there are lots of code paths. Perhaps the
applications are parsing XML or config files too much when doing so once and
caching the results would do just fine.

Everytime someone has pointed to me a slow .NET application I have been able
to (when I tried) make changes to improve performance significantly.

The .NET apps you refer to, are the VCL.NET apps? Perhaps VCL.NET (never
used it) itself is the culprit here.

Just offering suggestions to some common problems.
Post by Jon Robertson
Now, I haven't seen anything in .NET 2.0. I know the SQL Server team
had a lot of requirements for .NET 2.0, which was a major reason for
the delay of both products. I would assume .NET 2.0 apps are faster
than equivalent .NET 1.0 apps on the same hardware.
Yes, it is much better in so many ways. 1.x is a dinosour by comparison.


Thanks,
Shawn
Ramona van Riet
2006-02-26 09:03:45 UTC
Permalink
Post by Jon Robertson
Post by A Programmer
Actually having never observed a .NET app in action, this is a very
interesting thing to know. Yet another strike against it.
There were several demo apps with Win32 and .NET versions in the D2005
examples that DevRel put together. I tried most of them at the time
(.NET 1.0). The .NET versions were significantly slower.
Doesn't Delphi 2005 use version 1.1?
--
Ramona
Shawn B.
2006-02-26 09:29:55 UTC
Permalink
Post by A Programmer
I think we have finally arrived at a point where Windows app feel as
"snappy" as Java apps. No difference anymore.
Actually having never observed a .NET app in action, this is a very
interesting thing to know. Yet another strike against it.
I knew people cast performance considerations out the window long ago
(pioneered by Microsoft) to force obsolescence in the computer
hardware market as well, but MAN!
Upon further reflection (since my previous reply on this post) I can see how
people would think that. First, .NET applications are stored as IL code.
Each time they are executed, the first time a function in the application is
encountered it will be compiled to native code then executed. If there is
some intense code-paths then it can take a while. Next, if there are lots
of assemblies, they all need to be loaded and then rebased. 3rd, I've seen
many applications produced as an example of "architecture" best-practices
that really don't have a clue. Those do more harm than good.

I recently was assigned the task of speeding up a .NET application that
processes 100MB XML files and then acts upon them in some way in our system.
It was taking 45 minutes to parse the XML files along, not included the 18
minutes to act upon the XML, all the while consuming 100% of the CPU. We
had to process thousands of these files each night. Ouch. It was written
in VB.

After a few days, we were able to change our approach to how we parse the
XML and work with the results internally. We rewrote the logic in C# and
now it takes only 17.8 (average) seconds to process the XML and 7 seconds to
act upon it, all the while consuming less than 10% of the CPU. I'm sure
that C++ could do it better, but there comes a point when "good enough is
good enough". I won't blame the languages in this case, it was clearly the
architecture and approach taken to solve the problem... none-the-less, the
results were excellent.


Thanks,
Shawn
John Jacobson
2006-02-26 18:11:28 UTC
Permalink
Post by Shawn B.
I won't blame the languages in this case, it was clearly the
architecture and approach taken to solve the problem...
That is almost always the case. That is why I have to laugh when I read people
saying that .NET and/or C# will result in significantly better (or worse)
programs. The quality of the programs is primarily a function of programmer
skill, not the tool, framework or language used.

Until programmers are almost as good as they can be, it is futile and
unnecessarily expensive to keep changing languages and frameworks the way the
industry has been doing it.
--
***Free Your Mind***

Posted with JSNewsreader Preview 0.9.4.2102
Jim Cooper
2006-02-26 18:30:17 UTC
Permalink
Post by John Jacobson
Until programmers are almost as good as they can be, it is futile and
unnecessarily expensive to keep changing languages and frameworks the way the
industry has been doing it.
Back to ones and zeroes for you then.

Of course languages and frameworks make a difference. They don't necessarily
make a huge (eg order of magnitude) difference, but then we've all known that
since Fred Brooks wrote "No Silver Bullet", haven't we?


Cheers,
Jim Cooper

_____________________________________________

Jim Cooper ***@tabdee.ltd.uk
Skype : jim.cooper
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
_____________________________________________
Jim Cooper
2006-02-26 18:47:34 UTC
Permalink
Really? Show me some real evidence to support that claim.
You really need evidence? You don't think using Delphi lets pretty much anybody
write faster and cleaner apps than using C++ and MFC? Or using assembler? Or
using toggle switches?

Such studies have been done, if you really want to spend time looking for them.
I'm not going to waste time doing it though.

Cheers,
Jim Cooper

_____________________________________________

Jim Cooper ***@tabdee.ltd.uk
Skype : jim.cooper
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
_____________________________________________
John Jacobson
2006-02-26 18:42:41 UTC
Permalink
Post by Jim Cooper
Of course languages and frameworks make a difference.
Really? Show me some real evidence to support that claim.
--
***Free Your Mind***

Posted with JSNewsreader Preview 0.9.4.2102
Bob Dawson
2006-02-26 20:51:08 UTC
Permalink
Really? Show me some real evidence to support that claim.
So I take it the VCL offers you no benefits, and you don't use it?

bobD
Bob Dawson
2006-02-26 20:24:36 UTC
Permalink
Post by John Jacobson
The quality of the programs is primarily a function of programmer
skill, not the tool, framework or language used.
Your claim reduces to "All other things being equal, a more highly skilled
programmer will produce better programs."

While true, that doesn't exclude the orthogonal proposition that "Skill
being equal, the programmer with better tools and techniques will produce
better programs."
Post by John Jacobson
Until programmers are almost as good as they can be, it is futile ...
What's futile is waiting on human perfection. Given your knowledge of
history, would you say it's more likely for better tools to come along, or
better programmers?

Technical churn for its own sake is bad, and may happen all too often.
That's no reason, however, not to move to a better technology whenever it's
advantageous to do so. I'm not going to demand that I attain enlightenment
as a master programmer before buying myself better tools. If I did that I'd
still be using GWBasic on CP/M.

bobD
Fritz Huber
2006-02-26 08:27:41 UTC
Permalink
Post by A Programmer
Why do I need .NET as an end user, when my standard Windows stuff is
working just fine.
Especially if I have to download 23.2MB of software from Microsoft
just to be able to run anything someone cooks up with a .NET enabled
compiler?
Ahem - NONE ???
Actually I don't even think that the disk requirement is that bad thing. I
find the performance hit to be much worse. As an end user of Visual C++ for
exaple I find the delays that occur in 2005 hardly bearable (1GB RAM, 3GHz).
We even created a new term for it - the infamous WHITE SCREEN.

I think we have finally arrived at a point where Windows app feel as
"snappy" as Java apps. No difference anymore.
AnnShip
2006-02-26 08:42:28 UTC
Permalink
Aha, The proof will be when Microsoft releases Microsoft Office .NET
Edition, Microsoft Access .NET and Microsoft PowerPoint .NET.
Eat your own medicine first. Then, I will follow. Probably it will
be easier and hopefully less bulky (less DLL). And , finally all the
device driver and PnP hardware that requires .NET to run. Or wait
until Delphi becomes truly 64Bit , the only RAD native compiler available.
Post by Fritz Huber
Post by A Programmer
Why do I need .NET as an end user, when my standard Windows stuff is
working just fine.
Especially if I have to download 23.2MB of software from Microsoft
just to be able to run anything someone cooks up with a .NET enabled
compiler?
Ahem - NONE ???
Actually I don't even think that the disk requirement is that bad thing. I
find the performance hit to be much worse. As an end user of Visual C++
for exaple I find the delays that occur in 2005 hardly bearable (1GB RAM,
3GHz). We even created a new term for it - the infamous WHITE SCREEN.
I think we have finally arrived at a point where Windows app feel as
"snappy" as Java apps. No difference anymore.
A Programmer
2006-02-26 09:02:03 UTC
Permalink
Post by AnnShip
Aha, The proof will be when Microsoft releases Microsoft Office .NET
Edition, Microsoft Access .NET and Microsoft PowerPoint .NET.
Eat your own medicine first. Then, I will follow. Probably it will
be easier and hopefully less bulky (less DLL). And , finally all the
device driver and PnP hardware that requires .NET to run. Or wait
until Delphi becomes truly 64Bit , the only RAD native compiler available.
Thanks for reminding me of this. Exactly! Why does Microsoft think
their flagship office product isn't good enough for the .NET
bandwagon?

You jump first Billy Boy.
Shawn B.
2006-02-26 09:10:54 UTC
Permalink
Post by A Programmer
Post by AnnShip
Aha, The proof will be when Microsoft releases Microsoft Office .NET
Edition, Microsoft Access .NET and Microsoft PowerPoint .NET.
Eat your own medicine first. Then, I will follow. Probably it will
be easier and hopefully less bulky (less DLL). And , finally all the
device driver and PnP hardware that requires .NET to run. Or wait
until Delphi becomes truly 64Bit , the only RAD native compiler available.
Thanks for reminding me of this. Exactly! Why does Microsoft think
their flagship office product isn't good enough for the .NET
bandwagon?
You jump first Billy Boy.
Probly because Office products are 15 years old and have an intense
investment in them and are huge code bases that cannot just be converted
overnight, or even in 5 years time, appearantly... and because they want
them to work on platforms that don't support .NET. They are slowly
converting them over. I suspect it is why they are so big on having a
C++/CLI so they can retain most of ther C/C++ code to make it easier to do
the port. They'll end up introducing new bugs that were long ago corrected.

Oh wait, the same reasons that there are so many companies that haven't
migrated yet, also. Of course, most of MS's new things are/will be in .NET.
Even where I work, we do have some VB6/ASP code that hasn't been migrated in
3 years time because it works and its easier to maintain it. All the new
stuff since 3 1/2 years ago is purely done in .NET (which accounts for about
80% of the application these days). We have a staff of over 20 full-time
programmers, too. Its just not a priority. Although, we are converting it
little-by-little as we have time and the need. But overall, I suspect,
Microsoft is in the same boat.

Thanks,
Shawn
JEM
2006-02-26 15:55:51 UTC
Permalink
Post by Shawn B.
Oh wait, the same reasons that there are so many companies that haven't
migrated yet, also.
"So many companies" are not the ones that wrote the .NET framework.

Faith in ones' own products goes a long way in convincing others..
Jim Cooper
2006-02-26 18:06:39 UTC
Permalink
Post by JEM
Faith in ones' own products goes a long way in convincing others..
Which is why MS write so much .NET code.

The argument that they should rewrite Office in .NET to prove a point is stupid.
There is no business case for doing that at all.


Cheers,
Jim Cooper

_____________________________________________

Jim Cooper ***@tabdee.ltd.uk
Skype : jim.cooper
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
_____________________________________________
Liz
2006-02-26 08:54:37 UTC
Permalink
Post by AnnShip
Aha, The proof will be when Microsoft releases Microsoft Office .NET
Edition, Microsoft Access .NET and Microsoft PowerPoint .NET. Eat
your own medicine first. Then, I will follow. Probably it will be
easier and hopefully less bulky (less DLL). And , finally all the
device driver and PnP hardware that requires .NET to run. Or wait
until Delphi becomes truly 64Bit , the only RAD native compiler available.
and its truely .net and not some lame effort with a couple of bits
using .net
--
Liz the Brit
Delphi things I have released: http://www.xcalibur.co.uk/DelphiThings
Jim Cooper
2006-02-26 10:58:03 UTC
Permalink
Post by AnnShip
Aha, The proof will be when Microsoft releases Microsoft Office .NET
Edition, Microsoft Access .NET and Microsoft PowerPoint .NET.
Why do people keep insisting on this incredibly stupid point?



Cheers,
Jim Cooper

_____________________________________________

Jim Cooper ***@tabdee.ltd.uk
Skype : jim.cooper
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
_____________________________________________
Oliver Townshend
2006-02-26 11:10:17 UTC
Permalink
Post by Jim Cooper
Why do people keep insisting on this incredibly stupid point?
Maybe if you properly rebutted it rather than posting something that the
rest of us will ignore?

Oliver Townshend
Jim Cooper
2006-02-26 13:13:10 UTC
Permalink
Post by Oliver Townshend
Maybe if you properly rebutted it rather than posting something that the
rest of us will ignore?
It has been rebutted dozens of times previously. Sometimes even by MS people.

It is a self-evidently silly point in any case.


Cheers,
Jim Cooper

_____________________________________________

Jim Cooper ***@tabdee.ltd.uk
Skype : jim.cooper
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
_____________________________________________
Liz
2006-02-26 08:53:55 UTC
Permalink
Actually I don't even think that the disk requirement is that bad
thing. I find the performance hit to be much worse. As an end user of
Visual C++ for exaple I find the delays that occur in 2005 hardly
bearable (1GB RAM, 3GHz). We even created a new term for it - the
infamous WHITE SCREEN.
Usually this delay is the first time its run, subsequent runs are much
better, but yes, I dont like .net for this reason, I want it to run
when I run it, not a bit later when it feels like it
--
Liz the Brit
Delphi things I have released: http://www.xcalibur.co.uk/DelphiThings
Shawn B.
2006-02-26 10:07:36 UTC
Permalink
Post by Liz
Usually this delay is the first time its run, subsequent runs are much
better, but yes, I dont like .net for this reason, I want it to run
when I run it, not a bit later when it feels like it
Have you used NGEN? Applications that have been NGEN'd will already be
compiled to native code (for the processor it was NGEN'd on) by the time it
is executed. That doesn't mean much if you NGEN it when it is installed to
the computer, rather than NGENing it and then deploying it. NGEN doesn't
work on ASP.NET assemblies, however.

With 2.0, NGEN is significantly improved and the ASP.NET compile features as
much better.

Thanks,
Shawn
Fritz Huber
2006-02-26 10:36:59 UTC
Permalink
Post by Shawn B.
Have you used NGEN? Applications that have been NGEN'd will already be
compiled to native code (for the processor it was NGEN'd on) by the time
it is executed. That doesn't mean much if you NGEN it when it is
installed to the computer, rather than NGENing it and then deploying it.
NGEN doesn't work on ASP.NET assemblies, however.
With 2.0, NGEN is significantly improved and the ASP.NET compile features
as much better.
Thanks for the reminder. Haven't used it yet, but will try. I'm wondering if
the delays I'm experiencing with VS2005 are due to jitting or gc-ing.
Shawn B.
2006-02-26 20:25:17 UTC
Permalink
Post by Fritz Huber
Post by Shawn B.
Have you used NGEN? Applications that have been NGEN'd will already be
compiled to native code (for the processor it was NGEN'd on) by the time
it is executed. That doesn't mean much if you NGEN it when it is
installed to the computer, rather than NGENing it and then deploying it.
NGEN doesn't work on ASP.NET assemblies, however.
I said this backwards... I meant "that doesn't mean much *unless* you NGEN
it when it is installed to the computer, rather than NGENing it and then
deploying it." Most 3rd party components and some .NET applications, when
the installation program installs them, willl be NGEN'd so they aren't the
source of any initialization performanc penalty's. When the .NET Framework
SDK/Runtime is installed it gets NGEN'd, also. According to MS, the
JIT/NGEN compiler (same thing according to them) considers your hardware
(AMD vs. Pentium vs. Pentium 4 vs. Itanium) when it compiles.
Post by Fritz Huber
Post by Shawn B.
With 2.0, NGEN is significantly improved and the ASP.NET compile features
as much better.
Thanks for the reminder. Haven't used it yet, but will try. I'm wondering
if the delays I'm experiencing with VS2005 are due to jitting or gc-ing.
Could be. I think the IDE is mostly unmanaged C++, though... I've been in
discussions with the IDE team programmers in the past and that's what they
say. But, the IDE also hosts a fair amount of managed assemblies. The
WinForms designer and ASP.NET designer, as I understand it, are .NET
programs themselves, among other things. There is probly a lot of bad code
internally that is still being worked out. I remember the 2002 IDE was a
memory hog and slow and full of problems. The 2003 IDE improved peformance
and memory management significantly. Probly the same will happen with the
2005 vs. 2005.SP1 IDE.

Thanks,
Shawn
Liz
2006-02-26 10:36:44 UTC
Permalink
Post by Shawn B.
Have you used NGEN? Applications that have been NGEN'd will already
be compiled to native code (for the processor it was NGEN'd on) by
the time it is executed. That doesn't mean much if you NGEN it when
it is installed to the computer, rather than NGENing it and then
deploying it. NGEN doesn't work on ASP.NET assemblies, however.
Nice, but surely half the point of .net was like java in that it was
dealt with by the end computer to make it most efficient for it by
doing part of the compiliation process..

I understand this needs time, however, much like java, somehow many
.net apps just never get the speed of a win32 app. With the speed of
computers today, I dont want to have that loss.
--
Liz the Brit
Delphi things I have released: http://www.xcalibur.co.uk/DelphiThings
Ramona van Riet
2006-02-26 09:02:20 UTC
Permalink
Actually I don't even think that the disk requirement is that bad
thing. I find the performance hit to be much worse. As an end user of
Visual C++ for exaple I find the delays that occur in 2005 hardly
bearable (1GB RAM, 3GHz). We even created a new term for it - the
infamous WHITE SCREEN.
I thought the Delphi 2005 IDE was written in plain Win32, and it only
hosts .net for some features, like the .net designers and refactoring?

If that is true, it would defeat your argument.
--
Ramona
I.P. Nichols
2006-02-26 09:08:33 UTC
Permalink
Post by A Programmer
I think given the other thread, this might be an even better question.
Why do I need .NET as an end user, when my standard Windows stuff is
working just fine.
Especially if I have to download 23.2MB of software from Microsoft
just to be able to run anything someone cooks up with a .NET enabled
compiler?
If you are old enough then you will remember this same discussion taking
place when those mean old folks at Microsoft started telling everyone that
Windows was the wave of the future and people were shouting back, "Why do I
need Windows, my DOS stuff is working just fine".

So why bother with .NET, all us clever folks know that users will reject it
and in the end Microsoft will have again failed to cram their technology
down our throats.

OTOH that POV may be pure poppycock. You may be interested in this part of a
message recently posted here. Seems like a lot of folks are being hired as
.NET Developers.

------------------------
http://www.cio.com/blog_view.html?CID=17512
"The Yoh Index is assembled using data from over 5,000 technology
professionals
outsourced on short- and long-term projects by more than 1,000 employers in
a
number of industries including engineering, IT, manufacturing and
telecommunications, ExtremeTech said."

According to ExtremeTech, here's a list of Yoh's top ten tech positions with
the
highest employer demand in Q4 2005, along with the accompanying average
hourly
wages:

a.. Clinical Research Associate -- $38.53
b.. Data Manager -- $45.06
c.. CRM Project Manager -- $62.01
d.. Data Warehouse Architect -- $69.03
e.. Hardware/Firmware Engineer -- $59.34
f.. .NET Developer -- $45.77
g.. Oracle Database Administrator -- $55.82
h.. Project Manager -- $57.07
i.. SAP Functional Consultant -- $75.09
j.. Senior Scientist -- $43.76

http://money.cnn.com/2006/02/03/pf/pay_hike_jobseeker/index.htm?cnn=yes#pursue
"Two tech jobs in high demand these days are .NET (dot net) developers and
quality assurance analysts.

Developers who are expert users of Microsoft's software programming language
.NET can make between $75,000 and $85,000 a year in major cities. (See
correction.) If they pursue a job at a company that seeks someone with a
background in a given field (say, a firm looking for a .NET developer
experienced in using software related to derivatives) they might snag a
salary
hike of 15 percent or more when they switch jobs.

Those who work in software quality management, meanwhile, might make $65,000
to
$75,000 a year and be able to negotiate a 10 percent to 15 percent jump in
pay
if they switch jobs."
--------------------
somebody
2006-02-26 09:56:36 UTC
Permalink
Post by A Programmer
I think given the other thread, this might be an even better question.
Why do I need .NET as an end user, when my standard Windows stuff is
working just fine.
You don't. *If* you need to run an application that needs .NET, *then* would
need it.

Maybe you meant to ask why a *programmer* would need .NET?
John Jacobson
2006-02-26 18:05:15 UTC
Permalink
Post by somebody
Maybe you meant to ask why a *programmer* would need .NET?
To get a job.
--
***Free Your Mind***

Posted with JSNewsreader Preview 0.9.4.2102
Lee_Nover
2006-02-26 09:57:24 UTC
Permalink
Post by A Programmer
Why do I need .NET as an end user, when my standard Windows stuff is
working just fine.
because the developer will choose .NET because with it he can create an =
app faster, meaning it's gonna be cheaper for the user - you
not that much change for delphi developers :)
John Jacobson
2006-02-26 18:04:47 UTC
Permalink
because the developer will choose .NET because with it he can create an app faster, meaning it's gonna be cheaper for the user - you
not that much change for delphi developers :)
LOL. Talk about massively missing the point! And being downright wrong too.

The end user experience is not going to be significantly improved by getting a
piece of crap "faster" or "cheaper". The end user experience will be
significantly improved by not getting a piece of crap at all, but a good solid
piece of software that does what he needs it to do. .NET will not have any
appreciable affect on that, except in a negative sense in the short run.

In addition, I have yet to see any evidence at all that .NET programmers are
churning out apps any faster than native code programmers are, but I have seen
evidence that they are costing more than the native code programmers are
costing. Go online to any of the job boards and compare the salaries/rates
being offered for .NET work and compare them with the salaries/rates being
offered for Win32 native work.
--
***Free Your Mind***

Posted with JSNewsreader Preview 0.9.4.2102
Jim Cooper
2006-02-26 10:55:31 UTC
Permalink
Post by A Programmer
I think given the other thread, this might be an even better question.
No, it's a worse question. .NET is not, and never was, intended for end users.
It's programmer stuff. It's like asking what the benefit of the VCL is to end users.
Post by A Programmer
Especially if I have to download 23.2MB of software from Microsoft
just to be able to run anything someone cooks up with a .NET enabled
compiler?
<sigh>


Cheers,
Jim Cooper

_____________________________________________

Jim Cooper ***@tabdee.ltd.uk
Skype : jim.cooper
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
_____________________________________________
r***@bigpond.net.au
2006-02-26 11:26:20 UTC
Permalink
Post by A Programmer
Why do I need .NET as an end user, when my standard Windows stuff is
working just fine.
Especially if I have to download 23.2MB of software from Microsoft
just to be able to run anything someone cooks up with a .NET enabled
compiler?
When I consider that I have just downloaded over 100 megs of sdk files
from Sun today to try and get the Netbeans 5.5 preview to work, I
wonder which universe you are living in.
I.P. Nichols
2006-02-26 13:52:31 UTC
Permalink
Post by r***@bigpond.net.au
Post by A Programmer
Why do I need .NET as an end user, when my standard Windows stuff is
working just fine.
Especially if I have to download 23.2MB of software from Microsoft
just to be able to run anything someone cooks up with a .NET enabled
compiler?
When I consider that I have just downloaded over 100 megs of sdk files
from Sun today to try and get the Netbeans 5.5 preview to work, I
wonder which universe you are living in.
Hey, I'll make your day!

Yesterday I downloaded the new Feb CTP "beta" for WinFX Runtime (.NET 3) and
it is
a whopping 45.6MB.

Then the DVD disk image of the SDK for both Win32 and WinFX technologies is
an additional 1.9GB. (your 100 MB sounds so small)<g>

Gosh was I relived when I finished by downloading the installer for Visual
Studio (Code Name "Orcas") Extensions which provides developers with support
for building WinFX applications using VS 2005 and it was only 3.9MB, however
it did download even more while installing.<g>

Not only that, I managed to get it all running and am now busy learning how
to program WinFX apps for both the current Win-XP and the new Vista which is
expected (maybe) to be released later this year.
r***@bigpond.net.au
2006-02-26 11:27:50 UTC
Permalink
Post by A Programmer
Why do I need .NET as an end user, when my standard Windows stuff is
working just fine.
Because an application I need is written in .NET ?
John Jacobson
2006-02-26 17:46:01 UTC
Permalink
Post by r***@bigpond.net.au
Because an application I need is written in .NET ?
But that's only because some manager thought it had to be written in .NET, not
because .NET offered something you need. It is a synthetic, manufactured demand.
--
***Free Your Mind***

Posted with JSNewsreader Preview 0.9.4.2102
Don
2006-02-26 12:20:47 UTC
Permalink
Post by A Programmer
Why do I need .NET as an end user, when my standard Windows stuff is
working just fine.
In my opinion, this is a question which Microsoft has yet to answer.
What, you've not heard of MS PUT (Product Upgrade Treadmill)?
Huw Collingbourne
2006-02-26 12:26:05 UTC
Permalink
Post by Don
Post by A Programmer
Why do I need .NET as an end user, when my standard Windows stuff is
working just fine.
In my opinion, this is a question which Microsoft has yet to answer.
What, you've not heard of MS PUT (Product Upgrade Treadmill)?
I think they might have liked a few more VB users to upgrade ;-)

Huw Collingbourne
================================
Bitwise Magazine
www.bitwisemag.com
Dark Neon Ltd.
================================
Huw Collingbourne
2006-02-26 12:16:21 UTC
Permalink
Post by A Programmer
Why do I need .NET as an end user, when my standard Windows stuff is
working just fine.
In my opinion, this is a question which Microsoft has yet to answer.

From the perspective of a programmer starting a new project from scratch,
there are many attractive features of .NET - a good class library, easy
multi-language development, garbage collection etc. etc.

However, there are many disadvantages: not least of which is the fact that
most existing development cannot easily be migrated to .NET. Delphi is a
notable exception to the rule. It's a shame MS didn't give more thought to
the migration requirements of their programmers too. Moreover, it remains
the fact that .NET is still not a fundamental part of Windows and MS has
failed to persuade the developer community of its overwhelming merits.
They've done a better job at winning over journalists, however - which
probably explains why so many of my journalist colleagues think I'm mad when
I tell them that .NET isn't the be-all and end-all that the MS PR people
claim it to be... ;-)

I personally prefer programming .NET. Lots of things which would be hard
work under Win32 are done easily using the .NET library. And Garbage
Collection undoubtedly removes a great programming burden. But that may not
be sufficient reason on its own for choosing .NET.

best wishes
Huw Collingbourne
================================
Bitwise Magazine
www.bitwisemag.com
Dark Neon Ltd.
================================
Andre Kaufmann
2006-02-26 13:09:42 UTC
Permalink
Post by A Programmer
Why do I need .NET as an end user, when my standard Windows stuff is
working just fine.
In my opinion, this is a question which Microsoft has yet to answer.
From the perspective of a programmer starting a new project from scratch,
there are many attractive features of .NET - a good class library, easy
multi-language development, garbage collection etc. etc.
However, there are many disadvantages: not least of which is the fact that
most existing development cannot easily be migrated to .NET. Delphi is a
notable exception to the rule. It's a shame MS didn't give more thought to
What about C++/CLI ? You can easily mix native and managed code ?
the migration requirements of their programmers too. Moreover, it remains
the fact that .NET is still not a fundamental part of Windows and MS has
What do you mean with fundamental ? Part of a service pack ? It will be
a significant part of Windows Vista and is part of Win2003 Server.
failed to persuade the developer community of its overwhelming merits.
[...]
Andre
Jim Cooper
2006-02-26 13:15:58 UTC
Permalink
In my opinion, this is a question which Microsoft has yet to answer.
It's not a sensible question to ask them.

Any benefits to end users **must** be indirect, since .NET is for programmers,
not end users.



Cheers,
Jim Cooper

_____________________________________________

Jim Cooper ***@tabdee.ltd.uk
Skype : jim.cooper
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
_____________________________________________
Jim Cooper
2006-02-26 14:05:52 UTC
Permalink
virtual machine stuff like .net and java are not on my radar. so
slooooooooooooooooooooooooooooooooooooow. native win32/64 rocks!
The most sophisticated time-sensitive application I have ever seen (highly
multi-threaded, with sophisticated graphics processing going on) is being ported
to .NET. If you really think .NET is that slow you are either ill-informed or
doing something wrong. If you think .NET is a virtual machine you are ill-informed.

Cheers,
Jim Cooper

_____________________________________________

Jim Cooper ***@tabdee.ltd.uk
Skype : jim.cooper
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
_____________________________________________
Florian Klaempfl
2006-02-26 15:32:15 UTC
Permalink
Post by Jim Cooper
virtual machine stuff like .net and java are not on my radar. so
slooooooooooooooooooooooooooooooooooooow. native win32/64 rocks!
The most sophisticated time-sensitive application I have ever seen
(highly multi-threaded, with sophisticated graphics processing going on)
is being ported to .NET. If you really think .NET is that slow you are
either ill-informed or doing something wrong.
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=csharp&lang2=gcc

Ok, so what's wrong?
Joanna Carter [TeamB]
2006-02-26 15:50:27 UTC
Permalink
"Florian Klaempfl" <***@dont.spam.me> a écrit dans le message de news:
4401ca08$***@newsgroups.borland.com...

| Ok, so what's wrong?

Quoting a non-Microsoft .NET compiler/framework against a non-Microsoft C++
compiler is hardly a justification for slagging off Microsoft's own .NET 2.0
complier/framework.

Tell us, have you really ever done any .NET work yourself ?

Are you aware that, whatever the language, the .NET JIT compiler is always
that provided by Microsoft as part of their framework ?

Did you realise that the Microsoft .NET JITter optimises the generated code,
depending on the platform it is running on ?

Why don't you make up your own mind instead of taking other people's reports
as truth (including mine) ?

Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
Florian Klaempfl
2006-02-26 16:00:38 UTC
Permalink
Post by Joanna Carter [TeamB]
| Ok, so what's wrong?
Quoting a non-Microsoft .NET compiler/framework against a non-Microsoft C++
compiler is hardly a justification for slagging off Microsoft's own .NET 2.0
complier/framework.
So you have better ones? M$ .NET against Intel C(++) or even MS-VC++?
Post by Joanna Carter [TeamB]
Tell us, have you really ever done any .NET work yourself ?
Nobody showed me yet benchmarks which proves that .NET can compete with
a good compiler, so I'am not convinced yet to even spent any time in it.
Post by Joanna Carter [TeamB]
Are you aware that, whatever the language, the .NET JIT compiler is always
that provided by Microsoft as part of their framework ?
Did you realise that the Microsoft .NET JITter optimises the generated code,
depending on the platform it is running on ?
Really? It runs on Sparc/Solaris ;)?
Post by Joanna Carter [TeamB]
Why don't you make up your own mind instead of taking other people's reports
as truth (including mine) ?
Where are these reports? I want to see numbers :) Not only some buzz
words :)
Jim Cooper
2006-02-26 18:12:41 UTC
Permalink
Post by Florian Klaempfl
Nobody showed me yet benchmarks which proves that .NET can compete with
a good compiler, so I'am not convinced yet to even spent any time in it.
Why are you using Delphi if that is your only consideration?
Post by Florian Klaempfl
Really? It runs on Sparc/Solaris ;)?
No. And MS did not intend it to. What's that got to do with it not being too slow?

Cheers,
Jim Cooper

_____________________________________________

Jim Cooper ***@tabdee.ltd.uk
Skype : jim.cooper
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
_____________________________________________
Florian Klaempfl
2006-02-26 19:56:07 UTC
Permalink
Post by Jim Cooper
Post by Florian Klaempfl
Nobody showed me yet benchmarks which proves that .NET can compete with
a good compiler, so I'am not convinced yet to even spent any time in it.
Why are you using Delphi
I don't do anymore, D7 was the last one :) But as you might know (or
not), I'am still interested in the Object Pascal world :)
Post by Jim Cooper
if that is your only consideration?
It's an important one. Even our accounting department noticed that the
accounting software got slow when they got the 2006 version being partly
.NET. I wonder if we can get away from it ...
Post by Jim Cooper
Post by Florian Klaempfl
Really? It runs on Sparc/Solaris ;)?
No. And MS did not intend it to. What's that got to do with it not being too slow?
Did you read the whole discussion?
Shawn B.
2006-02-26 20:53:11 UTC
Permalink
Post by Florian Klaempfl
So you have better ones? M$ .NET against Intel C(++) or even MS-VC++?
I've seen some comparisons. Many of the tests simply just create a loop
iterating 10 million times and peforming some mathmatical calculation then
reporting how long it took each language to perform the task. I'd hardly
call that an interesting benchmark of performance. In my 16 years, I've
never written a business application that does that.

I have written business applications that display a UI, wait for input, then
wait some more for some database backend to do something with it, or they'll
wait some more while they make a network request, or they'll wait some more
to manipulate something in the filesystem, then report something back to the
user and the cycle repeats. In this case, its not the language or
environment chosen that is slow, it is the time spent waiting for the
network request to complete, the file operation or database request to
complete. Such things will take the same time no matter what language is
chosen. The only difference is, the person doing it in .NET is likely to
complete the project quicker than the guy doing it in C++. Oh, and, he
won't have to focus on memory management and buffer-overruns so much,
also... the .NET guy can focus on designing an application a lot sooner than
the C++ guys.

Of all the places I've worked full time or consulted, most of them are large
enterprise systems with hundreds of thousands of users either in a single
location but mostly all over the world. They were either programmed in VB6
or requires the .NET platform. .NET is friendly to those writing enterprise
systems, as they have a sound Remoting architecture (give or take some
flaws, its better than RPC and DCOM), they have great network and threading
support, and great database support. Most of which are there for free,
whereas with C++, it might take more to leverage the same ideas.

When talking about performance, if you're talking about a shops that
currently use VB6 and never have or never will use C++ for their main
application, .NET is an excellent alternative and a natural upgrade path for
more reasons, other than the fact that MS doesn't support VB6 anymore and
most 3rd party's have moved on. To them, the performance difference between
C++ and C# isn't important. The long-term maintainability and agility of
the dev team is.
Post by Florian Klaempfl
Post by Joanna Carter [TeamB]
Tell us, have you really ever done any .NET work yourself ?
Nobody showed me yet benchmarks which proves that .NET can compete with
a good compiler, so I'am not convinced yet to even spent any time in it.
Perhaps because you wouldn't care if they did. As I stated above,
performance is only one aspect, there are so many more issues involved when
using a language than pure performance. If C++ gave me X amount of
performanc, assuming I wasn't screwing anything up and wrote the code as
perfectly as possible and the compiler didn't accidentally generate code
that creates CPU stalls and such, and writing the same code in .NET gave me
X+7% performance, assuming I didn't do anything stupid... so what? 90% if
the "waiting" in our applications are spent waiting for the network
communication to complete, a database operation or some filesystem
operation... such "waiting" will happen whether we use C++ or .NET. Not to
mention, its significantly easier to write the code in a .NET language than
C++. The only difference is that the .NET guy will have the project
completed sooner than the C++ guy and can probly fix up the bugs and clean
up the architecture by the time the C++ guy finishes his first iteration.

What will convince you? Certainly not sound reasoning.
Post by Florian Klaempfl
Post by Joanna Carter [TeamB]
Why don't you make up your own mind instead of taking other people's reports
as truth (including mine) ?
Bravo. Good point.


Thanks,
Shawn
John Jacobson
2006-02-26 17:20:49 UTC
Permalink
Post by Joanna Carter [TeamB]
Did you realise that the Microsoft .NET JITter optimises the generated code,
depending on the platform it is running on ?
That's not as fascinating as it appears at first glance, since it only runs on
Windows, and therefore only on an Intel-compatible chip set. For every
"platform" that .NET runs on, there is an Intel native compiler that does a
better job than the .NET JITter. In addition, it has long been the case that
hand-optimized assembly code has been able to exceed compiled code in speed,
but that is not even an option available to the .NET programmer without jumping
through a lot of hoops, such as interop.

At this point in time, the best that .NET code can do is to not be so slow that
it impedes the user. My guess is that for something like 90% of all
applications, .NET is fast enough.
--
***Free Your Mind***

Posted with JSNewsreader Preview 0.9.4.2102
Jim Cooper
2006-02-26 18:13:45 UTC
Permalink
Post by John Jacobson
My guess is that for something like 90% of all
applications, .NET is fast enough.
If it's fast enough for Bryan's app, I would think 90% is quite conservative.


Cheers,
Jim Cooper

_____________________________________________

Jim Cooper ***@tabdee.ltd.uk
Skype : jim.cooper
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
_____________________________________________
Shawn B.
2006-02-26 20:57:02 UTC
Permalink
Post by Jim Cooper
Post by John Jacobson
My guess is that for something like 90% of all
applications, .NET is fast enough.
If it's fast enough for Bryan's app, I would think 90% is quite conservative.
The fact is, most of the time, the "wait" and "slowness" isn't in CPU code,
it is in waiting for database operations to complete or network
communication to complete or other types of IO. In this case, it is
unimportant what language is chosen as they'll all have the same congestion
points. With that in mind, if it isn't a performance critical application,
such as most business applications, than it's really a moot point and rather
a choice of the programmer or management what language to use.


Thanks,
Shawn
Jim Cooper
2006-02-26 18:11:19 UTC
Permalink
Post by Florian Klaempfl
Ok, so what's wrong?
That's Mono, for starters. MS will tell you that they very definitely do not
consider .NET to be a cross-platform framework (at least, not to non-MS OSes).


Cheers,
Jim Cooper

_____________________________________________

Jim Cooper ***@tabdee.ltd.uk
Skype : jim.cooper
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
_____________________________________________
Shawn B.
2006-02-26 20:32:22 UTC
Permalink
Post by Florian Klaempfl
Post by Jim Cooper
virtual machine stuff like .net and java are not on my radar. so
slooooooooooooooooooooooooooooooooooooow. native win32/64 rocks!
The most sophisticated time-sensitive application I have ever seen
(highly multi-threaded, with sophisticated graphics processing going on)
is being ported to .NET. If you really think .NET is that slow you are
either ill-informed or doing something wrong.
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=csharp&lang2=gcc
Ok, so what's wrong?
Talk about biased... you are comparing the Mono version of .NET. Not the MS
flavor. Further more, that's not even the 2.0 flavor of either Mono or MS
.NET.

So what's your point?


Thanks,
Shawn
Rod
2006-02-26 13:46:24 UTC
Permalink
Post by A Programmer
I think given the other thread, this might be an even better question.
Why do I need .NET as an end user, when my standard Windows stuff is
working just fine.
Especially if I have to download 23.2MB of software from Microsoft
just to be able to run anything someone cooks up with a .NET enabled
compiler?
virtual machine stuff like .net and java are not on my radar. so
slooooooooooooooooooooooooooooooooooooow. native win32/64 rocks!
Joanna Carter [TeamB]
2006-02-26 15:49:15 UTC
Permalink
"Rod" <***@999.com> a écrit dans le message de news:
***@newsgroups.borland.com...

| virtual machine stuff like .net and java are not on my radar. so
| slooooooooooooooooooooooooooooooooooooow. native win32/64 rocks!

You obviously haven't tried to get hardware drivers for Win64 lately.

.NET is *not* a virtual machine, it is JITted from IL into native code, then
the native code is run on subsequent executions of that code.

Go on, spoil yourself, see what all the fuss is about for yourself before
you take someone else's word for it.

Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
Rod
2006-02-26 16:27:06 UTC
Permalink
Post by Joanna Carter [TeamB]
.NET is *not* a virtual machine, it is JITted from IL into native code, then
the native code is run on subsequent executions of that code.
JITted! Wow! Please allow me to call that "Virtual machine". It's
Microsoft's Java! :-)
Dave Nottage [TeamB]
2006-02-26 15:40:31 UTC
Permalink
Post by Rod
Please allow me to call that "Virtual machine"
Please allow me to say you're wrong. Since the end result is native
code, it's not a virtual machine.
--
Dave Nottage [TeamB]
Have questions?: http://www.catb.org/~esr/faqs/smart-questions.html
Want answers?: http://support.borland.com
John Jacobson
2006-02-26 17:26:02 UTC
Permalink
Post by Dave Nottage [TeamB]
Please allow me to say you're wrong. Since the end result is native
code, it's not a virtual machine.
The end result of the .NET JITter is native code too, if you consider machine
code to be native.
--
***Free Your Mind***

Posted with JSNewsreader Preview 0.9.4.2102
Alex Zencovich
2006-02-26 19:20:02 UTC
Permalink
Yes, JIT make code SIMILAR to native except one - you cannot create memory
reference, even if native code allows it.

Instead of memory reference to object, JIT produce call to some interface
methods. Even if you use native-like datatypes, JIT will create call to
object methods. With stack loading, restoring and passing parameter.
In other words - JIT is not like usual VM. Some VM works as single virtual
memory room. Instead of, JIT make something like distributed VM which works
with native CPU(and this is advantage of .NET) code but work in
high-fragmented memory space.
Moreover, these fragmets constantly moved by standalone process (garbage
collector). As result - .NET could not have perfomance similar to native
code perfomance. It will poor anyway.

Alex.
Post by John Jacobson
Post by Dave Nottage [TeamB]
Please allow me to say you're wrong. Since the end result is native
code, it's not a virtual machine.
The end result of the .NET JITter is native code too, if you consider machine
code to be native.
--
***Free Your Mind***
Posted with JSNewsreader Preview 0.9.4.2102
Florian Klaempfl
2006-02-26 17:27:23 UTC
Permalink
Post by Rod
Post by Joanna Carter [TeamB]
.NET is *not* a virtual machine, it is JITted from IL into native code,
then
Post by Rod
Post by Joanna Carter [TeamB]
the native code is run on subsequent executions of that code.
JITted! Wow! Please allow me to call that "Virtual machine". It's
Microsoft's Java! :-)
Why does it matter whether source/IL code is compiled on developer's machine
or user's machine? If anything, compiled code on user's machine can have a
slight performance advantage in theory.
Only in theory :) Or are there good counter examples? A JIT compiler
simply can't spent that much time into optimization than a standalone
compiler can and e.g. gcc or Intel do if told so. Further, usual ILs are
rather primitive so a lot of information is lost which could be used to
generate good code. Any decent processor except the P4 with the net
burst micro archictecture are designed to run blended code well, so
using processor specific instructions makes usually no difference.
somebody
2006-02-26 17:11:46 UTC
Permalink
Post by Rod
Post by Joanna Carter [TeamB]
.NET is *not* a virtual machine, it is JITted from IL into native code, then
the native code is run on subsequent executions of that code.
JITted! Wow! Please allow me to call that "Virtual machine". It's
Microsoft's Java! :-)
Why does it matter whether source/IL code is compiled on developer's machine
or user's machine? If anything, compiled code on user's machine can have a
slight performance advantage in theory. Only problem with .NET is runtime
download, but once Vista ships, that will be a non-issue. It already is, if
you ask me. I have downloaded more just for Acrobat Reader upgrades over the
years and I don't care - the reason you have that cable with funky ends
plugged into your box is to enable you to download (and upload) stuff.
Jim Cooper
2006-02-26 18:15:08 UTC
Permalink
Post by Rod
Please allow me to call that "Virtual machine".
Sorry, but no. That's not a virtual machine. If it is then any compiled code has
to be called a virtual machine.


Cheers,
Jim Cooper

_____________________________________________

Jim Cooper ***@tabdee.ltd.uk
Skype : jim.cooper
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
_____________________________________________
Shawn B.
2006-02-26 20:59:36 UTC
Permalink
Post by Rod
Post by Joanna Carter [TeamB]
.NET is *not* a virtual machine, it is JITted from IL into native code,
then the native code is run on subsequent executions of that code.
JITted! Wow! Please allow me to call that "Virtual machine". It's
Microsoft's Java! :-)
JIT is really a runtime compiler. So what's the difference if it's compiled
once at development time like C++ or if its compiled once at runtime like
.NET? In the end, its comipled.


Thanks,
Shawn
John Jacobson
2006-02-26 17:25:07 UTC
Permalink
Post by Joanna Carter [TeamB]
.NET is *not* a virtual machine, it is JITted from IL into native code, then
the native code is run on subsequent executions of that code.
There exist JITTers for Java too. I'm not sure that means that Java doesn't use
a JVM, just that the JVM is not an idiot about how it approaches compiling the
code.

In other words, it is really splitting hairs to argue that .NET does or does
not use a virtual machine. When it comes to performance, Java is not near as
slow as it used to be, even though it uses a JVM, and .NET is not so slow that
it is not useable, whether or not one admits that it uses an internediary layer
between the code and execution, just like a JVM does.
--
***Free Your Mind***

Posted with JSNewsreader Preview 0.9.4.2102
Wayne Niddery [TeamB]
2006-02-26 20:04:17 UTC
Permalink
Post by John Jacobson
In other words, it is really splitting hairs to argue that .NET does
or does not use a virtual machine. When it comes to performance, Java
is not near as slow as it used to be, even though it uses a JVM, and
.NET is not so slow that it is not useable, whether or not one admits
that it uses an internediary layer between the code and execution,
just like a JVM does.
A difference is that Java was originally designed to be interpreted and
compilers came out later. .Net was *never* designed to be interpreted but
with JIT in mind from the start. While that difference is not a guarantee,
it should result in both faster JIT and more optimized results - at the very
least there is more opportunity to make that so because it was designed with
that as a goal.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: http://www.logicfundamentals.com/RADBooks.html
Working for yourself is great because you get to work half days, and
you can choose any twelve hours you want.
Bob Dawson
2006-02-26 14:54:00 UTC
Permalink
Post by A Programmer
I think given the other thread, this might be an even better question.
Actually I think it's a horrid question, like asking why a user would want
disc brakes rather than drum brakes. The user only cares about getting the
car stopped.

Same here. No user needs .NET. They may, however, want more reliable,
flexible, extensible, and cheaper software, and sometimes a change of
underlying technologies is the best way to gain those options.

Obviously continuous rewriting for its own sake is pointless except for the
hobbyist, but that doesn't mean that the decision to rewrite is always
wrong, even at the cost of some short term problems.
Post by A Programmer
Why do I need .NET as an end user, when my standard Windows
stuff is working just fine.
Have yet to meet a user with so poor an imagination that he/she was unable
to find fault with existing software, or was unable to imagine better.
Post by A Programmer
Especially if I have to download 23.2MB of software from Microsoft
just to be able to run anything someone cooks up with a .NET enabled
compiler?
For most business computing, this is simply a bogus issue.

bobD
John Jacobson
2006-02-26 17:38:34 UTC
Permalink
Post by Bob Dawson
Have yet to meet a user with so poor an imagination that he/she was unable
to find fault with existing software, or was unable to imagine better.
But that begs the question of how .NET is going to provide him with better
software when Win32 native code could not. In fact, since it has a learning
curve for programmers, it is very likely to impede that process in the short
run. Nobody can claim, with a straight face, that adopting .NET is going to
make programmers significantly better at their craft all of a sudden. They'll
just crank out crap.NET instead of plain vanilla crap.

It might be fun to imagine all sorts of things, but it is here in the real
world that user needs are translated into demand. Users want solid software
that does what they want and need it to do. It is no harder to churn out bad
software in .NET than it was in Win32, so is the user experience likely to
improve as a result of .NET? No, because .NET does not solve the problems that
really matter. It solves problems that good programmers have already been
solving, like object lifetime management, and wild references/pointers.
--
***Free Your Mind***

Posted with JSNewsreader Preview 0.9.4.2102
Bob Dawson
2006-02-26 18:08:59 UTC
Permalink
Post by John Jacobson
But that begs the question of how .NET is going to provide him with
better software when Win32 native code could not.
A power loom does nothing that a hand weaver couldn't have done. Made a big
splash though.
Post by John Jacobson
In fact, since it has a learning
curve for programmers, it is very likely to impede that process in the
short run.
Conceded. Major issue. But I can also walk to the store (an hour or so) much
faster than learning to drive. Learned to drive anyway. Bet you did too.
Post by John Jacobson
It is no harder to churn out bad
software in .NET than it was in Win32,
New technnologies don't make an idiot into a craftsman, no. But by that
standard we'd all still be hunter-gatherers using hand axes. They do raise
raise the bar for what's achieveable by those who know what they're doing.
And isn't that the point?
Post by John Jacobson
so is the user experience likely to
improve as a result of .NET?
For the above reason, yes.
Post by John Jacobson
.NET does not solve the problems that
really matter.
The problem that really matters is how the problem domain gets expressed
in code. Better domain analysis is one base of that relation, better
software tools are the other. While I'm a subscriber to the 'No Silver
Bullet' position, no where in that article does Brooks say that improvement
isn't possible.
Post by John Jacobson
It solves problems that good programmers have already been
solving, like object lifetime management, and wild references/pointers.
Cartridge ammunition solved problems that experienced marksmen already knew
well: getting a consistent charge for each round, and keeping your charges
dry. And using the best rifle available, a totally unskilled hunter is no
more likely to hit his target than he would be using a blackpowder
muzzle-loader.

bobD
John Jacobson
2006-02-26 18:46:51 UTC
Permalink
Post by Bob Dawson
A power loom does nothing that a hand weaver couldn't have done.
Interesting example, since that was a case of a technology that demonstrated a
very obvious and very significant improvement in the production process. I
think you'd be hard-pressed to demonstrate an equivalent effect of .NET on
software production.
--
***Free Your Mind***

Posted with JSNewsreader Preview 0.9.4.2102
AlisdairM
2006-02-26 18:23:41 UTC
Permalink
Post by John Jacobson
Interesting example, since that was a case of a technology that
demonstrated a very obvious and very significant improvement in the
production process. I think you'd be hard-pressed to demonstrate an
equivalent effect of .NET on software production.
What is your point of comparison though?

You are saying .NET development is no more productive than VC++/MFC?
Or VB? Or simply that it is a much smaller leap for Delphi/VCL
developers?

The latter I can agree with <g> The first I will definitely dispute,
the second it depends on what you are measuring ;?)

Real benefits from .NET are those of a managed environment - garbage
collection, built-in application security, elimination of common errors
such as buffer overruns. The built in reflection makes productivity
enhancers like nUnit possible, or certainly far simpler than the
equivalent in a pre-.Net windows environment.
--
AlisdairM(TeamB)
Florian Klaempfl
2006-02-26 19:47:22 UTC
Permalink
Post by AlisdairM
Post by John Jacobson
Interesting example, since that was a case of a technology that
demonstrated a very obvious and very significant improvement in the
production process. I think you'd be hard-pressed to demonstrate an
equivalent effect of .NET on software production.
What is your point of comparison though?
You are saying .NET development is no more productive than VC++/MFC?
Or VB? Or simply that it is a much smaller leap for Delphi/VCL
developers?
The latter I can agree with <g> The first I will definitely dispute,
the second it depends on what you are measuring ;?)
Real benefits from .NET are those of a managed environment - garbage
collection, built-in application security, elimination of common errors
such as buffer overruns.
Which doesn't lead necessarily to less buggy applications. I think I saw
more .NET applications crash with an exception than any other
application ... ok, otoh e.g. Acrobat Reader usually simply hangs or MS
Word simply disappears ;)
Post by AlisdairM
The built in reflection makes productivity
enhancers like nUnit possible, or certainly far simpler than the
equivalent in a pre-.Net windows environment.
Florian Klaempfl
2006-02-26 15:26:42 UTC
Permalink
Post by A Programmer
I think given the other thread, this might be an even better question.
Why do I need .NET as an end user, when my standard Windows stuff is
working just fine.
Especially if I have to download 23.2MB of software from Microsoft
just to be able to run anything someone cooks up with a .NET enabled
compiler?
It makes the decision easier which software to buy :) For .NET or Java
based software you've usually to assume that also a new PC is necessary
so the .NET or Java based one must be significantly cheaper which is
often not the case.
Jim Cooper
2006-02-26 18:17:23 UTC
Permalink
For .NET or Java based software you've usually to assume
that also a new PC is necessary
That's just silly


Cheers,
Jim Cooper

_____________________________________________

Jim Cooper ***@tabdee.ltd.uk
Skype : jim.cooper
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
_____________________________________________
Florian Klaempfl
2006-02-26 18:48:59 UTC
Permalink
Post by Jim Cooper
For .NET or Java based software you've usually to assume
that also a new PC is necessary
That's just silly
So you say .NET/Java reach the same speed and require as little memory
as native code? Show me reproducable benchmarks proving this, I've still
seen none :)
OD
2006-02-26 15:22:50 UTC
Permalink
haha :-)
It's always a pleasure, when you are a bit old, to read again the same
things 10 years, 20 years after, very refreshing :-)

Were customers able to see the difference between Win16 and W32 ?
were custumers able to see the difference between procedural Pascal and
Object Pascal ?
...
But today you will not create a software using procedural Pascal, nor
you will began a new project under Win16.

Same reasons, same effets.

What is very interesting is that people blaming MS because Millemium
was just a cosmetic change (or a lot of other examples of this kind)
are always fighting new languages/platforms because "customer will not
see the difference".
So programming, creating software is just a work for decorators and
painters ? All for the eyes ?
--
Olivier Dahan
MK Query Builder
www.e-naxos.com
Jolyon Smith
2006-02-26 19:45:50 UTC
Permalink
Post by A Programmer
Why do I need .NET as an end user, when my standard Windows stuff is
working just fine.
Or, to wind the clock back a few years:

"
Why do I need Windows as an end user, when my standard DOS stuff is
working just fine.

Especially if I have to install 100+MB of software from Microsoft
just to be able to run anything someone cooks up with a Windows enabled
compiler?
"


It's called progress/change/whatever.

In 10-15-20 years time your future self or counterpart thereof wil be
moaning about why should they have to replace their perfectly adequate
.Net systems with FutureStuff(TM).

<shrug>
--
Jolyon Smith
Wayne Niddery [TeamB]
2006-02-26 19:59:07 UTC
Permalink
Post by Jolyon Smith
"
Why do I need Windows as an end user, when my standard DOS stuff is
working just fine.
...or...

Why, oh why, does everything have to keep changing?? I want everything to
stay exactly the way it is *forever*! It's not fair that new things keep
coming out all the time, forcing me to change the way I do things!

There will always be change, and there'll always be some who resist it no
matter what.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: http://www.logicfundamentals.com/RADBooks.html
"Light is faster than sound, which is why some folks appear bright
before they speak."
A Programmer
2006-02-26 20:35:20 UTC
Permalink
On Sun, 26 Feb 2006 21:14:06 +0100, Florian Klaempfl
DOS stuff didn't work fine. Now I can edit multi mega byte texts with
pictures and anything on even a 5 year old PC, I can edit videos in a
high quality, I can play games being almost photo realistic. This was 15
years ago imaginable stuff, but not doable because of lacking software
and hardware and DOS wasn't able to do this.
But what else would is now imaginable which would require to change a
currently running system (win32)?
640 kB were not enough, it was clear that 640 kB were too little to
view/edit a photo or even playback/edit a video. But I see no real
application which would require more than the 1.5 GB RAM I've currently.
So (as every stock trader knows ;)): extrapolation from the past to the
future is usually not possible :)
(sorry I don't usually do this, but...)

What he said . :) I wouldn't even say this applied to just win32,
though, but win16 as well. I can't say I've found anything that I
couldn't do on a win16 system given the appropriate software and
hardware drivers to do it. Of course, Windows 3.1 had the DPMI
manager.

A lot of it, too, though is how the applications were designed - where
they MEANT to handle a large amount of data in the first place?
A good example is DOS Edit. The original DOS 6 version choked on a
rather small amount of text, but the newest version of edit that was
developed by Microsoft will load as much text as you want to throw at
it.

I had a DOS photo viewer once upon a time which managed quite well
with 640K (GIF mainly, and later on this new creature called JPEG). I
had an animation player too that worked under DOS. Of course, it's
quite notable to mention that the original MP3 encoders all worked
under DOS. Then of course, I have this CD-burner software package for
DOS I mentioned earlier.

I can't say I had a video player on DOS, but I had one in Win 3.1
(which played very short videos that were very big files). I'm sure
someone could have /still could rig up a good video player that works
under DOS/4GW if necessary.

A lot of limitation is not what is generally placed upon the user by
the OS, but what the programmer arbitrarily places upon the user by
his unwillingness to do the work to make something happen. Really,
the only thing I find that really doesn't work well with DOS these
days is the UDMA hard disk drivers I have that don't co-exist with my
UDMA CD drivers, but I understand that could be worked around too if
the expertise was there.

This change is often not truly necessary, but manufactured simply for
profit's sake.
Florian Klaempfl
2006-02-26 20:14:06 UTC
Permalink
Post by Jolyon Smith
Post by A Programmer
Why do I need .NET as an end user, when my standard Windows stuff is
working just fine.
"
Why do I need Windows as an end user, when my standard DOS stuff is
working just fine.
DOS stuff didn't work fine. Now I can edit multi mega byte texts with
pictures and anything on even a 5 year old PC, I can edit videos in a
high quality, I can play games being almost photo realistic. This was 15
years ago imaginable stuff, but not doable because of lacking software
and hardware and DOS wasn't able to do this.

But what else would is now imaginable which would require to change a
currently running system (win32)?

640 kB were not enough, it was clear that 640 kB were too little to
view/edit a photo or even playback/edit a video. But I see no real
application which would require more than the 1.5 GB RAM I've currently.

So (as every stock trader knows ;)): extrapolation from the past to the
future is usually not possible :)
somebody
2006-02-26 21:00:44 UTC
Permalink
Post by Jolyon Smith
Why do I need Windows as an end user, when my standard DOS stuff is
working just fine.
DOS stuff didn't work fine. Now I can edit multi mega byte texts with
pictures and anything on even a 5 year old PC, I can edit videos in a
high quality, I can play games being almost photo realistic.
Hindsight is 20/20.
This was 15 years ago imaginable stuff,
Really? Well, anything is imaginable. I can imagine a robot doing all my
work. But how can you predict what precise technologies will enable that?
.NET may or may not be a brick in that wall, time will tell. However, I can
easily imagine programmers in 50 years thinking that we must be utterly and
completely out of our minds for working with unmanaged code and moreover,
resisting the change.

marc hoffman
2006-02-26 21:02:22 UTC
Permalink
A Programmer,
What is the benefit to me of .NET as an end-user?
What's the benefit of Delphi to the end-user?
--
marc hoffman
Chief Architect, .NET
RemObjects Software
http://www.chromesville.com

and the fifty-two daughters of the revolution
turn the gold to chrome
Continue reading on narkive:
Loading...