VB RezQ Recovery Performance
VB RezQ recovers a set of files from a compiled 32-bit Visual Basic
program. Although these files are only partly complete (e.g. they do
not include any of the Basic language contents of sub-routines),
they do contain most of the graphical design (GUI) and the overall
structure of the program and so form a useful starting point for
rebuilding the program source.
When saved from VB RezQ, the recovered file set is ready to be opened
as a project in the Visual Basic development system (IDE). Our aim is
that the project should load into the VB IDE without error. This may
not always be achievable directly and in these cases some manual
editing of the files may be necessary first.
This section provides more information about the recovery process and
the accuracy of the recovered files.
The file set recovered by VB RezQ will match the version of Visual
Basic that was originally used to compile the program being recovered.
VB RezQ does not attempt to perform any version conversion. E.g. for
a program that was compiled by Visual Basic 4 (32-bit), the recovered
file set will be suitable for loading into the VB4 IDE. Loading the
recovered files into the IDE of a later version of VB may produce
warning messages but should not be a problem.
Project File (.vbp)
VB RezQ recovers the following project file entries from the
information stored in the compiled program :-
Type=Exe (or Control or OleDll or OleExe)
Some of the entries in a project file are IDE specific and are not
represented in the compiled program. For these, VB RezQ will recreate
a typical entry.
VB RezQ determines the type of project.
VB RezQ identifies all the files used in the project and
creates filenames for them as the original filenames are not
present in the compiled program.
VB RezQ recovers the filenames of custom controls and uses a
look-up table to recreate the full entry for the .vbp. The
look-up table within VB RezQ caters for all the standard custom
controls and is extended by additional entries in the
"moreocxs.txt" file. This enables the user to customise
VB RezQ to cope with specific custom controls. The look-up
table is also used to recreate the corresponding custom control
entry for each Form (.frm) that uses the control.
VB RezQ identifies when additional Windows resources are
present in the compiled program and will recreate the "Res32.res"
Startup="frmWidgetMain" (or "(None)" or "Sub Main")
StartMode=0 (or 1)
VB RezQ determines the startup mode of the program.
Description="A Widget Tool"
VB RezQ recovers these text items from the program.
(optional, not VB4)
This item is included if determined by VB RezQ.
VersionComments="Acme is best"
VersionCompanyName="Acme Widget Inc."
VB RezQ recovers the version information for the program.
CompilationType=0 (or 1)
VB RezQ identifies whether p-code or native compilation was used.
Unattended=0 (or -1)
Retained=0 (or 1)
ThreadPerObject=0 (or -1)
MaxNumberOfThreads=1 (or n)
ThreadingModel=0 (or 1)
(optional, not VB4)
VB RezQ recovers these memory and thread settings for the program.
Graphical User Interface (GUI) - Forms etc.
The graphical design of the compiled program is recovered by VB RezQ
and saved as the first section of the (.frm) files which it recreates
for each Form. Where necessary, VB RezQ also recreates the
associated (.frx) files which contain binary data such as picture
bitmaps. In a similar manner, VB RezQ recovers the graphical design
for UserControls (.ctl), UserDocuments (.dob) and
In Visual Basic the graphical design is specified as the properties
(e.g. BackColor) of instances (e.g. Command1) of object types
(e.g. CommandButton). Actually, it is only the properties which have
non-default values which are explicitly stored. There are two
categories of object types; those that are members of the standard set
of controls that are built-in as part of the Visual Basic
runtime DLL (e.g. CommandButton), and 'custom' controls
(e.g. CommonDialog) which may be added to extend the standard set and
are implemented by additional support files (e.g. comdlg32.ocx). While
VB RezQ will completely recover all of the properties of the standard
controls, the custom controls provide more of a challenge.
Firstly, Visual Basic adds a wrapper (the VBControlExtender) around
custom controls and this provides a standardised set of properties for
all custom controls. VB RezQ will completely recover these properties
for all custom controls.
Secondly, custom controls have their own properties and are designed
to take responsibility for saving and loading these themselves. As far
as Visual Basic is concerned, the custom control is using a block of
bytes for its own purposes and Visual Basic has no understanding of
what those bytes mean. As there is no standard format for these blocks,
it is impossible for VB RezQ to use a generic technique to recover
these internal properties for all custom controls. However, for many
of the more commonly used custom controls, we have uncovered the
coding used for their data blocks and given VB RezQ the ability to
fully recover all their properties. For other custom controls, VB RezQ is
currently unable to recover these internal properties.
Version 5 of Visual Basic introduced the Designer (.dsr) module
type which also has some graphical design information. In many ways the
implementation of a designer is similar to that of a custom control
and the comments above for custom controls apply to designers - though
there appear to be very few 3rd party designers in existence.
VB RezQ will recover the standard "wrapper" properties of all designers
and partially recover some of the properties of the following designers
- Add-In, Data Report, Data Environment, DHTML Page, Forms and
A few custom controls and designers when their properties are only
partially recovered may cause an error report when loaded into the VB
IDE and some manual editing may be necessary.
Where the compiled program makes a call to an API function, VB RezQ
will recover the external procedure name and the name of the
dynamic-link library (DLL) which contains the procedure. VB RezQ is
not able to recover the procedure's parameter list nor to determine
whether the procedure is a Sub or a Function. VB RezQ will recreate a
partial Declare statement as a comment, e.g.
' Declare Function GetWindow Lib "user32" ()
For VB5 and VB6, VB RezQ attempts to determine the appropriate source
file to which each Declare statement corresponds. The technique used
is not perfect and it may sometimes assign a Declare statement to
a source file earlier in the project than would have been the case in
the original source. For VB4, VB RezQ places all Declare statements in
the last source file in the project.
Although VB RezQ does not recover the Basic language code within the
body of the compiled program's subroutines, it does identify the
subroutines corresponding to each source module and will recreate
declarations for them. This can provide a good 'aide-memoire' for
reconstructing your program source. There are the following variations
in the form of the declarations that VB RezQ will produce:-
For the events of controls, VB RezQ will recreate the
full declaration including the parameter list, e.g.
Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
This applies to all the standard built-in controls, to the range of
over 25 commonly used custom controls for which VB RezQ provides a full
recovery of properties and events and to most of the custom controls shipped with VB.
For the events of all other custom controls for VB4 and VB6, VB RezQ
will recreate a partial declaration as a comment using the control
name and an event number, e.g.
The user may be able to determine the true event name and parameter
list for this event number by compiling a test program using the custom
control and comparing its source with the output from VB RezQ.
For the events of all other custom controls for VB5, and for all other
functions and subroutines where the compiled program contains the
subroutine name, VB RezQ will recover this and recreate a partial
declaration as a comment, e.g.
VB RezQ is unable to distinguish between the Sub, Function,
Property Get, Property Let and Property Set styles of declaration and
will always use Sub in the recreated version. For all other cases where
there is no name stored within the compiled program, VB RezQ will
create a name derived from its sequential numbering of the
Where a Sub Main is set as the first subroutine to be run when the
program loads, VB RezQ will ensure the appropriate subroutine is declared
as Sub Main().
Native Code Disassembly
For programs compiled to native code, VB RezQ can provide a disassembly of
the x86 code. VB RezQ analyses the address references in the native code and
indicates jumps to other locations in the same subroutine, calls to other
subroutines, calls to routines in the VB Runtime DLL, calls to API
routines in other DLLs, and references to text strings.
The disassembly is displayed as commented lines within the subroutine
declaration. The user can select the level of display from none, through
a brief analysis, e.g.
to a full listing, e.g.
'N * ref: __vbaExceptHandler
'N * ref: __vbaStrToAnsi
'N * API ref: RegOpenKeyExA
'N * ref: __vbaSetSystemError
'N * ref: __vbaStrToUnicode
'N * ref: __vbaFreeStr
'N * ref: String$(
A more detailed example of the Native Code Disassembly facility is given
'N 110059D0 55 push ebp
'N 110059D1 8BEC mov ebp, esp
'N 110059D3 83EC0C sub esp, 0Ch
'N 110059D6 6876120011 push L11001276
'N * ref: __vbaExceptHandler
'N 110059DB 64A100000000 mov eax, dword ptr fs:[L00000000]
'N 110059E1 50 push eax
'N 110059E2 64892500000000 mov dword ptr fs:[L00000000], esp
'N 110059E9 81ECD4000000 sub esp, 0D4h
'N 110059EF 53 push ebx
'N 110059F0 56 push esi
'N 110059F1 57 push edi