Date: Sun, 10 Dec 2000 08:34:17 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: cat AT animal DOT u-net DOT com
cc: djgpp AT delorie DOT com
Subject: Re: function fork()
In-Reply-To: <3a2fe050$1@news.gemsoft.net>
Message-ID: <Pine.SUN.3.91.1001210081950.700D-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On 7 Dec 2000 cat AT animal DOT u-net DOT com wrote:

>     In the case of a program p2fork for example it might be possible
> to save the state of the running version of the program to a data file
> and then replicate the program with a line such as
> 
>     system("start /b p2fork --restart=data");

Note that restarting a program from a disk file is not an easy task.  You 
cannot let start.exe (which is a stock Windows program) do that, because 
it doesn't understand the structure of the file to which you write the 
memory image of the running program.  If you want p2fork itself do that, 
it needs to include code that can read a file into memory, set up an 
execution environment expected by DJGPP programs (segment registers, 
memory arena--stack and heap--, exception handlers, etc.), then release 
its own memory and other resources, and jump into the code it read from 
disk.

In other words, you need to write a custom stub loader which can load a 
program from a memory image, similar to what DJGPP's stub.asm and 
v2loadimage function do, but quite different from them.  This can be
done, but is far from easy.

And if you want every DJGPP program have that capability, you need that 
special loader be linked into all of them.

In addition, running a program via start.exe has a problem that 
inheriting file handles is tricky if not impossible.  Inherited file 
handles are generated by a dup() system call, so they all share the same 
entry in the system file tables, and thus share the same file pointer 
position and other attributes.  I don't think you can do that from 
another VM, and that might break some code which uses fork(), because it 
assumes file inheritance works.

> It may be necessary to modify the .pif for
> p2fork after it has been invoked to make it keep using CPU time when
> running in background mode.

I think this isn't required.  It suffices to change the properties of the 
DOS box to not suspend in background.  The DOS box properties are used by 
default for each DOS program that doesn't have a PIF file of its own.