NE (16-bit Windows) executables through the Ghidra lane: I have a working fork prototype. Would you want it?

[CassieFox23]

TL;DR: Today REA refuses 16-bit Windows (NE) programs, and the docs say that is on purpose. In my fork I made a small change that opens them through Ghidra, and it worked on one sample. I will not open a PR unless you want one, and a no is a fine answer.

Why I am asking

A user on REA's Discord wanted to look at a DOS-era program in NE format, the 16-bit Windows kind. REA turned it away. I filed the confusing error text as #1979, which is closed. The docs in docs/ghidra-dos.md say "NE, LE, and LX declarations are explicitly unsupported", so I made no PR.

Today versus the prototype

The sample is binw/wzoom.exe from Open Watcom v2 (Sybase Open Watcom Public License 1.0), a Windows 3.x program.

Check	REA main today	My fork branch
open_binary on wzoom.exe	Refused, target_unavailable	Opens, format ne
Functions over MCP	None	217, the same as Ghidra headless
Decompiler	None	Real C, with calls like CREATEWINDOW
read_bytes at the first function	None	Matches the file at offset 578
LE and LX files	Refused	Still refused, same message
DOS MZ control (dosserv.exe)	Opens as dos-mz	Unchanged, still dos-mz

What it would cost you

The change adds a new ne value to several public format lists, including the tool output schemas. That is why I am asking first. NE addresses also differ from DOS. They read as selector then offset. So 1000:007c shows as 0x1000007c.

Not run

• Only one Windows NE sample. No OS/2 NE and no NE DLL.
• The LE and LX test files were synthetic, so the refusal was tested but Ghidra on a real LE or LX was not.
• Linux only.
• The branch is not rebased on today's main.

The question

Would you take this as a PR? Would you want it shaped differently? Or would you rather leave NE refused? Any answer is fine with me, and I am happy to drop it.

Design and files changed

The branch is feat/ne-ghidra-lane in my fork. It holds two commits on base 83a4445 (#2034): 39c0a1a70 for code and tests (19 files) and 3155636e2 for docs (1 file). The branch is local only and not pushed.

How it works:

• NE becomes its own format, ne, with x86 architecture. Admission needs the full 64-byte NE header. A new parseNeRecord in src/domain/binaryTarget.ts does this. LE and LX still return unsupported <sig> executable in MZ image.
• The file reader in BinaryTargetResolver.ts reads 64 bytes at the NE header. So headers beyond the 4096-byte probe work. LE and LX are refused there too.
• Ghidra's launcher gets an ne option. It passes -loader NeLoader -processor "x86:LE:16:Protected Mode" -cspec default. It refuses NE together with PSP, MIPS soft-float, DOS, raw-binary or a language override.
• The analysis profile commits that loader and language. REA_GHIDRA_LANGUAGE_ID is rejected for NE. None of the DOS keys apply.
• The Ghidra client pins the language and compiler in its handshake. It adds two limitation lines. One says the selectors come from Ghidra's loader. The other says the load-image check that DOS MZ gets is not done for NE.
• Hopper declines NE and points to Ghidra.
• Docs: docs/ghidra-dos.md has a new "NE executables" section.

Files that gained the new ne value:

• File src/domain/binaryTargetTypes.ts
• File src/domain/evidence.ts
• File src/domain/analysisSnapshot.ts
• File src/domain/artifactGraph.ts, in the target-format list only
• File src/contracts/toolOutputSchemaPrimitives.ts
• Two unions inside the resolver, in BinaryTargetResolver.ts

Tests added or changed:

• File src/domain/dosMz.test.ts
• File tests/boundary/filesystem/targetDiagnostics.test.ts
• File tests/boundary/filesystem/binaryTarget.test.ts
• File tests/boundary/providers/ghidra/ghidraLauncher.test.ts
• File src/ghidra/GhidraProvider.behavior.test.ts
• File src/hopper/HopperProvider.test.ts
• File tests/boundary/providers/hopper/hopperAnalysisProfile.test.ts

Left alone on purpose:

• The load-image check files, GhidraLoadImageAttest.ts and GhidraLoadImageValues.ts. NE falls through to the existing unsupported result.
• The native load image file, nativeLoadImage.ts.
• The Java bridge, ReaGhidraBridge.java.
• The artifact inventory, which still says unknown for NE.
• The Go lane file, GoPeImage.ts, which still refuses NE.
• The real-Ghidra DOS script, verify-real-ghidra-dos.mjs.

Calls and replies, trimmed

Over MCP stdio with REA_ANALYSIS_PROVIDER=ghidra, on the branch:

Call	Reply
open_binary	ok in 42 ms: {"format":"ne","kind":"executable","architecture":"x86"}
list_procedures	303 rows. 217 are local: 131 real functions and 86 thunks that jump to imports. 86 are external Win16 imports, like USER::MESSAGEBOX.
list_segments	16 blocks, such as Code1 at 0x10000000 to 0x10004ff2
procedure_pseudo_code on FUN_1000_007c	Real C with CREATEWINDOW(...), SHOWWINDOW and UPDATEWINDOW calls
read_bytes at 0x10000000, 16 bytes	5589e553515283ec1ac746e00000c746, the same 16 bytes I read from the file at offset 578
address_to_file_offset at 0x10000000	578 (0x242)
inspect_native_load_image	unsupported, with measured mappings. This is the intended result.

The 217 local rows match the 217 functions that Ghidra headless found. Headless gave 217 with the forced NeLoader and with its own natural pick.

Two selectors appear among the local functions. The selector 0x1000 holds 131 functions. The selector 0x1078 holds the 86 thunks.

Refusals and the control:

• Synthetic LE file: unsupported LE executable in MZ image, category: unsupported_target, constraint: file_format_rejected.
• Synthetic LX file: unsupported LX executable in MZ image.
• DOS control dosserv.exe: still dos-mz, 94 procedures, as on main.

Here is the refusal on main for the same file. I checked it on 2026-10-11, at main sha 1449e8e (#1910).

{"error":{"code":"target_unavailable","category":"unavailable","message":"Cannot open artifact: unsupported NE executable in MZ image. Check that the path exists, is readable, and points to a supported file.","retryable":false}}

Checks with exit codes

Node 24.18.0, on the branch:

Step	Exit	Result
npm run typecheck	0	Also 0 after the commits
npm run build	0
npm run check:fast	0	The first try exited 1, because my new test made a describe block longer than oxlint's 150-line limit. I split it.
npm run test:fast	0	393 files, 5,080 passed, 3 skipped
npm run test:boundary	1	3,854 passed, 77 skipped, 2 failed
the 2 failing files, on clean base 83a4445 (#2034)	1	Both fail there too: 2 failed, 9 passed

The 2 failures are in files my diff does not touch. Both files sit under tests/boundary.

• The cliOptionAliases.test.ts file fails. Two options of trace-web-module-imports have no description. They are --import-map-path and --import-map-base-url.
• The referenceSourceReader.test.ts file expected ignored and then kept. It got the other order. This may be directory listing order, but I did not verify that.

The exit code of npm ci was not captured. The build ran fine afterwards.

Ghidra headless on the same file exited 0. It printed "Using Loader: New Executable (NE)" and language x86:LE:16:Protected Mode:default. It found 217 functions and 7,458 instructions.

Test setup

• Box: Nobara 44 (Fedora 44 base), Linux 7.2.9
• CPU: AMD Ryzen 9 5900X
• RAM: 32 GB
• Node: 24.18.0
• Head: 3155636e2. Base: 83a4445 (test(sourcemap): consolidate source map regressions #2034).
• Other: Ghidra 12.1.4 (Apache-2.0), JDK 21

🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊