delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1997/09/09/13:41:44

Message-ID: <34158A0F.1C24@bo.dada.it>
Date: Tue, 09 Sep 1997 19:40:31 +0200
From: Diego Zuccato <dz AT bo DOT dada DOT it>
Organization: CyberSpace Software Labs BBS
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: djgpp-workers AT delorie DOT com
Subject: Re: fread slowstart
References: <Pine DOT SUN DOT 3 DOT 91 DOT 970909164758 DOT 7594C-100000 AT is>

Eli Zaretskii wrote:

[locked memory]
> AFAIK, no, you can't, because this will break with DPMI 1.0 servers
> (currently, there is only 386Max that supports 1.0).  In DPMI 1.0, the
> descriptors aren't global, they are local to the process.
Can't you set a descriptor in the global area ?
But, hey ! when spawning (if no multitasking is supported) we are always
the SAME process, for the DPMI server, so they should be valid in the
child too.

> A single tb is not good enough, even if there's no multitasking, because
> the child program would overwrite the contents of the buffer, and when
Uh, I thought a tb is something temporary. It's used just to pass data
to/from dos, but data isn't stored there for a 'long' time (eg 2 calls
to read() ) : it's copied to memory over the first MB. Isn't it ?
> controls gets back to the parent, it will see in the tb something
> different from what it put there before spawning the child.  This might
> lead to very subtle bugs.
I don't think so. Why should it expect that the child doesen't change
the tb?
Spawning the child is just another DOS call, like read() ...

- Raw text -


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