Click above to get retro games delivered to your door ever month!

 Saving the currently executing program
------------------------------------------------------------------------------
 The program image can be saved to any of three supported swap media - XMS
 2.0 (or higher) memory provided by the Microsoft HIMEM.SYS driver or
 equivalent, EMS 3.2 (or higher) memory, or a disk file.

 If necessary, the swap function will make a transition from one media to the
 next, saving part of the image on one storage media, and the rest on
 another, but under no circumstances will more than one disk swap file be
 created.

 The swap function can be called from a real or protected mode parent and can
 call a real or protected mode child program, but only the conventional
 memory portion of the parent program is swapped out. It is often important
 to restrict the amount of XMS or EMS allocated to the first program in order
 to leave enough for the swap to proceed and still leave some for the child
 program.

 XMS/EMS memory

 The use of XMS or EMS memory can be controlled through the two functions
 SWPUSEXMS() and SWPUSEEMS(). The use of XMS and EMS defaults to on, that is
 to say XMS or EMS will be used if available.

 In addition, the amount of XMS or EMS left for the child program can be
 controlled through the use of the two functions SWPFREXMS() and SWPFREEMS().

 Disk swap file

 In the event that there is no available XMS or EMS memory, or its use has
 been disabled, the image will be saved to a disk file. The directory where
 the image file is to be stored can be specified as a parameter to the swap
 function itself, or alternatively can be specified via the SWAP environment
 variable, which has priority over the passed parameter. The default is to
 use the current directory.

 Each disk swap file is created with a unique name. Under DOS 3.x and higher,
 DOS is called to create a uniquely named file, and under DOS 2.x, the swap
 function itself will manufacture a unique filename. The image file is
 created read only to prevent accidental deletion while the child program is
 executing.

 System settings saved

 The swap function will save and restore the following settings:

 . Expanded file handle table
 . Interrupt vector table
 . Video mode and page (optional)
 . Current directory (optional)
 . EMS pageframe mapping state
 . Mouse event handler and call mask

 The resident kernel

 A small amount of code and data, known as the resident kernel, always
 remains in memory during the swap. This code performs several functions, the
 most important of which is restoring the parent program once the child has
 terminated.

 Currently there are two possible locations where the resident kernel may
 reside - as low down in conventional memory as possible, or in an upper
 memory block (UMB).

 UMBs (also known as LOADHI areas) are areas of memory between the 640 Kb and
 1 Mb address range. They are therefore outside of conventional DOS memory,
 but still within the 1 Mb real mode address space of the 80x86 family of
 processors.

 UMBs are generally only available on computers with 386 processors (or
 better), and are provided by a software memory manager, such as EMM386.EXE
 provided with MS DOS 5.0, QEMM from Quarterdeck, or 386MAX from Qualitas.

 The swap function will utilise a UMB by default, if available, thereby
 increasing the amount of memory available to the child program by a few Kb.
 The use of UMBs by the swap function may be controlled by the SWPUSEUMB()
 function.

 Kernel size

 The size of the resident kernel in memory is 7-8 Kb under normal
 circumstances. If a suitable UMB is available, the overhead in conventional
 memory will be just the size of the parent's environment, plus the size of
 the command interpreter. In unusual circumstances with very small parent
 programs, if no UMB is available, and the kernel is unable to relocate
 itself, the overhead can be as large as 11 Kb.