.NET SUCKS --- READ FOLLOWING. MICROSOFT IS A SUCKY CO

  • Thread starter Thread starter consumer62000
  • Start date Start date
Is it just me or Microsoft, DevelopMentor and others were taken over by
marketing people. One argues that some programs don't need speed (since
when
I wonder). The other is argues that you need ". you need a real-time
operating system.." for resolution of seconds. Windows is pretty good
system
Click to expand...
It's just Troll effect ;-)
Of course everyone think perf is important but suddenly to wrong the Troll
they say it doesn't matter.
I don't get it either ;-)
And no need to go for such statment, the truth is simply: .NET is good and
performs well ;-)
if you do not use s..ty .Net, Java etc., it is not unheard of a program on
Windows measuring their operations in millisecond and even microseconds
(.Net
excluded). Maybe Microsoft engineers should pull their heads out of .Net
ass
and try to save the great system they have. Yes it is true Microsoft is
dropping their support for ANSI C++ (see "sprtintf depreciated" warning in
VC8) - too bad I really liked Windows last 10 years or so. Oh well there's
always Linux.
Click to expand...
Ha.. I see, you've been taken over by linux people ;-)
1st, if anything, MS is certainly NOT dropping its support for C++
(although, personally, I can't care less), read that:
..... uh.. CodeProject down.. anyway, they have made huge commitment to C++
and it shows in .NET 2.0!

2nd, about your sprintf exemple, tss... again it's very much blind linux
attitude (read uninformed MS hating). what about reading MSDN documentation
to know why?
I copied / paste it for you below
Security Remarks
The first argument, buffer, must be large enough to hold the formatted
version of format and the trailing NULL ('\0') character otherwise a buffer
overrun may occur.

This can lead to a denial of service attack against the application if an
access violation occurs, or in the worst case, allow an attacker to inject
executable code into your process.

This is especially true if buffer is a stack-based buffer.

Be also aware of the dangers of a user or application providing format as a
variable. The following example is dangerous because the attacker may set
szTemplate to "%90s%10s" which will create a 100-byte string:

void test(char *szTemplate,char *szData1, char *szData2) {
char buf[BUFFER_SIZE];
sprintf(buf,szTemplate,szData1,szData2);
}Consider using _snprintf instead, or consider using an appropriate
strsafe.h function.

For more information, see Safe String Functions.
 
your comments and the title sound a bit immature ,

I have used Java , C# , C and C++ ( for over 15 years ) , and C# with .NET
is a saviour.

- In your scenario 1 second should not be a problem Garbage collection is
measured in ms
- There are different types of garbage collection ie server vs client . In
most cases it will wait till the system is idle before collecting . It will
only force a collection if your machine is at 100% cpu for long periods of
time . In C++ apps what would happen if you r app runs at 100% CPU for long
periods is until it consummes the heap and crashes. Or you need to have load
dependent free's , not an easy task .

It should be noted there are cases say you had a 1ms requirement that C# (or
java) could not meet . You pretty much have to write these as drivers anyway
with higher level hooks for easier to write languages.

My tip try it for a while.

Regards ,

Ben
 
Jeez,

I think you are all missing the point!
I too had to build an interface in which guaranteed response and indeed
split second timing was crucial. For that I also build a hardware buffer out
of a PLC that went then into a custom built PCI interface built using an 8255
where I would queue my events which were then processed as fast as possible.

BUT! That's how it goes when you need that!
A multitasking operating system is a whole other story and a necessity for
99 percent or applications. The .Net library and in perticular the CLR are
incredibly useful and powerful for almost everything else I do and I am
thankful for it.

If you don't like it then build your own library cause for RAD (the
necessity nowadays) you need something like this.
The .Net lib is not only useful for RAD but it's very flexible and suits
many diff needs.
The CLR and the GC are a great idea and if you put them to use and test them
you will find that your concerns are a load of paranoid crap. The real
scenario is that most applications need to go hard for a short time and then
there are frequent moments of idle time which is a better time to do things.
The CLR GC mechanism makes very good use of this and it's stable as mount
fricken fuji from my experience.

It's bloody open source too (mostly). You're just nit picking?

As much as I dislike some of MS developments I have found after some
experimentation that the CLR is a good thing and the windows kernel now days
is quite good.

Do you think there is any one platform that you will build anything and
everything on? Do you suppose you will write a video display driver for a
betacam interface in C# or a http user agent in Assembler????

Also, consider what happens on a system such as you describe when a glitch
occurs? The whole damn system goes down my friend. Period. Nothing moves.

Congrats to the CLR dev team and forget about what these monkeys say.
Peace.

Sahil Malik said:
I agree with you. I had to implement a system that needed realtime data
input from a device, the way we did it was we fabricated a peice of hardware
that would buffer the data and keep it ready for the PC to read in a .. umm
... lossless manner ;-) .. KISS@Work.

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
----------------------------------------------------------------------------

Richard Blewett said:
So how often have you noticed the GC taking approching 1 second? I've
never seen it and I've been able to allocate 40,000,000 objects per second
that will cause alot of GCs.

If you are talking about a system that mjust *never* take longer than a
second then you shouldn't be using Windows or most versions of Unix - you
need a realtime operating system that guarantees that it won't spend a
whole bunch of time housekeeping.

You must be writing a branch of software that is very unlike many many
busniess apps that need to retieve data and perform complex processing on
it but don;t require realtime like guarantees of reponse times.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Let me tell you a scenario and you will see what I mean.
There is a large application that has communication with a real time
system . The app has to respond to the requests in no more than 1 s.
The app is a C# .NET app and everything is fine and everyone at
Microsoft is happy that they forced their "new" platform down someone's
throat.

Now imagine a scenario where the GC has to collect the memory. Well,
when GC runs all the threads are suspended and there is no response to
the incoming requests and application fails a critical requirement.

Well,any MS people here who can defend their sucky product,
I know they will say "don't use .NET for this or that...use C or C++
etc"
My q to them is why did you create .NET then?


[microsoft.public.dotnet.framework]
Click to expand...
Click to expand...
 
This very attitude annoys me in Microsoft. Microsoft assumes that it deals
with morons. I do know 1000 reasons not to use sprintf: not type safe, buffer
overrun, bla bla bla, I know 1 reason to use it - speed (yes I checked many
times against streams). I think I am able to decide for myself all the pros
and cons. The example I gave is very symptomatic of where Microsoft is going
with .Net. sprintf is part of ANSI C - Microsoft does not care as long as it
is not part of their marketing strategy. It is becoming more and more
difficult to convince employers to stay with Microsoft technologies because
of such decisions.


Lloyd Dupont said:
Is it just me or Microsoft, DevelopMentor and others were taken over by
marketing people. One argues that some programs don't need speed (since
when
I wonder). The other is argues that you need ". you need a real-time
operating system.." for resolution of seconds. Windows is pretty good
system
Click to expand...
It's just Troll effect ;-)
Of course everyone think perf is important but suddenly to wrong the Troll
they say it doesn't matter.
I don't get it either ;-)
And no need to go for such statment, the truth is simply: .NET is good and
performs well ;-)
if you do not use s..ty .Net, Java etc., it is not unheard of a program on
Windows measuring their operations in millisecond and even microseconds
(.Net
excluded). Maybe Microsoft engineers should pull their heads out of .Net
ass
and try to save the great system they have. Yes it is true Microsoft is
dropping their support for ANSI C++ (see "sprtintf depreciated" warning in
VC8) - too bad I really liked Windows last 10 years or so. Oh well there's
always Linux.
Click to expand...
Ha.. I see, you've been taken over by linux people ;-)
1st, if anything, MS is certainly NOT dropping its support for C++
(although, personally, I can't care less), read that:
..... uh.. CodeProject down.. anyway, they have made huge commitment to C++
and it shows in .NET 2.0!

2nd, about your sprintf exemple, tss... again it's very much blind linux
attitude (read uninformed MS hating). what about reading MSDN documentation
to know why?
I copied / paste it for you below
Security Remarks
The first argument, buffer, must be large enough to hold the formatted
version of format and the trailing NULL ('\0') character otherwise a buffer
overrun may occur.

This can lead to a denial of service attack against the application if an
access violation occurs, or in the worst case, allow an attacker to inject
executable code into your process.

This is especially true if buffer is a stack-based buffer.

Be also aware of the dangers of a user or application providing format as a
variable. The following example is dangerous because the attacker may set
szTemplate to "%90s%10s" which will create a 100-byte string:

void test(char *szTemplate,char *szData1, char *szData2) {
char buf[BUFFER_SIZE];
sprintf(buf,szTemplate,szData1,szData2);
}Consider using _snprintf instead, or consider using an appropriate
strsafe.h function.

For more information, see Safe String Functions.
Click to expand...
 
AAO said:
This very attitude annoys me in Microsoft. Microsoft assumes that it deals
with morons. I do know 1000 reasons not to use sprintf: not type safe,
buffer
overrun, bla bla bla, I know 1 reason to use it - speed (yes I checked
many
times against streams). I think I am able to decide for myself all the
pros
and cons. The example I gave is very symptomatic of where Microsoft is
going
with .Net. sprintf is part of ANSI C - Microsoft does not care as long as
it
is not part of their marketing strategy. It is becoming more and more
difficult to convince employers to stay with Microsoft technologies
because
of such decisions.
Click to expand...
The fact the Microsoft has developed a library of safe string handling
functions is annoying to you?
The intent is to offer the new library as a safe alternative, then submit it
for inclusion in the C++ standard. That's the way languages evolve.
 
AAO said:
This very attitude annoys me in Microsoft. Microsoft assumes that it deals
with morons. I do know 1000 reasons not to use sprintf: not type safe, buffer
overrun, bla bla bla, I know 1 reason to use it - speed (yes I checked many
times against streams). I think I am able to decide for myself all the pros
and cons. The example I gave is very symptomatic of where Microsoft is going
with .Net. sprintf is part of ANSI C - Microsoft does not care as long as it
is not part of their marketing strategy. It is becoming more and more
difficult to convince employers to stay with Microsoft technologies because
of such decisions.
Click to expand...
And as a competent developer who does know the difference, your unable
to add the C4996 warning to the "Disable Specific Warnings" settings?

You'd rather let those people who aren't aware of the 1000 reasons not
to use sprintf to carry on blindly producing code which could easily
contain buffer overflows?

Damien
 
Okay, so YOU know all this stuff because you've been developing since
before fire became "the next big thing." But what about the
inexperienced developer? Is it a bad attitide that drives Microsoft to
ensure that potential security loopholes are documented so that new
developers without YOUR experience know what to watch out for? I
thought Microsoft did all that extra documentation as part of its
effort to increase the security of its operating systems and
development tools after a series of security vulnerabilities were
exploited by hackers. Since SP2, we've seen nothing but an escalation
in the security of Windows, and the documentation for development tools
has been expanded to warn users against potential loopholes. That's a
GOOD thing, in my book. If you're taking offense to it, I suggest a
nice course in humility.

Microsoft isn't deprecating sprintf. They're telling you that, if not
properly used, it can open a security loophole in your application.
They go on to say that you should consider a different function that
does something similar, but without the security loophole; if that
function fails to meet your needs, and you're aware of the risks and
willing to accept them, go ahead and use sprintf. (That is, generally,
what "consider using" means.) However, you should not that (1) they
aren't dropping it from the libraries and (2) no one is FORCING you to
use anything. Your code will still compile.

You seem to be making a very broad generalization, and one that is
based on speculation and not fact.

If you're having difficulty convincing an employer to stay with
Microsoft because they think Microsoft is dropping support for ANSI
C++, you should have done one thing first: Either substantiate or
refute those claims with hard facts. You have NO facts to substantiate
the claim that Microsoft is dropping support for ANSI C++. If your
employer thinks Microsoft is doing so, you need to find out where they
heard that and whether or not it's true. Chances are, it's more
anti-Microsoft sentiment generated by people who dislike Microsoft
because they think it's cool to do so and makes them a rebel.
 
I am happy for MS people developing safe handling libraries, good for them.
What annoys me is that Microsoft forces me to use it. Even before .Net
programming was not limited to MFC.
 
Yeah, but I am a bit too dense to catch it. :-)

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
I can disable warning. I can even probably reimplement sprintf if ms drops
it. That is not the point. Depreciated means (I think) going away, so release
after next it is not going to be supported. There is always people "who
aren't aware" , if we were structuring our development life around them we
would not get anywhere.
 
Microsoft isn't *forcing* you to do anything. You don't like .NET? Go
with Java. Go with Borland Delphi (if it's still around). Heck. Go with
VB 6.0 or with any number of standalone C++ compilers out there. There
are lots of alternatives to .NET that target Windows.

Point of fact, Microsoft CAN'T force you to do anything. They can
strongly suggest that you move along with a technology because it's
where they're going, but that doesn't mean you have to follow like a
lemming.
 
In the past everything marked depreciated was removed in next release. So
when I see "sprintf depreciated" warning I assume VC9 will not support it.
Which forces me to search alternatives. As for employer convincing it is
Microsoft own doing. First "dlls are the best" then it is "dll hell", then
COM is the the only way to go - after "COM is dead", "VB almost as fast" -
"you have to rewrite it". Now new best thigh is .Net, for how long I wonder.
 
First it looks like you kind of complain technology keeps evolving (too
fast)...
While I understand that from my grand-mother, I think it's not a good
attitude from an IT professional.
Thanks technology keeps evolving! I wish it would be the same for car
engine, so we could all have hybrid-hydrogen car by now 8-D

Then I think you should take it easy.
If it really bother you, why 'convince' your management to stay with MS
(against your apparent inner desire), switch to Linux, why not?
That would give you a good experience of it ;-)
And then either of these alternative might happen:
1. you'll be satisfied
2. you'll come back to MS wiser ;-)

And certainly you'll send them a clear message: "keep sprintf, you bastard!"
;-)
 
You work in the software industry, and you're complaining about the
fact that technology improves rapidly? Would you rather that the
technology never improved? That it remained what it was 10 years ago?
When DLLS, COM, and Visual Basic didn't exist?

As fast as processor technology evolves, software and development tools
evolve. If they didn't, we'd be trying to write modern applications
using tools like QuickBasic 4.5. You HAVE to expect that. Technology
improves because people learn from their mistakes. DLLs were actually a
great thing at the time. They solved a lot of problems. But some issues
didn't come to light until we had lots of developers creating them and
trying to deploy them to the same machine. So then COM was developed to
address those issues and more. It provided solutions for many of the
DLL issues and garbage collection, and made it easier to develop
applications that could work together. But we found, over time, that it
had serious flaws too. So then the time came to address the flaws in
COM. The next logical evolution was .NET. Sure, Microsoft could have
just stuck with COM, but why? The opportunity had arisen to see the
technology evolve. When it comes to survival, you can embrace either
evolution or extinction. Microsoft chose evolution.

..NET is a great boon to productivity, and will be for some time to
come. It's no silver bullet, but then Microsoft never claimed that it
was. They know it has flaws; there's no such thing as perfect code (at
least, not on the scale of the Framework). And if you don't like the
fact that the technology has evolved and will consider to do so, you're
just setting yourself up for a lot of misery down the road. Technology
WILL change. It HAS to change. That's the nature of our industry.
 
I actually compiled some projects in VC8. As for MSDN - it does not say
anything on the subject.
 
Jon Skeet said:
Okay, here's my first entry. It takes 370MB (according to task manager)
and the garbage collection takes between 1.5 and 2 seconds on my
(fairly fast) box. Oh, and don't worry - I'd never normally write code
like this :)
Click to expand...

Interesting. I'm getting over 3 seconds at this one.

However, I've failed to get anything succesful yet that doesn't basically
copy this. Everything I've produced that doesn't work this way either runs
out of memory or causes stack overflows. I'll keep at it though.
 
Back
Top