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 5 was the first VB that could compile to native machine code, and its binaries
are close cousins of VB6's: the same VB5! header, the same project tables, the same
property streams for forms. Our VB5 decompiler is the VB6 engine with the handful of things VB5
does differently detected and handled — so a 1997 program comes back as a project you can open
in VB5 or VB6 today.
See a real native VB5 recovery, Frogger, next to its original source →
The runtime import tells the two apart: a VB5 program imports MSVBVM50.DLL, a
VB6 program MSVBVM60.DLL. Everything above the code — header, object table, forms,
resources — is read the same way, and the decompiler loads a VB5-specific description of the
runtime's helper functions so calls resolve to the right names.
The VB5 native compiler also emits a few patterns VB6 does not. It caches a form's own method pointer in a local and calls through it, where VB6 re-reads the vtable each time; it reaches control accessors through a register rather than a direct call; and it fills every form event-handler slot in the type information where VB6 leaves the unused ones empty. Each of these has a detector in the engine that is switched on only for VB5 files, so VB6 output is never affected, and VB5 forms get their full set of event signatures.
.vbp, forms with controls and .frx resources, modules, classes, user controls and ActiveX projects, with the components the original referenced.
Conditions, loops, Select Case, string handling, file I/O, API calls, control arrays and user-defined types — the same native engine described on the VB6 decompiler page, with the VB5-specific call patterns resolved.
VB5 P-Code builds take the P-Code path: opcodes decoded to Basic with structure, error handling and properties restored.
Form, control and class names, event handlers with parameters, Public procedures and Declare signatures come back as written; stripped names get readable placeholders.
Local, global and standard-module procedure names, type and field names, and constant names
and values are stripped from a native VB5 EXE; the decompiler substitutes stable placeholders
such as var_18 and proc_401F20 and never invents a name. Very old
third-party OCX controls may need to be registered on your machine before their properties can
be read in full. The free evaluation tells you what your specific program 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.
Only in a few compiler patterns, which the engine detects and handles automatically. The project rebuild, the forms and the code reconstruction are the same. Frogger on our technology page is a native VB5 recovery you can compare line for line.
No. The output is a standard .vbp project that Visual Basic 6 opens directly; VB5 can open it as well if you still run it.
Usually not. The decompiler reads each control's saved properties through the control itself, so having the OCX registered on the machine gives the most complete result; otherwise the control is placed with its raw property blob preserved.
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.