Lotus, Intel y Microsoft

Ahora puede resultar curioso o lejano, pero hubo un tiempo en que Lotus (ahora IBM), Intel, y Microsoft, se unieron para desarrollar la especificación que posteriormente se denominaría LIM, como acrónimo de sus siglas: Lotus-Intel-Microsoft.

Hablamos del año 1984, dónde por primera vez la frase de que 640 Kb. deberían ser suficientes, deja de ser válida, gracias a la hoja de cálculo Lotus 1-2-3, que en determinados ámbitos, se quedaba corta de memoria RAM para almacenar la matriz de filas y columnas.

Así surge LIM EMS 3.2, el estándard de memoria expandida, que mediante un tarjeta de expansión ISA, permite ampliar la memoria de cualquier PC, para ser usada por programas diseñados a tal efecto.

EMS funcionaba paginando bloques, por lo que su uso no era tan directo como el de la memoria convencional, sin embargo las necesidades obligaron, de manera que software tan conocido como el citado 1-2-3, Wordperfect, o Pkzip, enseguida tomaron partido para aprovecharla. En la revisión 4, EMS llegó a soportar hasta 32 Mb. de memoria.

Con la difusión del 286, y sobre todo el lanzamiento del 386 que soportaban modo protegido por hardware, se propueso XMS (memoria extendida), que se implementaba directamenteen la placa, y que a nivel de programación no sólo era mucho más flexible y algo más sencillo, sino también más rápido.

No obstante, para mantener la compatibilidad con aplicaciones que sólo aprovechaban EMS, se popularizó CEMM (Compaq), 386Max (Qualitas), QEMM (Quarterdeck), y luego EMM386 (de MS-DOS 4 y DR-DOS 5), que emulaban por software la API EMS sobre XMS.

Por nostalgia, y motivos históricos, os dejo la especificación 4.0 de octubre de 1987 aquí (59 Kb. en formato ZIP).

4 comentarios en “Lotus, Intel y Microsoft”

  1. Ya ni me acordaba de aquel galimatías de memoria extendida, expandida, memoria alta… ¡Qué tiempos aquellos!

  2. El asunto era que para los 286 la EMS venía en una placa ISA que se pinchaba en el bus del ordenador (no sé si llegaron a existir para 8086). A fin de cuentas, solo era un método más de paginar memoria al estilo del que usaban los ordenadores de 8 bits. Recuerdo una placa con 2 MB de RAM que costaba como un piso de 200 m² en plena burbuja inmobiliaria.

    La cosa cambió con la llegada del 386 y los EMM386, QEMM386 y demás. El ordenador tenía más memoria, 4 y hasta 8 MB y el procesador ya permitía usar trucos para simular la EMS, los UMB, la HIMEM y la XMS. En ese punto desapareció el HW y todo quedó en SW.

    Lo que no sé cuanta gente recuerda es porqué siguió ese lío de las memorias, si el 386 podía manejar una cantidad de RAM quasi infinita (4 GB) para la época. La EMS permitía paginar hasta 64 KB (si la memoria no me falla) en la que podían existir tanto datos como código ejecutable. Usando la técnica de la línea A20 se podía acceder a la HIMEM, que proporcionaba 64Kb – 16 bytes de acceso a memoria donde también se podía poner código. De hecho, era típico que el DOS se pusiera en gran parte allí. Pero de ahí en adelante, toda la XMS servía para almacenar datos PERO NO CODIGO, y ahí residía el quid de la cuestión.

    Los extensores de DOS, especialmente el QEMM386 hace muchas cosas virgueras con la CPU. De hecho, si se instala en una VM tipo VirtualBox, el consumo de CPU se dispara hasta el 100% hagas lo que hagas.

  3. Efectivamente había tarjetas de expansión EMS, disponibles para 8086. De hecho mi Amstrad PC/2086 podía equipar una de ellas, aunque por los altos precios que comentas, no conozco a nadie que lo hiciera.

    Tal y como dices, EMS y XMS funcionaban con mapeo. Es decir, se le decía a la API, quiero que me coloques esto que está en XMS/EMS aquí. Ese aquí era memoria accesible por el DOS de 16 bits, y efectivamente podía contener datos, pero también código.

    Sólo que era tedioso, e ineficiente estar mapenado y desmapeando constantemente. De modo que cuando los primeros extensores DOS hicieron acto de presencia, explotando el modo flat de los i386 que permitía direccionar hasta 4 GB de código y datos, poco a poco se impusieron. Sin embargo pasar de 640 KB (o 1 MB si queremos) a 4 GB era tan abismal, que muchos extensores estaban artificialmente limitados a 32 MB o incluso menos.

    Es extraño que DOS siguiera siendo por motivos de compatibilidad un SO de 16 bits, cuando muchas aplicaciones y juegos eran de 32 bits, que mediante extensores, cambiaban a 16 bits cada vez que necesitaban invocar a DOS.

Deja un comentario