Volver a la portada de Duiops
Volver al Web de Duiops
 
   
Menú
Secciones destacadas
Artículos y FAQs
Trucos de Windows
Versiones de Windows
y suites de software
Windows Vista
Windows Media Center
Windows XP
Windows 2000
Windows Millenium
Windows 98/98 SE
Windows 95 OSR-2
Internet Explorer
Office
Otros
Tutorial muy básico
   
Portada
Portada - Artículos y FAQs - Desde que pulsamos el boton de encendido de nuestro PC hasta... (parte 14)
 
Desde que pulsamos el boton de encendido de nuestro PC hasta... (parte 14)

 

Por Jose Manuel Tella Llop, extraído de microsoft.public.es.windows98

DESDE QUE PULSAMOS EL BOTON DE NUESTRO PC HASTA..... (Parte 14)
----------------------------------------------------

PARAMETROS DE CONFIGURACION - CONFIG.SYS
----------------------------------------

Teóricamente, debemos recordar que el config.sys no es necesario. No debería existir y es una reminiscencia del antiguo MsDOS.

Unicamente en paises diferentes a USA, es necesario especificar un par de lineas en él debido a las clasicas configuraciones regionales. (y esto unicamente si tenemos un teclado diferente al teclado normal utilizado en USA)

Las lineas a utilizar en España, deberían ser:

device=C:\WINDOWS\COMMAND\display.sys con=(ega,,1)
Country=034,850,C:\WINDOWS\COMMAND\country.sys

Y extrictamente no es necesaria ninguna linea más en el config.

(en otros paises de America Latina, los parametros pueden variar ligeramente)

** Recordemos un poco de la historia del MsDOS y del antiguo Windows 3.1.

* Windows 3.1 fué el primer sistema (mejor dicho, fue la primera interface grafica sobre el MsDOS -no puede llegar a la categoría de sistema operativo-), que era capaz de superar la barrera del mega. Para ello, era capaz ya de poner a trabajar al procesador en modo protegido. (Veremos este funcionamiento mas adelante).

* Para ser capaz de realizar esto, necesitaba un manejador de memoria en modo protegido. Este manejador fué un standard creado por microsoft como driver de DPMI (Dos Protected Mode Interface). Dicho driver era el HIMEM.SYS

* Windows 98, necesita por cuestiones de compatibilidad de la misma interface DPMI para iniciar su carga. Por tanto es necesaria, pero es opcional el declararlo o nó en el CONFIG.SYS. Windows lo cargará de todas maneras.

* Igualmente, aunque no esté declarado en el config.sys, Windows cargará el DBLBUFF.SYS. Este es un driver para suministrar un marco en memoria baja para todos los dispositivos SCSI que lo necesiten para transferencia de datos via DMA (esto se refiere a las antiguas tarjetas SCSI ISA cuya transferencia es DMA y que prácticamente ya, no existen).

* NOTA IMPORTANTE: Además de lo anterior, en el antiguo MsDOS, era necesario cargar aquí todos los drivers de dispositivos de los fabricantes (y alguno del propio Microsoft que veremos a continuacion). Es importante recordar, que estos drivers ya no son necesarios en Windows 98, y que si los ponemos, podemos correr el riesgo de malfuncionamiento, o lo que es peor, de perdida grave de prestaciones y velocidad dentro de Windows 98. Por esto, debemos ser excesivamente cautos con este archivo de configuración y además vigilar despues de cualquier instalación ya que todavia circula mucho software muy viejo el cual tiene la "insana" costumbre de tocar sin permiso nuestro CONFIG.SYS

Todos los drivers de dispositivos, se cargan con el comando DEVICE o DEVICEHIGH.

Vamos a ver ahora un driver especial de Microsoft. Tambien es una vieja herencia, pero a veces nos puede resultar necesario el instalarlo para poder utilizar viejos programas MsDOS, o algun juego que requiere mucha memoria MsDOS. Me estoy refiriendo al EMM386.EXE.

Para poder estudiar el funcionamiento del EMM386.EXE, es necesario repasar un poco la memoria real por debajo del mega. Es necesario tambien que recordemos lo que vimos en los primeros capitulos sobre la memoria real.

A modo recordatorio, debemos tener presente que una dirección en MsDOS (debido al funcionamiento del hardware, es decir debido al funcionamiento del propio procesador de Intel en modo real), estaba formada por una dirección de segmento y un desplazamiento.

El segmento en hexadecimal, podia valer desde 0000 a FFFF. Exactamente igual el desplazamiento. La manera de sumarlos era desplazando un cuarteto el segmento y sumando entonces el desplazamiento para formar una dirección real. (repasar los capitulos anteriores).

Igualmente recordemos, que por diseño, IBM definió la dirección del adaptador de video en el segmento A000. Por tanto la memoria real, podia (y por degracia, todavia es así por compatibilidad) llegar desde 0000 hasta A000 (esto corresponde justo a 640 Kbs.). Es por el propio diseño de donde se encuentra el adaptador de video. Por tanto esta es la maxima memoria real "contigua" que puede existir en el PC. Podeis verificar con la calculadora de Windows que A0000 en hexadecimal son justo los famosos 640 Kbs de los que hemos oido hablar por todos los lados.

Debemos recordar tambien que desde la C000 hasta la F000 (en la cual se encuentra la bios), estan en principio reservadas para otras bios de otros posibles dispositivos y tarjetas que puedan necesirtarlo. En particular la tarjeta de video tiene siempre (practicamente, aunque no es una norma), su dirección en C000 hasta C7FF.

Pero...... allí hay 196 Kbs. y de ellos, unicamente 32 Kbs utilizados por la bios de la tarjeta grafica. Entonces.... si no tenemos mas tarjetas que tengan bios propia, ¿por qué no utilizar esos Kbs de memoria para meter algun driver de dispositivo?. O bien ¿por qué no utilizarlos para que el propio MsDOS meta allí sus rutinas, en vez de utilizar el espacio de los primeros 640 Kbs?

Efectivamente, esta idea surgió en el MsDOS 5.0 (y superiores). Recordad que el MsDOS de Windows 98, se identifica internamente con la versión 7.10.

** Microsoft en el MsDOS 5.0, modificó el codigo del sistema para poderse cargar todo o parte, tanto codigo como areas de datos reservadas, en dicho espacio. Y además diseñó un driver (el EMM386) para recuperar dicho espacio y poderlo utilizar incluso para cargar posibles pequeños programas que se quedaban residentes en la maquina.

A esta memoria se la llamo UMB (Upper Memory Block).

Antes de ver con detalle el EMM386.EXE, veamos que otras necesidades podiamos tener con respecto a ese posible "mega" de memoria.

* Existió antes de la especificacion DPMI de Microsoft, la cual suministraba el concepto de memoria XMS (eXtended Memory System) o memoria Extendida, otro tipo de memoria. La memora Espandida. o memoria EMS (Expanded Memory System). Era la memoria LIM definida por el consorcio Lotus-Intel-Microsoft. Dicha memoria lo que hacia era utilizar un marco  de pagina (una ventana) que apuntaba a 64 Kbs de memoria en cualquier posicion por encima del mega.

Es decir en un momento determinado, al escribir o leer en ese marco de pagina, estabamos escribiendo realmente en una zona determinada por encima del mega. Cambiando simplemente una dirección en el PC, esa ventana apuntaba a otro marco de 64 Kbs, diferente al anterior.

De esta manera, cambiando simplemente unas direcciones, nos estabamos moviendo en pequeños bloques de 64 Kbs por encima del mega. Esto en un principio era memoria hardware especial. Una tarjeta especial con un chip controlador. Esa memoria se dirección aba mediante la programacion del chip, cambiando la dirección de un puerto, y nos hacia ver una ventana de 64 Kbs en la dirección fisica de memoria E000 de nuestro PC, la cual se "movia" a lo largo de esa memoria EMS (o memoria LIM).

Cuando se modificó el procesador 8086 en sus sucesores, el manejo de memoria unicamente cambió para poder ver mas direcciones contiguas por encima del mega en el modo protegido. Es decir empezó a "crecer" dicho mega. Esta memoria era contigua y por tanto muy diferente a la memoria manejada por el controlador fisico de EMS.

Se decidió entonces crear un controlador "logico" EMS, el cual nos permitiese ver la "nueva" memoria ahora definida como si fuese una memoria EMS de las que acabamos de ver. Se hizo así para que los antiguos programas que necesitasen EMM, pudiesen seguir funcionando.

Pues de paso.... se dotó de dicha funcionalidad al controlador EMM386.

** Y por ultimo, las malas lenguas comentan que cuando se creó el primer procesador capaz de ir al modo protegido, el 80286 (los antiguos 286), algun ingeniero de intel, comentó a algun tecnico de Microsoft, que si era capaz de controlar la linea A20 de direcciones del procesador, sería capaz de obtener otros preciosos 64 Kbs (realmente 64 Kb menos 16 bytes) de memoria real.

Esta historia es curiosa, por lo que vamos a comentarla un poco. Curiosa en plan tecnico, por lo que pido disculpas por salirnos un poco del tema. Veamos: la definicion de las lineas de direcciones en un 8086, eran de 20 direcciones. Lineas de direcciones A00 a A19.

Recordad igualmente que para obetenr una direcion real, sumando un segemento y un desplazamiento, se hacia (por hardware) añadiendo un cuarteto con contentido cero a la dirección de segmento y sumandole el desplazamiento. Es decir por ejemplo, para sumar el segmento 1234 al desplazamiento 5678, se hacia:

 12340
  5678
 --------
        179B8

Y la maxima direcion que podia sumarse entonces era el segmento F000 (ya que como el desplazamiento iba desde 0000 a FFFF, de esta manera no habría "desbordamiento") Es decir:

 F0000
  FFFF
       -------
 FFFFF

(FFFFF era la maxima dirección real que podia expresarse con 20 lineas de dirección : 5 cuartetos = 20)

Bien, pues Intel, le "sopló" a Microsoft, que si se utilizaba el segmento FFFF, con linea A20 activada no habría desbordamiento. Pero para esto, el software debería estar preparado. Es decir podriamos sumar:

 FFFF0
  FFFF
 ------
       10FFEF

Para esto necesitamos las 20 lineas del modo real, mas la linea 21 (la A20) para manejar el "1" que nos sobra.

Si la linea A20 no está activada, entonces por ejemplo:

 FFFF0
 00010
 -------
 00000  nos vuelve justo al comienzo de la memoria fisica.

Pero con la linea activada, esa misma suma nos dá:

 FFFF0
 00010
 -------
       100000  es decir por encima del mega. Y así nos puede llegar hasta 64 Kbs - 16 bytes. A esta memoria se la llamó memoria HMA (o HIGH).

Pues ahora ya estaba relativamente sencillo. La manera de controlar la linea A20, era facil. El HIMEM.SYS de por sí controla todas las lineas de direcciones. Por tanto controla esta en particular. Y ahora el EMM386, podia ser el encargado de comunicarse con el HIMEM para activar o desactivar dicha linea, tomar control de dicha memoria y suministrarsela a los programas de aplicación.

Como el "primer" programa que podia hacer uso correcto de ella, era el propio MsDOS, se procedio a modificar su núcleo (al objeto de enseñarle a "sumar" direcciones de 21 bites), para poder utilizar dicha memoria.

Resumiendo: EMM386 tiene (o puede tener) tres funciones basicas:

1) Control de la memoria EMS (LIM) y creacion del marco de pagina
2) Soporte a la memoria UMB.
3) Soporte a la memoria HMA (HIGH).

Y de pasó se le dotó al EMM386 de una serie de parametros para poder controlar esta memoria. En particular, el parametro RAM suministra memoria UMB. El parametro RAM implica tambien memoria EMS (y por tanto utilizar el segmento E000 por defecto como marco de pagina).

Se definió tambien la combinacion RAM NOEMS, si queremos unicamente UMB y no queremos marco de pagina.

Existen además otra serie de parametros que se salen del contenido de este capitulo.

** Es importante indicar, que si ponemos el driver EMM386.EXE en el config.sys, entonces *SI* que es obligatorio poner primero el HIMEM.SYS en dicho archivo.

** Ademas, tambien es importante resaltar, que aunque pongamos el parametro RAM, esto solo indica que esta memoria estañra disponible para programas que "sepan" utilizarla. En particular si queremos que el propio MsDOS pueda utilizarla, se deberá incorporar en el config.sys (en cualquier sitio), la linea:

DOS=UMB

Y por ultimo, tambien, para que el propio MsDOS pueda utilizar la memoria HIGH (HMA), se deberá igualmente incirporar la linea:

DOS=HIGH

Ambas lineas, pueden resumirse en:

DOS=HIGH,UMB

(pero recordad que solo tendran sentido si tenemos el EMM386 con el parametro RAM, y esto además obliga a tener el HIMEM.SYS)

OTROS PARAMETROS DEL CONFIG.SYS
-------------------------------

**** Bueno, y este será el siguiente capitulo......


Volver a Artículos y FAQs

 

     
 

Volver arriba Volver arriba

© 1997-2009 Duiops (http://www.duiops.net)
Prohibida la reproducción parcial o total de los textos o las imágenes

Para comentarios, usa las direcciones e-mail de contacto.