From 7f971a0d1cd1dd19a34c2a955cd21607f99e0101 Mon Sep 17 00:00:00 2001 From: nmlgc Date: Fri, 20 Sep 2019 19:53:52 +0200 Subject: [PATCH] [Research] Find out why we can't decompile TH05's hud_bar_put() Part of P0033, funded by zorg. --- Research/Borland C++ decompilation.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 Research/Borland C++ decompilation.md diff --git a/Research/Borland C++ decompilation.md b/Research/Borland C++ decompilation.md new file mode 100644 index 00000000..a35fbf0a --- /dev/null +++ b/Research/Borland C++ decompilation.md @@ -0,0 +1,17 @@ +## Limits of decompilability + +### `MOV BX, SP`-style functions, no stack frame + +These almost certainly weren't compiled from C. By disabling stack frames +using `#pragma option -k-`, it *might* be possible to still get the exact same +code out of Turbo C++ – even though it will most certainly look horrible, and +barely more readable than assembly (or even less so), with tons of inline ASM +and register pseudovariables. However, it's futile to even try if the function +contains one of the following: + +* A reference to the `DI` register. In that case, Turbo C++ always inserts a + `PUSH DI` at the beginning (before the `MOV BX, SP`), and a `POP DI` before + returning. + + **Certainty:** Confirmed through reverse-engineering `TCC.EXE`, no way + around it.