Confirm the format
Run the free VBScanner on the folder. It reads the file headers and tells you what built each EXE, DLL or OCX and whether it is P-Code, native or IL.
Visual Basic 2 and 3 store their projects the same way — in the resources of a 16-bit NE executable — and run on interpreters that differ in a handful of tokens. Our VB2 decompiler is the VB3 engine with its own generated token table, and it gives you back the same thing: a project in VB3's format, forms with named controls, real event-handler names and structured Basic.
See a real VB2 recovery, MISSILE, next to its original source →
A VB2 EXE names VBRUN200 in its module table where a VB3 EXE names
VBRUN300. Everything else about the container is shared: the project object table in
resource 1, globals and type descriptors in resource 2, binary form designers in the even
resources and control-name pools in the odd ones. The decompiler builds its token table per
runtime — 97 semantic records for VBRUN200 against 100 for VBRUN300 — and otherwise runs the
same designer walk, the same descriptor chains and the same statement reconstruction.
The first real-world VB2 program we recovered, a 590 KB business application with no surviving source, found three rules that the VB3 corpus had only satisfied by luck. That is the value of a second runtime: it hardens the engine for both.
Text .MAK, text .FRM files with .FRX resources and .BAS modules. VB3 opens it directly; VB4 upgrades it.
The full control tree with properties, including VBX custom controls when their descriptors are available.
Handler names are stored in the file and come back exactly; 107 distinct handler names on the 590 KB benchmark.
If / ElseIf, Select Case, Do, While, For, GoSub, On Error, typed declarations and Win16 Declare signatures.
| SSBATLS.EXE — 590 KB, no surviving source | Result |
|---|---|
| Statements rendered | 98.0% of 4,877 (unrendered 802 → 96) |
| Controls recovered | 290 |
| Distinct event handlers named | 107 |
| Output | 10,292 lines of Basic |
They return as stable invented names you rename as you read; event handlers, control names and string literals are exact. Comments are never compiled. Undecoded statements are marked, not guessed. Protected or unusual 16-bit EXEs vary — the free evaluation tells you what yours yields.
Run the free VBScanner on the folder. It reads the file headers and tells you what built each EXE, DLL or OCX and whether it is P-Code, native or IL.
License the software — $299 for one computer or $1,499 for your whole organization with the command line — and run it on your own machine. Nothing leaves your network.
Request a free evaluation. We examine the binary, tell you exactly what comes back, and quote a fixed price and timeline. Hand-finishing of anything the engine marks is included.
Structurally, no: the same container, the same designers, and interpreters that differ in a few dozen tokens. The decompiler treats VB2 as a runtime variant of the VB3 engine, with its own token table.
VB3's format: a text .MAK with text .FRM, .FRX and .BAS files. VB3 opens it; VB4 can upgrade it towards a 32-bit build.
The free VBScanner reads the NE module table and reports VBRUN200, VBRUN300 or VBRUN100 for every file in a folder.
The evaluation is free and tells you exactly what your binary yields before you spend anything. Or license the decompiler and run it in-house today.