Optimization and acceleration of the decompiler, as well as many improvements for .NET in VB Decompiler 11.9
New version of VB Decompiler has a number of fundamental changes and improvements. Also all founded bugs has been fixed.
New algorithm for working with external objects
Each time the decompiler encounters code calling methods from external objects (ActiveX OCX and DLL files), a series of actions are performed. First, this object is searched in the built-in database of the decompiler. This greatly speeds up the analysis, and also makes it possible to decompile the code even if the called external objects are not registered in the system, and moreover, if their files do not exist at all. This works for standard and commonly used popular libraries.
If the called object is unknown to the decompiler, the algorithm for parsing the GUID of the called ActiveX, as well as the identifier of the interface and class inside this COM OLE container, is launched. The algorithm is quite complex, because Visual Basic supports many ways to make these calls. This includes both early binding and late binding, referencing a previously created OLE object instance by interface ID, referencing using both the library GUID and interface ID, and so on. Especially a lot of such calls in Native Code. This includes calling object methods after API __vbaNew and calling after __vbaObjSet and __vbaObjSetAddref and 22 functions from the __vbaLateXX/__vbaVarLateXX series. All this is already supported by VB Decompiler. But there is one caveat. If the object is not known to the decompiler, then the parser of the external DLL/OCX library is launched. First, lookup its file by GUID, and then parse its TypeLib tables.
Previously, the decompiler did a rather superficial analysis of TypeLib. And sometimes the generated function prototypes might not have return values (although they were present). Also, the return type was not always specified. In the case of basic types, this was not critical (Visual Basic generally loves Variant types). But when the returned type is an instance of another class or interface, the code was decompiled incorrectly, because the decompiler did not know that the parameter returned by the external method should be considered as a class, and not a string or numeric variable.
New version of the VB Decompiler has a completely rewritten parsing engine of the TypeLib's information from external libraries. Now prototypes always contain the type of the return value, if it is a class or an interface.
New algorithm for parsing If ... Else ... End If
Any function is always based on conditions and comparisons. VB Decompiler has a fairly advanced algorithm for analyzing conditional jumps, else branches, Select Case, etc. All of this blocks of code are correctly recognized. But in a number of non-standard cases, the decompiler could experience difficulties in the analysis. In particular, if one of the comparison parameters was already the result of another variable comparison. Or when one of the comparison parameters is the result of the function with the assignment of the result of its work to a variable. As well as comparing the class pointer with zero, while the pointer has already been decompiled and its prototype is substituted. In these cases, not entirely clear code with intermediate assignments could be issued. Now such moments are analyzed at the stage of parsing the elements of comparison and provide a fine compatibility.
Improved parsing of prototypes in virtual method tables
Each form, UserControl or class has a virtual public method table (VTable). Often it contains not only names, but also function prototypes with parameter names. Unfortunately, in some cases, parameter lengths were recognized incorrectly and the decompiler did not parse some of the function argument names. Due to the complete non-documentation of the internal structures of Visual Basic, it was not possible to find a solution immediately, but only after analyzing dozens of examples where complex data types were used in function parameters. Now the decompiler supports the decoding of prototypes more comprehensively.
Merging the decompiled code with the disassembled one and jumping to the desired line
VB Decompiler has a very useful function of combining decompiled code with the machine code for deeper analysis. In the decompiled code, just right-click, select "Copy to disassembler" and all the decompiled code will be merged with the disassembled one. This is very useful to understand where this or that comparison came from or where the variable came from. But there is one but. After the merging, the cursor was set to the beginning of the code and it was necessary to search again for the line to be analyzed. If there is a lot of code, it created a lot of inconvenience. Now, before clicking the right button, it is enough to place the cursor on the address of the line (loc_XX) at the left of the code, and after the merging, the transition to the same line will be made.
Experimental support for Windows XP
Back when VB Decompiler was developed on Visual Basic 6.0, it supported all versions of Windows since Windows 95. Even now, customers can download the old 8.4 version, which will work on Windows 95 as well (including disassembly of .NET assemblies without the presence of . NET Framework in the system) and on Windows 11. Unfortunately, the high compatibility of VB6 does not allow you to use the new features of operating systems, and the language itself is very outdated. Ten years ago VB Decompiler was rewritten into another language. Gradually, compatibility with old and unsupported operating systems began to disappear in favor of adding new features. Realizing that some customers still use virtual machines on Windows XP for code analysis, work was done to adapt the decompiler to run under XP. Unfortunately, there is no way to guarantee 100% operation of all functionality, but the product can now be installed and used under Windows XP.
Many other improvements
It is difficult to tell in one article the entire amount of work done in the new version. Each new release is a sea of changes. Some more obvious, some less. But all of them do not just add the external shine, but actually improve the quality of decompilation and make the code clearer and more understandable. The new version adds support for emulation of a number of assembler commands that were not previously supported. Emulation of some already supported commands has been improved. Algorithms for parsing calls to internal classes have been changed, which added the ability to also display calls to public variables specified in the virtual table of class methods. Added support for basic methods when manually calling classes (such as AddRef, Release, PropertyBag, and so on). Also fixed a bug that hides a form or class in the object tree if it was followed by an empty module. Improved Select Case analyzer. And many, many more.
As always, with each new version, VB Decompiler gets significantly better. Improved code quality. New features are being added. I am also grateful to all our users for using the product. It is thanks to you that it continues its active development for 17 years already!
September 3, 2022
(C) Sergey Chubchenko, VB Decompiler's main developer