These has been some recent misinformation floating around in various forums about ixemul.library and its capabilities. ixemul.library does have a working vfork(), and assisted fork().

1. Generally vfork() should be directly usable in situations where fork() + exec*() is used. In this case vfork() can used instead. Any potential exit() calls in the child code path should be replaced with _exit().

2. Replacing fork() is doable, but might require significant work. First, the application and all its dependencies should be built with -mresident32 flag. The application must manually duplicate the context at the time of the fork() call by doing the following:

A. perform first part of the fork by calling ix_vfork(). A new child is spawned and the parent's execution is paused. pid == 0 indicates child codepath, the parent will get returned the pid of the child.

B. In child: Duplicate static data segment and initialize the child memory allocator and other internal structures: ix_vfork_setup_child();

C. In child: copy the parent's state to the child. Generally this requires use of static variables to relay values over to the child. Any malloc() memory and local variables and structures that are used by the child must be cloned before the parent is let to continue. This always requires manual work to construct the necessary code to perform the state cloning, as each use of fork() is unique in regards of what state is present and how the child will be using it after the call.

D. In child: Indicate that parent can continue with ix_vfork_resume();

At this stage both parent and child are executing the same code segment, concurrently. Both have their own copies of static variables and can use them freely.

If everything is done correctly this works fine. It is successfully used by for example the ixemul shell (pdksh).

[ Edited by Piru 03.02.2026 - 23:38 ]

Btw

How Unix-compatible is signal-stuff in ixemul? AROS uses this to have Exec on top of Unix. Tasks are switched by poking sigcontext in Unix signal handler. Disable()/Enable() is blocking/unblocking Unix signals. Timers/VBlank is with SIGALRM.

Theoretically you could use similiar method to spawn one (or more) nested MorphOS (sand)boxes from MorphOS itself == MorphOS hosted on MorphOS. To run certain stuff in them. Possibly mem protected. Possibly in memory not reachable by normal MorphOS programs (> 2GB). Possibly on another core (if you add support to MorphOS itself to allow very "simple" tasks to run on another core = not doing things which are usually done in AOS and AOS apps that are not multi-core-compatible) ~ something like in powerpc.library era)).

MOS hosted on MOS would run as "simple" task (because of using ixemul.library). Stuff interacting with "host MOS" would maybe run in helper tasks. Like gfx driver. Or file/io for emulated file handler.

"simple": more or less only shuffling memory around and not using much else from host MOS beside msg functions and ixemul stuff required to hack "Exec on top of Unix" together.

Of course you could do this also without ixemul. But in Unix, signal-handler-context-poking is more or less some publicly documented feature, while directly doing such things in Exec requires poking private Task structs where context is store and theoretically since this is private the struct or place may even change without notice.

@Georg

Ixemul signal implementation is fairly complete. It's not fully POSIX though as real-time signals are missing.

As a side note: Older ixemul was stuck on some partial implementation of early 1990s POSIX. Many functions were outright missing. I've spent considerable effort to modernize ixemul, bringing it in sync with latest POSIX versions in many regards. The work isn't completed though, and there are some gaps still I'd like to bridge.

However, we won't be implementing exec on top of ixemul. If we would need to do something like that, we'd just add the necessary things in the core components as required rather than mess about with ixemul.

Ixemul has a clear function: To provide easy way to port GNU and OSS tooling. This way we can for example enable easy porting of modern components for the SDK (including git, perl, python etc). Ixemul of course doesn't not prevent porting the components to libnix as well, and in fact many components live as both ixemul and libnix ports. However, keeping clear separation between ixemul and libnix has proven a wise decision as this allows us to update SDK even though some update would cause complications on the libnix side. Trying to port every OSS component to libnix would be an insane task, and we very much prefer focus on other, more important tasks.

@Piru
Thank you very much for explanation.