Mail Archives: djgpp/1997/04/15/04:57:09
Eli Zaretskii wrote:
> This problem is only relevant to a program that forks itself. Most
> programs call `execXX' right after forking, which is functionally the
> same as `spawnXX'.
A lot do, certainly (I've normally used popen for that on Unix), it
happens that most of the programs I've written which use fork explicitly
(mostly network) don't do exec. As they say, Your Mileage May Vary...
> I think the approach that you had in mind (to change the DJGPP startup
> code) is too complex.
Very probably. I usually go for the most complex way first <g>...
> I can think about two other possibly simpler
> ways of making this happen.
>
> 1) Look how this is done in the DJGPP port of Bash. I don't
> know the answer, and therefore cannot tell how well it suits you, but
> it *does* work.
I have the sources, but I haven't found where it does it yet. I'll
carry on looking.
> 2) Create an image of the program with all the variables
> frozen at their values, then invoke that program.
Now that's one I rejected as being too complex <g>. But it does come
the closest to what fork really does, and if you think it's feasible
I'll investigate it.
> That is how the
> Emacs executable is created when you build Emacs, so you can look at
> the Emacs sources (filename unexec.c) to see how this works. In
> Emacs, the image is actually written to a disk file, but going from
> there to a memory move followed by passing the control to that image
> shouldn't be very hard.
I don't even object too much to a disk file image - if it's on ramdisk
then it will be plenty fast enough for me (that's what 4DOS does, for
instance, under DesqView).
> The `v2loadimage' function (see djlsr201.zip,
> file src/debug/common/v2load.c), used by all DJGPP debuggers, is a
> working example of how an image is loaded and control passed to it.
Thanks. I'll have a look at those...
Chris
- Raw text -