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
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.