From: pavenis AT lanet DOT lv Message-ID: To: eplmst AT lu DOT erisoft DOT se (Martin Stromberg), djgpp AT delorie DOT com Date: Mon, 11 Oct 1999 12:19:24 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Problems using signals In-reply-to: <7tqeh0$ktf$1@antares.lu.erisoft.se> X-mailer: Pegasus Mail for Win32 (v3.12a) Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On 10 Oct 99, at 16:22, Martin Stromberg wrote: > Eli Zaretskii (eliz AT is DOT elta DOT co DOT il) wrote: > : The way it works is as follows. The keyboard interrupt handler > : invalidates the DS selector by resetting its limit to the first page > : (a.k.a. null page) only, saves the original limit in a special > : variable, sets a flag which indicates that Ctrl-C was seen, and then > : does an IRET. Since all data is above the null page, we are > : guaranteed that the first time the program touches any of its data, it > : will trigger a GPF. The GPF exception handler, also set up by the > : startup code, sees that the exception is really a fake one generated > : by Ctrl-C, so it restores the DS limit to its original value and then > : does a "raise(SIGINT);". > > Nice explanation, but how can this work in WINDOZE where there isn't any > NULL page? > Under Win9X DPMI server You cannot protect NULL page against access (so You cannot catch NULL pointer dereferencing). That doesn't meen that there is no such page.