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

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.