Date: Sun, 31 Aug 1997 19:13:40 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
cc: djgpp workers <djgpp-workers AT delorie DOT com>
Subject: Re: _dos_ds segment limit
In-Reply-To: <3406ADF3.63CE@rug.ac.be>
Message-ID: <Pine.SUN.3.91.970831191315.17131C-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Fri, 29 Aug 1997, Vik Heyndrickx wrote:

> 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

Does a program that calls `stat', or `fstat', or `getmntent'
considered ``normal''?  If so, they all access internal DOS data
structures which are outside the above-mentioned areas.  They could be
also either below or above the 640K mark, depending on how did the
host machine load DOS.

> 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.

No matter how many safe functions would you ad to the library, people
will always want The Fastest Way Ever.  I don't see anything wrong in
using farptr functions for accessing any address in the first MB.

> Those video access
> routines are useful because on some systems 32-bit r/w does not work
> properly, remember?

What happened to the video RAM access speed survey you were
conducting, btw?  I don't think I saw the results.  Did I miss
something?