maddo/Crusader_Decomp
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Furthened decomp work

Browse source
This commit is contained in:
Marco 2026-04-10 18:14:55 +02:00
commit 28cbbe3470
519 changed files with 1498 additions and 43421 deletions
Download patch file Download diff file Expand all files Collapse all files

2
crusader_decompilation_notes.md
View file

@ -40,7 +40,7 @@ Latest broad-sweep UI follow-up: the same UI-heavy lane is now tighter in three
Recent retail debugger-entry follow-up: [docs/retail-debugger-entry-options.md](docs/retail-debugger-entry-options.md) now consolidates the hidden-debugger entry question with the newer live Ghidra evidence instead of leaving it split across the older `-debug` and patch-attempt notes. Current best read is now tighter in three ways: first, fresh data-use recovery still finds reads but no writer for the debugger-state global at `1478:659c/659e`; second, fresh decompiles of `usecode_debugger_open_for_current_unit`, `usecode_debugger_open_modal`, `usecode_debugger_gump_create`, and `usecode_debugger_handle_event` confirm that the debugger UI and event bundle are real but only meaningful after a valid break-state object/gump already exists; and third, the retail `-u` override remains the lowest-risk non-EXE experiment surface but still does not currently show a script-visible way to construct the seg1408 break-state object or write the required global pointer. The resulting priority order is now explicit: prefer a focused No Regret / JP No Remorse bootstrap comparison first, keep `-u` plus a replacement `EUSECODE.FLX` as the least invasive indirect experiment surface second, and treat the current interpreter-callsite-retarget patch family as the smallest structurally defensible retail EXE path only if cross-build comparison fails to reveal a smaller missing bootstrap.
Recent No Regret debugger follow-up: [docs/regret-hidden-debugger-investigation.md](docs/regret-hidden-debugger-investigation.md) now also records the first forcing-options pass instead of stopping at structural recovery. Current best read is that Regret is now the first build where a practical forced debugger bring-up looks realistically hackable without rebuilding the subsystem: executable patching is the strongest route because Regret already has the bootstrap, the live vtable override, and the interpreter-side auto-open path; live memory forcing is plausible if the debugger object already exists; and usecode remains useful only as a hybrid context-generator after code or memory has already armed the debugger, not yet as a pure launcher.
Recent No Regret debugger follow-up: [docs/regret-hidden-debugger-investigation.md](docs/regret-hidden-debugger-investigation.md) now also records the debugger-side cleanup pass after the first source-loader/runtime split, the final deep caller-recovery closure in the upstream Regret VM lane, and the first practical seeding model. The live `REGRET.EXE` database now has names and comments not just for the breakpoint/current-entry helpers, but also for the source-pane constructor/pointer/draw/viewport methods, the full source-buffer create/load/split/destroy chain, the interpreter saved-farptr helpers at `13f0:0000/003c`, the interpreter-context create/init pair at `13f0:00e8/0244`, and the shared slot-chunk accessor at `13f8:1d72`. The practical model is tighter in four ways: first, the broader `usecode_debugger_handle_event` map now shows explicit line-search, goto-line, and breakpoint-clear interactions over that loaded source buffer; second, the compiled-usecode question is no longer ambiguous, because retail Remorse already carries parsed `LINE_NUMBER` ops while Regret currently does not; third, the remaining debugger-seeding uncertainty is now narrowly bounded inside the already-identified interpreter dispatcher path rather than in some still-unmapped Regret-side subsystem; fourth, the seeding record itself now reads as a serialization of existing live interpreter pointers, which means a future bring-up can probably reuse in-process VM state with a small patch instead of depending on any hypothetical external preprocessor. It would improve source correlation, but even a future Regret-focused line-number injector would still not replace the missing interpreter-seeded current-entry stack needed for stable `RUN` / step behavior.
Recent JP hidden-debugger follow-up: [docs/jp-remorse-hidden-debugger-investigation.md](docs/jp-remorse-hidden-debugger-investigation.md) now records the first debugger-focused comparison pass on `/ja/CRUSADER.EXE`. Current best read is narrower than the No Regret result but still useful: the JP Win32 build clearly retains broad executable cheat/debug features, but this pass did not recover the classic hidden usecode-debugger UI signature bundle. Live byte searches on the active JP image found known positive-control strings like `JASSICA16`, `Immortality enabled.`, and `Cheats are now active.`, but returned no hits for the debugger-only strings `Goto Line`, `Watch what?`, `Inspect what?`, `Global name`, `Search for`, `FILE NOT FOUND`, `Unable to open this file`, `Nothing to find`, `Not found`, and `Done`. The practical outcome is that JP currently strengthens the `broad cheat/debug support survived in Win32` story, but not the `JP preserved the missing retail debugger bootstrap` theory; No Regret remains the stronger sibling-build anchor for the hidden-debugger unlock problem.