| |
|
Desde que pulsamos el boton de encendido de nuestro PC hasta... (parte 19) |
|
|
|
| |
Por Jose Manuel Tella Llop, extraído de microsoft.public.es.windows98
DESDE QUE PULSAMOS EL BOTON DE NUESTRO PC HASTA..... (Parte 19)
---------------------------------------------------- LOS RECURSOS DE WINDOWS
----------------------- Tal y como hemos comentado previamente, los componuentes, USER, GDI y KERNEL que ejecuta Windows son de 16 bites. Además de estos 3, Windows 95 / 98, carga el USER32, GDI32, y KRNL32 que son los 3 respectivos componentes para tareas de 32 bites. Pero por desgracia, los componentes de 32 bites a este nivel, llaman a sus respectivos de 16 bites "siempre", los cuales son los encargados "reales" de realizar las tareas. Veamos un ejemplo. El API es el conjunto de funciones que puede utilizar cualquier tarea Windows para realizar una accion. Por ejemplo "crear una ventana". Evidentemente hay dos API's una de 16 y otra de 32 (cada tarea, dependiendo del tipo -16-32-, llama a la correspondiente funcion). El API del GDI32 tiene los siguientes subcomponentes: * GDI32 como tal
* Adaptador tipografico TrueType
* Archivos TrueType (usa archivos proyectados en memoria).
* Perfiles de color (usa archivos proyectados en memoria).
* Correspondencia de colores de imagenes (ICM)
* INTERFAZ de salto al subsistema de 16 bites. Por tanto una tarea de 32 que utilice el GDI32, siempre salta al subsistema de 16, que a su vez contiene (API de 16): * GDI16
* Minicontrolador de visualizacion
* Minicontrolador de Impresora
* Controlador universal de impresora
* Motor DIB grafico
* Visualizacion o Impresora (drivers ya especificos del fabricante). NOTA (para los puristas): El motor DIB realmente es codigo de 32 que se ejecuta con una vista de 16 bits (segmentada) de la memoria del sistema, por lo que por ejemplo el codigo hace uso de las instruccciones rapidas del 386 para las operaciones de transferencia de memoria. Hay una cantidad considerable de trucos implicados en la manipulacion eficiente de direcciones, pero permiten que las aplicaciones existentes de 16 bits puedan realizar las mejoras de implementacion del nuevo motor DIB. Si el motro DIB, se colocara en el lado de los 32 bits, o bien el modilo GDI de 32 tendría que reproducir muchas de las funcionalidades del de 16 o bien el motoe GDI incurriria en mucha sobrecarga de ajuste volviendo a llamar al lado de 16 bites. ** Bien, una vez "matizado" este comportamiento, vemos que por desgracia, Windows 95 / 98, se apoya (por mantener compatibilidad total) sobre los subsistemas de 16 bites. ** Y ahora para los programadores (o quien haya seguido con atencion estos capitulos): ¿cual es el segmento mayor que se puede poner en una tarea de 16 bits?: facil 2 elevado a 16 o sea 64 Kbs de memoria. Por tanto el tamaño de la "pila" ("heap", monton), maximo que puede utilizar una tarea de 16 bites es 64 Kbs. Pues bien a ese "pequeño" espacio de memoria y que además es INDEPENDIENTE del numero de megas de nuestro PC (por diseño), es lo que se le llama RECURSOS. Por tanto, hay tres "pilas" de recursos (correspondiente a los tres programas principales del núcleo : USER, GDI y KERNEL. Estos recursos libres los podemos ver ejecutando el programa RSRCMTR.EXE del directorio de windows). Por desgracia, todas las llamadas a funciones de esta API, que nos vayan creando "objetos" (asignacion de memoria, iconos, ventanas, etc...), consumen una pequeña cantidad de esta "pila". Lo grave es que si nos quedamos sin alguno de los recursos, tenemos muchas posibilidades de que Windows se "caiga" -nos intenta enviar un mensaje, pero puede ya caerse en cualquier momento-) ** Evidentemente esto es un comportamiento heredado. Windows NT y el futuro Windows 2000, no tienen esta limitacion de recursos, debido a que TODO el codigo de este estilo es de 32 bites "puro". Contra el consumo de estos recursos, no hay solucion. Ademas, lo "grave" del tema, es que es responsabilidad del programa que "consume" recursos, el liberarlos. Por tanto un programa mal codificado (mal diseñado), o que termina anormalmente, nos dejará recursos "gastados" en la pila, que no se recuperarán hasta que reinicimos Windows. DIAGRAMA DE PROCESOS DE WINDOWS
------------------------------- Anteriormente habiamos vistos los diferentes modos de funcionamiento del procesador para la proteccion de las tareas. Desde modo 0 (nucelo o kernel) a modo 3 (usuario). Y podiamos imaginarlos como anillos concentricos (el mas interior el cero y el mas exterior el 3). El cero era quien tenia control absoluto de la maquina y suele corresponder al "núcleo ". Si algun programa o modulo, "falla" en modo kernel, prácticamente seguro que nos podemos despedir de windows: a reiniciar la maquina. El modo cero tiene además control absoluto sobre los otros maods. Por tanto si se cae cualquier proceso de los otros modos es capaz de "rearancarlo". Es decir: simplemente no pasa nada. ** El tema para los diseñadores de cualquier sistema operativo, es ¿que ponemos en modo kernel y que ponemos en el resto de modos hasta llegar al modo 3 -usuario-? Hay que tener presente, que la "transicion" o saltos de modo, son operaciones muy costosas en tiempo Y deben realizarse lo menos posible. Por otra parte, por motivos de eficiencia, es mejor poner las cosas en modo 0. ¿como se nivela la balanza? ¿perdemos seguridad frente a estabilidad? Este es el gran dilema. Por ejemplo puedo comentar que en su dia, cuando se diseño Windows NT 4, fué muy criticado debido a que metió dentro del núcleo (modo cero) el GDI (las versiones anteriores no lo tenian así). Esto fue por razones de eficiencia del sistema. Pero peligroso: un programa que utilizase mal el GDI, ahora ya podia "tirar" al sistema. Es decir, a veces hay que tomar deciones de diseño "peligrosas". ** ¿Como es entonces la estructura de win 95 / 98? 1) Se decidió utilizar unicamente los anillos 0 (kernel) y 3 (user) 2) En el anillo 0 se incorporan dos subsistemas: * Subsistema Administrador de maquina virtual con:
* Servicios de Gestion de memoria
* Planificador
* Servicios VxD y cargador dinamico
* Administrados de maquinas virtuales MSDOS
* Controladores (teclado, video, raton, comunicaciones...) * Subsistema de gestion de archivos con:
* Administrador del sistema de archivos instalable(IFS)
* FAT de 32 bits
* Sistema de archivos CDROM
* Redirectores de red
* Subsistema de E/S por bloques 3) En el anillo 3, se ejecutaria tano la maquina virtual del sistema como todas las maquinas virtuales MSDOS (una por cada ventana MSDOS que tengamos abierta). En este maquina virtual del sistema existe un espacio virtual de direcciones compartidos por todas las tareas que son: * Servicios del sistema: núcleo , Usuario, GDI
* Subsistema de 16 bits. Y luego se crearia un espacio virtual de direcciones "diferente" para cada tarea de 32 bits. Es decir en un espacio virtual de direcciones de 32 bits se pueden dirección ar 4 Gb de memoria virtual. Los 2 primeros gigas son comunes a todas las tareas y corresponden a zonas del sistema operativo. Un guga más (hasta los 3 gigas) es para el espacio de direcciones compartido de las tareas de 16 bits, y desde los 3 a los 4 gigasm es "diferente" para cada tarea de 32 bits. Por tanto una "caida" de una tarea de 32 bits no es nunca critica para el sistema. ** Con todo este "rollo" hemos terminado de ver un poco las "tripas" de Windows,y quizá ahora entendamos un poco más de como, cuando y porqué Windows puede sufrir una "catastrofe". Vamos a pasar ahora a ver ya la carga completa de Windows. WINDOWS CONTINUA CARGANDOSE
--------------------------- **** Bueno, y este será el siguiente capitulo......
Volver a
Artículos y FAQs
| 
