nx_pe_writer.nx

nx_pe_writer.nx -- substrate-emitted Windows PE32+ bytes. Arc Step 1 of the nxc2 Windows PE backend. Per cardinal 2026-05-21 ("always do the bits up harder investment"): substrate produces a valid, runnable Windows PE32+ executable from NishiLang source + the substrate's existing byte-writing primitives + sys_openat to flush to disk. No assembler, no linker, no MinGW, no MSVC, no third-party PE writer. What this Step 1 ships: - nx_pe_emit_exit42(buf): writes the bytes of a complete PE32+ executable that calls kernel32!ExitProcess(42) and returns to the Windows loader cleanly - Bytes are byte-for-byte deterministic for this minimal case; subsequent steps generalize (variable .text, multiple imports, real codegen integration with nxc2 x86_64 backend) - sys_openat + sys_write flush bytes to a Windows-visible path (/mnt/c/...) so PowerShell / cmd can execute it What this Step 1 does NOT ship (queued for next steps): Step 2: generalize -- accept (code_bytes, code_len, imports[]) and lay out sections dynamically; supports any kernel32 function the substrate wants to call Step 3: integrate with nxc2 x86_64 backend so a NishiLang program compiles to PE directly (--target pe32plus); emits MS x64 calling convention instead of SysV Step 4: substrate-side .obj+.lib equivalents (still no MS toolchain) Step 5: retire WSL2/qemu/binutils from the Win-native build path Why a minimal PE matters as foundation: - Validates byte layout against the real Windows loader - Establishes import-table mechanics (Import Descriptor + INT + IAT + IMAGE_IMPORT_BY_NAME + dll-name string) - Lets the substrate's HAL gain a Windows shim that calls kernel32 functions (the future NX_HAL_SHIM_WINDOWS sealed-enum option finally has an implementation path) - Proves the substrate doesn't need MinGW/MSVC to produce Windows-native binaries PE32+ layout for this minimal case (file size = 0x600 = 1536 bytes):