|
|
TESTING FOR THE PRESENCE OF THE EXPANDED MEMORY MANAGER
Before an application program can use the Expanded Memory
Manager, it must determine whether the manager is present. The
two recommended methods are the "open handle" technique and the
"get interrupt vector" technique.
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 functions; programs that interrupt DOS during file
operations have a similar restriction. During their interrupt
processing procedures, they can't access the DOS file functions
because another program may be using the system. Since the "get
interrupt vector" method doesn't require the DOS file functions,
you must use it for programs of this type.
The "Open Handle" Method
Most application programs can use the DOS "Open Handle" method to
test for the presence of the EMM. To use this method, 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 reserved name of the expanded 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 code, skip Steps 3 and 4 and go to
Step 5. If DOS returns a "Too many open files" error code,
go to Step 3. If DOS returns a "File/Path not found" error
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 through 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 =
0). 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 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 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. 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 = 7).
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).
The "Get Interrupt Vector" technique
Any type of program can use this method to test for the presence
of the EMM.
Use this method (not the "Open Handle" method) if your program is
a device driver or if it interrupts DOS during file system
operations.
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:019Ch thru 0000:019Fh). 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 is present.
Terminate and Stay Resident (TSR) Program Cooperation:
In order for TSR's to cooperate with each other and with other
applications, TSRs must follow this rule: a program may only
remap the DOS partition it lives in. This rule applies at all
times, even when no expanded memory is present.
See Also Func/40h Func/4Eh/00h Errors History Programming Specifications |
|
|