mirror of
https://github.com/HeyPuter/gex.git
synced 2026-11-13 20:12:43 -10:00
velzieandClaude Opus 5.5
414f0fa8cb
A program the page starts (System.run, host.mjs spawnExec) is adopted in a fresh Worker and never goes through execve, so the kernel never chose its memory flavour: a GEX_MEM64 entry stayed in its environment, its image's user.gex.mem64 record and its own headers were not looked at, and it ran in the page's flavour whatever it needed, unless its Wine loader happened to exec itself again (to start the server). The adopted exec of such a program (gex_page_program, set from the child's `page` mark) now runs Kernel::exec_flavour and exec_route as an execve does, and goes on in a Worker of the other flavour (exec_away) when this one's is not the one it needs. test/wine/mem64spawn checks this in the browser: a relocatable program stays on the default flavour; one with no relocations above the lowered memory's code space gets a 64-bit memory, at its base; one the environment asks one for gets it, top down above 4 GiB. Both 64-bit cases also check that gex's own space (2 to 4 GiB) reads as reserved and is out of the available virtual memory. test/wow64/exeplace checks the same placement and accounting on the node page, and natively the available virtual memory being the free space. Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_e0aa53aa95eb4b86910519b4d14812a5