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 PC IBM o compatible. IBM reservó los 384 KB superiores del espacio de direcciones de 1024 KB de la CPU 8088 para BIOS ROM (o CSM de algún firmware UEFI ), Video BIOS , ROM opcionales , RAM de video, E/S asignadas en memoria y ROM BASIC obsoleta . [1]
Sin embargo, incluso con la RAM de vídeo, la BIOS ROM , la BIOS de vídeo , 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 superiores ( 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 antiguo más QEMM era que el núcleo de DR DOS y casi todas sus estructuras de datos podían cargarse en una memoria elevada. Esto dejó prácticamente toda la memoria base libre, permitiendo configuraciones con hasta 620 KB de 640 KB libres.
La configuración no era automática: las UMB libres debían identificarse manualmente, incluirse manualmente en la línea que cargaba EMM386 desde CONFIG.SYS , y luego los controladores, etc., debían cargarse manualmente en las UMB desde CONFIG.SYS y AUTOEXEC.BAT . Esta configuración no fue un proceso trivial. Como estaba en gran medida automatizado por el programa de instalación de QEMM, este programa sobrevivió en el mercado; de hecho, funcionó bien con el soporte HMA y UMB del propio DR DOS y llegó a ser una de las utilidades para PC más vendidas.
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 DOS de la memoria convencional, lo que permitió dejar libres hasta 631 KB de 640 KB. A partir de la versión 6.0 de MS-DOS, Microsoft incluso incluyó un programa llamado MEMMAKER que se utilizaba para optimizar automáticamente la memoria convencional moviendo programas residentes de terminación y estancia (TSR) a la memoria superior.
Durante un período a principios de la década de 1990, la optimización manual del mapa de memoria de DOS se convirtió en una habilidad muy apreciada, que permitía ejecutar las aplicaciones más grandes incluso en las configuraciones de PC más complejas. La técnica consistía en crear primero tantas UMB como fuera posible, incluida la reasignación de bloques de memoria asignados pero no utilizados, como el área de visualización monocromática en las máquinas en color. Luego, los numerosos subcomponentes de DOS debían cargarse en estos UMB en la secuencia correcta para utilizar los bloques de memoria de la manera más eficiente posible. Algunos programas TSR requirieron memoria adicional durante la carga, que se liberó nuevamente una vez que se completó la carga. Afortunadamente, había pocas dependencias entre estos módulos, por lo que era posible cargarlos en casi cualquier secuencia. Las excepciones fueron que para almacenar en caché los CD-ROM con éxito, la mayoría de los cachés de disco debían cargarse después de cualquier controlador de CD-ROM, y que los módulos de la mayoría de las pilas de red debían cargarse en una secuencia determinada, esencialmente trabajando progresivamente 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 dispositivo y luego cargar EMM386.EXE como dispositivo con la opción "RAM AUTO" que permite el acceso a UMA cargando controladores de dispositivo como dispositivo alto. Este método carga efectivamente los administradores de memoria fundamentales en la memoria convencional y luego todo lo demás en la UMA. Los programas convencionales que consumen mucha memoria, como MSCDEX, también podrían cargarse en la UMA de forma similar, liberando así una gran cantidad de memoria convencional.
La creciente popularidad de Windows 3.0 hizo que la necesidad del área de memoria superior fuera menos relevante, ya que las aplicaciones de Windows no se vieron directamente afectadas por los límites de memoria base de DOS, pero los programas de DOS que se ejecutan en Windows (con el propio Windows actuando como administrador multitarea) todavía lo eran. constreñido. Con el lanzamiento de Windows 95 , se volvió aún menos relevante, ya que esta versión de Windows proporciona gran parte de la funcionalidad de los controladores de dispositivos DOS para aplicaciones DOS que se ejecutan en Windows, como soporte para CD, red y sonido; El mapa de memoria de las cajas DOS de Windows 95 se optimizó automáticamente. Sin embargo, no todos los programas de DOS se pueden ejecutar en este entorno. Específicamente, los programas que intentaron cambiar directamente del modo real al modo protegido no funcionarían ya que esto no estaba permitido en el modo virtual 8086 en el que se estaba ejecutando. Además, los programas que intentaron realizar el cambio utilizando la API de la interfaz de programa de control virtual (VCPI) (que se introdujo para permitir que los programas de DOS que necesitaban el modo protegido ingresaran desde el modo virtual 8086 configurado por un administrador de memoria, como se describe anteriormente) no funcionaba en Windows 95. Sólo la API de la interfaz de modo protegido de DOS (DPMI) para Se admitió el cambio 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 usando memoria extendida , por lo que este método de proporcionar bloques de memoria superiores generalmente lo proporciona el administrador de memoria expandida (por ejemplo, EMM386 ). La interfaz de programación de aplicaciones para administrar los bloques de memoria superiores se especifica en la Especificación de memoria extendida .
En muchos sistemas, incluidos los modernos, es posible utilizar la memoria reservada para el seguimiento de la ROM de la tarjeta de expansión como memoria superior. Muchos conjuntos de chips reservan hasta 384 KB de RAM para este propósito y, dado que esta RAM generalmente no se utiliza, puede usarse 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 una PROM decodificadora de direcciones personalizada 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 .
AllCard, una unidad de administración de memoria adicional para computadoras de clase XT, permitía asignar la memoria normal al rango de direcciones 0xA0000-EFFFF, proporcionando hasta 952 KB para programas de DOS. Programas como Lotus 1-2-3 , que accedían directamente a la memoria de vídeo, necesitaban parches para manejar este diseño 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 dispositivo y TSR a los 384 KB superiores del espacio de direcciones de 1 MB , pero dejaba la cantidad de memoria direccionable (640 KB). ) intacto.
[…] Uno de los estímulos más importantes para agregar funciones fue la presión competitiva de
DRDOS 5.0
, del que nos enteramos por primera vez en la primavera de 1990. El conjunto de funciones de DRDOS nos llevó a agregar compatibilidad con
UMB
, intercambio de tareas y recuperación.
[…] Una cantidad considerable de la atención administrativa del equipo se desvió hacia nuevas funciones como software de transferencia de archivos, recuperación e instalación de red […] Finalmente, esta situación alcanzó un punto crítico a finales de julio de 1990 y, liderado por
BradS
, el equipo La gerencia pasó una ardua serie de reuniones para definir un cronograma y un proceso para cerrar el proyecto […](1+32 páginas)