Vous êtes sur la page 1sur 37

Arquitectura del Sistema Operativo Windows NT

Indice 1. Prlogo 2. Introduccin Y Conceptos Bsicos 3. Diseo de Windows Nt 4. Procesos 5. Administracin de la Memoria 6. Sistema de Archivos 7. Entrada y Salida 8. Windows Nt 5 9. Bibliografia

1. Prlogo El presente trabajo trata sobre la Arquitectura de Windows NT. La investigacin se ha llevado a cabo desde cuatro puntos de vista que son los componentes sealados por Andrew Tanenbaum para el enfoque del estudio de un Sistema Operativo, es decir: procesos, administracin de la memoria, ficheros y entrada/salida. Se ha comenzado con un captulo dedicado a conceptos bsicos y otro a la arquitectura global del sistema, para seguidamente estudiar en detalle cada uno de los cuatro puntos antes citados. Se puede decir que Windows NT representa la primera propuesta de la empresa Microsoft por construir un Sistema Operativo serio, capaz de competir con los dinosaurios clsicos como UNIX o VMS (o al menos intentarlo). Para ello se ha elegido un enfoque cliente-servidor, con la intencin de alcanzar el sueo delos Sistemas Distribuidos. Windows NT no se puede considerar todava un sistema operativo de carcter domstico. Pero el objetivo de sus diseadores parece ser que lo sea dentro de muy pocos aos, y de h echo, para que los programadores vayan entretenindose en el uso de las llamadas al sistema (el llamado Win32), han construido un Sistema Operativo de poco confiable. Hablamos, cmo no, deWindows 95. La arquitectura de Windows 95/98 no tiene absolutamente nada que ver con la de Windows NT. No es que sea un mal trabajo pero deja bastante que desear. Durante la elaboracin de este trabajo nos hemos encontrado con varias dificultades principalmente por la falta de fuentes bibliogrficas que trataran el diseo con la suficiente profundidad como para satisfacer el nivel que se buscaba. Los libros que se encontraron, la mayora se refieren a la Administracin del Sistema a alto nivel, o bien de la programacin bajo Windows NT en lenguaje C++, por lo que he tenido que recurrir a diversos artculos de la Internet, principalmente al nodo de Microsoft en Internet. Por ello, pedimos disculpas por las posibles erratas que puedan existir. Para tratar ciertos temas dentro de cada captulo se ha credoconveniente apoyarnos en la descripcin de las llamadas al sistema, ya que, anuestro entender, de esta manera todo resulta mucho ms fcil de explicar y decomprender.

2. Introduccion Y Conceptos Basicos Eventos A Travs Del Tiempo A finales de los aos 40's y a principios de los aos 50's las computadorasmasivas, eran controladas por tubos al vaco inestables. Todo la programacinse haca directamente en lenguaje de mquina

porque la industria no habaavanzado lo suficiente para necesitar Sistemas Operativos. Con la aparicin deltransistor a mediados de los 50's, las computadoras se fueron haciendo ms y msconfiables. Lenguajes crudos como Ensamblador y Fortran aparecieron, pero un SistemaOperativo (S.O.), tal como los conocemos ahora, an no. Para accesar a laprogramacin de la maquinaria se manejaron tarjetas perforadas. 1960's. Cuando IBM introdujo la computadora System/360 intent tomar elmercado cientfico y el comercial. Cuando en este proyecto surgieron problemasde conflictos por la arquitectura, se inici el desarrollo de un software queresolviera todos aquellos conflictos, el resultado fue un muy complejo sistemaoperativo. Luego AT&T trat de desarrollar a Multics, un Sistema Operativoque soportara cientos de usuarios de tiempo compartido, pero fall. Msadelante cientficos de la computacin desarrollaron Unics, que seramonousuario. Ello marca el nacimiento de Unix (1969), el primero de los sistemasoperativos modernos. 1980's. En este tiempo la arquitectura de las computadoras, circuitos LSI(Large Scale Integration) abrieron el paso para una nueva generacin decomputadoras. DOS de Microsoft aparece en 1981 dominando este mercado de las PCsinmediatamente, aunque el sistema UNIX, predomina en las estaciones de trabajo. 1990's. Aumenta el uso de conexiones en redes, equipos de trabajo yaplicaciones distribuidas, los cuales surgen en la dcada anterior, con ellolos Sistemas Operativos como Unix, Windows NT, etc., soportan muchos clientes,dando as el nacimiento de la Computacin en Red. Sistema Operativo Introduccin Software bsico que controla y administra los recursos deuna computadora. El sistema operativo tiene tres grandes funciones: coordina ymanipula el hardware de la computadora, como la memoria, las impresoras, lasunidades de disco, el teclado o el mouse; organiza los archivos en diversosdispositivos de almacenamiento, como discos flexibles, discos duros, discoscompactos o cintas magnticas, y gestiona los errores de hardware y la prdidade datos. Cmo funciona un sistema operativo? Los Sistemas Operativos controlan diferentes procesos de lacomputadora. Un proceso importante es la interpretacin de los comandos quepermiten al usuario comunicarse con el ordenador. Algunos intrpretes deinstrucciones estn basados en texto y exigen que las instrucciones seantecleadas. Otros estn basados en grficos, y permiten al usuario comunicarsesealando y haciendo clic en un icono. Los Sistemas Operativos pueden ser de tarea nica omultitarea. Los sistemas operativos de tarea nica, ms primitivos, slopueden manejar un proceso en cada momento. Por ejemplo, cuando la computadoraest imprimiendo un documento, no puede iniciar otro proceso ni responder anuevas instrucciones hasta que se termine la impresin. Todos los Sistemas Operativos modernos son multitarea ypueden ejecutar varios procesos simultneamente. En la mayora de losordenadores slo hay una UCP; un Sistema Operativo multitarea crea la ilusinde que varios procesos se ejecutan simultneamente en la UCP. El mecanismo quese emplea ms a menudo para lograr esta ilusin es la multitarea porsegmentacin de tiempos, en la que cada proceso se ejecuta individualmentedurante un periodo de tiempo determinado. Si el proceso no finaliza en el tiempoasignado, se suspende y se ejecuta otro proceso. Este intercambio de procesos sedenomina conmutacin de contexto. El sistema operativo se encarga de controlarel estado de los procesos suspendidos. Tambin cuenta con un mecanismo llamadoplanificador que determina el siguiente proceso que debe ejecutarse. Elplanificador ejecuta

los procesos basndose en su prioridad para minimizar elretraso percibido por el usuario. Los procesos parecen efectuarse simultneamentepor la alta velocidad del cambio de contexto. Los Sistemas Operativos pueden emplear memoria virtual paraejecutar procesos que exigen ms memoria principal de la realmente disponible.Con esta tcnica se emplea espacio en el disco duro para simular la memoriaadicional necesaria. Sistemas Operativos actuales Los sistemas operativos empleados normalmente son UNIX,Macintosh OS, MS-DOS, OS/2 y Windows-NT. El UNIX y sus clones permiten mltiplestareas y mltiples usuarios. Su sistema de archivos proporciona un mtodosencillo de organizar archivos y permite la proteccin de archivos. Sinembargo, las instrucciones del UNIX no son intuitivas. Otros sistemas operativosmultiusuario y multitarea son OS/2, desarrollado inicialmente por MicrosoftCorporation e International Business Machines (IBM) y Windows-NT, desarrolladopor Microsoft. El sistema operativo multitarea de las computadoras Apple sedenomina Macintosh OS. El DOS y su sucesor, el MS-DOS, son sistemas operativospopulares entre los usuarios de computadoras personales. Slo permiten unusuario y una tarea. Sistema Operativo de Red A un Sistema Operativo de Red se le conoce como NOS. Es elsoftware necesario para integrar los muchos componentes de una red en un sistemaparticular, al cual el usuario final puede tener acceso. Otra definicin es la siguiente; es un software que rige yadministra los recursos, archivos, perifricos, usuarios, etc., en una red ylleva el control de seguridad de los mismos. Un NOS maneja los servicios necesarios para asegurar que elusuario final tenga o est libre de error al accesar a la red. Un NOSnormalmente provee una interfaz de usuario que es para reducir la complejidad yconflictos al momento de usar la red. Dentro del contexto del Sistema Operativo de Red, se puedenescribir aplicaciones tales como un sistema de correo electrnico pueden serescritas para que permitan "conexiones virtuales" entre entidades dered, sin intervencin humana directa. Diferencia entre un S.O. Distribuido, un S.O. de Red y unS.O. Centralizado. En un Sistema Operativo de Red, los usuarios saben de laexistencia de varias computadoras y pueden conectarse con mquinas remotas ycopiar archivos de una mquina a otra, cada mquina ejecuta su propio sistemaoperativo local y tiene su propio usuario o grupo de usuarios. Por el contrario, un Sistema Operativo Distribuido es aquelque aparece ante sus usuarios como un sistema tradicional de un solo procesador,aun cuando est compuesto por varios procesadores. En un sistema distribuidoverd adero, los usuarios no deben saber del lugar donde su programa se ejecute odel lugar donde se encuentran sus archivos; eso debe ser manejado en forma automticay eficaz por el Sistema Operativo. Adems son sistemas autnomos capaces de comunicarse ycooperar entre s para resolver tareas globales. Es indispensable el uso deredes para intercambiar datos. Adems de los servicios tpicos de un SistemaOperativo, un Sistema Distribuido debe gestionar la distribucin de tareasentre los diferentes nodos conectados. Tambin, debe proporcionar losmecanismos necesarios para compartir globalmente los recursos del sistema. Sistemas Operativos Centralizados, de un solo procesador, deun solo CPU o incluso tradicionales; en todo caso, lo que esto quiere decir esque un sistema operativo controla una sola computadora.

3. Diseo De Windows Nt Windows NT presenta una arquitectura del tipocliente-servidor. Los programas de aplicacin son contemplados por el sistemaoperativo como si fueran clientes a los que hay que servir, y para lo cual vieneequipado con distintas entidades servidoras. Uno de los objetivos fundamentales de diseo fue el tener unncleo tan pequeo como fuera posible, en el que estuvieran integrados mdulosque dieran respuesta a aquellas llamadas al sistema que necesariamente setuvieran que ejecutar en modo privilegiado (tambin llamado modo kernel, modo ncleoy modo supervisor). El resto de las llamadas se expulsaran del ncleo haciaotras entidades que se ejecutaran en modo no privilegiado (modo usuario), y deesta manera el ncleo resultara una base compacta, robusta y estable. Por esose dice que Windows NT es un sistema operativo basado en micro-kernel. Es por ello que en un primer acercamiento a la arquitecturadistinguimos un ncleo que se ejecuta en modo privilegiado, y se denominaExecutive, y unos mdulos que se ejecutan en modo no privilegiado, llamadossubsistemas protegidos. Los programas de usuario (tambin llamados programas deaplicacin) interaccionan con cualquier sistema operativo (SO) a travs de unjuego de llamadas al sistema, que es particular de cada SO. En el mundo Windowsen general, las llamadas al sistema se denominan API (Application ProgrammingInterfaces, interfaces para la programacin de aplicaciones). En Windows NT yen Windows 95 se usa una versin del API llamada API Win32. Un programa escritopara Windows NT o Windows 95, y que por consiguiente hace uso del API Win32, sedenomina genricamente "programa Win32", y de hecho esta denominacines bastante frecuente en artculos y libros al respecto. Desgraciadamente, yconviene dejarlo claro cuanto antes, el trmino "Win32" tiene tresacepciones (al menos hasta ahora) totalmente distintas. Una es el API, otra esel nombre de uno de los subsistemas protegidos de Windows NT del que hablaremosms adelante, y por ltimo se denomina Win32s a una plataforma desarrolladapor Microsoft, similar a Windows 3.1, pero que usa el API Win32 en vez del APIWin16 del Windows 3.1. Hechas estas aclaraciones, podemos continuar adelante.Algunas de las llamadas al sistema, debido a su naturaleza, son atendidasdirectamente por el Executive, mientras que otras son desviadas hacia algnsubsistema. Esto lo veremos con detalle en breve. El hecho de disponer de un ncleo rodeado de subsistemas quese ejecutan en modo usuario nos permite adems aadir nuevos subsistemas sinproducir ningn tipo de confrontacin. En el diseo de Windows NT han confluido aportaciones detres modelos: el modelo cliente-servidor, el modelo de objetos, y el modelo demultiprocesamiento simtrico. Modelo cliente-servidor. En la teora de este modelo seestablece un kernel que bsicamente se encarga de recibir peticiones deprocesos clientes y pasrselas a otros procesos servid ores, ambos clientes yservidores ejecutndose en modo usuario. Windows NT pone el modelo en prcticapero no contempla el ncleo como un mero transportador de mensajes, sino queintroduce en l aquellos servicios que slo pueden ser ejecutados en modokernel. El resto de servicios los asciende hacia subsistemas servidores que seejecutan en modo usuario, independientes entre s, y que por tanto puedenrepartirse entre mquinas distintas, dando as soporte a un sistemadistribuido (de hecho, el soportar los sistemas distribuidos fue otra de lasgrandes directivas de diseo de este SO). Modelo de objetos. Decir que no implementa puramente la teorade este modelo, sino que ms bien lo que hace es simplemente contemplar losrecursos (tanto internos como externos) como o bjetos. Ms adelante daremos unalista de los objetos de Windows NT. Brevemente, sealar que todo objeto ha deposeer identidad propia (es nico y distinguible de todos los dems), y unaserie de atributos (variables) y mtodos (funciones) que modifican susatributos. Los objetos interaccionan entre s a travs del envo de mensajes.No slo existen en Windows NT objetos software (lgicos), sino que losdispositivos hardware (fsicos) tambin son tratados como objetos (adiferencia de UNIX, que recordemos trataba a los dispositivos como ficheros).

Modelo de multiprocesamiento simtrico. Un SO multiproceso(o sea, aquel que cuenta con varias CPU y cada una puede estar ejecutando unproceso) puede ser simtrico (SMP) o asimtrico (ASMP). En los sistemasoperativos SMP (entre los que se encuentran Windows NT y muchas versiones deUNIX) cualquier CPU puede ejecutar cualquier proceso, ya sea del SO o no,mientras que en los ASMP se elige una CPU para uso exclusivo del SO y el restode CPU quedan para ejecutar programas de usuario. Los sistemas SMP son mscomplejos que los ASMP, contemplan un mejor balance de la carga y son mstolerantes a fallos (de manera que si un subproceso del SO falla, el SO no secaer pues podr ejecutarse sobre otra CPU, cosa que en los ASMP no seraposible, con lo que se bloqueara el sistema entero). Comencemos describiendo los subsistemas protegidos, paraseguidamente estudiar la estructura del Executive.

Figura 1. El ncleo se ejecuta en modo privilegiado(Executive) y en modo no privilegiado (subsistemas protegidos) Los Subsistemas Protegidos Son una serie de procesos servidores que se ejecutan en modousuario como cualquier proceso de usuario, pero que tienen algunas caractersticaspropias que los hacen distintos. Al decir subsistemas protegidos nosreferiremos, pues, a estos procesos. Se inician al arrancar el SO. Los hay dedos tipos: integrales y de entorno. Un Subsistema Integral: es aquel servidor que ejecuta unafuncin crtica del SO (como por ejemplo el que gestiona la seguridad).Tenemos los siguientes: El Subsistema Proceso de Inicio (Logon Process) El proceso de inicio (Logon Process) recibe las peticiones deconexin por parte de los usuarios. En realidad son dos procesos, cada unoencargndose de un tipo distinto de conexin: El proceso de inicio local: gestiona la conexin de usuarios localesdirectamente a una mquina Windows NT. El proceso de inicio remoto: gestiona la conexin de usuarios remotos aprocesos servidores de Windows NT.

Figura 2. Diagrama de Flujo del Proceso de Inicio de Windows NT. El Subsistema de Seguridad Este subsistema interacciona con el proceso de inicio y elllamado monitor de referencias de seguridad (se tratara en el Executive), y deesta forma se construye el modelo de seguridad en Windows NT. El subsistema de seguridad interacciona con el proceso deinicio, atendiendo las peticiones de acceso al sistema. Consta de dossubcomponentes: La autoridad de seguridad local: es el corazn delsubsistema. En general gestiona la poltica de seguridad local; as, seencarga de generar los permisos de acceso, de comprobar que el usuario quesolicita conexin tiene acceso al sistema, de verificar todos los accesos sobrelos objetos (para lo cual se ayuda del monitor de referencias a seguridad) y decontrolar la poltica de auditoras, llevando la cuenta de los mensajes deauditora generados por el monitor de referencias. Las auditoras son unafacilidad que proporciona Windows NT para monitorizar diversos acontecimientosdel sistema por parte del Administrador. El administrador de cuentas: mantiene una base de datos con las cuentas detodos los usuarios (login, claves, identificaciones, etc.). Proporciona losservicios de validacin de usuarios requeridos por el subcomponente anterior. Un Subsistema de Entorno: da soporte a aplicacionesprocedentes de SO distintos, adaptndolas para su ejecucin bajo Windows NT.Existen tres de este tipo: El Subsistema Win32 Es el ms importante, ya que atiende no slo a las aplicaciones nativas deWindows NT, sino que para aquellos programas no Win32, reconoce su tipo y loslanza hacia el subsistema correspondiente. En el caso de que la aplicacin seaMS-DOS o Windows de 16 bits (Windows 3.11 e inferiores), lo que hace es crear unnuevo subsistema protegido pero no servidor. As, la aplicacin DOS o Win16 seejecutara en el contexto de un proceso llamado VDM (Virtual DOS Machine, mquinavirtual DOS), que no es ms que un simulador de un ordenador funcionando bajoMS -DOS. Las llamadas al API Win16 seran correspondidas con las homnimas enAPI Win32. Microsoft llama a esto WOW (Windows On Win32).

El subsistema soporta una buena parte del API Win32. As, seencarga de todo lo relacionado con la interfaz grfica con el usuario (GUI),controlando las entradas del usuario y salidas de la aplicacin. Por ejemplo,un buen nmero de funciones de las bibliotecas USER32 y GDI32 son atendidas porWin32, ayudndose del Executive cuando es necesario. El funcionamiento como servidor de Win32 lo veremos un poco msadelante, en el apartado de llamadas a procedimientos locales. El Subsistema POSIX La norma POSIX (Portable Operating System Interface for Unix)fue elaborada por IEEE para conseguir la portabilidad de las aplicaciones entredistintos entornos UNIX. La norma se ha implementado no slo en muchasversiones de UNIX, sino tambin en otros SO como Windows NT, VMS, etc. Se tratade un conjunto de 23 normas, identificadas como IEEE 1003.0 a IEEE 1003.22, otambin POSIX.0 a POSIX.22, de las cuales el subsistema POSIX soporta laPOSIX.1, que define un conjunto de llamadas al sistema en lenguaje C. El subsistema sirve las llamadas interaccionando con elExecutive. Se encarga tambin de definir aspectos especficos del SO UNIX,como pueden ser las relaciones jerrquicas entre procesos padres e hijos (lascuales no existen en el subsistema Win32, por ejemplo, y que por consiguiente noaparecen implementadas directamente en el Executive). El Subsistema OS/2 Igual que el subsistema POSIX proporciona un entorno para aplicaciones UNIX,este subsistema da soporte a las aplicaciones OS/2. Proporciona la interfaz grficay las llamadas al sistema; las llamadas son servidas con ayuda del Executive. El Executive No se debe confundir el Executive con el ncleo de Windows NT, aunque muchasveces se usan (incorrectamente) como sinnimos. El Executive consta de unaserie de componentes software, que se ejecutan en modo privilegiado, y uno delos cuales es el ncleo. Dichos componentes son totalmente independientes entres, y se comunican a travs de interfaces bien definidas. Recordemos que en eldiseo se procur dejar el ncleo tan pequeo como fuera posible, y, comoveremos, la funcionalidad del ncleo es mnima. Pasemos a comentar cada mdulo. El Administrador de Objetos (Object Manager) Se encarga de crear, destruir y gestionar todos los objetosdel Executive. Tenemos infinidad de objetos: procesos, subprocesos, ficheros,segmentos de memoria compartida, semforos, mutex, sucesos, etc. Lossubsistemas de entorno (Win32, OS/2 y POSIX) tambin tienen sus propiosobjetos. Por ejemplo, un objeto ventana es creado (con ayuda del administradorde objetos) y gestionado por el subsistema Win32. La razn de no incluir lagestin de ese objeto en el Executive es que una ventana slo es innata de lasaplicaciones Windows, y no de las aplicaciones UNIX o OS/2. Por tanto, elExecutive no se encarga de administrar los objetos relacionados con el entornode cada SO concreto, sino de los objetos comunes a los tres. El Administrador de Procesos (Process Manager) Se encarga (en colaboracin con el administrador e objetos)de crear, destruir y gestionar los procesos y subprocesos. Una de sus funcioneses la de repartir el tiempo de CPU entre los distintos subprocesos (ver el captulode los procesos). Suministra slo las relaciones ms bsicas entre procesos ysubprocesos, dejando el resto de las interrelaciones entre ellos a cadasubsistema protegido concreto. Por ejemplo, en el entorno POSIX existe unarelacin filial entre los procesos que no existe en Win32, de manera que seconstituye una jerarqua de procesos. Como esto slo es especfico de esesubsistema, el administrador de objetos no se entromete en ese trabajo y lo dejaen manos del subsistema.

El Administrador de Memoria Virtual (Virtual Memory Manager) Windows NT y UNIX implementan un direccionamiento lineal de32 bits y memoria virtual paginada bajo demanda. El VMM se encarga de todo lorelacionado con la poltica de gestin de la memoria: determina los conjuntosde trabajo de cada proceso, mantiene un conjunto de pginas libres, elige pginasvctima, sube y baja pginas entre la memoria RAM y el archivo de intercambioen disco, etc. Una explicacin detallada la dejaremos para el captulo de lamemoria. Facilidad de Llamada a Procedimiento Local (LPC Facility) Este mdulo se encarga de recibir y envar las llamadas aprocedimiento local entre las aplicaciones cliente y los subsistemas servidores. Administrador de Entrada/Salida (I/O Manager) Consiste en una serie de subcomponentes, que son: El administrador del sistema de ficheros El servidor y el redirector de red Los drivers de dispositivo del sistema El administrador de caches Buena parte de su trabajo es la gestin de la comunicacinentre los distintos drivers de dispositivo, para lo cual implementa una interfazbien definida que permite el tratamiento de todos los drivers de una manerahomognea, sin que intervenga el cmo funciona especficamente cada uno. Trabaja en conjuncin con otros componentes del Executive,sobre todo con el VMM. Le proporciona la E/S sncrona y asncrona, la E/S aarchivos asignados en memoria y las caches de los ficheros. El administrador de caches no se limita a gestionar unoscuantos buffers de tamao fijo para cada fichero abierto, sino que es capaz deestudiar las estadsticas sobre la carga del sistema y variar dinmicamenteesos tamaos de acuerdo con la carga. El VMM realiza algo parecido en sutrabajo, como veremos en su momento. Este componente da soporte en modo privilegiado al subsistemade seguridad, con el que interacciona. Su misin es actuar de alguna maneracomo supervisor de accesos, ya que comprueba si un proceso determinado tienepermisos para acceder a un objeto determinado, y monitoriza sus acciones sobredicho objeto. De esta manera es capaz de generar los mensajes de auditoras.Soporta las validaciones de acceso que realiza el subsistema de seguridad local. En UNIX, de la seguridad se encargaba un mdulo llamado elKerberos (Cancerbero), desarrollado por el MIT como parte del Proyecto Atenas.Kerberos se ha convertido en una norma de facto, y se incorporar a Windows NTen su versin 5.0. El Ncleo (Kernel) Situado en el corazn de Windows NT, se trata de unmicro-kernel que se encarga de las funciones ms bsicas de todo el SO: Ejecucin de subprocesos

Sincronizacin multiprocesador Manejo de las interrupciones hardware Nivel de Abstraccin de Hardware (HAL) Es una capa de software incluida en el Executive que sirve deinterfaz entre los distintos drivers de dispositivo y el resto del sistemaoperativo. Con HAL, los dispositivos se presentan al SO como un conjunto homogneo,a travs de un conjunto de funciones bien defnidas. Estas funciones son i llamadas tanto desde el SO como desde los propios drivers. Permite a los drivers de dispositivo adaptarse a distintas arquitecturas de E/S sin tener que sermodificados en gran medida. Adems oculta los detalles hardware que conlleva el multiprocesamiento simtrico de los niveles superiores del SO. Llamadas a Procedimientos Locales y Remotos Windows NT, al tener una arquitectura cliente-servidor, implementa elmecanismo de llamada a procedimiento remoto (RPC) como medio de comunicacinentre procesos clientes y servidores, situados ambos en mquinas distintas dela misma red. Para clientes y servidores dentro de la misma mquina, la RPC toma la forma de llamada a procedimiento local (LPC). Vamos a estudiar endetalle ambos mecanismos pues constituyen un aspecto fundamental del diseo deWindows NT. RPC (Remote Procedure Call) Se puede decir que el sueo de los diseadores de Windows NT es que algnda se convierta en un sistema distribuido puro, es decir, que cualquiera desus componentes pueda residir en mquinas distintas, siendo el kernel en cada mquina el coordinador general de mensajes entre los distintos componentes. En la ltima versin de Windows NT esto no es an posible. No obstante, el mecanismo de RPC permite a un proceso clienteacceder a una funcin situada en el espacio virtual de direcciones de otroproceso servidor situado en otra mquina de una manera totalmente transparente. Vamos a explicar el proceso en conjunto. Supongamos que setiene un proceso cliente ejecutndose bajo una mquina A, y un proceso servidor bajo una mquina B. El cliente llama a una funcin f de una biblioteca determinada. El cdigo de f en su biblioteca es una versin especial del cdigo real; el cdigo real reside en el espacio de direcciones del servidor. Esa versin especial de la funcin f que posee el cliente se denomina proxy. El cdigo proxy lo nico que hace es recoger los parmetros de la llamada a f, construye con ellos un mensaje, y pasa dicho mensaje al Executive. El Executive analiza el mensaje, determina que va destinado a la mquina B, y se lo enva a travs del interfaz de transporte. El Executive de la mquina B recibe el mensaje, determina a qu servidor va dirigido, y llama a un cdigo especial de dicho servidor, denominado stub, al cual le pasa el mensaje. El stub desempaqueta el mensaje y llama a la funcin f con los parmetros adecuados, ya en el contexto del proceso servidor. Cuando f retorna, devuelve el control alcdigo stub, que empaqueta todos los parmetros de salida (si los hay), forma as un mensaje y se lo pasa al Executive. Ahora se repite el proceso inverso; el Executive de B envael mensaje al Executive de A, y este reenva el mensaje al proxy. El proxyd esempaqueta el mensaje y devuelve al cliente los parmetros de retorno de f.Por tanto, para el cliente todo el mecanismo ha sido transparente. Ha hecho unallamada a f, y ha obtenido unos resultados; ni siquiera tiene que saber si el cdigo real de f est en su biblioteca o se encuentra en una mquina situada tres plantas ms abajo. LPC (Local Procedure Call) Las LPC se pueden considerar una versin descafeinada de lasRPC. Se usan cuando un proceso necesita los servicios de algn subsistemaprotegido, tpicamente Win32. Se intentara descubrir su funcionamiento.

El proceso cliente tiene un espacio virtual de 4 Gb. Los 2 Gbinferiores son para su uso (excepto 128 Kb). Los 2 Gb superiores son para usodel sistema. Vamos a suponer que el cliente realiza una llamada a la funcinCreateWindow. Dicha funcin crea un objeto ventana y devuelve un descriptor al mismo. No es gestionada directamente por el Executive, sino por el subsistema Win32 (con algo de colaboracin por parte del Executive, por supuesto; por ejemplo, para crear el objeto). El subsistema Win32 va guardando en su propioespacio de direcciones una lista con todos los objetos ventana que le vanpidiendo los procesos. Por consiguiente, los procesos no tienen acceso a la memoria donde estn los objetos; simplemente obtienen un descriptor para trabajar con ellos. Cuando el cliente llama a CreateWindow, se salta al cdigo de esa funcin que reside en la biblioteca USER32.DLL asignada en el espacio de direcciones del cliente. Por supuesto, ese no es el cdigo real, sino el proxy. Elproxy empaqueta los parmetros de la llamada, los coloca en una zona de memoria compartida entre el cliente y Win32, pone al cliente a dormir y ejecuta una LPC. La facilidad de llamada a procedimiento local del Executive captura esa llamada, y en el subsistema Win32 se crea un subproceso que va a atender a la peticindel cliente. Ese subproceso es entonces despertado, y comienza a ejecutar el correspondiente cdigo de stub. Los cdigos de stub de los subsistemas seencuentran en los 2 Gb superiores (los reservados) del espacio virtual delproceso cliente. Aunque no he encontrado ms documentacin al respecto, es muyprobable que dichos 2 Gb sean los mismos que se ven desde el espacio virtual deWin32. Sea como sea, el caso es que el stub correspondiente desempaqueta los parmetrosdel rea de memoria compartida y se los pasa a la funcin CreateWindow situadaen el espacio de Win32. se s es el cdigo real de la funcin. Cuando la funcin retorna, el stub contina, coloca el descriptor a la ventana en la memoria compartida, y devuelve el control de la LPC al Executive. El subproceso del Win32 es puesto a dormir. El Executive despierta al subproceso cliente, queestaba ejecutando cdigo proxy. El resto de ese cdigo lo que hace es simplemente tomar el descriptor y devolverlo como resultado de la funcin CreateWindow.

4. Procesos Definicin de Proceso y Sub Proceso Debemos tener cuidado con no confundir el proceso en Windows NT con elproceso en los SO ms clsicos, como UNIX. Vamos a intentar dar una definicingeneral de lo que entiende Windows NT por proceso y subproceso, aunque despusiremos perfilando poco a poco ambos conceptos. Un proceso es una entidad no ejecutable que posee un espaciode direcciones propio y aislado, una serie de recursos y una serie desubprocesos. En el espacio de direcciones hay colocadoalgn cdigo ejecutable(entre otras cosas). Bien, hemos dicho que un proceso es una entidad"no ejecutable". En efecto, no puede ejecutar el cdigo de su propioespacio de direcciones, sino que para esto le hace falta al menos un subproceso.Por consiguiente, un subproceso es la unidad de ejecucin de cdigo. Unsubproceso est asociado con una serie de instrucciones, unos registros, unapila y una cola de entrada de mensajes (enviados por otros procesos o por elSO). Cuando se crea un proceso, automticamente se crea unsubproceso asociado (llamado subproceso primario). Los subprocesos tambin sellaman "hebras de ejecucin" (threads of execution). Debe quedarnosmuy claro, pues, que lo que se ejecutan son subprocesos, no procesos. Losprocesos son como el soporte sobre el que corren los subprocesos. Y entre lossubprocesos se reparte el tiempo de CPU. Podemos pensar en los subprocesos de Windows NT como losprocesos de los SO clsicos (aunque existen matices, como sabemos). A veces,por comodidad y por costumbre, usaremos ambos trminos como sinnimos, ydiremos que "el proceso A llama a CreateWindow", aunque se debeentender que "un subproceso del proceso A llama a CreateWindow".

Un proceso tiene un espacio de direcciones virtuales de 4 Gb.En algn lugar de ese espacio s halla e un cdigo ejecutable (que quizs es laimagen de un programa en disco). Un proceso puede crear subprocesos, estando sunmero fijado por el sistema. Se dice que muere cuando todos sus subprocesoshan muerto (incluso aunque el subproceso primario haya muerto, si an existealgn subproceso propiedad del proceso, el proceso seguir vivo). Planificacin del Tiempo de la CPU por Round Robin conPrioridades Windows NT utiliza la planificacin del anillo circular o round robin. Estatcnica consiste en que los subprocesos que pueden ser ejecutados se organizanformando un anillo, y la CPU va dedicndose a cada uno durante un tiempo. Eltiempo mximo que la CPU va a estar dedicada a cada uno se denomina quantum, yes fijado por el Administrador del Sistema. Si el subproceso est esperando por alguna entrada-salida opor algn suceso, la CPU lo pondr a dormir, y pondr en ejecucin alsiguiente del anillo. Si un subproceso que la CPU est ejecutando consume suquantum, la CPU tambin lo pondr a dormir, pasando al siguiente. En Windows NT, existe un rango de prioridades que va del 1 al31, siendo 31 la ms alta. Todo proceso y subproceso tienen un valor deprioridad asociado. Existe un anillo o cola circular por cada uno de los nivelesde prioridad. En cada anillo estn los subprocesos de la misma prioridad. ElExecutive comienza a repartir el tiempo de CPU en el primer anillo de mayorprioridad no vaco. A cada uno de esos subprocesos se les asignasecuencialmente la CPU durante el tiempo de un quantum, como ya indicamos antes.Cuando todos los subprocesos de nivel de prioridad n estn dormidos, elExecutive comienza a ejecutar los del nivel (n-1), siguiendo el mismo mecanismo. Anlogamente, si un subproceso se est ejecutando, yllegara uno nuevo de prioridad superior, el Executive suspendera al primero(aunque no haya agotado su quantum), y comenzara a ejecutar el segundo (asignndoleun quantum completo). Prioridad de proceso y subproceso Un proceso se dice que pertenece a una clase de prioridad.Existen cuatro clases de priorida que d, son: Desocupado. Corresponde a un valor de prioridad 4. Normal. Corresponde a un valor de prioridad 7 9. Alta. Corresponde a un valor de prioridad 13. Tiempo Real. Corresponde a un valor de prioridad 24. La clase "Normal" es la que el Executive asocia alos procesos por defecto. Los procesos en esta clase se dice que tienen unaprioridad dinmica: el Executive les asigna un valor de 7 si se estnejecutando en segundo plano, mientras que si pasan a primer plano, la prioridadse les aumenta a un valor de 9. La clase "Desocupado" va bien para procesos que seejecuten peridicamente y que por ejemplo realicen alguna funcin demonitorizacin. La clase "Alta" la tienen procesos tales como elAdministrador de Tareas (Task Manager). Dicho proceso est la mayor parte deltiempo durmiendo, y slo se activa si el usuario pulsa Control-Esc. Entonces,el SO inmediatamente pone a dormir al subproceso en ejecucin (aunque no hayaagotado su quantum) y ejecuta al subproceso correspondiente del procesoAdministrador de Tareas que , visualizar el cuadro de dilogo caracterstico,mostrndonos las tareas actuales.

La clase "Tiempo Real" no es recomendable que latenga ningn proceso normal. Es una prioridad ms alta incluso que muchosprocesos del sistema, como los que controlan el ratn, el teclado, elalmacenamiento en disco en segundo plano, etc. Es evidente que usar estaprioridad sin un control extremo puede causar consecuencias nefastas. As como un proceso tiene una prioridad oscilando entrecuatro clases, un subproceso puede te ner cualquier valor en el rango [1,31]. Enprincipio, cuando el subproceso es creado, su prioridad es la correspondiente ala de la clase de su proceso padre. Pero este valor puede ser modificado si elsubproceso llama a la funcin BOOL SetThreadPriority (HANDLE hThread, int nPriority); Donde: hThread es el descriptor del subproceso nPriority puede ser: THREAD_PRIORITY_LOWEST : resta 2 a la prioridad del padre THREAD_PRIORITY_BELOW_NORMAL: resta 1 a la prioridad delpadre THREAD_PRIORITY_NORMAL: mantiene la prioridad del padre THREAD_PRIORITY_ABOVE_NORMAL: suma 1 a la prioridad del padre THREAD_PRIORITY_HIGHEST: suma 2 a la prioridad del padre THREAD_PRIORITY_IDLE: hace la prioridad igual a 1,independientemente de la prioridad del padre THREAD_PRIORITY_TIME_CRITICAL: hace la prioridad igual a 15si la clase de prioridad del padre es desocupada, normal o alta; si es tiemporeal, entonces hace la prioridad igual a 31 De esta manera es como calcula el Executive la prioridad deun subproceso. Por tanto, la prioridad de un subproceso es relativa a la de supadre (excepto en IDLE y TIME_CRITICAL). Mediante suma y resta de la prioridaddel padre obtenemos todo el rango de prioridades:

Clase proceso padre Prior. Subproceso Crtico en tiempo Ms alta

Clase desocupado

Clase normal en primer plano

Clase normal en segundo plano

Clase alta

Clase tiempo real

15,00

15,00

15,00

15,00

31,00

6,00

9,00

11,00

15,00

26,00

Ms que normal

5,00

8,00

10,00

14,00

25,00

Normal

4,00

7,00

9,00

13,00

24,00

Menos que normal Ms baja

3,00

6,00

8,00

12,00

23,00

2,00

5,00

7,00

11,00

22,00

Desocupado

1,00

1,00

1,00

1,00

16,00

La ventaja de este sistema de las prioridades relativas esque si un proceso cambia su clase de prioridad durante su vida, sus subprocesoshijos tendran sus prioridades automticamente actualizadas. Creacin y destruccin de procesos La llamada al sistema que crea un proceso es una de las mscomplejas de todo el API Win32. Vamos a comentarla para comprender mejor laforma en la que el Executive trabaja. Un proceso se crea cuando un subproceso de otro proceso haceuna llamada a: BOOL CreateProcess (LPCTSTR lpszImageName, LPCTSTR lpszCommandLine,LPSECURITY_ATTRIBUTES lpsaProcess, LPSECURITY_ATTRIBUTES lpsaThread, BOOLfInheritHandles, DWORD fdwCreate, LPVOID lpvEnvironment, LPTSTR lpszCurDir,LPSTARTUPINFO lpsiStartInfo, LPROCESS_INFORMATION lppiProcInfo); El Executive crea un espacio virtual de 4 Gb para el proceso,y tambin crea el subproceso primario. Veamos el significado de los parmetros: lpszImageName: es el nombre del archivo que contiene el cdigoejecutable que el Executive asignar en el espacio virtual del proceso. Si esNULL, entonces se entender que viene dado en el siguiente parmetro. lpszCommandLine: argumentos para el nombre del archivo lpsaProcess, lpsaThread y fInheritHandles: los dos primerosson punteros con los que podemos dar unos atributos de seguridad para el procesoy su subproceso primario. Si pasamos NULL, el sistema pondr los valores pordefecto. Los parmetros son punteros a una estructur del tipo: a El campo lpSecurityDescriptor se refiere a permisos sobre elobjeto proceso, pero no he encontrado ms informacin al respecto. De esta estructura vamos a destacar el campo bInheritHandle,que se refiere a la herencia. En Windows NT, cualquier objeto que creemos va atener asociada una estructura de este tipo en donde se indicar, con el parmetrobInheritHandle, si dicho objeto es heredable o no. El objeto es propiedad de unproceso. Ese proceso puede crear procesos hijos; dichos procesos, por defec to,no heredarn ninguno de los objetos de su padre. Los procesos hijos que tenganla capacidad de heredar, heredarn aquellos objetos de su padre que tengan elcampo bInheritHandle a TRUE.

Ahora bien, un proceso y un subproceso son tambin objetos.Por tanto, ambos objetos podrn ser heredables por otros procesos. Si el campobInheritHandle es TRUE en la estructura apuntada por lpsaProcess, entonces elproceso que estamos creando ser heredable por otros procesos hijos de su mismopadre. Si el campo bInheritHandle es TRUE en la estructura apuntadapor lpsaThread, entonces e subproceso primario del proceso que estamos creandoser igualmente heredable. Resta explicar el parmetro fInheritHandles. Si vale TRUE,entonces el proceso que estamos creando podr heredar todos los objetosheredables de su padre (es decir, aquellos objetos cuyo campo bInheritHandle seaTRUE). No se debe confundir todo esto con herencia entre procesos y subprocesoshijos. Un subproceso siempre podr tener acceso a los objetos creados por elproceso al que pertenece (o mejor dicho, creados por algn otro subproceso delproceso al que pertenece). fdwCreate: es una mscara donde se pueden especificar (mediante OR lgica)muchos indicadores para el proceso a crear. Los ms importantes son:la clase deprioridad del proceso: IDLE_PRIORITY_CLASS (desocupado), NORMAL_PRIORITY_CLASS(normal), HIGH_PRIORITY_CLASS (alta), REALTIME_PRIORITY_CLASS (tiempo real)si elproceso va a ser dormido al crearse, usando CREATE_SUSPENDED lpvEnvironment: apunta a un bloque de memoria que contienecadenas de entorno. Si vale NULL, usar las mismas cadenas que su procesopadre. Las cadenas de entorno no son ms que variables con algn valor queusarn los procesos con algn fin, (por ejemplo, el directorio home, el path).Tiene un significado similar al concepto de entorno de UNIX. lpszCurDir: cadena con directorio y unidad de trabajo para elnuevo proceso. lpsiStartInfo: apunta a una estructura bastante grande que novamos a escribir. Los campos de dicha estructura dan informaciones al subsistemaWin32 como por ejemplo si el proceso va a estar basado en GUI o en consola (GUIes con ventanas; consola es simulando el modo texto), el tamao de la ventanainicial del proceso, las coordenadas de dicha ventana, su tamao, su ttulo... En hprocess y hThread el Executive devuelve un par dedescriptores a los objetos proceso y subproceso primario recin creados, y queservirn para hacer referencias a los mismos. Cada vez que el Executive creacualquier objeto, asocia con dicho objeto un contador de uso. Cada vez que unproceso distinto usa un mismo objeto, incrementa el contador en 1. Cada vez queun proceso libera un objeto, decrementa el contador en 1. Cuando el contador deuso de un objeto es 0, el Executive destruye el objeto. Pues bien, cuandoCreateProcess devuelve el control, los objetos proceso y subproceso primariotienen sus respectivos contadores con valor 2. De este modo, para que elExecutive pueda destruirlos, habrn de ser liberados dos veces: una, cuandoellos mismos terminen (el contador pasara a valer 1), y otra, cuando elproceso padre los libere (o sea, cuando cierre los descriptores; as, suscontadores valdran 0 y 0, y el Executive los destruira). De aqu es infiereque es vital que el proceso padre cierre esos descriptores (si no, no sedestruiran los objetos y podra desbordarse la memoria). La llamada paracerrar descriptores es BOOL CloseHandle (HANDLE hobject); dwProcessId y dwThreadId son unos identificadores nicos queel Executive asocia al proceso y subproceso primario, respectivamente, anlogosal PID en UNIX. Hasta aqu la llamada al sistema que nos permite crearprocesos. La llamada para finalizar el proceso es, afortunadamente, mucho mssimple: VOID ExitProcess (UINT fuExitCode); que devuelve el enterofuExitCode, que es un cdigo de salida que el proceso enva antes de finalizar(que diga si ha finalizado con xito, si no, etc). Cuando un proceso termina,se realizan las siguientes acciones:

Todos los subprocesos del proceso finalizan Se cierran todos los descriptores de objetos del Executive yde Win32 abiertos por el proceso El estado del objeto proceso para a estar sealado El estado de terminacin del proceso se pone al cdigo desalida adecuado Hemos dicho que el objeto proceso se pone a estado sealado. Un objeto puedetener dos estados: sealado y no sealado, estados que utiliza el sistema ylos propios procesos para varias funciones. El curioso lector puede consultar elapartado de "Comunicacin entre procesos". Creacin y destruccin de subprocesos Anlogamente a como nos hemos auxiliado de la llamada alsistema CreateProcess para comprender el mecanismo de creacin de procesos,vamos a hacer lo propio para la creacin de subprocesos. Un subproceso se creacuando otro subproceso hace una lla mada a: HANDLE CreateThread (LPSECURITY_ATTRIBUTES lpsa, DWORD cbStack,LPTHREAD_START_ROUTINE lpStartAddr, LPVOID lpvThreadParm, DWORD fdwCreate,LPDWORD lpIDThread); lpsa: tiene el mismo significado que en CreateProcess, es decir, un puntero auna estructura SECURITY_ATTRIBUTES, donde se especifican permisos del subprocesoy si es heredable o no. cbStack: vamos a aprovechar este parmetro para explicar la pila de unsubproceso. Todo subproceso tiene una pila asociada situada en el espaciovirtual del proceso al que pertenece. Virtualmente, la pila tiene un tamao pordefecto de 1 Mb (y adems es el mximo; tamaos inferiores pueden serindicados al enlazar la aplicacin). De esa pila virtual el subproceso puedetener asignada en memoria un trocito. El tamao de ese trocito viene dado porel parmetro cbStack, y por defecto es 1 pgina (4 Kb). Tcnicamente, se diceque la pila tiene reservado un espacio de 1 Mb, y asignado un espacio de cbStackbytes. (el significado de ambos trminos lo veremos detenidamente en el captulode administracin de la memoria). Si el subproceso desborda su trocito de pilaasignado en memoria se eleva una excepcin; el Executive captura la excepciny asigna otros cbStack bytes en memoria fsica para la pila del subproceso. Portanto, la pila crece dinmicamente en trozos de cbStack bytes. Lo mseficiente es que cbStack sea mltiplo del tamao de la pgina. lpStartAddr, lpThreadParm: ya dijimos que todo subprocesoejecuta una porcin de cdigo del proceso al que pertenece. Este parmetroapunta a la funcin que contiene el cdigo a ejecutar por nuestro subproceso.Es posible hacer que varios subprocesos tengan la misma funcin asociada. Elperfil de la funcin es fijo: El parmetro lpvThreadParm de la funcin es justamente elmismo que se le pasa a CreateThread; de hecho, el sistema se limita a pasardicho parmetro a la funcin asociada al subproceso cundo ste comienza suejecucin. El parmetro puede ser un valor de 32 bits o un puntero de32 bits. Puede servir para dar algn tipo de inicializacin al subproceso. El parmetro dwresult de la anterior funcin es un cdigode salida que el subproceso devuelve cuando acaba de ejecutar cdigo. Essimilar al cdigo que devuelven los procesos al acabar. fdwCreate: si vale 0, entonces el subproceso comienza aejecutarse en cuanto est creado. Si vale CREATE_SUSPENDED, entonces se crear,pero automticamente ser suspendido. lpIDThread: debe ser un puntero a una estructura DWORD, dondeel Executive pondr el identificador que le ha asignado al subproceso. Esobligatorio pasar una direccin vlida.

El subproceso recin creado iniciar su ejecucininmediatamente antes del retorno de CreateThread (a menos que hayamosespecificado el indicador CREATE_SUSPENDED). Comunicacin y Sincronizacin de Procesos Mediante Objetos En Windows NT, los mecanismos clsicos de sincronizacin entre procesos(como los semforos, las regiones crticas, los sucesos, etc.) son tratadoscomo objetos. Es ms, existen objetos no especficos de sincronizacin peroque tambin pueden ser usados con e stos fines. Por tanto, vamos en primer lugara enumerar todos los objetos de sincronizacin y a dar algunas caractersticasglobales, para posteriormente adentrarnos a estudiar los ms importantes. Podemos sincronizar subprocesos mediante alguno de lossiguientes objetos: o o o o o o o o Semforos Mutexes Sucesos Archivos Procesos Subprocesos Entrada del terminal Notificacin de cambio de archivo

Antes hemos mencionado las regiones crticas. Aunque WindowsNT las incluye como mecanismo de sincronizacin, no las trata explcitamentecomo objeto. No obstante tambin las estudiaremos en este apartado por mantenerla homogeneidad. Como ya esbozamos en el captulo de los procesos, en cualquier instante unobjeto est en uno de dos estados: sealado (1) y no sealado (0). Cadaestado tiene un significado dependiendo de la clase del objeto. Por ejemplo, en el apartado anterior vimos que durante la vida de un procesoo un subproceso su estado era no sealado, pero que al morir pasaban al estadosealado. De aqu que ambos tipos de objetos sirvan para la sincronizacin.Por ejemplo, un subproceso A puede querer dormir hasta que otroproceso/subproceso B acabe; por tanto, A dormir mientras el objeto asociado alB est no sealado. En cuanto B pase a sealado, A despertar. Igualmente, un subproceso se puede sincronizar con el fin de unalectura/escritura en un archivo. En general, cuando alguna de estas operacionesfinalizan, el objeto archivo en cuestin pasa a estado sealado. El objeto asociado a la entrada de teclado se pone sealado cuando existealgo en el buffer de entrada. La aplicacin de este hecho para sincronizacines evidente. Un subproceso puede as estar durmiendo mientras el buffer estvaco. El resto de objetos los veremos con ms detalle a lo largo de este captulo.Pero antes vamos a dar las llamadas al sistema que se utilizan para lasincronizacin con objetos. Se trata de: DWORD WaitForSingleObject (HANDLE hObject, DWORD dwTimeout); Esta llamada simplemente mantiene al subproceso que larealiza dormido hasta que el objeto identificado por hObject pase al estado sealado.El parmetro dwTimeout indica el tiempo (en ms) que el subproceso quiereesperar por el objeto. Si vale 0, entonces la llamada slo hace una comprobacindel estado y retorna inmediatamente; si devuelve WAIT_OBJECT_0, el objeto

estabasealado; si devuelve WAIT_TIMEOUT, el objeto estaba no sealado. Si comotiempo metemos INFINITE, el subproceso dormir hasta que el objeto pase a sealado.Hay un par de cdigos de salida ms que comentaremos en su momento (cuandoexpli uemos los mutex). q DWORD WaitForMultipleObjects (DWORD cObjects, LPHANDLElpHandles, BOOL bWaitAll, DWORD dwTimeout); Es parecida a la anterior pero da la posibilidad de esperarpor varios objetos o bien por alguno de una lista de objetos. cObjects indica elnmero de objetos a comprobar. lpHandles apunta a una matriz que contienedescriptores a los objetos. El booleano bWaitAll indica si queremos esperar aque todos los objetos pasen a estado sealado o tan slo uno, y dwTimeout esel tiempo a esperar. Si hay varios objetos que han pasado al estado sealado,la llamada coge sus descriptores, toma el menor y devuelve su posicin dentrode la matriz (sumada a un cdigo de retorno anlogo a los deWaitForSingleObject). El tema de sincronizacin est ntimamente relacionado conel de interbloqueos. Supongamos que tenemos dos subprocesos A y B compitiendopor dos objetos 1 y 2, esperando a que ambos estn sealados, para lo cual hanhecho sendas llamadas a WaitForMultipleObjects. Supongamos que 1 pasa a estadosealado. Y supongamos que el Executive decidiera otorgar ese hecho al procesoA, colocando a 1 de nuevo a no sealado. Mientras tanto, 2 pasa tambin a sealado,y el Executive otorga este hecho a B, y tambin pone a 2 a no sealado. Enesta situacin, ninguno de los dos subprocesos podra terminar nunca, puescada uno estara esperando a que el objeto del otro pasara a sealado.Entonces A y B estn interbloqueados. Para evitar esta situacin, el Executiveno entrega los objetos hasta que ambos estn sealados; en ese momentodespertara a uno de los subprocesos. El otro seguira dormido hasta que elprimer subproceso terminara de trabajar con los objetos. A continuacin se estudia cada uno de los objetos especficosde sincronizacin de Windows NT. Secciones Crticas Las secciones crticas son un mecanismo para sincronizarsubprocesos pertenecientes a un mismo proceso, pero, como ya hemos indicado, noson objetos. Una seccin o regin crtica (SC) es un trozo de cdigoejecutable tal que para que un subproceso pueda ejecutarlo se requiere que tengaacceso a una estructura de datos especial y compartida. Dicha estructura es del tipo CRITICAL_SECTION, cuyos camposno son interesantes, y adems no son accesibles directamente, sino a travs deuna llamada al subsistema Win32: VOID InitializeCriticalSection (LPCRITICAL_SECTIONlpCriticalSection); Veamos algunas llamadas para manejar las SC: VOID EnterCriticalSection (LPCRITICAL_SECTION lpCriticalSection); VOID LeaveCriticalSection (LPCRITICAL_SECTION lpCriticalSection); La primera sirve para que un subproceso solicite entrar en una SC. La segundapermite salir de la SC a un subproceso que est dentro de la misma. La funcin de entrar opera as: la primera vez que es llamada, se registraen la estructura CRITICAL_SECTION un identificador del subproceso que la posee. Si antes de que el subproceso la abandone, el SO entrega la CPU a otro (elcaso ms frecuente), y entonces ese otro subproceso hace la llamada para entraren la SC, entonces la funcin ve que la estructura ya est en uso, con lo queel segundo subproceso sera puesto a dormir.

Cuando la CPU vuelva al primero y ste haga una llamada parasalir, la estructura ser asignada al segundo subproceso. Si un subproceso vuelve a llamar a la funcin de entrarestando ya dentro de la SC, simplemente se incrementar un contador de usoasociado con el objeto SC. Ms tarde, deber hacer tantas otras llamadas a lafuncin de salir para poner el contador a 0; en caso contrario, ningn otrosubproceso podra ocupar la SC. La estructura CRITICAL_SECTION y todos los recursos que el SOle hubiera asignado se pueden eliminar haciendo una llamada a VOID DeleteCriticalSection (LPCRITICAL_SECTIONlpCriticalSection); Sera catastrfico usar esta funcin estando un subprocesodentro. Exclusin Mutua (Mutex) Los objetos exclusin mutua (abreviadamente mutex, de mutualexclusin) son muy parecidos a las SC, pero permiten sincronizar subprocesospertenecientes a procesos distintos. Se crean con la llamada: HANDLE CreateMutex (LPSECURITY_ATTRIBUTES lpsa, BOOLfInitialO wner, LPTSRT lpszMutexName); fInitialOwner: dice si el subproceso que crea el mutex ha deser su propietario inicial o no. Si vale TRUE, entonces el estado inicial delobjeto mutex sera no sealado, por lo que todo subproceso que espere por lsera inmediatamente puesto a dormir. Si vale FALSE, el mutex se crea conestado sealado, por lo que al primer proceso que estuviera esperando le seraasignado y podra continuar ejecutndose. lpszMutexName: apunta a una cadena con el nombre que le hemosquerido dar al o bjeto (o NULL si no se pone un nombre). La llamada devuelve un descriptor al objeto creado. Si otro subproceso llamara a la funcin pasndole el mismonombre de mutex, el SO comprobara que ya est creado y devolvera otrodescriptor al mismo objeto. HANDLE OpenMutex (DWORD fwdAccess, BOOL fInherit, LPTSTRlpszMutexName); Esta funcin comprobara si existe algn objeto mutex connombre lpszMutexName. Si es as, devolvera un descriptor al mismo. Si no,devolvera NULL. El booleano fInherit permite que el mutex sea heredado por lossubprocesos hijos. Si el mutex no tuviera nombre, un subproceso podra obtenerun descriptor al mismo llamando a DuplicateHandle. Otra diferencia de los mutex con las SC (y en general concualquier objeto de sincronizacin en Windows NT) es que un subproceso mantienela propiedad de un mutex hasta que quiera liberarlo, pero hasta el punto de que,si el subproceso muere y no ha liberado al mutex, ste seguira siendo de supropiedad. As, si un mutex est libre (sealado) y es tomado por unsubproceso (pasa a no sealado), y dicho subproceso finaliza antes deliberarlo, el estado del mutex pasara a sealado; los subprocesos queestuvieran esperando por el mutex seran despertados pero no se les asignarael objeto a

ninguno, sino que con el valor WAIT_ABANDONED de retorno de lasllamadas WaitFor...Object(s) se les informara de lo que ha sucedido, de que elmutex no ha sido liberado sino abandonado. Esto se considera como una situacinde fallo en un programa. Para liberar un mutex usaremos la llamada BOOL ReleaseMutex (HANDLE hMutex); Donde: hMutex: es un descriptor al objeto. La funcin decrementa elcontador de uso que el subproceso tiene sobre el mutex. Cuando sea 0, el objetopodr ser asignado al primer subproceso que por l est esperando, igual quecon las SC. Semforos Un semforo es un objeto distinto de las SC y los mutex. Adiferencia de ambos, el objeto semforo puede ser posedo a la vez por variossubprocesos, y no posee dentro ningn identificador del subproceso/s que lo estusando. Lo que tiene es un contador de recursos, que indica el nmero desubprocesos que pueden acceder al semforo. Cuando un subproceso toma el objetosemforo, el SO mira si el contador de recursos del mismo es 0. De ser as,pone al subproceso a dormir. Si no es 0, asigna el semforo al subproceso ydecrementa el contador. Cada vez que un subproceso libera el semforo, seincrementa el contador. Un semforo est sealado cuando su contador es mayor que0, y no sealado cuando su contador vale 0. Un semforo se crea con la llamada: HANDLE CreateSemaphore (LPSECURITY_ATTIBUTES lpsa, LONG cSemInitial, LONGcSemMax, LPTSTR lpszSemName); cSemInitial es el valor inicial no negativo del contador de recursos. cSemMax es el valor mximo que puede alcanzar dicho contador (por tanto 0<= cSemInitial <= cSemMax) lpszSemName es el nombre que le damos al objeto. HANDLE OpenSemaphore (DWORD fdwAccess, BOOL fInherit, LPTSTR lpszName); La semntica de esta llamada es anloga a la de OpenMutex. Para incrementar el contador de referencia del semforo se usa: HANDLE ReleaseSemaphore (HANDLE hSemaphore, LONG cRelease, LPLONGlplPrevious); Donde: cRelease indica el nmero de veces que queremos incrementar el contador (elnmero de veces que liberamos el semforo). A la vuelta de la funcin,tendremos en lplPrevious un puntero al valor anterior del contador. Por tanto,si queremos averiguar el valor del contador tenemos que modificarlo. Ni siquierallamando a la funcin con cRelease igual a 0 podramos saber el valor anteriorsin modificar el semforo, pues entonces la funcin devuelve 0 como datoapuntado por lplPrevious. Sucesos.

Los sucesos son objetos utilizados para indicar a lossubprocesos que ha ocurrido algo en el entorno. Se puede distinguir dos tipos deobjetos suceso: Sucesos con inicializacin manual. Sucesos con autoinicializacin. Cualquier objeto suceso podr estar en estado sealado o nosealado. No sealado significa que la situacin asociada con el objeto anno ha ocurrido. Sealado indica que s se ha producido. Ambos tipos de objeto se crean con la misma llamada: HANDLE CreateEvent (LPSECURITY_ATTIBUTES lpsa, VOOLfManualReset, BOOL fInitialState, LPTSTR lpszEventName); fManualReset a TRUE le indicar al SO que queremos crear unsuceso de inicializacin manual, y a FALSE, un suceso de autoinicializacin. fInitialState indica el estado inicial del objeto; un valorTRUE significa que el suceso se crear como obejto sealado, y a FALSE como nosealado. Como vimos con los otros tipos de objetos de sincronizacin,otros procesos pueden acceder al mismo objeto usando CreateEvent y el mismonombre, o usando la herencia, o con DuplicateHandle, o con: HANDLE OpenEvent (DWORD fdwAccess, BOOL fInherit, LPTSTRlpszName); Sucesos con inicializacin manual (manual reset) Este tipo de objetos se usan para que, cuando el suceso ocurra, es decir, seponga a sealado, todos los subprocesos que esperaban por ese suceso sedespierten a la vez y todos puedan seguir ejecutndose. Por tanto, ahora lasfunciones WaitFor...Objext(s) no van a tocar el estado del objeto, sino que debehacerlo el propio subproceso que cre el objeto. Dicho subproceso puede usarlas llamadas: BOOL SetEvent (HANDLE hEvent); BOOL ResetEvent (HANDLE hEvent); que ponen, respectivamente, el suceso identificado por hEvent en estado sealadoy no sealado. O sea, con SetEvent indicaremos que la situacin asociada alobejto se ha producido, y con ResetEvent indicaremos lo contrario. Existe una llamada muy til con este tipo de objetos: BOOL PulseEvent (HANDLE hEvent); que le da un "pulso" al suceso hEvent: lo pone enestado sealado, con lo que se libera a todos los subprocesos en espera (que seseguirn ejecutando), y entonces lo pone a no sealado, con lo que lossubprocesos que a partir de ese momento esperen por el suceso sern do rmidos.Por tanto, equivale a SetEvent + liberacin + ResetEvent. Sucesos con autoinicializacin (auto-reset) Con estos objetos las funciones WaitFor...Object(s) van afuncionar como con cualquier otro tipo de objeto. Por tanto, cuando la situacinasociada con el suceso ocurra y ste se ponga a sealado (con

SetEvent), slouno de los subprocesos que estaban esperando podr continuar, y su funcinWaitFor...Object(s) correspondiente pondr el estado del objeto a no sealado.La funcin ResetEvent no tendra efecto aqu. La funcin PulseEvent pondrael suceso a sealado, liberara un slo subproceso de los que estnesperando, y pondra el suceso a no sealado.

5. Administracion De La Memoria La parte de Windows NT que soporta la gestin de la memoriase denomina Gestor de Mquina Virtual (VMM), y reside en el Executive, porencima del ncleo pero ejecutndose en modo supervisor, como vimos en laintroduccin. En Windows NT se utiliza memoria virtual paginada. En algunas mquinas, comolas CPU Intel 386 en adelante, combina paginacin con segmentacin. El tamaode la pgina depende de la mquina. En la CPU anterior es de 4 Kb. Espacio de Direcciones de un Proceso Todo proceso que se crea en Windows NT posee un espacio de direccionesvirtuales de 4 Gb exclusivos de l. Ningn otro podr acceder a esasdirecciones, sencillamente porque no las ve!. Para un proceso, todo lo que vees suyo, y ve virtualmente 4 Gb. Los 2 Gb superiores estn reservados al SO, ascomo los 64 Kb primeros y los 64 Kb ltimos de los 2 Gb inferiores. El resto delos 2 Gb inferiores son para uso del proceso. Distinguimos varias zonas: Direcciones para las DLL del sistema (NTDLL, KERNEL32, USER32, GDI32 ...). Direcciones para las DLL propias de la aplicacin. Bloques y pilas de los subprocesos. Imagen del archivo ejecutable: cdigo, datos, cabecera, informacin deldepurador y tab de la activacin imagen. Adems, cada proceso posee su propia tabla de implantacin de pginas(TIP), a dos niveles. El objetivo de esa tabla (tambin llamada tabla detraduccin) es, dada una direccin virtual, devolver su direccin fsicaasociada. A veces la direccin virtual no tiene correspondencia en memoria fsica.Entonces se dice que se ha producido un fallo o defecto de pgina (page fault).En el siguiente apartado vamos a describir cmo funciona el VMM y qu hacecuando se dan los fallos de pgina. Funcionamiento del VMM Cada proceso tiene asignado un nmero que indica el mximo de pginas fsicasque se le pueden conceder. Dicho nmero es ajustado por el llamado gestor delconjunto de trabajo, del que luego hablaremos. Adems, cada proceso llevaasociada una lista que contiene referencias a las pginas fsicas a las que seha accedido menos ltimamente. Cuando el proceso accede a una direccin que no tiene direccin fsicaasociada en la TIP, se produce un fallo de pgina. Entonces, el VMM consulta elnmero de pginas que el proceso tiene asignadas. Si no ha llegado al lmite,se le concede una nueva pgina fsica y se escribe con la correspondientedesde el disco. Esto se denomina paginacin bajo demanda. Si por el contrarioya haba llegado al lmite, entonces hay que descargar una pgina fsica aldisco para subir a memoria la que ocasion el fallo. El VMM elige la pgina vctimade la lista de menos recientemente usadas del proceso. Ntese que aunque existan pginas libres en la memoria, si el proceso agotasu nmero de pginas asignadas, se producir el swapping, y adems de una desus propias pginas. Este mecanismo

puede parecer ilgico, pero presenta tantoventajas como inconvenientes. Como problema puede nombrar por ejemplo, que si unproceso estuviera gran parte del tiempo dormido (en espera de un suceso o de unaE/S), dicho proceso estara ocupando pginas fsicas que de otro modo podranser descargadas. Como ventaja tenemos que, con este esquema, procesos querequieran muchos recursos no dejarn fuera de juego a aquellos cuya demanda dememoria sea escasa. No obstante, el problema planteado es paliado (al menos engran medida) por una parte del VMM llamada gestor del conjunto de trabajo.Realiza dos funciones fundamentales: Por un lado, peridicamente revisa las estadsticas sobre el uso de la CPUpor cada proceso. Siguiendo este criterio, procede a ajustar el nmero queindica el mximo de pginas fsicas asociadas a cada uno. A aquellos procesoscon poca actividad se les bajar el nmero (lo que acarrear un descargue desus pginas fsicas, si las tiene, cuando sean necesarias), y a aquellos conmucha carga se les subir el nmero. Por otro lado, y tambin de forma peridica, roba a los procesos pginas fsicas,elegidas de entre las menos recientemente usadas por cada uno. Esteprocedimiento se reliza a la frecuencia necesaria para que los procesos no seralenticen demasiado por los fallos de pgina. El objetivo de esto es manteneruna reserva de pginas para que una repentina demanda no ocasione una cada enprestaciones del sistema completo. Por ejemplo, cuando se inicia un procesonuevo se suele requerir una cantidad considerable de pginas. Para llevar a cabo estas tareas, las pginas fsicas se clasifican en unade cuatro listas que son mantenidos por el gestor del conjunto de trabajo: o o o o lista de pginas modificadas lista de pginas no activas lista de pginas liberadas lista de pginas a cero

Cada pgina que el gestor roba a un proceso es borrada su lista de menosrecientemente usadas e incluida en la lista de modificadas (y las entradascorrespondientes de la TIP marcadas como no vlidas, de forma que se produzcafallo de pgina al acceder el proceso a dichas direcciones). Dicha listacontiene pginas robadas que an estn en memoria RAM pero que no han sidoescritas a disco (al archivo de paginacin). Cuando se produzca un fallo de pgina,si la direccin fsica correspondiente estuviera en una de estas pginas,simplemente se volvera a insertar en la lista del proceso y se ajustara suTIP. Cuando la lista de modificadas se hace suficientemente grande, otra parte delVMM (el escritor de pginas) copia algunas pginas de la lista al archivo depaginacin, las borra de la lista de modificadas y las aade a la lista deinactivas. Ah estn las pginas que han sido robadas, que estn en RAM yadems en el archivo de paginacin. El tratamiento de un fallo de pgina aqutambin sera muy rpido y simple. Cuando un proceso libera memoria, sus pginas fsicas asociadas se aadena la lista de liberadas. Son, por tanto, potencialmente utilizables sinnecesidad de escribirlas en el fichero de swapping pero su contenido no ha sidoborrado (estn tal y como las dej el proceso propietario). Peridicamente,estas pginas van siendo inicializadas con ceros,y aadidas a la lista de pginasa cero. El mecanismo de inicializacin es para proteger la intimidad delantiguo proceso propietario. Cualquier pgina que se entrega a un proceso ha dehaber sido convenientemente inicializada. Cuando un proceso requiere memoria fsica, el VMM comienza cogiendo pginasde la lista de inicializadas. Cuando est vaca, toma de la lista deliberadas, y las inicializa. Cuando sta se vaca, toma de la lista deinactivas, y las inicializa. Slo como ltima opcin recurre a lasmodificadas. Estas ltimas requieren escritura en el archivo de paginacinjunto con inicializacin, lo cual es un proceso lento.

En ambientes en los que la memoria es escasa, el gestor del conjunto detrabajo se centra en mantener un conjunto aceptable de pginas disponibles, msque en revisar las esta dsticas de uso de la CPU. Como valores aproximativos, podemos sealar que si el nmero de pginas acero ms las liberadas ms las inactivas suman menos de 20, el gestor robarpginas a procesos que comparten la CPU. Si el nmero de modificadas superalas 30, proceder a descargar algunas a disco, pasndolas a inactivas. Archivos Asignados en Memoria Estudiemos ahora cmo el SO utiliza esta facilidad para cargar el cdigo deun ejecutable y sus bibliotecas DLL asociadas. Un archivo asignado en memoria es todo aquel archivo para el que se hareservado una regin del espacio de direcciones virtuales de un proceso. Puedeestar asignado el archivo completo o slo una porcin del mismo (llamadavista). En principio, el VMM no asigna ninguna pgina fsica para el archivoasignado en memoria. El proceso simplemente supone que en ciertas direcciones desu espacio tiene cargado el fichero, as que cuando acceda a alguna se producirun fallo de pgina. Es entonces cuando el VMM le asigna algunas pginas fsicasy las copia desde el disco (paginacin bajo demanda, como comentbamos antes). La gestin del VMM de los archivos asignados en memoria es como cualquierotra regin del espacio direccionable del proceso, excepto que el swapping sehace directamente sobre el archivo (o sea, el archivo de intercambio es elpropio archivo asignado en memoria). Cuando se arranca un proceso con su cdigo grabado en un fichero, el VMMasigna automticamente dicho fichero en el espacio de direcciones del proceso.Tambin asigna todas las bibliotecas incluidas explcitamente y todas aquellasa las que se hace referencia en el cdigo. Dentro del ejecutable existe unatabla llamada tabla de activacin imagen, incluida por el enlazador, cuyasentradas contienen las funciones de biblioteca que se llaman durante el cdigo.Una vez que se cargan las DLL (bibliotecas) en el espacio, el VMM completa latabla escribiendo para cada entrada la direccin que ocupa la correspondientefuncin en el espacio del proceso. Por tanto, cada llamada a funcin implicauna bsqueda en la tabla. Supongamos ahora que se arranca una segunda instancia del mismo proceso.Entonces el VMM pagina en el espacio de direcciones del nuevo proceso el fichero y las DLL, pero novuelve a asignar pginas fsicas, sino que ambas instancias comparten todo, almenos en principio. La ventaja de esto es ahorrar memoria, pero el inconvenientems claro es que si uno de los procesos modificara, por ejemplo, algunavariable global de su segmento de datos, el otro la tendra igualmentemodificada. Esto ocurre evidentemente tambin l la pila e incluso en el mismocdigo (por ejemplo al ejecutar un depurador sobre una de las instancias parameter puntos de ruptura, se modificara el cdigo, lo cual implicara que enla otra tambin). Para solucionar el problema, Windows NT (y tambin UNIX) tiene una propiedaddenominada "copiar antes de escribir". El VMM intercepta cualquierinstruccin de escritura en el archivo mapeado en memoria por parte de lasinstancias. Cuando ocurre, asigna una o varias pginas fsicas para lainstancia escritora, y copia los contenidos de las pginas originales en lasnuevas. A partir de ahora, esa instancia posee su propia regin del archivopara modificar a su antojo. Anlogamente para datos y pila. UNIX tambin trabaja as, aunque duplica las zonas de datos y pila pordefecto, de forma que mltiples instancias comparten, en principio, slo el cdigo.

Con respecto a la tabla de activacin imagen, decir que el VMM asigna lasDLL por defecto en direcciones fijas dentro del espacio de direcciones delproceso. As, mltiples instancias del mismo pueden compartir la misma tabla.No obstante, un proceso puede especificar la direccin base de cada DLL; en esecaso, el proceso tendra su propia tabla en memoria, con lo que resulta mseficiente que todos los procesos tengan las DLL asignadas en las mismasdirecciones. Desde el punto de vista del programador, se pueden asignar en memoriaarchivos de hasta 264 bytes usando vistas del archivo. El archivo se abre con CreateFile. Los primero es crear un objeto de asignacinde archivo para l, con la funcin CreateFileMapping indicando el tamao realdel archivo. Despus podemos definir diferentes vistas, con CreateViewOfFile.La vista se abandona con UnmapViewOfFile (y fueza al VMM a escribir lasmodificaciones en disco). Los archivos asignados en memoria son el nico mecanismo de comparticin dedatos entre procesos. Existe un archivo que crea el objeto de asignacin, y elresto de los procesos usarn el mismo objeto referenciado por la funcinOpenFileMapping. Si como descriptor de archivo se pasa a las funciones0xFFFFFFFF, entonces el VMM usar el archivo de paginacin como medio decomparticin de datos. En una red no es posible usar este mecanismo de comparticin de datos, puesel SO no garantiza la coherencia de los mismos. Por ejemplo, una CPU en unordenador podra modificar el archivo en disco y otra en otro distinto tenerloen memoria, con lo cual no se percatara de la actualizacin. Uso de Memoria Virtual por parte del Programador Vamos a ofrecer unas pinceladas sobre cmo el programador puede hacer usoexplcito del mecanismo de la memoria virtual, y as hacer aplicaciones mseficientes. Se trata sin duda de una forma elegante de programar, ya que permitesituar objetos de grandes dimensiones en el espacio de direcciones del proceso,cuyo tamao real se desconoce al tiempo de compilacin. Por ejemplo, una hojade clculo. Consiste en dos etapas: la reserva y la asignacin. La reserva no es ms que indicar al SO que una regin del espacio dedirecciones del proceso se va a destinar a un determinado objeto u objetos. Portanto no hay ninguna correspondencia con memoria fsica. El VMM toma nota en unVAD (Virtual Address Descriptor) de la direccin de inicio, nmero de bytesreservados, y proteccin de la zona (en efecto, las pginas pueden tenerpermisos de lectura, lectura/escritura, o ninguno). Si el proceso accede a unade estas direcciones, se elevar una excepcin. La reserva se hace siempre portrozos de 64 Kb. La asignacin consiste en hacer corresponder toda o parte de la memoriaante reservada con s memoria fsica. No obstante, el VMM no va a asignar memoriafsica inmediatamente, sino que simplemente actualizar el VAD para permitirque esa memoria sea ahora accesible, y se asegurar que en el archivo depaginacin haya espacio suficiente. Cuando el proceso haga un acceso, seproducir un fallo de pgina, y es en ese momento cuando el VMM asignar pginasfsicas (para la pgina que produzca el fallo y las vecinas) y actualizar laTIP del proceso. El problema de usar memoria virtual explcitamente es que el programadordebe llevar una lista de la memoria que ha asignado de entre la que hareservado. Otra solucin es instalar un manejador de excepciones, de manera queal acceder a una direccin reservada pero no asignada se eleve una excepcin.El manejador de esa excepcin har la asignacin y se continuar la ejecucin. Para reservar memoria se llama a la funcin VirtualAlloc pasndole elindicador MEM_RESERVE, y para asignar, pasndole MEM_COMMIT. La memoria reservada o asignada se puede liberar con VirtualFree, peroentonces ha de liberarse por completo.

Con VirtualLock indicamos al VMM que no descargue una determinada pgina adisco cuando el proceso est ejecutndose (aunque cuando no se ejecuteperdamos el control). Por ltimo sealar que existen funciones del API Win32 que permitenverificar si una direccin virtual tiene correspondencia fsica o no. Bloques (heaps) Los bloques de memoria son muy tiles cuando el programador no necesita usarmemoria virtual explcitamente. Podemos tener estructuras de datos distintas enbloques distintos de memoria, de manera que un fallo en la manipulacin deestructuras de un tipo no repercuta en las dems. Adems, de este modo se gestionara ms eficientemente la memoria, ya queal borrar estructuras y escribir otras no se provocara fragmentacin internadentro del bloque (al ser todas las de un tipo del mismo tamao). Una ltimarazn sera l poder minimizar los fallos de pgina. Estructuras en un mismobloque son probables que compartan la misma pgina, luego podramos acceder atodas las de un mismo bloque con slo un fallo de pgina.

6. Sistema De Archivos Windows NT soporta cuatro tipos de sistemas de ficheros (SF)disintos, y puede trabajar con los cuatro a la vez (un disco con variasparticiones, en cada una un SF distinto). Son los siguientes: Sistema de Archivos FAT HPFS NTFS CDFS Sistemas Operativos Soportados DOS, Windows NT, y OS/2 OS/2 y Windows NT Windows NT Windows NT

NTFS (New-Technology File System): Es el sistema de ficherosnativo de Windows-NT. Como caractersticas podemos sealar: y y y y y y Permite nombres de archivo de hasta 255 caracteres, sensibles al tipo de letra. Permite la gestin de medios de almacenamiento extraordinariamente grandes. Incorpora mecanismos para garantizar la seguridad. Soporta el concepto de enlace (por compatibilidad con el estndar POSIX). Es capaz de recomponerse rpidamente despus de una cada del sistema. Soporta el estndar Unicode.

El que usa MS-DOS y Windows 16 bits. Es el SF ms pobre, yes se mantiene para dar soporte a las aplicaciones DOS. HPFS (High-Performance File System): Es el que usa el sistema operativo OS/2.Se ha incluido para dar soporte a las aplicaciones OS/2 y complementar as alsubsistema del mismo nombre. No es capaz de recomponerse del todo bien despusde una cada del sistema ni de asegurar la no corrupcin de los datos. CDFS (CD-ROM File System): Es un SF que Microsoft ha desarrolladoexclusivamente para montarse sobre los CD-ROM. Vamos a centrarnos en el ms importante de los cuatro: NTFS. Este sistema deficheros lleva incorporados muchos conceptos de teora de bases de datosrelacionales.

Proporciona la seguridad, recuperacin y tolerancia a fallos en base a laredundancia de datos. De hecho, implementa los cinco primeros niveles del pseudo-estndar RAID. RAIDsignifica Redundant Arrays of Inexpensive Disks, algo as como "vectoresredundantes de discos baratos". Actualmente, el coste de losalmacenamientos masivos o secundarios es nfimo, y ya se pueden encontrardiscos de varios Gb por menos de S/.500.00. A eso se refieren, a mi entender, las siglas. RAID es una "norma"de facto que se basa fundamentalmente en conseguir la integridad de los datos abase de dividirlos en pedazos y repartir los pedazos entre varios discos, juntocon informaciones redundantes de comprobacin de errores. Cada nivel ofrece unaestrategia distinta para conseguir la integridad. Los niveles son: Nivel 0: los datos de cada fichero se dividen en porciones, las cuales sereparten en un orden fijo entre los distintos discos con los que cuente elsistema. Realmente aqu no se usan cdigos de comprobacin de errores. y y Nivel 1: de cada disco se realiza una copia o espejo. Es la estrategia que da mayor fiabilidad (pero tambin, evidentemente, la ms costosa). Nivel 2: como el 0, pero un algortimo va construyendo una serie de cdigos correctores de errores. Esos cdigos son igualmente distribuidos entre unos discos destinados especialmente a ese uso. Nivel 3: como el 2, pero no se usan cdigos correctores sino un simple cdigo de paridad, que puede ser guardado en un mismo disco para todos los ficheros. Nivel 4: como el 3, pero dividiendo los ficheros en segmentos de datos ms grandes. Nivel 5: es el nivel ms usual; es igual que el4, pero no usa un disco separado para almacenar los cdigos de paridad, sino que divide igualmente esos cdigos y los distribuye por los disco, intentando que no coincidan en la misma zona de disco datos de un fichero con sus cdigos de paridad correspondientes. Nivel 6: igual que el 5 pero se auxilia de elementos hardware, tales como controladoras de disco especiales, fuentes de alimentacin. En NTFS, al igual que en los SF de UNIX, existe una serie de permisos sobre ficheros y directorios, que son los siguientes: lectura (R), escritura (W), ejecucin (X), borrado (D), cambio de permisos (P) y ser el nuevo propietario (O). Todo fichero y directorio tienen un propietario, que puede conceder permisos sobre ellos. El Administrador del sistema puede tomar la propiedad de cualquier fichero o directorio sobre NTFS, pero no transferirla de nuevo a ningn otro usuario, a diferencia de UNIX, ni siquiera a su dueo original. Sistemas de Archivos FAT Ventajas Poco consumo de sistema. El mejor para discos y/o particiones de menos de 200MB. El mejor para discos y/o particiones entre 200 y 400 MB. Elimina la fragmentacin almacenando en un solo bloque el archivo completo. El mejor para volmenes de 400MB o ms. Recuperable (registro de transacciones), diseado para no ejecutarle utilerias de reparacin. Es posible establecer permisos y registro de auditora sobre archivos y directorios. Desventajas El rendimiento decrece con particiones de ms 200MB. No se pueden aplicar permisos sobre archivos y directorios. No es eficiente para menos de 200MB.No soporta hot fixing. No se pueden aplicar permisos sobre archivos y directorios. No recomendable para volmenes de menos de 400MB. Consume de 1 a 5 MB de acuerdo al tamao de la particin.

y y y

HPFS

NTFS

Ventajas y Desventajas de los Sistemas de Archivos A continuacin vamos a comentar las llamadas al sistema msusuales para crear ficheros, leer de ellos, escribir en ellos, etc. Creacin/Apertura de Ficheros Para crear/abrir un fichero se usa la llamada al sistema HANDLE CreateFile (LPTSTR lpszName, DWORD fdwAccess, DWORD fdwShareNode,LPSECURITY_ATTRIBUTES lpsa, DWORD fdwCreate, DWORD fdwAttrsAndFlags, HANDLEhTemplateFile); lpszName: nombre del archivo a crear o abrir. fdwAccess: especifica el modo de acceso al archivo: lectura (GENERIC_READ),escritura (GENERIC_WRITE), o ambos. fdwShareMode: permisos que tendr la comparticin del archivo a abrir: 0(ningn proceso podr abrirlo hasta que nosotros lo cerremos), FILE_SHARE_READ(otros procesos pueden abrirlo pero slo para leer), FILE_SHARE_WRITE (slopara escribir; no se suele usar), o una combinacin de ambos. lpsa: la tpica estructura de seguridad de todo objeto en Windows NT. Slotendr sentido si el archivo se crea en un SF que soporte seguridad, como NTFS. fdwCreate: una serie de indicadores que especifican una accin: CREATE_NEW: crea un archivo nuevo, y da error si ya existe CREATE_ALWAYS: crea un archio nuevo,y si existe lo machaca OPEN_EXISTING: abre un archivo, y da error si no existe OPEN_ALWAYS: abre un archivo y si no existe lo crea TRUNCATE_EXISTING: si el archivo exisye, lo abre pero truncando su tamao a0 bytes; si no existe, da una error. fdwAttrsAndFlags: sirve para dar atributos al fichero (slo si lo estamoscreando) y activar ciertas banderas. Veamos algunos. Atributos: FILE_ATTRIBUTE_HIDDEN: archivo oculto FILE_ATTRIBUTE_NORMAL: archivo sin atributos especiales FILE_ATTRIBUTE_READONLY: archivo de slo lectura FILE_ATTRIBUTE_SYSTEM: archivo del sistema

FILE_ATTRIBUTE_TEMPORARY: archivo temporal; el Executive intentarmantenerlo en RAM tanto como le sea posible FILE_ATTRIBUTE_ATOMIC_WRITE: para indicar que los datos de este archivo soncrticos; eso har que el Executive aumente la frecuencia con que escribeestos datos de RAM a disco. A propsito de los dos ltimos indicadores, comentar que el Executive noescribe a disco inmediatamente los cambios realizados a un archivo en RAM, puesdegradara las prestaciones del sistema. Usa un mecanismo de escrituradiferida, de manera que se escribe a disco cuando se cierra el archivo, o cuandoel sistema est desocupado, o cuando es necesario hacer swapping. Para losficheros cuyos datos son crticos, necesitamos que las modificaciones seanescritas rpidamente a un soporte no voltil, por si el sistema se cayera. Banderas: FILE_FLAG_NO_BUFFERING: con esta bandera le indicamos al Executive que nogestione buffers de memoria con relacin a la entrada/salida de este archivo,sino que lea y escriba directamente a disco. FILE_FLAG_RANDOM_ACCESS: queremos acceso directo al archivo. FILE_FLAG_SEQUENTIAL_SCAN: acceso secuencial. FILE_FLAG_WRITE_THROUGH: con este indicador, el SO enviar a disco los datosque hayan sido modificados en memoria, pero los mantendr en memoria paraacelerar las lecturas FILE_FLAG_POSIX_SEMANTICS: acceso al archivo segn el estndar POSIX (porejemplo, sensible al tipo de letra) FILE_FLAG_BACKUP_SEMANTICS: cuando un proceso solicita abrir un archivo, elSO normalmente realiza ciertos tests de seguridad para comprobar si el procesotiene o no los permisos necesarios. Con este indicador se anulan ciertos tests,de manera que el SO comprueba si el proceso tiene permiso para acceder alarchivo, y si es as, le permite el acceso pero slo para realizar una copiade seguridad. Aunque tenga permiso de escritura, le ser anulado. FILE_FLAG_OVERLAPPED: los accesos a los archivos suelen hacerse de manera sncrona(el subproceso duerme hasta que se consuma el acceso). Con este indicador sepermite realizar E/S asncrona, con lo que el subproceso seguir ejecutndosey el SO le informar cuando la E/S finalice. hTemplate: el descriptor de un archivo ya abierto; si no es NULL, losatributos y banderas de dicho archivo sern asignados a los de nuestro archivo. La llamada retorna el descriptor al objeto archivo, o -1 si hubo algnerror. Cierre de Ficheros Se usa la misma llamada que para cerrar un descriptor a cualquier objeto. ElSistema Operativo decrementar el contador de uso del archivo, y si es 0 locerrar definitivamente. BOOL CloseHandle (HANDLE hObject); Lectura/escritura a ficheros Windows NT permite que los subprocesos hagan E/S a ficheros de manera sncronao asncrona. EL modo sncrono es el habitual: un subproceso inicia una operacinde E/S sobre un fichero; el Executive lo pondr a dormir hasta que esa E/S decomplete. En cambio, en el modo asncrono, el

subproceso que inicia la operacinpuede seguir ejecutndose, y cuando necesite los datos de la E/S se pondrvoluntariamente a esperar, de manera que si para ese tiempo la E/S se hacompletado, obtendr los resultados inmediatamente. Se usan las mismas llamadas al sistema para ambos tipos de acceso. En dichasllamadas existir un parmetro de entrada (lpOverlapped) que, si es NULL,indicar que la llamada es acceso sncrono; si no, indicar acceso asncrono,dando la direccin de una estructura OVERLAPPED que tiene el siguiente formato: typedef struct _OVERLAPPED{ DWORD Internal; DWORD InternalHigh; DWORD Offset; DWORD OffsetHigh; DWORD hEvent;} OVERLAPPED; Internal: cuando la E/S se completa, el sistema guarda en esa palabra unestado interno. InternalHigh: cuando la E/S se completa, el sistema guarda ah el nmero debytes transferidos. Offset,OffsetHigh: indican la posicin del byte del archivo donde queremoscomenzar el acceso. hEvent: el descriptor (opcional) de un objeto suceso. Vamos a suponer que un subproceso A desea realizar E/S asncrona sobre unfichero, y para ello inicializa el parmetro lpOverlapped de la llamada con ladireccin correspondiente a una estructura OVERLAPPED. Entonces sigue ejecutndose.Cuando al Executive le llega la peticin de E/S sobre el fichero, pone elestado de este objeto a no sealado. Cuando la E/S finaliza, lo pone a sealado(esto ya lo vimos en el captulo de los procesos). En algn momento, Anecesita los datos de la E/S que inici, con lo que se pone a esperar a que elobjeto archivo se ponga a estado sealado (para lo cual usar una llamada tipoWaitFor...Object(s), como ya explicamos). Si, en el momento de hacer la llamadaa E/S, el subproceso A hubiera especificado en hEvent un descriptor a un suceso,el Executive pondra a sealados tanto el objeto fichero como dicho objetosuceso, con lo cual el subproceso A tendra la facilidad de esperar porcualquiera de los dos. La utilidad de esto es en la situacin de que el fichero es compartido, yvarios subprocesos pueden estar haciendo E/S sobre l y, por consiguiente, ponindosea estado sealado/no sealado mltiples veces. Especificando un objeto sucesopropiedad de A, dicho subproceso sabr que cuando el suceso est sealado,seguro que se ha completado su operacin de E/S y no la de otro. Una vez explicados estos matices, pasamos sin ms a describir el perfil delas llamadas de lectura/escritura, que son muy parecidas a las que usa UNIX: BOOL ReadFile (HANDLE hFile, LPVOID lpBuffer, DWORD nNumberOfByt esToRead,LPWORD lpNumberOfBytesRead, LPOVERLAPPED lpOverlapped); hFile: es el descriptor al archivo. nNumberOfBytesToRead: es el nmero de bytes a leer.

nNumberOfBytesRead: es un parmetro de salida que indica el nmero de bytesque se leyeron en realidad. lpOverlapped: elige modo sncrono/asncrono; ya comentado BOOL WriteFile(HANDLE hFile, CONST VOID * lpBuffer, DWORDnNumberOfBytesToWrite, LPDWORD lpNumberOfBytesWritten, LPOVERLAPPEDlpOverlapped); hFile: es el descriptor al archivo. lpBuffer: apunta a un rea de memoria donde se encuentran los datos aescribir. nNumberOfBytesToWrite: nmero de bytes a escribir. nNumberOfBytesWritten: nmero de bytes escritos en realidad. lpOverlapped: elige modo sncrono/asncrono; ya comentado. Nos gustara sealar que en los accesos sncronos existe un puntero delectura/escritura sobre un archivo para cada subproceso que est accediendo almismo. Ese puntero lo asigna el SO en el momento de apertura del archivo cuandoun subproceso lo abre para accesos sncronos (o sea, sin especificar elindicador FILE_FLAG_OVERLAPED). El puntero se modifica al leer y al escribir. Enel caso de que el acceso sncrono sea tambin acceso directo, entonces esposible cambiar el puntero usando la llamada SetFilePointer, que no merece lapena comentar. Ntese que en los accesos asncronos no existe el puntero, por lo que hemosde indicar la direccin de inicio de cada acceso (recordemos que se indica enla estructura OVERLAPPED). Existen unas llamadas de lectura/escritura extendidas (ReadFileEx yWriteFileEx), que son muy tiles a la hora de realizar una E/S asncrona.Permiten que se les pase la direccin de una funcin de forma que, cuando laE/S asncrona se complete, se salte a la ejecucin de esa funcin. Para ello,el subproceso ha de estar esperando por el fin de la E/S con una funcinWaitFor...Object(s) extendida (WaitForSingleObjectEx o WaitForSingleObjectsEx).De hecho, WaitForSingleObject est construida internamente como una llamada aWaitForSingleObjectEx pasndole un parmetro que indica que no queremos usoextendido. Atributos de Ficheros Los atributos que se indican al crear un fichero en el parmetrofwdAttrsAndFlags pueden ser consultados con una llamada a: BOOL GetFileInformationByHandle (HANDLE hFile, LPBY_HANDLE_FILE_INFORMATIONlpFileInformati on); Esta llamada devuelve en la estructura apuntada por lpFileInformation toda lainformacin relativa al fichero cuyo descriptor es hFile. La estructura tienelos siguientes campos:typedef struct _BY_HANDLE_FILE_INFORMATION { DWORD dwFileAtributes; FILETIME ftCreationTime; FILETIME ftLastAccessTime; FILETIME ftLastWriteTime;

DWORD dwVolumeSerialNumber; DWORD nFileSizeHigh; DWORD nFileSizeLow; DWORD nNumberOfLinks; DWORD nFileIndexHigh; DOWRD nFileIndexLow;} BY_HANDLE_FILE_INFORMATION; dwFileAttributes: los atributos del fichero que se pasaron en el parmetrofdwAttrsAndFlags en el momento de su creacin (ver CreateFile) ftCreationTime: fecha de creacin del fichero ftLastAccessTime: fecha del ltimo acceso al fichero ftLastWriteTime: fecha de la ltima escritura al fichero dwVolumeSerialNumber: nmero de serie del volumen donde se encuentra elfichero nFileSizeHigh, nFileSizeLow: 64 bits que indican el tamao del fichero; portanto, Windows NT permite ficheros de hasta 264 bytes nNumberOFLinks: nmero de enlaces del fichero; este parmetro asegura lacompatibilidad con el estndar POSIX. Recordemos que en UNIX cada fichero tieneun nmero de enlaces que indican los distintos nombres que referencian al mismofichero dentro del sistema de ficheros. As se evita la redundancia de datos. nFileIndexHigh, nFileIndexLow: es un identificador nico que el Executiveasocia a un fichero en el momento de que algn subproceso lo abre. Si elsistema se apaga y se enciende, el identificador puede no ser el mismo. Sinembargo, en la misma sesin, procesos distintos leern el mismo identificador.Esto es til para determinar si dos descriptores distintos referencian enrealidad al mismo fichero dentro de un volumen (basta hacer sendas llamadas aGetFileInformationByHandle y ver si el identificador y nmero de volumencoinciden en las estructuras devueltas por cada una). Bloqueo de Archivos Otra llamada muy importante es la que permite el bloqueo de todo o parte deun fichero, de manera que ningn otro subproceso pueda acceder a la reginbloqueada. La llamada para bloquear es: BOOL LockFile (HANDLE hFile, DWORD dwFileOffsetLow, DWORD dwFIleOffsetHigh,DWORD cbLockLow, DWORD cbLockHigh); hFile: descriptor al archivo a bloquear. dwFileOffsetLow, dwFileOffsetHigh: direccin de comienzo de la regin abloquear. cbLockLow, cbLockHigh: tamao de la regin a bloquear. La llamada para desbloquear es:

BOOL UnlockFile (HANDLE hFile, DWORD dwFileOffsetLow, DWORD dwFIleOffsetHigh,DWORD cbUnlockLow, DWORD cbUnlockHigh); Los parmetros son anlogos a los anteriores. Es necesario que unsubproceso desbloquee un rea que previamente bloque antes de que finalice.En caso contrario, estar impidiendo el acceso al fichero a todos los demssubprocesos. Existen versiones extendidas de ambas llamadas (LockFileEx y UnlockFileEx)que permiten establaces bloqueos pero slo de escritura (otros subprocesos podrnleer el rea bloqueada, pero no escribir en ella).

7. Entrada Y Salida A lo largo de los captulos precedentes hemos hablado de losdistintos aspectos de la E/S: gestin de las caches, E/S sncrona y asncrona,drivers de dispositivo, nivel de abstraccin de hardware, ficheros y sistemasde ficheros, por citar algunos. Cuando describamos el administrador de E/S delExecutive, hablamos tambin de que se encargaba de gestionar los mecanismosrelacionados con la red. Me parece conveniente dedicar parte de este ltimo captuloal tema de las comunicaciones en Windows NT, por tratarse de uno de los aspectosdonde ms fuertemente brilla este SO. Windows NT soporta trabajo en red con varios protocolos decomunicaciones. Lo ms importante es que las facilidades de red estnintegradas en el SO, lo que lo distingue de DOS y de la mayora de lasversiones de UNIX, en los que las interfaces con la red eran un aadido al SO,y frecuentemente no se adaptaban del todo bien al mismo. Vamos a describir brevemente qu ocurre en cada uno de losniveles de implementacin del modelo OSI: En el nivel 0 aparece un dispositivo que es la tarjeta deinterfaz a la red (Network Interface Card, NIC). El NIC conecta el bus internode la mquina con la red, sirviendo de interfaz entre el nivel 0 y el 1 (nivelfsico). Es contemplado por el SO como un perifrico ms, controlado a travsde su driver correspondiente. En el nivel 2 (nivel de enlace de datos) aparece un softwarellamado NDIS (Network Device Interface Specification), que es una interfaz entrelos drivers de dispositivo del NIC y los protocolos de transporte. En los niveles 3 (nivel de red) y 4 (nivel de transporte)Windows NT sita el software de los protocolos de transporte. Soporta TCP/IP,NBF, NWLink, DLC y AppleTalk. En el nivel 5 (de sesin) aparecen dos interfaces con losprotocolos de transporte, que son los Windows Sockets (WinSock) y la NetBIOS. Un socket es un mecanismo para establecer una conexin entredos mquinas. Acta como una especie de tubera bidireccional para los datos.Fueron introducidos por primera vez por el UNIX de Berkeley, y Windows NTincorpora una versin especial llamada WinSock. Se utilizan cuando se quiereuna comunicacin a travs del protocolo TPC/IP, IPX/SPX. La interfaz NetBIOS es usada por aquellas aplicaciones quedeseen usar protocolos que se adapten a NetBIOS (como el NBF). Establececonexiones entre distintas mquinas de la red y se encarga de que la transmisinsea fiable una vez establecida la conexin. En la misma capa de sesin estn dos subsistemas integralesgestionados por el administrador de la E/S, denominados el redireccionador y elservidor. El redireccionador es el responsable de enviar peticiones de E/S a lolargo de la red, cuando el fichero o dispositivo solicitados son remotos.

Alservidor le llegan peticiones desde los redireccionadores clientes, y lasgestiona de modo que alcancen su destino. Tanto servidores comoredireccionadores son implementados como driv del ers sistema de ficheros. As,cuando un proceso quiere realizar una E/S, usar las mismas llamadas al sistemapara acceso local o remoto, con lo que no necesita conocer la ubicacin delrecurso (fichero o dispositivo). Pueden existir mltiples parejas deredireccionadores-servidores ejecutndose concurrentemente. En el nivel 6 (capa de presentacin) define como se presentala red a si misma ante la maquina y sus programas y/o aplicaciones. En el nivel 7 (capa de aplicacin) existe un proceso llamadosuministrador por cada redireccionador de la capa 5. Cuando una aplicacin haceuna llamada de E/S, un software llamado enrutador de suministradores (multipleprovider router) determina el suministrador adecuado, y le enva la peticin.El suministrador, a su vez, se la pasar al correspondiente redireccionador.Por ejemplo, el gestor de ficheros (del administrador de E/S) es una aplicacinque usa los servicios de los suministradores. El ltimo tema sobre E/S que vamos a tratar es la gestinde entradas del usuario (mediante teclado o ratn). Cuando el sistema searranca y se crea el proceso subsistema Win32, este proceso crea a su vez unsubproceso llamado subproceso de entrada inicial (Raw Input Thread, RIT), quepor lo general est inactivo. Cada vez que un usuario pulsa una tecla, o mueveo pulsa el ratn, el driver de dispositivo correspondiente aade un sucesohardware a la cola de mensajes del RIT. Entonces, el RIT despierta, examina elmensaje, determina qu tipo de suceso es (WM_KEY*, WM_?BUTTON*, WM_MOUSEMOVE) ya qu subproceso va dirigido, y lo enva a la cola de mensajes de dichosubproceso. Para determinar el subproceso destino, el RIT examina sobre quventana se encontraba el ratn cuando se produjo el suceso, y determina qusubproceso es el propietaro de i ese objeto ventana. Si es una secuencia deteclas, el RIT busca qu subproceso est actualmente en primer plano, y a lle mandar el mensaje. No obstante, el RIT tambin monitoriza qu tipo de entradaes, para que de esta manera se pueda cambiar de contexto (Alt-Tab), o llamar alproceso Administrador de Tareas (si Ctrl-Esc) o visualizar la ventana de dilogode la seguridad (si Ctrl-Alt-Del), etc.

8. Windows Nt 5 En la versin 4.0, Microsoft nos dio una alegra al cambiarla interfaz grfica de Windows NT y sustituirla por Indy, la bonita GUI deWindows 95. Desgraciadamente, NT 4.0 no inclua muchas de las cosas que se venananunciando desde haca tiempo, lo que nos dej un sabor agridulce. En Windows NT 5.0, Microsoft da un paso de gigante,incluyendo las siguientes novedades importantes: y y y Servicios de Directorio al estilo de X.500. Modelo de Objetos de Componentes Distribuidos (DCOM). Sistema de seguridad Kerberos.

Servicios de Directorio: Active Directory NT 5.0 incluye un servicio de directorio llamado Active Directory, basado enDNS (Domain Name Server) y LDAP (Lightweight Directoy Access Protocol). El protocolo DNS da una manera de nombrar mquinas situadasen cualquier parte del planeta y nos permite conocer sus correspondientesdirecciones IP, gracias a que estructura los nombres de las mquinas jerrquicamentepor dominios, y cada dominio conoce potencialmente las direcciones IP de las mquinasque pertenecen a l. Si quiero conocer la direccin de la mquinami_servidor.dom1.edu, preguntar a algn servidor del dominio edu, el cual, ola sabe directamente, o preguntar a algn servidor de dom1, y as.

Con Active Directory vamos a poder localizar cualquier objetollamndolo por su nombre, y acceder a informacin sobre l. Un objeto seralgo heterogneo: una mquina en Internet, un fichero, o un proceso en ejecucin.La informacin sobre ese objeto depender de la clase a la que pertenezcadicho objeto (por tanto ser tambin algo heterogneo). El pegamento queaglutina todo esto se llama Active Directory. La idea no es nueva: el sistema de directorios X-500 permitealgo parecido, pero su complejidad ha hecho que no est muy difundido entre lossistemas operativos. Por ello se desarroll LDAP, una versin simplificada deX-500. En Active Directory va a tener, para cada dominio de nuestraLAN, un nombre de dominio al estilo DNS, y uno o varios servidores de dominio(llamados controladores de dominio). Cuando LDAP sea, al igual que DNS, un estndar,podremos acceder a la base de datos de directorios del servidor Active Directoryusando un cliente UNIX, OS/2 o Macintosh. Tener varios controladores de dominio asociados al mismo dominio interesacuando necesitemos alto rendimiento y baja tasa de errores. Cada controlador vaa almacenar la misma base de datos del dominio del directorio. Active Directoryasegura la integridad de esas BD, de manera que actualizar una implique laactualizacin de cada una de sus copias. Para ello se usa un protocolo decomunicacin entre controladores. La actualizacin de las copias se realiza slosobre los datos modificados. La replicacin se realiza va RPCs cuando estamos en un mbito local, conalta fiabilidad y baja tasa de errores. Para redes a travs de lneas telefnicas,se ha incluido la opcin del correo electrnico como mtodo para que loscontroladores se intercambien informacin de replicacin. En una LAN, la replicacin se produce cada 5 minutos. En una WAN, eladministrador puede ampliar el intervalo para aumentar as las prestaciones. Existen varias alternativas a la hora de elegir una API para los clientesActive Directory, destacando ADSI (Active Directory Sservice Interface). Modelo de Objetos de Componentes Distribuidos (DCOM) DCOM es una extensin natural a COM. COM es un estndar para la comunicacinentre objetos independientemente del lenguaje en el que hayan sido escritos (porejemplo, objetos Java con obejtos C++). El objeto cliente acceder a los mtodosdel objeto servidor a travs de interfaces COM normalizados. Quizs nos suenems el nombre de componentes ActiveX. DCOM extiende lo anterior a un mbito de red; los objetos a comunicarse notienen porqu compartir la misma mquina. Pero esto no es nuevo: lo podamos hacer desde haca tiempo con las RPC. Dehecho, DCOM est construdo sobre las RPC; se trata de un estndar de msalto nivel, con el que podremos escribir aplicaciones distribuidas en un entornode red sin necesidad de conocer todos los entresijos de las RPC, y adems conun enfoque orientado a objetos. De hecho, Microsoft tambin se refiere a DCOMcomo Object RPC (ORPC). DCOM se incluy a Windows NT en su versin 4.0 (tambin sali en 1.996una versin para Windows 95), y actualmente la empresa Sofware AG prev lanzarversiones para Solaris, Linux y otros sistemas a finales de este ao. Con estotenemos que DCOM se est convirtiendo en un estndar importante en laindustria, y se podr utilizar para comunicacin entre objetos corriendo ensistemas operativos distintos. Entonces, qu aporta NT 5.0?

Supongamos que tengo un objeto servidor subsumido en unproceso en mi mquina servidora,y que un cliente quiere acceder a alguno delos mtodos que mi objeto exporta como pblicos. Entonces, el componente DCOMlocaliza l solito al objeto servidor en la red, y le manda una RPC. DCOMencuentra el objeto servidor en la red de dos posibles maneras: En Windows NT 4.0, el cliente ha de conocer dnde est elservidor (lo tiene escrito en el Registro) y se lo dice a DCOM (trivial). En Windows NT 5.0, DCOM usa Active Directory para hallar ladireccin del objeto. sta es la gran ventaja sobre el caso anterior. Ademsde la direccin, puede encontrar ms informacin sobre el objeto servidor. Servicios de Seguridad: el estndar Kerberos En UNIX, de la seguridad se encarga un mdulo llamadoKerberos, desarrollado por el MIT como parte del Proyecto Atenas. Kerberos esactualmente un estndar en la industria, y Microsoft ha implementado la versin5 de la norma en NT 5.0. Como sabemos, NT soporta varios protocolos de seguridad.Existe, no obstante, una interfaz comn que los aglutina (la SSPI, SecurityService Provider Interface), y que proporciona una API comn a los nivelessuperiores. En NT 4.0, la API cubre los protocolos SSL (Secure Sockets Layer,junto con su versin PCT) y NTLM (NT Lan Manager). En NT 5.0, Kerberos se uneal grupo. Los usuarios del nivel de seguridad son otros protocolos, que, usandola API SSPI, acceden a los servicios que ofrece ese nivel, eligiendo elprotocolo que deseen de entre los de la lista. Ejemplos de protocolos clientesson HTTP, LDAP, CIFS (usado por el Sistema de Ficheros Distribuido) y RP C. En entornos de red, las aplicaciones usan primordialmente elprotocolo NTLM, que da autentificacin, integridad de datos y privacidad. Estova a cambiar con la introduccin del estndar Kerberos. Kerberos, al igual que NTLM, proporciona autentificacin,integridad de datos y privacidad. Entre las mejoras que hace a NTLM se encuentrala autentificacin mutua, es decir, que tanto el cliente ha de probar suidentidad al servidor como el servidor al cliente. Cada dominio de la red va atener su servidor Kerberos, que utiliza la base de datos de Active Directory,con lo que se habr de ejecutar sobre la misma mquina que el controlador dedominio. Tambin puede estar replicado dentro del mismo dominio. De manera muy general, podemos decir que un usuario que deseeacced a servicios de una er mquina remota debe primero hacer logon sobre elservidor Kerberos del dominio correspondiente (o sobre alguna de sus copias, sicabe). Si los procesos de identificacin y declaracin deprivilegios son correctos, Kerberos entrega al cliente un "ticket queconcede tickets" llamado TGT (ticket-granting ticket) de acuerdo a losprivilegios del cliente. Usando ese ticket, el cliente podr de nuevo solicitara Kerberos otros tickets para acceder a determinados servidores del dominio.Kerberos examinar el TGT del cliente y el servicio que desea; si el TGT es vlidopara acceder al servicio solicitado, Kerberos entregar al cliente un ticketnuevo para acceder al servicio concreto. El cliente enva ese nuevo ticket a lamquina donde se encuentra el servicio al que desea acceder; el servidorposiblemente lo examinar para comprobar la identificacin del usuario(autentificacin). Los tickets estn todos encriptados. El estndar Kerberos versin 5 no especifica el contenidode los mensajes que se intercambian para identificar al cliente. Por ello, losmensajes de cada implementacin de la norma sern distintos, con lo que podramostener problemas al interactuar con Kerberos de otros sistemas operativos.

9. Bibliografia

Andres s. Tanenbaum. Sistemas operativos modernos. 1992. Jose caete v. Microsoft windows nt. 1997. Al servati. La biblia de intranet. 1997. Erick jimenes m. Sistemas operativos de redes. Www.tecmor.mx/mats-dsc/sor/indice~ 1.html Jose gonzales m. Implementacin de una intranet sobre windows nt. Www.globalnet.com.mx/intranet/index.html Microsoft. Documento NT4UNIX.DOC. www.microsoft.com