Memoria convencional

En la gestión de memoria de DOS, la memoria convencional, también llamada memoria base, son los primeros 640 kilobytes de la memoria en IBM PC o sistemas compatibles. Es la memoria de lectura y escritura a la que el procesador puede acceder directamente para que la utilice el sistema operativo y los programas de aplicación. A medida que los precios de la memoria disminuyeron rápidamente, esta decisión de diseño se convirtió en una limitación en el uso de grandes capacidades de memoria hasta la introducción de sistemas operativos y procesadores que la hicieron irrelevante.

Barrera de 640 KB

La barrera de los 640 KB es una limitación arquitectónica de las PC compatibles con IBM PC. La CPU Intel 8088, utilizada en la PC IBM original, podía direccionar 1 MB (2²⁰ bytes), ya que el chip ofrecía 20 líneas de dirección. En el diseño del PC, la memoria inferior a 640 KB era para memoria de acceso aleatorio en la placa base o en placas de expansión y se denominaba área de memoria convencional. El primer segmento de memoria (64 KB) del área de memoria convencional se denomina memoria inferior o área de memoria baja. Los 384 KB restantes más allá del área de memoria convencional, denominada área de memoria superior (UMA), se reservaron para uso del sistema y dispositivos opcionales. UMA se utilizó para la ROM BIOS, memoria adicional de solo lectura, extensiones de BIOS para unidades de disco fijo y adaptadores de video, memoria del adaptador de video y otros dispositivos de entrada y salida mapeados en memoria. El diseño de la PC IBM original colocó el mapa de memoria del Adaptador de gráficos en color (CGA) en UMA.

La necesidad de más RAM creció más rápido que las necesidades del hardware para utilizar las direcciones reservadas, lo que resultó en que la RAM finalmente se asignara a estas áreas superiores no utilizadas para utilizar todo el espacio direccionable disponible. Esto introdujo un 'agujero' reservado; (o varios agujeros) en el conjunto de direcciones ocupadas por hardware que podrían usarse para datos arbitrarios. Evitar ese agujero era difícil y feo y no era compatible con DOS ni con la mayoría de los programas que podían ejecutarse en él. Más tarde, el espacio entre los agujeros se utilizaría como bloques de memoria superiores (UMB).

Para mantener la compatibilidad con sistemas operativos y aplicaciones más antiguos, la barrera de los 640 KB siguió siendo parte del diseño del PC incluso después de que el 8086/8088 fuera reemplazado por el procesador Intel 80286, que podía gestionar hasta 16 MB de memoria en modo protegido.. La barrera de 1 MB también se mantuvo mientras el 286 se ejecutara en modo real, ya que DOS requería el modo real que utiliza los registros de segmento y desplazamiento de manera superpuesta, de modo que no son posibles direcciones con más de 20 bits. Todavía está presente en las PC compatibles con IBM hoy en día si se ejecutan en modo real, como el que utiliza DOS. Incluso los PC Intel más modernos todavía tienen reservada una superficie de entre 640 y 1024 KB. Sin embargo, esto es invisible para los programas (o incluso para la mayoría de los sistemas operativos) en sistemas operativos más nuevos (como Windows, Linux o Mac OS X) que usan memoria virtual, porque no tienen ningún conocimiento de las direcciones de memoria física. En cambio, operan dentro de un espacio de direcciones virtuales, que se define independientemente de las direcciones RAM disponibles.

Algunas placas base cuentan con un "Agujero de memoria de 15 megabytes" opción requerida para ciertas tarjetas de video VGA que requieren acceso exclusivo a un megabyte en particular para la memoria de video. Las tarjetas de video posteriores que utilizan el bus AGP (espacio de memoria PCI) pueden tener 256 MB de memoria con un tamaño de apertura de 1 GB.

Memoria adicional

Una técnica utilizada en las primeras computadoras IBM XT era instalar RAM adicional en el rango de direcciones de la memoria de video y aumentar el límite hasta el inicio del Adaptador de pantalla monocromática (MDA). A veces se necesitaba software o un decodificador de direcciones personalizado para que esto funcionara. Esto movió la barrera a 704 KB (con MDA/HGC) o 736 KB (con CGA).

Los administradores de memoria en sistemas basados en 386 (como QEMM o MEMMAX (+V) en DR-DOS) podrían lograr el mismo efecto, agregando memoria convencional a 640 KB y moviendo la barrera a 704 KB (hasta el segmento B000, el inicio de MDA/HGC) o 736 KB (hasta el segmento B800, el inicio de CGA). En esta situación solo se podía usar CGA, porque la memoria de video del Adaptador de gráficos mejorado (EGA) estaba inmediatamente adyacente al área de memoria convencional debajo de la línea de 640 KB; No se pudo utilizar la misma área de memoria tanto para el frame buffer de la tarjeta de video como para programas transitorios.

Todas las computadoras' unidades de administración de memoria complementarias AllCard para XT y Chargecard para computadoras clase 286/386SX, así como ECM (memoria convencional extendida) de MicroWay.) el complemento permitió asignar la memoria normal al rango de direcciones A0000-EFFFF (hexadecimal), lo que proporciona 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 hardware.

También era posible usar la redirección de consola (ya sea especificando un dispositivo de consola alternativo como AUX: al invocar inicialmente COMMAND.COM o usando CTTY más adelante activado) para dirigir la salida y recibir entrada desde un terminal tonto u otra computadora que ejecute un emulador de terminal. Suponiendo que el BIOS del sistema aún permitiera que la máquina arrancara (lo que suele ser el caso al menos con los BIOS para PC integradas), la tarjeta de video podría retirarse por completo y el sistema podría proporcionar un total de 960 KB de memoria DOS continua para programas. cargar.

Un uso similar era posible en muchas computadoras compatibles con DOS pero no con IBM con un diseño de memoria no fragmentada, por ejemplo, sistemas de bus SCP S-100 equipados con su tarjeta CPU 8086 CP-200B y hasta dieciséis tarjetas de memoria SCP 110A. (con 64 KB de RAM en cada uno de ellos) para un total de hasta 1024 KB (sin tarjeta de video, pero utilizando la redirección de la consola y después de mapear la ROM de arranque/BIOS), el Victor 9000/Sirius 1 que admitía hasta 896 KB, o la PC Apricot con más memoria DOS continua para usar en su versión personalizada de MS-DOS.

Software de controlador de DOS y TSR

La mayoría de los programas estándar escritos para DOS no necesitaban necesariamente 640 KB o más de memoria. En su lugar, se podrían utilizar software de controlador y utilidades denominados programas residentes de terminación y permanencia (TSR), además del software DOS estándar. Estos controladores y utilidades normalmente utilizaban permanentemente parte de la memoria convencional, lo que reducía el total disponible para los programas estándar de DOS.

Algunos controladores de DOS y TSR muy comunes que utilizan memoria convencional incluyen:

• ANSI.SYS - soporte para texto de color y diferentes resoluciones de texto
• ASPIxDOS.SYS, ASPIDISK.SYS, ASPICD.SYS - todo debe ser cargado para las unidades de Adaptec SCSI y CDROMs para trabajar
• DOSKEY.EXE - permite recordar los comandos de DOS previamente escritos utilizando el trazado
• LSL.EXE, E100BODI.EXE (o otro controlador de red), IPXODI. EXE, NETX.EXE - todos deben ser cargados para NetWare acceso a la tarjeta del servidor de archivos
• MOUSE.EXE - soporte para dispositivos de ratón en programas DOS
• MSCDEX.EXE - soporte para el acceso a la unidad CDROM y la letra de la unidad, utilizado en combinación con un controlador específico del fabricante. Necesitado además de los controladores SCSI para acceder a un dispositivo SCSI CDROM.
• SBCONFIG.EXE - soporte para el dispositivo de audio Sound Blaster 16; un controlador de nombre diferente fue utilizado para varias otras tarjetas de sonido, también ocupando la memoria convencional.
• SMARTDRV.EXE - instalar caché de la unidad para acelerar lecturas y escrituras del disco; aunque podría asignar varios megabytes de memoria más allá de 640kb para el caché de la unidad, todavía necesita una pequeña parte de la memoria convencional para funcionar.

Como se puede ver arriba, muchos de estos controladores y TSR podrían considerarse prácticamente esenciales para el funcionamiento completo del sistema. Pero en muchos casos, el usuario de la computadora tenía que elegir entre poder ejecutar ciertos programas estándar de DOS o tener cargados todos sus controladores y TSR favoritos. Cargar la lista completa que se muestra arriba probablemente no sea práctico o imposible, si el usuario también desea ejecutar un programa DOS estándar.

En algunos casos, los controladores o TSR tendrían que descargarse de la memoria para ejecutar ciertos programas y luego volverse a cargar después de ejecutar el programa. Para los controladores que no se podían descargar, las versiones posteriores de DOS incluían una capacidad de menú de inicio para permitir al usuario de la computadora seleccionar varios grupos de controladores y TSR para cargar antes de ejecutar ciertos programas de DOS estándar de alto uso de memoria.

Bloques de memoria superiores y carga alta

A medida que las aplicaciones DOS crecieron y se volvieron más complejas a finales de los 80 y principios de los 90, se convirtió en una práctica común liberar memoria convencional moviendo los controladores de dispositivo y los programas TSR a bloques de memoria superior (UMB) en el área de memoria superior (UMA).) en el arranque, para maximizar la memoria convencional disponible para las aplicaciones. Esto tenía la ventaja de no requerir cambios de hardware y preservaba la compatibilidad de las aplicaciones.

Esta característica fue proporcionada por primera vez por productos de terceros como QEMM, antes de integrarse en DR DOS 5.0 en 1990 y luego en MS-DOS 5.0 en 1991. La mayoría de los usuarios utilizaban el EMM386 proporcionado en MS-DOS 5, pero los productos de terceros de compañías como QEMM también resultaron populares.

Al iniciar, los controladores se pueden cargar en alto usando la opción "DEVICEHIGH=" directiva, mientras que los TSR podrían cargarse en alto usando las teclas "LOADHIGH", "LH" o "HILOAD" directivas. Si la operación fallaba, el controlador o TSR se cargaría automáticamente en la memoria convencional.

CONFIG.SYS, cargando ANSI.SYS en UMB, no hay soporte EMS habilitado:

DEVICE=C:DOSHIMEM.SYS
DEVICE=C:DOSEMM386.EXE NOEMS
DEVICEHIGH=C:DOSANSI.SYS

AUTOEXEC.BAT, cargando MOUSE, DOSKEY y SMARTDRV en UMB si es posible:

LH C:DOSMOUSE.EXE
LH C:DOSDOSKEY.EXE
LH C:DOSSMARTDRV.EXE

La capacidad de las versiones 5.0 y posteriores de DOS de mover su propio código central del sistema al área de memoria alta (HMA) mediante el comando DOS=HIGH dio otro impulso a la memoria libre.

Optimización del controlador/TSR

Las placas de expansión de hardware podían usar cualquiera del área de memoria superior para el direccionamiento de ROM, por lo que los bloques de memoria superiores eran de tamaño variable y estaban en diferentes ubicaciones para cada computadora, dependiendo del hardware instalado. Algunas ventanas de memoria superior pueden ser grandes y otras pequeñas. Al cargar controladores y TSR en un nivel alto, se elegiría un bloque y se intentaría encajar el programa en él, hasta que se encontrara un bloque donde encajara, o iría a la memoria convencional.

Un aspecto inusual de los controladores y TSR es que usarían diferentes cantidades de memoria convencional y/o superior, según el orden en que se cargaron. Esto podría usarse con ventaja si los programas se cargaran repetidamente en diferentes órdenes y se verificara cuánta memoria quedaba libre después de cada permutación. Por ejemplo, si había una UMB de 50 KB y una UMB de 10 KB, y se cargaban programas que necesitaban 8 KB y 45 KB, los 8 KB podrían ir a la UMB de 50 KB, impidiendo que se cargara la segunda. Las versiones posteriores de DOS permitieron el uso de una dirección de carga específica para un controlador o TSR, para unir mejor los controladores/TSR.

En MS-DOS 6.0, Microsoft introdujo MEMMAKER, que automatizó este proceso de coincidencia de bloques, igualando la funcionalidad que ofrecen los administradores de memoria de terceros. Esta optimización automática muchas veces todavía no proporcionaba el mismo resultado que hacerlo a mano, en el sentido de proporcionar la mayor memoria libre convencional.

Además, en algunos casos, empresas de terceros escribieron controladores multifunción especiales que combinarían las capacidades de varios controladores DOS estándar y TSR en un único programa muy compacto que utilizaba sólo unos pocos kilobytes de memoria. Por ejemplo, las funciones de controlador de mouse, controlador de CD-ROM, soporte ANSI, recuperación de comandos DOSKEY y almacenamiento en caché de disco se combinarían en un solo programa, consumiendo sólo 1 a 2 kilobytes de memoria convencional para el acceso normal al controlador/interrupción, y almacenar el resto del código del programa multifunción en la memoria EMS o XMS.

Extensores de DOS

La barrera sólo se superó con la llegada de los extensores de DOS, que permitieron que las aplicaciones de DOS se ejecutaran en modo protegido de 16 o 32 bits, pero no se utilizaron mucho fuera de los juegos de ordenador. Con un extensor de DOS de 32 bits, un juego podría beneficiarse de un espacio de direcciones plano de 32 bits y del conjunto completo de instrucciones de 32 bits sin los prefijos de anulación de direcciones/operandos 66h/67h. Los extensores de DOS de 32 bits requerían compatibilidad con compiladores (compiladores de 32 bits), mientras que XMS y EMS trabajaban con un compilador antiguo destinado a aplicaciones DOS de 16 bits en modo real. Las dos especificaciones más comunes para extensores de DOS eran compatibles con VCPI y, posteriormente, DPMI con Windows 3.x.

El extensor de DOS compatible con DPMI más notable puede ser DOS/4GW, que se envía con Watcom. Era muy común en los juegos para DOS. Un juego de este tipo consistiría en un kernel DOS/4GW de 32 bits o un código auxiliar que carga un kernel DOS/4GW ubicado en la ruta o en el mismo directorio y un "ejecutable lineal" de 32 bits. Hay utilidades disponibles que pueden eliminar DOS/4GW de dicho programa y permitir al usuario experimentar con cualquiera de los varios, y quizás mejorados, clones de DOS/4GW.

Antes de los extensores de DOS, si un usuario instalaba memoria adicional y deseaba usarla en DOS, primero tenía que instalar y configurar controladores para admitir la especificación de memoria expandida (EMS) o la especificación de memoria extendida (XMS) y ejecutar programas. compatible con una de estas especificaciones.

EMS era una especificación disponible en todas las PC, incluidas las basadas en Intel 8086 e Intel 8088, que permitía que el hardware adicional entrara y saliera pequeños fragmentos de memoria (cambio de banco) del "modo real". #34; espacio de direcciones (0x0400–0xFFFF). Esto permitió que los programas DOS en modo real de 16 bits accedieran a varios megabytes de RAM a través de un agujero en la memoria real, normalmente (0xE000–0xEFFF). Entonces, un programa tendría que solicitar explícitamente que se acceda a la página antes de usarla. Estas ubicaciones de memoria podrían usarse arbitrariamente hasta que sean reemplazadas por otra página. Esto es muy similar a la memoria virtual paginada moderna. Sin embargo, en un sistema de memoria virtual, el sistema operativo maneja todas las operaciones de paginación, mientras que la paginación era explícita con EMS.

XMS proporcionó un protocolo básico que permitía que programas DOS de 16 bits cargaran fragmentos de memoria extendida 80286 o 80386 en memoria baja (dirección 0x0400-0xFFFF). Un controlador XMS típico tenía que cambiar al modo protegido para poder cargar esta memoria. El problema con este enfoque es que mientras estaba en modo protegido 286, no se podían realizar llamadas directas a DOS. La solución fue implementar un mecanismo de devolución de llamada, que requería reiniciar el 286. En el 286, esto fue un problema importante. El Intel 80386, que introdujo el "modo 8086 virtual", permitió que el kernel invitado emulara el 8086 y ejecutara el sistema operativo host sin tener que forzar al procesador a volver al "modo real". HIMEM.SYS 2.03 y superiores usaron el modo irreal en las CPU 80386 y superiores, mientras que HIMEM.SYS 2.06 y superiores usaron LOADALL para cambiar registros internos no documentados en el 80286, lo que mejoró significativamente la latencia de interrupción al evitar cambios repetidos de modo real/modo protegido.

Windows instala su propia versión de HIMEM.SYS en DOS 3.3 y superior. Windows HIMEM.SYS inicia el proveedor de servicios XMS (n-).0 en modo protegido de 32 bits para Windows Virtual Machine Manager, que luego proporciona servicios XMS (n-1).0 a cajas DOS y a la máquina Windows de 16 bits (por ejemplo, DOS 7 HIMEM.SYS es XMS 3.0 pero al ejecutar el comando 'MEM' en una ventana de Windows 95 DOS se muestra información de XMS 2.0).