Path: utzoo!utgpu!attcan!uunet!steinmetz!control!dixon From: dixon@control.steinmetz (walt dixon) Newsgroups: comp.sys.ibm.pc Subject: Re: DOS Device Error Handling - Need Help Message-ID: <11891@steinmetz.ge.com> Date: 18 Aug 88 14:03:46 GMT References: <104@sickkids.UUCP> Sender: news@steinmetz.ge.com Reply-To: dixon@control.steinmetz.ge.com (walt dixon) Organization: General Electric CRD, Schenectady, NY Lines: 45 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.