www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/10/11/17:57:10

Date: Mon, 11 Oct 1999 12:25:57 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Martin Stromberg <eplmst AT lu DOT erisoft DOT se>
cc: djgpp AT delorie DOT com
Subject: Re: Problems using signals
In-Reply-To: <7tqeh0$ktf$1@antares.lu.erisoft.se>
Message-ID: <Pine.SUN.3.91.991011122446.28307F-100000@is>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On 10 Oct 1999, Martin Stromberg wrote:

> Nice explanation, but how can this work in WINDOZE where there isn't any
> NULL page?

You are mixing two related, but different things.

One is the null page protection, whereby the DJGPP startup code tries
to unmap the null page from the program's address space, to catch NULL
pointer dereferences.  Windows doesn't support the underlying DPMI
function, so this part doesn't work on Windows.  Accessing an unmapped
page causes the Page Fault exception. 

The other thing is catching references to memory beyond the data
segment's limit, which triggers a GPF exception.  This works in ANY
protected-mode environment, because checking the pointer against the
segment limit is fundamental to memory protection and is done by the
CPU, not by the OS.

Since the DJGPP signal generation resets the DS segment limit to 4095
bytes, and since the starting address of DJGPP programs is 4096, *any*
data reference is beyond the DS limit, and will therefore trigger a
GPF (not a Page Fault).

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019