四套加载器

四种可执行格式各自有一套加载路径。它们是独立实现的——PE 的节区与重定位和 ELF 的段完全不是一回事，硬套一个抽象只会更糟。

格式	实现	定位与边界
ELF64 Linux	elf_loader.rs 7.0 K	第一公民，走得最远。45 个系统调用臂原生执行、零垫片；小体积静态样例直接原地运行。
PE32+ Windows	pe_loader.rs 17.4 K	体量最大的一个，因为 Windows 需要一张 97 条的 SHIM_TABLE 加导入表处理。已知缺口：LoadLibraryA 返回假句柄、无真实动态 CRT。
Mach-O darwin	macho_loader.rs 4.2 K	最薄的一层：8 个 BSD syscall 加 mach-trap 垫片。样本只有 2 个——这一面是验证性的，不是主力。
FUJR .run	fujr.rs 11.8 K	不是 CPU 的执行格式，是本项目自己的容器：MAGIC + MANIFEST + EMBED + DATA（≤8 资源）+ FNV 校验。.shell 走 EMBED 首行 shebang。

一个反复出现的取舍

四种格式有一个共同的诱惑：为它们做一个统一的“可执行文件”抽象。项目没有这么做，理由和语言那一节是同一条——把不同的事实强行合并，换来的是一个谁都不像的中间层，以及一堆“这个字段对 PE 没意义”的特例。

容器格式的细节： FUJR 的字段布局见 FUJR 容器；这张地图（.run）与进程隔离（fujo-sandbox）的关系见架构 · 进程与隔离。