www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1995/12/15/11:27:18

Date: Fri, 15 Dec 1995 08:29:44 -0500
From: dj AT delorie DOT com (DJ Delorie)
To: A DOT APPLEYARD AT fs2 DOT mt DOT umist DOT ac DOT uk
Cc: DJGPP AT sun DOT soe DOT clarkson DOT edu
Subject: Re: The generation gap?

>   (0) If a djgpp program calls a djgpp child process, will it always happen
> successfully? What will happen if the parent is an old-style djgpp program and
> the other is a V2 djgpp program? Or vice versa?
>   (1) Of the various sorts and modes that programs djgpp and otherwise can be,
> what pairs of parent mode and child mode are incompatible?

V1 programs can't call V2 programs.  Any other combination works.

>   (2) While the child is running, how much of the parent is in RAM rather than
> swopped out onto disk?

All of it, but it's all in extended memory anyway.

>   (3) I read that (except via files) a parent can only talk to a child via its
> call parameters, and the child to the parent by the return value. Is there any
> way that the parent can pass to the child a RAM address as a hex number, and
> the child can thus poke and peek its parent's contents? Will it work if the
> address thus passed across is the address of some conventional memory that the
> parent had grabbed before by _go32_dpmi_allocate_dos_memory(&x)?

This will work for dos memory.  This may work for extended memory if
the DPMI server keeps the parent's selectors valid while the child is
running.  However, the parent can't do anything with the data until
the child returns.

>   (4) How much time overhead does calling a child, and returning from the
> child back to the parent, use up?

I don't know, but with uclock() you should be able to time it.  Why
not run some benchmarks and report back to us?

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019