Date: Wed, 10 Sep 1997 09:16:22 +1100
From: Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz>
Subject: Re: fread slowstart
In-reply-to: <Pine.SUN.3.91.970909164758.7594C-100000@is>
To: djgpp-workers AT delorie DOT com
Message-id: <199709092121.JAA13127@teleng1.tait.co.nz gatekeeper.tait.co.nz>
Organization: Tait Electronics Limited
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <341541B4 DOT 2462 AT bo DOT dada DOT it>
Comments: Authenticated sender is <billc AT blackmagic DOT tait DOT co DOT nz>
Precedence: bulk

On  9 Sep 97 at 16:58, Eli Zaretskii wrote:

> 
> On Tue, 9 Sep 1997, Diego Zuccato wrote:
> 
> > Well, couldn't we have a 'locked' memory out the first MB and use it for
> > all DJGPP programs that need a lot of arguments ?
> 
> 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.  So
> you have no means of passing the address of the block where long
> command line is stored to the child program.  Conventional memory
> addresses are always global, so passing the seg:off address of a
> conventional memory block works in both DPMI 0.9 and 1.0. 

DMPI 1.0 has shared memory. It shouldn't be that difficult to detect 
1.0 and do the appropriate thing.  It also shouldn't cause too much 
bloat.

> 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 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 would have to agree with this, I think. I can't think off hand what 
sort of programs would have this problem, but I can imagine the 
possible situations.
Bill
--
Leave others their otherness.