Locating
Home Up Feedback Contents Search


           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


Copyright © 1985 to 2022 Beta Systems                            Last modified: Wednesday, January 05, 2022 .