Most DR-DOS system calls return error information in the event of the call being unable to complete successfully. The nature of the returned information varies depending on the particular call. “Handle” calls use the carry flag and the AX register to notify the calling program of an error condition, whereas the “FCB” calls use the AL register. For all system calls Extended Error information is available.
Application programs can check for error conditions that might occur during handle calls by testing the state of the carry flag. If the carry flag is set then the program can determine the nature of the error condition by examining the contents of the AX register. The following handle calls return error codes in AX:
38H - 43H
44H (subfunctions 0EH and 0FH)
45H - 4BH
4EH, 4FH
56H, 57H
5AH
5CH
65H
67H, 68H
Values for AX and the meaning of those values are shown in Table 5-1.
|
Code |
Error |
|
0 |
No error |
|
1 |
Illegal function |
|
2 |
File not found |
|
3 |
Path not found |
|
4 |
No file handles (too many open files) |
|
5 |
Access denied |
|
6 |
Illegal file handle |
|
7 |
Memory control blocks destroyed |
|
8 |
Insufficient memory |
|
9 |
Illegal memory block address |
|
10 |
Invalid environment |
|
11 |
Illegal format |
|
12 |
Invalid access code |
|
13 |
Invalid data |
|
15 |
Invalid drive specified |
|
16 |
Removal of current directory attempted |
|
17 |
Devices do not match |
|
18 |
No more files |
|
19 |
Attempted write on protected disk |
|
20 |
Unit unknown |
|
21 |
Drive not ready |
|
22 |
Command unknown |
|
23 |
CRC error |
|
24 |
Bad Request Structure Length |
|
25 |
Seek error |
|
26 |
Media type unknown |
|
27 |
Sector not found |
|
28 |
Printer out of paper |
|
29 |
Write failure |
|
30 |
Read failure |
|
31 |
General failure |
|
32 |
Sharing violation |
|
33 |
Lock violation |
|
34 |
Invalid change of disk |
|
35 |
File Control Block not available |
|
80 |
File already exists |
|
82 |
Cannot create subdirectory |
|
83 |
Critical error failure |
|
86 |
Invalid password |
Application programs that use certain FCB calls can also check for error conditions by testing the contents of the AL register. If the contents are set to FFH then an error condition has occurred and the call was not completed successfully.
The following FCB calls provide error status via the AL register:
0FH - 13H
16H, 17H
23H, 29H
2BH, 2DH
More information about the precise cause of a notified error condition can be obtained if the application program immediately issues a Get Extended Error system call 59H. This call returns four items of information in the AX, BH, BL and CH registers. The error code is returned in AX. The error Class is returned in BH, the recommended Response in BL and the Resource affected in CH. More information on the error Class, Response and Resource can be found in the description of system call 59H in Chapter 4, DR-DOS System Calls.
Critical Error Handling is discussed in Section 3.5 INT 24H - Critical Error Exit Address.
An application program can provide its own Critical Error Handling routine. The application’s initialization code should save the INT 24H vector and substitute the start address of the applications error routine as the new INT 24H vector. This error routine will then gain control when an INT 24H occurs as the result of DR-DOS detecting a critical error. On entry to the routine the lower byte of the DI register will contain an error code. Values for these codes are shown in Table 3-3 and match the codes 19 through 31 in Table 5-1.
The error routine can pass control back to DR-DOS in order to obtain a user response to the error. It does this by pushing the Flag register onto the stack and making a FAR Call to the address saved from the INT 24H vector previously. DR-DOS will then issue a request for user response and return to the application error routine at the instruction after the FAR Call.
The error routine may then proceed to deal with the error as befits the needs of the application. To return to the point in the application at which the critical error occurred the routine need only execute an IRET instruction.
The error routine is not obliged to return control to DR-DOS for user response, it can elect to deal with the error itself. If it does so then the routine must also clean up the stack prior to returning control to the application. This involves the application program’s registers being popped from the stack and an IRET instruction being executed. The stack layout on entry to the Critical Error Handler is shown in Figure 3-1.
Critical error handling routines are allowed to issue an INT 21H function 59H system call to obtain extended error information as discussed above. For example it might be the case that a critical error shown as “Drive not ready” by the value in DI was actually caused by a “Sharing violation”. This cause could be determined via the 59H call.
[Front] [Prev Chapter] [Next Chapter]