Artículos > Desde que encendemos la PC hasta que termina la carga de Windows... (2):
|
PREPARACION DE LA CARGA DE UN SISTEMA OPERATIVO:
Bien llegados a este punto, suponemos que la bios ya ha inicializado todos los dispositivos de la maquina. Asignado las correspondientes IRQs y recursos a los dispositivos y ahora va a proceder a cargar el sistema operativo.
Lo mas normal es que intente su carga desde un disquete primero. Si esta carga falla, lo intenta desde el primer disco duro.
Hay que matizar, antes de continuar, que esto es configurable en la bios de la maquina. Lo comentado en el parrafo anterior es la opcion por defecto de casi todas las bios, y matizando precisamente en esta opcion, mi consejo es precisamente desactivar el intento de carga desde disquete en la bios. Casi todas las bios, permiten cambiar la sequencia de arrancada de A,C (es el defecto) a C,A o bien C only. Las ventajas que tenemos con esto son:
1) Se iniciará la carga mas rapidamente ya que no irá a buscar a disquete.
2) No tenemos el riesgo de habernos dejado un disquete en la maquina con un virus del boot. Si lo tuviesemos e intentase arrancar desde el disquete aunque no lo consiguiese, ya nos habría infectado el disco duro.
Vamos a ver primero, precisamente la carga (el inicio de la carga) desde disco duro. Luego veremos una variante de este metodo de carga, que coincide precisamente con el arranque estandard desde un disquete. Para ver la carga desde disco duro, debemos conocer primero como está logicamente particionado el disco.
PARTICIONES EN UN DISCO DURO
Bien, por definicion un disco duro permite hasta 4 particiones. No puede tener más y la explicacion, proviene del diseño del sector de boot del disco duro. Este sector de boot, se le llama tambien MBR (Master Boot Record). Dicho sector que ocupa siempre la misma posicion fisica en todos los discos duros (cabeza cero, cilindro cero, sector 1), tiene un diseño fijo.
Todos los sistemas operativos tienen un FDISK o similar, que "sabe" crear en vacio este sector y ademas lo hace automaticamente si el disco está nuevo (recien comprado). Todos los sistemas operativos, lo crean exactamente igual.
Recordad que el tamaño de un sector es unicamente 512 bytes.
La estructura de dicho sector, es un mini-programa y una pequeña tabla de 4 elementos. Cada elemento de la table, tiene los datos de cabeza, cilindro, sector de donde empieza una particon, de donde termina, el tipo de particion (hay unos codigos para FAT 16, FAT 32, Linux, NTFS, primaria, secundaria etc...), y una marca de cual es la particion "arrancable".
El mini-programa de este sector, lo unico que sabe hacer es leer dicha tabla, buscar si existe una particion "arrancable" y si existiese, va a la posicion del cilindro, cabeza, sector de comienzo y allí carga en memoria el primer sector que encuentra y lo ejecuta. Este nuevo sector es precisamente el "boot" de la particion (no confundirlo con el MBR, o sector 2 "boot" del disco que hemos citado anteriormente). Este ultimo "boot", el responsable de crearlo es el "format". Y el responsable de la creacion de las particiones es el FDISK (en sistemas Microsoft)
Entonces, retomando un poco el titulo de estos articulos, la bios lo que hace es cargar en memoria el MBR del disco duro (en la direccion 7C00 hexadecimal) y cede el control a dicho programa. Este se realoja en otra posicion de memoria, busca la particion "activa" o "rrancable" y carga en memoria su sector de "boot", tambien en la direccion 7C00 y le cede control.
Pero antes de continur con esto, merece la pena que echemos una mirada al sector de particiones o MBR.
EL SECTOR DE PARTICIONES
El llamado sector de particiones es creado por FDISK en su primera llamada (con un disco recien adquirido y sin preparar) o cuando ejecutamos el comando FDISK /MBR.
Es el primer sector del disco duro (cabeza 0, cilindro 0, sector 1). Este es el sector que siempre arranca la BIOS primeramente antes de cargar ningun sistema operativo. La bios lo carga en la poscion de memoria 0000:7C00 siempre que no encuentre un disquete en la unidad A:.
Si los dos ultimos bytes de los 512 de este sector contienen el codigo 55h,AAh (hexadecimal) considera este sector como ejecutable y comienza la ejecucion de programa en el primer byte de ester sector una vez se ha cargado en la posicion de memoria anterior.
El codigo de programa que hay en este sector de arranque, tiene como tarea el reconocer la particion "activa" y con ello, el sistema operativo a ejecutar, cargar su sector de arranque y comenzar la ejecucion del codigo de programa que allí está contenido. Ya que este codigo de programa, por definicion, se ha de encontrar en la posicion de memoria 0000:7C00, el codigo de particion, primeramente, se desplaza a la posicion de memoria 0000:0600 y con ello deja espacio para el sector de arranque.
Direccion Contenido Tipo
-
+000h Codigo de la particion Codigo
+1BEh 1ª entrada en la tabla de particiones 16 Bytes
+1CEh 2ª entrada......... 16 Bytes
+1DEh 3ª entrada......... 16 Bytes
+1EEh 4ª entrada......... 16 Bytes
+1FEh Identificacion AA55h 2 Bytes
Longitud= 200h = 512 Bytes.
Veamos cada entrad de 16 Bytes que define una particion, que es lo que contiene:
Direccion Contenido Tipo
-
+00h Estado de la particion 1 BYTE
00h = Inactiva
80h = Particion de arranque
+01h Cabeza de lectura/escritura 1 BYTE
donde comienza la particion.
+02h Sector y Cilindro donde comienza 2 BYTES
la particion (formato WORD - palabra)
+04h Tipo de particion 1 BYTE
00h = Libre
01h = DOS con la vieja 12-bit FAT
02h = XENIX
03h = XENIX
04h = DOS FAT 16
05h = Particion extendida
06h = Particion DOS 4.0 > 32 Megas
DBh = Concurrent DOS
.... etc
+05h Cabeza de lectura/escritura 1 BYTE
donde termina la particion.
+06h Sector y cilindor donde 2 BYTES
termina la particion.
+08h Distancia del primer sector de la 4 BYTES
particion (Sector de arranque)
+0Ch Numero de sectres de esta particion 4 BYTES
Longitud = 10h = 16 Bytes
Luego las funciones del programa de boot (MBR) del disco duro son:
1) Localizar el sector de arranque de la particion activa, para esto se recorre las 4 entradas de las 4 posibles particiones para ver cual es la activa.
2) Posicionar la cabeza de lectura escritura en dicha particion.
3) Volver a cargar los 512 primeros bytes de esa particion en memoria y ceder el control (este es el verdadero sector de arranque del sistema operativo. En el caso de MSDOS o WINDOWS, es creado al dar un FORMAT a la particion)
PARTICIONES. SU SIGNIFICADO Y SU CREACION
Una particion, no es ni mas ni menos que reservar un "trozo" (o todo) del disco para contener un sistema operativo o datos.
La manera de crear / borrar paticiones bajo MsDOS (o en los sistemas operativos de microsoft), es mediante el comando FDISK.
* La primera pregunta que nos realiza FDISK es si queremos soporte para grandes particiones (por defecto viene activada la letra "S" en windwos 98). Esta pregunta a lo que realmente se refiere, es que si decimos "S", la particion que vamos a crear en ese momento, será FAT 32. Si decimon que "N", la particion a crear será FAT 16.
Al contrario de lo que cree mucha gente, no es en el FORMAT en donde se le dice en tipo de FAT, sino justo en el momento de crear la particion.
Antes de continuar con las particiones, vemos que hemos introducido un concepto: FAT 16 y FAT 32. Vamos a hablar un poco de ellas.
FAT 16 y FAT 32
Bien, imaginemos que ya tenemos un "pedazo" de disco. Imaginemos ahora que queremos guardar allí archivos. ¿de que manera "fisicamente" puede hacerse, para ser capaces de almacenarlos y recuperarlos rapidamente?.
Se admiten ideas......
Bueno, los primeros programadores del MSDOS, de los cuales heredamos el actual windows, tuvieron que "diseñar" un sistema de archivos... El diseño, quizá no sea el mejor (seguro que no), pero funciona y por suerte o por desgracia lo hemos heredado. Pensemos un poco.... ¿como lo diseñaron? Pues mas o menos razonando de la siguiente manera:
1) Evidentemente la manera mas rapida de acceder a un archivo, siempre es si tenemos un "indice" a donde está ese archivo.
2) Sí tenemos un "indice", debemos guardarlo siempre en el mismo sitio para que el sistema lo busque rapidamente.
3) Ademas, de alguna manera, deberemos ser capaces de buscar rapidamente sitios no utilizados en el disco para poder grabar un archivo nuevo.
4) Lo mejor sería tener numerados todos los "pedacitos" del disco. Sabemos "por diseño" que la minima cantidad que entiende un controlador de disco son 512 bytes. Es decir se grabará de 512 en 512.
5) Pero 512 es poco. ¿por qué no agrupamos pequeños grupos de 512 bytes?. Correcto. Pues tenemos que dar un nombre a esta "agrupacion". Y se decidiói darle en nombre de "cluster". Ya veremos cual es el tamaño mejor.
6) Ahora bien, si tenemos "cluster". ¿no sería mejor tenermos en un indice tambein al inicio del disco para saber si está libre o ocupado?. Vale, pues parece correcto. Pero como esto es delicado por si acaso, vamos a tener 2. El original y otra copia de él.
7) Bueno ya tenemos un indice para tener los archivos. Vamos a llamarle "Directorio principal". Tambien tenemos unos pequeños indices o tablas que nos indican si un "cluster" está libre o ocupado. Vamos a llamarle FAT (File Allocation Table, o "tabla de asignacion de archivos").
8) Y como podemos ahora guardar un archivo. A ver ¿que nos hace falta saber de un archivo?. Pues, "Su nombre", "la fecha de creacion", "la fecha de modificacion", en que "cluster" comienza, su tamaño en "bytes", y de paso, vamos a ponerle tammbien "atributos". Del tipo "rchivo", "Oculto", "Sistema", "Solo lectura".... Bueno, pues todas estas caracteristicas comunes las guardamos en el "directorio".
9) Y ahora su contenido. Hemos dicho que en el directorio está el numero del "cluster" en donde comienza el archivo. ¿Como lo hemos buscado?... Bien hemos hablado de la FAT. La FAT en principio podría ser simplemente un bite por cada cluster del disco, al inicio del proio disco, que nos dijese 1 o 0 para saber si está libre o ocupado. Pero ¿que tal si utilizamos esto para algo más?. Vamos a utilizarlo.
10) ¿y si cada "entrada" en la FAT, en vez de ser de 1 bite, con contenido uno o cero, lo definimos de "n" bites de tal manera que tengan un cero si está libre. Pero si está ocupada, que su contenido sea distinto de cero pero puede ser perfectamente el numero del siguiente cluster que utiliza el fichero, en el caso de utilizar mas de un cluster. Y ademas, si es el "ultimo" cluster del fichero, pues podemos ponerle una marca. Por ejemplo todo a "unos" binarios.
11) Parece que encaja. Entonces para grabar un archivo nuevo, primero buscamos un hueco en el directorio. Allí grabamos su nombre y sus datos de fecha, atributos, tamaño, etc. Ahora vamos a la FAT. La recorremos buscando una posicion que tenga "ceros". Esto nos indica que ese cluster del disco estará vacio o se puede utilizar. Pues nos guardamos dicho numero en el directorio, y asignamos todos a unos binarios en esa posicion de la FAT. Igualmente guardamos en el cluster fisico del disco el primer pedacito de nuestro archivo. Ahora miramos si el archivo ocupa mas tamaño de un cluster. Si es así, continuamos recorriendonos la FAT para buscar el siguiente "hueco" a ceros. Cuando lo encontremos, en la posicion ANTERIOR que habiamos grabados unos binarios, le ponemos la direccion de este nuevo "hueco" y a este hueco le llenamos con unos binarios (y grabamos en ese cluster, el segundo pedacito de nuestro archivo). Y así continuamos hasta el final del archivo.
12) ¿que estamos haciendo con lo anterior?. Facil: crearnos una "lista" de apuntadores al disco. Supongamos, que el tamaño del cluster es 4 Kbs. Supongamos que cada entrada en la FAT es de 16 bites y recordad que el numero maximo en binario que puede tener con 16 bites es 2 elevado a 16, es decir, desde cero a 65535. Con la suposicion anterior, vamos a ver como guardariamos un archivo de 7150 bytes.
12.1) Primero se busca un hueco en el directorio. Una vez encontrado recorremos la FAT de 2 bytes en 2 bytes (16 bites = 2 bytes). Imaginemos que encontramos "cero" en la posicion 124 desde el inicio de la FAT. Como vamos de 2 en 2 bytes, indica que el "cluster" numero 64 del disco está libre.
12.2) Entonces guardamos el numero 64 en el directorio. Grabamos unos binarios en esa posicion de la FAT, y en el cluster 64 real del disco grabamos los 4 primeros Kbs del archivo.
12.3) Como el archivo tenia 7150 bytes y hemos guardado 4 Kbs, quiere decir que para guardar el resto, debemos guardar otro pedacito de 4 Kbs. Entonces, realizamos la secuencia definida en 12.1) es decir buscamos el siguiente hueco, Por ejemplo el 250 (esto indica el cluster 125). Guardmos el numero 125 en la posicion anterior de la FAT en donde habiamos guardado unos binarios, ponemos unos binarios en la posicion actual y guardamos otros 4 Kbs, en el cluster real 125 del disco.
13.4) Si nos fijamos, ha quedado la lista: 64->125->unos binarios (o marca de fin). Y ademas hemos "utilizado" 8 Kbs fisicos del disco, cuando querimos guardar unicamente 7150. Por tanto se deperdicia un espacio. Logicamente a mayor tamaño del cluster, mas espacio podriamos perder...
14) Pues lo que acabo de describir es el funcionamiento de la FAT 16. Se le llama 16 porque utiliza 16 bites para cada "apuntador".
Realmente en el proceso anterior que hemos supuesto que el tamaño del cluster era 5 Kbs, esto no es verdad. ¿como calcula el sistema operativo cual va a ser el tamaño del cluster?.
Bien, tal y como definimos antes, sabemos que solo podemos tener hasta 65536 pedacitos. Ademas sabemos el tamaño total de la particion. Pues el sistema divide el tamaño en Kbs entre 65536. El resultado lo redondeamos hacia arriba a un numero que se multiplo de una potencia de dos. O sea a 2, 4 , 6, 16, 32.... y el numero que nos salga es el tamaño del cluster.
Se consideró que para no perder mucho espacio, se debria limitar el tamaño maximo del cluster. Y se definió así que el tamaño maximo del cluster debia ser 32 Kbs. Por tanto 32 Kb * 65535 maximos posibles cluster, nos dá la cantidad de 2 Gigas maximo. Por tanto la particion maxima que podemos tener en FAT 16, está limitada a 2 Gb.
Y ahora la FAT 32. Simplemente y debido a la limitacion anterior, se amplió el tamaño de fat a 32 bites (o 4 bytes). Con esto el numero maximo que cabe, ya no es 65535, sino 4.294.967.295 y como el tamaño maximo de cluster se define aquí en: 16 Kbs, entonces el tamaño maximo del disco sería: 68.719.476.736 es decir 68000 Gigas (o lo que es lo mismo 68 Teras).
CONSEJOS UTILES (Y NECESARIOS)
* Recordad que tal y como hemos comentado antes, un disco soporta 4 particiones maximo.
Como consejo, se debe seguir esta secuencia (IMPORTANTE):
1) Arrancar con la tecla CTRL pulsada y seelccionar "Solo Simbolo del Sistema), o bien arrancar con el disco de inicio de win98. Es decir en modo MsDOS "puro".
2) Crear o borrar una particion con FDISK
3) Inmediatamente despues, salir y reiniciar el ordenador (boton de reset).
Aunque parezca una tonteria, es importante. Sinoi lo hacemos así puede que la particion no sea creada correctamente.
TIPOS DE PARTICION
Habiamos hablado de dos posibles tipos de particion: Promaria y Extendida (o secundaria). Es simplemente un "marca". Pero una marca muy importante, ya que el sistema operativo lo va a hacer caso.
En el caso de los sistemas operativos de Microsoft, unicamente nos deja crear una particion primaria y una particion "extendida".
El disco de arranque (el C:) del sistema operativo, debe tener obligatoriamente una particion primaria. El propio FDISK, al ser la particion primaria del C:, la deja igualmente marcada como "arrancable".
Ademas, estos sistemas operativos, permiten a su vez, el volver a partir la partcion extendidad en otros pedacitos.
Por cada "pedazo", el sistema le asignará una letra de disco. ¿cual?. Bien esto es IMPORTANTE, si tenemos mas de un disco. El sistema se recorre todos los discos buscando particiones primarias en TODOS (repito). En este primer proceso ignora las extendidas. Por cada particion primaria que se encuentra, le asigna una letra consecutiva de disco. C:, D:, etc....
Cuando se ha recorrido TODOS los discos, ahora empueza a busczar particiones extendidas, empezando otra vez desde el primer disco. Cuando las encuentra, continua asignando letras a todas las "subparticiones" dentro de cada particion extendida que se encuentre.
** ¿Para que nos puede ser util lo anterior?. Facil. Imaginemos que tenemos 2 discos. Ademas que al primer disco le queremos tener "partido" en dos, y ademas queremos "entero" el segundo disco.
Y ademas, queremos que el primer disco fisico, tenga las letras C: y D:, y el segundo la E:
Pues bien, si creamos en el primer disco una particion primaria y una extendida, y ahora en el segundo creasemos una primaria, lo anterior no podría ser, ya que por los razonamientos anteriores, se recorre primero todas las particiones primarias. Por tanto a la del primer disco, le daría la C:, ahora va al segundo disco. Como tiene una primaria, le daría la D:, y ahora empieza con las secundarias, y por tanto a la particion extendida del primer disco, le daria la E:. Esto no es lo que queriamos.
Repetir el ejercicio anterior, suponiendo que en el segundo disco, la particion (unica) creada, en vez de primaria es secundaria. Vereis como "sale" lo que queriamos hacer.
FDISK
* La primera pregunta, a "compatibilidad para discos grandes", realmente está camuflada. Lo unico que nos quiere decir, es que lo que vayamos a crear en dicha sesion, como lo queremos: FAT 16 o FAT 32. Si decimos que "S" a esa pregunta, la partcion que creamos en ese momento será FAT 32. Si decimos que "N", será FAT 16.
* Recordar que SIEMPRE, una vez creada una particion, hay que salirse de FDISK y reiniciar el ordenar. SIEMPRE (insisto).
Basicamente continene 5 funciones.
1. Crear una particion o una unidad logica de DOS
2. Establecer la particion activa
3. Eliminar una particion o unidad logica del DOS
4. Mostrar informacion sobre la particion
5. Cambiar la unidad actual del disco duro
Antes de hacer nada, debemos saber que nada mas arrancar el FDISk, este está "apuntando" a nuestro primer disco fisico. Si queremos operar sobre otro disco, lo primero sería cambias la unidad de disco (opcion 5). Cuidado con esto, ya que por error podriamosm por ejemplo, borrar una particion de un disco, creyendo que estamos en otro disco..... y si hacemos esto, *no* hay marcha atrás.
* La opcion numero 1). nos permite crear una particion primaria, una extendida o bien "dentro" de la extendida, crear unidades logicas (es decir realmente crear "subparticiones" de dicha extendida como si esta fuese un nuevo disco.
Las particiones primarias, tienen una marca que le indica al sistema si es "activa" (arrancable). Evidentemente la particion primaria correspondiente a nuestro primer disco fisico, debe estar "activa" (opcion 2). En principio, esto no debe preocuparnos, ya que el propio FDISK, al crear la primera particion del primer disco, siempre la pone la marca de "activa". De todas maneras, saber que existe dicha opcion, por si acaso en algun momento nuestro sistema no arranca. La opcion 2), solo pone la "marca". No es "destructiva", es decir, no hay perdida de datos.
* La opcion 3) corresponde a borrar una particion. O bien borrar unidades logicas dentro de una particion extendida (sub-partiones). Mi consejo es siempre el mismo. Si borramos y deseamos crear una nueva, lo primero, borrar y debemos salir y reiniciar la maquina, luego volver a entrar y crear la particion que queriamos.
NOTA: (para quien tenga ademas dispositivos SCSI). Recordar que le FDISK unicamente las unidades a las cuales la bios les ha asignado la INT 13 de acceso a disco. Las bios (todas) por diseño, unicamente asignan dicha interrupcion a los 8 primeros discos que se encuentran. Por tanto, el FDISK está limitado a esos 8 primeros discos ("discos" fisicos). Esto no causa problemas a uien tenga unicamente unidades IDE, ya que estas estan limitadas a 4 posibles discos. Bien en el caso de tener mas de 8 discos fisicos, para "particionarlos" con FDISK, se hace necesario "quitar" alguno para que el nuevo disco entre en los limites de los 8 anteriores. Particionarlo, y luego volver a poner las unidades quitadas. Otra solucion sería utilizar herramientas de terceros para particionarlos. (normalmente las utilidades que nos sumnistran con las tarjetas SCSI, suelen tener un software de este tipo, debido a que son conscientes de esta problematica).
* Conocemos ya un poco de FAT 16 y FAT 32, y ademas hemos visto las particiones y como crearlas. Ahora que analizar un poco cual es la mejor de dichas opciones. Existe mucha discusion sobre el tema y entiendo que es debida a una mala informacion (o desinformacion) por parte de Microsoft al anunciar la FAT 32. Los programas por ejemplo, de instalacion de windows 98, nos dicen que nuestro sistema irá un 33% mejor. Esta frase es totalmente incorrecta. La frase "real" debería ser: "puede ahorar hasta un 33% de espacio en disco, penalizandose (ligeramente, dependiendo del sistema) los tiempos de acceso a disco". Vamos a ver esto ultimo con detalle.
FAT 16 y FAT 32: VENTAJAS E INCONVENIENTES
* A astas alturas supongo que tenemos "asimilado" un poco los capitulos anteriores. Es necesario el haberlo intentado al menos (sé que me explico muy mal, y menos sin una "pizarra" para dibujar, pero al menos se debe intentar comprender.....). Por tanto empezemos a "pensar" un poquito:
1) La FAT es importantisima. Se utiliza para todo. Es el "indice" de como están los archivos en el disco duro. Tanto para leer un archivo o para grabarlo, se hace necesario "varios" accesos a la FAT.
2) Y ademas es peligrosa, ya que si se daña perderemos informacion.
3) Por tanto el sistema operativo "intenta" tenerla en memoria siempre para ahorrar accesos a disco (debido al punto 1). Y ademas una vez que se "actulice" por la grabacion de un archivo, intenta escribirla inmediatamente a disco (debido al punto 2).
** El punto 3) nos implica varias cosas. Pensemos un poco ¿que tamaño real tiene la FAT?. Recordemos que la FAT 16 tiene un maximo de 65535 entradas cada una de 16 bites (2 bytes). Es decir, tiene un tamaño maximo de 128 Kbs. Como existen 2 FAT por seguridad, es un tamaño maximo de 256 Kbs. Totalmente aceptable para tenerlo en memoria y actualizarla a disco en el momento en que es actualizada en memoria.
Pero ¿y en FAT 32?... pues muy mal: un disco tipico de 3,2 Gb, tiene 800.000 entradas en la FAT (en FAT 32). Y como es FAT 32, son 32 bites (4 Bytes). Es decir en total 3,2 Megas y por dos copias de la FAT son: 6,4 megas que el sistema intenta tener en memoria para no penalizar los accesos. Y ademas si actualizamos un fichero, intenta escribirla inmediatamente en disco.
** CONCLUSION:
A) PENALIZACION
1) Se utiliza bastante mas memoria real para FAT 32 que va en detrimento de la memoria "ejecutiva" de programas.
2) Se utiliza mas CPU en la busqueda en memoria de las entradas en la FAT (es dirente recorrese "muchas" veces una tablita de 65000 elementos maximo, que una tabla de casi un millon de elementos (al menos y dependiendo de que disco tengamos)
3) Se penaliza cada actualizacion de un archivo ya que hay que reescribir todo o parte de la FAT en disco. Y la FAT 32, es "bastante" mas grande.
4) El disco C: no puede ser FAT 32, si deseasemos instalar ademas un sistema operativo diferente de win98. Por ejemplo NT 4 obliga a que el disco de "boot" del sistema sea FAT 16, independientemente de donde instalemos el NT (es decir independientemente de si la particion real de instalacion es FAT 16 o NTFS).
B) VENTAJAS
1) Se puede superar el limite de 2 Gb por particion.
2) Como el tamaño de "cluster" es menor, "ahorramos" una cantidad de espacio en disco, que en este caso, y en un disco tipico de 2 Gb, sí que puede llegar al famos 33% anunciado por Microsoft. (depende del numero de archivos este ahorro de espacio).
** Las medidas tipicas de penalizacion en un disco, FAT 32 frente a FAT 16 con una CPU PII 400, on aproximadamente del 7% de perdida de rendimiento en FAT 32.
NOTA: Existe una manera de "ver" cuanto espacio tenemos "perdido" en el disco por culpa de los "cluster" de gran tamaño. Es sencilla:
a) Abrimos una ventana msdos
b) tecleamos: dir \*.* /s/v
Esperamos a que finalice, y nos mostrará los bytes utilizados por los archivos y los bytes "asignados" a esos archivos. La diferencia de tamaño es el espacio "perdido" que "casi, casi", podremos recuperarlo con una FAT 32.
**** Es interesante, ahora que hemos introducido un poco la FAT, particiones y discos, retomar "Desde que pulsamos el boton de nuestro PC...." en el punto en que la bios habia finalizado el reconocimiento, asignacion de IRQs, e inicializacion del hardware. Hemos introducido tambien, que la siguiente tarea era "cargar" el MBR del disco, que realmente es un mini-programa, y le había cedido el control a dicho programa.
Pero es importante saber, que hace la propia bios, inmediatamente antes de iniciar dicha carga. Como ha preparado la memoria real (por debajo del mega, ya que los sistema intel, arrancar siempre en modo real tal y como vimos anteriormente), para que el sistema operativo, el que sea, sea capaz de comenzar a hacer algo......
LA BIOS. PREPARACION DE LA MEMORIA REAL PARA INICAR UN O.S.
(esto hay que leerlo despacio... tiene su "miga", y si veis que es un poco lioso, la culpa es unicamente mia. Es un tema dificil de explicar, y tampoco es imprescindible para continuar con estos capitulos. Pero por "culturilla" lo cuento aquí).
* Bien, la bios ademas de la inicializacion del hardware, se encarga de crear una serie de estructuras en memoria y deja ademas en ella, las rutinas "minimas" para escribir en pantalla, manejar el teclado y acceder a disco.
Mas adelante veremos por ejemplo, que "cisco" se tiene que montar, solo para pulsar la letra "A" y que esta aparezca en pantalla.....
Aunque el procesador en modo real y en MsDOS no es multitarea, si pensamos un poco en la que está haciendo, si que "parece" que está hacindo multitarea. Pensar que mientras estamos tecleando algo, no solo lo muestra por pantalla, sino que a la vez, por ejemplo, está actualizando el "reloj" del sistema.... este es el ejemplo más sencillo. Un ejemplo que realmente sorprendió a todo el mundo de la programación, fué en los primeros años del MsDOS, cuando Microsoft sacó un programa residente "print". Recordad que en esa epoc ademas, las impresoras iban muy lentas.... pero maravillosamente con el comando print empezaba a imprimir un archivo, y dejaba "libre" la pantalla el teclado, con lo cual podiamos seguir haciendo cosas. Y la impresora mientras tanto, iba sacando hojas.....
Esta tontería que ahora no nos llama en absoluto la atención, causó furor en el mundo de la programacion. Inmediatamente a "destripar" el programa para ver dos cosas:
1) Como se creaban los residentes en MSDOS (no estaba "documentado")
2) Como hacer o "simular" una multitarea.
Ahora cualquier programador, sus primeros "pinitos" es construir residentes. No tiene ningun merito. Está ya perfectamente documentado.
* Pero la pregunta es ¿como podemos hacerlo?.
Relativamente facil. A base de manejar interrupciones (interrupciones de "software", no de hardware como las que vimos al principio de estos capitulos. Más adelante veremos estas interrupciones). Me explico: por definicion, una interrupcion, "interrumpe" el programa que se esté ejecutando y cede control a una rutina. En principio la que queramos. Entonces, sabemos que hay interrupciones cada cierto tiempo. Por ejemplo existe una interrupcion que se activa 11 veces por segundo y que se encarga de mantener el reloj de nuestro PC.
Si fuesemos capaz de que esa rutina de actualizcion del reloj, "ademas" de eso, por ejmplo, enviase una linea a la impresora.... pues ya tendriamos activo el "print". Genial idea.
Este es el concepto basico de multitarea: reparto de tiempos de una CPU entre varias tareas. Y la idea, para su epoca, no estuvo mal....
Pasemos ahora a ver las interrupciones "software".
INTERRUPCIONES SOFTWARE
En el diseño del primer procesador Intel de la serie X86 (de los cuales derivan por compatibilidad los Pentium actuales), se pensó en implementar por hardware dentro del procesador de una serie de interrupciones "software", que cada vez que se activasen se cediese el control a cierta rutina.
En dicho diseño, se definieron 256 posibles interrupciones. Y ademas la intruccion maquina INT para provocar una interrupcion. Por deficion, entonces se reservó el area de memoria mas "baja" de la maquina, es decir desde la direccion "cero" para contener las direcciones de esas 256 posibles rutinas (o programas que son llamados) de interrupcion.
Para el mundo "real" del procesador, una direccion de memoria es un "segmento" y un "desplazamiento". Es decir 4 bytes. Por tanto 256 * 4 = 1024. Es decir de la direccion 0 a la 1024 "fisica" de la memoria de nuestro PC, se reserva para tener 256 posibles direcciones de las rutinas de dichas interrupciones.
La manera de invocarlas por software en INT 21h (por ejemplo). Esto hace que el procesador salte a la direccion 21h * 4 y allí se encontrará a su vez con la direccion que apunta a la rutina que dá el "servicio" a la INT 21h.
Evidentemente no todas las posibles 256 interrupciones están ocupadas. No son necesarias tantas. Por tanto, las no ocupadas apuntan a una instruccion IRET (volver desde interrupcion). Es decir: no hacen nada. Pero está la posibilidad de que nosotros, en nuestro programa, "colguemos" en vez del IRET, una rutina nuestra que haga lo que queramos....
Bién, ppues lo que la bios hace, es "disparar" unas interrupciones "software" cada vez que sucede una interrupcion "hardware". Recordar que habia 16 IRQs (del la 0 a la 15).
La bios, lo que hace, es que cada vez que suceda una IRQ 0 a 7, dispara una interrupcion 50 a 57h "software". Igualmente las IRQs 8 a 15, disparan de la 70 a la 77h.
Por tanto esas interrupciones software, deberán contener la "direccion" del programa o driver que va a manejar dicha IRQ.
* Veamoslo con un ejemplo real. Recordad que habios dicho al ver las IRQs que la IRQ 1 era la de teclado. Entonces ¿que sucede al pulsar una tecla?. Bien lo primero que sucede es una IRQ 1. Esto interrumpe lo que esté haciendo el procesador y tal y como acabamos de comentar, esto disparará la interrupcion software 51h. Esta interrupcion software, entonces lo que provoca es que el procesador, busque en la direccion de memoria 51h * 4, y pega un salto a la zona de memoria que esté apuntada por el contenido de esa direccion. Se supone que en esa zona de memoria "debe" haber un programa, o
una rutina que se encarga de analizar la tecla pulsada y ademas de "sacarla en pantalla". Efectivamente, esa rutina existe, y es la propia bios quien la ha puesto allí.
Realmente el tema es un poco mas complicado. La INT 51h lo que hace a su vez, es invocar a la INT 09h. (tambien software). Esta, mediante los comandos IN vistos anteriormente, lee del puerto de teclado. Allí puede saber la tecla pulsada y no solo eso, sino admeas si tenemos a la vez pulsada otra tecla (MAY, CTRL, ALT), y ademas si en ese momento se está pulsando o "soltando" la tecla. Es decir realmente al pulsar una tecla, suceden 2 interrupciones una en le momento de pulsarla y otra en el momento de soltarla -y otra más por cada ciclo de tiempo que la tenemos pulsada-.
Una vez analizada la tecla pulsada, hay que sacarla en pantalla. Bien, el "servicio" de video, lo ha definido tambien la bios, en la interrupcion 10 h. Por tanto, la INT 09h lo que hace una vez analizada la tecla pulsada en cuando tengamos disponible ya el caracter, se emite una INT 16h que a su se emite una INT 10h.
Y todavia es mas complicado. Si pulsamos un CTRl-G dá un "pitido" el altavoz. Por lo tanto ademas, debe analizar dicha rutina, si es algun caracter especial como el anterior. Si lo fuese, ahora se deben emitir las correspondiente interrupciones tambien software para "activar" el altavoz. Esta activacion, será tambien mediante comandos IN y OUT a unos puertos que son los correspondientes al "timer" para generar una onda de sonido hacia el altavoz del PC.
*** Todos un verdadero lio ¿no?.
Bien, el encargado de situar estas rutinas "basicas" y de generar la tabla de interrupciones es la bios.
Ademas, pensemos que lo hace "casi" instantanemanente nada mas encender el PC. Si no lo hiciese, no podriamos ni "ver" las letras en la pantalla. De echo, hasta que no ha definido la INT 10h de video, no podemos ver nada en pantalla. Y hasta uqe no estén activas la INT 09 y 16h, no se podrá pulsar el teclado.
Y vemos que eto ultimo es casi instantaneo!!!!.
Buen cisco se monta la bios nada mas encender nuestro PC, ¿no?
RESTO DE RUTINAS EN MEMORIA REAL
Al igual que define los accesos a pantalla y teclado, la bios nos dá soporte "minimo" para acceso a disco. INT 13h, etc....
Cuando se emite una interrupcion, se le pasan parametros (contenidos) en los registro generales del procesador. Por tanto cada INT, por decirlo de alguna manera, admite "parametros" o ordenes especificas de que hacer. Por ejemplo, la de acceso a disco, espera, en un regustro general, si es en escritura o en lectura. Y en otros registros generales, el numero del cilindro, la cabez y el sector que queremos leer. Y por supuesto, la direccion de memoria en donde queremos que nos deje el dato. Y ciuantos "bytes" hay que "traer" del disco.
Lo importante en esta parte, que acabamos de ver, es que aunque "todavia" no se ha cargado nada del sistema operativo, la bios, ya ha sido capaz de deajrnos perfectamente preparado nuestro hardware y nuestra memoria con las rutinas basicas para empezar a hacer algo.
Y ahora viene ese "algo". Hay que empezar a cargar el sistema operativo. Empieza la busqueda......
CARGA DEL SISTEMA OPERATIVO
La bios ha terminado sus tareas y ahora decide cargar el sistema operativo. Empieza la busqueda por las unidades de busqueda que tenga definidas en los parametros de la bios. Por defecto, suele ser A,C. Es decir, intenta cargar desde disquete y si no puede lo hace desde el disco C:.
Para ello, lee el primer sector fisico del disco: cilintro 0 cabeza 0 sector 1. Lo carga en memoria y le cede control para su ejecucion.
Vamos a imaginar que el sistema que queremos cargar, es el windows 98. Bien, windows 98 comienza su carga desde un MsDOS, por tanto lo primero que se cargaría sería un MsDOS. O bien, tambien podemos cargar un MsDOS desde el disco de inicio de win98, o desde un disquete formateado con el parametro /S (es decir, contiene el "sistema").
ARRANQUE DESDE DISQUETE
Supongamos ahora que la carga es desde disquete. El sector de boot del disquete (el cual es creado con el format), contiene (si ha sido formateado con el sistema - parametro /S -), un mini programa que lo unico que sabe hacer es buscar un archivo oculto en esa unidad de disco, llamado "IO.SYS", cargarlo en memoria y cederle control.
* EL IO.SYS inicia la carga y ejecucion. Lo primero que busca es otro archivo oculto en la misma unidad llamado MSDOS.SYS. Este archivo no es un archivo de ejecucion, sino un archivo de parametros del sistema que en cualquier momento podemos ver (no es aconsejable tocarlo), con un editor. Mas adelante veremos el posible contenido de este archivo.
* A continuacion, el IO.SYS, busca en el directorio raiz de esa unidad, un archivo llamado CONFIG.SYS. Sí el archivo existe, lo lee y ejecuta las instrucciones que lleva dicho archivo. Basicamente el config.sys, lo que puede contener son parametros del propio sistema y sobre todo, carga de drivers de dispositivo. No es obligatorio que exista. Solo si lo encuentra lo ejecuta.
* A continuacion, el IO.SYS, busca el COMMAND.COM. Es decir al interprete de comandos. No es obligatorio (pero sí lo mas usual), que el command.com sea el interprete de comandos. En el archivo config.sys que acaba de ejecutar previamente el IO.SYS, podria haberse cambiado este interprete, y decirle al sistema que utilice otro.
* Supongamos que es el COMMAND. entonces lo carga en memoria y le cede control para su ejecucion.
* El COMMAND, busca a su vez la existencia de un archivo llamado AUTOEXEC.BAT tambien en el directorio raiz de la unidad de arranque y lo lee para ejecutar los comandos que allí existan. Dichos comandos, serian basicamente programas (no pueden ser ya drivers de dispositivos) y algun parámetro de configuracion (como el PATH por ejemplo) propio del interprete de comandos. Al igual que el CONFIG.SYS no era obligatorio, el AUTOEXEC.BAT tampoco lo es.
NOTA: debido a que en España o en otros paises distintos de USA, se utilizan tablas de codigos especiales (para los caracteres especiales, por ejemplo los acentos, la "ñ", o caracteristicas regionales) y teclados de acuerdo con el idioma, es obligado en este caso el tener CONFIG.SYS y AUTOEXEC.BAT con las "pocas" lineas de comando que definen tanto las tablas de codigos como el teclado. Esto sería lo unico obligatorio. Todo el resto sobra y son herencias del antiguo MsDOS. Por tanto mi consejo, es no andar tocando estas cosas. Es muy facil, que windows pierda prestaciones por haber incorporado lineas indebidas en estos archivos. Incluso todavia, hay "viejos" programas instaladores, que tocan estos archivos y lo unico que hacen es dañar nuestra configuracion de windows.
** Bien, si hemos arrancado desde disquete, esta habrá sido la secuencia de arranque, y el sistema se nos queda en este punto.
ARRANQUE DESDE DISCO DURO
El arranque desde disco duro es ligeramente diferente. Lo primero, al igual que en el disquete, carga el primer sector del disco duro (cilindro 0, cabeza 0, sector 1). Pero en este caso, tal y como debemos recordar de capitulos anteriores, este sector en un disco duro es el MBR (Master Boot Record).
Como tambien es un miniprograma, se carga en memoria y comienza su ejecucion. Pero este miniprograma lo unico que sabe hacer, es localizar la particion activa del disco duro (la primaria y "activa"). Una vez que la localiza, es como si ahora estuviesemos en la secuencia de arranque desde disquete que acabamos de ver.
Es decir, carga otra vez, el "primer" sector de esa particion, que al igual que el primer sector de un disquete, contiene un miniprograma que ha sido generado con el format /S, que es "identico" al que tiene un disquete. Por tanto, inicia la carga del IO.SYS, y la misma secuencia de carga que la definida anteriormente.
** Es necesario, recordar de nuevo: en un disco duro, hay dos sectores de boot. Uno el MBR que ha sido creado con FDISK, y otro el "boot" de la particion, que ha sido creado con el FORMAT. Ambos son necesarios para el inicio del sistema operativo.
* Vamos a ver a continuacion, por parametros de configuracion en los tres posibles archivos de los que hemos hablado. MSDOS.SYS, CONFIG.SYS y AUTOEXEC.BAT. Pero unicamente vamos a ver en este momento los parametros de configuracion. No los posibles drivers (config) o programas (autoexec) que pueden ser ejecutados o cargados desde allí.
PARAMETROS DE CONFIGURACION - MSDOS.SYS
** Contiene dos secciones diferenciadas.
La seccion [Paths] puede contener las siguientes opciones:
HostWinBootDrv=<Disco en donde esta instalado windows>
Defecto: C
Proposito: Especifica la localizacion de en que disco está instalado windows.
UninstallDir=<Disco de "desistalacion">
Defecto: C
Proposito: Especifica la localizacion de los archivos W95undo.dat and W95undo.ini. Son los ficheros necesarios para desistalar windows cuando se ha seleccionado la opcion de parmitir desistalar en caso de una actualizacion.
WinBootDir=<Directorio de windows>
Defecto: Directorio donde reside windows (por ejemplo, C:\WINDOWS)
Proposito: Indicar al cargador del sistema desde donde debe inicarse windows.
WinDir=<Directorio de windows>
Defecto: Directorio especificado en la instalacion (por ejemplo, C:\WINDOWS)
Proposito: Localizacion del directorio de windows especificado durante la instalacion.
====================================================================
La seccion [Options] puede contener las siguientes opciones, o bien pueden ser insertadas manualmente.
NOTA: El valor "booleano" que aparece a continuacion, indicará un "0" para NO y un "1" para SI.
AutoScan=<Numero>
Defecto: 1
Proposito: Define cuando o no, Scandisk va a ejecutarse debido a un apagado de maquina incorrecto. Una opcion de 0 indica no ejecutar Scandisk. 1 indisca preguntar antes de ejecutar Scandisk; 2 indica no preguntar antes de ejecutar Scandisk, pero preguntar antes de "fijar" posibles errores si estos fuesen encontrados.
BootDelay=<Segundos>
Defecto: 2
Proposito: Cantidad de segundo en los que aparece la frase "Iniciando windows" y por tanto permite pulsar F8, en windows 95.
NOTA: Esta opcion no está soportada en windows 98.
BootSafe=<Booleano>
Defecto: 0
Proposito: Si tiene valor 1, el PC arrancará en el "modo a prueba de fallos".
BootGUI=<Booleano>
Defecto: 1
Proposito: Si tiene el valor 1, arrancará windows automaticamente, con el valor de 0, una vez ejecutado el config.sys y el autoexec.bat, permanecerá en el simbolo del sistema. En este caso, será necesario teclear "win" para que windows cargue la interfaz grafica.
BootKeys=<Booleano>
Defecto: 1
Proposito: Un valor de 1 activa el uso de las teclas de funcion (F4, F5, F6 y F8). Un valor de 0 desactiva el uso de teclas de funcion durante el proceso de arranque de windows.
NOTA: Colocando BootKeys=0 sobreescribe el uso de BootDelay=n.
BootMenu=<Booleano>
Defecto: 0
Proposito: Colocando un 1, activa el que siempre aparezca el menú de seleciion de incio. Si está colocado a 0 se debe pulsar F8 cuando aparezca la frase "Iniciando windows 95" (o pulsar y mantener pulsada la tecla CTRL en windows 98 al inicio del PC), para invocar el menú de inicio.
BootMenuDefault=<Numero>
Defecto: 1 si el sistema se está ejecutando correctamente
3 si el sistema falló en el arranque anterior.
Proposito: Se utiliza para seleccionar la opcion del menu de incio de windows que se ejecutará por defecto.
BootMenuDelay=<Numero>
Defecto: 30
Proposito: Este valor es usado para colocar el numero de segundos que el sistema va a esperar en el menú de inicio de windows, antes de arrancar automaticamente sino seleccionamos ninguna opcion.
NOTA: Esta opcion no tiene sentido a no ser que la opcicion BootMenu=1 haya sido añadida en la seecion [Options].
BootMulti=<Booleano>
Defecto: 1
Proposito: Un valor de 0, desactiva la opcion de "multi-boot" o arranque del "antiguo" o previo sistema operativo. Un valor de 1 activa tanto la tecla F4 como la posibilidad en el menú de seleccionar laopcion de arrancar el sistema operativo anterior.
BootWarn=<Booleano>
Defecto: 1
Proposito: Un valor de 0 desactiva el aviso del modo a prueba de fallos al ejecutarse el menu inicio.
BootWin=<Booleano>
Defecto: 1
Proposito: Colocando un 1 fuerza a windows a cargarse en el incio. Un valor de 0 desactiva windows como su sistema operativo por defecto. (esto solo tiene sentido si teneiamos instalado MS-DOS 5.x o 6.x previamente en nuestro PC)
NOTA: Presionando F4 invierte el defecto de arranque solo si BootMulti=1. (Por ejemplo, presionando F4 con una opcion 0, fuerza a Windows 95/98 a arrancar).
DoubleBuffer=<Booleano>
Defecto: 0
Proposito: Colocando un 1 activa el "double-buffering" para los controladores que necesiten esto (por ejemplo los controladores SCSI). Colocando un 2, es una opcion incondicional que activa el "double-buffering" mirando cuando el controlador es necesario o no.
DBLSpace=<Booleano>
Defecto: 1
Proposito: Un valor de 1 carga automaticamente el DBLSPACE.BIN. Un valor de 0 impide su carga.
NOTA: Windows 95 usa o Dblspace.bin o Drvspace.bin si alguno de ellos está presente en el directorio principal de C: Para desactivar esta opcion sino tuviesemos discos comprimidos, debe forzarse un valor de 0. Por ejemplo:
DBLSpace=0
DRVSpace=0
DRVSpace=<Booleano>
Defecto: 1
Proposito: Mismo sentido que la opcion anterior pero con DRVSPACE.BIN.
LoadTop=<Booleano>
Defecto: 1
Proposito: Un valor de 0 no permite a windows cargar COMMAND.COM o DRVSPACE.BIN o DBLSPACE.BIN por encima de los 640 Kbs. Si tenemos problemas de compatibilidad con alguna vieja aplicacion DOS, es conveniente probar a forzar un cero en esta opcion.
Logo=<Booleano>
Defecto: 1
Proposito: Si tiene el valo 1 hace que aparezca el logo de windows al arrancar. Con el valor 0 se desactiva el logo de windows. Un valor de cero, libera una serie de interrupciones software que pudieran causar incompatibilidades con antiguos TSR del modo DOS o incompatibilidades con cierto manejadores de memoria de terceros.
Network=<Booleano>
Defecto: 0
Proposito: Con un valor 1, nos paparecerá la opcion "Modo a prueba de fallos con soporte de RED" como una opcion en el menu de inicio.
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 practicamente ya, no existen).
* NOTA IMPORTANTE: Ademas 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 ademas vigilar despues de cualquier instalacion 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 direccion en MsDOS (debido al funcionamiento del hardware, es decir debido al funcionamiento del propio procesador de Intel en modo real), estaba formada por una direccion 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 direccion real. (repasar los capitulos anteriores).
Igualmente recordemos, que por diseño, IBM definió la direccion 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 direccion 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 version 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 ademas 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 direccion 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 direccionaba mediante la programacion del chip, cambiando la direccion de un puerto, y nos hacia ver una ventana de 64 Kbs en la direccion 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 direccion 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 direccion real que podia expresarse con 20 lineas de direccion: 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 nucleo (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 ademas 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 ademas obliga a tener el HIMEM.SYS)
OTROS PARAMETROS DEL CONFIG.SYS
** Lo primero y mas importante, es recordar que NO hac falta ningun parametro en el config.sys (excepto el DOS=HIGH,RAM visto en el capitulo anterior).
** Igualmente quiero insistir en tres cosas:
1) Estos parametros unicamente tendrán efecto en MsDOS no en windows.
2) Cuando me refiero a MsDOS, me estoy refiriendo a MsDOS "puro". Las ventanas MsDOS bajo windows no se ven afectadas por estos parametros. Incluso la apertura de ficheros se hace a traves de windows en estos casos.
3) Lo que he comentado en los puntos 1) y 2), es la teoria. La practica nos demuestra, que efectivamente, si que influyen en windows: pero NEGATIVAMENTE. Es decir, jugando con estos parametros, lo unico que podemos conseguir es que windows funciones peor.
Por curiosidad vamos a ver estos parametros y comentar su efecto tanto en MsDOS como en windows.
NOTA: Algunos de los parametros que veremos a continuacion, pueden terminar en la palabra HIGH. Esto indicará que el MsDOS lo cargará en memoria alta si tenemos activo el EMM386.
Pero esto no es necesario (y ademas es contraproducente), si ademas hemos especificado el parametro DOS=HIGH,UMB que vimos anteriormente, el propio MsDOS ya cargará automaticamente en memoria alta y sin necesidad de "forzar" esta situacion.
ACCDATE=disco1+|- disco2+|- ....
Nos guardará la fecha de la ultima vez que hemos accedido a los archivos de un disco o nó (en funcion del + o del -). Este parametro no tiene efecto en windows, ya que por defecto windows nos informa de estos accesos.
BREAK [ON|OFF]
Sirve para activar la manera de "parar" un proma MsDOS.En un programa MsDOS, pulsando CTRL-C podemos casi siempre teclear CTRL-C y pararlo. Pero el MsDOS, unicamente chequea el que hayamos pulsado CTRL-C, cuando vá a escribir en pantalla o cuando va a leer desde teclado. Si nuestro programa no está haciendo ninguna de estas dos cosas en ese momento, no se parará. Si tenemos BREAK ON en el config.sys, el MsDOS tambien chequerá el que pulsemos CTRL-C cuando va a leer o escribir en disco. De esta manera, aunque nuestro programa no escriba en pantalla, se supone que al menos, accederá al disco y por tanto de esta manera podremos pararlo.
No tiene ningun efecto en windows, y este parametro no será pernicioso tampoco para windows. Es conveniente tenerlo.
NOTA: En cualquier ventana MsDOS, podemos teclear BREAK y veremos la situacion en la que estamos.
BUFFERS=n[,m]
BUFFERSHIGH=n[,m]
Assigna memoria "real" para contener bufferes de disco. Recordad que cada sector de disco son 512 bytes, por tanto cada buffer que asignemos, nos robará medio k de la memoria real.
No tiene ningun efecto bajo windows ni bajo las ventanas MsDOS bajo windows. Unicamente tiene efecto en MsDOS puro. Y tambien tiene efecto al "arrancar" windows, antes de que este entre en modo protegido. Antes de que entre el procesador en ese modo, se está utilizando todavia el antiguo sistema de apertura y carga de ficheros en MsDOS. Por tanto se ahorraria "algo" de tiempo al arrancar windows, si este parametro fuese elevado.
Mi consejo es NO ponerlo. Solo sirve para ahorrar unos segundos en el arranque de windows. Por contra, nos disminuirá muchisimo nuestra memoria real. Recordad que esta memoria es "preciosa", no solo por la posibilidad de rodar antiguos programas o juegos MsDOS en ventana que requieren mucha memoria, sino tambien porque el propio windows necesita "parte" de la memoria real para cargar ciertas secciones de DLLs (normalmente DLLs de 16 bites heredadas del 3.1), pero de todas maneras, influye negativamente en las prestaciones de windows el tener "poca" memoria real.
DEVICE=
DEVICEHIGH=
Con estas lineas cargamos un dirver de dispositivos. Ya hemos comentado que windows, excepto el HIMEM.SYS y el EMM386, *NO* necesita ninguno. Y no es conveniente tener *ninguno*.
El poner alguno, indica que es un "viejo" programa o necesario para un "viejo" dispositivo. Por tanto esto influye negativamente en el comportamiento de windows.
En caso de tener que poner algun driver (solo en caso de "extrema necesdad), podemos utilizar el DEVICEHIGH (en vez del DEVICE), en este caso y una vez que ademas hemos utilizado el HIMEM y el EMM386.
Casi (pero no todos) todos los drivers admiten funcionar en memoria alta. Existen especificos (sobre todo los de acceso a las antiguas tarjetas SCSI, y alguno de red en modo real), que no funcionaran o provocarán cuelgues aleatorios si los cargamos en memoria alta.
La instruccion DEVICEHIGH admite ademas la "region" de carga (con el paramtro /L, pero es opcional). Se llama "region" de carga, al numero del posible hueco en memoria superior. Recordad que en el capitulo anterior, y en el de memoria real, comentamos que hay huecos en la memoria superior que se pueden utilizar, si hemos puesto el EMM386 con el parametro RAM y utilizamos DOS=UMB. Evidentemente, como en teoria podemos tener varias "bios" de varias tarjetas en esos huecos de memoria, puede que no queden "contiguos". Si no quedan contiguos, admiten "numeracion". Pues bien, podríamos especificar así el "numero" del hueco UMB.
-
DOS=HIGH|LOW[,UMB|,NOUMB][,AUTO|,NOAUTO]
No conviene andar jugando con este paramtro. Unicamente poner DOS=HIGH,UMB si utilizmos EMM386.
El intentar forzar la memoria de otra manera es unicamente para alguna situacion muy especifica (y totalmente improbable).
DRVPARM=
Unicamnete a utilizar para disqueteras *no* estandard. En este caso, normalmente el fabricante nos indicará que parametros debemos especificaer aquí. Evidentemente se caé de su peso, que no debemos tocar esto para las disqueteras estandard que nos dan en nuestro PC.
FCBS=x
FCBSHIGH=x
Es un parametro viejisimo. Herencia del MsDOS 1.0 (del año 82). Este MsDOS abría los archivos mediante la tencica de "File Control Block". Es decir era necesario crear en memoria una estructura de control y pasarselo a las funciones de acceso a disco. Esto ya no se utiliza (desde hace mas de 15 años). Pero por cuestiones de compatibilidad con los posibles programas MsDOS del año 82 que nos quedasen, todavia existe esta opcion.
FILES=nn
FILESHIGH=nn
Indica el numero maximo de archivos que puede tener abierta una aplicacion MsDOS.
Mismos comentarios que he realizado para los BUFFERS:
No tiene ningun efecto bajo windows ni bajo las ventanas MsDOS bajo windows. Unicamente tiene efecto en MsDOS puro. Y tambien tiene efecto al "arrancar" windows, antes de que este entre en modo protegido. Antes de que entre el procesador en ese modo, se está utilizando todavia el antiguo sistema de apertura y carga de ficheros en MsDOS. Por tanto se ahorraria "algo" de tiempo al arrancar windows, si este parametro fuese elevado.
Mi consejo es NO ponerlo. Solo sirve para ahorrar unos segundos en el arranque de windows. Por contra, nos disminuirá muchisimo nuestra memoria real. Recordad que esta memoria es "preciosa", no solo por la posibilidad de rodar antiguos programas o juegos MsDOS en ventana que requieren mucha memoria, sino tambien porque el propio windows necesita "parte" de la memoria real para cargar ciertas secciones de DLLs (normalmente DLLs de 16 bites heredadas del 3.1), pero de todas maneras, influye negativamente en las prestaciones de windows el tener "poca" memoria real.
-
INSTALL=
INSTALHIGH=
Equivale exactamente lo mismo que cargar un programa (no un dirver de dispositivo), en el AUTOEXEC. Si estas lineas se ponen, se ejecutarán siempre al final del config, independientemente de en donde las hayamos situado.
-
LASTDRIVE=
LASTDRIVEHIGH=
Indica cual es nuestra "ultima" unidad o letra de disco. Este parametro afecta a windows, por lo que no conviene tocarlo. En el antiguo MsDOS 6.22, si no lo poniamos por defecto, era la F:. En el MsDOS de windows 95 / 98, por defecto es la letra Z:, por tanto no debe tocarse.
NUMLOCK=[ON|OFF]
Indica si queremos que la tecla de bloqueo del teclado numerico esté o no activa. No es necesario ponerlo y se asumirá lo que esté definido en la bios de nuestra maquina.
REM
Escrito por delante de cualquier linea, la convierte en linea de "comentarios". Por tanto no se jecutará la instruccion que va a continuacion.
SET variable=xxxxxxxx
Permite especificar variables de entorno. En los antiguos MsDOS, esto era posible unicamente en el AUTOEXEC.BAT. Actualmente es posible en ambos sitios: en el config y en el autoexec.
SHELL=[[disco:]path]programa [parametros]
Este comando *si* es importante. No es necesario, pero algunas veces nos puede ayudar a solucionar algun problema.
Aquí se define el "interprete de comandos". Normalmente sabemos que dicho interprete es el COMMAND.COM pero puede ser perfectamente otro interprete que no sea de MS (existen interpretes de comandos de terceros).
Por defecto, si no ponemos la linea, asume que es el COMMAND.COM. Pero recordad que el command.com, admite parametros. Podeis verlo dando command /? en una venta MsDOS. Imaginar que quereis que por defecto TODOS los command (o ventanas MsDOS) de vuestra maquina se abran con unas determinadas caracrteristicas de tamaño de entorno ,etc... BIen en este caso, como queremos "todas", lo mas comodo es especificarlos en el SHELL del config.sys.
-
STACKS=
STACKSHIGH=
Define el numero de stacks (pilas) para el uso internos del MsDOS. No es conveniente ponerlo y no tiene ningun efecto en windows ni en ventanas MsDOS bajo Windows.
SWITCHES= /F /K /N /E[:n]
/K Fuerza un teclado "enhanced" como teclado normal.
/N Deja inactivas dirante el arranque las tecla F5 y F8 que nos permite "pasar" del archivo de comandos.
/E[:n] Si se usa sin el parametro :n indica que se debe suprimir la reasignacion de ciertas extensiones de la bios (EBIOS). No es conveniente tocar este parametro ya que puede tener efectos negativos en la memoria real de la maquina al forzar la carga de las extensiones de la bios en memoria baja.
PARAMETROS DE CONFIGURACION - AUTOEXEC.BAT
* Como introduccion (y casi, casi como unico resumen), podemos decir que el autoexec.bat se encarga, o puede encargarse de ejecutar cualquier programa MsDOS, así como de establecer las condiciones de "entorno" (ya las veremos mas adelante), de todo el MsDOS, y lo que es mas importante: de todo Windows. Esto ultimo, deriva de que Windows "hereda" todo el entorno que tenía al arrancar.
* Extrictamente este archivo no es necesario (al igual que el config.sys), pero por desgracia, el MsDOS y el Windows, estan pensados para configuraciones regionales USA (así como el teclado). Por tanto como nuestro sistema (y nuestro teclado) no está en USA, debemos incorporar unas pocas lineas, tanto en el config, como en el autoexec.
Recordemos que en el config eran:
device=C:\WINDOWS\COMMAND\display.sys con=(ega,,1)
Country=034,850,C:\WINDOWS\COMMAND\country.sys
Y en el autoexec.bat, son:
mode con codepage prepare=((850) C:\WINDOWS\COMMAND\ega.cpi)
mode con codepage select=850
keyb sp,,C:\WINDOWS\COMMAND\keyboard.sys
(en ambas me estoy refiriendo a "España" y teclado Español. Para configuraciones en Latino America, estas lineas variarán ligeramente)
Basicamente, en estas lineas, estoy configurando la tabla de codigos, como la 850, el país España como 034, y el teclado como español "sp".
** NOTA: Es importante, sobre todo si vamos a tener más de un sistema operativo, es decir, si nuestro sistema va a convivir con NT 4 o con Windows 2000, que estas lineas esten correctamente definidas.
El problema nos puede venir causado, porque si no tenemos correcta la pagina de codigos en Windows 98, los caracteres acentuados y caracteres locales (como la "ñ") aunque la veamos correctamente en pantalla, se almacenan con la tabla de codigos por defecto del MsDOS.
Entonces veríamos correctamente los nombre de archivos acentuados, pero internamente el nombre estaría almacenado con otro codigo.
En esta situacion, si instalamos windows NT o Windows 2000, estos, al configurarse (recordad que son independientes y no se apoyan en el MsDOS), se configuran con la tabla correcta de codigos: 850. Por tanto los caracteres acentuados en nombres de archivos, serán otros. De esta manera, un scandisk desde windows 98 a la particion NT, nos dará errores en los nombres de archivo, y lo que es mas grave: intentará arreglarlos (estropeando el correcto desde "su" sistema). Exactamente igual nos pasará desde windows 2000.
CONDICIONES DE ENTORNO
* Se entiende por entorno, auqellas variables que son comunes a todo el sistema. Se heredan entre los procesos.
* En general no son necesarias, excepto para programas particulares que las vayan a utilizar.
Las variables que queramos que se vean en "todo" el sistema y que puedan ser leidas por un programa, se asignan en el autoexec mediante el comando SET. Esto lo utilizan muchas aplicaciones.
La variable más curiosa de entorno, es la TEMP. Esta la utilizan desde el comienzo del MsDOS, muchas aplicaciones, y en particular, tambien la utiliza windows.
Por defecto, sino está definida, el propio MsDOS le asigna el contenido C:\WINDOWS\TEMP y por costumbre desde los inicios del DOS, esta carpeta se utiliza para escribir en ella ficheros temporales que necesiten las aplicaciones, y que por definicion pueden ser borrados en cualquier momento. Los programas o aplicaciones bien realizadas, deberían ademas ser las responsables de borrarlos. Pero esto, quizá sea mucho pedir...
Tal y como estabamos comentando con el entorno, nosotros podemos definir en el autoexec otra localizacion de la carpeta TEMP. Lo mas normal es tener:
SET TEMP=C:\TEMP
y a su vez tener creada la carpeta TEMP en C:.
** Una de las variables de entorno mas importante en el PATH (camino). Cuando tecleamos un programa para su ejecucion, tanto el MsDOS como Windows, buscan el programa en la carpeta en donde estamos en ese momento, y si no lo encuentran, lo buscan en el "camino" que esté definido en nuestra variable PATH.
Por defecto, sino especificamos un path, en windows por defecto el path es C:\WINDOWS;C:\WINDOWS\COMMAND (se debe tomar nota, que los distintos caminos, se separan por punto y coma).
Como PATH, ademas, es una variable de entorno, puede ser asignada mediante el comando SET. Es lo mas comodo. Imaginar que queremos "añadir" al PATH que tuviesemos en un momento determinado, la carpeta C:\KK. Bien, lo mas sencillo sería escribir:
SET PATH=%PATH%;C:\KK
Fijaros que lo que estamos haciendo, es decirle que el nuevo PATH, es igual al anterior (en este caso, se pone %PATH% -es decir encerrado entre simbolos %), y a continuacion, separado por punto y coma, el camino que queremos añadir.
NOTA 1: Para ver el PATH que tenemos en un determinado momento, podemos abrir una ventana MsDOS y teclear simplemente PATH. Esto nos mostrará el contenido del PATH. Iguelmente en una ventana MsDOS, si tecleamos el comanto SET nos mostrará todas las variables de entorno, y en particular el propio PATH, ya que esta es una variable de entorno.
NOTA 2: Cuando dentro de windows, vamos a Inicio->Ejecutar y tecleamos el nombre de un programa, windows primero buscará en C:\WINDOWS\SYSTEM y si no lo encuentra, a continuacion buscará en el PATH.
EMPIEZA LA OPTIMIZACION DE NUESTRO SISTEMA
Recordar que el directorio de archivos temporales, "debe" estar vacio. Si tiene muchos archivos, degrada de una manera apreciable las prestaciones y velocidad de windows. Es conveniente borrarlo de vez en cuando. Y ahora la pregunta del millón: ¿no podriamos utilizar el propio autoexec.bat, para que cada vez que arranquemos, sea él el encargado de "limpiar" esta carpeta?.
Pues sí podemos y "debemos" hacerlo.
Una manera muy sencilla de hacerlo, es incorporar las siguiente lienas de codigo en nuestro autoexec.
if not exist c:\temp\*.* goto cont0
attrib c:\temp\*.* -s -h -r
echo S | del c:\temp\*.* >nul
:cont0
Esto nos borrará el contenido de la carpeta C:\TEMP. Si tuviesemos los temporales en otra carpeta (por ejemplo, en la carpeta por defecto de windows C:\WINDOWS\TEMP), deberemos sustituir C:\TEMP por el nombre de la carpeta que tuviesemos los temporales en nuestro sistema.
Es importante recordar ademas que debe sustituirse la "S" de la linea "echo S", por una "Y" (sin las comillas) si tuviesemos windows en Inglés.
CONFUSION EXISTENTE EN TORNO AL MSCDEX
En muchas consultas realizadas y debido a cierta confusion que existe con el MSCDEX y la posibilidad de ver o nó nuestra CDROM desde MsDOS puro, voy a hablar un poco sobre este tema.
Notas a tener encuenta:
1) No le hace falta a windows, que tengamos definido "nada" en nuestro config y autoexec, para ser capaz de ver la CDROM.
2) Si tuviesemos algo definido, es mas que probable que a windows no le quede mas remedio que acceder a nuestra CDROM, utilizando el viejo metodo de acceso de 16 bites, perdiendo entonces la capacidad de acceso en 32 bites. Ademas, tambien es mas que probable, que si nuestra CDROM fuese IDE, perdamos el acceso a 32 bites tambien en nuestro disco duro si este está en el mismo cana IDE.
* Con lo anterior, quiere decir: "cuidadito" con lo que tenemos o ponemos allí.
** Repasemos un poco el antiguo MsDOS, para entender como se accedía a una CDROM (sistema de 16 bites).
Para acceder a la CDROM, necesitamos dos componentes software:
1) Un driver de dispositivo (por ser driver, debe estar en el config.sys), que nos permite ver un dispositivo de tipo "stream" (o de flujo) como un dispositivo "record" (orientado a registro). Recordad que un CDROM es un dispositivo "stream" -como si fuese una unidad de cinta-.
2) Un programa (por tanto, montado en el autoexec), que sea capaz de acceder al dispositivo virtual montado en el punto 1), y devolvernos los datos como si fuese una unidad de "disco". Este programa es un estandard de Microsoft: el MSCDEX (pero podría ser cualquier otro y de echo existieron algunos durante la vida del antiguo MsDOS).
* A partir de ahora me voy a referir unicamente a los CDROM IDE. (la idea basica, de todas maneras, es igualmente extrapolable a los CDROM SCSI).
** Hasta que surgió windows 98, y nos incorporó un driver casi "universal" para todas las unidades de CDROM, era bastante normal en el MsDOS em deter
drivers del tipo:
DEVICE=C:\HITACHI.SYS /D:MSCD001 .... o
DEVICE=C:\PIOONER.SYS /D:......
Es decir un driver de nuestro fabricante de CDROM (normalmente lo identificamos por el parametro /D:MSCD001) en el config.sys para poder ver nuestra CDROM. Igualmente teniamos una linea del tipo MSCDEX /D:MSCD001 en el autoexec.
Fijaros que el nombre puesto en /D:MSCD001, puede ser cualquiera, con tal que sean el mismo en el driver del config y en el programa MSCDEX.
Bien, retomando el tema, estabamos diciendo que windows nos aporta un driver "casi" universal: el OAKCDROM.SYS (que podemos encontrarlo en el disco de inicio de windows 98, o bien en la carpeta C:\WINDOWS\COMMAND\EBD). Por tanto incorporando este driver en el config y a su vez invocando al programa MSCDEX, tendríamos acceso a la CDROM en modo MsDOS puro.
** Pero... debido a los problemas que he comentado al principio de este capitulo, esto está completamente desaconsejado. Perderiamos muchas prestaciones en nuestro sistema.
** Entonces, la pregunta es ¿como puedo acceder a la CDROM, al reiniciar en modo MsDOS, desde windows?. Bueno, y ademas, existe un problema: un driver de dispositivo, "debe" cargarse en el config.sys. Veamos tres posibilidades para solucionar este problema:
1) Cargar el OAKCDROM.SYS en el config de nuestro propio windows. Y *no* cargar el MSCDEX. Con esto evitamos que el acceso se haga a 16 bites. Posteriormente crearnos un archivo en nuestro directorio de windows, llamado DOSSTART.BAT que unicamente tuviese la linea de MSCDEX /D:MSCD001. Si este el archivo ya existiese, incorporarle dicha linea.
Esta solucion funciona, pero no me gusta por dos motivos: uno, consumo de memoria MsDOS (al cargar el driver anterior), que luego no sirve para nada bajo windows. Y segundo motivo, este tipo de drivers en combinacion con ciertas controladoras y unidades de CDROM, pueden causar inestabilidades al windows.
2) Utilizar algun programa de los llamados "cargadores" de drivers. Por ejemplo, Creative Labs, tenia en su servidor FTP, un programa llamado CTLOAD, que era capaz de cargar un driver una vez que estuviesemos en MsDOS y sin necesidad de incorporarlo en el config. La manera de cargarlo sería entonces:
CTLOAD C:\WINDOWS\COMMAND\EBD\OAKCDROM.SYS /D:MSCD001
MSCDEX /D:MSCD001
(y suponiendo que el programa CTLOAD, lo hemos dejado por ejemplo en C:\windows\command para que lo encuentre en el path).
Incorporando estas lineas en el DOSSTART.BAT citado anteriormente, tendriamos acceso a la CDROM al reinicar en modo MsDOS.
3) Tercera posibilidad: utilizar un config y autoexec propio y crear un acceso directo a un "command.com" desde el escritorio con ese config y autoexec propio que incorporte esas lineas cada una en su correspondiente archivo.
Tampoco me gusta, porque esto implica el tener que "mantener" otros config y autoexec.
La solucion mas "limpia" en mi opinion es la 2).
SE INICIA YA LA CARGA DE WINDOWS
Llegado a este punto, ya hemos visto un poco de la maquina, del procesador del MsDOS, y nos empiezan a "sonar" los terminos de memoria real, modo protegido, dispositivo PnP..... etc.
INTRODUCCION A SISTEMAS OPERATIVOS
Windows 98, a pesar de arrancar "sobre" MsDOS es un sistema operativo con todas las de la ley. No se apoya en MsDOS. Unicamente lo hace por motivos de compatibilidad en ciertas situaciones y para ciertos dispositivos que ya veremos mas adelante.
Por poner un simil con otros sistemas operativos, NT y Linux por ejemplo. Estos no se apoyan en MsDOS, pero para arrancar se apoyan en la Bios de la maquina. Siempre arranca la Bios. En Windows 95 / 98, hay un paso mas: primero arranca la Bios, posteriormente el MsDOS y por fin el Windows. El paso más es el MsDOS, pero debemos verlo de esta manera: como un "paso" más.
Es verdad que con posterioridad a la "patada" inicial, el NT y el Linux, montan su capa de abstraccion del hardware (HAL), y se olvidan totalmente, de la Bios. Y no utilizan sus recursaso para nada, y es más, ni se fian de como han inicializado los posibles dispositivos. Ellos los vuelven a verificar e inicializar.
Esto por desgracia, parece que se va a perder en la informatica. Existen ya distribuciones de nucleo de Linux, que "sí" se apoyan en las bios (evidentemente con nuestro consentimiento). Igualmente, parece que el futuro Windows 2000, tambien se va a apoyar en la bios (y en este caso, excesivamente por ahora -en la beta 3-).
** Veamos ahora los dos modos de funcionamiento del procesador "REAL" y "PROTEGIDO", y al final de esta parte, vermeos tambien el "MODO VIRUTAL 8086" que es el tercer modo de funcionamiento del procesador y que es el que nos dará soporte a las ventanas MsDOS desde Windows.
MODO REAL Y MODO PROTEGIDO
Vamos a repasar un poco más en detalle estos dos terminos, antes de empezar con la carga real de windows. Vamos a hacerlo así, debido a que windows, lo primero que hace es poner a trabajar a la CPU en modo protegido.
Hasta ahora, hemos visto el modo REAL. Recordemos que el procesador arranca siempre en este modo fundamentalmente por cuestiones de compatibilidad. Recordemos un poco sus caracteristicas:
1) La memoria está restringida a lo que podamos direccionar con 20 lineas de direcciones (por tanto 2 elevado a 20 posiciones de memoria direccionables = 1 Mega).
2) Hay zonas que obligatoriamente estan en uso por el hardware (la zona de video: segmento A000 a C000)
3) Existe una zona de vectores de intrrupcion (interrupciones software) en las direcciones de memoria desde la posicion 0 a la 1024 fisicas reales. (256 interrupciones, y cada interrupcion, 4 bytes. 2 para definir el segmento y 2 el desplazamiento). Esta table contiene las direcciones de las rutinas a las que saltará automaticamente el hardware: la CPU, cuando se le interrupa mediante una INT xx (interrupcion xx). Muchas de estas interrupciones software, realmente son "preparadas" por la bios de la maquina, y algunas de ellas, se disparan como consecuencia de una interrupcion hardware (IRQ). Lo IMPORTANTE es destacar, que el manejo de interrupciones lo hace la CPU ya que lo tiene implementado por hardware. Es decir "ella solita" salta a la correspondiente direccion de la tabla una vez que se produce la interrupcion. Ademas la CPU en el modo real "sabe" que esta tabla empieza fisicamente en el desplazamiento cero de la memoria fisica.
** ¿que hay que hacer para poner a trabajar la CPU en modo protegido?: pues muy poco. Se coloca en unos registros especificos la nueva direccion de la tabla de interrupciones (llamadas aquí "excepciones"), se crea una tabla con los descriptores de segmento en modo protegido y se le pasa su direccion tambien a otros registros especiales del procesador, se cambia ahora un bite de un registro de control de la CPU, y se realizá un salto "largo" (JMP FAR). A la vielta de ese salto, ya estamos en modo protegido.
** ¿pero realmente que és el modo protegido? Bueno, esto es un poco mas costoso de explicar en unas pocas lineas. Voy a intentar resumirlo.
La CPU en este modo nos dá tres cosas:
1) Control de procesos, Proteccion.
2) Proteccion mediante la memoria virtual y su mecanismo.
3) Virtualizacion del hardware.
CONTROL DE PROCESOS. PROTECCION:
Este es un nuevo concepto. Recordar que una direccion de memoria era un segmento y un desplazamiento.
Ahora suponer que lo que antes llamabamos segmento (16 bites), ahora es un indice (es decir vale, 1, 2, 3, 4,.....) y que la direccion real de memoria es lo que se indicque en una tabla (llamada tabla global o local de direcciones).
Es decir si nuestro segmento, contiene un 1, indica que realmente nos estamos refiriendo al contenido de la primera posicion de la tabla de direcciones. Este contenido se toma tal y como tomabamos el antiguo segmento, que sumado al desplazamiento, nos dá la direccion real.
Entonces lo que antes llamabamos segmento y que ahora contiene un indice, le cambiamos de nombre: pasa a llamarse: "Descriptor".
Y ademas, lo modificamos un poco: por tener 2 bites, puede tener un numero desde 0 a 65535. ¿y nos hacen falta 65535 elementos de direcciones?. Probablemente no. Entonces vamos a limitarlo. Supongamso que utilizamos unicamente 13 de los 16 bites. Con esto tendriamos unicamente 8192 posibles elemento de la tabla de direcciones. Nos dá de sobra, ya que ademas en cualquier momento podemos apuntar los registros que definen la tabla de direcciones a una nueva, y así tendriamos otros 8192 posibles elementos. Lo importante, es el para qué vamos a utilizar los otros bites. Facil, en particular, con 2 de ellos podemos tener el valor 0, 1, 2 y 3.
Estos bites en el descriptor de segmento, nos van a indicar el "modo" de funcionamiento del procesador en el segmento de codigo que esté a su vez apuntado por el indice del descriptor a la tabla de direcciones.
El modo "0" es el modo más potente. Puede realizar todo. A este modo se le llama modo KERNEL del procesador. Es decir el codigo del programa que se este ejecutando en modo 0, tiene acceso a todo. Esto puede servirnos para el "nucleo" del sistema operativo.
El modo "1" en principio puede hacer todo, excepto saltar a modo cero. Igualmente el "2" no tiene acceso a los anteriores, y el "3" no tiene acceso nada mas que a segmentos de us propio modo. Este es el modo menos potente. No puede hacer casi nada. Este es modo en que deben ejecutase los programas de aplicacion. Es el llamado modo USER.
Evidentemente, tiene que existir alguna manera de poder ejecutar "trozos" de codigo del sistema operativo. Pero en principio el modo "3" no puede saltar a modo "0", y de hecho no salta. No puede. Lo hace mediante la tecnica de "excepciones" o puertas de tarea. Estas están totalmente protegidas, por lo que un programa de usuario, nunca podría "tirar" al sistema operativo.
Graficamente lo anterior, puede pintarse con un circulo. Este es el modo 0. Luegop un circulo concentrico mayor. Es el modo 1, y así pintar otros dos circulos contentricos mayores hasta el modo 3. Y ahora graficamente, podemos decir que podemos saltar del interior al exterior en cualquier punto, pero nunca al reves. Para pasar al reves. solo puede hacerse en ciertos "puntos" de cada circulo. Estos puntos, son la "puertas de tarea".
Curiosamente..... de esta manera ya se puede implementar proteccion a nivel de tareas. El tema es mucho mas complejo con respecto a los descriptores, pero a nivel de introduccion nos puede servir.
MEMORIA VIRTUAL. SU MECANISMO.
Antes hemos comentado que una direccion, es un descriptor de segmento y un desplazamiento. Este descriptor de segmento, es un indice que apunta a una tabla y contiene el "segmento" real que sumado al desplazamiento inicial, nos da, la direccion correcta. La direccion es ya la direccion real fisica de memoria que queremos localizar. (memoria lineal).
Todo este "cisco" que he contado, no hay que preocuparse. No necesitamos "programarlo" nosotros. El hardware lo hace por nosotros. Todo esto lo tiene implementado directamente la CPU. En general esto que estoy describiendo, no es una cosa de la arquitectura 386 (es decir los actuaes Pentium). Es algo de "todas" las CPUs. Intel no descubrió nada nuevo con esto (tiene algunas matizaciones...). Todas las CPUs trabajan basicamente con los conceptos descritos en estos capitulos.
Pero... que pasa si ademas de esta tabla, o este mecanismo mejor dicho, de "segmentacion", el cual nos dá una direccion lineal, esta en vez de ser la direccion fisica, lo que hacemos es que a su vez apunte a otra tabla especial. Vamos a llamarla tabla de "paginacion". Esta nueva tabla, tendrá en cada elemento, bien su direccion ya en memoria real, o bien su direccion en el archivo de paginacion (ya veremos que es esto).
Y sí ademas, este mecanismo lo implementamos por hardware, y que sea la CPU la encargada de realizar todo este trasiego de direcciones, pues mucho mejor ¿no?.
Pues ahora, empezemos al reves: cogemos toda la memoria y la dividimos en paginas de 4 Kbs. La direccion o numero de pagina, lo ponemos en una tabla que nos vamos a crear con las direcciones de dichas paginas. Ademas esa tabla, va a contener un indicador de si está en memoria real o bien en disco en el archivo de paginacion.
Cada elemento de la tabla, son las direcciones sucesivas de memoria que "cree" ver nuestro programa. Pero la CPU, accediendo a dicha tabla, salta a la direccion real que está allí indicada que será cualquier otra, o bien, si está en disco, carga esa pagina del disco, en cualquier localizacion de memoria libre, y le cede control.
Es decir, estamos "virtualizando" las direcciones. Nuestro programa no entiende de direcciones reales. Unicamnete direcciones virtuales que son las que le muestra la tabla de paginacion. Y es la CPU la que se encarga del trasiego de paginas de memoria real al archivo de paginacion (cunado no le "caben") y al contrario.
Evidentemente, el propio hardware, sigue unos criterios para descargar las paginas "menos" utilizadas al archivo de paginacion. Una vez que ha hecho esto, con marcar en la tabla de paginas, que esa direccion no está en memoria real y está guardada en tal posicion de disco.... pues ya está. Los programas ni se enteran. Realmente estan en modo "virtual".
VIRTUALIZACION DEL HARDWARE
Bien, al igual que se puede poner poner un mecanismo por el cual las tareas están protegidas, tambien puede ponerse un bit de marca que nos indique si un descriptor de segmento (es decir el codigo, real o virutal) al que apunta ese descriptor, está autorizado o no para ejecutar una entrada / salida directa al hardware. Es decir una instruccion IN / OUT en ensamblador de las que veiamos al principio de estos capitulos.
Si el bit está activo, se lo permite. Si no, lo que hace el procesador cuando encuentra una instruccion de estas, es provocar una "excepcion". Esta excepcion, tendrá su puerta de tarea y un manejador de esta excepcion. Un "manejador" de excepciones, no es nada mas que un "trozo" de codigo de programa (normalmente perteneciente al sistema operativo, o implementado por algun driver), el cual es el encargado real de ejecutar ducah instruccion o de prohibir su ejecucion.
Por eso, por ejemplo, en windows NT, que tiene virtualizacion completa del hardware, no podemos realizar ninguna instruccion no permitida, y la mayoria de juegos basadso en DOS, que intentan acceder al hardware directamente, la propia CPU no les deja. Se dispara una "excepcion" y el manejador de dicha "excepcion" se lo prohibe. Recordad que una secuencia mal programada de IN / OUT directos a un puerto, o bien intentando acceder a un puerto inexistente, es lo que provoca las caidas de maquina. Un sistema operativo "serio" no puede dear que se realicen estas cosas (NT, Linux). Un sistema que quiera guardar compatibilidad ocn el "viejo" MsDOS, por desgracia, no virtualiza totalmente el hardware, y deja hacer la mayoria de las cosas a casi todos los programas. Esto es lo que provoca "cuengues" en windows 98 por programas mal codificados (o mal "educados").
** La pregunta que surge es: ¿si unicamente es un bit, el que "indica" estas protecciones, facil, por que no lo cambiamos?
Y la respuesta mas facil todavia: porque no se puede. No deja la CPU ejecutar una instrucccion de este tipo, cuando nuestro programa está en modo USER. Unicamente el sistema operativo que está en modo KERNEL es el que puede ejecutar estas instrucciones privilegiadas. Y ademas si lo intentamos, se provocará otra excepcion. Y en esa excepcion, el sistema operativo hará lo que considere oportuno: normalmente "matar" a esa tarea.
MODO VIRTUAL 8086
Es el tercer modo de funcionamiento del procesador. Simplemente se le dá un espacio de direcciones virtuales de un mega y al poner a trabajar el procesador en este modo es como si estuviese en modo real. Pero es "como" si estuviese. No lo está y todas las llamadas podrían ser interceptadas por el sistema operativo.
Pongamos un ejemplo muy claro. Habiamos dicho que la direccion de memoria grafica para modo texto es el segmento B800. Pues bien, si fisicamente "ponemos" en la posicion de memoria B800:0000 (una direccion asoluta de memoria), dos bytes, uno de ellos con los atributos de color y otro con la letra "A", veremos instantanemanete la letra "A" con el color seleccionado en la esquina superior izquierda de la pantalla. Es instantaneo, como si la pantalla fuese una "ventana" a esa direccion de memoria.
Esto es en modo real. Pero la pregunta es ¿como lo hace windows cunado abrimos una ventana msdos?. Es importante esto, ya que el escribir en esa posicion de memoria por un probrama, implicaría que esa "A" saldría instantanemante en pantalla. Y no sucede esto, lo vemos, eso sí en la parte superior izquierda de una "ventana" MsDOS que puede estar ademas fisicamente en cualquier posicion de nuestro monitor.
** Bien, es facil si hemos entendido un poco el mecanismo de memoria virtual. La solucion es "marcar" esas paginas de memoria como "paginadas" en la tabla de paginas. Al ir a utilizar esa direccion, como está teoricamente paginada, ocurres una excepcion del procesador, entra a funcionar el mecanismo de excepciones, y un manejadro para esta excepcion toma control. Este manejador "se da cuenta" de lo que queria hacer el programa y en vez de hacer lo "normal" que es buscar en el fichero de paginacion y traer a memoria fisica la pagina que falta, lo que hace, es "dibujar" esa "A" que queriamos en la ventana MsDOS en la esquina superior izquierda.
Parece un poco retorcido..... pero es la unica solucion, y funciona perfectamente. De cara al programa que se está ejecutando, para el es como si estuviese funcionando en modo real. Es exactamente lo mismo, pero en vez de hacer lo que el quiere, se hace lo que quieres el sistema operativo. Ademas, ese "mega" de memoria, está en cualquier sitio de la memoria fisico, incluso troceado, da igual. Unicamente windows, construye una tabla de memoria con las paginas que le interese, lo pone en unos registros del procesador y cambia a modo virtual 8086.
MULTITAREA REAL
El concepto de multitarea lo unico que nos incorpora es la posibilidad de repartir el tiempo en unas unidades muy pequeñas, llamadas "quantum", y ceder el control, consecutivamente y por orden de esa cantidad de tiempo asignado a cada tarea de la maquina.
Esto nos muestra "aparentemente" que hay varios programas en ejecucion. Realmente, en cada instante del tiempo, (en cada "quantum", dure lo que dure), solo hay UN solo programa en ejecucion. Pero en ese quantum, con las velocidades actuales de las CPUs, se pueden hacer muchas cosas.
Evidentemente, aquí intervienen otros dos conceptos:
1) Intercambio de tareas.
2) Proridad de las tareas.
El intercambio de tareas, es simplemente el guardar el estado de una tarea cuando ha agotado su tiempo (sus quantums asignados), recuperar el estado de otra tarea y cederle el control. Normalmente esto se puede realizar por el hardware de la CPU (existe una instruccion especifica para ello, en "todas" las CPUs del mercado, incluidos los mainframes). Pero Microsoft en vez de utilizar el mecanismo hardware, lo hace por software, "a mano". Esto es muy costos en ciclos de reloj, pero aparentemente, Microsoft no se fiaba, al menos al principio, de la implementacion de este mecanismo en la CPU por parte de Intel.
Prioridad de las tareas, es simplemente un numero asignado a cada tarea, que indica el numero de "quantums" que puede ejecutar antes de que el sistema operativo tome control y le ceda el control a otra tarea.
* Hay que hacer notar, que una tarea, puede "perder" el control, antes de agotar su numero de quantums. Sí esa tarea hace una peticion de entrada / salida a disco por ejemplo, debido a que esa peticion es muy costosa en tiempo (estamos hablando de algunos milisegundos), mientras se ejecuta, evidentemente la CPU puede hacer muchisimas mas cosas. Por tanto el sistema operativo toma el control y se lo cede a otra tarea.
El sistema operativo, debe ser "listo". Debe jugar con las prioridades de tarea y variarlas ligeramente. Es cedir, a un programa que hace mucha entrad/salida, debido a que está poco tiempo en memoria, el sistema operativo le debería subir la prioridad. En cambio al reves, a un programa que chupa mucha CPU y no realiza apenas entrada / salida, el sistema operativo debe bajarle la prioridad al objeto de que no se apodere todo el tiempo de la CPU.
* Evidentemente, el propio nucleo del sistema operativo debe ser el proceso de maxima prioridad.
Bien, esta es la teoria de Multitarea REAL. Y esto es lo que realiza win95 / 98 con las tareas de 32 bites.
Pero las tareas de 16 bites, se "inventaron" (heredado de windows 3.1), la MULTITAREA CORPORATIVA ("preemptive"). Realmente este no es un concepto informatico. Es un concepto Microsoft. Me explico: en este caso no existe la "cesion" de una tarea a otra por el tiempo consumido en maquina, sino como por definicion, las tareas windows, "generalmente" emiten muchos mensajes al sistema, (funcionan por intercambio de mensajes), cada vez que se emiten por parte de un programa ciertos tipos de mensaje, el sistema operativo toma control al recibir ese mensaje y cede en algunos de ellos el control a otra tarea. Este es el funcionamiento de las tareas de 16 bites. Y evidentemente, peligrosisimo, ya que si una tarea no emite esos mensajes, y esa tarea está mal programada y se mete en un bucle infinito, entonces windows se nos quedará "colgado". No responderá ni el teclado.
* Windows 95 / 98, por "herencia", debe permitir ambos tipos de "multitarea". La REAL para tareas de 32 bites, y la "cooperativa" para tareas de 16 bites (y recemos, para que realmente "cooperen" esas tareas). La manera de hacerlo, es crearse una maquina virtual para cada tarea de 32 bites, y otra maquina virtual para "todas" las tareas de 16 bites. Por tanto es importante recalcar que TODAS las de 16, comparten la "misma" maquina virtual.
Esto ultimo implica, que la caida de una tarea de 16 bites, dejará, probablemente, inutilizado TODA la maquina virtual de 16 bits. Y esto es importante, porque win 95 / 98 tiene mucho codigo de 16 bites en su nucleo. Por tanto nos inutilizará, probablemente, parte del sistema operativo, obligandonos a reiniciar la maquina.
En cambio, la caida de un programa de 32 bites, unicamente, provocará la caida de esa maquina virtual, y no afecta al resto del entorno windows. Rearrancando la tarea, esta seguirá en funcionamiento. Por ejemplo, la caida de Word (por lo que sea) no pasa nada, se rearranca word y sigue funcionando. La caida de una tarea de 16 bites, en el mejor de los casos, lo unico que sucedería es que esa tarea ya no podremos arrancarla hasta que reiniciemos la maquina.
HardSide