En la gestión de memoria DOS , el área de memoria alta ( HMA ) es el área de RAM que consta de los primeros 65520 bytes por encima del megabyte en una computadora IBM AT o compatible.
En modo real , la arquitectura de segmentación de los procesadores Intel 8086 y posteriores identifica las ubicaciones de memoria con un segmento de 16 bits y un desplazamiento de 16 bits, que se resuelve en una dirección física mediante (segmento) × 16 + (desplazamiento). Aunque está pensado para direccionar solo 1 megabyte (MB) (2 20 bytes) de memoria, segmento:desplazamiento se dirige a FFFF:0010la memoria de referencia más allá de 1 MB ( FFFF0 + 0010 = 100000). Por lo tanto, en un procesador 80286 y posteriores, este modo puede direccionar los primeros 65520 bytes de memoria extendida como parte del rango de 64 KB comenzando 16 bytes antes de la marca de 1 MB, FFFF:0000 (0xFFFF0)hasta FFFF:FFFF (0x10FFEF). Los procesadores Intel 8086 y 8088 , con solo 1 MB de memoria y solo 20 líneas de dirección , se envolvían en el bit 20, por lo que esa dirección FFFF:0010era equivalente a 0000:0000. [1]
Para permitir la ejecución de programas DOS existentes que dependían de esta característica para acceder a la memoria baja en sus computadoras IBM PC AT más nuevas, IBM agregó un circuito especial en la placa base para simular el enrollado. Este circuito era una puerta lógica simple que podía desconectar la línea de direccionamiento número 21 del microprocesador, A20 , del resto de la placa base. Esta puerta podía controlarse, inicialmente a través del controlador del teclado , para permitir la ejecución de programas que quisieran acceder a toda la RAM. [1]
Los denominados controladores A20 podrían controlar el modo de direccionamiento de forma dinámica, [1] permitiendo así que los programas se carguen en la región de 1024–1088 KB y se ejecuten en modo real. [1]
El código adecuado para ser ejecutado en la HMA debe estar codificado para que sea independiente de la posición (usando solo referencias relativas), [2] [1] debe compilarse para funcionar en las direcciones específicas en la HMA (normalmente permitiendo que solo una o como máximo dos piezas de código compartan la HMA), o debe estar diseñado para que sea reubicable en los límites de párrafo o incluso en desplazamientos (con todas las direcciones fijadas durante la carga). [2] [1]
Antes de que la CPU pueda acceder al código (o los datos) en la HMA, el controlador correspondiente debe asegurarse de que la HMA esté mapeada. Esto requiere que dichas solicitudes se tunelicen a través de un stub que permanece en la memoria fuera de la HMA, que invocaría al controlador A20 para habilitar (temporalmente) la compuerta A20 . [2] [1] Si el controlador no exhibe ninguna estructura de datos públicos y solo usa interrupciones o llamadas ya controladas por el sistema operativo subyacente, podría ser posible registrar el controlador con el sistema de manera que el sistema se encargue de A20 por sí mismo, eliminando así la necesidad de un stub separado. [1] [nb 1]
El primer usuario de la HMA entre los productos de Microsoft fue Windows/286 2.1 en 1988, que introdujo el controlador de dispositivo HIMEM.SYS . A partir de 1990 con DR DOS 5.0 de Digital Research [3] (a través de [4] y CONFIG.SYS ) y desde 1991 con MS-DOS 5.0 [3] (a través de ), partes del BIOS y del núcleo del sistema operativo también se podían cargar en la HMA, [3] [5] liberando hasta 46 KB de memoria convencional . [1] Otros componentes, como los controladores de dispositivos y los programas residentes de terminación y permanencia (TSR), al menos se podían cargar en el área de memoria superior (UMA), pero no en la HMA. En DOS 5.0 y versiones superiores, con , el sistema intentaba además mover los búferes de disco a la HMA. [5] Bajo DR DOS 6.0 (1991) y superiores, los buffers de disco (a través de , y posteriormente también ), partes del procesador de comandos COMMAND.COM así como varios controladores especiales de reubicación automática como KEYB , NLSFUNC y SHARE también podían cargarse en el HMA (usando su opción), liberando así incluso más memoria convencional y memoria superior para que el software DOS convencional trabaje con ella. [1] TASKMAX parece haber reubicado partes de sí mismo también en el HMA. [6] [7] El NLCACHE de Novell de NetWare Lite y las primeras versiones de NWCACHE de Personal NetWare y Novell DOS 7 también podían utilizar el HMA. [8] [9] [7] Bajo MS-DOS/PC DOS, una porción compartida de ca. 2 KB de COMMAND.COM puede reubicarse en el HMA, [10] así como los mapas de bits de DISPLAY.SYS para páginas de códigos preparadas . [10] [11] En MS-DOS 6.2 (1993) y versiones superiores, una porción de aproximadamente 5 KB de DBLSPACE.BIN / DRVSPACE.BIN puede coexistir con DOS en la HMA (a menos que se invoque DBLSPACE / DRVSPACE ). [5] [12] En PC DOS 7.0 (1995) y 2000 , DOSKEY se carga en la HMA (si está disponible), [13]HIDOS.SYS /BDOS=FFFF HIDOS=ONDOS=HIGHDOS=HIGHHIBUFFERSBUFFERSHIGH/MH /NOHMAy SHARE también se puede cargar en el HMA (a menos que /NOHMAse dé su opción). [13] En MS-DOS 7.0 (1995) a 8.0 (2000), partes del HMA también se utilizan como un bloc de notas para almacenar una estructura de datos creciente que registra varias propiedades de los controladores de modo real cargados. [7] [14] [15]
[…] 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)
[…]
MS-DOS 7.0+
agrega INT 21h/AX=4A03h e INT 21h/AX=4A04h.
RBIL
61 INT 21h/AH=52h tiene algo de información sobre la cadena MCB de HMA de MS-DOS 7.0+ […] La reubicación de HMA para TSR tiene mucho sentido para
DR-DOS
: aunque puede cargar grandes partes del
BIOS
y
BDOS
, la parte residente del shell, los
BUFFERS
y los TSR de DR-DOS como
SHARE
,
KEYB
y
NLSFUNC
(y en algunos números partes de TASKMGR y
NWCACHE
) en el HMA, generalmente todavía hay espacio libre disponible, típicamente alrededor de 10 Kb (hasta ca. 20 Kb cuando usa un shell de terceros). También tiene sentido para
MS-DOS 5.0
-
6.22
y
PC DOS
hasta
2000
, que generalmente dejan entre 4 y 7 Kb de la memoria HMA sin usar (SHARE, KEYB y NLSFUNC no se pueden cargar en el HMA, pero
DBLSPACE
y
HIMEM
pueden hasta cierto punto). El espacio disponible en HMA puede ser bastante limitado con
MS-DOS 7.0+
, ya que este problema introdujo una nueva estructura de datos RMD, en su mayor parte no documentada, que normalmente se encuentra en HMA. El núcleo recopila y registra datos de configuración y del controlador de modo real durante el arranque (tipo de controlador, interrupciones enganchadas por el controlador, línea de invocación
CONFIG.SYS
, etc.) y almacena esta información en una […] estructura de datos complicada […] y […] creciente. Es de suponer que esta información está destinada a ser utilizada por el núcleo de Windows para obtener una mejor imagen de los controladores de modo real cargados en lugar de tratar a DOS como un bloque monolítico, o incluso […] intentar desenganchar o descargar algunos de ellos, sin embargo, solo se utiliza en una medida muy limitada (por ejemplo, puede ver parte de la información reflejada en los archivos de registro creados en el inicio de Windows 9x, y algunas partes del administrador de configuración de Windows también la utilizan), lo que deja espacio para la especulación mucho más allá del aspecto técnico, en particular porque nada de lo interesante está documentado… […]
NWDOSTIP.TXTes un trabajo exhaustivo sobre Novell DOS 7 y OpenDOS 7.01 , que incluye la descripción de muchas características y componentes internos no documentados. Es parte de la MPDOSTIP.ZIPcolección aún más grande del autor, mantenida hasta 2001 y distribuida en muchos sitios en ese momento. El enlace proporcionado apunta a una versión anterior del archivo convertida a HTML). [4][…] algunas ediciones de DISPLAY.SYS (de
PC DOS 7
/
2000
, por ejemplo) almacenan las fuentes actualmente no utilizadas en
la memoria XMS
. Algunas ediciones anteriores de MS-DOS/PC DOS DISPLAY.SYS parecen haber tenido una función para almacenarlas en la HMA […]
[…]
DOSKEY.COM
[…] Mueva el código a HMA si está disponible. […]SHARE.EXE
[
…] Mueva el código a HMA si está disponible y agregue la opción /NOHMA para forzar la carga a baja velocidad. […]
…] El código de ANSIPLUS no se puede cargar en la HMA en
MS-DOS 7
(solo Windows 9x) porque aparentemente no hay suficiente memoria HMA sin usar disponible. […]
[…] 86-DOS , y por lo tanto PC DOS / MS-DOS , usaban un truco inteligente. El byte en el desplazamiento 5 del PSP contenía un código de operación de llamada lejana (9Ah); la palabra en el desplazamiento 6 del PSP contenía el valor apropiado para indicar el tamaño del segmento del programa, y también la parte de desplazamiento de la llamada lejana. La palabra en el desplazamiento 8, que servía como parte del segmento de la llamada lejana, se diseñó de tal manera que, cuando se combinaba con el desplazamiento, se ajustaría (una característica bien entendida de la CPU 8086 ) y apuntaría a la dirección 0:C0h, que contiene el vector de interrupción 30h. […] la interfaz CALL 5 funciona incluso en emulación DOS bajo Windows NT y OS/2, y esos sistemas ciertamente no pueden funcionar con la línea A20 deshabilitada. ¿Cómo funciona eso entonces? […] En lugar de cortar bits de dirección, el sistema refleja los cinco bytes en 0:C0h en 1000C0h. La misma técnica se había utilizado de hecho en DOS 5 y superior que se ejecutaba con DOS=HIGH. En ese caso, DOS se asegura de que la dirección lineal 1000C0h contenga la llamada lejana apropiada. […]
punteros
tan destrozados […] hace muchos años, Axel y yo estábamos pensando en una forma de usar *un* punto de entrada en un controlador para múltiples vectores de interrupción (ya que esto nos ahorraría mucho espacio para los múltiples puntos de entrada y el código de encuadre de inicio/salida más o menos idéntico en todos ellos), y luego cambiar a los diferentes controladores de interrupciones internamente. Por ejemplo: 1234h:0000h […] 1233h:0010h […] 1232h:0020h […] 1231h:0030h […] 1230h:0040h […] todos apuntan exactamente al mismo punto de entrada. Si conecta INT 21h a 1234h:0000h e INT 2Fh a 1233h:0010h, y así sucesivamente, todos pasarían por el mismo "vacío", pero aún podría distinguirlos y ramificarse en los diferentes controladores internamente. Piense en un punto de entrada "comprimido" en un stub A20 para la carga de HMA. Esto funciona siempre que ningún programa comience a hacer magia de segmento: desplazamiento. […] Compare esto con el enfoque opuesto de tener múltiples puntos de entrada (quizás incluso admitiendo el Protocolo de uso compartido de interrupciones de IBM ), que consume mucha más memoria si conecta muchas interrupciones. […] Llegamos a la conclusión de que esto probablemente no sería seguro en la práctica porque nunca se sabe si otros controladores normalizan o desnormalizan los punteros, por cualquier razón. […]