nx_pe_job_limit_test.nx

nx_pe_job_limit_test.nx -- W2b: sovereign Windows Job Object ENFORCEMENT, native, no HCS. Docker-replacement ladder rung W2b. Proves the Job Object does not just EXIST (W2a) but ENFORCES a resource limit -- the cgroups analog, native NT, kernel32-only, no VM/HCS. Mechanism: ActiveProcessLimit via SetInformationJobObject(JobObjectBasicLimitInformation). One emit fn parameterized by the limit value. main() emits TWO PEs differing ONLY in the ActiveProcessLimit immediate: nx_pe_job_limit_deny.exe (limit=1): self is the 1 allowed proc; spawning a child is DENIED -> exit 42 nx_pe_job_limit_allow.exe (limit=2): room for the child; spawn SUCCEEDS -> exit 50 Each PE: 1. CreateJobObjectW(NULL,NULL) -> hJob 2. SetInformationJobObject(hJob, 2, &basic, 0x40) LimitFlags=JOB_OBJECT_LIMIT_ACTIVE_PROCESS(0x8), ActiveProcessLimit=N 3. AssignProcessToJobObject(hJob, (HANDLE)-1) self joins the job (counts as 1) 4. CreateProcessW(NULL,"cmd.exe /c exit 0",...,CREATE_NO_WINDOW,...,&si,&pi) -> rax (BOOL) 5. ExitProcess( rax==0 ? 42 : 50 ) child auto-joins the job; denied if over limit NO-FALSE-GREEN: the gate requires deny->42 AND allow->50. The two binaries are byte-identical except the ActiveProcessLimit immediate, so a CreateProcessW arg bug would fail BOTH (deny AND allow -> 42) and a non-enforcing limit would pass BOTH (deny AND allow -> 50). Only a genuinely ENFORCED limit produces 42-then-50. (positive control = allow; negative control = deny.) HONEST SCOPE: proves ActiveProcessLimit ENFORCEMENT. Memory.max/CPU-rate caps + child-spawn-into-job supervision = later rungs. Founded on nx_pe_writer.nx (hand byte-layout, tutor-scaffold). genealogy_id: win32_job_objects_2000 + lmctfy_2013 + runc_cgroups_2016 lineage_id: substrate_pe_joblimit_v1