Decompiler

[Hexadecimal Disaster]

I don't think so, Glenn. Maybe that fact fit into the "collateral damage" cathegory.

[wizardlife]

Once you've seen the extreme simplicity of ASM code, it's impossible to even consider what it might have been as a higher level language...

So this JMP... hmm... I wonder, was that an IF? maybe the result of an ELSE? perhaps a CASE statement? maybe a GOTO? GOSUB? SUB or FUNCTION? These registers here... were they separate variables, or are they just operations on one... hmm...

[Agamemnus]

If the decompiler deciphered the output commands and make GOTOs, IFs, variables starting from a and going to z and beyond, and line numbers, then i'd be happy.

I could work with that.

[wizardlife]

If the decompiler deciphered the output commands and make GOTOs, IFs, variables starting from a and going to z and beyond, and line numbers, then i'd be happy.

I could work with that.

Well, that would be the only option... but even then, there's so much ambiguity about what's going on with registers. It's particularly frustrating because a decompiler for QB would have to work _completely_, whereas for C or pascal, any blocks that confuse it can be transferred straight through as an inline ASM block.

[Agamemnus]

So then one will have to make it provably perfect.

[Antoni Gual]

This guy claims his decompiler works:
http://members.aol.com/mspring810/privat....htm#CLAUD
But it does'nt return QBasic source (just a steak?)
Someone willing to pay to test it?

[Antoni Gual]

The most curious thing is this question is asked by whitetiger0990 who has a tag making fun on Babelfish (it could be called a natural language decompiler? )
If a computer can't translate correctly between two (very) high level languages how do you expect it can recover high level source from ASM?

[Agamemnus]

it ought to be able to.

[Hexadecimal Disaster]

Well, Antoni, human language is by far more complex than any programming language, so a decompiler is perfectly realizable. However, wizardlife got a point with his previous post, and if we take into account this little marvel found on the site Antoni posted:

"It is much better to get me to do the decompilation for you because it can be quite difficult to work out the run time parameters and to knock the raw decompilation into shape. Also the current version has bugs. It is hoped to have a version which will overcome many of these problems in late March 2001 (see The Future). However, if you really want a copy of the decompiler now you can obtain it (and a license to use it) for £500 (Pounds Sterling) . (See How To Pay). I recommend that before doing this you send me a few of your EXE files so that I can check that the decompiler works on them."

So basically the decompiler "works" with lots of corrections...

- Branch locations occasionally out by a line.
- For Next loops are not always correctly initialised.
- Occasionally some array elements with constant terms in their index might be regarded as separate arrays.
- Dynamic string variables in subroutines are not always identified as such.
- Problems concerning arrays.
- Problems with dynamic arrays and parameter arrays in subroutines.
- TYPE DEFS . The decompiler doesn't recognise these yet.

In the end, the guy itself is decompiling the "decompilation", hence the £500-£5000 fee. The code examples are really simple, yet the proggie still has some problems. And don't forget that he's working on his decompiler since 1997.

*sigh*

[Glenn]

If it was perfectly realizable, it would have been realized by now. Human language is more complex than computer programming languages? I highly doubt it. Human language is designed for allowing people with an IQ of something > 0 (usually) to communicate with each other. Programming languages are designed to allow humans to communicate with a device with an IQ of 0. *That* makes things *harder*, not easier. Yes, in some sense, that might require that the programming language be simpler. But that "simplicity" is precisely what makes reversing the compiling process a nightmare.