Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

Moving to .NET

Well, Here is the problem. we are going to develop a  complex,  somewhat real time application that is expected run 24/7, with best performance. This is a workstation application that will talk to several hardware instruments from different vendors. Not all the vendors have a API for .NET. Some of them are just direct serial communication and some have COM interfaces. This application will involve lots of multi-threading, communication with hardware and other workstation systems, Database support and Graphics. The developers are all C++ developers,  and mostly done .NET work in their free time. The system will be released somewhere in 2006 or early 2007. Do you guys think we can achieve what we want if we develop the system  completely in .NET / C#. Again, this is not a web application or some business application. This is a time critical, workstation system that will control, multiple hardware instruments from multiple vendors and may involve some complex math calculation and large amount of in-memory data. What do you guys think ? Should we consider developing in .NET ?

Thina Kesavan
Wednesday, July 28, 2004

From experience I can tell you that learning .NET is easy for an experienced Windows C++ programmer.

.NET supports multithreading, using COM components, databases, and graphics.

It doesn't support talking to hardware directly (nor, I think, is their a .NET API for talking to serial ports), but it does support talking to unmanaged C-style DLL APIs (e.g. the Win32 API) ... for example, we're talking to an "unmanaged" DLL which talks to a USB driver.

The fact that it's "somewhat real-time" may be problematic ... in C/C++ the question is "how real-time?" In C/C++ I found that by using high-priority threads I could do soft-real-time (e.g. "most events handled within a second provided CPU utilitization didn't get too high") ... with .NET it may be similar, with the possible complication (I haven't experienced this yet) that everything is suspended whenever/while the garbage-collection runs ... which, if this is a problem, you might be able to work-around by putting time-critical event-handling into non-.NET unmanaged DLLs and/or processes.

As for "24/7" I don't know whether your requirement allow you to achieve near-24/7 by using clustering, nor do I know how nearly you can achieve 24/ with .NET without clustering.

> Do you guys think we can achieve what we want if we develop the system  completely in .NET / C#.

Maybe not completely ... maybe mostly or partially.

Christopher Wells
Wednesday, July 28, 2004

A managed memory environment like .NET (or Java or Python) will start garbage collections of unpredictable length at unpredictable times. Absolutely, utterly unsuited to real-time applications.

You could write some kind of data-processing module or GUI front-end in .NET but the real-time core must be written in C/C++. You should also consider that Windows itself is not a real-time OS, though.

Chris Nahr
Thursday, July 29, 2004

What i meant somewhat realtime is that the application will be constantly collection data / sending back the data ( about 95% of the runnig time ) to the instruments. I guess for that kind of work , windows is ok. We have other similar systems exists that are running on windows, but are completely developed in C++.  The system could be idle when there is no work shift, but when engaged it is expected to be working hard.

Thanks you guys for your comments.

Thina Kesavan
Thursday, July 29, 2004

reuse existing code

Bill Gates
Thursday, July 29, 2004

Regarding UI in .NET I was shocked to read this at ( )

"And if you're developing a Windows GUI app today using Microsoft's "official" latest-and-greatest Windows programming environment, WinForms, you're going to have to start over again in two years to support Longhorn and Avalon. Which explains why WinForms is completely stillborn. Hope you haven't invested too much in it. "

Dont know much about real time stuff, but if your application involves Forms based GUI, so just be careful about the "avalon" and the new windows in case there is a need to port to the new environment.

Shubham Shekhar Singh
Thursday, July 29, 2004

Here's an article on Avalon:

I get the feeling that:

- Avalon classes will be added to the framework
- Old (Winforms) code will still work
- XAML will mean you can write XML to define GUI elements where previously you used the IDE's Visual Designer

Christopher Wells
Friday, July 30, 2004

WinForms simply wraps existing Win32 controls. Of course it can be used on Longhorn, just like existing Win32 apps will run on Longhorn. You only have to rewrite if you want the new Avalon look.

Chris Nahr
Friday, July 30, 2004

Yes, existing WinForms / Win32 stuff will work just fine on Longhorn/Avalon. You will have to update it if you want the very latest "look and feel", but it has *always* been like this.

Be careful about reading Joel's article as absolute truth. It is, at best, an extremely biased opinion piece, written at a time when he was clearly angry (which is all the time recently). Just check out some of the responses it generated.

Monday, August 2, 2004

"... It doesn't support talking to hardware directly (nor, I think, is their a .NET API for talking to serial ports)"

what? No device drivers? Are you off your meds again?
Is it some kind of David Copperfield type magic programming language?

This whole abridged piece of fucking clay isn't worth fixing.

My job is a joke.

Fucking GPF's and thier empowered moron losers..

Master of the universe
Friday, August 6, 2004

"...reuse existing code

Bill Gates
Thursday, July 29, 2004 .."

Keep your busy fingers of my ideas, I may or may not be seeing you in court. XAML my ass.

you (c) .

Master of the universe
Friday, August 6, 2004

Since you are shipping in 2006 or 2007, I highly suggest that you start with the latest beta version of .NET 2005.

It has some nasty windows forms bugs fixed. I hate to say it but .NET 2005 is really a V1.0 product, both 2001 and 2003 feel more like good release cadidates.

P.S. I said FEEL.


Saturday, August 14, 2004

I would not use Windows on any real-time, critical systems. Unix is better, but something like QNX would be best. This does not mean you can't use .Net.. all you need is the rutime for the platform you are deploying on.

That said, we're using Windows services coded in C# to support an ASP .Net web app and we gave the customer a 99.9% uptime SLA...  no problems yet.

Nick Ruisi
Thursday, September 9, 2004

Regarding Joel's 6/13/04 article called "How Microsoft Lost the API War" at
Nemesis wrote on 8/2/04 "Just check out some of the responses it generated. "  So I wanted to post another response to that article (from one of our developers who, unlike me, has actually worked with .NET), and I couldn't find those other responses, so I guess I'll post it in this thread instead.

I am a fairly non-technical software entrepreneur, and the article scared me to death because we've spent a year and counting to rewrite our existing MS Access front-end application (using VBA) to .NET.  (This front-end can talk to a back-end in either Access or SQL Server.)  I had already been regretting the .NET decision, because it is taking so much longer than we thought and we haven't been spending any of that time adding the features that our customers have actually been asking for.  When I voiced my concern to my developer, he responded as follows:

Don't worry about this article, I think Joel doesn't have all his facts straight. I am familiar with Avalon and have already seen how it works in some webcasts. First, Avalon is built on top of the CLR which is .Net "virtual machine". Avalon has something new called XAML (which is a bit complicated for me to explain here) which just extends the UI functionality, but doesn't replace it.

He said "if you're developing a Windows GUI app today using Microsoft's "official" latest-and-greatest Windows programming environment, WinForms, you're going to have to start over again in two years to support Longhorn and Avalon." That's not true at all!!!!
Basically WinForms will integrate very well with Longhorn especially the version coming out next year (which we will be using). We can certainly take advantage of the new features of Avalon, but we don't have to. Most people who aren't very familiar with .Net (he admits not having much time to learn .Net deeply) don't understand very well how these new technologies are tied together.

I do agree that it can get quite overwhelming having to keep up with everything new that is coming out. I personally can't wait for the new release (framework 2.0) because it will make my life so much simpler and provide us with some really cool features. I am sure that Avalon will just give us more options and features to provide to our clients.

When Longhorn is released, we won't have to make another investment. The investment is already made and we will just reap the benefits.

(end of quote)

I sure hope that my guy is right and Joel is wrong, but it seems to me that Joel has been right about an awful lot of things, so maybe I'm just in denial.

I am wondering whether I should just cut my losses and pull the plug on our .NET migration.  We could stay with an MS Access front-end for at least a few more years if had to.  Any advice on that?

Also, our company has only two developers (4 people total; less than $1 million in sales; 140 companies in 15 countries use our product; we've been in business for 5 years).  Does anybody know where I can get a "second opinion" on just how much longer our .NET migration is likely to take, so that I can decide whether it's worth finishing?  Thanks.

Wednesday, November 3, 2004

*  Recent Topics

*  Fog Creek Home