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.

VB6 is dying:  But... when will it be completely dead?

We have a big application that would need about 5 years to rewrite from scratch or migrate to C# or whatever.
We are just wondering how long 32-bit-VB6-applications will continue to run *fine*.
We all know that:
- VB6 works *great* on Vista.
- 32 bit applications will run on 64 bit systems (using WOW technology)
Windows 7 will be just a Vista upgrade (32 and 64 bits versions); and it is very probable that Windows 8 will be just a 64 bit OS (still running 32 bit apps with WOW).

So... I guess we would still be able to run 32-bit compiled apps AND vb6 apps for at least 8 or 10 years.

Am I right?

Thanks a lot.
Donatello Salvatore
Wednesday, July 16, 2008
Note that Turbo Pascal 3.0 programs from 1985 SILL run (in the command line) on Windows XP and Vista.

Since this is one of the secrets of the commercial success of Windows (namely every single new release will run all, or almost all, programs created for earlier releases) I don't think you have much to worry about.

Though I might mention, I've had problems with the "auto-register" approach that VB6 takes when you create an Active-X "Class" if you "compile" it without having "Admin" priveleges.

Now, getting HIRED without VB.NET (or better on your resume can be difficult.  But that's different from knowing when you HAVE to port the application.
Thursday, July 17, 2008
At some point in time VB6 will lack features that other toolsets provide (that are difficult to add into a VB6 app).
i.e. it will get more and more difficult to sell VB6 apps as your competition have newer shiner applications.

So there isn't a quick upfront benefit for re-writing your app now ... but in a few years time sales will start to dry up and users will move onto prettier more powerful applications.
Ray Smith Send private email
Thursday, July 17, 2008
5 years?  Crikey -- what the heck does this thing do?

I mean, you already have a pretty good spec (the existing app), and there are automated tools to do a lot of the grunt work.

I dunno, 5 years sounds a bit over the top...
BillAtHRST Send private email
Thursday, July 17, 2008
> Windows 7 will be just a Vista upgrade (32 and 64 bits versions)

I wouldn't be 100% sure of that. I know Microsoft are saying there will be a 32 bit version, but they aren't saying whether all editions will be available in 32 bit.

We know with Vista that they released Home Basic without the Aero interface just so they could claim there was a low-requirement version for older PC's.

It wouldn't suprise me if the real versions (Home Premium, Business, Ultimate) are 64 bit only and 32 bit apps are run via WOW or virtualisation.
Friday, July 18, 2008
The OP might be referring to man-hour years, not actual years; it could mean one year with five people working, etc.
Kyralessa Send private email
Friday, July 18, 2008
"The OP might be referring to man-hour years, not actual years; it could mean one year with five people working, etc."

Or it could mean that it has had 5 years of development work to get where it is with interim releases and features that are now deprecated or removed.

Plus some things are just plain easier in a good contemporary platform than VB6. I've seen a lot of complex VB6 systems migrated to .Net and they ended up being much simpler.

Of course, YMMV.
Friday, July 18, 2008
Our main revenue producing product is a VB6 app. Originally a VB3 app, it took several painful years to migrate to VB6. The project to move another VB3 app, but to .NET this time, is 3-4 years behind schedule (depending on who one talks to) and the conversion process has more than 30 man-years involved already. This is for an app that has been marketed for about the last 15 years - so despite it being trapped in VB3, it still has a lot of functionality.

What is the point of this? That it is quite reasonable for a large complicated VB6 app to need 5 years to migrate to .NET. To get it done quicker will involve tools that most companies are unwilling to pay for: to virtually every PHB out there, 1 man-year of effort is far cheaper than spending $5k on a tool because the tool takes a budget request, and the person already works there.
Peter Send private email
Saturday, July 19, 2008
If all you want is a shiny app, you know that you can isolate modules and only port the GUI, right?
Daniel_DL Send private email
Monday, July 21, 2008
Monday, July 21, 2008

Funniest thing I've seen in a long, long time.  You can find the page yourself, but they've got a screenshot that nearly made me wet myself.
Monday, July 21, 2008
Sorry, but I meant to type "WWW.COBOLONCOGS.ORG" not ".COM".  Reminds me of university when I would compile my ALGOL W program, walk to the Computing Services building, wait in line for my batch job to get to the front of the print queue, and as soon as the technician put only two pages in the mailbox, I knew I had mis-typed a keyword, and off I went back to the terminal room in another building on campus, to make my correction, recompile and so on.
Monday, July 21, 2008
Run 'fine' good enough?

We are in a similar situation with a large C++ Win32 code-base that has been in development for ~15 years. We have found that even continuous improvements have some issues; for instance the UI looks dated against competition, is not a native web app, there are minor bugs & issues that appeared with Vista that we had to fix. I would say that running 'fine' may not be good enough in a competitive market. 

Even factoring in the productivity gains of starting with a clean code base in say C# on .NET, we figure at least 2 programmer years to get basic functionality to market; and it would be a less functional solution than the current app. Even if it looks much nicer, we found clients don't like their favourite bits not being supported in a new version.   

For us, we are walling off the current code-base and extended the (tangled) UI into a web-app. The C++ code-base will still be extended (to 64-bits and open-source platforms) over time, but the most pressing issues will be resolved by extending the app with new code in new languages.

Personally, I think moving new development & modules to say C# makes a lot of sense for you...
Grant Black Send private email
Wednesday, July 23, 2008
A VB6 app that works just fine the way it is doesn't seem like a much of problem at all for the company using the app.

On the other hand, it's a very big problem for the developers who will never be able to get another job if the only language they've worked with is VB6.

This industry sucks.
Grumpy .NET programmer
Sunday, July 27, 2008
"who will never be able to get another job if the only language they've worked with is VB6"

You're being too deterministic. If these people are any good, they can learn .Net with a good book in three months.
Daniel_DL Send private email
Monday, July 28, 2008
There's no way you can become good at .NET in just three months. It took me years before I finally feel like I understand it.
Grumpy .NET programmer
Monday, July 28, 2008
And furthermore, I didn't say they will not be able to learn .NET, I said they wouldn't be able to find jobs.

The typical employer will not want to hire someone without .NET experience.

Back when .NET was new, you could get a .NET job without experience. But now, there are people who have been using it for six years. Employers have lots of experienced .NET people to choose from, and a 24-year-old kid with 2 years of .NET experience looks like a more attractive hire than a 40-year-old VB6 guy with no .NET experience, because the kid can be paid a lower salary.
Grumpy .NET programmer
Monday, July 28, 2008
If you are a good software engineer, you can become good at .NET in three months.

I repeat. If you are a good software engineer, you can become good at .NET in three months.

About jobs, I don't know, have you tried? I've developed in .Net at two different places and in both of them I started doing C++, I later changed to .Net because of the needs for new projects. It's not that hard.

Legacy C++/VB code + New projects in .Net = They hire you for C++/VB, you end up doing .Net = Cool

Anyway that's just my experience.
Daniel_DL Send private email
Tuesday, July 29, 2008
Given the way that IT hiring works, I am CERTAIN that a person with no professional .NET experience would have a difficult if not impossible time getting hired, today in 2008 , for a .NET job.

It was different a few years ago when fewer people had .NET experience.
Grumpy .NET programmer
Wednesday, July 30, 2008
"A VB6 app that works just fine the way it is doesn't seem like a much of problem at all for the company using the app".

Could be a problem with the company selling the app though.

The OP is worried about the future; and I can see why. We stopped supporting Win9x last year. Our C++ application using a relatively modern compiler compared with VB6, had a range of subtle & not so subtle issues running under Vista. Not to mention some clients having odd issues running our app on MacBooks using Parallels

Just takes client to move to a new platform or MS to roll up some update that breaks something minor & it could be a major problem for the vendor. For instance .HLP's worked fine, but we can't currently get CHM files to work correctly for a Japanese client; it could well be an issue that stops the client using the product. (actually we did have a solution for that.. but as a point).

Have been through this before around W2K, with clients moving to NT & Win2K and finding some of the low-level Win9x code I used to develop in a previous company no longer working.
Grant Black Send private email
Thursday, July 31, 2008
Unlike C++, VB6 runs in a virtual machine, and I don't think that Microsoft would do something that would break what was once their flagship development tool.

But who knows for sure? There are risks involved in not rewriting it in .NET, but rewriting in .NET costs a lot of money, and there's the risk that the .NET app will be worse, or at least not any better.
Grumpy .NET programmer
Friday, August 01, 2008
In terms of interface such as using the newer 32-bit and alpha channel images, you can use the ImageList tool to make your VB6 app look like an XP app. You can also use the manifest file approach.

You can slso do a database change from using the older Jet and Access mdb files to perhaps SQL Server and MySQL without too much of a change in VB6 code.

One problem in converting from VB3 to VB6 is that all the VBX controls need to be re-purchased and replaced for OCX controls. In terms of VB syntax, many features remain the same except perhaps the database portion.

One other problem I faced in converting to VB.NET is that I could not use Innosetup anymore to package a setup program and also any external interfaces to DLL and OCX and to third-party apps have to be relooked into deeply.
Tuesday, August 05, 2008
Wow a lot of responses, I was out of town.
Thanks to all.....
"Our approach with Windows 7 is to build off the same core architecture as Windows Vista so the investments you and our partners have made in Windows Vista will continue to pay off with Windows 7. Our goal is to ensure the migration process from Windows Vista to Windows 7 is straightforward."

So it seems that just a 128 bit OS could break vb6 compiled apps.

BUT I have to agree that staying with vb6 could be harmful......  I guess it is important to join the .NET wagon..... sooner or later new technologies will provide better user experience that will be difficult to mimic with VB6.

Thank you all.
Donatello Salvatore
Tuesday, August 05, 2008

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

Other recent topics Other recent topics
Powered by FogBugz