www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/05/02/09:01:22

Date: Thu, 2 May 1996 15:08:45 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Dettino Alberto <adettino AT dsi DOT unive DOT it>
Cc: djgpp AT delorie DOT com
Subject: Re: Handling INT 0x24
In-Reply-To: <199605021015.AA28083@moo.dsi.unive.it>
Message-Id: <Pine.SUN.3.91.960502150113.7358D-100000@is>
Mime-Version: 1.0

On Thu, 2 May 1996, Dettino Alberto wrote:

> When an error related to the disks accour (such as no disk in drive, disk ful,
> ecc.) dos calls the critical error handler (int 0x24).
> I have seen that programs compiled with DJGPP automatically handle this
> interrupt and make the routine fails the system call so the calling (for
> example fopen, fread, ecc.) function returns an error.

Beware: some DPMI hosts (notably, QDPMI) will abort your program instead 
of silently failing the call.

> Now I want to trap this interrupt so I have written a little program:

Is this under CWSDPMI?  AFAIK, it doesn't support hooking Int 24h, so the 
problems that you see might be due to this misfeature.

>  /* simply make dos terminate our application */
>  r->h.al=2;

I don't think you are allowed to do this under DPMI.  Terminating a DPMI 
program should not be done when it temporarily switches to real mode.  
That is why most DPMI hosts do not even print that Abort/Retry/Explode 
message, so you don't get a chance to press `A'.

What you should have done is to hook Int 24h in protected mode and handle 
it from there.  As CWSDPMI doesn't support this, it won't call you 
handler, that's why you tried to hook the real-mode Int 24h, right?  
Well, don't.

- Raw text -


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