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

  • Thread starter Thread starter consumer62000
  • Start date Start date
Brian said:
Rob,

Yeah, that was my first though as well. But, I took his response as
being relevant to services that have a realtime data acquisition
element to them. Perhaps a service that is collecting data from a
hardware device of some kind.

Depends on the purpose of the data collection. I can totally see how
we'd need realtime for things like antilock brakes or nuclear pile
dampeners, but I wouldn't dare to use Windows or Unix for either of
those applications, because the critical task shouldn't ever be
preempted; I'd design a specific and explicit program and implement it
in hardware and firmware, using non preemptive multitasking, if I used
multitasking at all.

Rob
 
Yes, The mono mcs or the .net csc compiler can produce an application that
will run under the .net runtime and the Mono runtime will run the app under
windows and Linux. Now im not saying that every namespace is compatible from
one to the other but in the last few builds of Mono with their implementation
of windows forms has been an amazing eye opening experience for me. I have
found that most simple windows forms apps will work on both operating systems
and mono just gets better with each release. Just install Microsoft Virtual
PC (Richard I know you have a copy of this), install suse version of linux
(the iso is free), and the mono runtime, after that read a small amount of
documentation on how to use the mono runtime on linux and you can run the
app. It is that easy!
 
I think that this thread may be seriously missing a point. To wit: if an
application has a hard real-time requirement, even if that requirement is
just the need to respond to a "true" real-time system within a fixed time
limit, you're not using the wrong language; you're using the wrong Operating
System.

GC is the least of your problems. There is no way a preemptive of
cooperative multi-tasking OS can guarantee you that your thread won't be
suspended, and it can't guarantee you for how long.

If you have real-time requirements, you need a real-time OS. Windows is not
now, has never been, and has never claimed to be a real-time OS.

That said, there are things you can do with GC in .NET, and with Windows
thread management in general, to mitigate this problem. If the response-time
requirement is merely a target and not a hard requirement, an application
should be able to hit a 1s window, even in .NET with GC.

If it can't, somebody has got either a bad design/implementation or
unreasonable expectations.
 
wecall said:
I think that this thread may be seriously missing a point. To wit: if an
application has a hard real-time requirement, even if that requirement is
just the need to respond to a "true" real-time system within a fixed time
limit, you're not using the wrong language; you're using the wrong Operating
System.

I don't think this thread has particularly missed that point. I seem to
remember several people pointing out (sometimes several times) that
Windows isn't a real-time OS...
 
Kevin,

I fully endorce and agree with your writings. WHile I have recently
committed to VS .Net for all current and future applications (primarily fat
client WIndowsForm apps), the learning curve for .Net is only steep based on
the number of Objects available.

My only frustration is the IDE performance. I have been hoping that there
are some configuration settings that would make my interaction with the IDE
more responsive, but to date no one has been able to help me locate them.
Some contributors to these threads have talked about 3-5 second compile
times. I can only assume that these are for class projects that do not
involve forms. If I am wrong (which I would like to be), I am still seaching
for the best IDE configuration settings.
 
Hi Norm,

Visual Studio.Net's IDE is one of the most massive applications that
Microsoft makes, in terms of what it does in real time, and what it does in
general.

With any software, the more work it does, the more resources (memory and
processor) it consumes. So, one easy way to improve performance is to
upgrade your memory and/or processor.

In addition, you can fine-tune what Visual Studio.Net does while you're
working with it. Use the Tools menu, and the Options dialog box. You can
disable various types of options in there, which, while disabling the
options, does improve performance, as these operations (especially real-time
operations) are no longer being performed.

You can set up the IDE to start with an empty environment to speed up the
load time when you launch Visual Studio.

The following link is about hardware requirements, but also contains a few
other performance tips:

http://msdn.microsoft.com/library/d...ml/vxoriVisualStudioNETSystemRequirements.asp

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Who is Mighty Abbott?
A twin turret scalawag.
 
NormD

3-5 seconds is very reasonable.
I'm working on a multi project solution.
One of the main project which I recompile hourly is about 1.5Mb of source
code (in ~ 100 C# class).
It compiled in 3~5 seconds.
Of course C++ is much slower to compile, one of the reason I favor C#.
But anyway I have a C++ projecvt, as long as I don't modify too many
critical headers it recompile in the same amount of time.

Perhaps you should add some memory to your computer?
 
It has been said several times in this "discussion" that Windows is not a
real-time OS. It is not, and to expect it to behave as if it is is wrong;
wishing doesn't make it so. If you've ever programmed under a real RT OS
you'd know the difference.

A bunch of years ago I needed 1 second servicing on some instruments. The
Windows clock is "interesting" so we used a Nat. Instruments board that was
set to generate a hardware interrupt at 1 second intervals; a hardware clock,
in other words. Interrupt was tied to code that ran to communicate with the
instruments, get data process it, etc.

Do I need to tell you the routine has to finish in under 1 second or the
queue qill build and you'll loose data?

I will admit that how all this is handled under .NET and all that is going
 
(Not sure why you're resurrecting this thread this late, but hey...)

NormD said:
It has been said several times in this "discussion" that Windows is not a
real-time OS. It is not, and to expect it to behave as if it is is wrong;
wishing doesn't make it so. If you've ever programmed under a real RT OS
you'd know the difference.

A bunch of years ago I needed 1 second servicing on some instruments. The
Windows clock is "interesting" so we used a Nat. Instruments board that was
set to generate a hardware interrupt at 1 second intervals; a hardware clock,
in other words. Interrupt was tied to code that ran to communicate with the
instruments, get data process it, etc.

Do I need to tell you the routine has to finish in under 1 second or the
queue qill build and you'll loose data?

Actually, that wouldn't be true in a sensible implementation. There's
no reason why it would always have to finish in under 1 second - just
under 1 second on average (over a reasonably short period of time). I
can envisage situations where an occasional spike would be perfectly
acceptable, so long as the queue didn't build up too far.
 
Last things first. You're correct, of course about the average response, but
then the application design gets more (but not absurdly so) complex. If one
set of data hasn't been processed before the next comes in you'd have to
double buffer (or more, if you're going to allow for more than one overlap
before the system catches up). But it certainly can be done.

As for why I'm "resurrecting this thread this late" I thought some
experiences with RT systems and hardware in a Windows environment might be
useful to someone searching around for information on the subject. I felt
that the 39 year of software and hardware experinece with interfacing
instruments I have might have left me with a little to contribute, even
though (unfortunately) much of it isn't .NET based.
 
Tyrant said:
For the record, by "real-time application" I meant things like
high-speed device drivers and software that must process hundreds or
thousands of transactions per second *without exception.*

That may be your definition, but it is not the accepted/standard definition.

Real-time does not deal w/ 'speed', fast or slow. Real-time is simply
and explicitly a system that can guarantee event/interrupt response
within a defined time.

For example, you could have a system w/ a guaranteed maximum interrupt
latency of < 1 hr., and it is therefore "real-time".
 
Chris said:
Who would use an interpreted language for real time processing? Doesn't
sound like someone knew what they were doing when they chose a language
to meet their requirements.

Interpreted language has nothing to do w/ "real-time". The underlying
hardware (and OS) are used to define "real-time" or not.

Let's understand that REAL TIME HAS NOTHING TO DO WITH SPEED.
 
Hi Heath,

I am developing a windows application using visual studio.net 2003. I am
using bundled version of Crystal Report for reporting purpose. I dont have
seperate licence version of Crystal Report.

My main concern is can I deploy this application at client side, bacause
client is only having licence version of .NET Frameword 1.1. So if I deploy
this application at client side, will my crystal report work properly? Or
client need licence version of Crystal Report.

Thanks in advance.
Shailesh
 
Hi Tim,

I am developing a windows application using visual studio.net 2003. I am
using bundled version of Crystal Report for reporting purpose. I dont have
seperate licence version of Crystal Report.

My main concern is can I deploy this application at client side, bacause
client is only having licence version of .NET Frameword 1.1. So if I deploy
this application at client side, will my crystal report work properly? Or
client need licence version of Crystal Report.

Thanks in advance.
Shailesh
 
Hi Jon,

I am developing a windows application using visual studio.net 2003. I am
using bundled version of Crystal Report for reporting purpose. I dont have
seperate licence version of Crystal Report.

My main concern is can I deploy this application at client side, bacause
client is only having licence version of .NET Frameword 1.1. So if I deploy
this application at client side, will my crystal report work properly? Or
client need licence version of Crystal Report.

Thanks in advance.
Shailesh
 
Hi William,

I am developing a windows application using visual studio.net 2003. I am
using bundled version of Crystal Report for reporting purpose. I dont have
seperate licence version of Crystal Report.

My main concern is can I deploy this application at client side, bacause
client is only having licence version of .NET Frameword 1.1. So if I deploy
this application at client side, will my crystal report work properly? Or
client need licence version of Crystal Report.

Thanks in advance.
Shailesh
 
Hi Sahil,

I am developing a windows application using visual studio.net 2003. I am
using bundled version of Crystal Report for reporting purpose. I dont have
seperate licence version of Crystal Report.

My main concern is can I deploy this application at client side, bacause
client is only having licence version of .NET Frameword 1.1. So if I deploy
this application at client side, will my crystal report work properly? Or
client need licence version of Crystal Report.

Thanks in advance.
Shailesh

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]
 
Hi Richard,

I am developing a windows application using visual studio.net 2003. I am
using bundled version of Crystal Report for reporting purpose. I dont have
seperate licence version of Crystal Report.

My main concern is can I deploy this application at client side, bacause
client is only having licence version of .NET Frameword 1.1. So if I deploy
this application at client side, will my crystal report work properly? Or
client need licence version of Crystal Report.

Thanks in advance.
Shailesh
 
Hey Shailesh,

You don't have to post a *separate* message to EVERYONE in a message
thread for them to be able to read it ! Duplicate, triplicate posts in
the same thread, rather than getting you a suitable response, will get
you nothing but admonitions from everyone. The same way that
crossposting to different newsgroups will get you labelled as a
spammer.

However, this is not an admonition...

I see that your question has nothing to do with the Subject line of the
thread, notwithstanding what all may have been discussed in this very
long thread. You would be well advised to "Start a new topic" in this
newsgroup.

Regards,

Cerebrus.
 
Back
Top