Comments: Authenticated sender is From: "George Foot" To: rylan AT inbtekom DOT co DOT za Date: Wed, 26 Aug 1998 02:04:36 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT 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: Precedence: bulk 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