[comp.sys.ibm.pc] DOS Device Error Handling - Need Help

gw@sickkids.UUCP (CFI/Graham Wilson ) (08/18/88)

Hello all.  I am looking for techniques to cleanly handle device errors in
DOS.  I am mainly interested in trapping floppy disk errors.  I don't like

	Error reading drive A
	Abort, Retry, Ignore ?

showing up on your graphics display because the user forgot to put the data
disk in drive A.

I have used a variety of techiques to deal with this problem, and my current
solution is to intercept BIOS int 0x13 calls.  When an error occurs (i.e.
write protect or disk not ready), then the error is passed via assembler to
my C routine, which flashes a nice window telling the user to fix what ever
is wrong.  The diskette system is resette (int 0x13 service 0) and the disk
command is tried again.  DOS never gets an error returned from BIOS.  It
works just fine (no bugs, no crashes - I'll email the source if you ask).

But, I'm greedy.  I want more!  I want to exit cleanly from disk I/O if
an error occurs.  For example, I want the following to work:


	errortrap_init();

	/*  Drive A is empty */

	fp = fopen("a:file","r");
	if ( fp==0 && errortrap_flag==NODISK )
		printf("No disk in drive A");

	errortrap_term();

Without the annoying DOS error message.  Note that error recovery must be
clean - no hangs and no flags left set which make it difficult retry the
same operation later.

All I can think of is to re-write large chunks of DOS for floppy disk I/O.
I really don't want to do that.  Can anyone help?  Ideas? Thanks bunches
in advance.  Please e-mail.  Will post summary if working solution can be
devised.

Oh yes, if it matters, it should apply to DOS 3.X

Graham Wilson         |   watmath  allegra     decvax
CyberFluor Inc        |        |      |           |  
179 John St, #400     | uunet!utai!utgpu!utzoo!sickkids!gw
Toronto, Ont, M5T 1X4 |        |           |
(416) 977-5450        |  ubc-vision      linus

dixon@control.steinmetz (walt dixon) (08/18/88)

The error message you refer to is displayed by a critical error
handler established by command.com.  When DOS needs a device drivers
help to complete a request,  DOS passes a data structure known
as a request header to the driver.  Information within the request
header describes what DOS wants the driver to do.  After the driver
completes the request,  it sets the request header status field and
returns to DOS.  The value in the status field indicates whether the
operation was successful.  DOS looks at this status and executes
an int 24h if an error occured.

You can declare your own critical error handler by capturing int
24h.  The error description is passed in various registers,  so
some type of assembly language interface is probably needed.  Your
critical error handler can ask that the error be ignored,  retried,
the call failed,  or the program be aborted.  Not all of these
options are valid at all times.  Before DOS makes a driver request,
it sets a flag indicating valid critical error actions.  DOS validates
the action requested by a critical error handler against this mask.
If you do not invoke the previous critical error handler (ie the
one that command.com set up),  you can eliminate the abort, retry,  etc
message.

There are a couple of caveats to critical error handlers.  If DOS
was servicing a handle request,  it invalidates the file handle
before invoking the critical error handler.  You cannot reissue the
offending request from a critical error handler.  More importantly
only certain DOS services are safe within a critical error handler.
Because of the way the int 21h dispatcher switches stacks,  only
requests in the range 01h to 0ch are safe.

The DOS Technical Reference manual discusses the arguments passed
to a critical error handler.  Chapter 10 of the MS-DOS Papers
(Howard Sams,  1988) describes device driver/dos interaction.  Critical
error processing is described in Chapter 4 of the revised MS-DOS
Developer's Guide (to be published later this year). [Although I am
the author of these chapters,  I get no royalties.  Just citing a
couple of good references.]

Walt Dixon		{ARPA:		dixon@ge-crd.arpa	}
			{US Mail:	GE Corp. R&D		}
			{		PO Box 8		}
			{		Schenectady,  NY 12345	}
			{Phone:		518-387-5798		}

Standard disclaimers apply.

mason@tc.fluke.COM (Nick Mason) (08/23/88)

In article <104@sickkids.UUCP> gw@sickkids.UUCP (CFI/Graham Wilson (977-5450) [RICFI7921Z]) writes:

To trap "abort retry ignore" use the
 
 _harderr() function in microsoft C 5.1.  It will call
 a routine that you write and will probably do what you want.



Nick Mason/ms272G/John Fluke Mfg Co/Box C9090/Everett WA 98206 USA
   mason@tc.fluke.COM
UUCP:
 {{cornell,decvax,sdcsvax,tektronix,utcsrgv}!uw-beaver} \
{microsoft,gatech!sb1,hplabs!lbl-csam,decwrl!sun,sunup} - !fluke!mason
		 {ssc-vax,hplsla,wavetek,uw-vlsi,tikal} /
ARPA: fluke!mason@uw-beaver.ARPA
BITNET: "fluke!mason@uw-beaver.ARPA"@PSUVAX1.bitnet
"Avoid the Dull and Ignorant"