Área de memoria superior

La siguiente etapa en la evolución del DOS estuvo en el sistema operativo en sí mismo al hacerlo consciente de los bloques de memoria superior (UMB) y del área de memoria alta. Esto ocurrió con el lanzamiento de DR-DOS 5.0 en 1990. El gestor de memoria[1] incorporado en el DR-DOS, el EMM386.EXE, podía realizar la mayor parte de la funcionalidad básica del QEMM y programas comparables.

Donde el DR-DOS hizo puntos sobre la combinación de un más viejo DOS junto con el QEMM fue que el núcleo (kernel) en sí mismo del DR-DOS y casi todas sus estructuras de datos se podían cargar en memoria alta, más todos sus componentes asociados en UMBs. Esto dejó virtualmente libre toda la memoria baja, permitiendo configuraciones con hasta 620 KiB libres de los 640 KiB de la memoria convencional.

La configuración no era automática - UMBs libres tenían que ser identificados a mano, incluidos manualmente en la línea que cargaba el EMM386 en el CONFIG.SYS, y entonces los drivers, etc, tenían que ser cargados manualmente en UMBs desde el CONFIG.SYS y el AUTOEXEC.BAT. Esta configuración no era un proceso trivial. Mientras fue automatizada en gran parte por el programa de la instalación del QEMM, este programa sobrevivió en el mercado. de hecho, trabajó bien con el propio soporte del HMA y UMB del DR-DOS y continuó siendo una de las utilidades mejor vendidas para el PC.

Esta funcionalidad fue copiada por Microsoft con el lanzamiento del MS-DOS 5.0 en junio de 1991. Eventualmente, aún más estructuras de datos del DOS fueron sacadas de la memoria convencional, permitiendo hasta 631 KiB libres en ella.

Por 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 altamente estimada, permitiendo que las aplicaciones más grandes corrieran incluso en las configuraciones más complejas del PC. La técnica era crear primero tantos UMBs como fuera posible, incluyendo el remapeo de bloques de memoria asignados pero no necesarios, como el área de la pantalla monocromática en las máquinas con tarjetas de video en color. Entonces, muchos subcomponentes del DOS tenían que ser cargados en estos UMBs en justo la secuencia correcta para usar los bloques de memoria tan eficientemente como fuera posible, teniendo en cuenta el hecho de que algunos programas TSR requerían memoria adicional mientras se cargaban que era liberada una vez que la carga estaba completa. Afortunadamente había pocas dependencias entre estos módulos, así que era posible cargarlos en casi cualquier secuencia. Las excepciones eran tener con éxito el caché de los CD-ROM, la mayoría de los caché de disco tenían que ser cargados después de cualquier driver de CD-ROMs, y los módulos de la mayoría de los stack de redes tenían que ser cargados en cierta secuencia, esencialmente trabajando progresivamente a través de las capas del modelo OSI.

Con la adición de un manejador de multitarea de DOS como el DESQview de Quarterdeck, múltiples sesiones podían ser arrancadas al mismo tiempo, cada una con 600 KiB de memoria libre y todas compartiendo el acceso al DOS y sus drivers y facilidades asociados.

La creciente popularidad de Windows 3.0 hizo esto menos relevante, dado que las aplicaciones de Windows no eran afectadas por los límites de la memoria base del DOS, pero los programas de DOS corriendo bajo Windows (con Windows en sí mismo actuando como un manejador multitarea) todavía tenían ese inconveniente. Con el lanzamiento de Windows 95, todavía se convirtió en menos relevante, porque esta versión de Windows proporcionaba mucha de la funcionalidad de los drivers de dispositivo del DOS a las aplicaciones de DOS corriendo bajo Windows, como por ejemplo, soporte de CD, red y sonido. El mapa de memoria del DOSBox de Win95 fue automáticamente optimizado. Sin embargo, no todos los programas de DOS podían ejecutarse en este ambiente. Específicamente, los programas que intentaban cambiar directamente de modo real a modo protegido, no trabajarían puesto que esto no era permitido en el modo virtual del 8086 en el que estaban corriendo (de hecho, este punto está siendo ahora tratado por tecnologías de virtualización para los CPU x86 a punto venir (2006), como Vanderpool y Pacífica). Tampoco trabajaban en Windows 95, programas que trataban de hacer el cambio usando el API VCPI (que fue introducido para permitir a los programas DOS que necesitaran modo protegido entrar a este desde el modo virtual 8086 puesto en marcha por un manejador de memoria, según lo descrito arriba). Para cambiar al modo protegido solamente fue soportado el API DPMI.

En muchos sistemas incluyendo los modernos, es posible usar la memoria reservada para la sombra de la ROM de tarjetas de expansión como memoria superior. Muchos chipsets reservan hasta 384 KiB de RAM para este propósito, y puesto que este RAM generalmente está sin uso, puede ser usado como memoria superior de modo real con un driver de dispositivo específico para ello.

En las computadoras IBM XT era posible agregar más memoria a la tarjeta madre y usar un PROM decodificador de direcciones a la medida para hacer que aparezca en el área de memoria superior.[2] Como con la memoria superior basada en el 386 descrita arriba, el RAM adicional podía ser usado para cargar archivos de TSR, o como disco RAM.

La existencia del UMA y la barrera de los 640 KiB eran artefactos, características propias, del diseño del IBM PC y por lo tanto de cualquier computadora compatible con este, en otras palabras, todos los sistemas compatibles del IBM PC. Sin embargo, ha habido muchas otras computadoras basadas en Intel u otros procesadores x86 que no eran compatibles con el PC y no tenían así un Upper Memory Area y ninguna barrera de los 640 KiB.

• Administración de Memoria
• Especificación de memoria expandida
• Especificación de memoria extendida
• Gestión de memoria
• Memoria convencional
• Modo irreal
• Modo protegido
• Modo real
• Área de memoria alta