Printable View
How good/bad of an idea is it to continue to maintain a program in VB6.0? I started this project in 2003, so I have been working on it for some time now. Converting it sounds not only scary but downright impossible. I have tried converting to VB.NET and it was a bit hellish. So what do I have to worry about? Are there still a lot of people using it?
Yes there are and will continue to be as long as the program itself lasts.
Many companies are turning all new development to VB.NET but maintaining legacy systems in their original language for one very important reason...it is cheaper, financially, to do so.
When the program dies or has so many "band-aids" on it that maintaining is no longer feasible, it will either get rewritten or dumped.
NOT converting them makes no sense to me, but then I'm a programmer not a corporate wonk.
About the only thing you have to worry about is a new version of Windows not being able to run/install the Visual Studio 6 IDE and/or not being able to run the VB6 runtime libraries in the future.
There will never be a time where maintenance and band-aids won' be cheaper than a complete rewrite... look at the Y2K scare: Companies were paying programmers to come in and repair 30-year old software! Plus, with faster hardware, you'll be able to EMULATE older hardware fast enough to still run ancient software.
But it never made sense to me either to not convert. My recommendation is to start all new projects in .NET. I've never met a VB6 program that wasn't 10x simpler to do in .NET. If VB6 is like a toolbox, the .NET framework is like a fully stocked mechanic's garage.
Heck, I've known programmers and IT departments to "loose" their VB6 install disks just so they can force the corporate wonks to agree to the conversion of legacy applications. :)
After you're proficient in .NET where you'd never even consider touching VB6 again (should take about 6 months), then bring up the topic of converting the program as a side-project. Put in like an hour a day rewriting it. Aim for 1:1 functionality. Don't do anything fancy or add any new features unless you're sure they won't take any extra time. After a few months, you'll be done. You'll have a perfect conversion of your program in .NET 3.5 or 4.0 or whatever.
I wasn't leaving it up to chance: Somebody stole the whole computer and all the source code. There's more to that story, but it makes it uninteresting. Suffice it to say that I used that as an excuse not to deal with those legacy programs again.Quote:
Originally Posted by Jenner
You should be safe maintaining existing programs until:
1) The IDE or program no longer runs: This has been threatened repeatedly, but as of Windows 7, it has not happened, nor is it likely to in the near future.
2) You become familiar with .NET, at which point you won't want to open the VB6 IDE ever again. I loved that language, yet I would never willingly go back to it.
There are of course other options such as moving to native Delphi, or Java, or one of the RAD front-ends for C++ that might gain ascendency.
So far I don't see too many additional practical development tools that operate at a high enough level of abstraction to make them productive alternatives to classic VB or C#/VB.Net. You can throw in a few popular Web development languages and toolsets, but that really doesn't address this thread too directly
But .Net is not a "given" when looking at a move from VB6. It's more of a popular option that has its advantages and disadvantages - and few real competitors.
What type of application are you talking about? How large is the codebase?Quote:
Originally Posted by ctullar
Wow. If someone "lost" my installation CD, I might "lose" my mind.
I will try to become more familiar with .NET, but I was mostly just trying to get a feel for how widely used VB 6.0 is. I started to get concerned when someone told me my program didn't work on Windows 7. I don't believe this person (because I am always innocent until proven guilty) but have no way to really test it because I have not yet seen Windows 7.
Thanks for the input, folks.
I'd guess VB6 is still widely used compared to something like FreeBASIC or Delphi, but the numbers are only a fraction of what they once were.
If you haven't been keeping up you'll find that Vista and Windows 7 changed (or now enforce) a number of things. Things that may indeed keep your old VB6 programs from working, or working as expected. These have been widely discussed here and Modifications Required for VB6 Applications to Work on Vista is one place to start reading.
Take it all with a grain of salt though, you'll find lots of rough edges in most of the info because Microsoft never provided any explicit guidelines for VB6 programmers. This produced a lot of... speculative explanations of things.
I agree that .Net is great, the only thing that I find hard to implement is "Resume Next" with the new Try Catch structure.Quote:
Originally Posted by Jenner
Dont forget that its your audience that will help dictate your direction. If its all workstation/clients then you will have to be at the mercy of the support of the VB6 IDE primarily and secondary will be the runtimes as runtimes are easier for MS to support in a new OS then the IDE.
We have hundreds of applications at work that we have written. Most are in VB6 with a handful that are mission critical software used by hundreds of agents worldwide. We still actively make upgrades and modifications to the critical ones. The reason why we havent re-written them yet is cost, time and resource availability/allocation. Ive been pushing a re-write for the first critical app and looks like I may get it this upcoming year. :)
So I would have to say that eventually it will signifigantly drop in the list of top languages and am sure its already on its way.
Yea, I got lucky at my current job when the source for our one and only legacy VB6 app got lost; apparently in a computer upgrade (it was on the local hard drive and not on the network).Quote:
Originally Posted by Shaggy Hiker
Use multiple Try Catch statements, or embed them. I agree, the error handling in .NET is deceptively easy appearing, but requires some playing with to really learn how to use it well. I'd never, ever use "Resume Next" again, as that has caused so much data-corruption for me in the past in my VB6 days it simply wasn't worth it. I once filled a database with faulty measurement data because of a math error that my code "resume next'ed" over rather than compute it properly or halt it with an exception.Quote:
Originally Posted by dee-u