Having just discussed VB6 in this thread, VB6 has reared its ugly head again.
I got an email last night asking me to extend the functionality of a VB6 program I wrote several years ago. I'm asking them if they'd consider moving to another language, but there's a lot of work involved (I'd love the payday, but they might not). What's a common solution to supporting legacy VB6 programs? Are people rewriting/replacing all their VB6 systems? Is it less effort to port it to VB.NET?
I don't know that there is a "common" solution, since it's highly dependent on the circumstance, such as the amount of VB6 experience you'd have, and the complexity of the original code and the complexity of the changes being requested. What's your estimate on the amount of time to add the functionality to the existing VB code? What's your estimate for completely rewriting it in LabVIEW? When you ask whether it's less effort to port it to VB.NET are you asking relative to LabVIEW? That's really hard to say without knowing more about what the application does. If, for example, the app is doing a bunch of Windows API calls, then that's NOT going to be fun in LabVIEW. VB.NET isn't too bad, though, with respect to this.
My 2 cents: I think the bottom line comes down to whether you want to really support this application, or whether you're simply going to say that you're not going to support old VB6 code anymore. That would force them to go somewhere else, obviously. If they're a good customer you may just want to bite the bullet this time and perhaps drop a strong hint that you may not be doing any more VB6 support in the future. But ultimately that's a business decision on your end, more than a programming decision.
Thanks for the answer. Here are mine:
the amount of VB6 experience you'd have I wrote the program, so I know the structure of the code (textual spaghetti, literally) and the engineering behind the maths.
What's your estimate on the amount of time to add the functionality to the existing VB code? I'm still working on this, but I expect it'll be less than 100 hours of night and weekend work.
What's your estimate for completely rewriting it in LabVIEW? Forever, give or take an eternity. 🙂 But, I would be starting from a position of knowledge that I didn't have when starting the original almost ten years ago. I could ARCHITECT it!
When you ask whether it's less effort to port it to VB.NET are you asking relative to LabVIEW? I think so. It's a VB6 application so it makes sense to me that it'd be a shorter putt. It won't work in VB.NET, but I was thinking that it would be close.
If, for example, the app is doing a bunch of Windows API calls, then that's NOT going to be fun in LabVIEW. VB.NET isn't too bad, though, with respect to this. It's doing a bunch of calls to Adobe Illustrator's API. It would be a lot of short/wide VIs.
whether you want to really support this application I do.
I'm mostly interested in how I can help my customer not get stuck in the future. I added a tongue-in-cheek post to the other VB thread, but there was some real concern behind it. What's the risk that VB6 will not work in Windows 7 (I guess I could buy a Win7 PC and try it) or beyond. A colleague is trying to buy a license of Win XP to repair an old ATE and he can't find it (except EBay, which is prohibited) so keeping old PCs around forever isn't a great option. I also want to be the one they come back to, so it's in my interest to look to their future even before they do.
[...] perhaps drop a strong hint that you may not be doing any more VB6 support in the future. But ultimately that's a business decision on your end, more than a programming decision.
I'll be willing to support VB6 for them until I become independantly wealthy. I'm thinking the OS environment will quit before I do.
I've got VB6 (and most MS studio products) on Win7 at home here-- Flipping NI driver DVD for 2011 is taking forever to install support- Can't say I USE VB6 ( or text languages) but the system doesn't crash
Too bad about the Adobe calls though
The VB6 runtime is basically just your run of the mill 32bit program, and is going to be officially supported by Win7 for the next few years, however you may need to write and update code in Win XP, as the IDE may run, but is not supported.
@Jeff Bohrer wrote:
Too bad about the Adobe calls though
Figuring out those Adobe calls has been profitable over the past few years. 😉 I tried to do create the same functionality in SolidWorks but I couldn't get lines to start close to each other (picture graduations on a pressure gauge dial) without ends snapping together. I'm sure I was doing something wrong, but Illustrator didn't give me that issue. Additionally, I got the Graphic Artist on my side by using the tool he uses. He'd be my biggest fan if I refactored my code to run on the Mac...
But the VB runtime is in Windows 8.x, and will probably be in Windows 9 too.
As long as Windows uses the Windows API VB6 applications should run.
The VB6 programming language is still the most popular version of Visual Basic.
VB6 programming is fine on Windows 10. The VB6 IDE installs and apps run OK.
Microsoft say they will support VB6 until at least 2024.
VBA programming continues too, despite Microsoft attempting to replace it.
Meanwhile .Net is being eased into open source. It looks as though VB6 programming will outlive .Net.