Editing Conventional memory (section)

== DOS driver software and TSRs ==
Most standard programs written for DOS did not necessarily need 640&nbsp;KB or more of memory. Instead, driver software and utilities referred to as [[terminate-and-stay-resident program]]s (TSRs) could be used in addition to the standard DOS software. These drivers and utilities typically used some conventional memory permanently, reducing the total available for standard DOS programs.

Some very common DOS drivers and TSRs using conventional memory included:
* ANSI.SYS - support for color text and different text resolutions
* ASPIxDOS.SYS, ASPIDISK.SYS, ASPICD.SYS - all must be loaded for Adaptec [[SCSI]] drives and CDROMs to work
* [[DOSKEY|DOSKEY.EXE]] - permits recall of previously typed DOS commands using up-arrow
* LSL.EXE, E100BODI.EXE (or other network driver), IPXODI.EXE, NETX.EXE - all must be loaded for [[NetWare]] file server drive letter access
* MOUSE.EXE - support for mouse devices in DOS programs
* MSCDEX.EXE - support for CDROM drive access and drive letter, used in combination with a separate manufacturer-specific driver. Needed in addition to above SCSI drivers for access to a SCSI CDROM device.
* SBCONFIG.EXE - support for [[Sound Blaster 16]] audio device; a differently-named driver was used for various other sound cards, also occupying conventional memory.
* [[SMARTDRV.EXE]] - install drive cache to speed up disk reads and writes; although it could allocate several megabytes of memory beyond 640&nbsp;KB for the drive caching, it still needed a small portion of conventional memory to function.

As can be seen above, many of these drivers and TSRs could be considered practically essential to the full-featured operation of the system. But in many cases a choice had to be made by the computer user, to decide whether to be able to run certain standard DOS programs or have all their favorite drivers and TSRs loaded. Loading the entire list shown above is likely either impractical or impossible, if the user also wants to run a standard DOS program as well.

In some cases drivers or TSRs would have to be unloaded from memory to run certain programs, and then reloaded after running the program. For drivers that could not be unloaded, later versions of DOS included a startup menu capability to allow the computer user to select various groups of drivers and TSRs to load before running certain high-memory-usage standard DOS programs.

=== Upper memory blocks and loading high ===
As DOS applications grew larger and more complex in the late 1980s and early 1990s, it became common practice to free up conventional memory by moving the device drivers and TSR programs into upper memory blocks (UMBs) in the [[upper memory area]] (UMA) at boot, in order to maximize the conventional memory available for applications. This had the advantage of not requiring hardware changes, and preserved application compatibility.

This feature was first provided by third-party products such as [[QEMM]], before being built into [[DR&nbsp;DOS 5.0]] in 1990 then [[MS-DOS 5.0]] in 1991. Most users used the accompanying {{mono|[[EMM386]]}} driver provided in MS-DOS 5, but third-party products from companies such as [[QEMM]] also proved popular.

At startup, drivers could be loaded high using the "[[DEVICEHIGH (CONFIG.SYS directive)|DEVICEHIGH]]=" directive, while TSRs could be loaded high using the "[[LOADHIGH]]", "[[LH (DOS command)|LH]]" or "[[HILOAD]]" directives. If the operation failed, the driver or TSR would automatically load into the regular conventional memory instead.

[[CONFIG.SYS]], loading ANSI.SYS into UMBs, no EMS support enabled:
 DEVICE=C:\DOS\HIMEM.SYS
 DEVICE=C:\DOS\EMM386.EXE NOEMS
 DEVICEHIGH=C:\DOS\ANSI.SYS

[[AUTOEXEC.BAT]], loading MOUSE, DOSKEY, and SMARTDRV into UMBs if possible:
 LH C:\DOS\MOUSE.EXE
 LH C:\DOS\DOSKEY.EXE
 LH C:\DOS\SMARTDRV.EXE

The ability of DOS versions 5.0 and later to move their own system core code into the [[high memory area]] (HMA) through the [[DOS (CONFIG.SYS directive)|DOS]]=HIGH command gave another boost to free memory.

=== Driver and TSR optimization ===
Hardware expansion boards could use any of the upper memory area for ROM addressing, so the upper memory blocks were of variable size and in different locations for each computer, depending on the hardware installed. Some windows of upper memory could be large and others small. Loading drivers and TSRs high would pick a block and try to fit the program into it, until a block was found where it fit, or it would go into conventional memory.

An unusual aspect of drivers and TSRs is that they would use different amounts of conventional and/or upper memory, based on the order they were loaded. This could be used to advantage if the programs were repeatedly loaded in different orders, and checking to see how much memory was free after each permutation. For example, if there was a 50&nbsp;KB UMB and a 10&nbsp;KB UMB, and programs needing 8&nbsp;KB and 45&nbsp;KB were loaded, the 8&nbsp;KB might go into the 50&nbsp;KB UMB, preventing the second from loading. Later versions of DOS allowed the use of a specific load address for a driver or TSR, to fit drivers/TSRs more tightly together.

In MS-DOS 6.0, Microsoft introduced <code>[[MEMMAKER]]</code>, which automated this process of block matching, matching the functionality third-party [[DOS memory management|memory managers]] offered. This automatic optimization often still did not provide the same result as doing it by hand, in the sense of providing the greatest free conventional memory.

Also in some cases third-party companies wrote special multi-function drivers that would combine the capabilities of several standard DOS drivers and TSRs into a single very compact program that used just a few kilobytes of memory. For example, the functions of mouse driver, CD-ROM driver, ANSI support, DOSKEY command recall, and disk caching would all be combined together in one program, consuming just 1 – 2 kilobytes of conventional memory for normal driver/interrupt access, and storing the rest of the multi-function program code in EMS or XMS memory.