www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/01/12/04:53:47

Date: Mon, 12 Jan 1998 11:52:00 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Petr Mrazek <mrazek AT cas3 DOT zlin DOT vutbr DOT cz>
cc: Konference DJGPP <djgpp AT delorie DOT com>
Subject: Re: hardretn and others
In-Reply-To: <Pine.LNX.3.91.980112111310.4359C-100000@cas3.zlin.vutbr.cz>
Message-ID: <Pine.SUN.3.91.980112114122.1820R-100000@is>
MIME-Version: 1.0

On Mon, 12 Jan 1998, Petr Mrazek wrote:

> I need to port program which uses harderr, hardretn and hardresume 
> functions. How to write harderr I think I know (this is FAQ, isn't it?). 
> But how to write these two others I don't know.

This is a minefield!  The DPMI spec explcicitly disallows to terminate a
DPMI program from within an Int 24h handler.  Therefore, most DPMI servers
trap Int 24h and silently fail the call that caused it.  For those which
don't, the DJGPP startup code installs a handler for Int 24h that does the
same. 

In other words, for all practical purposes, your DJGPP program already
behaves as if `harderr' were called, and as if it calls `hardresume' with
a fail code when the handler is called.  And changing this behavior is 
AFAIK not easy and will probably get you into problems with the ways 
different DPMI servers deal with this issue.

I would therefore suggest not to mess with this at all.  If the original 
code only wants to trap the ubiquitous "Abort, Retry, Fail?" prompt, then 
DJGPP already does it for you.  But if the application really needs to 
take any path other than Fail, it is in general not possible in DPMI.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019