* C:\DOC\LOADSYS.DOC **** 16 FEB 95 *** 9:16 ******; G W Robinson

                   R A L   I B M   P C   U S E R   G U I D E
                   -----------------------------------------

                 LOADSYS TSR and Device Driver loader/unloader
                 ---------------------------------------------
      Contents
      ========
      1.    Introduction and Disclaimer

      2.    Overview
      2.1     Interrupts
      2.2     Memory Allocation
      2.3     TSRs
      2.4     Device Drivers
      2.5     I/O Port and Memory Modification
      2.6     LOADSYS features
      2.7     Loading at different positions in memory
      2.8     Upper Memory
      2.9     Extended Memory
      2.10    Expanded Memory
      2.11    Expanded Memory Managers
      2.12    LOADSYS Support of EMMs
      2.13    Moving system code and data
      2.14    Summary

      3.    LOADSYS
      3.1     Description
      3.2     Notes

      4.    Usage Guidelines
      4.1     BAT files
      4.2     Upper Memory
      4.3     Control Programs (Windows 3 and DESQview)
      4.4     Additional Features

      5.    Worked Examples
      5.1     PRINT
      5.2     Communications Cards
      5.3     RAINBOW
      5.3.1     RAINBOW over BICC 8 bit card MPS v3
      5.3.2     RAINBOW over BICC cards using MPS v4
      5.3.3     RAINBOW over BICC cards using Packet Driver
      5.3.4     RAINBOW over other cards using Packet Driver
      5.4     TCP/IP
      5.4.1     PC/TCP over BICC cards
      5.4.2     PC/TCP over other cards using Packet Driver
      5.5     PC-NFS
      5.5.1     PC-NFS over Packet Driver
      5.5.2     PC-NFS over 3COM cards
      5.6     PC3270
      5.7     MOS2
      5.8     Upper Memory

      6.    Bugs/Features and Problem Programs

      7.    Differences in LOADSYS versions

      8.    Support and Acknowledgements


      1. Introduction and Disclaimer
      ==============================

      The author and his employers accept no responsibilty for any damage
      done by this software.  It is run strictly at the users risk and
      all necessary precautions, such as backing up of discs, should be
      taken before hand.

      This document descibes LOADSYS which is a program that can load and
      unload Terminate and Stay Resident programs (TSRs) such as PRINT
      and also Device Drivers such as ANSI.SYS and VDISK.SYS.

      For Device Drivers this means that they no longer have to be
      defined in CONFIG.SYS and loaded when the PC is booted up.  They
      can be loaded when needed by LOADSYS and unloaded when not required
      thus removing the need to reboot the machine when the memory they
      occupy is needed by other programs.

      For TSRs which do not have an unload facility LOADSYS allows them
      to be removed from memory when they are no longer required.

      LOADSYS also contains a host of supporting features.  These include
      memory and I/O port reading and resetting and the listing of
      internal DOS tables. LOADSYS is also able to interface to expanded
      memory via drivers that support the LIM 3.2 or 4.0 interface. These
      include systems that map extended to expanded memory such as are
      found on 386 machines.

      However as with all good things there are some drawbacks.  LOADSYS
      has only limited facilities to shut down the program it is
      unloading.  Hence you have to use some commonsense before doing an
      unload.  For example unloading PRINT while it is still printing is
      not a good idea.  Similarily unloading a communications TSR whilst
      it is in use may have undesired effects.

      A second drawback is that although the unloading process frees the
      memory used by the Device Driver or TSR this may result in a gap in
      memory because of other programs that have been loaded after it.
      LOADSYS is able to move programs down memory to fill such holes but
      there is no guarantee the program would still work correctly - in
      fact it is highly likley it would fail hence the facility should be
      used with care.  It is prudent to take account the order of loading
      programs when several are involved.

      LOADSYS was developed and tested mainly under DOS 3.3 though it
      should work on all versions of DOS from 2.0 to 6.0.  DOS 5 and
      later are rather special in that they introduce their own memory
      management facilities and LOADSYS is able to interface to these.
      It has not been tested under OS/2 and is unlikely to work in that
      environment.  A list of problem programs is given near the end of
      this document.

      The current version is 1.4i and it fixes a problem with
      the help system introduced in v1.4h. The latter fixed a
      problem unloading CD-ROM device drivers.
 


      2. Overview
      ===========

      This section gives an overview of how LOADSYS works.  It is
      essential reading only if you wish to use the expert facilities or
      to understand a little of whats going on.

      2.1 Interrupts
      --------------

      Before describing how LOADSYS works it is necessary to understand a
      little about some of the features of the PC.  The first one to
      consider is an interrupt and these are generated by two possible
      means.  Hardware interrupts are generated by a hardware event such
      as pressing a key on the keyboard or the timer tick that occurs
      18.6 times per second.  Software interrupts are generated by
      programs using the INT instruction and are used to access the
      facilities of the BIOS and DOS such as writing to the screen or
      reading input from the keyboard buffer.  There are a maximum of 256
      different interrupts and the first 1K bytes of memory on a PC holds
      the table of four byte Interrupt vectors which are pointers to the
      code that services each interrupt.

      2.2 Memory Allocation
      ---------------------

      A second feature is memory allocation.  This is managed by DOS and
      programs and subsystems within DOS can request blocks of a given
      size.  Memory is allocated in multiples of 16 byte units known as
      paragraphs and all pointers to memory blocks are in terms of
      paragraphs.  This means that the 1Mbyte memory space of a PC can be
      accessed via 2 byte(16 bit) pointers know as segment or paragraph
      pointers.  Each block is preceded by a one paragraph header which
      contains details of its owner and how many paragraphs long the
      block is.

      2.3 TSRs
      --------

      A major subsystem in DOS is the program loader (EXEC).  This works
      by asking DOS for a block of memory to hold a copy of the DOS
      Environment (shown by the DOS SET command) and then for a second
      block to hold program itself.  The program block starts with
      256byte (Hex 10 paragraphs) Program Segment Prefix (PSP) which is
      used by DOS to control the running of the program.  A normal
      program releases all its memory on termination.  Those that dont
      are known as Terminate and Stay Resident (TSR) programs and these
      exit back to DOS via a special call which leaves them resident in
      memory.


      Once a TSR has returned control back to DOS it needs some mechanism
      to reactive itself.  It does this by linking in to an interrupt,
      such as the timer if it needs regular activation, or the keyboard
      if just wants to react to certain key presses.  It does this by
      copying the contents of the appropriate Interrupt vector and
      replacing it by a pointer to an interrupt handler in its own code.

      Thus when the Interrupt is activated the TSR code is executed and
      usually this ends by jumping via the original Interrupt vector to
      the previous interrupt handler.  It is therefore quite possible for
      several TSRs to form a chain of programs that are activated by one
      interrupt.  Thus removing a TSR from the middle of such a chain is
      rather difficult without the cooperation of the preceding TSR in
      the chain since there is no way of knowing where the latter has
      stored the next Interrupt vector in the chain.

      Before loading any program LOADSYS notes down all the Interrupt
      vectors.  For a TSR it then loads and runs the program.  On
      termination any changes to the Interrupt vectors are stored in
      small block of memory which will be referred to as the LOADSYS
      Control Block.  This Control Block enables LOADSYS to know which
      TSRs it has loaded and contains sufficient information to allow
      them to be unloaded subject to certain conditions.

      In theory unloading a TSR simply requires the Interrupt vectors to
      be returned to their original values and the memory occupied by the
      TSR to be released.  However if another TSR has added itself to the
      Interrupt chain LOADSYS has no means of telling the preceding
      Interrupt handler the new next member in the chain.  If this
      happens then LOADSYS is unable to unload the TSR.

      To get round this problem the /r option on LOADSYS redirects the
      Interrupt vectors used by a program via the Control Block.  Thus
      any further program will record an Interrupt vector that points to
      the Control block so that by judicious changing of pointers within
      the Control Block a program can be unloaded leaving the Control
      Block to take care of its position in the Interrupt vector chain.
      Only when it is the start of all the Interrupt vector chains is the
      Control Block removed from them and deleted.  Because it may have a
      life much longer than a TSR the Control Block is kept at the top of
      the DOS memory - just before 640K on most PCs.  TSRs are loaded at
      the bottom of memory as are normal programs.

      2.4 Device Drivers
      ------------------

      Device Drivers are treated in much the same way except that they
      have to be linked in to a series of lists within DOS.  This becomes
      especially tricky for Block Device Drivers (further details in the
      DOS Technical Reference).  A typical Block Device Driver is the
      virtual disc driver VDISK.SYS.  Because some of the information is
      held in a table rather than a chain it is very difficult to remove
      all but the last Block Device Driver so that is all that is
      allowed.  Fortunately most Device Drivers are of the Character type
      which is much easier to deal with.


      Because Device Drivers are normally loaded when DOS is booted up
      they sometimes make assumptions about the state of the machine.
      VDISK, for example, checks the memory it has been loaded into and,
      if it finds traces of itself, assumes that a warm start of the
      machine (Ctrl+Alt+Del) has occurred and that the virtual disc has
      all its files intact.  It can do this because VDISK.SYS is always
      loaded into the same area of memory at boot up.  Unfortunately for
      LOADSYS this cannot be assumed so the feature is inhibited by
      clearing the memory before any Device Driver is loaded and also the
      BIOS flag indicating a warm start is unset.

      2.5 I/O Port and Memory Modification
      ------------------------------------

      When a program is unloaded by LOADSYS it may be necessary to close
      down a communications card or disable an interrupt in order to
      avoid crashing the machine.  The /p option permits this by allowing
      an I/O Port to have its value reset when a program is unloaded.
      The entire value or just selected bits may be reset.  The /p option
      also allows I/O Port values to be displayed thus facilitating the
      setting up of this option.  I/O Port usage can be found in the
      appropriate Technical Reference manuals and great care is needed in
      setting them.  Note also that reading some ports clears the setting
      and this could adversely affect a program using that port.

      The /m option provides the same facility for inspecting and
      changing memory locations.

      2.6 LOADSYS features
      --------------------

      Both TSR and Device Drivers loaded with the /r option can be
      disabled (/d) by removing them from the Interrupt vector chains and
      the DOS lists.  The program is not removed from memory and can be
      enabled (/e) again.  It will preserve its previous state thus VDISK
      will still contain any files that had been written to it.

      Whilst the majority of programs will add themselves into the chain
      of Interrupt vectors at initialisation and thus be noted by LOADSYS
      there are some exceptions.  LOADSYS therefore checks before
      unloading or disabling a program to see if there are any extra
      Interrupt vectors pointing into it.  If so then the action is
      refused and an indication given how this limitation can be overcome
      if the Interrupt is not actually being used by the program.  The /i
      option allows such Interrupts to be specified at load time and thus
      overcomes the problem.

      Another variation on Interrupts is when loading a program can
      change an Interrupt vector yet it does not point into the program.
      This is referred to as a side effect and is reported by LOADSYS
      unless the /os option is given. Specifying such Interrupts via the
      /i option allows them to be reset when the program is unloaded.


      When several TSRs or Device Drivers are loaded and then some are
      unloaded it is possible to leave gaps in memory when the unloading
      is not last in - first out.  This should be avoided by loading
      programs in the right order but should this not be possible then
      LOADSYS with the squeeze (/q) option can move programs down memory
      to fill the gaps.  This is VERY DANGEROUS since it assumes the
      programs are relocatable at run time and this is not the case for
      the majority.  ANSI.SYS works but VDISK does not and should a
      failure occur then the machine will probably crash.  A much safer
      way is to unload and the load the program again though note that
      this will reinitialise it.  Any program that is going to be moved
      must be loaded with the /f (free) option.

      2.7 Loading at different positions in memory
      --------------------------------------------

      Similarily it is possible to load programs into the top of memory
      by using the /t option.  This is not as useful as it might be due
      to most programs reducing their memory requirements when they
      become resident and discard their initialisation code.  Thus there
      is likely to be an unusable gap at the top of memory.  A second
      problem is that programs loaded into the bottom of memory are given
      all the available free memory.  When they are loaded at the top of
      memory this is not practicable so they are loaded in the minimum
      specified.  This is frequently not enough so the /z option can
      specify the size of memory to be used for loading.  Loading the
      program in low memory with /z and no value will give an indication
      of its requirements.

      A subsiduary problem is the location of the programs stack.  If
      this is not explicitly defined in the program then it is initially
      located at 64K ie the end of the .COM program address space.  When
      a program is loaded at the top of memory this would waste a lot of
      memory so a 32 byte stack is added onto a programs stated size
      unless the /z option has been used when the stack is placed at the
      end of the program address space.  Note that even when a program
      sets up its own stack there must be a valid stack available when
      the program starts in order to cope with timer interrupts and the
      like that occur before the program has setup its own stack.  It
      takes 24 bytes to store the state of the machine.

      Note that when a program is loaded at the top of memory the Control
      Block is put into the bottom of memory.  However if the /oa option
      is given then the Control Block is put in the same part of memory
      as the program.

      Programs may also be loaded at a specified point in memory by using
      the /w option.  This can either be within the DOS 640K space or in
      any other memory below 1 Mbyte.  The latter can be memory held on
      device cards (ie the monochrome screen on a two screen PC) or any
      memory space obtained from memory mapping software or hardware -
      see next section.  Care is needed to make sure nothing else uses
      the memory whilst the program is loaded into it.


      An alternative way to use memory above 640K is to extend the DOS
      memory block chain into this region using the /b option and in this
      case LOADSYS will load programs in this area in preference to
      normal low memory.

      Programs can also be loaded at an address greater (/wg) or less
      than (/wl) that specified.

      When programs can also be moved to and from the top of memory using
      the /q option and the /t & /w options determine where it is
      located.

      2.8 Upper Memory
      ----------------

      Having developed a program loader one obvious extension is to load
      programs in the memory gaps between 640K and 1Mbyte.  To do this
      you need some form of memory mapping which gives the impression
      that such memory exists.  Due to its memory mapping hardware this
      is possible on 386 PCs and the present implementation is targeted
      at these.  There are several commercial products that do this such
      as QEMM and 386MAX and under DOS 5 the DOS=UMB command in
      CONFIG.SYS in conjunction with HIMEM.SYS and EMM386.SYS provides a
      similar facility.  LOADSYS does not seek to copy them since this
      would need a lot of effort which cannot be justified.  Rather it
      seeks to provide a poor mans halfway house by interfacing to what
      is already available.  These are the LIM v3.2, EMS/LIM v4.0 and XMS
      v2.0 interfaces.

      Before explaining what LOADSYS supports it is perhaps useful to
      explain the different types of memory for those who are unclear in
      this area.  The original PC was based on a 16 bit processor which
      had an address size of 20 bits and can thus address upto 1Mbyte of
      memory.  When it designed the PC, IBM decided to only use the first
      640K of this address space for programs and to reserve the
      remainder for the system side of the PC.  Thus the ROMs that
      provide the BIOS (Basic Input Output System), BASIC and support for
      new features such as EGA cards are all situated in the 640K to
      1Mbyte gap.  The screen buffers are also in this region.  The
      important point is that the whole of this area is not used.  There
      are gaps in the address space that are not occupied and it is the
      exploitation of this allows the PC to gain extra memory.

      This area of the address space between 640K and 1Mbyte will be
      referred to as upper memory - the memory below 640K being referred
      as lower memory.  The crucial thing to note is that most code
      will execute wherever it is situated in lower or upper memory.
      Thus if you can somehow install memory in the gaps is this area
      then it has the potential of being used to run programs.


      2.9 Extended Memory
      -------------------

      The original address limitation of 1Mbyte was removed by the
      arrival of the 286 processor in the PC/AT and its various clones.
      Whilst it is possible to address up to 16Mbytes with this machine
      you have to switch it into a different addressing mode and then you
      cannot run DOS or any of the programs that run under it without
      major modification.  Switching back to the original mode is also a
      tortuous process which involves rebooting the machine!  The memory
      that is situated above 1Mbyte is referred to as Extended memory
      because it is an extension of the original 1 Mbyte address space.
      There is now a standard known as Extended Memory Specification
      (XMS) v2.0 which defines how a system can manage not only memory
      above 1 Mbyte but also the upper memory between 640K and 1 Mbyte.

      2.10 Expanded Memory
      --------------------

      A second solution, which can also be used on the original 8088
      based PC/XT machines, is to add extra memory and provide a special
      mechinism to access it.  This is done by the hardware mapping 16K
      byte areas (called pages) of this memory onto a suitable gap in the
      upper memory address space.  This window onto the extra memory can
      be moved around thus giving access to it all but only in 16K pages.

      The technique is known as bank switching and the memory is referred
      to as Expanded memory.  The standard defining the mapping interface
      was originally known as LIM and there are two versions, 3.2 which
      limits you to four adjacent 16K byte pages in a 64K frame, and 4.0
      which allows you to use any 16K gap in upper memory as a page.  The
      latest definition is the Expanded Memory Specification (EMS) 4.0.

      2.11 Expanded Memory Managers
      -----------------------------

      A final twist to the senario is that the 386 processor has much
      better memory management and this permits software to be written
      which makes Extended memory (ie that above 1Mbyte) appear to be
      Expanded memory.  Such Expanded Memory Managers (EMM) can thus be
      used to fill all the gaps in the upper memory area.  Some also
      implement the XMS interface to upper memory.  The technique used
      requires the machine to be run is a special mode known as Virtual
      8086 and this can give interesting problems.

      Several products for 386 machines provide these features.  One of
      simplest is EMM386.SYS supplied by Microsoft either with DOS 4, or
      a smaller but inferior version with Windows 3, both of which
      provide a EMS 4.0 interface to the Extended memory.  More
      sophisticated systems are QEMM and 386MAX which combine a EMS 4.0
      interface, XMS and their own memory management which permits
      programs to be loaded into upper memory and also allows the EMS 4.0
      interface to be used.  DOS 5 in conjunction with HIMEM.SYS and its
      version of EMM386.SYS provides similar facilities.  Compaq machines
      have CEMM which is version of the early Microsoft software.  Any
      machine with an Expanded memory board and driver can also be used.

      Note that PC-DOS 4 does not include EMM386 and only the Windows
      and DOS 5 versions will run on a PS/2.


      2.12 LOADSYS Support of EMMs
      ----------------------------

      LOADSYS therefore provides the ability to interface onto an EMM
      which conforms to the LIM 3.2 or EMS/LIM 4.0 specification.  It can
      use any of the memory pages up to 1Mbyte via the /xp option which
      prevents any other programs from using this interface or /xl which
      allows LIM access as well.

      LOADSYS can also interface onto an XMS v2.0 interface which
      provides upper memory via the /xx option.

      Under DOS 5 where HIMEM.SYS is used with the CONFIG.SYS command
      DOS=UMB,HIGH the LOADSYS will automatically load programs into
      upper memory.

      On a 386 machine with a VGA most EMMs can supply 160K of upper
      memory.  With sophisticated systems such as QEMM this can increase
      to 192K and if graphics are not required then 240K is possible.
      The only exception in the PS/2 where the Advanced BIOS reduces all
      these values by 64K.  The total available memory is reduced by the
      low memory occupancy of the EMM which in the case of QEMM is
      2Kbytes and MS-DOS 4 EMM386 is 37Kbytes. The Windows 3 version of
      EMM386 which must be run alongside HIMEM uses only 10K bytes but
      note this does not support DMA so BICC 16 bit & MCA drivers wont
      work under it. This limitation is not shared by the DOS 5 version.

      When upper memory is available LOADSYS will use it by default.

      LOADSYS detects the use of Expanded, Extended and HMA memory by a
      program and release this memory when the program is unloaded. It
      will also note any extension to the chain of XMS drivers and reset
      it at unloading provided it is the first in the chain.

      2.13 Moving system code and data
      --------------------------------

      Various parts of the DOS system can be moved by LOADSYS and if
      upper memory is present this will be used.  The buffers specified
      in the CONFIG.SYS line BUFFERS= can be reduced to 1 and additional
      buffers allocated by LOADSYS.

      COMMAND.COM, the DOS Environment and the PS/2 Extended BIOS Data
      Area can also be moved into upper memory as can the buffer used for
      running a BAT file.  The latter avoids memory fragmentation when
      TSR's and Device Drivers are loaded and unloaded via BAT files.

      2.14 Summary
      ------------

      In summary LOADSYS is a set of tools for loading, unloading and
      positioning programs in memory.  It is very much a suck it and see
      process for the expert facilities since a lot depends on how a
      system has been programmed.  However once a methodology has been
      proven it should work reliably.



      3.  LOADSYS
      ===========

      3.1 Description
      ---------------

      The format of a call to LOADSYS is:

            LOADSYS  /options filename params

      which loads device driver or TSR called filename and runs it with
      parameters params.  /options are optional LOADSYS parameters and
      are described below.  They must precede the filename.  Filename can
      be a full pathname or a file in the current directory or a PATH
      directory.  Filename need not have an extension in which case the
      first file ending in .SYS, .COM or .EXE will be used. (Notes 1,5 & 32).

      The following options modify the action taken:

        ?  display this help information
        a  give additional information on what is being done (Note 2)
        h  display this help information
        l  list the TSRs/Device Drivers loaded by LOADSYS. (Note 2)
        n  TSRs/Device Drivers must always be referred to by name.
           (Note 5)
        r  redirect Interrupts to allow disable/enable and guarantee
           unloading will work. (Notes 3 and 14)
        s  silent flag - no reporting is done except for a warning
           or major error. The option /ss surpresses warnings and /sss
           supresses errors as well. (Note 30)
        u  unload filename or last TSR/Device Driver loaded. /ur unloads
           all LOADSYS programs or until a named program is found. (Note 4)
       xh  record current directory as the home directory. (Note 29)
      !xh  return to home directory.

      Examples are:

        loadsys ansi       Load ANSI.SYS if in a directory in the Path
        loadsys /u ansi    Unload ANSI.SYS
        loadsys /u         Unload last TSR or Device Driver to be loaded
        loadsys /l         List TSRs/Device Drivers loaded via LOADSYS
        loadsys /r ansi    Load ANSI.SYS so it can disable/enable and
                           guarantee unloading
        loadsys /d ansi    Disable ANSI.SYS but dont unload it
        loadsys /e ansi    Enable disabled ANSI.SYS
        loadsys /xh        Record current directory as home
        loadsys /!xh       Return to home directory


      The following options are for expert use only - some may crash the PC.
       is a hexadecimal number,  is a decimal number,  is a bit value
      (0,1 or x - x means dont care):

        *  the remaining text on the command is a comment. (Note 35)
        1  filename refers to the first program of this name to be
           loaded and not the last. (Note 5)
        2  force second copy of TSR or Driver to be loaded. (Note 12)
        3  do INT 3 prior to running program. (Note 16)
        b  reserve the last paragraph of memory for LOADSYS so
           DOS memory chain can be extended to upper memory. (Note 19)
       !b  reduce DOS memory chain to lower memory.
        b:  add memory at  size  paragraphs to DOS
           memory chain. (Note 19)
        d  disable a TSR/Device Driver - must have loaded with /r
        e  enable disabled TSR/Device Driver
        f  load program as free to be moved in memory. (Note 9)
        i  record interrupt  as chained into at a later date
           or not to be rediredted. (Note 14)
        lb list memory blocks. (Note 2)
        ld list memory blocks. (Note 2)
        lf list DOS file table. (Note 2)
        lp list program memory blocks. (Note 2)
        ls list system features. (Note 2)
        lx list XMS memory chain. (Note )
        m:            display value of memory byte :
        mw:           display value of memory word :
        m:=         reset memory byte : to 
        mw:=      reset memory word : to 
        m:=10#     reset memory byte : to
                              decimal value 
        mw:=10#  reset memory word : to
                              decimal value 
        m:=2# reset memory byte : to
                              bit values 
        mw:=2#   reset memory word : to
                                         bit values 
                                         (Note 15)
        o  override default options where o is one of:
         oa  place control block adjacent to program instead of other
             end of memory. (Note 10)
         ob  dont extend DOS memory chain into /xl, /xp or /xx supplied
             memory. (Note 23)
         od  force file to be loaded as a Device Driver. (Note 7)
         oe  force Environment copy to be released. (Note 8)
         of  dont Flush Device Driver before unloading. (Note 18)
         oh  load program into HMA if available. (Note 34)
         oi  use DOS internal loader instead of the one in LOADSYS.
             (Note 13)
         ok  keep LOADSYS where it is, dont move up memory when loading
             (Note 33)
         ol  force LOADSYS to load in lower memory despite upper memory
             being present. (Notes 6 and 19)
         om  dont take note of Expanded, Extended and HMA memory used
             by the program. (Note 32)



         oo  overlay program out if loads another program. (Note 28)
         oq  quit if a warning occurs. (Notes 31 and 6)
         or  dont enable ROM shadowing at unload or disable at loading.
             (Note 21)
         os  dont report Interrupt changes that dont point to me
             (Side Effects) (Note 17)
         ot  force file to be loaded as a TSR. (Note 7)
         ou  load only into upper memory (Note 6)
         ov  notify that program may switch to Virtual 8086 mode
             and switch off ROM shadowing. (Note 21)
        p, pw, p=, pw=, etc  display or reset
                        8 and 16 bit I/O Port  in same way as /m
                        (Note 15)
        q   squeeze memory by moving programs loaded with /f option down
            memory (up if /t) to remove gaps. (Note 9)
        t   load or move to top of memory. (Note 6)
        uh  unload home directory (/xh) record. (Note 29)
        w   Load program at segment  in memory. (Note 6)
        wg  Load program at a memory segment greater than or
                equal to . (Note 6)
        wl  Load program at a memory segment less than . (Note 6)
        xb increase number of DOS file Buffers to . (Note 24)
       !xb  decrease DOS file buffers to original CONFIG.SYS value
        xc  move COMMAND.COM. (Note 25)
        xd  allow DOS access to upper memory. (Note 19)
       !xd  reduce DOS access back to lower memory.
        xe  move DOS Environment. (Note 25)
        xf  remove memory fragmentation caused by LOADSYS (Note 20)
       !xf  allow memory fragmentation. (Note 20)
        xl  as xp but allow 4 pages for LIM access. (Note 23)
        xl as xp but allow  pages for LIM access.
       !xl  release upper memory if not in use.
        xp  use all memory pages upto 1Mbyte being offered by a
            Memory Manager via the EMS or LIM interface. (Note 23)
       !xp  release upper memory if not in use.
        xr  switch on ROM shadowing. (Note 22)
       !xr  switch off ROM shadowing.
        xt  move PS/2 Extended BIOS data area. (Note 26)
        xw  move DOS working buffer for BAT files. (Note 27)
        xx  use all memory  upto 1Mbyte being offered by a
            Memory Manager via the XMS interface. (Note 23)
        xx  use only  paragraphs of upper memory from XMS
       !xx  release XMS upper memory if not in use
        z Load program in block of memory size  (hex) paragraphs.
            (Note 11)


      Examples are:

        loadsys /d ansi    Disable ANSI.SYS but dont unload it
        loadsys /e ansi    Enable disabled ANSI.SYS
        loadsys /f ansi    Load ANSI.SYS so it can be moved in memory
        loadsys /q ansi    Move ANSI.SYS down memory filling any gaps
        loadsys /qt ansi   Move ANSI.SYS to top of available memory
        loadsys /z ansi    Load ANSI.SYS to determine minimum load size
        loadsys /t /z6B ansi   Load ANSI.SYS at top of available memory
                               in 6B paragraphs
        loadsys /z6B /w9000 ansi   Load ANSI.SYS at segment 9000 in
                                   6B paragraphs
        loadsys /z6B /wgC800 ansi  Load ANSI.SYS at segment greater
                                   than C800 in upper memory
        loadsys /2 vdisk   Load second virtual disk driver
        loadsys /i15 himem Load HIMEM.SYS and note INT 15 as this is
                                linked into after startup.
        loadsys /mw40:72=1234  Set memory word 40:72 to 1234
        loadsys /p2D4      Display value of I/O port 2D4
        loadsys /p2D4=2#1xxxxxx0 pc3270  Load PC3270.COM and reset I/O port
                           2D4 at unload by setting bit 7 and clear bit 0
        loadsys /xp        Use all upper memory provided by EMM.
        loadsys /!xp       Release all EMM provided memory
        loadsys /xl2       Use all available EMM memory leaving
                           2 pages for LIM access.
        loadsys /xx        Use all available XMS provided upper memory
        loadsys /xx1000    Use 64K XMS upper memory
        loadsys /bD000:1000  Add 64k memory block at D000 to DOS memory chain
        loadsys /xb20      Increase DOS buffers to a total of 20
        loadsys /xb20 /wgC800  Increase DOS buffers to a total of 20
                               using upper memory above C800.
        loadsys /xcou      Move COMMAND.COM but only if upper memory available
        loadsys /xf        Remove memory fragmentation prior to using Windows 3


      3.2 Notes
      ---------

      1.  LOADSYS acts just like the normal DOS command processor in
      searching for a command except that it adds the .SYS file extension
      onto its list of acceptable filenames and ignores .BAT files.  Thus
      it searches the current directory and then each directory defined
      by the PATH environment varaible.  When no extension is given to
      the filename each directory is searched first for .SYS extension,
      then a .COM and finally a .EXE.

      2.  LOADSYS lists the TSRs and Device Drivers in the order that
      they were loaded.  The /a option will give further details.  If the
      /u option is given without a filename then the programs will be
      unloaded in reverse order starting from the bottom of the list.

      If the /lb option is given then LOADSYS lists the memory blocks and
      gives details of their usage.  Adding /a shows blocks marked as the
      end of the DOS chain with <EOC> and summerises free blocks.  It
      also checks for blocks of memory (orphans) that have not been
      released when their owners terminated and indicates any LOADSYS
      control blocks that are still in Interrupt chains.  The RAL utility
      PCCONFIG with the /b option will also give additional details of
      the memory blocks but note that it gives the address of the 16 byte
      header block which precedes each memory block.  This is one less
      than the address given by LOADSYS which is the data.  Note that
      only PCCONFIG version 2.0 and later can interpret LOADSYS control
      blocks.

      If the /ld option is given LOADSYS lists the DOS Device Driver
      chain and the list of Block Device Drivers that are present - the
      latter are usually the various disc drives.  Adding the /a option
      in this case gives further details of the Block Device Drivers and
      is for diagnostic purposes.

      If the /lf option is given LOADSYS lists the DOS File Table which
      is the internal table of all the files that are open.

      If the /lp option is given LOADSYS lists only those memory blocks
      containing programs.

      If the /ls option is given LOADSYS lists the various relevant system
      features including available free memory.

      3.  LOADSYS normally notes the Interrupt vectors used by a program
      and repatches back the old values when the program is unloaded.
      However this is not possible if a further program has patched
      itself in to one of the interrupts.  LOADSYS gets round this by
      pointing the interrupts used by a program to its Control Block
      which redirects them to the correct place in the program.  When the
      program is unloaded the addresses in the Control Block are changed
      back to the orginal Interrupt values so the program can be deleted.
      The Control Block is only deleted when LOADSYS can make the correct
      changes to the Interrupt pointers in DOS and this is checked at
      each invocation.  The /lb option gives details of any such blocks.


      The Control Block is also used when a TSR or Device Driver is
      Disabled by LOADSYS since this involves removing the program from
      any Interrupt chains that it may be in.

      Note that this option will give problems with those programs that
      use an interrupt vector to see if they, or an auxiliary program,
      are already loaded.  Examples of this are DOS 2.1 PRINT.COM, the
      RAINBOW Communications software and Packet Driver ethernet drivers.

      4.  LOADSYS is unable to unload any program whose Interrupt vectors
      have been repatched unless it was loaded with the /r option.  It is
      also unable to unload any Block Device Driver that is not the last
      Block Device.

      LOADSYS will also refuse to unload a program when unrecorded
      Interrupt vectors in the range 0 - 7f point into it.  This could
      warn that a program has chained into an Interrupt after it was
      loaded, in which case use /i to specify the interrupt at load time,
      or that an interrupt has not been reset by a previous program and
      this program happens to be in the memory pointed to by the Interupt
      vector.  The option /uu will force unloading to continue.

      If the /ur option is given then all LOADSYS programs are unloaded
      starting from the last entry and going back up the list stopping
      only if a program had been loaded with the /n option or an error
      occurs.  If a filename is also given the unloading starts at the
      last program of that name to be loaded (unless the /1 option is
      given) and continues back up the list.  See also note 5.

      LOADSYS can also load and unload Expanded Memory Management (EMM)
      programs such as EMM386 and QEMM.  To unload these programs the
      option /uu must be given since this is quite dangerous and requires
      a Protection Violation to be generated.  This usually causes the
      EMM to give an error message and invite the user to respond with an
      indication of what to do next.  The usual reply is C to continue
      which will cause LOADSYS to finish off the unloading of the EMM.
      This does not work for 386MAX, since this appears to have no
      aborting facilities.  Note that LOADSYS will refuse to unload an
      EMM if the memory is still in use and the /!xp or /!xl option has
      usually to be given on a previous call to LOADSYS.

      5.  If no name is given LOADSYS will assume the last TSR or Device
      Driver it loaded is to be acted upon by the unload, squeeze or
      disable/enable options.  If however it was loaded with the /n
      option then this requires the program to be named before any action
      is taken.  Note that this provides a blocking mechanism for the /ur
      option (unload repeat).

      If a program has been loaded more than once then the last one
      loaded will be the one acted upon.  This can be overridden by the
      /1 option which causes the first one loaded to be acted on.  If the
      name ends in * then this acts as a wildcard and a match is done on
      any preceding characters.  Again it is the last matching entry in
      loading order that is acted upon unless the /1 option is given.
      Note that a name of just * will select the last program to be
      loaded.
 

      The /n option may be given on its its own and this forces the last
      program loaded by LOADSYS to be marked as requiring it to be named.
      Thus a BAT file which can optionally use TSRs or Device Drivers can
      ensure that a LOADSYS /ur will remove them all if it first issues a
      LOADSYS /n to protect any other programs LOADSYS has loaded.

      6.  LOADSYS will load the TSR or Device Driver by default in low
      memory (as per a normal program) and put the Control Block at the
      top of DOS memory.  The /t option reverses this but will leave
      significant gaps at the end of memory.  In this case the /z option
      will probably be required to specify the memory needed by the
      program.  Warning messages are given when LOADSYS makes assumptions
      regarding the positioning of the programs stack.

      If however upper memory has been made available via the /b /xp or
      /xl options or under DOS 5 via the DOS=UMB command in CONFIG.SYS
      then this will be used in preference to lower memory.  This can be
      overridden by giving the /ol option.  The /ou option forces loading
      in upper memory causing a failure if it is not present.

      The /oa option causes the Control Block to be loaded in the same
      area of memory as the program.

      If the /wg or /wl options are given the program and its Control
      Block are loaded within the address range specified. Note that the
      default settings are:

        /wg0000 /wlA000     ; range 0 to 640K

      unless upper memory is present when in the absence of the /ol
      option they are reset to:

        /wgA000 /wlFFFF     ; range 640K - 1M

      Note that /wg and /wl addresses are compared with the starting
      paragraph of a suitable free block so that any block spanning the
      address will be rejected for /wg and accepted for /wl.  Thus they
      are only useful where there is more than one free block available
      and the /w option should be used for more precise location.  The /t
      and /oa options operate as before.  If it is not possible to obtain
      sufficient memory in the area specified the limits are relaxed
      first, if it is available, to the whole of upper memory and then to
      the whole of lower memory.  The aim is to load the program if at
      all possible but this can be overriden by the /oq option which will
      quit the loading if it is not possible in the area specified.

      Finally if the /w option is given (without the g or l qualifier)
      then the program is loaded at that paragraph if free memory exists.
      This can be anywhere upto 1 Mbyte and could for example be an
      unused area of memory on a video card.  The Control Block and any
      Environment copy are located in their normal places according to
      any other relevent options such as /t /wl /wt or /ol.  The /oa
      option causes the Control Block to be placed in the same part of
      memory as the Environment. Failure to obtain the memory causes
      the load to abort.


      Giving the /a option will give further details including where
      things are loaded.

      See also note 33.

      7.  LOADSYS assumes a TSR program ends in .COM or .EXE and a Device
      Driver ends in .SYS.  Where this is not the case then the /od or
      /ot options may be used to override this feature.  Be warned that
      if you get it wrong then DOS will probably crash.

      Some TSRs also terminate as if they were normal programs (ie dont
      execute the DOS Terminate and Stay Resident exit) and leave their
      resident part in another block of memory.  The usual reason is when
      they want to leave their code at the top of memory.  LOADSYS can
      cope with this case provided the changed Interrupts point to the
      new program location.

      If this is not the case LOADSYS will report that the program is not
      a TSR and it will reset any interrupts that have been changed and
      thus leave the TSR disabled.  If the program actually was a TSR
      (and not a program infected by a virus) the solution is to give the
      /ot option but be warned this can give problems as LOADSYS may be
      unable to locate the programs memory block.

      8.  Some TSRs dont release their copy of the DOS Environment when
      they become memory resident - LOADSYS gives a warning when this is
      the case.  Where memory usage is critical LOADSYS can force the
      Environment to be released and it patches the program into the
      orginal copy.  Should the TSR subsequently access the Environment
      then it will work provided access is via the pointer in the
      programs PSP.  If however the program took a copy of the
      Environment pointer then it may fail as this will now point to an
      undefined area of memory.  Note that the Environment copy is often
      held in the same block for each program invocation so you could
      well get away with it.  Therefore use with care and be prepared for
      disaster - it usually only saves about 100+ bytes so is maybe not
      worth the risk.

      The normal place for loading the DOS Environment copy is below the
      program itself. Thus if a program frees its Environment copy this
      could leave a small gap. Whilst this will probably be reused by the
      next programs Environment copy this can be avoided by using the /oe
      option which will cause the Environment copy to be loaded at the
      other end of memory from the program.

      9.  The /q option squeezes memory by moving the TSRs or Device
      Drivers loaded with the /f option.  This implies the /r option so
      can only be used on programs which allow interrupts to be
      redirected or those that cannot are specified by /i.  Where the
      programs are moved to follows the same rules as program loading
      defined in Note 6.


      Thus if only low memory is in use then a program at the bottom of
      memory is moved down filling any gaps.  If the /t option is given
      then the program is moved up to the top of memory.  Conversely if
      the program was at the top of memory then the absense of the /t
      option would cause it to be moved to the bottom memory.  Finally
      for a program at the top of memory the /t option would move it
      higher up if possible.

      If upper memory was available then the program would be moved into
      that in accordance with same rules unless the /ol option was given.

      The /r option can also be given to repeat the operation in a
      similar manner to /ur for unloading programs.

      This option is VERY DANGEROUS and only works on a few programs such
      as ANSI.SYS and KEYB.COM.  It does not work on PRINT.COM,
      VDISK.SYS, CED.COM to name just a few.  It would be very dangerous
      to try this feature on a disc caching program!

      Note that some EXE programs have relocation tables which are
      implemented on loading. Since these are not recorded then moving
      such programs is not possible therefore the /f option is ignored
      and an error message given.

      10.  LOADSYS Control Blocks are usually located at the opposite end
      of memory to the program.  Thus for normal loading where the
      program at the bottom of memory the Control Block is at the top of
      memory (usually just below 640k) .  The /oa option forces the
      Control Block to be located at the same end of memory as the
      program ie adjacent to it.  This option is forced when loading
      programs in low memory under 4DOS or when fragmentation (option
      /xf) is not allowed.  See also Note 6.

      Control Blocks are allocated in paragraphs (16 bytes) and the
      minimum size is 28 bytes for a Device Driver using no interrupts.
      Recording an Interrupt takes 10 bytes, setting an I/O Port takes 4
      bytes and setting memory 6 bytes.  Thus a TSR with upto 2
      interrupts takes 48 bytes (3 paragraphs) and PRINT.COM with 9
      interrupts takes 8 paragraphs.

      11.  When a program is loaded in low memory it is initially given
      all the available free memory.  On termination when it becomes
      memory resident it releases what it does not need.  When loading a
      program at the top of memory (/t) or at a specified point (/w) the
      minimum memory specified in the program header is used.  This is
      frequently too small so /z can be used to give the correct value.
      Note the units are hex paragraphs.


      If /z is given without a value, ie followed by a space, LOADSYS
      will load the program as normal and then give an estimate of the
      minimum memory required to load it.  This is calculated by filling
      the memory with zeroes and then searching from the end looking for
      the first bytes that have been changed.  If this coincides with
      where the stack is located then this is passed over and further
      searching is done.  The value finally suggested includes an
      allowance for the stack.  There is no guarantee that this value is
      correct but it gives a starting value for tests.  Note that the
      loaded size shown on termination is the final memory requirement of
      the program and is usually smaller that the load size due to the
      initialisation code having been discarded.

      Thus the recommended procedure is to load the program with the /z
      option and no value in low memory which will give the estimated
      value for /z which can then be used for loading elsewhere in
      memory.  Note that if a program is run with too small a /z value
      then the program will overwrite the DOS memory block control header
      and crash the system with the message:  Memory Allocation Error.

      12.  LOADSYS will normally refuse to let you load a second copy of
      a TSR or Device Driver.  However for cases where this is valid such
      as a second Virtual Disc the /2 option overrides this restriction.

      13.  LOADSYS has its own internal loader which it uses instead of
      the one available via DOS.  The latter one may be accessed by using
      the /oi option and is provided just in case a bug in the LOADSYS
      loader prevents a program from loading or running.  It is not
      recommended that this option is used for loading programs at the
      top of memory (/t) as it needs a minumum of 64k bytes thus leaving
      a large gap.  It is also not able to load TSRs at a given point or
      with a given size and any failure is likely to crash the machine.

      14.  LOADSYS only records those interrupts that are changed when a
      program is first loaded.  However some programs such as HIMEM.SYS
      chain into Interrupt vectors after they have been loaded.  The /i
      option tells LOADSYS to also record these interrupts.

      In order to check for such cases LOADSYS checks when a program is
      unloaded to see if any unrecorded Interrupt vectors point to it.
      The check is made for 0 to 7F which is the normal range used.  If
      option /i is given without a value, ie followed by a space, then
      the range is increased to the maximum of FF which is 255 decimal.
      This will include Interrupt vectors which are used as data areas so
      can give spurious warnings.

      This /i option is also used to inform LOADSYS that the specified
      interrupt should be not be redirected when option /r is in force.
      This allows a mixture of redirected and direct interrupts.

      15.  When a program is unloaded by LOADSYS it may be necessary to
      close down a communications card or disable an interrupt in order
      to avoid crashing the machine.  The /p option allows this by
      specifying an I/O port and a byte value to be written (using OUT)
      to the port.  For a word port /pw is used.  The /m option does a
      similar job for memory where the : specifies the segment
      and offset of a byte.  To change a word /mw is used.


      The value may either be a hex or decimal (prefix 10#) number in
      which case the byte or word is completely changed or a binary
      pattern (prefix 2#) which allows selected bits to be changed.  In
      this instance values for  are 0 to clear the bit, 1 to set the bit
      and x for dont change.  If less than the total number of bits are
      specified then the least significant ones are assumed and the
      higher bits are left unchanged.

      An example of selected bit changes is to shut down an interrupt
      by resetting the interrupt mask on I/O port 21. Thus for IRQ4 this
      would be /p21=2#1xxxx.

      The /m or /p option is normally supplied when a program is loaded
      and is implemented when the program is unloaded.  However they can
      be given on any other call to LOADSYS when they will be implemented
      immediately.

      If no value is supplied for the /m or /p option then the memory or
      I/O port is read and displayed.  This can be useful in ascertaining
      the current value.  For the loading and unloading cases the value
      is displayed before and after the action so any change can be
      noted.  Thus either of the following will cause the value of the
      port 2F9 to be printed:

        /p2f9
        /p2f9=

      Note also that reading some ports clears the setting and this could
      adversely affect a program using that port.

      On AT and XT type machines the maximum port value is 3ff (hex), on
      PS/2s this is increased to ffff though there are a lot of instances
      where the first digit is ignored.  Thus in the case of the BICC
      board where the I/O port is 28c for the 16 bit varient and 828c for
      the PS/2 MCA version the /p828c would work in on both machines.

      Further details are given in the section of Worked Examples.

      16.  The /3 option causes LOADSYS to obey an INT 3 instruction
      prior to running a program.  Normally this will have no effect but
      when LOADSYS is being run under DEBUG or CODEVIEW this will cause
      an entry into the debugger.  Note that under DEBUG the IP register
      has to be reset to the next instruction before execution can
      continue.  The facility is mainly for the debugging of Device
      Drivers.

      For a Device Driver the INT 3 is obeyed just before the Strategy
      routine is executed.  When this is complete the Interrupt routine
      is called.

      For a TSR the next instruction is the jump into the program and the
      main use in this case is to debug LOADSYS by seeing if registers
      etc are correctly initialised.


      17.  If loading a program causes Interrupt vectors to be changed
      but the new value does not point to the program then this is termed
      a Side Effect.  An example is the loading of SMARTDRV.SYS which
      causes HIMEM.SYS to link into Interrupt 15. The option /os stops
      LOADSYS from giving a warning message. The /i option can be used to
      record the Interrupt so it is reinstated when the program is
      unloaded. See also note 32.

      18.  When unloading or disabling a Device Driver, LOADSYS
      implements a Flush to clear out any buffers.  This can be inhibited
      by the option /of.

      19.  If memory is available above 640K an alternative to using /w
      to load programs into it is to include it in the DOS memory block
      chain.  On all systems upto DOS 5 this is by the /b option which
      causes LOADSYS to extend the chain to 1Mbyte if it has not been
      done already and to include the specified block.  Since the chain
      must be contiguous the ROM and screen buffers must also be included
      and these are marked as being owned by the BIOS.  The option /lb
      will list the new situation.  Note that the calls that obtain upper
      memory (/xx, xp and /xl) normally invoke /b so it is only required
      to be used directly in special cases.

      In order to extend the DOS memory block chain above 640K LOADSYS
      needs to be able to use the last paragraph in memory. This is
      usually available but should it need to be reserved then the call:

        loadsys /b

      will keep it for later use by LOADSYS.

      Once upper memory has been defined via the /b option subsequent
      loading of programs will use this memory in preference to low
      memory unless the /ol option is given.

      Upper memory can be released once it is no longer occupied by the
      call:

        loadsys /!b

      The above should not be used under DOS 5 and later systems where
      the DOS=UMB command should be used in CONFIG.SYS to achieve the
      same effect.

      By default DOS knows nothing about this extra memory even though it
      has been added to the DOS memory chain.  However it can be told
      about it by the option /xd and this allows programs which ask DOS
      for further memory to access the upper memory.  The /!xd option
      switches this feature off.

      See also the /xx /xp and /xl options and Notes 20 and 23.


      20.  The /xf option attempts to remove the memory fragmentation
      that control programs such as Windows 3 object to.  All LOADSYS
      control blocks that are located at the top of low memory are moved
      down the memory.  All subsequent program loads in low memory force
      the /oa option and ignore the /t option to prevent further blocks
      being located in this area.  Fragmentation is automatically allowed
      again once the control program has been loaded.  The option /!xf
      also allows memory fragmentation to occur.

      The /xf option also works with DOS 5 when the DOS=UMB command is
      present in CONFIG.SYS and retrieves the 4K bytes of memory that is
      normally lost when Windows 3 is loaded. In this case it must be
      given just before WIndows 3 is loaded since it removes access to
      upper memory from the LOADHIGH command.

      The reason for /xf is twofold.  Firstly if lower memory is not
      exactly a multiple of 4K (eg.  exactly 640K) then Windows will
      reduce the lower memory to a value that is (eg 636K).  This can
      occur when the last paragraph is used to extend the memory chaining
      into upper memory by either LOADSYS or DOS5.

      Secondly the last block of memory must be the main free block and
      hence there must be no small blocks at the end of low memory.  If
      there are then Windows 3 will refuse to load complaining of memory
      fragmentation and DESQview will not show any upper memory that is
      in use.  Thus any such blocks created by LOADSYS must be moved
      either down low memory or into upper memory if it is available and
      this one of /xf actions.

      See the Usage Guidelines Section for further details.

      21.  LOADSYS has to take special action in order to unload an
      Expanded Memory Manager (EMM) so such programs have to be noted.
      This is usually done by checking whether the program has switched
      the PC into Virtual 8086 mode.  However some managers do not switch
      immediately and the /ov option is provided as an alternate way of
      notifying LOADSYS.

      The /ov option is assumed by default for any device driver with a
      name of the form EMM or ?EMM.

      On Compaq 386 machines most EMMs also switch off ROM shadowing thus
      increasing the available number of pages.  By default the ROM
      shadowing is switched back on when any program noted as being an
      EMM is unloaded by LOADSYS.  The /ov option also causes LOADSYS to
      switch off ROM shadowing when the program is loaded.  Giving the
      /or option overrides both these features.

      See also note 22

      22.  On Compaq 386 machines the /xr option will switch on the ROM
      shadowing and /!xr will switch it off. Note that when ROM shadowing
      is off then screen updating will be slower.


      23.  LOADSYS provides the ability to interface onto memory managers
      supporting the EMS/LIM or XMS interfaces and uses them to provide
      upper memory. These are not required under DOS 5 where the
      CONFIG.SYS command DOS=UMB,HIGH should be used.

      Where the EMS/LIM v4.0 or LIM 3.2 interface is available the option
      /xp takes all the pages and disables the LIM interface thus making
      the maximum amount of memory available.  Unless the /ob option is
      given it then does an internal call of the /b option to add this
      memory to the DOS memory chain.  Subsequent calls to LOADSYS will
      attempt to load programs in the memory unless the /ol (override
      lower) option is given when low memory is used.

      For all but LIM 3.2 managers if it is required to run programs
      which use the EMS/LIM interface then the /xl option should be used
      instead of /xp.  This by default gives four pages (64K) for LIM
      usage and uses the rest for program loading.  /xl can be optionally
      followed by a number indicating how many LIM pages to use.  Note
      that LOADSYS has to put its own small driver in front of the EMS
      manager in order to hide the extra pages that it has taken.
      Sophisticated users of LIM may thus get confused.

      Once programs have been unloaded by LOADSYS the upper memory can be
      released by the /!xp or /!xl options. These will abort if the
      memory is still in use. /!xp or /!xl must also be given before an
      Extended Memory Manager is unloaded.

      Alternatively if an XMS v2.0 interface manager is available which
      provides access to upper memory then this can be utilised via the
      /xx option.  This can optionally be followed by the the number of
      paragraphs to allocate otherwise all the available upper memory is
      obtained.  Again /!xx releases the memory.

      If it is required to obtain the available XMS from memory from a
      given area then use of the /a /xx options without any parameter
      will show the amount of memory that the XMS provides.  Then release
      the XMS memory (/!xx) and use this value as the parameter.  Note
      the value will be slightly less than expected since the XMS manager
      uses some paragraphs for its own memory management.

      /xx can only be used once (unless /!xx is used) except when a
      control program is present when it can be used from each DOS
      session subject to their being sufficient available memory.

      Note that the XMS management of upper memory is done by maintaining
      a chain of blocks in a similar way the DOS memory management. This
      has no impact on the use of upper memory unless it is accessed vi
      aboth the /xx and /xp or /xl options. In this case the EMS/LIM
      memory would normally have a one paragraph block on either side
      which was part of the XMS memory management. This would prevent the
      EMS/LIM free memory from being merged with any adjacent XMS
      provided free memory. LOADSYS gets round this by removing the
      EMS/LIM memory from the XMS memory chain and reinstating it when
      the memory if freed. The XMS memory chain can be listed by the /lx
      option.


      24.  DOS 3.x systems use 528 bytes of memory per buffer to
      impliment the BUFFERS parameter in CONFIG.SYS which occupies lower
      memory.  By giving a small BUFFERS value in CONFIG.SYS (eg
      BUFFERS=1) and using the LOADSYS option /xb followed by a decimal
      number then the additional buffers can be allocated from memory in
      accordance with same rules as for loading programs (Note 6).  No
      value or 0 gives the current buffer count.  Thus if upper memory is
      available via an EMM which has been loaded via CONFIG.SYS then
      buffers can be allocated from it by the AUTOEXEC.BAT having
      something something similar to:

        loadsys /xp             ; Use all memory pages above 640K
        loadsys /xb20           ; Increase DOS buffers to 20

      The number can be increased by giving a larger number and also can
      be reduced back to original CONFIG.SYS value by giving the /!xb
      option. The latter is actually very dangerous but appears to work -
      it should only be used for testing purposes. /!xb does not work
      when the buffers are not held on a DOS buffer chain.

      This option can also be used under DOS 5 but it is more efficient
      to use the facilities of DOS 5 to achieve the same effect.

      In DOS 3.x and DOS 5 systems the buffers are all held in one chain.
      DOS 4.x systems are different in that the buffers can be held in
      one or more chains and each chain is held within a 64K segment of
      memory.  DOS uses 532 bytes per buffer and tests suggests that it
      increases the number of chains when the minimum possible chain size
      is 15.  Thus at BUFFERS=30 it uses two chains and at 45 uses 3.

      The algorithm implemented by LOADSYS under DOS 4 is as follows and
      will only operate where DOS is not using EMS to hold its buffers.
      If the initial BUFFERS value is 1 then the first call of LOADSYS
      /xb creates a single chain of buffers containing the number
      specified.  Some of the 532 bytes of the original buffer is used
      for a control block but the bulk is unused.  Subsequent calls
      create additional chains of the same size as the first until the
      total buffer request is reached.  If the request is not modulo the
      chain size then the excess is ignored.

      If the initial BUFFERS value is greater than 1 then additional
      chains of the same size as the first are created. In this case the
      control block is appended to the front of the first buffer chain
      added by LOADSYS and contains enough space to add 31 chains.

      Thus differing combinations of chain size and number can be
      experimented with to achieve optimal performance.


      25.  The /xc and /xe options allow the current COMMAND.COM and the
      DOS Environment to be moved.  If a second COMMAND.COM is in use
      then this is acted upon rather than the primary copy.  Under DOS 5
      it is only possible to move the secondary copy.

      Where they move to conforms to the same rules as loading a program
      (Note 6).  Thus if upper memory is available via an EMM driver then
      both items can be moved to upper memory by the commands:

        loadsys /xc
        loadsys /xe

      Adding the option /a gives further details and /ou aborts the move
      if upper memory is not available.

      The /xe option also deletes the superfluous copy of the environment
      when a second COMMAND.COM is in use if the option /oe is given.

      Giving the /z option with a size in hex paragraphs allows the
      Environment size to be increased.  Thus when running a second
      COMMAND.COM (eg under Windows 3) the following will increase the
      size of the environment to 256 bytes (Hex 10 paragraphs).

        loadsys /xet /z10
        loadsys /xe

      This works by moving the environment up memory and increasing its
      size. The second call moves it back down memory and is optional.

      26.  On the PS/2 IBM introduced the Extended BIOS Data Area (XBDA)
      which is a 1Kbyte block at the end of normal memory which is
      outside the normal DOS memory management.  This can give problems
      for programs which convert the video ram into accessible memory.
      The /xt option allows it to be moved according to the same rules as
      for program loading defined in Note 6. Thus a call of:

        loadsys /xt

      would move the XBDA into low memory and free up the last 1Kbytes. A
      more useful sequence would be where an EMM driver has been loaded
      via CONFIG.SYS:

        loadsys /xt           ; move XBDA into bottom of low memory
        loadsys /xp           ; expand memory blocks to upper memory
                              ; alternatively /xx or /xl could be used.
        loadsys /xt           ; move XBDA again - by default it now goes
                              ; to upper memory. Frees 1K of low memory.

      It has been noted that some systems such as Windows 3 do not work
      if the XBDA is in upper memory.

      27. When DOS executes a BAT file it uses a 64byte buffer as a work
      buffer and if a TSR is being loaded then this memory leave a hole.
      Using the /xw option along with /t moves the buffer to the top of
      memory thus allowing the TSR to be loaded at the lowest possible
      point. If several BAT files have been CALLed then all working
      buffers are moved.


      28. /oo is an experimental option which allows LOADSYS to run a
      normal program and monitor if it loads a subsequent program. When
      this occurs the original program is swopped out of memory thus
      increasing the available memory. The most usual use is when a
      program has the facility to execute DOS commands.

      In order to keep the monitor that LOADSYS leaves in memory to a
      minimum size (currently 7K) several restrictions and limitations
      are imposed.  The program is always loaded in low memory using the
      DOS internal loader and it must not be a TSR.  No checks on changes
      to interrupts are done so no checks for a virus are made.  It is
      assumed that a subsequently loaded program makes no use of its
      parent.

      If the /oo option is used in any other circumstances then the
      machine will probably crash.

      LOADSYS implements /oo by monitoring the use of INT 21 function 4B
      (EXEC).  It only reacts to calls from the program it loaded.  It
      writes the program out to a file @loadsys.@@a in the current root
      directory (usually C:\) unless this file already exists when the
      last letter (a) is incremented until a unique name is found.  Thus
      several copies of LOADSYS using this feature can be run.  The file
      is deleted on termination but will be left if the system crashes.

      29. The /xh option records the current directory as the home
      directory and the /!xh option resets the current directory to the
      home directory. Multiple calls of LOADSYS with the /xh option will
      stack the various home settings and /!xh will remove the last
      entry. The option /!xhr will repeatedly implement the /xh settings
      until no more are present. The /uh option removes the last /xh
      record with implementing it and and /uhr option removes all such.

      30.  The /s option stops LOADSYS from giving out anything other
      than warning or major error messages.  /ss surpresses the warnings
      and /sss the major errors as well.  When the option /s is given
      then the name LOADSYS is placed in front of most warning and error
      messages in order to identify their source and the LOADSYS command
      that generated the error is displayed.

      31.  The /oq option is designed to allow a LOADSYS command to only
      be executed if conditions are right.  If a warning message is given
      about the options specified then the command is aborted.  Thus the
      general default that LOADSYS ignores option errors that are not
      fatal is overridden.  See note 6 for its effect on the /w option.

      32.  LOADSYS detects the use of Expanded, Extended and the HMA
      memory by a program when it is loaded and releases such memory when
      the program is unloaded.  It will also detect when a program chains
      into the XMS driver and will correct this at unloading.  The option
      /om overrides these features.  Option /a gives details of the use
      of such memory at loading, unloading and listing via the /l option.


      Note that LOADSYS is unable to detect if the memory is being used
      by the program being run or some other system that has been
      activated as a result. When this side effect occurs then the /om
      option must be given otherwise when the program is unloaded the
      memory belonging to the other system will be released and this
      will probably crash the PC.

      33.  LOADSYS relocates itself in memory in order to facilitate the
      loading of programs. Thus it moves itself to near the top of DOS
      memory when loading a program and the bottom of low memory. If the
      /t option has been given then it stays put. When loading in upper
      memory it also moves to the top of DOS memory just in case there is
      insufficient space in upper memory and the program is forced into
      lower memory. However there are some cases, such as TSRs which
      relocate themselves to the top of low memory, where LOADSYS gets in
      the way and this results a large block of free memory at the top
      of memory.

      To overcome this the /ok option tells LOADSYS to keep where it is,
      that is at the base of low memory. Note if this option is given
      with a normal TSR or Device Driver then a large block of free
      memory at the bottom of memory will result.

      The LOADSYS option /lb will display the memory usage.

      34. The option /oh asks LOADSYS to attempt to load a program into
      the High Memory Area and is of limited use. It is for experts
      only and may probably crash the PC.

      It will only work with .COM programs that do not change their
      segment register when accessing their data.  Thus .EXE programs and
      Device Drivers are excluded.  There must also be an XMS manager
      operating in order to control usage of the HMA (eg.  HIMEM.SYS) and
      the program must not chain into INT 21.  Note that only one program
      at a time may use the HMA.

      If the HMA is not in use LOADSYS claims it and loads the program
      starting at address FFFF0. Since this includes the last 16 bytes of
      the BIOS ROM area the first 16 bytes of the programs PSP will not
      be correct. Hence the program cannot terminate in the normal manner
      and so LOADSYS has to catch its exit by monitoring INT 21. Program
      loading can be done at addresses lower than this via the /w option
      but note that further parts of the PSP will be incorrect and
      bizzarre effects may occur. Most notable may be the loss of of all
      output from the porgram since the I/O handles are held in the
      second 16 bytes of the PSP.

      35.  The option /* indicates that the remainder of the command is a
      comment.  It cannot be used when loading programs as it would be
      included as a parameter to the program.  It is useful in BAT files
      to add comments to LOADSYS commands to remind you what they do and
      also if the /s option is given the comment is displayed as well as
      the LOADSYS command should an error occur.



      4. Usage Guidelines
      ===================

      The following give some general guidelines on usage. See also the
      Worked Examples Section.

      4.1 BAT files
      -------------

      The recommended method of using LOADSYS is via BAT files.  Thus the
      mechanism can be tested out and user finger trouble is avoided. The
      later section of worked examples illustrates most of the techniques
      described below.

      For programs that normally require a Device Driver in CONFIG.SYS a
      BAT file should be written which uses LOADSYS to load the Device
      Driver(s) before invoking the main program and then unloads them
      again afterwards.

      Similarily programs such as PRINT can be loaded via a BAT file
      which uses LOADSYS to run PRINT.COM.  To retrieve the memory used
      after printing has finished LOADSYS /U PRINT should do the trick.

      For systems which may load a variety of programs depending on
      options selected the following technique is available to simplify
      the unloading process.  The BAT file should have the line

        loadsys /sn

      before any programs are loaded which will set the /n option on last
      program loaded by LOADSYS (if any).  The /s avoids worrying the
      user with an error message if there is no previous LOADSYS loaded
      program.  The unloading can then be achieved by the line:

        loadsys /ur

      which will terminate unloading at the named entry.

      Whilst this technique is suitable for a system where all the
      LOADSYS calls are within one BAT file it is not satisfactory where
      say one BAT file loads a system and a second unloads it because the
      /ur takes no account of any more programs subsequently loaded via
      LOADSYS.  Examples are communications drivers where the kernel is a
      TSR and various utilities provide the communications applications.
      The solution is to name of the last program loaded in the unload
      call for example:

        loadsys /ur tsr_name

      where tsr_name is the last program in the group that is to be
      loaded and thus the first to be unloaded.

      LOADSYS sets the BAT file ERRORLEVEL at 0 if it is successful and 1
      if not.  No indication of ignored options is shown unless the
      option /oq is given when they cause LOADSYS to abort with an
      ERRORLEVEL of 1.


      4.2 Upper Memory
      ----------------

      Where upper memory is going to be used there is a choice of
      methodologies. EMMs such as QEMM and 386MAX have their own
      programs to allow loading in upper memory. However they lack the
      unloading facility so using LOADSYS can be advantageous. It is
      probably unwise to mix the two though tests with the LOADHIGH of
      DOS 5 and LOADSYS show they can both be used.

      Where there is the choice, such as with QEMM, accessing upper
      memory via the XMS interface (/xx) is better since this allocates
      in 4K byte units rather than the 16K byte pages used by EMS (/xp
      and /xl). It is thus usually able to obtain more upper memory.

      The option /ou is useful for moving items to upper memory since it
      can be used to abort the action if it does not exist. For example

        loadsys /xcou

      will move COMMAND.COM to upper memory but only if it exists.

      Similarily the /oq option can be used to be more selective in
      placing a program. Thus the command

        loadsys /wgE000 /oq program

      will fail to load if it cannot optain memory above E000 thus
      allowing a second choice of where to load it.  If the /oq had not
      been given then an attempt would have been made to load the program
      first in the whole of upper memory and then in lower memory.  Note
      that a BAT file could test the ERRORLEVEL reply to see if it had
      been successful - for example

        loadsys /sswgE000 /oq program
        IF ERRORLEVEL 0 GOTO OK
        loadsys /sswgD000 /oq program
        IF ERRORLEVEL 0 GOTO OK
        loadsys /sswgC000 /oq program
        IF ERRORLEVEL 0 GOTO OK
        loadsys /ss program
        :OK

      The IF ERRORLEVEL could actually be left out since LOADSYS will
      refuse to load the program a second time and would thus plough on.
      The /ss is included so as not to alarm the user.

      4.3 Control Programs (Windows 3 and DESQview)
      ---------------------------------------------

      LOADSYS is cogniscent of two control programs - Windows 3 and
      DESQview.  These provide a special challange in that on a 386
      machine they can provide several DOS sessions.  This gives problems
      with memory management since some memory is shared (eg that below
      the control program) and some is unique (usually from the end of
      the control program to 640k).  Where upper memory is used then this
      compounds the problems.


      Before running a control program all programs loaded via LOADSYS
      should have the /oa option and the command:

        loadsys /xf

      must be given. It is best given just before the control program is
      loaded but can be given earlier and subsequent program loadings
      or memory block relocations should conform.

      It can also be given to DOS 5 when the DOS=UMB command is present
      in CONFIG.SYS and will retrieve 4K bytes of lower memory that would
      normally be lost.  If it is not given then upper memory will also
      not be visible since the chaining has been broken.

      Note that if this command is not given and the control program
      loads successfully, as is the case with Windows 3.1, then LOADSYS
      will be unable to manage the memory correctly and failures may
      occur.

      After a control program has been loaded then LOADSYS can be used as
      before and fragmentation is allowed again.  The first use of
      LOADSYS will remove the fragmentation and reinstate the memory
      chain to its correct setting.  It is therefore recommended that
      every use of the DOS box commences with the command:

        loadsys /!xf

      The /lb option will show the shared and unique areas of memory and
      program loading/unloading and memory block relocation will be
      confined to the latter area.  If the /xl, /xp or /xx option is used
      to obtain upper memory then any shared upper memory will cease to
      be displayed and only that unique to the DOS session will be shown.

      The only exception is under Windows 3 when /xp or /xl has been
      used to obtain upper memory before Windows 3 is loaded. Because
      a unique copy of this area is supplied the upper memory cannot be
      displayed by /lb. Further upper memory can still be obtained via
      /xp or /xl. It is strongly recommended the /xx is used to obtain
      upper memory before loading Windows 3 as /xp or /xl supplied memory
      can cause it not to load.

      It has been noted that moving the Extended Bios Data Area (XBDA)
      on a PS/2 to upper memory causes Windows 3 to fail.

      Note that because DESQview does not maintain a unique list of
      Device Drivers for each DOS session that these cannot be loaded
      under DESQview. This was tested under v2.24 and if a later version
      implements this feature then the restriction can be overridden by
      giving the option /odod.


      4.4 Additional Features
      -----------------------

      LOADSYS can also be used to run normal programs.  It will complain
      that they are not a TSR but it will also note and correct any
      changes made to the Interrupts on the system.  It is thus useful
      for testing out any program that may change the Interrupts (such as
      one that may contain a virus).  The /i option is recommended so
      that all interrupts are checked but be warned that some of the
      higher interrupts are used as data areas so can confuse the issue.

      LOADSYS can be used to record the current directory when running
      a system requires a switch to another directory. Thus a BAT file
      to run such a system could be of the form:

        loadsys /xh
        .
        . commands to run system
        .
        loadsys /!xh

      LOADSYS can also be used to examine the value of I/O ports or
      memory locations and also to reset them if required.  Thus to
      examine the value of I/O port 28c you type:

        loadsys /p28c

      which will display the value,

        loadsys /p28c=04

      will reset the value to hex 04 and

        loadsys /p28c=2#xxxxx1xx

      will set bit 2.

      Be warned that reading an I/O port can reset its value in some
      cases - see the appropriate technical documentation.

      The features in LOADSYS to display various aspects of DOS can be
      quite useful. For example the /lb option which displays memory
      blocks gives an insight into what DOS (and also LOADSYS) does with
      memory.

      Option /lf shows which files are open and to what programs. Adding
      /a gives the whole table including all files opened and closed.

      The /xb option to increase the DOS file buffers can be useful for
      optimisation of how many DOS buffers are really needed by an
      application.  The number of buffers allocated can be increased
      between timing an application without having to reboot the machine.


      If the DOS Environment is too small then introducing new parameters
      via the SET command can fail with a message to that effect.  This
      can occur when either the Environment is too small or when a
      secondary Command processor is in use (eg when DOS is invoked from
      within a program) and the Environment is not expandable.  Moving
      the Environment using the /xe option along with the /z option to
      define a new size will increase the size of the Environment.  For
      example to increase the size to 512 bytes use:

        loadsys /xe /z20

      As this will leave a gap at the bottom of memory where the old
      Environment was it is best to move it to the top of memory and then
      back down again. If this was being done in a BAT file then the
      recommended sequence is:

        loadsys /xw /t         /* move DOS working buffer for BAT file up
        loadsys /xe /t         /* DOS Environment up memory
        loadsys /xe /z20       /* DOS Environment increased to 512 and
                               /* moved down memory

      5. Worked Examples
      ==================

      The following worked examples show the use of LOADSYS and cover
      most of the aspects of its use.  Note that if upper memory has been
      allocated via the /b, /xx, /xp or /xl options or under DOS 5 via
      the DOS=UMB command in CONFIG.SYS then this will be used in
      preference to low memory.

      5.1 PRINT
      ---------

      An example of a PRINT.BAT file could be:

        @ECHO OFF
        loadsys /ss2r print %1 %2 %3 %4 %5

      which appears to behave in an identical manner to the normal PRINT
      command due to the /ss option cutting out all the LOADSYS
      reporting.  The /r option should be omitted for DOS 2.x systems.
      The PRINT.BAT file must be held in a directory that precedes the
      directory holding PRINT.COM in the DOS PATH.  On a RAL system that
      would be C:\BAT.  Note that as LOADSYS ignores the PRINT.BAT entry
      when searching down the DOS PATH it will find PRINT.COM in a later
      directory.

      A further development on this is to load the PRINT.COM program at
      the top of memory.  To achieve this you have to include details of
      how much memory is required.  For an MS-DOS 3.3 system the LOADSYS
      command would be of the form:

        loadsys /ss2roatz25e print %1 %2 %3 %4 %5

      where the /z25e option reserves 25e paragraphs to load PRINT.COM.
      Note that this value was found by loading PRINT.COM with a /z
      parameter without a value and then experiment (which will crash the
      machine if the /z value is too low!).  The gain is that further
      TSRs can be loaded into low memory and the removal of PRINT.COM
      will not leave a gap in memory.  Note that the cost is an unused
      free area at the top memory which was required for the PRINT.COM
      initialisation code.

      To simplify the user interface an addition option /u can be
      introduced into PRINT.BAT in order to unload PRINT.COM.  The BAT
      file could then be of the form:

        @ECHO off
        IF %1.==/u. GOTO UNLOAD
        IF %1.==/U. GOTO UNLOAD
        loadsys /ss2roatz25e print %1 %2 %3 %4 %5
        GOTO EXIT
        :UNLOAD
        loadsys /uu print
        :EXIT

      And unloading can be achieved by the command:

        print /u


      5.2 Communications Cards
      ------------------------

      Care is needed when unloading communications drivers since the
      interrupt mechanisms of the card have to be disabled before the
      driver can be removed from memory. This section gives general
      details of how this is done and the following sections give
      specific examples.

      Two techniques are available.  The simplest is to disable the IRQ
      line that the card is using.  This is achieved by setting the
      appropriate bit in the interrupt mask which is accessed by I/O port
      21. This is done via the LOADSYS /p option as detailed in the
      following table.

        IRQ        LOADSYS Option
        ---        --------------

        IRQ3       /p21=2#1xxx
        IRQ4       /p21=2#1xxxx
        IRQ5       /p21=2#1xxxxx
        IRQ6       /p21=2#1xxxxxx
        IRQ7       /p21=2#1xxxxxxx

      On reloading the communications driver should reset the mask to
      enable interrupts again.  If it does not then the options above can
      be used with the 1xx..  set to 0xx..

      Whilst this technique often works it has some drawbacks. It will
      not work where the card has been given a pointer into the
      driver memory and examples of this are the BICC 16bit and MCA
      cards.  It is also not viable in cases where the IRQ is being
      shared by several devices as is possible on PS/2 machines.

      A more hygenic approach is to shut down the card itself and this
      requires some knowledge of the interface. This can be gleaned from
      technical documentation or from the code of a driver. A very good
      source for ethernet cards is the Packet Driver source code which is
      usually supplied with the driver. The routine RESET_INTERFACE does
      as its name suggests and mimicing this will achieve the desired
      result.

      The following table gives the options required to shut down certain
      cards. For the ethernet cards it is assumed they are set up for
      their default I/O port which is usually 300.

           Card           LOADSYS Option
           ----           --------------

         Asynch COM1        /p3f9=0
         Asynch COM2        /p2f9=0
         BICC 8bit          /mc000:10=0   (Assume memory mapped at C000)
         BICC 16bit/MCA     /p828c=4
         3COM 3C501         /p30e=80
         3COM 3C503         /p300=21 /p307=ff /p30f=0
         NE1000/2000        /p31f=ff


      It is usual to put the option onto the LOADSYS call which loads the
      communications driver and it will be implemented when the driver is
      unloaded. This appears to work very well but it is possible to
      envisage a case where the removal of TSRs that implement higher
      levels of the protocol could crash the machine as the driver tries
      to communicate with them in the brief interval before it too is
      terminated. Moving the option to the first TSR to be unloaded will
      aleviate this possibility.

      Most communications drivers can be run in upper memory, the main
      exception being the 16bit and MCA BICC cards whose drivers must be
      run below 640K.  For the BICC cards this limitation applies right
      up to the program that communicates with the driver.  This includes
      ETHDRV, BDNINT, PCNFS and the RAL LLCPKT program.  The option /ol
      on the LOADSYS calls will enforce this and since LOADSYS does not
      object to /ol if there is no upper memory then a BAT file to run in
      either situation should include it.

      The following examples illustrate these techniques and also
      highlight other problems.


      5.3 RAINBOW
      -----------

      The following details the loading and unloading of ethernets card
      with the RAINBOW software.

      Note that for reasons that are not quite clear RAINBOW is sometimes
      unable to reestablish contact with the RAL IBM host after the
      communications software has been unloaded and loaded again.
      Unloading and loading the whole system or just PINKBOOK usually
      cures the problem.

      5.3.1 RAINBOW over BICC 8 bit card using MPS v3
      +++++++++++++++++++++++++++++++++++++++++++++++

      A BAT file to run the RAINBOW software could be as follows:

        : RAIN.BAT - file to load and unload RAINBOW
        loadsys /sxh
        cd \isolan
        loadsys /s bdnldr
        loadsys /s /mc000:10=0 sfb
        loadsys /s!xh
        pinkbook
        rainbow
        pinkbook /de
        loadsys /suu sfb
        loadsys /suu bdnldr

      where the RAINBOW.EXE and PINKBOOK.EXE programs are held in a
      directory in the PATH and the card is at memory address C000.
      The LOADSYS calls with /xh and /!xh are optional and ensure that
      the user returns to the directory he started from.


      Tests suggest that you can get away without disabling the card
      interrupts.  Thus the /mc000:10=0 could be omitted from the SFB
      load to make a BAT file that was independent of the card location.

      Be warned that SFB modifies the entry point of BDNLDR when it loads
      so it is not possible to just load and unload SFB. Even if this
      modification is corrected and the card reset it has still been
      found necessary to reload it for reasons which are not understood.

      5.3.2 RAINBOW over BICC cards using MPS v4
      ++++++++++++++++++++++++++++++++++++++++++

      It is recommended that the BICC installation procedure is followed
      and the parameters for the calls of BICCARB, BICCDLC or MBICCDLC
      obtained from CONFIG.SYS.  Then by removing them from CONFIG.SYS
      and also the NETCON call in AUTOEXEC.BAT it is possible to load and
      unload the software.

      A BAT file to run the RAINBOW software on a 8bit card could be as
      follows:

        : RAIN.BAT - file to load and unload RAINBOW
        loadsys /sxh
        cd \isolink
        loadsys /s /m40:a1=0 biccarb.sys
        loadsys /s /mc000:10=0 biccdlc.sys ST=7 SA=4
        netcon
        loadsys /s!xh
        pinkbook
        rainbow
        pinkbook /de
        loadsys /suu biccdlc
        loadsys /suu biccarb

      where the comments in the previous example apply.  MPS v4 uses
      location 40:a1 to act as a flag and this needs to be reset to zero
      before the drivers can be reloaded.

      The 16bit and MCA varients are similar with the BICCDLC.SYS call
      replaced by the appropriate MBICCDLC.SYS call with the /ol
      parameter added to prevent loading in upper memory.  A general call
      suitable for both cards would be of the form:

        loadsys /sol /p828c=4 mbiccdlc.sys /D3 /IA ST=7 SA=4

      where the card is at the default I/O Port of 280 for 16bit and
      8280 for MCA, using IRQ10 and DMA channel 3. Note the 16 bit
      machine ignores the top 8 in the 828c port address.

      In this case disabling of interrupts is done by writing to I/O Port
      (8)28c where (8)280 is the base port setting.  The initial value of
      the port is 04 and after startup with IRQ10 being used the value
      becomes 73.  Resetting it to 04 at unload disables the interrupts.

      PINKBOOK appears to work satisfactorily from upper memory so if it
      could be put there by LOADSYS.  Note that it must be unloaded by
      the PINKBOOK /DE command and not by LOADSYS so that it can be
      restarted.


      5.3.3 RAINBOW over BICC cards using Packet Driver
      +++++++++++++++++++++++++++++++++++++++++++++++++

      An alternate and more memory efficient method of running RAINBOW is
      over a Packet Driver rather than MPS.  This is most relevent when
      using PADPORT to support a terminal emulator such as EMUTEK or
      MOS2.  Two BAT files are defined called for example PADLOAD.BAT and
      PADUNLOAD.BAT which load and unload the Rainbow programs.  PADLOAD
      is run first then the application (eg EMUTEK) is run.  When it is
      required to regain the memory used PADUNLOAD is called.  Beware of
      loading any other TSRs or Device Drivers after PADLOAD since they
      will prevent the memory being reclaimed.  For a 16bit and MCA BICC
      card set up as described previously and with the packet driver
      using Interrupt 62 the BAT files could be as follows:

        : PADLOAD.BAT - file to load PADPORT, PINKBOOK and Packet Driver
        loadsys /sn
        loadsys /sol /p828c=4 \isolink\mbdndpd.com 0x62 /I10 /D3
        loadsys /sol \isolink\llcpkt.com
        pinkbook
        padport


        : PADUNLOAD.BAT - file to unload PADPORT etc
        padport /de
        pinkbook /de
        loadsys /sur llcpkt

      where MBDNDPD.COM is the packet driver for the BICC 16bit and MCA
      cards and LLCPKT.COM is the RAL interface program to emulate the
      MPS interface over a packet driver.

      Both PINKBOOK and PADPORT could be loaded in upper memory via
      LOADSYS.

      5.3.4 RAINBOW over other cards using Packet Driver
      ++++++++++++++++++++++++++++++++++++++++++++++++++

      For any other card for which there is a Packet Driver available the
      line:

        loadsys /s /p828c=4 \isolink\mbdndpd.com 0x62 /I10 /D3

      should be replaced with the appropriate call and the /ol option can
      be omitted.

      Thus for the 3C501 card on default settings the line becomes:

        loadsys /s /p30e=80 \3com\3c501.com 0x62

      and for the 3C503 card it becomes:

        loadsys /s /p300=21 /p307=ff /p30f=0 \3com\3c503.com 0x62


      5.4 TCP/IP
      ----------

      5.4.1 PC/TCP over BICC cards
      ++++++++++++++++++++++++++++

      The following gives details of using LOADSYS with the PC/TCP
      package.  Other TCP/IP implementations would be supported in a
      similar manner.  Two BAT files are defined called for example
      IPLOAD.BAT and IPUNLOAD.BAT which load and unload the TCP/IP
      kernel.  IPLOAD is run first then the various applications (TN3270,
      FTP or MAIL) are run.  When it is required to regain the memory
      used IPUNLOAD is called.  Beware of loading any other TSRs or
      Device Drivers after IPLOAD since they will prevent the memory
      being reclaimed.  For a 16bit and MCA BICC card the BAT files could
      be as follows:

        : IPLOAD.BAT - file to load PC/TCP over MPS v4
        loadsys /sn
        loadsys /sxh
        cd \isolink
        loadsys /s    /m40:a1=0 biccarb.sys
        loadsys /sol  /p828c=4 mbiccdlc.sys /D3 /IA ST=7 SA=4
        netcon
        loadsys /s!xh
        loadsys /s    \pctcp\ipcust.sys
        loadsys /sn   \pctcp\ifcust.sys
        loadsys /snol \pctcp\bdnint


        : IPUNLOAD.BAT - file to unload PC/TCP
        c:\pctcp\inet unload
        loadsys /suur ifcust.sys

      Strictly speaking BDNINT need not be loaded by LOADSYS since the
      INET call is used to unload it. As is explained in section 8 there
      is a bug/feature in this system and using LOADSYS corrects for it.

      If a program such TN3270 or TNVT is used to access another system
      then it can be loaded by LOADSYS with the /oo option so that when
      Alt-F10 and !  are used to execute DOS commands the TNx program is
      swopped out of memory thus allowing larger programs to be run.
      Note that this inhibits any processing of output from the other
      system so no indication that a message has been received is given.

      To reduce memory usage the packet driver interface can be used and
      in this case the IPLOAD file changes to:

        : IPLOAD.BAT - file to load PC/TCP over BICC Packet Driver
        loadsys /sn
        loadsys /sol  /p828c=4 \isolink\mbdndpd.com 0x62 /I10 /D3
        loadsys /s    \pctcp\ipcust.sys
        loadsys /sn   \pctcp\ifcust.sys
        loadsys /snol \pctcp\ethdrv


      5.4.2 PC/TCP over other cards using Packet Driver
      +++++++++++++++++++++++++++++++++++++++++++++++++

      This is similar to the use with Rainbow.  Thus for the 3COM 3C503
      card the IPLOAD file now becomes:

        : IPLOAD.BAT - file to load PC/TCP over 3COM 3C503 Packet Driver
        loadsys /sn
        loadsys /s  /p300=21 /p307=ff /p30f=0 \3com\3c503 0x62
        loadsys /s  \pctcp\ipcust.sys
        loadsys /sn \pctcp\ifcust.sys
        loadsys /sn \pctcp\ethdrv


      5.5 PC-NFS
      ----------

      5.5.1 PC-NFS over Packet Driver
      +++++++++++++++++++++++++++++++

      The following BAT files will load and unload PC-NFS v3.0 over the
      Packet Driver interface for a BICC 16bit or MCA card.

        : NFSLOAD.BAT - file to load PC-NFS
        loadsys /sn
        loadsys /s     \nfs\sockdrv.sys
        loadsys /solof \nfs\pktd.sys
        loadsys /sol   /p828c=4 \isolink\mbdndpd.com 0x62 /I10 /D3
        loadsys /soe   \nfs\prt *
        loadsys /snol  /i5 /i8 /i17 /i20 /i21 /i27 /i2f /i30 /i31 ...
           ... \nfs\pcnfs.sys /b1
        loadsys /s ansi
        nfsrun
        loadsys /su

        : NFSUNLOAD.BAT - file to unload PC-NFS
        loadsys /suur pcnfs

      The example shows the use of the /of for PKTD.SYS in order to
      prevent LOADSYS doing a flush before unloading the program.  If not
      this will crash the machine.  Also noteworthy is that LOADSYS needs
      notifying of the fact that PCNFS uses several interrupts that dont
      get activated until NFSRUN is executed.

      PKTD.SYS and PCNFS.SYS must be in lower memory for BICC 16bit and
      MCA cards. They can be in upper memory for all other cards.

      The /oe on the PRT loading is because this program releases its
      Environment after loading. The /oe prevents this leaving a gap
      in memory by loading the Environment at the top of memory.

      Note the /b1 on PCFNFS.SYS to give all ones IP broadcast.  This
      MUST be included at RAL


      The optional loading and unloading of ANSI.SYS is to cater for
      NFSRUN which needs it for its highlighted output.  This avoids the
      need to have ANSI.SYS permanently loaded and saves 1600 bytes of
      memory. Under DOS 5 the option /r will have to be added when
      ANSI.SYS is loaded since it now uses INT 2F as does PC-NFS.


      5.5.2 PC-NFS over 3COM cards
      ++++++++++++++++++++++++++++

      The 3COM 3C503 card is run by a different driver when used with
      PC-NFS. The NFSLOAD file therefore becomes:

        loadsys /sn
        loadsys /s   \nfs\sockdrv.sys
        loadsys /s   /p300=21 /p307=ff /p30f=0 /ib /i1c \drivers\vecie5.sys
        loadsys /s   \nfs\nfsvec.sys
        loadsys /soe \nfs\prt *
        loadsys /sn  /i5 /i8 /i17 /i20 /i21 /i27 /i2f /i30 /i31 ...
           ... \nfs\pcnfs.sys /b1
        nfsrun


      5.6 PC3270
      ----------

      The IBM PC3270 emulator can be run from upper memory by use of the
      following commands:

        loadsys /s /p2d4=2#1xxxxxx0 \pc3270\pc3270 nr
        loadsys /s \pc3270\eehllapi

      The last line could be omitted if EEHLLAPI is not required.  If
      Alt-5 is used to close down PC3270 then LOADSYS will give a warning
      message and delete its control block at its next use.  A BAT file
      to perform both loading and unloading could be of the form:

        : PC3270.BAT - file to load and unload IBM PC3270 v1.x
        IF %1.==/u. GOTO UNLOAD
        IF %1.==/U. GOTO UNLOAD
        loadsys /s /p2d4=2#1xxxxxx0 \pc3270\pc3270 nr
        loadsys /s \pc3270\eehllapi
        GOTO EXIT
        :UNLOAD
        loadsys /suu eehllapi
        loadsys /suu pc3270
        :EXIT


      5.7 MOS2
      --------

      The RAL 3270 Emulator MOS2 can also be run from upper memory by use
      of LOADSYS. The MOS2.BAT file should be modified as follows to
      allow both loading and unloading:

        IF %1.==/u. GOTO UNLOAD
        IF %1.==/U. GOTO UNLOAD
        loadsys /sn
        loadsys /ss /ib /ic ns_async
        IF ERRORLEVEL 1 GOTO EXIT
        loadsys /ss keyio /d %2
        IF ERRORLEVEL 1 GOTO EXIT
        loadsys /ssos mos3270 %1
        GOTO EXIT
        :UNLOAD
        loadsys /suur mos3270
        :EXIT

      Note that MOS3270 gives side effects hence the /os option and
      NS_ASYNC uses the async ports and links into INTs C and B.  The /u
      option on KEYIO is best not used unless the memory manager reserves
      High Memory (the 64K above 1Mbyte). MOS2 can be either unloaded via
      the normal Alt-Ctrl-Esc mechanism or via the BAT file with the /u
      option. Note that in the first case LOADSYS will give a warning
      message when it is next invoked so say what has happened.


      5.8 Upper Memory
      ----------------

      The following example gives details of optimising the use of upper
      memory using QEMM 5.0 or 5.1 on a 386 type machine with VGA. It
      is not applicable to DOS 5 and later systems where the CONFIG.SYS
      command DOS=HIGH,UMB should be used along with HIMEM.SYS.

      CONFIG.SYS should contain something like the following and it is
      assumed that no EMS memory is going to me used:

        buffers=1
        country=044 437 C:\dos\country.sys
        shell=c:\dos\command.com c:\dos /e:512 /p
        device=c:\qemm51\qemm386.sys ram frame=none
        stacks=0,0
        files=40

      If EMS is required then the FRAME=NONE should be removed which will
      reduce the available upper memory by 64K.  The AUTOEXEC.BAT could
      then include the lines after the PATH has been setup:

        loadsys /sxwt
        loadsys /sxx
        loadsys /sxb25
        loadsys /sxcou
        loadsys /sxeou
        loadsys /soeoa c:\dos\keyb.com uk,,c:\dos\keyboard.sys

      This moves the BAT file working buffer out of the way, grabs all
      the upper memory, sets up 25 DOS file buffers, moves the
      COMMAND.COM and the ENVIRONMENT to upper memory and finally loads
      KEYB there.  This gives something of the order of 595K free memory
      on a DOS 3.3 system along with upwards of 160K of free upper
      memory, less 64K on a PS/2.  The /xc and /xe options have /ou to
      abort them if no upper memory exists.

      A subsequent call to a BAT file as shown previously could load a
      communications system in upper memory. Where these had a hot key
      switching system, such as in MOS2 or PC3270, you would have
      communications available all the time and no extra memory cost.


      6. Bugs/Features and Problem Programs
      =====================================

      The following list of programs need special action when being run
      under LOADSYS.  It is based upon limited experience so only covers
      a few cases at present.

      BICC ethernet cards - see worked examples above.

      ISOLINK.COM v1 - this was the first version of MBDNDPD, the packet
      driver for BICC 16bit and MCA cards.  It has a very interesting
      bug/feature.  In searching to find the BICC Ethernet card via the
      PS/2 POS system it uses I/O Port 96 to select which adapter card to
      interrogate and on exit leaves the register pointing to the card.
      Unfortunately there is a bug in the BIOS of early PS/2s in that
      when INT 15 Function C0 is used to find out details of the machine
      this gives the reply that the function is not implemented.  This is
      because it assumes I/O Port 96 is pointing to the motherboard.  The
      solution is to reset the value of I/O Port 96 to zero after
      ISOLINK.COM has been loaded as follows:

        loadsys /sp828c=4 isolink.com 0x62 /I10 /D3
        loadsys /sp96=0

      Known ramifications of this problem are that the PS/2 Mouse will
      not load and that XVIEW will only run once.

      CEMM.EXE and EMM386.EXE - These EMM drivers can be loaded but note
      that the full name must be given to avoid confusion with .COM
      varients and the /od option must be given to load it as a Device
      Driver.  For example:

        loadsys /od emm386.exe

      386MAX - this EMM cannot be unloaded by LOADSYS and although it
      claims to support XMS upper memory tests show this not to be the
      case so the /xx option does not work.

      The version of EMM386 supplied with Windows 3 does not support DMA
      therefore communications cards such as the BICC 16 bit and MCA
      versions will not work in a Windows 3 virtual machine. This
      does not apply to the DOS 4 and DOS 5 versions though reports
      suggest this may be machine dependent.

      HIMEM.SYS - use /i15 option as it chains into this interrupt after
      startup.

      The Novell NET5.COM program can be run from upper memory but when
      called with the /u option will not unload.  It should not be
      unloaded by LOADSYS as it will crash the PC.  Moving the DOS
      Environment into upper memory via LOADSYS /XE causes the LOGIN to
      the Novell Server to lock the machine.


      PC3270.COM - the IBM 3270 Emulator on an IBM PS/2 requires the IBM
      3278 card to be disabled at unloading with the option
      /p2d4=2#1xxxxxx0.  This is also recommended on all other machines
      but does not appear to crash the machine if ommitted.  The /oe
      option should not be used as this program accesses its copy of the
      environment.  As PC3270 has an unloading option LOADSYS should only
      be used when it is required to load PC3270 elsewhere in memory.

      Some programs object to the use of the top of the 640K memory by
      LOADSYS Control Blocks.  Examples are Windows 3.0 (but not 3.1) and
      any program that extends memory into the video area such as VIDRAM
      which comes with QEMM386.  Using the /oa option makes LOADSYS put
      the control block adjacent to the program.

      The NDIS protocol manager PROTMAN.SYS is a rather unusual device
      driver in that it leaves its code at the top of the lower memory
      where it can be overwritten by any other program. The assumption is
      made that device drivers using this facility such as NE2000.DOS and
      DIS_PKT9.DOS are loaded immediately after the protocol manager and
      dont trample on the top of memory. Under LOADSYS this is not the
      case and although things can be made to work it is best to say that
      this system cannot be loaded in this way. Experience also suggests
      that the NET START command must be given before any other TSRs are
      loaded with LOADSYS since it also appears to use the
      PROTMAN.SYS code at the top of memory.

      The following programs should either not be run with the /r option
      or have the offending interrupt (usually the one used to access the
      program) specifed by /i to make it direct.

      BICC Ethernet board drivers:  BICCDLC.SYS & MBICCDLC.SYS

      CEMM.EXE - Compaq 386 EMM driver

      PINKBOOK.EXE from the RAINBOW communications software.

      PRINT.COM under DOS 2.1.

      Any program that implements the Packet Driver interface for
      ethernet. Examples are MBDNDPD.COM and PBDNDPD.COM.

      Programs such as Sidekick which insist on being at the head of an
      Interrupt chain.

      The following are other problems with TSRs which have been noted:

      Most TSRs with the facility to unload themselves (eg PINKBOOK /DE)
      do not close the four files (CON input and output, AUX and PRN)
      that DOS opens by default for all programs.  The net result is that
      the DOS File Handle Cnt (as shown by LOADSYS /LF) is incremented at
      each load but not decremented at unload.  No problems have been
      noted as a result of this but on machines that are never switched
      off and TSRs are frequently loaded and unloaded things may go bang
      when the count goes negative.  LOADSYS unloads TSRs via DOS which
      thus closes any open files and resets the handle counters.


      Interesting side effects have been observed with TSRs written in C
      and compiled with the Microsoft C compiler. This is because
      programs produced by this compiler link into various interrupts
      when they are run and unlink at termination. A TSR therefore has to
      be very careful when it wishes to link into any of these
      interrupts. It is highly likely that the same problem will occur
      with Microsoft Pascal.

      This problem was highlighted by the TCP/IP BDNINT and ETHDRV
      programs which for reasons which are not quite clear link into INT
      0.  The program INET is used to unload them but this fails to reset
      INT 0 back to its correct value thus leaving it pointing into the
      memory the TSR has just vacated.  The reason appears to be that
      INET, being a C program, links into INT 0 and then commences to
      unload the TSR and unlink its interrupts including INT 0.  However
      when INET terminates it sets INT 0 back to its original value which
      points to the now unloaded TSR. The solution is to load such
      programs with LOADSYS and after they have been unloaded by INET the
      next call to LOADSYS will detect their removal and correct the
      problem.


      7. Differences in LOADSYS versions
      ==================================

      7.1 Version 1.0
      ---------------

      First release to prove that the techniques worked.

      7.2 Version 1.1
      ---------------

      This version will not work with programs that have already been
      loaded with version 1.0 as the LOADSYS Control Block format has
      been changed.  LOADSYS will detect this and abort.

      Before a program is unloaded LOADSYS now checks to see if any
      Interrupt Vectors in the range 0 to 7F point into its address
      space.  If so it refuses to do the unload just in case the program
      has linked into a further interrupt during its execution.  To
      override this limitation the option must be specified twice.  Thus
      the command

        loadsys /uu

      will force an unload to take place.  The /i option allows these
      extra interrupts to be noted.

      LOADSYS is now able to load EXE files that are Device Drivers -
      this did not work in v1.0.

      In order to add new facilities several options have had to be
      changed.  Aplogies for the inconvenience this causes.  The changes
      follow.

      Variants of the /o (override) option now replace the following
      options:

      /i - use internal DOS loader now /oi (override internal loader)
      /d - force loading as a device driver now /od (override device
           driver)
      /p - force loading as a TSR now /ot (override TSR)
      /v - force release of Environment now /oe (override Environment)
      /a - in conjuntion with loading a program to locate control block
           adjacent to the program now /oa (override adjacent)

      Other changes are:

      /ua - unload all programs now /ur (unload repeat) and the use of a
      filename in this context now indicates where to start unloading.

      /s - stop a program - now /d (disable)
      /g - go a stopped program - now /e (enable)

      /q - quiet now /s (silent)

      /m - move now /q (squeeze)


      The /a option now gives additional information at load and unload
      times.

      /i option introduced to allow extra interrupts to be noted

      /m: option introduced to display and reset memory values.

      /p option introduced to display and reset I/O Port values.


      7.3 Version 1.2
      ---------------

      There have been no changes to any options so BAT files for version
      1.1 should still work.

      LOADSYS now reserves one paragraph at the top of memory in order to
      facilitate the expanded memory facilities.

      The /os option to override side effects was incorrect in version
      1.1 in that it did not record any changed interrupts.

      LOADSYS can now load QEMM.SYS and also very large EXE files - this
      did not work on previous versions.

      The /b option can be used to extend the DOS memory management upto
      1Mbyte thus allowing upper memory to be easily utilised.

      LOADSYS can now unload any 386 Expanded Memory Manager such as QEMM
      and EMM386.  The only exception so far found is 386MAX which has no
      abort mechanism.  LOADSYS can also change the ROM shadowing on
      Compaq machines when loading such drivers or directly via the /xr
      option.  It can also interface to any LIM 3.2 or 4.0 driver and
      make use of the memory pages these provide via the /xp or /xl
      options.

      The /xb option allows the DOS file buffer chain to be extended and
      suppliments the BUFFERS parameter in CONFIG.SYS.

      The /xp option extends the memory management into memory above 640K
      provided by an Expanded Memory Manager. The /xl does the same but
      leaves a window whereby LIM memory may be accessed.

      The /xc option allows COMMAND.COM to me moved and the /xe does the
      same for the DOS Environment.

      The /xt option moves the PS/2 Extended BIOS Data Area

      The /xf option fiddles the DOS memory chain to hide the control
      blocks at the end of lower memory.

      The /ls option lists various relevent system features including
      available free memory.

      The /lb option to list memory blocks does not now show those blocks
      occupied by LOADSYS itself.


      7.4 Version 1.2a Bug Fix Release
      --------------------------------

      When no stack was specified it was incorrectly positioned after the
      program and not just before the end.


      7.5 Version 1.3
      ---------------

      Version 1.3 is incompatible with previous versions because it has
      changed its control block formats.  Therefore if you have already
      used a previous version to load programs this version will
      complain.  Just install v1.3 and reboot the machine to cure it.
      There are no major changes in the v1.2 options so these should
      still work with v1.3.

      The error and warning message system has been improved and the
      program name LOADSYS precedes all such messages when the /s option
      has been given  so you have a sporting chance of finding out from
      where it originated. As a result additional warning messages may
      appear compared with v1.2 - the /ss option will surpress them.

      The /xx option allows LOADSYS to obtain memory from XMS
      memory managers.

      The /xh option records the current directory as home and /!xh
      returns to it.

      The /xb option now sets up file buffers for DOS 4.x systems.

      The /xw option moves BAT file working buffers.

      The /xc and /xe options operate on the COMMAND.COM and Environment
      of the current COMMAND.COM not the top level one as previously.  A
      bug has been fixed in /xc whereby if EXIT was used on a moved
      COMMAND.COM it crashed the machine.

      The /z option with the /xe option sets the size of the DOS
      Environment if it is greater than the original value. This allows
      the Environment to be increased in size when running under
      a secondary COMMAND.COM.

      The /ou option forces loading in upper memory and causes a failure
      if it does not exist.

      The /oq option causes LOADSYS to quit if any option generates a
      warning message.

      The /xf option implementation has been changed but its function is
      still to remove memory fragmentation prior to loading control
      programs such as Windows 3 and DESQview.

      The /oo option allows programs to be overlayed out of memory when
      they run other programs.


      The /r option can now be given with /q so that all possible
      programs are moved in memory.

      Some checks for the restrictions of DR-DOS v5 have been added
      though the tests were by no means exhaustive.

      The worked examples have been updated to reflect the latest
      versions of software and to fix errors notably in the NFS example.

      A bug whereby filenames greater than eight characters corrupted the
      LOADSYS control block has been fixed.

      A bug whereby side effect interrupts were not recorded correctly
      has been fixed.

      A bug in the /wl option whereby it did not load large files below
      the given value has been fixed.

      A bug whereby LOADSYS when unloading a program gave a long list of
      interrupts that it claimed were pointing to the program has been
      fixed. It only occurred on certain BIOS' such as those found on
      Tandon PCA machines.

      A bug whereby LOADSYS failed under DESQview has been fixed.


      7.6 Version 1.3a Minor Enhancement and Bug Fix Release
      ------------------------------------------------------

      The restriction that the /r (Redirection) and /i (Interrupt)
      options cannot occur together has been removed. All Interrupts
      specified by /i will not be redirected. Hence a mixture of
      redirected and direct interrupts is possible.

      The /lb (List Memory Blocks) option is now better annotated.

      The option /lp lists the those memory blocks containing programs.

      /? now gives help

      A filename used to denote a program already loaded can end in a *
      to indicate a wildcard.

      If an attempt to unload a device driver failed because its
      interrupts were in use by another program then the driver was left
      disabled and a subsequent attempt to unload it crashed the machine.
      This is now fixed.

      There is a very obscure bug whereby in some cases when the /XC
      option has been used under DOS 4 to move COMMAND.COM an attempt
      to DEL a read only file crashes the machine. Fixed in v1.3b.

      Limited testing has been done under a beta release of DOS 5. It has
      not proved possible to implement XB (Increase DOS file buffers) and
      XC (Move COMMAND.COM) only works for Secondary command processors.
      The first limitation is fixed in v1.4, the second is permanent.


      The /xr and /!xr to switch Compaq ROM shadowing on and off stopped
      working in v1.3 because a reorganisation of the code somehow
      dropped the call to the routine. Now reinstated.

      There was a bug in the treatment of side effects (Interrupts
      changed on loading a program which did not point to it) in that
      they were never reset on unloading.  The meaning of the /os option
      has therefore been changed in that it now means dont report side
      effects.  In order to have the side effect reset back when a
      program is unloaded the interrupt must now be specified via the /i
      option.

      Some problems with TSRs that move themselves in memory after
      loading have been fixed. However this area is rather fraught so may
      continue to give problems.


      7.7 Version 1.3b Minor Enhancement and Bug Fix Release for DOS 5
      ----------------------------------------------------------------

      LOADSYS gave error messages when the DOS=UMB command was present in
      CONFIG.SYS. This is because this command extends the DOS 5 memory
      chain into Upper memory in the same way as LOADSYS does and
      confused the latter. Now fixed.

      When the DOS=HIGH command is present in CONFIG.SYS then DOS 5 is
      run with address wrap round disabled so that it can access the
      memory above 1Mbyte.  This is done by enabling the A20 address
      line.  When a program is loaded the A20 line is disabled thus
      allowing wrap round again.  This has been added to LOADSYS and
      programs such as BDNINT and ETHDRV which used wrap round will fail
      on previous versions.  Note there is a bug/feature in that any
      interaction with DOS disables wrap round on entering DOS but does
      not reinstate it on returning to the program.  Thus any program
      that uses wrap round after accessing DOS will fail.


      7.8 Version 1.4
      ---------------

      Version 1.4 is incompatible with previous versions because it has
      changed its control block formats.  Therefore if you have already
      used a previous version to load programs this version will
      complain.  Just install v1.4 and reboot the machine to cure it.
      There are no major changes in the v1.3 options so these should
      still work with v1.4 but note the next two paragraphs.

      V1.4 is fully compatible with DOS 5 but as this has required major
      recoding and hence possibly new bugs you are advised to keep a copy
      of v1.3 just in case.

      LOADSYS now detects the use of Expanded, Extended and the HMA
      memory by a program when it is loaded and releases such memory when
      the program is unloaded.  It will also detect when a program chains
      into the XMS driver and will correct this at unloading.  The option
      /om overrides these features.  The option /a will give details of
      the use of such memory at loading, unloading and listing via the /l
      option.  This is the most likely new feature to give problems in
      cases which worked with v1.3 and the /om option should revert back
      to the v1.3 method of working.

      The /oh option allows certain types of program to be loaded into
      the HMA.

      Details of Extended, Expanded and HMA memory availability are now
      displayed by option /ls. Adding /a gives further details.

      There was a bug in v1.3 whereby if upper memory was obtained via
      both the /xx and /xp options then this corrupted the XMS memory
      chain.  Subsequent use of the XMS gave incorrect values for the
      amount of free memory.  This has now been fixed.

      The XMS memory block chain in upper memory can be listed by the /lx
      option.

      The /ok option now keeps LOADSYS where it is when loading a
      program. This is only required where a program relocates itself to
      the top of low memory which is where LOADSYS would normally have
      moved itself to.

      Further problems with upper memory provided via the DOS=UMB command
      in CONFIG.SYS have been fixed.  The option /xf to remove
      fragmentation now works with the DOS=UMB command and retrieves 4k
      bytes of memory that is normally lost when Windows 3 is loaded.

      When operating with the /s option and an error or warning occurs
      LOADSYS now displays the command that generated it.

      The option /* allows a comment to be added to a LOADSYS command
      except where programs are being loaded.


      LOADSYS now works with the 4DOS command processor and has been
      tested with v3.02.  Despite claiming to be compatible with
      COMMAND.COM this program appears not to allow memory blocks at the
      top of low memory.  Thus loading with /t fails and the LOADSYS
      Control Block must always be adjacent to the program (option /oa).
      Thus when running under 4DOS the /t is not allowed and /oa is
      forced on program loading.


      7.9 Version 1.4a Bug Fix Release
      --------------------------------

      Some debugging calls to INT 3 were inadvertantly left in the code.
      Now removed.


      7.10 Version 1.4b Minor Enhancement Release
      -------------------------------------------

      There was a bug in the interpretation of a named program in that
      LOADSYS searched through the order in memory ignoring the loading
      order. This was only noticeable when upper memory was in use and
      programs with the same name, either identical or due to wildcard
      matching, were being accessed.

      Therefore the meaning of filename has been redefined and this
      is best explained by an example. Consider the command:

        loadsys /u filename

      where filename can be a complete name or may end in a * to give a
      wildcard match. This will unload the last program to match this
      name in the order of loading. ie. Last load, last unload. To change
      this to the first loaded program the option /1 should be given.
      This has the consequence that a filename of just * now unloads the
      last program to be loaded or, if /1 is given, the first.


      Bugs fixes in /l listing for upper memory and HMA indication have
      been made.

      Minor improvements to /lb listing made for orphan blocks.


      7.11 Version 1.4c Bug Fix Release
      ---------------------------------

      LOADSYS now refuses to load Device Drivers under DESQview.  This is
      because DESQview does not permit its DOS sessions to have different
      Device Driver lists.  This limitation does not apply to Windows 3.


      7.12 Version 1.4d Bug Fix Release
      ---------------------------------

      A bug whereby the entry in the PSP indicating the program owner
      was not set correctly for a TSR has been fixed.

      When the /oe option is given the Environment copy is always located
      in lower memory thus leaving the maximum upper memory free.


      7.13 Version 1.4e Bug Fix Release
      ---------------------------------

      A bug in the loading of multiple device drivers held within one
      program has been fixed. Each device driver is now individually
      initiated thus giving a Program Run and Program End message for
      each one. This is most noticable when loading a program containing
      a large number of devices such as SOCKDRV.SYS in PC-NFS.

      The option /sss now suppresses all messages including errors.


      7.14 Version 1.4f Minor Enhancement Release
      -------------------------------------------

      The /ls listing now gives the size of the Environment and how much
      space is has left in it.  LOADSYS is now kept at a new location.

      7.15 Version 1.4g Minor Enhancement Release
      -------------------------------------------

      The error message No Ctrl Blk is no longer given when LOADSYS is
      run in certain circumstances under Windows 3.

      Minor improvements to the /lb listings.

      7.16 Version 1.4h Bug Fix Release
      ---------------------------------

      LOADSYS now unloads CD-ROM device drivers correctly as it now
      clears the drive entry. Thus the device drive can be reloaded and
      it will use the same drive letter.

      Minor improvements have been made to the /lda and /ldaa listings.

      7.17 Version 1.4i Bug Fix Release
      ---------------------------------

      Version 1.4h introduced a bug whereby using the /h option crashed
      the PC. Now fixed.



      8. Support and Acknowledgements
      ===============================

      Some of the techniques used in LOADSYS were described in the
      program DEVADD by Giles Todd in .EXE Vol 4, Issue 3, August 1989.

      LOADSYS is supplied free and is supported for all users at RAL on
      IBM PC and PS/2 computers and near clones.  Users outside RAL are
      requested in the first instance to obtain copies and help from
      their normal support sources.

      Academic user support organisations may seek help from RAL but the
      latter will only be given on a 'best endeavours' basis.

      There is no support for other organisations other than by private
      arrangement with the author.

      Updates of the software may be obtained by anonymous FTP from
      FTP.CC.RL.AC.UK (currently 130.246.12.16).  It is held in a self
      extracting binary file loadxx.exe (xx being version number without
      a point - currently 14) in directory /pub/pcsupp/dos/loadsys.
      Executing the file will produce the program and documentation.

      Bug reports or problems should be reported, ideally by email, to
      Graham Robinson:

      E-mail: G.Robinson@RL.AC.UK   G W Robinson
      Tel UK: 01235 44 5636         Atlas Centre
      Int'l : +44 1235 44 5636      Rutherford Appleton Laboratory
      Fax   : 01235 44 6626         Chilton, Didcot, Oxon, OX11 0QX, UK
