|
Are there any .Net client-side applications?
Are there any .Net applications out there from anyone besides MS? My understanding was the runtime was still very large and difficult to install, and would only work on XP, etc. I understand .Net is great for web sites, etc - but if I want to release a small shareware app - I'm thinking .Net is still a ways off.
Jeff
Tuesday, May 18, 2004
The .NET runtime works all the way back to Win98.
The install is on the big side; people on modems probably won't have it installed.
From where I'm sitting, a lot of companies are going whole hog into .NET development, since it's fairly easy to roll the runtime out to their desktops. For commercial shrinkwrap apps, not so much yet.
If you're shipping on a CD, installing the runtime is easy. If you're doing downloads, you've got a bit more of a problem.
Chris Tavares
Tuesday, May 18, 2004
I have an application running in the background right now that's a shrinkwrapped (downloaded) commercial application. It's Beyond TV from Snapstream ( www.snapstream.com )
It works good. The installer downloads all the needed components (including the .NET runtime) if you don't have it installed.
If you're doing a small shareware application you might want to stay away from it. The 20MB runtime download makes your application not quite so small. But then it really depends on your target audience.
Almost Anonymous
Tuesday, May 18, 2004
My company has one, and we're about a month away from a second. However, we aren't doing shrinkwrap, and our customers are not normal people. Most have broadband, and don't care if they have to download it.
If you're doing shareware (as mentioned), I think you'll have a harder time, because that would suggest that average Joe Modem will be installing your software, and .NET saturation is still only 30-35%.
Walt
Tuesday, May 18, 2004
Check out NewsGator and IntraVNews. Both are .net based rss readers.
Anon
Tuesday, May 18, 2004
Vault
SharpReader
Eric Sink
Tuesday, May 18, 2004
I think the size of the .NET installation is a red herring.
The scarcity of .NET fat client apps can be explained by answering the simple question "What advantage does .NET provide for fat client development?"
While there is no doubt that the .NET platform is a tremendous productivity gain for ASP/web service shops, and is a medium productivity leap for multi-tier business developers, it is much less obvious for fat client development where highly productive tools like Delphi or Visual Basic already exist (or even Visual C++). Add to that the fact that there is a highly robust multitude of components of every sort for those platforms, and again it is evident that.NET has an uphill battle (especially when many teams have purchased a library of components, and have an existing code base in the alternate language). From a client perspective there are few computer users who will perceive managed code as superior to native code, so you don't get a client advantage switching to .NET.
So the answer seems obvious: Many development teams simply haven't been sold on the advantages of .NET for fat clients (at least to a degree that merits a switch). Thus, fewer .NET apps are released.
Dennis Forbes
Tuesday, May 18, 2004
To amplify what Dennis said - we will use dotnet for new applications and will slowly migrate old apps to dotnet over the next several years. Some of the development groups will wait until Whidbey before going whole hog on dotnet.
So, since new apps are few and most apps are improvements over existing apps, a user wouldn't see much in the way of dotnet apps from us for a while.
MilesArcher
Tuesday, May 18, 2004
So are there any advantages that .NET provides for fat client development?
KayJay
Tuesday, May 18, 2004
Sure, there are benefits. There are the benefits of the environment, benefits of the libraries, and benefits of the integration with server-side .NET support (for client/server apps). Don't forget the no-touch deployment benefits, too.
Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, May 18, 2004
We've built a fat client architecture using .NET with downloaded plug-ins, automatic updates, dynamic UI, all sorts of cool stuff, and the basics came together in about four weeks. And building plug-ins on top of it is extremely easy.
So yes, there are benefits. Maybe not enough to throw out everything and re-write, but for new stuff .NET is definately the way to go on Windows.
Chris Tavares
Tuesday, May 18, 2004
Eric Sink said:
"
Vault
SharpReader "
I think the user might have been looking for more shrinkwrap type applications that appeal to the general public.
Vault is aimed squarely at MS developers who are almost guaranteed to be running .NET. (If not developing in it.)
SharpReader is an RSS aggregator; which is still largely the domain of techies.
Take a trip to Best Buy, CompUSA, etc and count the number of applications that require .NET. I think you will find them very low. If existant at all.
Whatever
Tuesday, May 18, 2004
Just because you can do something quickly in .NET doesn't mean that you can do it well. I will also offer that
I think a profound lesson has been provided by the past two decades - Despite the promised silver-bullet productivity benefits of 4GL tools, what is the language/platform that the overwhelming (>95%) majority of commercial software applications are developed in? What platform does Microsoft develop all of their commercial applications in?
Dennis Forbes
Tuesday, May 18, 2004
> I think the user might have been looking
> for more shrinkwrap type applications
> that appeal to the general public.
Yes, that's probably true. Off the top of my head I can't name a single .NET client app which is for normal people.
Eric Sink
Tuesday, May 18, 2004
http://www.gogodatabase.com/ is probably for normal people?
Green Pajamas
Tuesday, May 18, 2004
I was also seriously considering .NET for a shrinkwrap software.
I consider myself to be a better C# programmer than a C++ programmer. If I code in C#, I'd be able to put up the app in days or weeks as compared to weeks or months in C++. My app would be easier to code, less buggier and easier to manage.
But developing in .NET will benefit only me. Admittedly, I would also need to resort to Windows API and COM to perform some of the non-trivial stuff - but that wouldn't be a problem for me either.
The real problem will be for my users. An average user who is mostly limited to Internet Explorer and MSN Messenger wouldn't really appreciate the cost of 20+ MB file to run a < 2 MB software. My primary goal - to make my application as easy-to-use and to make it run out-of-the-box for most users - will diminish somewhere in the background.
Although, I still prefer C# and .NET to any other development platform. I wouldn't go for them - at least at this stage.
Green Pajamas
Tuesday, May 18, 2004
"http://www.gogodatabase.com/ is probably for normal people?"
It appears to be for people who've never heard of MS Access and would rather a horribly sub-par version of it.
.
Tuesday, May 18, 2004
I think the mass majority of programmers really should use C# for 90% of their source, if they decide to make Microsoft-friendly applications. There are very few shareware programmers who 1) have the time to deal with C/C++ level development cycles; 2) deal with C/C++ related bugs; 3) or the time to eventually rewrite everything into C# when the time comes (2 years from now).
I am not saying Visual C++.net is useless. No, it's pretty awesome, but according to the doctrine of doing it purely unmanaged than what comes in 7.0 isn't going to help you as much as if you embraced managed space too.
Li-fan Chen
Tuesday, May 18, 2004
"or the time to eventually rewrite everything into C# when the time comes (2 years from now)."
Classic FUD. Absolutely classic.
Might you enlighten us as to what's going to happen in 2 years that'll change everything? Longhorn? Is that when the big unmanaged doomsday clock runs out and all code must be managed. I'll make the prophecy that in 5 years, the vast majority of commercial Windows apps will be unmanaged Win32. I'll further that, and say that in 10 years the majority of commercial Windows apps will be unmanaged Win32. Anyone who thinks otherwise is ignorant of the past, or intentionally in denial.
I remember a FUDster at one firm back in 2001 proclaiming that we should all switch to .NET because "Microsoft is rewriting all of their apps in .NET". Of course we know that "rewriting all of their apps" really means "integrating .NET stubs" (and isn't any more rewritten than saying Word is written in VBScript given that there's a VBScript engine in it).
Dennis Forbes
Tuesday, May 18, 2004
Just ran across this:
http://blogs.msdn.com/brada/archive/2004/03/09/87025.aspx
Green Pajamas
Tuesday, May 18, 2004
Dennis, I guess we are just disagreeing on the pace of change. I think most people will change a lot earlier than expected because they have already started years ago (say 4). Most companies I have seen already use it internally or mandated that most necessary training or acquisition of talents be completed by the time the .Net Framework 1.1 is out. Those that can deliver has already delivered or will. Those have only just begun are more than likely bitten completely into dotnet by now.
In terms of framework maturity: the only thing left for Microsoft to do is to take the less used libraries built using standards established by the more vertical industries. And like you said that's just stubs (and a lot of agreement and back and forth design between Microsoft and major customers). TAPI 3.0, Serial IO, advanced clustering IO, APIs for POS comes to mind.
Li-fan Chen
Tuesday, May 18, 2004
Hey Dennis, what do you think of the Open Office conversion article in "And So It Begins"
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=142555&ixReplies=22 ?
(tangentially related to this thread)
Philo
Philo
Tuesday, May 18, 2004
"I'll further that, and say that in 10 years the majority of commercial Windows apps will be unmanaged Win32. Anyone who thinks otherwise is ignorant of the past, or intentionally in denial."
Whoa....
Back in the early 90's, did you make any similiar predictions about how businesses apps would still be written for DOS in 10 years?
I'm not a .NET zealot who thinks the entire world will be changed, but I do recognize that 10 years is a *loooong* time.
I'd say to make such a prediction such as yours, one would have to be "ignorant of the past, or intentionally in denial."
Will everything be in .NET? I doubt it, but I also doubt that the majority of apps will still be managed Win32.
Whatever
Tuesday, May 18, 2004
"I think a profound lesson has been provided by the past two decades - Despite the promised silver-bullet productivity benefits of 4GL tools, what is the language/platform that the overwhelming (>95%) majority of commercial software applications are developed in?"
What decade would you like the answer for? It might well be Cobol, or C, or C++, or Java.
Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, May 18, 2004
"What decade would you like the answer for? It might well be Cobol, or C, or C++, or Java."
Between the period of 1984 and 2004, overwhelmingly commercial applications (which refers to shrinkwrapped style mass consumed/non-customized apps) have been developed in C/C++. Yes, I classify them as one (as C++ is generally a superset of C). I'm not really that aware of many Cobol or Java commercial apps (though, much like .NET, there was a promised onslaught of Java apps that were going to take over the market...strangely that never materialized as the negative value for consumers [more resource hungry and lower performance] made it a product hari kari).
Dennis Forbes
Tuesday, May 18, 2004
"Back in the early 90's, did you make any similiar predictions about how businesses apps would still be written for DOS in 10 years?"
No, I wouldn't have made such a prediction. Interesting, though, that 20 years ago I was programming 32-bit software in an advanced GUI using a message pump system (that was the Atari ST). Interesting that x86, predicted to be dead in the mid-80s, is the machine language of the majority of the world's software.
"I'm not a .NET zealot who thinks the entire world will be changed, but I do recognize that 10 years is a *loooong* time."
The rate of change in the software industry has dramatically slowed, and 85 - 95 represented tremendously more progress than 95-05, and 95-00 much more progress than 00-05 (compare Office 2003 to Office 2000 to Office 97). People also have an amazing ability to overstate the rate of change (we were all supposed to be in flying cars years ago).
Most importantly, change has to represent value to end consumers, and the .NET proposition offers little value to end consumers (it does, however, offer great value for internal development where the cost of development is spread across a much smaller group)
Dennis Forbes
Tuesday, May 18, 2004
"Most importantly, change has to represent value to end consumers, and the .NET proposition offers little value to end consumers "
What value did C++ bring to end consumers? You've said yourself that most development moved to C++, but what benefits does C++ bring to Aunt Milly in Boise?
Stalin
Tuesday, May 18, 2004
"What value did C++ bring to end consumers? You've said yourself that most development moved to C++, but what benefits does C++ bring to Aunt Milly in Boise?"
I've casually mentioned too many things and have opened too many fronts... Note that my original point was that .NET offers few benefits for developers that aren't already there in Delphi and Visual Basic...I then added the C/C++ comment just to point out that "even then things aren't always what they seem" (i.e. just because the former RAD and quickly get you started, on large commercial projects the slow and steady pace yields the solutions).
SALAD CREAM! HITLER! DELPHI!
Dennis Forbes
Tuesday, May 18, 2004
"Note that my original point was that .NET offers few benefits for developers that aren't already there in Delphi and Visual Basic"
If your assertion is that said developers are developing only stand alone applications, then that's probably true. The minute you want any type of advanced features, like client/server development, no touch deployment, etc., then you're just plain stupid to roll it yourself in a language like Delphi or VB, when it comes for free in .NET.
Not all applications are created equal.
Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, May 18, 2004
"What value did C++ bring to end consumers?"
On the whole today, using C/C++ does a disservice to the consumer. The rampant security flaws in modern OSes and applications are almost entirely poorly written applications in C/C++. On top of being buggy and potential security threats, they generally take longer to build than applications with higher level languages and environments.
Let's face it: virtually nothing Aunt Millie needs, needs to be written in C/C++ any more.
Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, May 18, 2004
I'm with Dennis on this one. I have yet to see a 100% compelling reason to develop a fat client app in .NET.
Face it, software tools vendors are cranking out .NET tools because it is a new market. The developers buying this stuff are delighting in working on something new.
I think it is a classic case of too much purple kool-aid.
First Java was going to save us from ourselves. Now .NET. Bah, humbug.
As Dennis noted, a great deal of truly serious and useful code is still written in C. There might just be a reason for that ...
Mitch & Murray (from downtown)
Tuesday, May 18, 2004
"The rampant security flaws in modern OSes and applications are almost entirely poorly written applications in C/C++"
Now come on -- it's "almost entirely poorly written applications in C/C++" because virtually every single application and operating system is written primarily in C/C++. I'll bet you that most serial murderers live on land...so I suppose that means that living under water is superior.
"On top of being buggy and potential security threats"
Virtual machine languages neither abolish bugs, or cure security problems - a .NET or Java app can still be rife with bugs that reveal personal data to the wrong person, or allow users to twiddle bits that they shouldn't.
"they generally take longer to build than applications with higher level languages and environments. Let's face it: virtually nothing Aunt Millie needs, needs to be written in C/C++ any more."
Yet the basic empirical fact remains - virtually every commercial application and operating system is written in C/C++, and remains that way despite numerous silver bullet technologies throughout the years. Why do you suppose that is? I asked this same question on a Java forum 4 years ago, and was promised that it's just that all of the Java apps were in the pipeline.
Dennis Forbes
Tuesday, May 18, 2004
Dennis is right, listen to Dennis! He's right, dammit!
Pretty much every major software package in the whole wide world is written in C/C++! Not a single freaking one in Java, and it's been here for ten years! Nuff' said.
Sassy (is learning C)
Tuesday, May 18, 2004
"Not a single freaking one in Java"
The Oracle installer is in Java.
Philo
Philo
Tuesday, May 18, 2004
Does anyone here think .NET abstracts away functionality?
I
Tuesday, May 18, 2004
http://www.onfolio.com
Ben R
Wednesday, May 19, 2004
A lot of whiners here. If you 'like' .NET development, just do it and use those comercial linkers. Your app will be < 5MB.
Nix
Wednesday, May 19, 2004
> The rampant security flaws in modern OSes and applications are almost entirely poorly written applications in C/C++.
Unfortunately a PHP programmer can open the doors to millions of dollars of data storage just as easily as an inconsiderate OpenBSD contributor/c wonk. We all have to be mindful. C/C++ programmers used to laugh at all weak assembly was, someday the generation of programmers would consider C# just as much a leaky ship.
I think the amount of time and attention current companies spend on the the security of modern frameworks is vital to minimizing future disasters, it's just about never enough.
Li-fan Chen
Wednesday, May 19, 2004
Lol Dennis already pointed that out.
Let's beat the dead horse again!
Li-fan Chen
Wednesday, May 19, 2004
The Linksys Wireless Media Adapter (WMA11b) uses a .Net service to handle streaming music and pictures from the host PC to the Linksys device connected to your home theater/stereo system. Probably a case of where a classic Win32 application would be better since the .Net version consumes gobs of memory.
Gerald
Wednesday, May 19, 2004
End users benefit from .NET in the same way developers do. Faster product development means the user either gets their product faster, or they get a higher quality product in the same amount of time. These are the same benefits that users get from C++. Nobody writes full applications in Assembler anymore.
Your point about how no other language has surpassed C++ in the past 10 years is somewhat of a red herring. First of all, most of those languages have not been sufficient for client applications, due to various factors of their design (speed, UI, cross-platform, etc). Secondly, these changes don't happen overnight. As you pointed out there is little advantage to rewriting old apps in the new language. C/C++ has had a long time to come to its current dominance. C++ was developed 20 years ago, and C over 30 years ago. To discount .NET because it has not surpassed C/C++ in a few short years is pretty rediculous. How long did it take C to gain its current market share over the dominant languages of the time?
I have no personal stake in .NET. I think it is interesting technology, and that client applications would be higher quality on the whole if it were used, but other than that I really couldn't care less if it succeeds. I just think the arguments used to discount it in this thread don't make any sense.
MikeMcNertney
Wednesday, May 19, 2004
"These are the same benefits that users get from C++. Nobody writes full applications in Assembler anymore."
Right - we're talking about the benefits of .NET over current competitive platforms, not .NET versus assembly. The productivity advantage of .NET aren't overly compelling against competitors like C++, Delphi, or even VB. I think that's the whole gist of this.
"First of all, most of those languages have not been sufficient for client applications, due to various factors of their design (speed, UI, cross-platform, etc). Secondly, these changes don't happen overnight."
Did you post to the wrong thread or something? Let me explain how this conversation went.
-(Someone) Where are the fat-client .NET apps?
-(Me) There probably isn't enough benefits provided by .NET for fat clients to make it worthwhile to many dev teams (given that they'll be tossing legacy code, throwing out libraries of components, and on top of that supplying overly resource hungry apps to clients that might be eaten alive by lean and speedy competing apps).
-(Someone) .NET is taking over. C++ is obsolete. In 2 years everything will be managed code so you might as well jump in now.
-(Me) I doubt it. C/C++ still comprises the vast bulk of commercial code, despite credible silver-bullet competitors (such as Java, and even, foolishly, at one time VB) being around for quite some time.
So what exactly are you arguing with?
Dennis Forbes
Wednesday, May 19, 2004
"C/C++ still comprises the vast bulk of commercial code, "
Cite?
Also, while I suspect you're right, wouldn't the real question be "what are most current projects started in"? If you've got two million lines of C++, then that project is two million lines of C++ and work on it will be C++ for the foreseeable future. But when the accounting department wants a Sarbanes-Oxley utility, what language does the project use?
I feel pretty safe betting "not C++"
Philo
Philo
Wednesday, May 19, 2004
"But when the accounting department wants a Sarbanes-Oxley utility, what language does the project use? "
Sorry I didn't add the disclaimer on that one, but I was referring to commercial, non-internal applications. VB was, by far, the #1 internal development tool, yet it was an absolutely abject failure from a commercial software perspective.
Dennis Fobes
Wednesday, May 19, 2004
"Sorry I didn't add the disclaimer on that one, but I was referring to commercial, non-internal applications"
Gotcha. In that case, then I'm in agreement about what it's like today. I think the odds are with you in the future, but it will be interesting to watch. The 20+MB runtime is a hefty pill to swallow, and the average home adopter is beyond reactionary in adoption. But stranger things have happened - the overnight explosion of both music CD's and movie DVD's still astound me. (and yet companies still buy boxes without DVD drives)
It's so hard to predict what next year may bring - for all we know there will be some killer app, and it will sell with the .Net runtime - then suddenly everyone's got it.
Or not. [shrug]
Philo
Philo
Wednesday, May 19, 2004
Dennis is so right, it's frightening.
I learned C++/MFC in 1995. Since then, I have been just a year or two away for obsolescence - every single year. First it was Java, then ATL, then .NET. *Yawn*
Java and ATL declined as threats to C++/MFC for well-hashed reasons. .NET will decline, too, into a web-only niche, and C++/MFC will be dominant for fat clients for the foreseeable future.
Or something very close to that will happen...
Grumpy Old-Timer
Wednesday, May 19, 2004
"I learned C++/MFC in 1995. Since then, I have been just a year or two away for obsolescence - every single year. First it was Java, then ATL, then .NET. *Yawn*"
I think your analog here is bad.
Java was never strong for client apps, especially on Windows, because it was too slow (and you can argue that the only company with a fast Java technology for Windows -- Microsoft -- was sued out of it).
ATL is not a windowing library like MFC is, and was always just a marginal technology for extreme people.
.NET has the full weight of Microsoft behind it.
Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, May 19, 2004
"Java was never strong for client apps, especially on Windows, because it was too slow (and you can argue that the only company with a fast Java technology for Windows -- Microsoft -- was sued out of it)."
There are some performance costs of inventing and implementing an abstracted intermediate language, and indeed Java wasn't a credible fat-client platform because of that. The jury is still out on whether .NET overcomes that hurdle, but if an end user has two applications and one provides a snappy, visually rich environment, and the other has a sloggy, resource hungry environment (but it made life easier for the developer), most users will opt for the first option.
"ATL is not a windowing library like MFC is, and was always just a marginal technology for extreme people."
ATL was introduced as the successor to MFC.
Dennis Forbes
Thursday, May 20, 2004
"but if an end user has two applications and one provides a snappy, visually rich environment, and the other has a sloggy, resource hungry environment"
Where have you seen .Net apps reported as "sloggy" and "resource hungry"?
Philo
Philo
Thursday, May 20, 2004
Notice that I cleverly didn't actually say that, but rather alluded that it does often tend to be the nature of managed code. Prove it wrong with a rich-UI managed application that is doing more than just wrapping common controls (which are of course native code).
Dennis Forbes
Thursday, May 20, 2004
(and please don't point to the absolutely hilarious "managed" Quake 2 [I won't even start to point out why that was the most absurd example of .NET performance imaginable])
Dennis Forbes
Thursday, May 20, 2004
"ATL was introduced as the successor to MFC."
Sorry, I've never seen it presented as such. ATL always has been billed as a lighter weight way to write COM clients and servers. The rudimentary "windowing" support was all in pursuit of ActiveX controls.
WTL was a never supported full-on windowing library.
Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, May 20, 2004
"Sorry, I've never seen it presented as such. ATL always has been billed as a lighter weight way to write COM clients and servers."
True enough - ATL in the practical incarnations was relegated to COM and ActiveX control work. However there was overwhelming noise coming out of Microsoft at that time that ATL was the future - MFC was nice and all, but you had better start sharpening your ATL skills because that was where it was going to be at (and, as you mentioned, WTL was the expansion of the theme to give a broader GUI focus). Take a look at some of the historic DejaNews postings and you'll find countless circa 98 "Is MFC dead?" posts caused by this paradigm shift as one propaganda department in Microsoft started getting more airtime than another.
Dennis Forbes
Thursday, May 20, 2004
"Prove it wrong with a rich-UI managed application that is doing more than just wrapping common controls (which are of course native code)."
That's an interesting constraint. Are you saying that only a .Net app that uses no common controls could validate the position that .Net may displace C++ as the main application coding language?
Philo
Philo
Thursday, May 20, 2004
And exactly how many shrink-wrap C++ applications are writing their own "Save File" dialog boxes instead of "just wrapping" the Win32 Common Controls?
Games are the only example I can think of, and they're also the only kind of shrinkwrap apps that will certainly continue to be written in C++ for the foreseeable future.
Chris Nahr
Thursday, May 20, 2004
(Actually an entire dialog box is more likely to be rewritten... a better example would have been list controls or buttons.)
Chris Nahr
Thursday, May 20, 2004
"Are you saying that only a .Net app that uses no common controls could validate the position that .Net may displace C++ as the main application coding language?"
Few actually useful apps make use of only common controls, for example using owner draw menu items, custom edit boxes for spell highlighting, custom sidebars, etc.
Dennis Forbes
Thursday, May 20, 2004
There are plenty of .NET libraries available, both free and commercial, that provide such, er, common enhancements to Common Controls. Outlook-style sidebars, pictures next to menu items, no problem.
Chris Nahr
Thursday, May 20, 2004
"There are plenty of .NET libraries available, both free and commercial, that provide such, er, common enhancements to Common Controls. Outlook-style sidebars, pictures next to menu items, no problem. "
Indeed. My contention is that those that do anything substantial in managed code (be in Java, .NET, Smalltalk, whatever) tend to have a rather subpar response time, and tend to be incredibly resource hungry. The fact that they exist is irrelevant if, when slung together into a feature rich application you're left wiht a monstrosity. Again, I'm not saying this is the case...but point me to a feature rich GUI managed application and I'll happily be proven wrong.
Dennis Forbes
Thursday, May 20, 2004
The Business Contact Manager in Outlook 2003 is written in Managed code.
dino chiesa
Thursday, May 20, 2004
Version 3.5 of Beyond TV, our PVR software which is going into a wide beta fairly soon, makes heavy use of .NET under the hood to provide network client playback, a programming framework using web services, and many other services. The real key for us has been strategic use of .NET in places where the performance and memory impact don't matter.
Our home theater front end, Beyond Media, is being written entirely in C# and Managed DirectX. Jury's out on that since it's not in beta yet.
Richard Kuo
Thursday, May 20, 2004
To elaborate a little more, the front end of Beyond TV is primarily C++ which renders the entire UI in Direct3D with a bit of interop mixed in. There is much heavier use of .NET at the application logic layer. I'm not sure where that fits in your definition of rich GUI's making use of .NET, but it's out there.
Richard Kuo
Thursday, May 20, 2004
Your software is dependant on the .NET framework. So that's it :).
Green Pajamas
Friday, May 21, 2004
 Recent Topics
Fog Creek Home
| 
