En la gestión de memoria de DOS , el área de memoria superior ( UMA ) es la memoria entre las direcciones de 640 KB y 1024 KB ( 0x A0000–0xFFFFF) en una IBM PC o compatible. IBM reservó los 384 KB superiores del espacio de direcciones de 1024 KB de la CPU 8088 para ROM BIOS , BIOS de video , ROM opcionales , RAM de video, RAM en periféricos, E/S mapeada en memoria y ROM BASIC obsoleta . [1]
Sin embargo, incluso con la memoria RAM de vídeo, la ROM BIOS , la Video BIOS , las ROM opcionales y los puertos de E/S para periféricos, gran parte de estos 384 KB de espacio de direcciones no se utilizaban. A medida que la restricción de memoria de 640 KB se convirtió en un obstáculo cada vez mayor, se encontraron técnicas para llenar las áreas vacías con RAM. Estas áreas se denominaron bloques de memoria superior ( UMB ).
La siguiente etapa en la evolución de DOS fue que el sistema operativo utilizara bloques de memoria superior (UMB) y el área de memoria alta (HMA). Esto ocurrió con el lanzamiento de DR DOS 5.0 en 1990. [2] El administrador de memoria integrado de DR DOS, EMM386.EXE , podía realizar la mayor parte de la funcionalidad básica de QEMM y programas comparables.
La ventaja de DR DOS 5.0 sobre la combinación de un DOS más antiguo más QEMM era que el núcleo de DR DOS en sí y casi todas sus estructuras de datos podían cargarse en memoria alta. Esto dejaba prácticamente libre toda la memoria base, lo que permitía configuraciones con hasta 620 KB de los 640 KB libres.
La configuración no era automática: los UMB libres debían identificarse manualmente, incluirse manualmente en la línea que cargaba EMM386 desde CONFIG.SYS y, a continuación, los controladores y demás debían cargarse manualmente en los UMB desde CONFIG.SYS y AUTOEXEC.BAT . Esta configuración no era un proceso trivial. Como estaba en gran parte automatizada por el programa de instalación de QEMM, este programa sobrevivió en el mercado; de hecho, funcionó bien con el soporte de HMA y UMB del propio DR DOS y se convirtió en una de las utilidades más vendidas para PC.
Esta funcionalidad fue copiada por Microsoft con el lanzamiento de MS-DOS 5.0 en junio de 1991. [2] Con el tiempo, se sacaron aún más estructuras de datos de DOS de la memoria convencional, lo que permitió dejar libres hasta 631 KB de los 640 KB. A partir de la versión 6.0 de MS-DOS, Microsoft incluso incluyó un programa llamado MEMMAKER que se usaba para optimizar automáticamente la memoria convencional moviendo los programas residentes en modo de terminación y permanencia (TSR) a la memoria superior.
Durante un período a principios de los años 1990, la optimización manual del mapa de memoria del DOS se convirtió en una habilidad muy valorada, permitiendo que las aplicaciones más grandes se ejecutaran incluso en las configuraciones de PC más complejas. La técnica consistía en crear primero tantos UMB como fuera posible, incluyendo la reasignación de bloques de memoria asignados pero no utilizados, como el área de visualización monocromática en las máquinas a color. Luego, los muchos subcomponentes del DOS tenían que cargarse en estos UMB en la secuencia correcta para utilizar los bloques de memoria de la manera más eficiente posible. Algunos programas TSR requerían memoria adicional durante la carga, que se liberaba nuevamente una vez que se completaba la carga. Afortunadamente, había pocas dependencias entre estos módulos, por lo que era posible cargarlos en casi cualquier secuencia. Las excepciones eran que para almacenar en caché CD-ROM con éxito, la mayoría de las cachés de disco tenían que cargarse después de cualquier controlador de CD-ROM, y que los módulos de la mayoría de las pilas de red tenían que cargarse en una secuencia determinada, trabajando esencialmente de manera progresiva a través de las capas del modelo OSI .
Un método básico pero efectivo utilizado para optimizar la memoria convencional fue cargar HIMEM.SYS como un dispositivo, y luego cargar EMM386.EXE como un dispositivo con la opción "RAM AUTO", que permite el acceso a la UMA cargando los controladores de dispositivo como devicehigh. Este método carga de manera efectiva los administradores de memoria fundamentales en la memoria convencional y, a continuación, todo lo demás en la UMA. Los programas convencionales que consumen mucha memoria, como MSCDEX, también se pueden cargar en la UMA de manera similar, liberando así una gran cantidad de memoria convencional.
La creciente popularidad de Windows 3.0 hizo que la necesidad de la zona de memoria superior perdiera relevancia, ya que las aplicaciones de Windows no se veían afectadas directamente por los límites de memoria base de DOS, pero los programas de DOS que se ejecutaban bajo Windows (con Windows mismo actuando como un administrador de multitarea) seguían estando así restringidos. Con el lanzamiento de Windows 95 , perdió relevancia aún, ya que esta versión de Windows proporciona gran parte de la funcionalidad de los controladores de dispositivos de DOS a las aplicaciones de DOS que se ejecutan bajo Windows, como soporte de CD, red y sonido; el mapa de memoria de los cuadros de DOS de Windows 95 se optimizó automáticamente. Sin embargo, no todos los programas de DOS podían ejecutarse en este entorno. En concreto, los programas que intentaban cambiar directamente del modo real al modo protegido no funcionaban, ya que esto no estaba permitido en el modo virtual 8086 en el que se estaba ejecutando. Además, los programas que intentaban realizar el cambio utilizando la API de la Interfaz de programa de control virtual (VCPI) (que se introdujo para permitir que los programas DOS que necesitaban el modo protegido entraran en él desde el modo virtual 8086 configurado por un administrador de memoria, como se describió anteriormente) no funcionaban en Windows 95. Sólo se admitía la API de la Interfaz de modo protegido DOS (DPMI) para cambiar al modo protegido.
Los bloques de memoria superior se pueden crear asignando memoria extendida al área de memoria superior cuando se ejecuta en modo virtual 8086. Esto es similar a cómo se puede emular la memoria expandida utilizando memoria extendida , por lo que este método de proporcionar bloques de memoria superior generalmente lo proporciona el administrador de memoria expandida (por ejemplo, EMM386 ). La interfaz de programación de aplicaciones para administrar los bloques de memoria superior se especifica en la Especificación de memoria extendida .
En muchos sistemas, incluidos los modernos, es posible utilizar la memoria reservada para la replicación de la ROM de la tarjeta de expansión como memoria superior. Muchos chipsets reservan hasta 384 KB de RAM para este propósito y, dado que esta RAM generalmente no se utiliza, se puede utilizar como memoria superior en modo real con un controlador de dispositivo personalizado, como UMBPCI. [3]
En las computadoras IBM XT , era posible agregar más memoria a la placa base y usar un decodificador de direcciones personalizado PROM para que apareciera en el área de memoria superior. [4] Al igual que con la memoria superior basada en 386 descrita anteriormente, la RAM adicional podría usarse para cargar archivos TSR o como un disco RAM .
La AllCard, una unidad de administración de memoria adicional para computadoras de la clase XT, permitió que la memoria normal se asignara al rango de direcciones 0xA0000-EFFFF, lo que proporcionaba hasta 952 KB para programas DOS. Los programas como Lotus 1-2-3 , que accedían a la memoria de video directamente, necesitaban parches para manejar esta distribución de memoria. Por lo tanto, se eliminó la barrera de los 640 KB a costa de la compatibilidad del software. Este uso del área de memoria superior es diferente del uso de bloques de memoria superior, que se usaba para liberar memoria convencional moviendo controladores de dispositivos y TSR a los 384 KB superiores del espacio de direcciones de 1 MB , pero dejaba intacta la cantidad de memoria direccionable (640 KB).
[…] Uno de los estímulos más importantes para agregar características fue la presión competitiva de
DRDOS 5.0
, de la que nos enteramos por primera vez en la primavera de 1990. El conjunto de características de DRDOS nos llevó a agregar soporte
UMB
, intercambio de tareas y recuperación de archivos eliminados. […] Una cantidad considerable de la atención de la gerencia del equipo se desvió a nuevas características como software de transferencia de archivos, recuperación de archivos eliminados e instalación en red […] Finalmente, esta situación llegó a un punto crítico a fines de julio de 1990 y, liderada por
BradS
, la gerencia del equipo pasó una ardua serie de reuniones para definir un cronograma y un proceso para cerrar el proyecto […](1+32 páginas)