Sender:	vheyndri AT rug DOT ac DOT be
Message-Id:	<34796E90.374@rug.ac.be>
Date:	Mon, 24 Nov 1997 13:09:52 +0100
From:	Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version:	1.0
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc:	DJ Delorie <dj AT delorie DOT com>, djgpp-workers AT delorie DOT com
Subject:	Re: djgpp 2.02 alpha 971114
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 971124134245 DOT 23713b-100000 AT is>

Eli Zaretskii wrote:
> 
> On Thu, 20 Nov 1997, DJ Delorie wrote:
> 
> > > I cannot run any programs from the djgpp 2.02 alpha 971114 release
> > > under Loose95; in addition to this, I cannot run any programs built with
> >
> > Check through c1*.c where it sets up the DOS selector.  The code
> > looked suspicious last time I was in there.
> 
> from crt1.c:
> 
>   /* This was -1, but DPMI doesn't guarantee more than */
>   /* 1M + 64K - 16 + 3 */
>   dpmi_set_segment_limit(_dos_ds, 0x101000)
>                                   ^^^^^^^^
> I think the limit needs to be 0x110000.  

I just checked this shortly before I got this mail. 
Let me explain the subtlety of this bug:

The segment size must be 65535 * 16 + 65536. Since this requires 21 bits
the granularity must be 4K, and therefore the segment size must be
0x110000, at least. The segment limit is one less!
Every sane DPMI implementor (like Charles S.) rounds every address which
cannot be represented in 20 bits up to the next page boundary, hence no
problems on plain DOS (even though the limit was not right). Every
insane implementor (like MS's) refuses addresses with the 12 LSBits not
all set and leaves the limit field at its default setting (which is 0).

> Vik, does that help?  

Yes, it does (limit = 0x10 * 0x10000 + 0x10000 - 1)
Writing the limit this way avoids making mistakes, BTW, IMHO

> If so,
> the problem should only show on systems which use HMA.

No true like I explained above.

DJ, do you make the mod. to crt1.c?

-- 
 \ Vik /-_-_-_-_-_-_/   
  \___/ Heyndrickx /          
   \ /-_-_-_-_-_-_/

- Raw text -