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"