The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Use .NET for shrinkwrap product?

I sell a shrinkwrap software product that was developed over a period of 10 years in VB6 and C++. There are 230K lines of VB6 and 95K lines of C++/ATL.

I've been looking at .NET for several years now, and I still can't make a business case for adopting it. I am no longer using third party controls, so my only dependencies are VB6, C++, ATL, Win32, and COM.

If I had jumped on the .NET bandwagon in 2001, I would have converted my GUI to Windows Forms. But now it appears that Avalon/WPF is set to replace Windows Forms.

I don't mind porting my code to a better platform, but I need to feel confident that the new platform is going to be stable. I don't want to keep rewriting my code over and over.

It appears that Office 2007 makes very little, if any, use of the .NET framework. As long as the Office suite requires Win32 and COM, I suspect that my code will run just fine in new versions of Windows.

I suspect that Win32 and COM are going to be around for a long time to come. And I am quite happy developing in VB6 and C++. My code is very well structured, and I've found it easy to port various components from VB6 to C++/ATL. I don't think it would be especially difficult to port from VB6 to C#, but I still don't see how this would benefit my customers.

I developed all of the controls used in my GUI using C++/ATL. My user interface does not look dated at all. In fact, I've recently adapted and incorporated some of the concepts used in Office 2007. To my customers, it looks totally modern. And I don't think they care whether I'm using .NET. Not one customer has ever bothered to ask.

My 5-year plan is to continue to develop for Win32 and COM using C++ and ATL, while gradually moving away from VB6. The .NET framework has no role in my plan.

What would change my thinking on .NET would be for Microsoft to build it directly into the operating system. Then it would no longer be a library that they can change every couple of years. Right now, if they change .NET, it only affects developers. But if .NET were built into the operating system, then changing the spec would break things for end users.

I had hoped that WinFX would represent exactly that. I was excited about porting my code to WinFX, thinking that WinFX would be every bit as stable and long-lived as Win32. But I am having trouble finding reliable information on WinFX. I'm not entirely certain what it is. Microsoft's WinFX web page (http://msdn.microsoft.com/winfx) continues to say that it contains WinFS. Didn't that get axed over a year ago?

Given the fact that the Office team continues to build major new functionality based on the Win32 platform, I think that from a business standpoint, that's the most sensible thing for me to do as well.

I really like C# and the .NET framework. But they still don't seem stable enough to bet my business on.

I would be interested in hearing how others are have assessed the situation.
Smoothie
Wednesday, March 29, 2006
 
 
One of the key principles of .NET is that new versions of the framework *DON'T* break older code, because the older code simply runs against the older framework. You can bet that when operating systems are shipping with .NET 3.0 that the 1.x and 2.x frameworks are still shipped as well.

Assembly versioning is well controlled, and the DLL hell from earlier years is pretty much gone. I don't believe this is a major concern. There are no scary breaking changes in .NET.

We've been developing a product over the last 12 months and embraced C#, .NET and Windows Forms, and it's the best move we ever made. Super productive way to develop. I don't mind that a new uber cool form handling engine will arrive some time later. Our stuff works great and will continue to run.

We have a bunch of C++/Win32/MFC applications out there, and I couldn't (and don't particularly want to) make a business case for rebuilding these. They do their thing, work well using the best tools of the time, and continue to work.

Microsoft have always worked hard at maintaining backward compatibility so you don't need to worry about decisions you make when developing for their platform.

That's why Windows is so slow and bloated. :-)
Andrew Lighten Send private email
Wednesday, March 29, 2006
 
 
If it works, leave it alone. I'm also perfectly happy writing my applications in C++, targeting the Win32 API. My codebase is clean and well structured, and I use modern C++ techniques and WTL. I use .NET for web stuff, but for applications? Nah. Not in the cards for what we do.
sloop
Thursday, March 30, 2006
 
 
Sure, if it works, leave it alone. But to address a common misconception: The WPF (Avalon) will NOT replace Windows Forms. WPF is designed to cooperate with WinForms and as Charles Petzold noted in his blog, the initial WPF release will actually miss many WinForms features -- you MUST combine the two if you want an Avalon user interface. Pure WinForms, on the other hand, will continue to work just fine.
Chris Nahr Send private email
Thursday, March 30, 2006
 
 
Any thoughts on size? Like that if someone doesn't have .net framework installed, they'll have to get it (I understand that .net 2.0 installers fire off a download).
Tim Almond Send private email
Thursday, March 30, 2006
 
 
>> We've been developing a product over the last 12 months and embraced C#, .NET and Windows Forms, and it's the best move we ever made.

Have you used Delphi, and if so, did you find the C#/.NET environment even more productive?  I'm contemplating the switch right now...
DelphiDev
Thursday, March 30, 2006
 
 
Thanks for the link to Petzold's blog. I've been a long time fan of his but never really thought to check if he had a blog. I'm currently learning WPF and it looks like he has a ton of really good stuff there. I'll definitely be spending some time there in the future.

Thanks!
Turtle Rustler
Thursday, March 30, 2006
 
 
"I've been looking at .NET for several years now, and I still can't make a business case for adopting it. "

Don't make up reasons/excuses to use .NET.  If what you stated is true, stick with what you are doing.

"I don't mind porting my code to a better platform, but I need to feel confident that the new platform is going to be stable. I don't want to keep rewriting my code over and over."

Sounds more like a design issue?  What is it you have to keep rewriting?  Can you give more details?

I write directly to Win32 and been using the Borland VCL framework without much rewrite between versions over the past 10 years.  If VCL went away, I have MFC and/or a host of other solutions.  I'm not recommending VCL but rather I'm trying to draw a correlation.  I don't believe in massive layers of abstration.  VCL wraps Win32 rather well such that if it went away it would not be hard to get the parts that went south back or move code to MFC with less rework.

.NET is just getting too proprietary for my tastes.

"It appears that Office 2007 makes very little, if any, use of the .NET framework."

Correct.  The reason, I believe, is that their software is still being written for the MAC so a common code base is assumed.  I have no facts to back this up.  The 2nd reason is why reinvent the wheel?  There is a lot of Office code out working well so why rewrite in .NET?  To prove a point?  No, that's not wise.

"I suspect that Win32 and COM are going to be around for a long time to come."

I agree with you here.  Microsoft will not let Win32 go away -- they have commitments to their customers and very large contracts that prevent this from happening.

my 2 cents...
Eric (another ISV guy with his company)
Thursday, March 30, 2006
 
 
If you have that many LOC in your app (in the hundreds of thousands!) I would leave it alone....

As a VB.Net developer, I believe that the future will be very diversified when it comes to development IDEs and frameworks....for the most part though, I think the only changes that will be implemented between varying versions of Visual Studio will be changes to the framework itself....either namespaces will be added or taken away (or elements thereof).

Within the next 10 years, I can foresee a typical Windows OS having and maintaining several versions of IDEs along with 8 0r 9 different separate frameworks.

In other words, in the future I don't think it will be uncommon to find a developers possessing multiple versions of the .Net Framework - 1.1, 2, 3, 4, 5, 6, and 7 along with their most favorite, corresponding IDEs - AND YES, there will still be those who are STILL running VB6 quite happily....

....In the near future, VB6 will be to computing what COBOL is today in mainframe programming....it still exists, but it's more of a historic computing anachronism than it is popularly relevant.
Brice Richard Send private email
Thursday, March 30, 2006
 
 
I would not port, but you might want to look at writing new applications in .NET.
MBJ Send private email
Thursday, March 30, 2006
 
 
I'm just wondering what is it about .NET that get's people in such a quandry and uproar on deciding it to support it or not? What's the difference between going from VB6/Win32 to C#/.NET from any 'proven existing language/platform' to 'newly introduced language/platform'.

Based on the simple fact that just about any app written for/since MS-DOS can run in Win XP 64 and everything in between show's that if Microsoft is anything it's anl about backwards compatibility. So I think it's safe to say it can run now with no problems it will be so for atleast the useful life of that codebase.

If you're maintaining an existing codebase then don't change platforms. When you're doing a major overhaul or rewrite and the consider a platform switch. (Not necessarily an upgrade.) .NET 2.0 was only officially released in November so it's fairly new. .NET 1.0 and 1.1 have been out for a while and whether MS is actively developing against them or not enough other companies are to the point MS can't just let it go without major setback. That means WinForms aren't going away.

I know for a fact most of Autodesk's major products have .NET 1.1 dependency that by itself is a market MS wouldn't want to loose since they only have some because Autodesk's products only run on Windows.
TrippinOnIT Send private email
Thursday, March 30, 2006
 
 
"Based on the simple fact that just about any app written for/since MS-DOS can run in Win XP 64 "

What do you base this on?

I heard from PC Mag that they tested DOS programs on XP 64 bit and they didn't run.

Also, Starting with Win 2k, DOS/16 bit apps are run by an emulator. That emulator can break.  No one notices because it's not *essential most programs*.

And that is my fear with .net:  .net can break, but if few things are dependent on it, the  user can limp along without fixing it (or doesn't know it's broken) and can't run (thus buy) my software. Or worse: since MY program is the only one that doesn't run (either b/c of the 16 bit or .net problem) they think OUR software is broken.

All that said, I love the .net environment and I'm using it for a necessary rewrite of our 16 bit apps.
Mr. Analogy {Shrinkwrap µISV} Send private email
Thursday, March 30, 2006
 
 
Good post Smoothie -- sounds if you need to stick to your 5 year plan.
Liam
Thursday, April 06, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz