Extended Memory Manager

XMS services are implemented under MVDM using a virtual device driver known as the Virtual Extended Memory Manager (VXMM) which is represented by the file VXMS.SYS (VXMS). VXMM provides a separate XMS emulation for each VDM by placing most VXMS control structures in a per-VDM data area outside the V86 mode address space. The amount of memory available to a VDM, the number of handles, and the existence of Upper Memory Blocks (UMBs) are all configurable parameters which may be altered on a per-VDM basis.

The VXMM hooks interrupt vector 2Fh in order to announce its presence to applications. It also provides a V86 stub device driver (XMM 3X device driver), which indicates to DOS applications that XMS is available, but more importantly acts as a V86 mode interface between the application and the VXMM proper.

VXMM depends heavily upon the memory manager. XMS object allocation reallocation, and deallocation are accomplished by requesting corresponding services from the memory manager. When an application requests the allocation of a block of extended memory, for example, VXMS asks the memory manager to allocate a memory object in linear memory outside any VDM. Reallocation and deallocation are handled similarly.

All EMS functions are executed by calling the XMS Control Function, the address of which can be obtained by a call to INT 2Fh. Arguments are passed in registers.

Figure "Extended Memory Manager Control Flow"

During the initialization of the VDM the VDM Manager loads and initializes the XMM DOS stub device driver into the VDM address space. As soon as there is a XMS request the VDM Manager loads the the XMS virtual device driver VXMS.

a)

The VDM Application issues a INT 15h service request. VXMS directly hooks INT 15h for function 87h and 88h. It does not provide any services through these calls but makes sure that no program tries to use extended memory directly. INT 15h function 88h will respond that no normal extended memory is available. Programs that want to use extended memory directly by using INT 15 and RAMdisks (electronic disks) using INT 15 won't work. The MS DOS RAMDRIVE for DOS 5.0 does work because it uses XMS instead of INT 15.
b)
The VDM application issues INT 2Fh to determine if an XMS driver is installed.
c)
The VDM application issues INT 2Fh to determine if an XMS driver is installed.
d)
Next the VDM application issues a INT 2Fh to obtain the address of the XMS driver's control function. As soon as the VDM Application got the address of the XMS driver's control function it can use any of the functions and call the XMM DOS stub device driver directly.
e)
The VDM application calls the XMS driver's control function to access all of the XMS functions.
f)
The XMM DOS stub device driver calls breakpoint traps by the VXMM Control Function.
g)
The VDM Manager initialization, creation, termination calls for XMS-Objects. The VDM Manager traps the VDM application's INT 15h service request and routes it to VXMS as well as XMS control function requests for XMS memory.
h)
The VXMS requests corresponding services from the VDH services:

Creation/termination handler registration

INT 67h prehooking

Linear address reservation

Memory management

Obtaining configuration information.
i)
The result is returned.

Like VEMM and unlike most other virtual device drivers, VXMS.SYS does not have a corresponding physical device driver. Instead, it depends heavily upon the OS/2 Version 2.0 memory manager. XMS object allocation, reallocation and deallocation are accomplished by requesting corresponding services from the operating system's memory manager. For example, when an application requests the allocation of a block of extended memory, VXMM requests the memory manager to allocate a memory object in linear memory outside the V86 mode address space. Reallocation and deallocation are handled similarly.

Structure

The VXMS.SYS module consists of:

• An initialization component that initializes global structures and reads the global configuration at boot time.

• A creation component that initializes per-VDM structures, reads per-VDM configuration values, and installs the DOS device driver stub when a VDM is created.

• A router component that receives control from the control function contained in the stub device driver, and dispatches the call to an appropriate service routine. In addition, the router function hooks interrupt vector 15h upon the first non-version-query call to VXMM, as required by the specifications, in order to:

  a)

  Preserve the state of the A20 line across block copies (service AH=87h).
  b)
  Respond to service AH=88h (Query Extended Memory) by reporting that there is no extended memory available.
  4.
  A number of service routines, which perform the required XMS functions.

  Applications request XMS services by calling a subroutine contained within the VXMM, known as the Control Function. The VXMS virtual device driver hooks interrupt vector 2Fh in order to announce its presence to applications.

  Initialization

  VXMS.SYS may be loaded at system initialization time by using a DEVICE= statement in CONFIG.SYS, as shown below:

  DEVICE=C:\OS2\MDOS\VXMS.SYS 8192, 2048

  This statement should be placed in CONFIG.SYS after the DEVICE= statement for VEMM.SYS, since VXMM queries VEMM to ensure that no conflicts occur in memory allocation.

  The DEVICE= statement uses parameters to specify the total amount of available XMS memory, and the default limit for each VDM. In the above example, the overall limit is set to 8MB and the limit for each VDM is set to 2MB.

  The virtual device driver VXMS.SYS can be configured as follows.

         device = {path} vxms.sys {options}
  

  The options are of the form "/keyword=value":

  • XMMLIMIT=g,i
    Sets the global (system-wide) maximum memory usage of the VXMS.SYS driver to g kilobytes, and a per-VDM maximum of i kilobytes. These values should be large enough to accommodate an automatic 64KB allocation in each VDM for the HMA. Values are restricted to the range 0..65535 (= 64Meg).

    The values of g and i are rounded up to the nearest multiple of 4.

    Specifying i = 0 suppresses XMS installation in all VDMs unless specifically overridden by a VDM-specific configuration string. (See below.)

    Default: /XMMLIMIT=4096,1024

    /HMAMIN=d
    Sets the minimum request size (in kilobytes) for an HMA request to succeed. Values are restricted to the range 0..63.

    Default: /HMAMIN=0

    /NUMHANDLES=n
    Sets the number of handles available in each VDM. Each handle occupies eight bytes. Values are restricted to the range 0..128.

    Default: / NUMHANDLES=32

    /UMB
    Instructs XMM to create Upper Memory Blocks

    Default: off

    /NOUMB
    Instructs XMM not to create Upper Memory Blocks

    Default: /NOUMB

    All other keywords are ignored. Case is ignored.

    These options affect all VDMs, but can be overridden by a VDM's configuration strings. The same option names are available to VDMs (without the prefixing slash), except that XMMLIMIT only takes one numeric argument, corresponding to the value i above. The value g above cannot be changed once XMM is installed.

    If a value of i=0 was specified on the DEVICE= line, to create a VDM with XMS installed, specify a configuration string "XMMLIMIT" with a non-zero value. Conversely, to have no XMS installed, specify a configuration string "XMMLIMIT" with a value of zero.

    If UMBs are being used, it is crucial that VXMS.SYS be the last device driver loaded, for VXMS.SYS reserves all available addresses between 640KB and 1Meg for use as UMBs. Hence, any device drivers which reserve pages in that region (for example, VEMM) will not be able to install.

    VXMS.SYS will fail to install if some other device driver has already reserved the region from 1MB to 1MB+64KB.

    The overall limit comprises the only relationship between XMS memory objects in different VDMs, and is imposed to prevent XMS from acquiring all available memory. The default overall limit is 4MB, and the default limit for each VDM is 1MB. The default limit for each VDM can be overridden by installing an application on the desktop and choosing to specify the XMS size with the DOS Settings feature (see DOS Settings).

    Setting the overall limit to zero disables XMS in all VDMs regardless of the per-VDM value. Setting the default limit for a particular VDM to zero disables XMS in all VDMs unless their start list entries specify a non-zero XMS size. Setting the XMS size to zero for an entry in the start list disables XMS for that application's VDM only. Novice users need never change the default values.

    In addition to memory sizes, the number of handles and the presence or absence of Upper Memory Blocks are all configurable parameters which may be altered on a per-VDM basis using the DOS Settings feature.

    Upon installation, an initialization routine within VXMS.SYS supplies the addresses of the VXMS.SYS VDM-creation and close routines to the Virtual DOS Machine Manager.

    VDM Creation

    Upon creation of a VDM, a VDH service is used to get the maximum XMS size for that VDM. This will return a string if the program's entry on the desktop has an associated VXMS size. If the per-VDM size is not defined, the default retrieved from CONFIG.SYS at initialization time will be used. If VXMS size is not 0, the following steps are then performed:

  • Upper Memory Blocks (UMBs) are found and reserved.

  • The High Memory Area (HMA) is reserved.

  • The real mode device driver stub is loaded.

  • The handle table and UMB list are initialized.

    To find an available linear region to use for UMBs, VXMS requests VDH services to locate the largest free address range in the V86 mode address space above 640KB. VXMS reserves all the pages returned until the call fails.

    VXMS requests the OS/2 Version 2.0 memory manager to allocate the 64KB region immediately above 1MB for use as the High Memory Area. The way in which this is accomplished depends upon a number of variables; see High Memory Area (HMA) for further details.

    Waiting until creation time to reserve this memory allows virtual device drivers with actual hardware to claim their addresses first, since VXMS's UMBs can be placed at any available address. A consequence is that the space is reserved only for the VDM being created; it could be in a different location or be a different size for other VDMs.

    VXMS then arranges for the loading of a stub device driver in the VDM. This driver serves three purposes:

  • The device driver header can be read by an application searching for the name of the real mode VXMS driver. It responds to all device requests with "done" without actually doing anything.

  • The device driver's initialization code attaches VXMS to interrupt vector 2Fh. Attaching to vector 2Fh must be delayed until after the virtual DOS environment has completed hooking all of its interrupts.

  • The device driver contains the VXMS control function; calls to XMS services are not performed by calling a software interrupt, but rather by calling a V86 mode far subroutine called the control function. Moreover, XMS specifications require the control function to have a particular physical layout. Hence, the control function is placed in a DOS device driver so that it may have the layout required by the specifications and can transfer control to the virtual device driver code (the router function).
    

    The stub device driver is used to transfer control to the router function. A DOS application invokes XMS functions by calling the control function as a far procedure, the address of which can be obtained by a different INT 2Fh call. In response to such a request, the INT 2Fh interrupt handler returns the address of the control function in the device driver stub. The Control Function then calls the protected mode VXMS entry point, and the router obtains control.

    The interrupt hook cannot be performed by the VXMS creation function, since the virtual DOS environment does not establish its interrupt hooks until after all virtual device driver creation code has completed. DOS device driver initialization code is called after the interrupt vectors are set; therefore delaying the hooking of vector 2Fh until DOS device driver initialization time succeeds in hooking the vector.

    Routing

    The router receives control from the control function within the stub device driver, as described above. After checking that the XMS service request is valid, the router calls the appropriate protected mode service routine, which in turn requests the OS/2 Version 2.0 memory manager to allocate and manipulate XMS objects.

    Information calls involve at most a quick search of structures. The number of kilobytes VXMS reports as available is the minimum of the number of kilobytes the VDM has left before it hits its per-VDM XMS memory usage limit, the number of kilobytes all VDMs have left before hitting the system-wide memory usage limit, and the amount the memory manager estimates is available.

    ---

    [Back: Extended Memory Support]
    [Next: High Memory Area (HMA)]