Decompilation unk files generation

docs/jp-remorse-hidden-debugger-investigation.md

@@ -0,0 +1,118 @@
+# Japanese No Remorse Hidden Debugger Investigation
+
+## Scope
+
+This note records a first debugger-focused pass on the Win32 Japanese build `/ja/CRUSADER.EXE`, following the stronger No Regret result.
+
+Question for this pass:
+
+- did the JP build keep the old hidden usecode debugger itself,
+- or did it only keep the broader cheat/debug framework (`-laurie`, `JASSICA16`, immortality, `-debug`, `-u`, and related launch/key features)?
+
+## Short Answer
+
+Current best read: the JP Win32 build clearly preserves broad executable cheat/debug machinery, but this pass did **not** recover evidence that the classic hidden usecode debugger UI/event subsystem survived in recognizable form.
+
+The strongest current reason is simple and specific: the live JP image does not contain the classic debugger-only English UI string bundle seen in the DOS-side hidden debugger, while the same live byte-search method **does** recover known surviving JP cheat/debug strings such as `JASSICA16`, `Immortality enabled.`, and `Cheats are now active.`
+
+That makes the current comparison result asymmetrical:
+
+- `REGRET.EXE` still shows the hidden debugger subsystem and a recovered write-side bootstrap
+- JP `/ja/CRUSADER.EXE` still shows broad cheat/debug support, but not the classic hidden debugger signature set from this first pass
+
+## Verified Findings From This Pass
+
+### 1. The byte-search method is valid on the live JP target
+
+Live `search_bytes` against the active JP program recovered known strings that earlier JP notes already proved were real.
+
+Positive-control hits from this pass:
+
+- `JASSICA16` -> hit at `0047b1cc`
+- `Immortality enabled.` -> hit at `004192b6`
+- `Cheats are now active.` -> hit at `004192cb`
+
+This matters because it rules out the simplest failure mode. The JP image is searchable with the current tool flow, and ordinary internal English cheat/debug strings are still present as raw bytes.
+
+### 2. The classic hidden-debugger string bundle does not appear in the JP image
+
+Live `search_bytes` against the active JP program returned **no hits** for the following classic hidden-debugger UI strings:
+
+- `Goto Line`
+- `Watch what?`
+- `Inspect what?`
+- `Global name`
+- `Search for`
+- `FILE NOT FOUND`
+- `Unable to open this file`
+- `Nothing to find`
+- `Not found`
+- `Done`
+
+This is the main result of the pass.
+
+Those strings are not generic cheat/debug text. They are the most characteristic UI vocabulary of the hidden usecode debugger's file-open, goto-line, watch, inspect, global-edit, and search flows.
+
+### 3. That absence is stronger than a simple localization explanation
+
+The JP build still retains multiple English internal cheat/debug strings, including the positive-control strings above. That means the absence of the debugger-only English UI bundle is not well explained by a blanket `everything was translated or removed from string form` theory.
+
+The current safest read is therefore not merely `the strings were probably renamed`; it is:
+
+> if the classic hidden usecode debugger survived in JP, it did not survive with the usual recognizable English UI string bundle that identifies the DOS-side debugger in Remorse and Regret.
+
+### 4. This pass does not overturn the earlier JP cheat/debug findings
+
+Nothing in this pass weakens the earlier JP Win32 cheat/debug note.
+
+Those earlier closures still stand:
+
+- `-laurie` still survives
+- `JASSICA16` still survives
+- the option-key cheat handler still contains the immortality path
+- `-debug` still survives
+- `-u` still survives as a usecode startup override
+
+What changed here is narrower: the first debugger-specific comparison did **not** find a recognizable hidden usecode-debugger UI signature in the JP build.
+
+## Current Interpretation
+
+The current best cross-build ladder is now:
+
+1. retail No Remorse still has the hidden debugger pieces but currently lacks a recovered writer/bootstrap for the debugger-state global
+2. No Regret still has the hidden debugger pieces **and** a recovered write-side bootstrap at `1398:0000`
+3. JP Win32 No Remorse still has broad cheat/debug machinery, but this first debugger-focused pass did not recover the classic hidden usecode-debugger signature bundle
+
+That means JP is not currently the build that reduces the retail unlock problem.
+
+Right now, No Regret is still the strongest sibling build for explaining what retail No Remorse seems to be missing.
+
+## Practical Consequence
+
+For the minimum-modification retail debugger-entry problem, the highest-value comparison is now still:
+
+- retail No Remorse versus No Regret bootstrap/state-hook paths,
+
+not:
+
+- retail No Remorse versus JP generic cheat/debug preservation.
+
+JP remains useful as evidence that the Windows port retained cheat/debug behavior broadly, but it does not currently provide the same debugger-bootstrap leverage that No Regret does.
+
+## Remaining Uncertainty
+
+This pass is still a first cut, not an absolute negative proof.
+
+The following possibilities remain open:
+
+1. the JP build could retain some debugger-related logic with different text or no user-facing text
+2. the JP port could have retained a lower-level break/inspection helper without the original DOS debugger UI
+3. a deeper JP function-side scan around the Win32 usecode runtime could still recover a non-string-anchored debugger path
+
+But none of those are currently evidenced by this pass.
+
+## Recommended Next Step
+
+Treat No Regret as the primary sibling-build anchor for the hidden-debugger unlock problem.
+
+If more time goes into JP, the next pass should be a deeper function-side scan around the Win32 usecode runtime and any debug-only message/menu handlers, not another broad string search.