En la gestión de memoria de DOS , la memoria convencional , también llamada memoria base , son los primeros 640 kilobytes de la memoria de IBM PC o sistemas compatibles. Es la memoria de lectura y escritura directamente direccionable por el procesador para su uso por parte del 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.
La barrera de los 640 KB es una limitación arquitectónica de los PC compatibles con IBM PC . La CPU Intel 8088 , utilizada en el IBM PC original , era capaz de direccionar 1 MB (220 bytes ), ya que el chip ofrecía 20 líneas de dirección . En el diseño del PC, la memoria por debajo de los 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, llamada área de memoria superior (UMA), se reservaban para el uso del sistema y los dispositivos opcionales. UMA se usaba para la ROM BIOS , memoria adicional de solo lectura , extensiones de BIOS para unidades de disco fijas y adaptadores de video, memoria del adaptador de video y otros dispositivos de entrada y salida mapeados en memoria . El diseño del IBM PC original colocó el mapa de memoria del Adaptador de gráficos en color (CGA) en UMA.
La necesidad de más memoria RAM creció más rápido que la necesidad de hardware de utilizar las direcciones reservadas, lo que dio como resultado que la memoria 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 se podían utilizar para datos arbitrarios. Evitar un agujero de este tipo 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 superior (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 de la PC incluso después de que el 8086/8088 hubiera sido reemplazado por el procesador Intel 80286 , que podía direccionar 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 las direcciones con más de 20 bits. Todavía está presente en los IBM PC compatibles hoy en día si se ejecutan en modo real como el utilizado por DOS. Incluso las PC Intel más modernas todavía tienen reservada el área entre 640 y 1024 KB . [3] [4] Sin embargo, esto es invisible para los programas (o incluso la mayoría del sistema operativo) en sistemas operativos más nuevos (como Windows , Linux o Mac OS X ) que usan memoria virtual , porque no tienen conocimiento de las direcciones de memoria física en absoluto. En cambio, operan dentro de un espacio de direcciones virtuales, que se define independientemente de las direcciones RAM disponibles. [5]
Algunas placas base cuentan con una opción de "Memory Hole at 15 Megabytes" (agujero de memoria a 15 megabytes) necesaria para ciertas tarjetas de vídeo VGA que requieren acceso exclusivo a un megabyte en particular para la memoria de vídeo. Las tarjetas de vídeo posteriores que utilizan el bus AGP (espacio de memoria PCI) pueden tener una memoria de 256 MB con un tamaño de apertura de 1 GB .
Una técnica utilizada en las primeras computadoras IBM XT era instalar RAM adicional en el rango de direcciones de memoria de video y ampliar 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 elevó la barrera a 704 KB (con MDA/HGC) o 736 KB (con CGA). [6] [7]
Los administradores de memoria en sistemas basados en 386 (como QEMM o MEMMAX (+V) en DR-DOS ) podían lograr el mismo efecto, añadiendo 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). [7] Solo CGA podía usarse en esta situación, porque la memoria de video Enhanced Graphics Adapter (EGA) estaba inmediatamente adyacente al área de memoria convencional debajo de la línea de 640 KB; la misma área de memoria no podía usarse tanto para el búfer de cuadros de la tarjeta de video como para programas transitorios.
Las unidades de administración de memoria complementarias AllCard para XT- [8] [9] y Chargecard [10] de All Computers para computadoras de clase 286/386SX, así como la placa complementaria ECM (memoria convencional extendida) de MicroWay [11] permitieron mapear la memoria normal en el rango de direcciones A0000–EFFFF ( hexadecimal ), lo que proporcionó hasta 952 KB para programas DOS. Los programas como Lotus 1-2-3 , que accedían directamente a la memoria de video, necesitaban parches para manejar esta disposición de memoria. Por lo tanto, la barrera de los 640 KB se eliminó a costa de la compatibilidad del hardware. [10]
También era posible utilizar la redirección de consola [12] (ya sea especificando un dispositivo de consola alternativo como AUX: cuando se invocaba inicialmente COMMAND.COM o utilizando CTTY más adelante) para dirigir la salida y recibir la entrada de una terminal tonta u otra computadora que ejecutase un emulador de terminal . Suponiendo que el BIOS del sistema todavía permitiera que la máquina se iniciara (lo que suele ser el caso al menos con los BIOS para PC integrados), la tarjeta de video en una computadora llamada sin cabeza podría entonces eliminarse por completo, y el sistema podría proporcionar un total de 960 KB de memoria DOS continua para que se carguen los programas.
Un uso similar fue posible en muchas computadoras compatibles con DOS pero no con IBM con un diseño de memoria no fragmentado, por ejemplo, los sistemas de bus SCP S-100 equipados con su tarjeta de CPU 8086 CP-200B y hasta dieciséis tarjetas de memoria SCP 110A (con 64 KB de RAM en cada una de ellas) para un total de hasta 1024 KB (sin tarjeta de video, pero utilizando redirección de consola y después de mapear la ROM de arranque/BIOS), [13] el Victor 9000 / Sirius 1 que admitía hasta 896 KB, o el Apricot PC con más memoria DOS continua para ser utilizada bajo su versión personalizada de MS-DOS.
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 podían utilizar software controlador y utilidades denominados programas residentes de terminación y permanencia (TSR) además del software estándar de DOS. Estos controladores y utilidades normalmente utilizaban parte de la memoria convencional de forma permanente, lo que reducía el total disponible para los programas estándar de DOS.
Algunos controladores DOS y TSR muy comunes que utilizan memoria convencional incluyen:
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 tuvo que tomar una decisión: si podía ejecutar ciertos programas DOS estándar o tener cargados todos sus controladores y TSR favoritos. Cargar la lista completa que se muestra arriba probablemente sea poco práctico o imposible si el usuario también desea ejecutar un programa DOS estándar.
En algunos casos, era necesario descargar controladores o TSR de la memoria para ejecutar ciertos programas y volver a cargarlos después de ejecutar el programa. Para los controladores que no se podían descargar, las versiones posteriores de DOS incluyeron una función de menú de inicio que permitía al usuario de la computadora seleccionar varios grupos de controladores y TSR para cargar antes de ejecutar ciertos programas DOS estándar que consumen mucha memoria.
A finales de los años 1980 y principios de los años 1990, a medida que las aplicaciones DOS se hicieron más grandes y complejas, se convirtió en una práctica común liberar memoria convencional moviendo los controladores de dispositivos y los programas TSR a bloques de memoria superior (UMB) en el área de memoria superior (UMA) durante el arranque, con el fin de 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 incorporarse a DR DOS 5.0 en 1990 y luego a MS-DOS 5.0 en 1991. La mayoría de los usuarios usaban el controlador EMM386 incluido en MS-DOS 5, pero los productos de terceros de empresas como QEMM también demostraron ser populares.
Al iniciar, los controladores se podían cargar en alto usando la directiva " DEVICEHIGH =", mientras que los TSR se podían cargar en alto usando las directivas " LOADHIGH ", " LH " o " HILOAD ". Si la operación fallaba, el controlador o el TSR se cargarían automáticamente en la memoria convencional normal.
CONFIG.SYS , cargando ANSI.SYS en UMB, sin soporte EMS habilitado:
DISPOSITIVO=C:\DOS\HIMEM.SYSDISPOSITIVO=C:\DOS\EMM386.EXE NOEMASDISPOSITIVO ALTO=C:\DOS\ANSI.SYS
AUTOEXEC.BAT , carga MOUSE, DOSKEY y SMARTDRV en UMB si es posible:
LH C:\DOS\MOUSE.EXELH C:\DOS\DOSKEY.EXELH C:\DOS\SMARTDRV.EXE
La capacidad de las versiones DOS 5.0 y posteriores de mover su propio código central del sistema al área de memoria alta (HMA) a través del comando DOS =HIGH dio otro impulso a la memoria libre.
Las placas de expansión de hardware podían utilizar cualquiera de las áreas de memoria superior para el direccionamiento de la ROM, por lo que los bloques de memoria superior eran de tamaño variable y estaban en diferentes ubicaciones para cada computadora, dependiendo del hardware instalado. Algunas ventanas de memoria superior podían ser grandes y otras pequeñas. La carga de controladores y TSR en alto elegiría un bloque e 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 los TSR es que utilizan diferentes cantidades de memoria convencional y/o superior, según el orden en que se cargan. Esto se puede aprovechar si los programas se cargan repetidamente en diferentes órdenes y se comprueba cuánta memoria queda libre después de cada permutación. Por ejemplo, si hay un UMB de 50 KB y otro de 10 KB, y se cargan programas que necesitan 8 KB y 45 KB, los 8 KB pueden ir al UMB de 50 KB, lo que impide que se cargue el segundo. Las versiones posteriores de DOS permitieron el uso de una dirección de carga específica para un controlador o TSR, para que los controladores y los TSR se adapten mejor.
En MS-DOS 6.0, Microsoft introdujo , que automatizaba este proceso de coincidencia de bloques, igualando la funcionalidad que ofrecían los administradores de memoriaMEMMAKER de terceros . Esta optimización automática a menudo todavía no ofrecía el mismo resultado que hacerlo a mano, en el sentido de proporcionar la mayor cantidad de memoria convencional libre.
También en algunos casos, empresas de terceros escribieron controladores multifunción especiales que combinaban las capacidades de varios controladores DOS y TSR estándar en un único programa muy compacto que utilizaba sólo unos pocos kilobytes de memoria. Por ejemplo, las funciones de controlador de ratón, controlador de CD-ROM, compatibilidad con ANSI, recuperación de comandos DOSKEY y almacenamiento en caché de disco se combinaban en un solo programa, consumiendo sólo 1 o 2 kilobytes de memoria convencional para el acceso normal al controlador o a las interrupciones, y almacenando el resto del código del programa multifunción en la memoria EMS o XMS.
La barrera sólo se superó con la llegada de los extensores DOS , que permitieron que las aplicaciones DOS se ejecutaran en modo protegido de 16 bits o 32 bits , pero no se usaron mucho fuera de los juegos de computadora . Con un extensor DOS de 32 bits, un juego podí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 operandos/direcciones 66h/67h. Los extensores DOS de 32 bits requerían soporte de compilador (compiladores de 32 bits) mientras que XMS y EMS funcionaban con un compilador antiguo destinado a aplicaciones DOS de modo real de 16 bits. Las dos especificaciones más comunes para los extensores DOS eran VCPI y, más tarde, DPMI, compatibles con Windows 3.x.
El extensor DOS compatible con DPMI más notable puede ser DOS/4GW , que se entrega con Watcom . Era muy común en los juegos para DOS. Un juego de este tipo consistiría en un núcleo DOS/4GW de 32 bits o un stub que cargaba un núcleo 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 un programa de este tipo y permitir al usuario experimentar con cualquiera de los diversos clones de DOS/4GW, quizás mejorados.
Antes de los extensores DOS, si un usuario instalaba memoria adicional y deseaba usarla bajo DOS, primero tenía que instalar y configurar controladores para soportar la especificación de memoria expandida (EMS) o la especificación de memoria extendida (XMS) y ejecutar programas que soportaran una de estas especificaciones.
EMS era una especificación disponible en todos los PC, incluidos los basados en Intel 8086 e Intel 8088 , que permitía que el hardware adicional paginara pequeños fragmentos de memoria dentro y fuera ( conmutación de bancos ) del espacio de direccionamiento de "modo real" (0x0400–0xFFFF). Esto permitía que los programas DOS de modo real de 16 bits accedieran a varios megabytes de RAM a través de un agujero en la memoria real, normalmente (0xE000–0xEFFF). Un programa tendría que solicitar explícitamente que se accediera a la página antes de usarla. Estas ubicaciones de memoria podrían usarse arbitrariamente hasta que fueran 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 proporcionaba un protocolo básico que permitía a los programas DOS de 16 bits cargar 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 se estaba en modo protegido 286, no se podían realizar llamadas DOS directas. La solución alternativa fue implementar un mecanismo de devolución de llamada, que requería un reinicio del 286. En el 286, esto era un problema importante. El Intel 80386 , que introdujo el " modo 8086 virtual ", permitió que el núcleo invitado emulara el 8086 y ejecutara el sistema operativo host sin tener que forzar realmente al procesador a volver al "modo real". HIMEM.SYS 2.03 y versiones superiores usaban el modo irreal en las CPU 80386 y versiones superiores, mientras que HIMEM.SYS 2.06 y versiones superiores usaban LOADALL para cambiar registros internos no documentados en el 80286, mejorando significativamente la latencia de interrupción al evitar cambios repetidos de modo real/modo protegido. [14]
Windows instala su propia versión de HIMEM.SYS [15] en DOS 3.3 y versiones superiores. Windows HIMEM.SYS lanza el proveedor de servicios XMS (n).0 en modo protegido de 32 bits para el Administrador de máquinas virtuales de Windows, que luego proporciona servicios XMS (n-1).0 a los equipos 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 DOS de Windows 95 se muestra información XMS 2.0).
Nótese la brecha en el rango de direcciones de memoria desde la página 9F000 a la página 100000...
IBM
también reintrodujo limitaciones de memoria que había evitado específicamente al diseñar la CPU 8086 [tarjeta]. Para
las computadoras S-100
, una alternativa de bajo costo al uso de una terminal de computadora normal era usar una tarjeta de video. Sin embargo, la tarjeta de video usaba parte del espacio de direcciones de memoria. La ROM de arranque normalmente también usaría espacio de direcciones. Los sistemas SCP fueron diseñados para usarse con una terminal, y la ROM de arranque podía deshabilitarse después del arranque. Esto hacía que todo el espacio de direcciones de memoria de 1 MB estuviera disponible para RAM. IBM, por otro lado, había limitado el espacio de direcciones en su
PC
a 640 KB de RAM debido al video y la ROM de arranque/BIOS. Esta limitación se ha denominado la "barrera DOS 640K", pero no tenía nada que ver con
DOS
.
Microsoft
aprovechó al máximo la capacidad del sistema
SCP
. En 1988, años después de que SCP se cerrara, todavía utilizaban el sistema SCP para una única tarea que podía realizar ("vincular el enlazador"). Su máquina estaba equipada con 1 MB de RAM completo (16 de las tarjetas de 64 KB). Esa máquina no pudo retirarse hasta que se desarrollaron herramientas de software de 32 bits para el microprocesador
386
de
Intel
.