Summary
Real AmigaDOS RunCommand(seglist, stacksize, argptr, argsize) (per the AmigaDOS Manual/RKRM) does not create a new process or address space -- it overlays the calling process: runs the seglist's code as part of the same process, with its own stack (swapped in, restored on return) and its own arguments (passed in A0/D0, and also temporarily installed into pr_Arguments and a buffer for the pr_CIS input handle so GetArgStr()/ReadArgs() see them). All of this reverts when the called command returns.
volamos's current RunCommand (crates/volamos-core/src/dosseg.rs's run_command_handler/resolve_and_run_command) instead routes through the exact same system_runner callback System()/Execute() use (crates/volamos/src/main.rs's run_nested_program), which builds a brand-new FlatMemory + Runtime and runs it to completion independently -- architecturally identical to spawning a new process, not overlaying the caller's own.
As of the fix in 92c09b2, RunCommand's A0/D0 argument passing is now byte-accurate (verbatim argptr/argsize, no reformatting) -- but the process-overlay semantics themselves are still an approximation.
Why this hasn't been done yet
Researched during the #7 investigation: implementing true overlay semantics needs Runtime::run's main dispatch loop to support reentrantly invoking guest code and getting a return value back -- something it can't do today. Runtime::run is built to run exactly one program from its entry point to a single top-level exit, not to be called into recursively from inside a library-call handler while already running. Building this would need either a nested run-like loop invoked from inside run_command_handler (tricky: HandlerContext already mutably borrows ctx.cpu/ctx.mem/ctx.heap/ctx.dos, so recursively re-entering Runtime::run from inside a handler needs restructuring), or a new internal "run until this task's exit trap, then return" primitive.
What's reusable already: crates/volamos-core/src/exectask.rs's stack_swap_handler (exec.library StackSwap, LVO -732) already implements exactly the save/restore-a-stack-region technique this would need. crates/volamos-core/src/dosseg.rs's build_seglist already loads code into the same address space (unlike run_nested_program's fresh FlatMemory). pr_Arguments/pr_CIS aren't modeled at all today (crates/volamos-core/src/exectask.rs only references their offsets in size-calculation comments, never reads/writes them) -- would need real offset constants and read/write support. GetArgStr() also isn't implemented at all yet (exists only as an LVO table entry).
Scope
Deliberately deferred rather than attempted alongside #7's fix -- this is a real architectural extension (reentrant guest-code invocation), not a quick change, and nothing in the current corpus depends on the deeper fidelity yet (shared globals/file-handle identity across a RunCommand overlay, ReadArgs() seeing RunCommand-supplied args specifically). Worth its own dedicated design pass when a real corpus binary actually needs it.
Summary
Real AmigaDOS
RunCommand(seglist, stacksize, argptr, argsize)(per the AmigaDOS Manual/RKRM) does not create a new process or address space -- it overlays the calling process: runs the seglist's code as part of the same process, with its own stack (swapped in, restored on return) and its own arguments (passed inA0/D0, and also temporarily installed intopr_Argumentsand a buffer for thepr_CISinput handle soGetArgStr()/ReadArgs()see them). All of this reverts when the called command returns.volamos's current
RunCommand(crates/volamos-core/src/dosseg.rs'srun_command_handler/resolve_and_run_command) instead routes through the exact samesystem_runnercallbackSystem()/Execute()use (crates/volamos/src/main.rs'srun_nested_program), which builds a brand-newFlatMemory+Runtimeand runs it to completion independently -- architecturally identical to spawning a new process, not overlaying the caller's own.As of the fix in 92c09b2,
RunCommand'sA0/D0argument passing is now byte-accurate (verbatimargptr/argsize, no reformatting) -- but the process-overlay semantics themselves are still an approximation.Why this hasn't been done yet
Researched during the #7 investigation: implementing true overlay semantics needs
Runtime::run's main dispatch loop to support reentrantly invoking guest code and getting a return value back -- something it can't do today.Runtime::runis built to run exactly one program from its entry point to a single top-level exit, not to be called into recursively from inside a library-call handler while already running. Building this would need either a nestedrun-like loop invoked from insiderun_command_handler(tricky:HandlerContextalready mutably borrowsctx.cpu/ctx.mem/ctx.heap/ctx.dos, so recursively re-enteringRuntime::runfrom inside a handler needs restructuring), or a new internal "run until this task's exit trap, then return" primitive.What's reusable already:
crates/volamos-core/src/exectask.rs'sstack_swap_handler(exec.libraryStackSwap, LVO -732) already implements exactly the save/restore-a-stack-region technique this would need.crates/volamos-core/src/dosseg.rs'sbuild_seglistalready loads code into the same address space (unlikerun_nested_program's freshFlatMemory).pr_Arguments/pr_CISaren't modeled at all today (crates/volamos-core/src/exectask.rsonly references their offsets in size-calculation comments, never reads/writes them) -- would need real offset constants and read/write support.GetArgStr()also isn't implemented at all yet (exists only as an LVO table entry).Scope
Deliberately deferred rather than attempted alongside #7's fix -- this is a real architectural extension (reentrant guest-code invocation), not a quick change, and nothing in the current corpus depends on the deeper fidelity yet (shared globals/file-handle identity across a
RunCommandoverlay,ReadArgs()seeingRunCommand-supplied args specifically). Worth its own dedicated design pass when a real corpus binary actually needs it.