Comments:	Authenticated sender is <mert0407 AT sable DOT ox DOT ac DOT uk>
From:	"George Foot" <george DOT foot AT merton DOT oxford DOT ac DOT uk>
To:	rylan AT inbtekom DOT co DOT za
Date:	Wed, 26 Aug 1998 02:04:36 +0000
MIME-Version:	1.0
Subject:	Re: Page Fault During Interupt
Reply-to:	george DOT foot AT merton DOT oxford DOT ac DOT uk
CC:	djgpp AT delorie DOT com
Message-Id:	<E0zBU2E-0006Q8-00@sable.ox.ac.uk>

On 25 Aug 98 at 23:21, Rylan wrote:

> JS Churchill wrote in message <35E2B1C5 DOT 24A5 AT boat DOT bt DOT com>...
> 
> >it works perfectly fine under a windows dos session, but not in normal
> >dos.
> 
> I've encountered this too - a demo I recently wrote with a little bit of
> assembler (nothing strange, just accesses video memory and some data in main
> memory) usind DJGPP inline asm crashed under plain DOS too, but runs under
> Windows. All it does is read stuff from memory and write to video memory.
> 
> Anybody else encounter this?

There are a number of reasons why something would work fine in a
Windows DOS box and crash when run in a real DOS session.  In Mr
Churchill's case I suspect that when he ran the program under
Windows, it was Windows's routines that were called to page in his
interrupt handler (or rather perhaps the block of memory it
accessed), rather than DOS routines, and perhaps the Windows
routines are more reentrant.

Other reasons tend to hinge around the two main differences in the 
environments: 1) Windows has its own DPMI server while under DOS 
people normally use CWSDPMI, which is stricter (so it informs you 
about more mistakes in your programs); 2) Windows has a built-in DOS 
extender of sorts which emulates various hardware functions (e.g. 
interrupts, port I/O) for the DOS box.

By far the most common cause for a program to crash under CWSDPMI but
not under Windows is that it attempts to dereference a NULL pointer.
CWSDPMI supports a new(ish) DPMI feature which allows the djgpp
startup code to mark the page of memory at your program's zero offset
as invalid, so that any reads from or writes to that page (i.e. NULL
pointer dereferences) cause a SIGSEGV.  Windows's DPMI server does
not support this function, so the accesses are permitted.  If your
program really is accessing this memory, it does have a bug and you
should fix it.  Running it from DOS (using CWSDPMI) and symifying the
traceback will point you to the NULL pointer dereference.

-- 
george DOT foot AT merton DOT oxford DOT ac DOT uk

- Raw text -