Date:	Thu, 24 Jun 1999 11:57:05 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Erik Berglund <erik2 DOT berglund AT telia DOT com>
cc:	pavenis AT lanet DOT lv, Charles Sandmann <sandmann AT clio DOT rice DOT edu>,
	djgpp-workers AT delorie DOT com
Subject:	Re: Re: gcc-crash - and a possible solution
In-Reply-To:	<MAPI.Id.0016.00333138303633303030303930303039@MAPI.to.RFC822>
Message-ID:	<Pine.SUN.3.91.990624115518.25071D-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

Erik, please add djgpp-workers AT delorie DOT com and sandmann AT clio DOT rice DOT edu
to your messages in this thread.  This is a complex problem and I would
like others to have opportunity to see your data and to offer ideas.

On Wed, 23 Jun 1999, Erik Berglund wrote:

> > I don't think this is wrong.  Assuming the DS limit is 0xfffeffff,
> > 0xfffeffff - 0xfff7ffd0 = 458799 (decimal), which is quite a lot.  So
> > why do you think this offset is wrong?
> 
> I only thought that CC1.EXE should use the same value always,
> namely 0x0015a630, as I get when everything goes well.

No, this is not necessary.  The DPMI server can return memory blocks
in any order, and the library is supposed to deal with this correctly.

> Also, to me it seems like the stack pointer has a negative value,

It's not negative, the linear address space is unsigned.

> I was wondering if CC1.EXE thereby overwrites parts
> of Windows, maybe the DPMI server.

This cannot happen, because Windows lives in another virtual machine.
That is, Windows and the DOS box have different sets of page tables,
so there's no way a DOS program can write into the Windows address
space, at least not by dereferencing a pointer.

- Raw text -