Some general questions, interesting points in this project
xcom169 opened this issue · comments
Hello!
From the generated x86/arm/llasm assembler code it's relatively easy to get back the original C/C++ code ?
From the generated x86/arm/llasm assembler how do you know which parts you should replace with some new code ?
The original DOS exes were 16bits? It's not a problem to convert them to 32 bit executables?
Can you also correct programming bugs in the generated x86/arm/llasm assembler or everything is the same as it was the original game ?
From the generated x86/arm/llasm assembler code it's relatively easy to get back the original C/C++ code ?
It's not easy at all. Otherwise I wouldn't generate assembler code, but C code. Also, not everything was originally C/C++ code - some parts were hand-written assembler code,.
From the generated x86/arm/llasm assembler how do you know which parts you should replace with some new code ?
Generally you don't. I replace parts which are difficult/impossible to recompile or to make things easier - everything just to make it work.
For example, I replace the original C library, because it contains a lot of hand written assembly, which is difficult to recompile and also because things like file access is much easier to do in higher level than emulating DOS interrupts.
I replace sound/music library because it's much easier to get sound/music working than emulating low level hardware.
Things like self-modifying code or jumping to the middle of an instruction are impossible to recompile, so they need to be replaced.
The original DOS exes were 16bits? It's not a problem to convert them to 32 bit executables?
No, the original executables were 32-bit. My approach only works with 32-bit executables.
Can you also correct programming bugs in the generated x86/arm/llasm assembler or everything is the same as it was the original game ?
I do correct some programming bugs, mostly null pointer dereferences - those work in DOS but crash the game in Windows/Linux.