[EMAIL PROTECTED] (David C. Ullrich) wrote:
>
> > And yet he never made the connection that maybe Michael
> > Caracena's code *is* the code in Windows that regularly GPFs...
>
> Um, no. In [1] I wasn't talking about the GPF's that we
> see when Windows crashes. I forget the details, but
> these are _intentional_ GPF's that don't give error
> messages - they're part of how the system "works".
One clever use for GPFs in an old OS called Primos (anyone
remember that?) was to detect kernel stack overflows. The
idea was that you positioned the stack in virtual address
space so that its end abutted onto a page marked void in
the address translation tables, in effect a "hole" in the
virtual address space. Then, if some rogue code overflowed
the stack it would try and reference an address in this page
and immediately throw up a page fault error. I think they
did the same with the (smaller but even more critical)
fault stacks, e.g. to catch recursive page fault errors.
I'd be surprised if the same trick isn't used, even more
extensively, in Windoze these days, since many ex-Primates
probably migrated to Microsoft after Prime Computer Inc's
woes in the early '90s.
> As opposed to [2] the GPF's this guy is hiding - these
> are not GPF's that are supposed to happen.
Mind you, I can see how this might make more efficient and
streamlined the kind of code in which references through
null pointers were an anticipated but infrequent event.
The code would need to be well-regulated though, by always
maintaining a context indicator to allow the signal handler
to, say, allocate and initialize the right kind of structure
for the pointer and then restart the offending instruction.
Cheers
---------------------------------------------------------------------------
John R Ramsden ([EMAIL PROTECTED])
---------------------------------------------------------------------------
The new is in the old concealed, the old is in the new revealed.
St Augustine.
---------------------------------------------------------------------------
=================================================================
Instructions for joining and leaving this list and remarks about
the problem of INAPPROPRIATE MESSAGES are available at
http://jse.stat.ncsu.edu/
=================================================================
