For years we have received the same message from users disappointed by a decompiler: "my application wasn't recovered." In almost every case the cause is identical — a confusion between the two compilation modes of Visual Basic 6. This article explains that fundamental distinction, because it alone determines whether, and how, your application can be decompiled.

Two compilation modes, two worlds

Visual Basic 6 offers two ways to produce an executable, set in the project options:

  • P-Code (pseudo-code): the code is translated into compact intermediate instructions, interpreted at runtime by the VB virtual machine (MSVBVM60.dll). The executable is smaller, but needs the interpreter to run.
  • Native Code: the code is compiled directly to x86 machine instructions, like a C++ compiler would. The compiler can analyze large code blocks to remove redundancy and optimize the result.

These two approaches produce radically different binaries. A decompiler designed for P-Code cannot handle Native Code, and vice versa. That is where the disappointment happens: many users buy a P-Code decompiler, then discover their application was released as Native Code.

The right question to ask

Before any purchase or attempt, ask yourself: "Is my application compiled as Native Code or P-Code?" That's the starting point. A tool that doesn't state which mode it supports should raise a red flag.

What is the real proportion of each mode?

In practice, Native Code dominates by far: around 90% of VB6 applications are released as Native Code. Several reasons explain this:

  • It is the default setting of the VB6 compiler;
  • Native applications run almost as fast as C++, which P-Code does not;
  • Developers rarely have a reason to switch back to P-Code once the project ships.

P-Code, although easier to decompile thanks to its high-level nature, therefore remains marginal. This is precisely why P-Code-only decompilers are largely obsolete today.

Our choice with VBReFormer

This observation guided the development of VBReFormer: top priority was given to Native Code decompilation, the mode that concerns the vast majority of real applications. VBReFormer handles both modes, but it is its ability to reconstruct readable Visual Basic from x86 machine code that makes the difference in the field.

In short: identify the compilation mode first, be wary of tools that stay vague on this point, and assume there's a 9-in-10 chance your application is Native Code.