Sustaining VB6

Written by

in

The runtime is less “vulnerable” than you fear. Microsoft still ships the VB6 runtime in Windows 10 and 11 for the lifetime of the OS, and services it only for serious regressions/critical security issues.

What’s truly dead is the VB6 IDE, unsupported since 2008. So your compiled apps keep running for now (roughly until Win10/11 EOL, ~2031), but you have no safe, supported way to rebuild them from source using the old tooling.

Here’s how the realistic paths compare:

Five realistic paths for a VB6 codebase whose maintainers have retired. Scores are 1–5 (higher = better).

The two rightmost options recompile from your existing source; the rest keep or rewrite it.

OptionKeeps codeSecure runtime64-bitLong-term supportLow cost
Keep VB6 runtime (status quo)51125
VB6 IDE on Win11 (unsupported)51115
twinBASIC (recompile)44545
Mobilize VBUC → .NET35553
Full rewrite15551

The options, in order of how I’d actually sequence them

1. twinBASIC — recompile without a rewrite (strongest fit for your situation). It’s a modern BASIC built specifically for VB6 backwards compatibility. It imports your .vbp projects (source + forms) and compiles to native 32-bit and 64-bit Windows, with full Unicode, modern controls, generics, inheritance, multithreading. Community Edition is free (a splash screen on 64-bit binaries). It’s actively developed — TWINBASIC LTD was formed in Nov 2025 ahead of a v1.0 release. Caveat: the OLE container control isn’t reimplemented yet, and a few third-party/Enterprise OCX controls may need community replacements (Krool’s VBCCR/VBFlexGrid have 64-bit tB versions). This is the path that lets you recompile from existing source and shed the legacy runtime with the least churn.

2. Mobilize.Net VBUC — migrate to .NET. The “Visual Basic Upgrade Companion” converts VB6 (and mixed ASP/VB6) to VB.NET or C#, now targeting .NET 6+. It maps legacy data access (ADO/DAO/RDO) to ADO.NET and many ActiveX controls to .NET equivalents, keeping proven logic intact. Microsoft partnered to offer a free license for up to 10,000 lines (use their discount code). Above that it’s commercial. Best when you want a permanent move onto a fully-supported, modern, 64-bit, cloud-ready platform — but expect cleanup work after conversion and a learning curve for the team on .NET.

3. Keep running as-is (buy time). The runtime is supported through the OS lifecycle. Reasonable as a short-term bridge while you pilot twinBASIC or VBUC on one module. Do not treat it as a strategy — it ends with the OS, and you have no maintainers to fix it when something breaks.

4. VB6 IDE on Windows 11 (avoid for anything new). It installs with compatibility hacks (XP SP3 compat mode, admin, skip Data Access components, install VS6 SP6) and mostly works, but it is unsupported and unpatched. Fine only for emergency fixes to existing builds; do not build your modernization plan on it.

5. Full rewrite. Highest cost, highest risk, longest timeline, but full control (C#/.NET, web, cloud). Usually the right answer only if the app is small, the business logic needs to change anyway, or .NET conversion leaves too much debt.

Recommended approach

Pilot twinBASIC on one non-critical module to measure import fidelity and 64-bit conversion effort for your specific controls and API calls — that tells you whether a near-no-rewrite recompile is viable.

In parallel, run Mobilize VBUC’s free tier on the same module as a .NET benchmark. Pick the path that leaves you with the least residual debt, then execute module-by-module so the app is never fully offline during migration.

TWINBASIC

Here are the key twinBASIC references, grouped by what each is useful for:

Official sources

Documentation & FAQ

Source, roadmap, issue tracking

VB6 import / real-world conversion evidence

Independent progress blog (the de facto changelog)

No Longer Set publishes weekly twinBASIC updates — the most reliable way to track what’s actually shipped and what’s still pending:

Control replacements for 64-bit builds

Several VB6 OCX controls aren’t reimplemented in tB yet; these community ports have 64-bit tB-compatible versions:

How to use these

For a go/no-go pilot, read in this order: the official FAQ (control/feature coverage), the SO answer (real conversion scope), the discussion (someone else’s import result), and the latest No Longer Set update (current build state). Then check the GitHub issues for any specific control or API pattern your codebase uses.

Comments

Leave a Reply