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.
twinBASIC is Visual Basic's modern successor, and its executables are unlike any VB6 file: a
native 32- or 64-bit PE with its own statically linked runtime, no VB5! header and no
P-Code. What they do carry — and what no VB6 native EXE gives us — is the compiler's own
reflection tables. Our twinBASIC decompiler reads them to recover every form, control,
procedure and parameter by its real name, and delivers a project that compiles.
See a real twinBASIC recovery, Item Viewer, next to its original source →
Four structures carry the project. Member metadata in the data section lists every interface's members by name (lightly encoded — the newer compiler XORs each byte with a constant). A function table gives the exact entry point and byte length of every procedure, runtime included. The form designer is a DEFLATE-compressed blob, which is why a strings search of a twinBASIC EXE finds no caption or control name anywhere; the engine inflates it with its own port of zlib's reference decoder. And a string literal pool holds the program's strings in BSTR layout. Both compiler generations and both bitnesses are handled — the x86 and x64 builds of the same project export a byte-identical form file.
Classes, forms, controls, procedures and parameters exactly as written — 219 of 219 parameter names on the corpus, none wrong — with return types, Public / Private and argument counts exact.
Every control's class, parent, position, size and caption; menus; embedded images extracted byte-exact; an imported ActiveX control's property bag.
The call graph (389 procedures checked against source, 0 differences), the Declare table with each call site's arguments in body order, and 1,476 runtime calls named — List1.Clear, Text1.Text = ... — with 0 wrong.
.vbp, one .frm per form and a .frm.twin carrying the attribute GUIDs, plus a recovery report. All ten exported benchmark projects compile.
| Metric | Result |
|---|---|
| Procedure addresses bound / checked against ground truth | 318 bound · 89 checked · 0 wrong |
| Procedure headers exact (visibility and arity) | 321 |
| Parameter names · return types · runtime-call names | 219/219 · 206 checked · 1,476 checked — 0 wrong |
| Designer and procedure recovery, ItemViewer (both compiler generations) | 55 of 55 · 21 of 21 |
| Procedure bodies lifted to statements | 240 procedures · 2,663 lines = 53.7% of the source's statements |
twinBASIC procedure bodies are native machine code with no P-Code, so code comes back through a lifter that currently emits about half of the statements as code and the rest as annotated walker comments, mostly around COM object plumbing. Local variable names, type and field names, module-level globals, constant names and comments are not in the file at all. Property names beyond name, geometry and caption are still being decoded. The free evaluation spells out exactly what your program yields today.
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.
Yes: the forms, menus, class and procedure structure and every name come back exactly, because the compiler leaves its reflection tables in the file. Procedure bodies are native code and are partially reconstructed today.
Yes. Both 32-bit and 64-bit builds are read, and the same project exported from each is byte-identical.
Procedure headers with real names and types, the call graph, Declare call sites and named runtime calls in body order, and structured statements where the lifter can prove them, with the rest clearly marked rather than guessed.
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.