eli5 what is the difference between a decompilation and a disassembly when it comes to viseo games?
In: 1
Programming languages have different “levels”.
At the very bottom is machine code, literally the 0s and 1s the hardware actually runs on.
Just above machine code, we have assembly languages. It’s basically just the same as machine code, with a “prettier” layer on top that can use words and letters. For example, the instruction that tells the CPU to add two numbers is a specific string of 0s and 1s in machine code. But in assembly, it can literally just be “ADD”.
Much higher up, we have languages that are closer to human language. In assembly, we may be able to say “ADD”, but we still have to tell it the addresses of where the numbers are in RAM. In higher level languages, we can just write “1 + 1”.
Ultimately, the hardware only understands machine code. So assembly code has to be “assembled” into machine code, while higher languages have to be “compiled” into machine code.
So disassembly takes the machine code, and brings it up a notch to an assembly language. Decompilation takes machine code and brings it up many notches to a high level language.
A computer game is a computer program. Computer programs are sets of instructions that hardware chips will execute. Those kinds of instructions are stored in the form of “assembly code”, a language that is closely related to the architecture and language of the machine code itself (what actually interacts with the chips). Assembly code is very difficult to make much sense of even in small chunks, and trying to write or understand a monolithic application program in assembly is an exercise in futility.
Instead programs are usually written in higher level programming languages where logical operations are abstracted in such a way that a human can somewhat easily understand what is being done. The programs composed in those languages need to be converted through a process called “compiling” into machine code/assembly which can be performed by the chips themselves.
Now to your question, disassembly is converting the machine code into a human-readable assembly code. This is at best one level of abstraction up from the machine or microcode. Decompilation on the other hand is converting the byte code back into the original programming language. This will be much more abstract and often far easier to understand.
Computers speak in 1’s and 0’s. If you want to tell it to do something, you have to speak its language. It’s *possible* to speak its language directly, but you’d be very hard-pressed to find a human that can do it well.
To make it easier for us stupid humans, we don’t write programs in the computer’s language. Instead, it can be written in a sort of simplified language. One that, if you feed it into a special program, can be translated into something the computer can understand. That program is called an assembler, and the coding language you feed it is called assembly.
Each programmable computer chip speaks its own special dialect of assembly. So if you write assembly code for one kind of computer, it might not work on another, as the other computer can’t understand the dialect. If you had to write a program that needed to work on many different kinds of computers, you’d have to tailor-make a unique copy for every dialect you want to support. That can get quite difficult to keep up with. It would be really nice if we could instead write one master program that works for all of them, and create a set of translators that can take the master program and translate it into all of those dialects for you. Each one of those translators is called a compiler.
At this level of abstraction away from actual machine language, you don’t really end up with any particular programming language. You can kind of make it whatever you want. So a lot of people have. C and C++ are two examples of programming languages that are on this level of the chart. They are both (by some definition of the word) easy for humans to read, that can be converted into something the computer to read via a compiler and assembler.
So, as you can probably guess, a *disassembly* is the result of doing the reverse of what an assembler does, and a *decompilation* is the result of doing the reverse of what a compiler does. Disassemblies tend to be more straightforward, as pure machine code and assembly language for a specific computer tend to map 1-to-1, but as far as being able to read and understand what the code actually *does* can be quite difficult. A decompilation is when someone takes this one step further, and tries to reconstruct the more human-readable code that something was originally created from. Decompilations are a lot trickier, as the process of mangling human-readable C or C++ or whatever language code into assembly for a specific computer is a lossy process, as the compiler often makes a lot of unintuitive optimizations to make the program run faster.
A computer game is a computer program. Computer programs are sets of instructions that hardware chips will execute. Those kinds of instructions are stored in the form of “assembly code”, a language that is closely related to the architecture and language of the machine code itself (what actually interacts with the chips). Assembly code is very difficult to make much sense of even in small chunks, and trying to write or understand a monolithic application program in assembly is an exercise in futility.
Instead programs are usually written in higher level programming languages where logical operations are abstracted in such a way that a human can somewhat easily understand what is being done. The programs composed in those languages need to be converted through a process called “compiling” into machine code/assembly which can be performed by the chips themselves.
Now to your question, disassembly is converting the machine code into a human-readable assembly code. This is at best one level of abstraction up from the machine or microcode. Decompilation on the other hand is converting the byte code back into the original programming language. This will be much more abstract and often far easier to understand.
Computers speak in 1’s and 0’s. If you want to tell it to do something, you have to speak its language. It’s *possible* to speak its language directly, but you’d be very hard-pressed to find a human that can do it well.
To make it easier for us stupid humans, we don’t write programs in the computer’s language. Instead, it can be written in a sort of simplified language. One that, if you feed it into a special program, can be translated into something the computer can understand. That program is called an assembler, and the coding language you feed it is called assembly.
Each programmable computer chip speaks its own special dialect of assembly. So if you write assembly code for one kind of computer, it might not work on another, as the other computer can’t understand the dialect. If you had to write a program that needed to work on many different kinds of computers, you’d have to tailor-make a unique copy for every dialect you want to support. That can get quite difficult to keep up with. It would be really nice if we could instead write one master program that works for all of them, and create a set of translators that can take the master program and translate it into all of those dialects for you. Each one of those translators is called a compiler.
At this level of abstraction away from actual machine language, you don’t really end up with any particular programming language. You can kind of make it whatever you want. So a lot of people have. C and C++ are two examples of programming languages that are on this level of the chart. They are both (by some definition of the word) easy for humans to read, that can be converted into something the computer to read via a compiler and assembler.
So, as you can probably guess, a *disassembly* is the result of doing the reverse of what an assembler does, and a *decompilation* is the result of doing the reverse of what a compiler does. Disassemblies tend to be more straightforward, as pure machine code and assembly language for a specific computer tend to map 1-to-1, but as far as being able to read and understand what the code actually *does* can be quite difficult. A decompilation is when someone takes this one step further, and tries to reconstruct the more human-readable code that something was originally created from. Decompilations are a lot trickier, as the process of mangling human-readable C or C++ or whatever language code into assembly for a specific computer is a lossy process, as the compiler often makes a lot of unintuitive optimizations to make the program run faster.
Programming languages have different “levels”.
At the very bottom is machine code, literally the 0s and 1s the hardware actually runs on.
Just above machine code, we have assembly languages. It’s basically just the same as machine code, with a “prettier” layer on top that can use words and letters. For example, the instruction that tells the CPU to add two numbers is a specific string of 0s and 1s in machine code. But in assembly, it can literally just be “ADD”.
Much higher up, we have languages that are closer to human language. In assembly, we may be able to say “ADD”, but we still have to tell it the addresses of where the numbers are in RAM. In higher level languages, we can just write “1 + 1”.
Ultimately, the hardware only understands machine code. So assembly code has to be “assembled” into machine code, while higher languages have to be “compiled” into machine code.
So disassembly takes the machine code, and brings it up a notch to an assembly language. Decompilation takes machine code and brings it up many notches to a high level language.
Imagine you were told to take apart a Lego castle. There’s two ways to do it. You can separate the pieces into smaller, more understandable parts: the gate, the walls, the towers, etc. It’s not too complicated to rebuild the castle and understand why each part is designed that way. This is decompiling code. It’s more human-focused and understandable.
The other way of taking the castle apart is to separate every single Lego, so all you have are the bricks. It’s a lot harder to put back together because you don’t know exactly which tiles are which or how they fit together. But everything is there, so if you put in enough time and effort, you could theoretically understand it. This is disassembling the code, turning it back into (almost) the simplest pieces available. It might not be helpful for the vast majority of people – but you have way more control over what you can build.
Imagine you were told to take apart a Lego castle. There’s two ways to do it. You can separate the pieces into smaller, more understandable parts: the gate, the walls, the towers, etc. It’s not too complicated to rebuild the castle and understand why each part is designed that way. This is decompiling code. It’s more human-focused and understandable.
The other way of taking the castle apart is to separate every single Lego, so all you have are the bricks. It’s a lot harder to put back together because you don’t know exactly which tiles are which or how they fit together. But everything is there, so if you put in enough time and effort, you could theoretically understand it. This is disassembling the code, turning it back into (almost) the simplest pieces available. It might not be helpful for the vast majority of people – but you have way more control over what you can build.
Latest Answers