🚀 go-pugleaf

In article <192@altger.UUCP> darkness@altger.UUCP (Stefan Willmeroth) writes:
  Some days ago when my Excel 2.1c was killed apruptly with an unrecoverable
  application error I wondered if this would be the only way to deal with
  an GP-Fault. I dont know exactly about the rules and tricks of protected
  mode, but as far as I remember those GP-violations mostly result when an
  application adresses an undefined memory location or loads an invalid
  descriptor into a segment register. Why cant Windows tolerate those faults
  and map some unused bytes to the referred adress instead of shutting down
  the application and deleting the users work?

Windows could do such a thing, but it would be irresponsible.  If your
spreadsheet was broken and it just printed wrong answers instead of
crashing, I wouldn't want to drive on the bridge you were designing.

  The scheme of protected mode
  seems rather ridicolous to me since an application is allowed to trash
  another applications data without being shut down.

In order to make Windows run in real mode as well as standard and extended
modes, some compromises were made.  A wild reference by a Winapp might
cause that app to fail, but it might simply trash something else instead.
I wouldn't go so far as to call it ridiculous.

  Now... can such thing be implemented by changing a driver or device?

It is possible to write a device driver using the DDK to do the sort of thing
you are interested in.  More importantly, it is possible to write a driver
that displays a box that says:
	General Protection fault by instruction at 105:6969  MOV ES,DX
	AX=0000 BX=1234 CX=0001 DX=FFFF SI=0000 DI=0000
        CS=0105 SS=087D DS=0785 ES=0000 FS=0000 GS=0000
which would give the programmer a clue as to what was happening.

It is similarly possible to write a driver which would let an application-
defined fault handler gain control and perform application-specific recovery
actions.