// format by format
The details — including the fine print
Each generation of Basic stored different things in its binaries, so each
gives back a different mix. Here's what that mix looks like, format by
format.
VB6 · VB5 — NATIVE x86
Native code — the hardest case, our specialty
Full page: VB6 decompiler →·VB5 decompiler →
imports MSVBVM60.DLL / MSVBVM50.DLL · compiled to machine code
- Project structure rebuilt:
.vbp, forms with
.frx resources, modules, classes, user controls, property
pages, designers — plus MDI forms and menus
- Readable Basic rebuilt from raw x86 — conditions, loops,
Select Case, string handling, file I/O and API calls
- Real names for Public form and class procedures and for
event handlers; Private helpers come back as readable placeholders
- Local variable types inferred from how they're used; user-defined
types rebuilt field by field, including fixed-length strings
- API
Declare statements with their signatures, control
arrays, and string literals as written
Names the compiler strips — locals, module globals,
standard-module procedure names, type fields — come back as readable
placeholders like var_18. See
exactly what that means.
See three real
native VB6 recoveries, line for line →·VB5 native: Frogger →
VB6 · VB5 — P-CODE
P-Code — decompiled, not just disassembled
Full page: VB6 / VB5 P-Code decompiler →
VB's interpreted byte-code · the default in many builds
- Procedure-by-procedure decompilation back to readable Basic —
not a token listing
- The same project reconstruction as native: forms,
.frx, modules, classes, controls
- Event handlers matched to their forms and controls by name
- A raw P-Code disassembly listing available alongside the source,
for teams that want to verify our work
A few module-level declarations are reconstructed by
hand during finishing — every such spot is flagged in your recovery
report, never silently guessed.
See a real P-Code
recovery: Miner VGA →
VB4 — 32-BIT & 16-BIT
Visual Basic 4 — always P-Code, both flavors supported
Full page: VB4 decompiler →
imports VB40032.DLL or VB40016.DLL · VB4 shipped with no native compiler
- Project file, forms with
.frx resources, and standard
modules with reconstructed source
- User-defined types, module globals and
Option Compare settings carried over
- 16-bit VB4 (NE executables) fully supported: forms and controls
rebuilt, and real
Control_Event handler names read
straight from the file — not guessed
- Measured on real programs: statement-level fidelity between
91% and 99.9% in our benchmark recoveries
- Raw P-Code and reconstruction listings delivered alongside the
project
Whether your EXE is the 32-bit or the 16-bit build,
the evaluation is free — you'll see what your
specific program yields before spending anything.
See a real 16-bit VB4
recovery: VisData →
VB3 · VB2 · VB1 — 16-BIT
The 16-bit era — yes, even Visual Basic 1
Full page: VB3 decompiler →·VB2 decompiler →·VB1 decompiler →
NE executables · VBRUN100 / 200 / 300
- VB3 / VB2: a rebuilt project in VB3's own format —
.MAK, text forms, code modules — with real event-handler
names and constant values intact
- Structured source, not token dumps:
If /
ElseIf, Select Case, Do and
For loops come back as the blocks they were — on
real-world benchmarks, 96–98% of statements render
- VB1: forms, nested menus and control layout, delivered as a
modern project that opens in today's IDE
- VB1 binaries kept their symbol table — so real procedure,
parameter, local, type and constant names come back, something
even VB6 native EXEs can't offer
- Code reconstructed by machine, then completed by hand as part of
the service — with every unrecovered line marked, never invented
Protected 16-bit EXEs vary widely; the free
evaluation tells you what's recoverable before any commitment.
See real recoveries:
VB3 VisData →·VB2 MISSILE →·VB1 IconWorks →
QUICKBASIC — DOS
QuickBASIC — recovery from DOS-era EXEs
Full page: QuickBASIC decompiler →
16-bit MZ executables · QuickBASIC 4.5
- Handles standalone QB 4.5 EXEs — including ones compressed with
Microsoft's EXEPACK, unpacked automatically
- Runtime library calls identified by signature, so file, screen,
string and math operations read as what they are
- Expressions, conditions and control flow rebuilt into readable
BASIC source
- Delivered as reconstructed
.BAS source plus a
detailed analysis report
Other QB-era variants — BRUN-runtime EXEs, BASIC PDS
7.x, LZEXE/PKLITE-packed files — are assessed during the free
evaluation.
See a real QuickBASIC
recovery: Regatta →
TWINBASIC — NATIVE x86
twinBASIC — VB's modern successor, forms recovered
Full page: twinBASIC decompiler →
32-bit native EXE · statically linked runtime · no VB header at all
- Complete form recovery: every form's control tree, menus,
geometry, captions and fonts — plus embedded images extracted
byte-exact
- Real names throughout — the compiler leaves its own metadata in
the EXE, so forms, controls, procedures and even parameter
names come back exactly as written, with correct
Public / Private and argument counts
- Every procedure mapped to its exact code address, with the
Windows API calls it declares and the runtime calls it makes —
List1.Clear, Text1.Text = ... — listed in
body order
- Delivered as a project that opens and compiles, with a full
recovery report
twinBASIC procedure bodies are native machine code
with no P-Code to decompile — statement-level code reconstruction is
the frontier here, and the free evaluation spells out exactly what your
program yields.
See a real twinBASIC
recovery: Item Viewer →
.NET — CLR / IL
.NET — back to C# or VB.NET
Full page: .NET / VB.NET decompiler →
any CLR assembly · VB.NET and C# apps
- Reconstructed C# and VB.NET source, plus the raw IL for
reference — you choose which to maintain
- Organized as a ready-to-open Visual Studio solution: one file per
class, project files, embedded resources extracted
- Windows Forms applications come back with forms, controls, typed
fields, properties and event wiring
- Structured control flow — if/else, loops, switch, try/catch —
rebuilt wherever it can be proven
Where structure can't be proven, the output says so
explicitly rather than guessing — those spots are finished by hand
during the service.
See a real .NET recovery:
MapEditor, in C# and VB.NET →