Why is VB6 still so widely used?

Question

Note that this question is not meant to start an argument, I am genuinely curious:

Back in the 90s I used to work for a large CPU maker and we were building some debuggers. All our core logic was in C++, but the GUI was made in VB6. We couldn't figure out MFC and it was too much a hassle. We glued together VB6 and C++ using COM which we created via ATL.

Fast forward to 2009, having been mostly in the Java world I am looking at job boards and seeing more VB6 jobs than I expected. I genuinely thought that VB6 was extinct, especially since VB.NET supposedly solved a lot of the problems with the VB6 which at the time felt a lot like a scripting language than a true OOP language.

So what happened? Why is new code still written in it? Isn't there a better way to glue C++ and VB.NET?

Note that I haven't used VB.NET, I just understand that it is a much more "stricter" language than VB6 was. Even with Option Explicit or whatever it was.

Answer 1

the last (small) company i worked for liked to stick with familiar technologies, as the development team was small and consisted of one member who was constant - all new things are being built with .NET, however. i'd be surprised if those weren't maintenance programming jobs, intended for work with legacy systems rather than new applications

Answer 2

The key to the ongoing popularity of VB6 is that it's really easy to code, creates useful applications quickly and users don't care what language the app is written. Of course there are now better languages, but better for who - the users, the millions of people who know VB6 well enough to create apps, or developers who know the best way of doing things?

The learning curve to get to .Net or Java is just too high for many people. To look at another example, you couldn't get much simpler than straight HTML, yet that created the biggest revolution in computer usage. As languages are designed by IT gurus they tend be designed for IT gurus, shame that all the users really want is simplicity.

Answer 3

As much as I hate VB (and VB.NET), it does do some things well enough to warrant its existence. It is good for building GUIs, and maybe some other unknown things. I would guess that compatibility is a big reason for people to keep using VB6. Also, I think the people that tend to use VB (especially VB6) aren't always interested in the latest trends, they just want to get the job done in a way they know how.

Answer 4

Part of it may be that VB6 was so successful within larger organizations for doing enterprisey apps; VB6 is the new COBOL. A lot of organizations don't have the time or inclination to "port" VB6 to VB.NET or C#, it's just not a priority for the business. For a lot of systems, VB6 is still "good enough".

Answer 5

My company flat out has too much code in vb6 to port it out. Most likely this will happen in the relatively near future (to take advantage of 64 bit), but its (mostly) stable and mature. A rewrite will probably take 10 developers 3 years working full time. If you have something that is mature, it doesn't make good economic sense to port it unless there is a good reason.

Answer 6

Another reason, in addition to the reasons above, is that it's extremely easy to deploy a VB6 application. There's no 250 MB redistributable to pull down (with all due respect to http://www.hanselman.com/smallestdotnet/).

Answer 7

VB6 is still used simply because there is no simpler way of creating COM objects, and there are LOTS of systems that are COM based - for example the whole Office suite. .NET did not fill the COM void, and I think they should still offer VB6 inside the current Visual Studio line up.

Answer 8

A lot of companies do not find it necessary to immediately rewrite their software to a newer technology unless it is mission critical or will save them money...

They find it cheaper to maintain rather than rebuild.

This is why there are still a need a COBOL programmers.

Answer 9

Because it is RIDICULOUSLY easy for a non-developer to understand and use. In the corporate world, many non-programmers start programming with VBA (e.g. in Excel) ... transitioning to VB6 is a natural progression.

Answer 10

Visual Basic up through VB6 was the way to create small simple applications. It offered instant gratification (for example GUIs with no coding whatsover) and still had a moderate amount of power once you needed it. It did have a runtime library, but it was nowhere near the size of .NET's current one... tiny apps still only required a few MB of RAM.

I remember back with .NET 1.0 when Microsoft decided to can VB6 in favor of VB.NET, there were tons of people who predicted that people wouldn't want to move languages, and would stay with VB.NET. Looks like they were right. MS also provided an upgrade "Wizard", which was supposed to simplify the task of upgrading apps from legacy VB to VB.NET. If I remember correctly, it didn't really work very well.

IMO VB.NET is no longer "Basic" anymore, but people still want a simple no-frills way to create applications. VB6 is probably the only way for the "layman" to get started programming.

Answer 11

Two reasons: VBA and legacy code.

VBA is still COM based. And I know how to write stuff that works with that in VB6. I don't even know how you'd use .net code from VBA. I've never tried or researched it. Honestly I'd just like to keep the two separate anyway. Secondly there are tons of legacy applications out there in business. And they need maintenance. And nobody wants to rewrite them for technologies sake. They just want to get their work done.

Also remember that VBA is not office only. There are other apps that use it. I work with one extensively and it has a very large deployed base. Not every client uses the vba functionality but several do. All my web based work is asp.net using vb.net. But the desktop work is still VB6 and VBA based. We are even producing new VB6 apps designed to work with the application. But 90% of the work is maintenance, fixing long term bugs or adjusting functionality to support new requirements.

Answer 12

VB6? I would happily use this if there was a demand: :-)

The Clipper Compiler, Summer '87
Copyright (c) Nantucket Corp 1985-1987.  All Rights Reserved.
Microsoft C Runtime Library Routines,
Copyright (c) Microsoft Corp 1984-1987.  All Rights Reserved.

                Richard McConnell & Brian Russell, Sr. VP

                Kevin Shepherd      Dennis Dias
                Rick Spence         David Dodson
                Jon P. Rognerud     Fred Ho

        options:
                -l   (no <l>ine numbers)
                -m   (compile one <m>odule only)
                -o   (<o>bject file drive and/or path)
                -p   (<p>ause for disk change)
                -q   (<q>uiet)
                -s   (<s>yntax check only)
                -v   (<v>ariables are assumed M->)

                @list.clp (list of files to compile)

        A>clipper a:main.prg -p -ob:
        C>clipper @list.clp -l -q

Or this (OMG, I can't believe the executable still runs 22 something years later):

┌──────────────────────────────────────────────────────────────────────────────┐
│                    dBASE III PLUS  Version 1.0 IBM/MSDOS                     │
│     Copyright (c) Ashton-Tate 1984, 1985, 1986. Alle Rechte vorbehalten.     │
│              dBASE, dBASE III, dBASE III PLUS, und Ashton-Tate               │
│                     sind Warenzeichen von Ashton-Tate                        │
│                                                                              │
│       Sie sind berechtigt die dBASE III PLUS  Software sowie das gedruckte   │
│       Begleitmaterial  zu  den  Bedingungen  des  Endkundenlizenzvertrages   │
│       zu nutzen.  Der wesentliche  Inhalt  dieses  Lizenzvertrages ist es,   │
│       Ihnen eine  nicht übertragbare,  persönliche Lizenz zur  Nutzung von   │
│       dBASE III PLUS  auf einem  Mikrocomputer oder an einem  Arbeitsplatz   │
│       zu gewähren.  Die geistigen  Eigentumsrechte verbleiben bei  Ashton-   │
│       Tate;  Sie dürfen die  Software und das  Begleitmaterial weder  ver-   │
│       vielfältigen  noch  verändern.  Jede Verletzung des  Lizenzvertrages   │
│       oder Urheber- und Warenzeichenrechte kann rechtlich verfolgt werden.   │
└──────────────────────────────────────────────────────────────────────────────┘




                           Drücken Sie F1 für HILFE.
.
Befehlszeile    ║<W:>║                       ║                   ║      ║
  Geben Sie einen Befehl (oder ASSIST) ein und drücken die RETURN-Taste (◄─┘)
                     Einen dBASE III PLUS Befehl eingeben.

Why am I posting this? Because VB6 is not the first technology that became obsolete, and because there is something to learn from earlier examples - namely that popular languages are hard to kill. People were still developing DOS-based applications with Clipper well into the 1990s, and many of these applications lived past Y2K. The productivity of this platform was simply amazing. Of course there was a point when IT managers could no longer justify an investment into this obsolete platform, and it disappeared relatively quickly, as there was no migration path. Character-based applications just did not appeal to Windows users, and Visual Foxpro was a marginal product, compared to the popularity of DBase and Clipper.

Answer 13

My company still has many VB6 apps running in production doing critical tasks server based tasks that would have been better suited for languages such as Java, C or C++. A rewrite would take years just because of the domain knowledge that has gone out the door.

I often wonder why anyone was crazy enough to write applications in VB of all languages. It is mostly because it is easy to learn while Microsoft makes it so easy to drag and drop things.

The glut of old code is probably still around and someone has to maintain it, just like COBOL.

Answer 14

I remember something Simon Peyton Jones said in a talk. (Paraphrasing) Based on number of users, there is a line that once a specific language crosses, there is so much code written in it that it basically cannot die.

Answer 15

It's very easy to write very bad, unmaintainable code in VB6, and harder and harder to find developers who can maintain it.

I fear that the majority of companies still using VB6, Classic ASP, Windows NT 4 or 2000, and other legacy "code" will eventually learn why "it ain't broke" was not a good idea. These are typically the same companies who do not document their code well, or even lose the source code, and continue to take no action because it "ain't broke".

In the meantime, they are slowly losing the knowledge necessary to fix the old code or to port it or rewrite it. They will need to pay more and more money to hire good people to maintain the code, or else pay less for those who can't find work elsewhere and will work wherever they can get paid.

And even in static industries, nothing is static forever. They'll eventually have a customer who wants web services added, or a competitor who has exposed their functionality on a web site, and they'll want the legacy code to compete with more modern requirements. And then they'll find out why the legacy languages were largely replaced by what came later.

I should add that I've seen one very good web-based application written in VB6 with XML, XSLT and JavaScript. The largest problem they had was that some of their modules had become too large. Not a very big problem. But, having seen that application, I know why the exception is not the rule - it took some very smart architects to create a flexible, maintainable and well-documented architecture that this company has been able to build on.

Most VB6 applications I've seen aren't like that.

I also want to add that I have not included COBOL in this list. There's so much intertia for COBOL that I don't expect a lack of COBOL expertise until next century. It still suffers a bit from lack of knowledge, but in the other direction - how many people know what a "copybook" is, or could help someone figure out how to serialize it? How many people have any idea how to call a web service from a COBOL program? Not that it can't be done, but most of the people who know about serialization or web services don't know anything about COBOL, and so couldn't help.

---

Code that never needs to changed, looked at, or even thought about, is code that really "ain't broke" in my opinion. Write it in Assembler without comments, for all I care.

Any other code needs at least to be changeable, readable, and understandable, not just today, but tomorrow, if you plan to have a tomorrow. Otherwise, you'll find a day when nobody can understand, read, or change the code, and you may some day need to do so.

Note that I suggested that adequate documentation is as good as keeping the code up to date. It may be necessary to include the manuals for VB6 in the documentation package, in order to train developers who have heard of VB6 only from their grandparents, but it should be possible to document the code well enough that only time is wasted when it needs to change.

It could be done, but in many cases, it won't be done.

Answer 16

Absolutely, you could say the same for VBA. Most people can Google for macros and stitch together simple scripts to get their jobs done. For most, that's all they really want.

In addition to all the answers here, some companies outsource their development, and as such, impose restrictions on developers. For example, "we are not allowed any software such as .NET or JAVA, so you have to write the app using VBA or VB6". I'm dealing with this right now, I have to cast my mind back, but I'd rather use VBA atm moment than MFC.

And as mentioned, legacy apps. Most of these are large, often poorly refactored, maybe the source was lost or the company who wrote it isn't around, or the developer is deceased, or isn't broken, so why mess with it? We all know what this leads too, but for the most non-developer staff it doesn't really matter to them. They wistfully do their jobs and do not care about how it looks or works, just that it does.

And just because something is dated and stale isn't enough reason for management to give permission to rewrite it.

One last thing, maintainability. VB6 is a heck of a lot cheaper to maintain than MFC. Anyone who knows MFC well and didn't get sucked up in the .NET and JAVA worlds is pushing 40 and is going to cost a lot of money.

Answer 17

1. Easy to use
2. It usually works first time
3. Plenty of example code.
4. Allows you to make an application without spending a year to understand a complicated framework of goobly gook.
5. There are no traps for beginners.

Answer 18

In addition what Steve said there are several features that VB6 still has a more ease of use (graphics and printing). VB.NET has closed the gap in many ways and while VB6 may be easier to use VB.NET is more capable. The only major usability problem I consider remaining is Printing. However Microsoft has mostly addressed that in the Printer Compatibility Library in VB Power Pack. Since the 2005 release, for a NEW project, I can work pretty much the same way in VB.NET as I can in VB6.

The real pitfall is still backwards compatibility. Microsoft blew their foot away with that. This was made even more egregious when it was found out that that many of the changes were NOT required by the .NET runtime. For example having Integer compile to a Int16 instead of a Int32. As more and more languages (F#, Boo, Python, etc) were released it became evident that that MS's decision not to support backwards compatibility was an arbitrary decision. This caused a loss of trust in Microsoft as a vendor for many VB6 developers.

This is a critical issue because working code is a very valuable asset and is not lightly abandoned.

The need to maintain working code and loss of trust are the two main reasons why VB6 persists to this day. The amount of NEW projects started in VB6 is probably minimal.

Answer 19

In My Opinion, #1 reason is that Microsoft gave no viable (practical/usable/workable/choose whatever word you want) upgrade path from VB6 to .NET like they did for all other versions prior.

The #2 reason is that it still works for its intended purpose - Rapid Application Development (if you can still find a copy to purchase that is).

So many people (myself included) have stopped at VB6 to preserve years and thousands of lines of code.

Answer 20

One factor may be that in its heyday so many people used VB5 and VB6 that no other programming language effectively existed. Even assuming 90% defection for numerous reasons since The Great Disgrace that leaves a lot of VB6 programmers yet if you consider sheer numbers.

The architecture of .Net parallels that of Java, for good reasons. Mostly that it's a ripoff. Thus it inherits many of the same handicaps Java has, being a poor choice for desktop development and strongest on the server. However .Net still lacks some key components that the Java ecosystem does have, primarily decent app server support in the form of Java EE (formerly J2EE). Even many Java programmers don't seem to comprehend what the EE platform brings to the table, perhaps because those using it take it for granted. Microsoft hopes to address this with what looks like a BizTalk rewrite (codename Dublin).

So VB6 is left with a huge niche that it only shares with less productive tools (C++) and quirky minority tools (Delphi). For low volume shrink wrapped desktop software VB6 is hard to beat, especially since the advent of registration-free COM in Windows XP and bundling of stable VB6 runtime components as part of the core Windows installation.

Where VB6 is weakest is its Web and server-side stories. The latter is reasonably well addressed via COM+ but still needs refinement. Good VB6 support in IIS was never developed beyond a first attempt (Web Classes, the conceptual precursor to ASP.Net). Another growing problem is multiplatform interoperation. As the world shifts further toward Web Services VB6 lags in terms of tools support, though at least there are functional if limited options.

WPF is doomed to die because it was developed in such a way as to be extremely difficult to use from non-managed environments. So you have a desktop-centric technology that cannot easily be used from the prime desktop development tools. Its only real hope of success would be a follow-on to VB6 that offered full IDE designer support as well as runtime support in the form of wrapper objects for the underlying technology.

WCF faces the same fate but Microsoft has seen the light in a small way, providing at least C/C++ support at this point via the new WWSAPI.

There is no question that VB6 needs a facelift desperately. But even so there just isn't a good alternative available. Fortunately there is still a strong community, and as time goes on workarounds are developed to help VB6 programmers cope with changes.

And yes, lots of new VB6 software projects are undertaken daily. It is entirely a myth that VB6 is only being used to maintain old applications.

Answer 21

VB6 is still being used because Microsoft made it difficult to migrate VB6 code to VB.NET. Which part of that is hard to understand?

Microsoft's own advice (screencast) is that VB6 applications should only be moved to .NET if major changes are planned. It requires significant effort to migrate them with the built-in VB.NET upgrade wizard - that's according to the original developer of the wizard.

Personally I find the suggestion that VB6 developers don't like learning very irritating. Microsoft UK surveyed VB6 developers in January 09, and found that at least 45% are using .NET as well as VB6. Many of us love learning and are using VB.NET for new development, but we have actual working applications ("legacy code") that still need maintenance.

---

Microsoft's decision to abandon VB6 applications was controversial and alienated many loyal VB6 developers. It was noticeable that Visual C++ code was treated with more respect - there was no suggestion that Visual C++ would be retired in favour of C#. As RS Conley has said in his answer, it has become plainer and plainer that many of the changes that broke VB6 code were not required. Also, Artinsoft and CodeArchitects are now offering proprietary tools that apparently migrate VB6 applications to VB.NET with very little manual effort. Microsoft UK are recommending these tools as better than the built-in wizard. This shows that Microsoft could have provided far more help. Personally I believe they should buy one or both of these companies and make the tools available free. I may start my own petition!

Answer 22

It is still used because many, many companies have a lot of code written in VB6, and Microsoft didn't leave developers with an easy way to upgrade this code to .NET. Large applications usually have to be rewritten in .NET to work the exactly the way they did in VB6, and most businesses don't have the time or the money to make this happen, so they would just rather maintain their VB6 code so long as it gets the job done.

Answer 23

One of the main reasons is legacy apps written in VB6 some of which would cost too much to port to a newer language. The previous company i worked for had two of their biggest products written in VB6.

They chose VB6 at the time (and still use it along side .NET for new products) was its speed ease of use, and the ease in which a new dev. can pick up the language.

Personally I always recommend people who are interested in programing to start with C# and only if they really find it hard to fall back to VB.NET.

Answer 24

In addition to some of the great answers already posted, let me throw one more in.

For the same reason that people use a lot of legacy software.

If it ain't broke....

Answer 25

I guess the two main reasons are the same as for why people still program in COBOL: tons of old code that ain't broken so it's still in use daily, and because people like it and it does what they want. Any programming language is a tool; if you like using a hammer to knock in nails, why should you switch to using a screwdriver to do that? Hammers work well for knocking in nails. Sure, using a screwdriver instead might be sexy, and maybe all the cool kids use screwdrivers these days to knock in nails, but if you don't really really need to, why should you? Use the best tool for the job at hand. For many people, the tool is VB6.

Answer 26

Our business software is written using VB6, and this is painfully obvious. Usually, it is the choice of a developer (company) to stay with VB6, for If they decided to change to VB8 (or even 2010) and rewrite everything, restructure their database schemas, redesign all their interfaces, and offer a much needed deployment method, the cost, both in time and culture shock, would be so great, that it might just put the developer out of business. It is far more profitable to stick with the old, leave it full of quirks, non-intuitive interface conventions, and a planned and billable need for user support plans. For if, the software was rewritten and deployed in a manner consistent with something like MS Office or Quicken or other mass distributed and constantly upgraded software, their customer base would have to grow by ten-fold to generate enough revenue to make a profit. Developers of niche category software depend on semi-monopolistic business conditions to ensure their survival and maximum profitability. There simply is no incentive nor outer force that compels them to modernize their product.