From: Mihai Moise <moisemih AT ift DOT ulaval DOT ca>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Linear Frame Buffer Programming
Date: Tue, 01 Oct 1996 14:12:34 -0400
Organization: Universite Laval
Lines: 58
Message-ID: <32515F12.41C67EA6@ift.ulaval.ca>
References: <52oric$hop AT hagar DOT cyberoptics DOT com>
NNTP-Posting-Host: rachmaninov.ift.ulaval.ca
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

On the i386 and its successor, a general protection fault is sent if a
program tries to read or write from/to a page which is read or write
protected ( hence the message "Processor honors WP bit even in
supervisor mode. Good" when booting Linux ). Or maybe the page was
absent, CWSDPMI did not know where to redirect the request, and decided
your program's brief but nice existance would come to an end. 

Eric Rudd wrote:


> 2. On my home computer, if a program bombs while the linear frame buffer
> is enabled, the DJGPP cleanup routines (wherever they are) do not reset
> the video mode to anything useful, probably due to a deficiency in the
> card's BIOS.  Thus, the dump goes off into the ether, and I have to re-run
> the program with REDIR.EXE just in order to capture the error output. This
> is manifestly inconvenient, and I wonder how best to deal with this
> problem. (After a couple of such bombs, I got wise and wrote a short
> command-line utility to reset the video mode, which I invoke by blindly
> typing it in, as the screen flashes garbage.  This at least saves me from
> re-booting.)  I have thought of three solutions, besides the obvious one
> (get a new video card):
> 

In svgalib, Harm Hanemaayer caught signals sent by the kernel ( SIGSEGV,
SIGFPE, and SININT are the most common ones ). These signals are handled
by a function which resets text mode, outputs a message, and then
invokes the usual signal handler, which is nonexistant, therefore the
program terminates.

I have tried the same thing under DOS and CWSDPMI and it works wuite
well. Never fails. You might want to take a look at the sources.


> 
> 3. After allocating physical address space with
> 
>    __dpmi_physical_address_mapping(__dpmi_meminfo *_info);
> 
> it would seem logical to free it before exiting the program, by calling
> 
>    __dpmi_free_physical_address_mapping(__dpmi_meminfo *_info);
> 
> but I find this function listed only in the DPMI 1.0 spec, in spite of the
> fact that the documentation in the DJGPP v2.00 file DPMI.H seems to
> suggest it exists under DPMI 0.9.  I am calling it anyway, and there seem
> to be no ill effects, even in a DOS box under Windows, but I don't know if
> I am doing the right thing.

You are not. It returns failure. I tried... ( sigh ). Just leave it
mapped. Sandmann and Gates will worry about it.

> 
> Has anyone out there dealt successfully with these problems?

That would be me. So e-mail me if you wish to discuss something else!

Mihai
check out DOS/svgalib at http://wwwbacc.ift.ulaval.ca/~moisemih