Compiler/Interpeter/Decompiler?

[Figaro]

Warning: Extreme Newbie

I know what a compiler is, and I hope I am not wrong, but the program where you write the code. Is an interpeter the same as a compiler? If a compiler puts it all togethor, than a decompiler must take the source apart, right? And if so, what is the point of decompiling something?

[hypronix]

A compiler translates your code into machine language so it can be used. Your box at home has no clue what printf("Print me!"); does, unless the C compiler translates that stuff into it's language.

The interpreter translates and executes an instruction. It takes stuff in line-by-line.

As for the decompiler, I'm assuming you mean a disassembler [in all honesty, I haven't heard of a decompiler, so if there is such a thing, I so hope somebody will enlighten me as well ]. A disassembler takes the machine code and transforms it back into the most basic of programming languages - ASM [assembly]. It is used in order to understand how a program works, check for flaws [that's how patches to games get released] and stuff. Most software has a legal note that does not allow for "reverse engineering" [disassembling]. Such software should be handled with care and, wherever possible, traded out for some Open Source soft that does the same [but, it comes with all of its source, and it's always nicely written in something less brutal then ASM ]. Cracks to software are also a product of disassemblying.

[Deimos326]

yes as hyperonix has excellently stated, a disassembler is a great but dangerous tool. they are used by game crackers and by companies for updating and fixing their software. however, before you go out disassemblign everything, make sure you know what you are doing. its very easy to rewrite something wrong and mess the whole program up. plus, if its not open source its generally gonna be in assembly, which is not an easy language

[Algaen]

Deimos,
One could disassemble a program and change whatever the heck they want and it won't hurt a thing unless it is reassembled and overwrites the original executable. If you actually take a hex editor and look at the hex representations of the original executable (assuming you can read machine language (uuggghhhh - assembler instruction encoding (I hated that part of assembler class))) and you make changes, then yes you can screw it up good.

hypronix,
I've always thought of a decompiler as a disassembler that will take the assembly instructions and convert them into a higher level language so that you can see you the original code in one possible high level language representation. This is probably not the original code since there are many ways to accomplish the same thing in most languages.

Hopefully I'm not way out in left field here and this makes things clearer.

[rapier57]

BTDT.

In some environments, you can use a disassembler to edit executable code to make changes, introduce patches, or introduce new procedures or functions. Did that in the old days with z-80 assembler, debug and the old WordStar.

You can still accomplish much the same things with debug or its derivatives in a command shell in Windows, the Mac or Linux. The disassembler can be used to troubleshoot and fix an application.

[Sun]

I know what a compiler is, and I hope I am not wrong, but the program where you write the code.

A compiler is not the one where U write the code, but one which translates your source code into object code.

The editor in which you can write code, compile it, run it and debug it is usually called an integrated development environment. (like ide of vb, vc++, turboc etc). But you can write code in an ordinary text editor, save it and pass it onto a compiler as input file (compiler is a pgm which accepts one or more source files written in a pgmming language and produce the corresponding object code as output.)

A compiler compiles the source pgm as a whole, doing some optimisations, while interpreter translates it one line at a time. (so easier to correct errors), but is slow compared to a compiled pgm

[hypronix]

Originally posted here by Algaen
hypronix,
I've always thought of a decompiler as a disassembler that will take the assembly instructions and convert them into a higher level language so that you can see you the original code in one possible high level language representation. This is probably not the original code since there are many ways to accomplish the same thing in most languages.

Hopefully I'm not way out in left field here and this makes things clearer.

I have always thought such a tool needed to exist! But, of course, you're right about the ways in which that can be achieved. As far as I know a disassembler simulates the execution of the program and based on what the proggie does it converts it into ASM. There's not a lot of ways to go wrong because the way ASM is made is so you see every command the registries get.

If you happen to know of any such tools [running under Windows or GNU/Linux] please let me know through a PM [I'm sure others would be interested to know as well, but I'm not sure of AO policies regarding software that _could_ be used illegally]

[frz]

here's my 2 cents.

compiler - a utility that translates a source code into a machine-readable/executable code.
editor - any utility you use to write the source code( e.g, edit.com, notepad.exe, etc...)
decompiler/disassembler - a utility used to generate the source code of an executable program. if you're curious about the source code of a particular program, you use a disassembler (e.g. HIEW, etc...)

[hypronix]

frz, as I'm sure you've read above, there's some degree of difference between disassembler and decompiler. Plus, you don't really see the source code of anything, that's only something you can get from the developer. What you see is an interpretation of what the program does. Just clearing stuff out

[slarty]

A decompiler, actually *attempts* to take the output of a compiler and produce readable (or at least compilable) source code. Because of the nature of compiling, it is quite unusual for it to succeed entirely.

However some languages don't compile "all the way" to machine code - notable examples are Java, .NET (C# and VB.Net etc) and some versions of VB (Not .NET)

These "bytecode" compiled languages are generally much easier to decompile, and produce much more legible results than stuff made in C and compiled to machine code.

However, that still doesn't necessarily mean the output of a decompiler is very legible, even if it's correct. You normally lose the names of local variables, and all the comments, so it can get quite confusing.

Additionally, "obfuscators" are available (for C# and Java anyway) which will rename variables and methods to make them shorter, remove debugging information (line numbers), and generally make life harder for the decompiler to do its work and a human to read the output. They're fairly effective.

Slarty