LIM Expanded Memory Specification V4: Appendix B

TESTING FOR THE PRESENCE OF THE EXPANDED MEMORY MANAGER

Before an application program can use the Expanded Memory Manager, it must determine whether DOS has loaded the manager. This appendix describes two methods your program can use to test for the presence of the memory manager and how to choose the correct one for your situation. The first method uses the DOS "open handle" technique; the second method uses the DOS "get interrupt vector" technique.

WHICH METHOD SHOULD YOUR PROGRAM USE?

The majority of application programs can use either the "open handle" or the "get interrupt vector" method. However, if your program is a device driver or if it interrupts DOS during file system operations, you must use only the "get interrupt vector" method. Device drivers execute from within DOS and can't access the DOS file system; programs that interrupt DOS during file system operations have a similar restriction. During their interrupt processing procedures, they can't access the DOS file system because another program may be using the system. Since the "get interrupt vector" method doesn't require the DOS file system, you must use it for these types of programs.

THE "OPEN HANDLE" TECHNIQUE

Most application programs can use the DOS "open handle" technique to test for the presence of the memory manager. This section describes how to use the technique and gives an example. Caution.......................................................... Don't use this technique if your program is a device driver or if it interrupts DOS during file system operations. Use the "get interrupt vector" technique described later in this chapter.

USING THE "OPEN HANDLE" TECHNIQUE

This section describes how to use the DOS "open handle" technique to test for the presence of the memory manager. Follow these steps in order:

1. Issue an "open handle" command (DOS function 3Dh) in "read only" access mode (register AL = 0). This function requires your program to point to an ASCII string which contains the path name of the file or device in which you're interested (register set DS:DX contains the pointer). In this case the file is actually the name of the memory manager.
   You should format the ASCII string as follows:
   ASCII_device_name DB "EMMXXXX0", 0
   The ASCII codes for the capital letters EMMXXXX0 are terminated by a byte containing a value of zero.
2. If DOS returns no error status code, skip Steps 3 and 4 and go to Step 5. If DOS returns a "Too many open files" error status code, go to Step 3. If DOS returns a "File/Path not found" error status code, skip Step 3 and go to Step 4.
3. If DOS returns a "Too many open files" (not enough handles), status code, your program should invoke the "open file" command before it opens any other files. This will guarantee that at least one file handle will be available to perform the function without causing this error.
   After the program performs the "open file" command, it should perform the test described in Step 6 and close the "file handle" (DOS function 3Eh). Don't keep the manager "open" after this status test is performed since "manager" functions are not available thru DOS. Go to Step 6.
4. If DOS returns a "File/Path not found", the memory manager is not installed. If your application requires the memory manager, the user will have to reboot the system with a disk containing the memory manager and the appropriate CONFIG.SYS file before proceeding.
5. If DOS doesn't return an error status code you can assume that either a device with the name EMMXXXX0 is resident in the system, or a file with this name is on disk in the current disk drive. Go to Step 6.
6. Issue an "I/O Control for Devices" command (DOS function 44h) with a "get device information" command (register AL = 0h). DOS function 44h determines whether EMMXXXX0 is a device or a file.
   You must use the file handle (register BX) which you obtained in Step 1 to access the "EMM" device. This function returns the "device information" in a word (register DX). Go to step 7.
7. If DOS returns any error status code, you should assume that the memory manager device driver is not installed. If your application requires the memory manager, the user will have to reboot the system with a disk containing the memory manager and the appropriate CONFIG.SYS file before proceeding.
8. If DOS didn't return an error status, test the contents of bit 7 (counting from 0) of the "device information" word (register DX) the function returned. Go to Step 9.
9. If bit 7 of the "device information" word contains a zero, then EMMXXXX0 is a file, and the memory manager device driver is not present. If your application requires its presence, the user will have to reboot the system with a disk containing the memory manager and the appropriate CONFIG.SYS file before proceeding. If bit 7 contains a one, then EMMXXXX0 is a device. Go to Step 10.
10. Issue an "I/O Control for Devices" command (DOS function 44h) with a "get output status" command (register AL = 7h).
    You must use the file handle you obtained in Step 1 to access the "EMM" device (register BX). Go to Step 11.
11. If the expanded memory device driver is "ready," the memory manager passes a status value of "0FFh" in register AL. The status value is "00h" if the device driver is "not ready."
    If the memory manager device driver is "not ready" and your application requires its presence, the user will have to reboot the system with a disk containing the memory manager and the appropriate CONFIG.SYS file before proceeding.
    If the memory manager device driver is "ready", go to Step 12.
12. Issue a "Close File Handle" command (DOS function 3Eh) to close the expanded memory device driver. You must use the file handle you obtained in Step 1 to close the "EMM" device (register BX)

AN EXAMPLE OF THE "OPEN HANDLE" TECHNIQUE

The following procedure is an example of the "open handle" technique outlined in the previous section.

;---------------------------------------------------------------;
;   The following procedure tests for the presence of the EMM   ;
;   in the system.  It returns the CARRY FLAG SET if the EMM is ;
;   present.  If the EMM is not present, this procedure returns ;
;   the CARRY FLAG CLEAR.                                       ;
;---------------------------------------------------------------;

first_test_for_EMM  PROC  NEAR

PUSH DS
PUSH CS
POP  DS
MOV  AX, 3D00h                     ; issue device open in
LEA  DX, ASCII_device_name         ; read only mode
INT  21h
JC   first_test_for_EMM_error_exit ; test for error during open

MOV  BX, AX                        ; get file handle returned by DOS
MOV  AX, 4400h                     ; issue IOCTL get device info
INT  21h
JC   first_test_for_EMM_err_exit   ; test for get device info error

TEST DX, 0080h                     ; test to determine
JZ   first_test_for_EMM_err_exit   ; if ASCII_device_name
                                   ; is a device or a file
MOV  AX, 4407h                     ; issue "IOCTL"
INT  21h
JC   first_test_for_EMM_error_exit ; test for IOCTL error
PUSH AX                            ; save "IOCTL" status
MOV  AH, 3Eh                       ; issue "close
INT  21h                           ; file handle"
POP  AX                            ; restore "IOCTL" status
CMP  AL, 0FFh                      ; test for "device ready" status
JNE  first_test_for_EMM_error_exit ; returned by the driver
first_test_for_EMM_exit:

POP  DS                            ; EMM is present in the system
STC
RET

first_test_for_EMM_error_exit:

POP  DS                            ; EMM is NOT present in the system
CLC
RET

ASCII_device_name                  DB  "EMMXXXX0", 0

first_test_for_EMM ENDP

THE "GET INTERRUPT VECTOR" TECHNIQUE

Any type of program can use the DOS "get interrupt vector" technique to test for the presence of the memory manager. This section describes how to use the technique and gives an example. Caution.......................................................... Be sure to use this technique (and not the "open handle technique) if your program is a device driver or if it interrupts DOS during file system operations.

USING THE "GET INTERRUPT VECTOR" TECHNIQUE

This section describes how to use the DOS "get interrupt vector" technique to test for the presence of the memory manager. Follow these steps in order:

1. Issue a "get vector" command (DOS function 35h) to obtain the contents of interrupt vector array entry number 67h (addresses 0000:019C thru 0000:019F).
   The memory manager uses this interrupt vector to perform all manager functions. The Offset portion of this interrupt service routine address is stored in the word located at address 0000:019Ch; the Segment portion is stored in the word located at address 0000:019Eh.
2. Compare the "device name field" with the contents of the ASCII string which starts at the address specified by the segment portion of the contents of interrupt vector address 67h and a fixed offset of 000Ah. If DOS loaded the memory manager at boot time this name field will have the name of the device in it.
   Since the memory manager is implemented as a character device driver, its program origin is 0000h. Device drivers are required to have a "device header" located at the program origin. Within the "device header" is an 8 byte "device name field." For a character mode device driver this name field is always located at offset 000Ah within the device header. The device name field contains the name of the device which DOS uses when it references the device.
   If the result of the "string compare" in this technique is positive, the memory manager driver is present.

AN EXAMPLE OF THE "GET INTERRUPT VECTOR" TECHNIQUE

The following procedure is an example of the "get interrupt vector" technique outlined in the previous section.

;---------------------------------------------------------------;
;   The following procedure tests for the presence of the EMM   ;
;   in the system.  It returns the CARRY FLAG SET if the EMM is ;
;   present.  If the EMM is not present, this procedure returns ;
;    the CARRY FLAG CLEAR.                                      ;
;---------------------------------------------------------------;

second_test_for_EMM                PROC    NEAR

PUSH DS
PUSH CS
POP  DS
MOV  AX, 3567h                     ; issue "get interrupt vector"
INT  21h
MOV  DI, 000Ah                     ; use the SEGMENT in ES returned by
                                   ; DOS, place the "device name
                                   ; field" OFFSET in DI
LEA  SI, ASCII_device_name         ; place the OFFSET of the device
                                   ; name string in SI, the SEGMENT
                                   ; is already in DS
MOV  CX, 8                         ; compare the name strings
CLD
REPE CMPSB
JNE  second_test_for_EMM_error_exit

second_test_for_EMM_exit:

POP  DS                            ; EMM is present in the system
STC
RET

second_test_for_EMM_error_exit:

POP  DS                            ; EMM is NOT present in the system
CLC
RET

ASCII_device_name                  DB "EMMXXXX0"

second_test_for_EMM                ENDP

LIM Expanded Memory Specification V4 Contents

• Title and Contents
• Chapter 1: Introduction
• Chapter 2: Writing Programs that use Expanded Memory
• Chapter 3: EMM Function Reference
• Appendix A
• Appendix B (this page)
• Appendix C
• Appendix D
• Glossary

See Also

• Lo-tech 2MB EMS Board