Crusader_Decomp/docs/jp-remorse-windows9x-investigation.md

Japanese No Remorse Windows 9x Investigation

Question

Investigate the claim that the Japanese build of Crusader: No Remorse supports Windows 9x and can run natively on Windows 95 instead of requiring a DOS boot path.

Active Ghidra target for this note: /ja/CRUSADER.EXE.

Verdict

Current static-analysis verdict: strongly supports the claim.

The loaded Japanese executable is not just a DOS executable with a small helper around it. It is a native flat Win32 image with Windows API startup, Windows registry configuration, DirectDraw/DirectSound initialization, and one explicit Win9x-aware compatibility branch.

What is proven from static analysis:

• the Japanese binary is a PE-style Win32 program loaded at 00400000, with sections such as BEGTEXT, DGROUP, .idata, .reloc, and .rsrc
• it creates a real top-level Windows game window and runs through Win32 startup code
• it initializes DirectDraw and DirectSound directly
• it reads and writes settings in the Windows registry
• it contains Japanese/Win9x-facing support clues, including IME handling and a GetVersion-based compatibility branch

What is not proven by this pass:

• an actual runtime launch on real Windows 95 hardware or emulation
• whether extra runtime prerequisites such as the expected DirectX version are always present on a bare Windows 95 install
• whether every shipped JP build variant behaves the same way

So the safest wording is:

The claim that the Japanese release has a native Windows 9x execution path is strongly supported by the code. The stricter claim that it will always run on a stock Windows 95 machine without additional runtime requirements is not fully closed by static analysis alone.

Main Evidence

1. The loaded JP executable is a Win32 image, not the old DOS/NE game binary

Ghidra reports the active program as /ja/CRUSADER.EXE with entry at 004729e0.

Relevant image layout recovered from Ghidra:

• Headers: 00400000 - 004003ff
• BEGTEXT: 00401000 - 0047afff
• DGROUP: 0047b000 - 00481bff
• .bss: 00482000 - 00495fff
• .idata: 00496000 - 00496dff
• .reloc: 00497000 - 0049e3ff
• .rsrc: 0049f000 - 004a03ff

That is a normal PE/Win32 layout, not the segmented NE or DOS-extender layout used by the original DOS executable.

2. The import table is decisively Windows-native

Recovered imports include all the major Windows subsystems expected of a native Win9x game executable:

• process and OS: GetVersion, CreateThread, ExitProcess, TlsAlloc, VirtualAlloc, GetCommandLineA, GetModuleHandleA, GetModuleFileNameA
• window/UI: CreateWindowExA, RegisterClassA, DefWindowProcA, DispatchMessageA, PeekMessageA, ShowWindow, RegisterWindowMessageA, MessageBoxA
• graphics: DirectDrawCreate, CreateBitmap, CreateCompatibleDC, CreatePalette, TextOutA
• audio/timing/input: DirectSoundCreate, DirectSoundEnumerateA/W, timeGetTime, joyGetDevCapsA, joyGetPosEx
• configuration/storage: RegCreateKeyExA, RegOpenKeyExA, RegQueryValueExA, RegSetValueExA, CreateFileA, ReadFile, WriteFile
• Japanese text/input support: IsDBCSLeadByte, GetCPInfo, WINNLSEnableIME

This is not a DOS launcher plus one or two helper calls. It is a full Windows application stack.

3. The main window path is explicit and native

00445f40 is now named win32_create_main_window.

Key behavior recovered from decompilation:

• registers a window class with RegisterClassA
• creates a fullscreen popup window with CreateWindowExA
• uses the title string "Crusader: No Remorse"
• calls ShowWindow(..., 10)
• calls WINNLSEnableIME(0,0) immediately after successful creation
• registers "MSWHEEL_ROLLMSG"

This is direct evidence of a native Windows UI path. The IME call is especially relevant in a Japanese build because it shows the executable is consciously managing Windows-side JP text/input behavior.

4. DirectDraw and DirectSound are initialized directly by the game

004459b0 is now named video_init_directdraw_and_directsound.

Recovered behavior:

• calls DirectDrawCreate()
• sets cooperative level and display mode on the DirectDraw object
• creates the palette and primary surface
• calls DirectSoundCreate()
• hides the cursor with ShowCursor(0)

This is a classic Windows 9x era DirectX setup path. It strongly supports the idea that this build was intended to run as a native Windows game executable.

5. Registry-backed configuration is built in

String at 0047b178:

• Software\Electronic Arts\Crusader: No Remorse\J1.21

004138e8 is now named config_load_registry_and_cfg.

Recovered behavior:

• reads installpath, cdpath, and flicpath from HKEY_LOCAL_MACHINE
• reads user preferences such as video, subtitles, limitblasts, animation, frameskip, musicvolume, soundvolume, and mousespeed from HKEY_CURRENT_USER
• falls back to parsing crusader.cfg

00413760 is now named config_write_registry_string and writes string values back into the same registry branch.

This is strong evidence of a normal Windows-installed configuration model rather than a DOS-only setup flow.

6. There is a real Win9x-specific compatibility branch

00472c41 is now named win32_runtime_capture_process_context.

Recovered behavior:

• captures environment strings
• captures module filename and command line
• calls GetVersion()
• stores split version fields into globals at 0x47c09f, 0x47c0a0, and 0x47c0a1

The more important follow-up is 00476616, now named win32_tls_alloc_with_win9x_guard.

Recovered behavior:

• calls TlsAlloc()
• checks the saved GetVersion() word
• if the version word has the high 0x8000 bit set, it retries while the TLS slot is less than 3

That is not generic Windows code. It is exactly the kind of branch you expect when a program needs to behave differently on the Win9x line, where GetVersion() reports the platform using the high bit and some low TLS slots are treated specially.

This is the strongest single code-level clue that the executable was designed with Win9x behavior in mind, not just NT-family Windows.

Secondary Evidence

Japanese-specific Windows integration

The import set and main-window path together show several JP-specific Windows integration points:

• WINNLSEnableIME
• IsDBCSLeadByte
• GetCPInfo

That does not by itself prove Windows 95 compatibility, but it does reinforce that this is a localized Windows build, not a DOS build being loosely wrapped.

WinMM and joystick APIs

The import table also includes:

• joyGetDevCapsA
• joyGetPosEx
• timeGetTime

These are ordinary Windows multimedia/input APIs and fit the same native-executable picture.

Interpretation

The claim can be split into two parts.

Part A: "The Japanese version supports Windows 9x"

This is strongly supported.

The binary:

• is a Win32 image
• uses Win32 startup and window management
• uses DirectX-era Windows multimedia APIs
• uses Windows registry storage
• has a GetVersion branch that specifically distinguishes Win9x-style version reporting

Part B: "It can run on Windows 95 natively without switching to DOS first"

This is also strongly supported, but with one caveat.

The executable is clearly built to run as a native Windows application, and the version/TLS branch is the best evidence that Win9x behavior was considered explicitly. The remaining uncertainty is practical, not architectural: an actual Windows 95 runtime may still need the expected DirectX/runtime environment installed.

So the architectural answer is yes; the deployment answer is very likely yes, but not fully closed until runtime-tested on a Win95 environment.

Ghidra Changes Made During This Pass

Renamed and commented in the active /ja/CRUSADER.EXE database:

• 00472c41 -> win32_runtime_capture_process_context
• 00476616 -> win32_tls_alloc_with_win9x_guard
• 00445f40 -> win32_create_main_window
• 004459b0 -> video_init_directdraw_and_directsound
• 004138e8 -> config_load_registry_and_cfg
• 00413760 -> config_write_registry_string

Each of those now has a decompiler comment explaining why it matters to the Win9x/native-Windows investigation.

Remaining Follow-Up

1. Run the JP executable under an actual Windows 95 target or a faithful Win95 VM to confirm runtime behavior.
2. Identify the expected DirectX version from installer files or runtime error strings.
3. Trace the message pump and main game loop entry after window creation for a fuller WinMain reconstruction.
4. Locate the import thunks or callsites for GetCPInfo and IsDBCSLeadByte to document the JP text path more precisely.
5. Check whether the JP installer writes the same J1.21 registry branch or whether the executable can self-heal missing keys.
6. Compare the JP Windows binary against the English DOS binary to isolate which subsystems were ported versus shared.