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 ]