Date:	Tue, 29 Feb 2000 11:01:45 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Nate Eldredge <neldredge AT hmc DOT edu>
cc:	djgpp AT delorie DOT com
Subject:	Re: Fastest bitblt?
In-Reply-To:	<83g0ud56n9.fsf@mercury.st.hmc.edu>
Message-ID:	<Pine.SUN.3.91.1000229110126.22619E-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	dj-admin AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On 28 Feb 2000, Nate Eldredge wrote:

> > Not true.  Memory protection is built into protected mode, at least to 
> > some degree.  Access rights checking and segment-level protection are 
> > always active, as they are inherent to PM.  Page-level protection is 
> > optional.
> 
> True.  But actually having protection requires also that something set
> what is to be protected.  I.e. you can set the segment limit to
> 0xffffffff.  Limit checking is still active, but I wouldn't consider
> the resulting state to be "protection".

You forget about page tables.

There are cases when Windows forces our sbrk to set a very high DS/CS
limit, because some of the memory chunks handed by Windows' DPMI host
are near the end of the address space; but a program will still crash
(with a Page Fault) for many invalid pointers.  The reason is that
page tables do their job even though limit checking does not.

To say nothing about other types of protection, like access rights to
selectors.

- Raw text -