Hex-Rays v1.7 vs. v1.6 Decompiler Comparison Page
Below you will find side-by-side comparisons of v1.6 and v1.7 decompilations. Please maximize the window too see both columns simultaneously.
The following examples are displayed on this page:
- Print else-if on the same line
- In conditions, prefer !strcmp(x, y)
- More ternary operators
- Better handling of negative indexes
- No messy code for byte accesses anymore
- More patterns for arithmetic operations
- More LIST_ENTRY related macros
- More "interlocked" intrinsics
- Better comparisions of symbolic constants
- Better support for CONTAINING_RECORD
- We continue to work on 64-bit arithmetics
- Support for more compiler helpers
- Concise representation for calculating booleans
- Data objects are printed in the output
NOTE: these are just some selected examples that can be illustrated as a side-by-side difference. Hex-Rays Decompiler v1.7 includes are many other improvements and new features that are not mentioned on this page - simply because there was nothing to compare them with. Also, some improvements have already been illustrated in the previous comparisons. Please refer to the news page for more details.
Print else-if on the same line
A sequence of else-if's was getting indented to the right, but now the decompiler shows them nicely, aligned one below the other. A simple improvement, yet makes the output more readable.
In conditions, prefer !strcmp(x, y)
After a string comparison we usually are interested in the case when the strings are equal. The listing on the right is more readable because the actions for each keyword immediately follow comparisions. However, the old listing (on the left) was too long that the actions just did not fit this web page.
By default the decompiler applies this logic to strcmp, memcmp, and similar functions, but the list of functions is configurable.
More ternary operators
The ternary operator is easier to read, isn't it?
Better handling of negative indexes
Both v4 and v5 point to the same structure type. However, references made by v4 were not represented nicely because of a negative index. Now the decompiler can handle that nicely.
No messy code for byte accesses anymore
On ARM, when the compiler cannot prove that a pointer is properly aligned, it resorts to copying the data byte by byte. The decompiler could not represent it nicely because it lacked special logic to handle that. Now we do it.
More patterns for arithmetic operations
Adding a new pattern to recognize a code sequence always helps to reduce the output. Above is a nice example of that. Both code snippets do the same, it is only a matter of representation.
More LIST_ENTRY related macros
We added more LIST_ENTRY related macros but there is still many remaining... This one uses the new "fastfail" macro from Win8.
More "interlocked" intrinsics
We added support for more intrinsic functions, especially the ones used by Visual Studio. There are too many of them to be listed here.
Better comparisions of symbolic constants
Here, the Result variable is HRESULT. Instead of logically negating it, it is better to compare against ERROR_SUCCESS, so the meaning of the code is clearer.
Better support for CONTAINING_RECORD
It seems that CONTAINING_RECORD will be our method of representing structure pointers with a delta. When we have a pointer that points not to the beginning of a structure object but somewhere in the middle (this occurs much more frequently that you might think!), we need to represent it nicely. The CONTAING_RECORD macro suits this need quite well.
In the new version we improved support for it very much, now it can handle virtually all cases. Above, v2 points to the middle of a structure type "a", to the field named "key".
We continue to work on 64-bit arithmetics
It is a never ending story but we do not give up. More 64-bit patterns - better output.
Support for more compiler helpers
Yet one more example of improved output.
Concise representation for calculating booleans
While some readers prefer the code of the left because it is more verbose, our preference is clearly on the right.
Data objects are printed in the output
Previous versions of the decompiler were not displaying data objects in the output listing at all. Now we print them in the output file. This makes the output more complete - less work if you want to recompile it.