A Visual Basic 6 application is still running in production, fifteen or twenty years after it went live, and the company wonders how long that can last. The answer often surprises: it is almost never the language that gives way.

The runtime is not the problem

Microsoft committed to one specific thing: the Visual Basic 6 runtime library — MSVBVM60.DLL — is supported for the support lifetime of every version of Windows, under a principle explicitly named "It Just Works". It ships with, and is supported on, Windows 11.

What lost its support is the development environment, in April 2008. In other words: your application keeps working, but the tool that allowed you to change it is no longer supported.

That is the whole difficulty, and it is widely misunderstood. The risk is not that the program stops one morning. The risk is that nobody can touch it on the day it needs to change.

What holds and what gives way

What holds

  • The VB6 runtime, supported by Microsoft
  • 32-bit executables, which run on 64-bit Windows
  • The binary format, unchanged since 1998
  • The business logic itself, which does not decay

What gives way

  • Third-party OCX and ActiveX components whose vendor has gone
  • The development environment, unsupported since 2008
  • The data access layers of the period
  • The source code, mislaid or never archived
  • And above all: the person who knew how it worked

The last two lines are what create the real emergencies. An application you cannot modify is not yet a problem — until the day a legal notice changes, a partner alters a file format, or a third-party control refuses to register on a new machine.

On the question of execution itself, we cover running a VB6 application on Windows 10 and 11 separately.

The effort depends entirely on what has to change

Many requests that look as though they require a full rewrite do not. Worth knowing before budgeting for one.

A wording, a logo, a windowCompany name, legal notice, image, form layout: editable directly in the binary, without the source and without recompiling.
A business rule, a calculation, a formatYou have to reach the code. Without the sources, that means recovering the project.
A third-party component to replaceThe trickiest case: you need the code to substitute the control and rewrite whatever used it. This is often what triggers the whole exercise.
A migration to .NETIt assumes you have the project. Decompile first, migrate second — never the other way round.

What you can establish today

Before any decision, it helps to know what the binary you hold actually contains. A VB6 executable keeps far more than one imagines: the full description of the forms and their controls, embedded resources, references to the COM and ActiveX components used, Win32 API declarations, and the names of public procedures.

That inventory answers concrete questions nobody in the company can settle any more: which third-party components does this application depend on? How many screens does it have? Was it compiled to P-Code or native code — which determines what a decompilation will give back?

What compilation removed does not come back: local variable names, private procedures, comments, folded constants. The actual coverage of the reconstruction is published with its denominators — 1,153 documented correspondences, function by function and instruction by instruction.

A word about the word "support"

We publish a tool, not a managed-service offering. What VBReFormer brings to a VB6 application with no source code is the ability to open it, inventory it, modify its interface and reconstitute its project. The rest — operations, hosting, user assistance — belongs to your organisation or your service provider.

The distinction is worth stating, because most companies that write to us have a problem of control before they have a problem of operations: the application works, but nobody can make it evolve.

Where to start

The free edition of VBReFormer opens your executable and shows you its compilation mode, its forms, its controls and its resources. Within seconds you know what is recoverable — and therefore what the change you are considering will actually cost.

Make sure you hold the rights to the application concerned: the most common case, by far, is recovering your own software.