Sorry for the delay with the release of this version of our decompiler! But we are absolutely sure that the improvements are worth it! Everybody knows that sometimes it is pretty difficult to find a piece of code that handles a click on a form button, a form loading event, or some other UI event. The major problem is not that you need to find the piece of code, but that you have to scroll through the entire function tree of the form. It's no big deal if your project is small and the form has a dozen of event handlers. But in a large project, where each form may have hundreds of event handlers, it may be pretty annoying.
We've known about this problem for quite a long time, and we've been working hard to fix it. And finally, in the new version of our decompiler, we did it! Now you only need to open the visual view of any form, click any control, and double-click the "_Event" field in the object's properties list. If you do that, a context menu will open, with the entire list of handled events of the selected control. Select an event, and you will instantly switch to the handler code. Simple and easy!
There are other changes in the new version of our Visual Basic decompiler, too.
We have significantly redesigned the internal architecture of our decompiler. Thanks to the further refactoring and redesigning of many functions, now the decompiler can analyze files much faster. In some cases, file analysis can go five times faster! You can easily notice the speed-up effect when analyzing a project with many modules, each of which contains hundreds of functions.
When analyzing a program to be decompiled, our decompiler searches for external ActiveX components used by the program and parses their TypeLib data to compile the lists of addresses and functions provided by the component. It is necessary for the decompilation of calls of functions or properties from external ActiveX components. Alas, due to the peculiarity of the COM/OLE technology, oftentimes the path to the file can only be found by analyzing the entries in the system registry. Starting with this version, VB Decompiler can do a deeper analysis of the registry entries. In some cases, this approach allows you to decompile previously unsupported components.
Our users have been asking us for a long time to add support for displaying HEX codes for p-code on the disassembler tab. The only thing that made adding that feature very difficult was the depth of optimization of the resulting code. After decompilation, one decompiled line sometimes replaced a couple of dozens of p-code lines. And in this case, the amount of binary data displayed would be just too much. So we made a trade-off. Now you can view binary HEX codes in the disassembler window...
... and if you need to view decompiled code, just select "Copy to disassembler" in the context menu of the Decompiler tab, and view everything at once on the disassembler tab!
Finally, as always, we also improved the quality of decompilation of p-code, native code, and .NET assemblies. We improved operations with the ESP register in the emulator. We fixed some bugs related to support for a number of functions in the p-code decompiler. We fixed this bug: User defined types (UDTs) were erroneously identified as variables. We fixed some bugs related to parsing tables and local variables in .NET assemblies. As you can see, that's a lot of changes! Hopefully, you will appreciate the work that we have done.
If you have an active subscription for updates, you can download the new version of VB Decompiler via the customer's panel for free. If you have just learned about VB Decompiler or have not updated it for a long time, we'll be happy to see you among our customers!
(C) Sergey Chubchenko, VB Decompiler's main developer