Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <3406ADF3.63CE@rug.ac.be>
Date: Fri, 29 Aug 1997 13:09:39 +0200
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: djgpp workers <djgpp-workers AT delorie DOT com>
Subject: Re: _dos_ds segment limit
References: <Pine DOT SUN DOT 3 DOT 91 DOT 970826190801 DOT 6359B-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Eli Zaretskii wrote:
> 
> On Tue, 26 Aug 1997, Vik Heyndrickx wrote:
> 
> > Wouldn't it be more desirable for debugging purposes to set the segment
> > limit of the _dos_ds segment to the range that can be accessed by a
> > regular DOS program (1M+64K) instead of 4G.
> > And maybe introduce a new selector to access the full flat memory for
> > whoever needs it?
> 
> This has come up before.  The conclusion was that the current setup is
> wrong, because it makes e.g. farptr functions as dangerous as nearptr,
> only slower.  It also doesn't make much sense since many DPMI hosts won't
> let you access memory-mapped devices above the 1MB mark without
> additional DPMI calls.

> As for another selector with 4GB limit: it seems to be unnecessary, since
> people already have nearptrs, and devices mapped to high memory need
> special DPMI calls to map them in anyway.

If I summarize the various needs for accessing the below 1M area from
point of the user program:
- the video memory
That's it. Normal programs don't require anything beyond that. The libc
sources may require also:
- the BIOS data area (yuck)
- the DOS transfer buffer
- the PSP
Means of access: the _far* functions, movedata, _movedata*

If we now limit the access to those different area's by means of
selectors and to the video area (in text mode) by means of a read, a
write and a move functions, it is even possible to give no access at all
to the user to anything but the regular memory space. Those video access
routines are useful because on some systems 32-bit r/w does not work
properly, remember? Those routines could work accordingly. In addition
to this, the same selector can be used for 0xb8000 and 0xb0000.

I've actually already done this, and I would be delighted to share this
with the world, but I also broke some things and I'm working on this
(don't hold your breath).

-- 
+----------------+
| Vik Heyndrickx |
+----------------+