.NET Framework ??

The Real Andy
Guest

Mon Feb 19, 2007 10:48 am

On Sun, 18 Feb 2007 18:28:28 -0800, MassiveProng
<MassiveProng_at_thebarattheendoftheuniverse.org> wrote:

Quote:

On Mon, 19 Feb 2007 13:18:52 +1100, "Michael Brown"
see_at_signature.below> Gave us:

/how Borland "lost" the C++ market

They were unable to compete in the "visual" based development realm.

I agree, and that is when most people gave up on Borland. MFC was
always ahead (even if it was crap) and the OWL compatibility debacle
in the early 90's (IIRC) was just a plain fucken pain in the arse.

Michael Brown
Guest

Mon Feb 19, 2007 5:21 pm

The Real Andy wrote:

Quote:

Michael Brown wrote:
[...]
Sorry, I screwed up once again Sad

I meant to write that MFC licence
condition was valid only if Borland dropped OWL. That was some time
ago now, I cant really remember what happened.

Initially this was the case, which is why it took so long for BC++ to become
MFC compatible (Watcom, Symantic, etc had MFC support years before Borland).
MS finally relented and allowed Borland to use both - I have no idea why.
Presumably money was involved somewhere.

[...]

Quote:

Cold start times for .NET applications are terrible. Even a simple
winforms "Hello World" takes somewhere between 15-25 seconds
(depending on the phase of the moon) to start where the CLR isn't
already loaded (for example, after a reboot, or if you have 512 MB
of RAM as the CLR files fall out of the cache pretty quickly). Warm
start times are better, though still in the order of 3-4 seconds.
Compared to, say, firefox, which cold-starts in a bit under 10
seconds and warm-starts basically instantly. While this isn't a
problem for applications that run all the time, it prevents .NET
from being used for small utility applications - I don't want to
wait for 3 or so seconds while calc or notepad starts, for example.
Similarly, meory usage is terrible for .NET apps - a "Hello World"
takes up around 7MB of RAM.

Ok, so the lowest CPU speed I have app's running on is around 2GHz.
These are AU$400 PC's shipped with 512mb RAM, running XPSP2. I have
never seen one take more than a few seconds to load the framework,
even after a reboot.

Are you sure that you're actually testing a "cold boot" scenario? For
example, if you use ATI graphics drivers, the framework gets loaded during
boot. The warm and cold start times are about the same on my main computer
because of this (and somewhere around 1-1.5 seconds due to better hardware).
The times I mentioned above are on my "clean test" machine, an XP1700 with
512 MB RAM. This is a cleaner machine than most when it comes to stuff in
RAM, since I'm only testing a single app at a time (more or less just XP +
..NET frameworks). On another machine that I use (P4 ~2GHz, 512 MB RAM, but
with lots of junk loaded like a virus scanner, firewall, web/email clients,
etc ) I observe similar or worse times - worse because when I exit a .NET
application the framework tends to fall out of the cache pretty quickly as
memory is tight. Resulting in times closer to cold starts than warm starts.

Quote:

BTW, there is tonnes of information out there on
how to reduce cold start times of app's. In fact MSDN mag did an
article on such not so long ago.

Yes, there are things you can do to improve cold (and warm) start times ...
but these times are for a "Hello World" app, which doesn't leave many
options for improvement.

[...]

Quote:

Hardware is cheap, development time is quick, results are relatively
robust (you can still write bad code). The whole idea with .net and
java is that you sacrifice some resources for the huge benefits gained
from safe, secure and reliable code.

Safe and secure, maybe, but reliable? Allowing people to be sloppy when
coding is just asking for reliability issues further down the line. The
"ideal" language (IMO) should be strictly typed (no magic float-to-int
conversions for you!), require explicit memory allocation and deallocation
(with a garbage collector there solely to slap you if you forget) and allow
you to get your hands dirty and bit-bash if you want to. Ideally it should
also treat fundamental types as fundamental types - an integer is an
integer, not an object. Basically, make the programmer think about what
(s)he is writing, not just spew out a whole lot of code and make random
changes until it works. Unfortunately, the trend seems to be away from every
one of these aspects and towards allowing - even encouraging - poor
programming practices. While in the short term this may seem like a good
solution, 5 years down the line you'll end up with millions of lines of
poorly written code just held together by comments such as "I don't know why
the following line is needed but things break if it's removed".

/me gets off his soapbox :)

[...]

Quote:

Fair point. I don't do FP stuff. Things such as casting classes to
binary buffers can be slow, but by marshalling to unmanaged and back
it is real fast. What's great about that is the marshaller will not
let you exceed the bounds of the array. You cant overrun a buffer. Big
plus. Does not matter how bad you code, you cant do it. It won't let
you. This is just one of the benefits. I challenge anyone to tell me
that they have not had a buffer overrun, even if it was found before
production.

I can't recall the last time I had a buffer overrun in any of my Delphi
code. I have had the odd one when mixing Delphi and inline assembler (the
overflow in the assembler part), but assembler is assembler and those things
happen Smile

In my C++ code, I've had the odd one in parts which I've been
aggressively optimizing (as in "we need to squeeze more performance out of
this procedure, new is slowing us down, so lets coalesce all the unrelated
new calls into a single malloc and bitbash some things around" aggressive)
but not AFAICR in "normal" code. In these cases, a managed language would
have prevented the buffer overflows simply by not allowing me to optimize so
aggressively. Not exactly a plus in that case.

The reason for this IMO is that I've always been quite conscious of buffer
overruns and the like, coming from an assembly and software security
background. Of course, I can't say I've never had one - my memory doesn't go
back far enough, and I'm pretty certain that when I was starting programming
I overflowed a few buffers (either accidentally or on purpose ...).
Defensive programming beats a safety net any day of the week - a (prevented)
buffer overflow in a .NET application usually results in the application
crashing or being terminated. While this is better than a buffer overflow,
it's better still that the app figures out beforehand that the buffer is too
small and handles it gracefully. Additionally, most C/C++ compilers now
support buffer overflow detection with guard words. While this results in
guaranteed termination of the program (rather than possible recovery with an
exception), the result is not all that different to an exception firing
where you did not anticipate it happening.

Quote:

The biggest problem I've found is that, although you can code a .NET
to be fast, it's not encouraged. A lot of the things that make .NET
development easy also make the resulting application slow. The end
result of this is things like ATI's CCC - massive memory use, slow
startup times, laggy interface, etc etc. While I know that CCC is
not representitive of a "good" .NET app, it is representitive of a
vast majority of .NET apps.

I wonder what agent uses.

As far as I can tell, it uses MSVC (and wxWindows for the gui). It's a
combination of C and C++. Though this is just from a quick glance through
the executable using notepad - it may be being crafty :)

Quote:

Currently in my process list (Sysinternals)
I have Agent at 10MB, followed by explorer(Win GUI shell) at 13MB, and
Visual Studio 2005 at 40Mb.

Heh, Explorer on this computer is at 17 MB - tis what you get when you don't
log off for 9 days ... Biggest memory users at the moment are Opera (103
MB), Delphi 7 (35 MB), OE (31 MB). However, I wouldn't consider Opera
bloated - I've got about 25 tabs open across 2 windows, and then the cached
renderings for the previous page, plus cached files ... Delphi and OE are
also quite "busy", and the memory is being put to good use. The award for
bloat (being defined as memory used for no good purpose) on my computer goes
to the annoying ATI tray icon that just won't go away. It's currently using
up 7 MB to display an icon in the tray that if I double-click on it starts
up CCC.

[...]

Quote:

While I can't say I've run into a problem that *can't* be worked
around, some bugs (mainly in the 1.0 and 1.1 era) have required
significant and/or ugly workarounds (which had to be developed using
trial and error). One of the things I love about Borland's VCL is
that you get the source code, which means you can easily trace into
the VCL and see where something is going wrong. This makes it much
easier to develop workarounds compared to developing them for .NET
where if you tell MS "{x} doesn't work correctly" you just get the
response "don't do {x}, and it may be fixed in a future service
pack". At which point, if doing {x} is important to your code, you
have to start the tedious process of black-box debugging the
framework. Reflector can help a bit if you've narrowed it down, but
it's still nowhere as nice as being able to trace into the code.

Maybe that's where I differ. I don't want the source code. I don't
care about it. The last thing I want to do is spend time learning my
way through some library. I just don't have time.

I'm coming somewhat from the same direction but with different experiences
.... I don't have time to be trying to second-guess what's happening inside a
library. If an application isn't behaving as it should, there's either a bug
in my code or a bug in the library (or very occasionally a bug in the
compiler). Maybe I've just been unlucky with hitting lots of .NET framework
bugs, but I'm pretty sure I've spent more time in the last couple of years
trying to isolate and work around .NET bugs than I've spent tracing through
the VCL source code (and it's not due to spending a lack of time with VCL).
Since I've written quite a few Delphi components I already knew (or had to
know) what a typical VCL component looks and acts like. Since the VCL
follows the same rules as the components I write, tracing through it is
pretty easy.

[...]

--
Michael Brown
Add michael@ to emboss.co.nz - My inbox is always open

Joel Kolstad
Guest

Mon Feb 19, 2007 8:39 pm

"Homer J Simpson" <nobody_at_nowhere.com> wrote in message
news:xZvBh.84639$Y6.80597_at_edtnps89...

Quote:

Removing and reinstalling software may lead to corruption.

True enough, although when that happens it's an easy way to know that the
piece of software is crap and you shouldn't bother using it if at all
possible!

The Real Andy
Guest

Mon Feb 19, 2007 11:06 pm

On Tue, 20 Feb 2007 03:21:06 +1100, "Michael Brown"
<see_at_signature.below> wrote:

Quote:

The Real Andy wrote:
Michael Brown wrote:
[...]

%<

Quote:

[...]
Cold start times for .NET applications are terrible. Even a simple
winforms "Hello World" takes somewhere between 15-25 seconds
(depending on the phase of the moon) to start where the CLR isn't
already loaded (for example, after a reboot, or if you have 512 MB
of RAM as the CLR files fall out of the cache pretty quickly). Warm
start times are better, though still in the order of 3-4 seconds.
Compared to, say, firefox, which cold-starts in a bit under 10
seconds and warm-starts basically instantly. While this isn't a
problem for applications that run all the time, it prevents .NET
from being used for small utility applications - I don't want to
wait for 3 or so seconds while calc or notepad starts, for example.
Similarly, meory usage is terrible for .NET apps - a "Hello World"
takes up around 7MB of RAM.

Ok, so the lowest CPU speed I have app's running on is around 2GHz.
These are AU$400 PC's shipped with 512mb RAM, running XPSP2. I have
never seen one take more than a few seconds to load the framework,
even after a reboot.

Are you sure that you're actually testing a "cold boot" scenario? For
example, if you use ATI graphics drivers, the framework gets loaded during
boot. The warm and cold start times are about the same on my main computer
because of this (and somewhere around 1-1.5 seconds due to better hardware).
The times I mentioned above are on my "clean test" machine, an XP1700 with
512 MB RAM. This is a cleaner machine than most when it comes to stuff in
RAM, since I'm only testing a single app at a time (more or less just XP +
.NET frameworks). On another machine that I use (P4 ~2GHz, 512 MB RAM, but
with lots of junk loaded like a virus scanner, firewall, web/email clients,
etc ) I observe similar or worse times - worse because when I exit a .NET
application the framework tends to fall out of the cache pretty quickly as
memory is tight. Resulting in times closer to cold starts than warm starts.

IIRC the boxes i am using have an onboard video compliments of intel.

All my testing is done on clean installs. A PC that you use for dev is
always going to be bloated with crap, and any app you run on it is
going to be slow. Same for running CAD apps.

However, I do have a few .net applications that i do run on my dev
machine for support reasons, some of which are quite big, and the
start times of all of those are quite good to. Mind you, I am going to
go and test cold start times of those now!!

Quote:

BTW, there is tonnes of information out there on
how to reduce cold start times of app's. In fact MSDN mag did an
article on such not so long ago.

Yes, there are things you can do to improve cold (and warm) start times ...
but these times are for a "Hello World" app, which doesn't leave many
options for improvement.

If you are doing .net dev, its worth reading this MSDN mag article.
http://msdn.microsoft.com/msdnmag/issues/06/02/CLRInsideOut/default.aspx

There are some other good ones around too.

Quote:

[...]
Hardware is cheap, development time is quick, results are relatively
robust (you can still write bad code). The whole idea with .net and
java is that you sacrifice some resources for the huge benefits gained
from safe, secure and reliable code.

Safe and secure, maybe, but reliable? Allowing people to be sloppy when
coding is just asking for reliability issues further down the line. The
"ideal" language (IMO) should be strictly typed (no magic float-to-int
conversions for you!), require explicit memory allocation and deallocation
(with a garbage collector there solely to slap you if you forget) and allow
you to get your hands dirty and bit-bash if you want to. Ideally it should
also treat fundamental types as fundamental types - an integer is an
integer, not an object. Basically, make the programmer think about what
(s)he is writing, not just spew out a whole lot of code and make random
changes until it works. Unfortunately, the trend seems to be away from every
one of these aspects and towards allowing - even encouraging - poor
programming practices. While in the short term this may seem like a good
solution, 5 years down the line you'll end up with millions of lines of
poorly written code just held together by comments such as "I don't know why
the following line is needed but things break if it's removed".

/me gets off his soapbox Smile

You will always get programmers that write bad code, in any language.
..net and java are helping the cause by taking care of that aspect as
much as possible.

Quote:

[...]
Fair point. I don't do FP stuff. Things such as casting classes to
binary buffers can be slow, but by marshalling to unmanaged and back
it is real fast. What's great about that is the marshaller will not
let you exceed the bounds of the array. You cant overrun a buffer. Big
plus. Does not matter how bad you code, you cant do it. It won't let
you. This is just one of the benefits. I challenge anyone to tell me
that they have not had a buffer overrun, even if it was found before
production.

I can't recall the last time I had a buffer overrun in any of my Delphi
code. I have had the odd one when mixing Delphi and inline assembler (the
overflow in the assembler part), but assembler is assembler and those things
happen Smile

In my C++ code, I've had the odd one in parts which I've been
aggressively optimizing (as in "we need to squeeze more performance out of
this procedure, new is slowing us down, so lets coalesce all the unrelated
new calls into a single malloc and bitbash some things around" aggressive)
but not AFAICR in "normal" code. In these cases, a managed language would
have prevented the buffer overflows simply by not allowing me to optimize so
aggressively. Not exactly a plus in that case.

The reason for this IMO is that I've always been quite conscious of buffer
overruns and the like, coming from an assembly and software security
background. Of course, I can't say I've never had one - my memory doesn't go
back far enough, and I'm pretty certain that when I was starting programming
I overflowed a few buffers (either accidentally or on purpose ...).
Defensive programming beats a safety net any day of the week - a (prevented)
buffer overflow in a .NET application usually results in the application
crashing or being terminated. While this is better than a buffer overflow,
it's better still that the app figures out beforehand that the buffer is too
small and handles it gracefully. Additionally, most C/C++ compilers now
support buffer overflow detection with guard words. While this results in
guaranteed termination of the program (rather than possible recovery with an
exception), the result is not all that different to an exception firing
where you did not anticipate it happening.

The biggest problem I've found is that, although you can code a .NET
to be fast, it's not encouraged. A lot of the things that make .NET
development easy also make the resulting application slow. The end
result of this is things like ATI's CCC - massive memory use, slow
startup times, laggy interface, etc etc. While I know that CCC is
not representitive of a "good" .NET app, it is representitive of a
vast majority of .NET apps.

I wonder what agent uses.

As far as I can tell, it uses MSVC (and wxWindows for the gui). It's a
combination of C and C++. Though this is just from a quick glance through
the executable using notepad - it may be being crafty :)

Currently in my process list (Sysinternals)
I have Agent at 10MB, followed by explorer(Win GUI shell) at 13MB, and
Visual Studio 2005 at 40Mb.

Heh, Explorer on this computer is at 17 MB - tis what you get when you don't
log off for 9 days ... Biggest memory users at the moment are Opera (103
MB), Delphi 7 (35 MB), OE (31 MB). However, I wouldn't consider Opera
bloated - I've got about 25 tabs open across 2 windows, and then the cached
renderings for the previous page, plus cached files ... Delphi and OE are
also quite "busy", and the memory is being put to good use. The award for
bloat (being defined as memory used for no good purpose) on my computer goes
to the annoying ATI tray icon that just won't go away. It's currently using
up 7 MB to display an icon in the tray that if I double-click on it starts
up CCC.

Those values were for Vista.

Quote:

[...]
While I can't say I've run into a problem that *can't* be worked
around, some bugs (mainly in the 1.0 and 1.1 era) have required
significant and/or ugly workarounds (which had to be developed using
trial and error). One of the things I love about Borland's VCL is
that you get the source code, which means you can easily trace into
the VCL and see where something is going wrong. This makes it much
easier to develop workarounds compared to developing them for .NET
where if you tell MS "{x} doesn't work correctly" you just get the
response "don't do {x}, and it may be fixed in a future service
pack". At which point, if doing {x} is important to your code, you
have to start the tedious process of black-box debugging the
framework. Reflector can help a bit if you've narrowed it down, but
it's still nowhere as nice as being able to trace into the code.

Maybe that's where I differ. I don't want the source code. I don't
care about it. The last thing I want to do is spend time learning my
way through some library. I just don't have time.

I'm coming somewhat from the same direction but with different experiences
... I don't have time to be trying to second-guess what's happening inside a
library. If an application isn't behaving as it should, there's either a bug
in my code or a bug in the library (or very occasionally a bug in the
compiler). Maybe I've just been unlucky with hitting lots of .NET framework
bugs, but I'm pretty sure I've spent more time in the last couple of years
trying to isolate and work around .NET bugs than I've spent tracing through
the VCL source code (and it's not due to spending a lack of time with VCL).
Since I've written quite a few Delphi components I already knew (or had to
know) what a typical VCL component looks and acts like. Since the VCL
follows the same rules as the components I write, tracing through it is
pretty easy.

[...]

The Real Andy
Guest

Tue Feb 20, 2007 12:10 am

On Tue, 20 Feb 2007 08:06:28 +1000, The Real Andy
<therealandy_at_nospam.com> wrote:

Quote:

On Tue, 20 Feb 2007 03:21:06 +1100, "Michael Brown"
see_at_signature.below> wrote:

The Real Andy wrote:
Michael Brown wrote:
[...]

%<

BTW: WCF was microsofts benchmark test for using c# internally. WCF
was written completely in managed code. Its only a matter of time
before your PC will have to run the .net framework as MS ramps up
internal development in .net. It would be interesting to know if Vista
uses any .net framework, because I cant see it load. Vista starts
pretty quickly too, and .net apps seem to boot fast on vista.

Frithiof Andreas Jensen
Guest

Tue Feb 20, 2007 10:04 am

"Joel Kolstad" <JKolstad71HatesSpam_at_yahoo.com> wrote in message
news:12tjrntkv4p6fa6_at_corp.supernews.com...

Quote:

"Homer J Simpson" <nobody_at_nowhere.com> wrote in message
news:xZvBh.84639$Y6.80597_at_edtnps89...
Removing and reinstalling software may lead to corruption.

True enough, although when that happens it's an easy way to know that the
piece of software is crap and you shouldn't bother using it if at all
possible!

If the software is crap to begin with, why do you expect the uninstaller to
work??

MassiveProng
Guest

Wed Feb 21, 2007 1:16 am

On Mon, 19 Feb 2007 18:48:49 +1000, The Real Andy
<therealandy_at_nospam.com> Gave us:

Quote:

On Sun, 18 Feb 2007 18:28:28 -0800, MassiveProng
MassiveProng_at_thebarattheendoftheuniverse.org> wrote:

On Mon, 19 Feb 2007 13:18:52 +1100, "Michael Brown"
see_at_signature.below> Gave us:

/how Borland "lost" the C++ market

They were unable to compete in the "visual" based development realm.

I agree, and that is when most people gave up on Borland. MFC was
always ahead (even if it was crap) and the OWL compatibility debacle
in the early 90's (IIRC) was just a plain fucken pain in the arse.

Paradox was one hell of a relational database.

Geoff
Guest

Sun Apr 01, 2007 11:10 pm

Genome wrote:

Quote:

"Jim Thompson" <To-Email-Use-The-Envelope-Icon_at_My-Web-Site.com> wrote
in message news:k61ct2t60icdg2geptsgpg9uevea065jn8_at_4ax.com...
I downloaded a calendar program that also installed ".NET Framework"

I uninstalled the calendar... pure crap.

Does ".NET Framework" have any usefulness, or should I uninstall it
as well?

...Jim Thompson

No..... your computer worked before it was installed your computer
will work after you get rid of it.

I know three fifths of bugger all about this stuff but .NET is some
new MicroCrap crap which is another layer of shit MicroCrap are
layering on top of their other crap to 'consolidate' programming
under Windows.

It's essential a run-time library for the increasing number of applications
that use it's features. If you use XP or Vista you will need .NET
eventually. It does no harm.

geoff

Mike Monett
Guest

Sun Apr 01, 2007 11:40 pm

"Geoff" <geoff_at_nospam-paf.co.nz> wrote:

Quote:

I know three fifths of bugger all about this stuff but .NET is some
new MicroCrap crap which is another layer of shit MicroCrap are
layering on top of their other crap to 'consolidate' programming
under Windows.

It's essential a run-time library for the increasing number of
applications that use it's features. If you use XP or Vista you will
need .NET eventually. It does no harm.

geoff

..NET is the stupidist crap MS has come up with. It clogs your system with
unwanted files that cannot be moved. It compiles the application before
running it. This increases the load time on first use. It has to do this
again when you update the software, or any time it feels like it. The code
is bloated and slow, and probably full of bugs. I don't need to waste my
time finding out where they are.

Anyone who writes software in .NET is demonstrating their amateur status
and corresponding incompetence. I don't need to waste my time with code
written by amateurs, and .NET clearly shows who they are.

Whenever I'm looking for applications, I disregard any application written
in .NET, and continue looking for code written by professionals.

One of the authors in the LTspice forum generated a MOSFET model program
using .NET. He recently changed it to a stand-alone exe. This shows .NET is
not needed, and how easy it is to get rid of it.

Regards,

Mike Monett

Lionel
Guest

Mon Apr 02, 2007 12:04 am

On Sun, 01 Apr 2007 22:40:18 +0000, Mike Monett <No_at_email.adr> wrote:

Quote:

"Geoff" <geoff_at_nospam-paf.co.nz> wrote:

I know three fifths of bugger all about this stuff but .NET is some
new MicroCrap crap which is another layer of shit MicroCrap are
layering on top of their other crap to 'consolidate' programming
under Windows.

It's essential a run-time library for the increasing number of
applications that use it's features. If you use XP or Vista you will
need .NET eventually. It does no harm.

geoff

.NET is the stupidist crap MS has come up with. It clogs your system with
unwanted files that cannot be moved. It compiles the application before
running it. This increases the load time on first use. It has to do this
again when you update the software, or any time it feels like it. The code
is bloated and slow, and probably full of bugs. I don't need to waste my
time finding out where they are.

Anyone who writes software in .NET is demonstrating their amateur status
and corresponding incompetence. I don't need to waste my time with code
written by amateurs, and .NET clearly shows who they are.

Whenever I'm looking for applications, I disregard any application written
in .NET, and continue looking for code written by professionals.

<applause>

Damn right.

--
W "Some people are alive only because it is illegal to kill them."
. | ,. w ,
\|/ \|/ Perna condita delenda est
---^----^---------------------------------------------------------------

Martin Riddle
Guest

Mon Apr 02, 2007 2:07 am

"Mike Monett" <No_at_email.adr> wrote in message
news:Xns9905BDEFF407FNoemailadr_at_208.49.80.251...

Quote:

"Geoff" <geoff_at_nospam-paf.co.nz> wrote:

I know three fifths of bugger all about this stuff but .NET is some
new MicroCrap crap which is another layer of shit MicroCrap are
layering on top of their other crap to 'consolidate' programming
under Windows.

It's essential a run-time library for the increasing number of
applications that use it's features. If you use XP or Vista you will
need .NET eventually. It does no harm.

geoff

.NET is the stupidist crap MS has come up with. It clogs your system with
unwanted files that cannot be moved. It compiles the application before
running it. This increases the load time on first use. It has to do this
again when you update the software, or any time it feels like it. The code
is bloated and slow, and probably full of bugs. I don't need to waste my
time finding out where they are.

Anyone who writes software in .NET is demonstrating their amateur status
and corresponding incompetence. I don't need to waste my time with code
written by amateurs, and .NET clearly shows who they are.

Whenever I'm looking for applications, I disregard any application written
in .NET, and continue looking for code written by professionals.

One of the authors in the LTspice forum generated a MOSFET model program
using .NET. He recently changed it to a stand-alone exe. This shows .NET
is
not needed, and how easy it is to get rid of it.

Regards,

Mike Monett

If you compile a DLL in the latest Visual Studio tools, you need to have
..Net loaded on the target machine. Better dll handeling.

Cheers

Jamie
Guest

Mon Apr 02, 2007 2:40 am

Mike Monett wrote:

Quote:

"Geoff" <geoff_at_nospam-paf.co.nz> wrote:

I know three fifths of bugger all about this stuff but .NET is some
new MicroCrap crap which is another layer of shit MicroCrap are
layering on top of their other crap to 'consolidate' programming
under Windows.

It's essential a run-time library for the increasing number of
applications that use it's features. If you use XP or Vista you will
need .NET eventually. It does no harm.

geoff

.NET is the stupidist crap MS has come up with. It clogs your system with
unwanted files that cannot be moved. It compiles the application before
running it. This increases the load time on first use. It has to do this
again when you update the software, or any time it feels like it. The code
is bloated and slow, and probably full of bugs. I don't need to waste my
time finding out where they are.

Anyone who writes software in .NET is demonstrating their amateur status
and corresponding incompetence. I don't need to waste my time with code
written by amateurs, and .NET clearly shows who they are.

Whenever I'm looking for applications, I disregard any application written
in .NET, and continue looking for code written by professionals.

One of the authors in the LTspice forum generated a MOSFET model program
using .NET. He recently changed it to a stand-alone exe. This shows .NET is
not needed, and how easy it is to get rid of it.

Regards,

Mike Monett

now wait a second, you can make a net app look like xxxx.EXE on start up..

so, do you really know if it wasn't NET?
And don't get me wrong, I write software my self, .NET is the biggest
disappointment from MS I have ever seen. what a piece of crap. And I
agree with you on the fact about wantabe programmers and those that
really are.
It's just a sorry way of saying "I'm not a VB programmer", you might as
well be one, what's the difference. I haven't really check performance
however, I would be willing to bet that VB is faster! at least it can
compile to some what native code to some degree.
I use C++ and Delphi mostly my self (Win32) on both.

--
"I'm never wrong, once i thought i was, but was mistaken"
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5

Paul Hovnanian P.E.
Guest

Mon Apr 02, 2007 3:48 am

Just say Nyet to NET.

--
Paul Hovnanian mailto:Paul_at_Hovnanian.com
------------------------------------------------------------------
Due to recent budget cuts, the light at the end of the tunnel has
temporarily been turned off.

Tom Del Rosso
Guest

Mon Apr 02, 2007 3:55 am

"Mike Monett" <No_at_email.adr> wrote in message
news:Xns9905BDEFF407FNoemailadr_at_208.49.80.251

Quote:

Anyone who writes software in .NET is demonstrating their amateur
status and corresponding incompetence. I don't need to waste my time
with code written by amateurs, and .NET clearly shows who they are.

In fairness to the programmers, it's probably their managers telling them to
use it.

--

Reply in group, but if emailing add another
zero, and remove the last word.

Homer J Simpson
Guest

Mon Apr 02, 2007 4:08 am

"Jamie" <jamie_ka1lpa_not_valid_after_ka1lpa__at_charter.net> wrote in message
news:g2ZPh.116$xB7.92_at_newsfe12.lga...

Quote:

I use C++ and Delphi mostly my self (Win32) on both.

Hasn't Borland jumped aboard also?