UNIDAD II Lab Oratorio Sistema Operativo

Carreras Pregrado Campus Global Universidad del Mar
Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl
UNIDAD II : HISTORIA DE WINDOWS 2000 INTRODUCCIN

Windows 2000, 2003 son sistemas operativos actuales y moderno que se ejecuta en computadoras personales de escritorio y servidores de alto nivel. Varios aspectos de este sistema operativo, comenzando con una breve historia, pasando por su arquitectura. Visualizaremos los procesos, la administracin de la memoria, entrada y salida, el sistema de archivos y la seguridad. El Sistema operativo Windows 2000 o bien otro, viene construido con una serie de capas de software que administra todos los dispositivos y proporciona a los programas de usuario una interfaz ms sencilla para comunicarse con el hardware. La versin de NT que seguira a NT 4.0 se denominara NT 5.0, pero en 1999 Microsoft le cambia el nombre a Windows 2000, sobre todo en un intento por tener un nombre neutral que tanto usuarios de Windows 89 como NT pudieran ver como un evolucin lgica que dar. Con esta estrategia exitosa Microsoft logra un sistema operativo principal basado en tecnologa confiable de 32 bits, pero con la popular interfaz de Windows 98.
Objetivos Generales
- Identificar los cambios generados desde las versiones de Windows 98 y NT - Clasificar las diversas versiones de Windows 2000, de tal forma de utilizar este sistema operativo en diversas implantaciones de proyectos informticos - Reconocer en el sistema operativo los diversos desarrollos que ha generado Microsoft, para la utilizacin de un kit de software, para usuarios avanzados
Amunategui 1838 Recreo Via del Mar Chile. Fono 56(32)2516700 anexo 5274 e-mail:victor.cardenas@udelmar.cl
2.1 HISTORIA DE WINDOWS 2000 Los sistemas operativos de Microsoft para las PCs de escritorio y porttiles pueden dividirse en tres familias: MS-DOS, Windows para consumidor (Windows 95/98/Me) y Windows NT. 2.1.1 Ms-Dos En 1981 IBM, que entonces era la compaa de computadoras ms grande y poderosa del mundo, produjo la PC de IBM basada en el 8088. La PC vena equipada con un sistema operativo en modo real de 16 bits, monousuario, manejado mediante lnea de comandos, llamado MS-DOS 1.0. Este sistema operativo haba sido proporcionado por Microsoft, una pequea compaa naciente, a la que en ese tiempo se conoca principalmente por su intrprete de BASIC que se usaba en sistemas 8080 y Z-80. El sistema operativo consista en 8 KG de cdigo residente en memoria y segua de cerca el modelo de CP/M, un diminuto sistema operativo para las CPUs 8080 y Z-80 de 8 bits. Dos aos despus sali a la luz un sistema operativo de 24 KB, mucho ms potente, llamado MS-DOS 2.0. Este sistema inclua un procesador de lnea de comandos (shell) con varias caractersticas tomadas de UNIX. Cuando Intel sac el chip 286, IBM construy una nueva computadora en torno a l, llamada PC/AT que sali al mercado en 1986. AT eran las siglas en ingls de Tecnologa Avanzada, porque el 286 operaba a la entonces impresionante velocidad de 8 MHz y poda direccionar con gran dificultadlos 16 MB de RAM. En la prctica, la mayora de los sistemas tena cuando ms 1 o 2 MB, por lo costoso de tanta memoria. La PC/T vena equipada con MS-DOS 3.0 de Microsoft, que ya ocupaba 36 KB. Al paso de los aos, MSDOS sigui adquiriendo nuevas funciones, pero segua siendo un sistema orientado a la lnea de comandos. 2.1.2 Windows 95/98/Me Inspirado por la interfaz de usuario de la Apple Lisa (la precursora de la Apple Macintosh), Microsoft decidi dar a MS-DOS una interfaz grfica del usuario (shell) a la que llam Windows. Windows 1.0, que sali al mercado en 1985, no era muy bueno. Windows 2.0, diseado para la PC/AT y distribuido en 1987, no era mucho mejor. Por ltimo, Windows 3.0 para CPU 386 (liberado en 1990), y sobre todo sus sucesores 3.1 y 3.11, tuvieron un enorme xito comercial. Ninguna de estas versiones tempranas de Windows era un verdadero sistema operativo, sino ms bien una interfaz grfica de usuario colocada encima de MS-DOS, el cual segua al mando de la mquina y del sistema de archivos. Todos los programas se ejecutaban en el mismo espacio de direcciones y un error de programacin en cualquiera de ellos poda paralizar el sistema.
Windows 95, que sali al mercado en agosto de 1995, no elimin por completo MSDOS, aunque s transfiri casi todas las funciones de la parte MS-DOS, a la parte Windows. Juntos, Windows 95 y el nuevo MS-DOS 7.0 contenan casi todas las funciones de un sistema operativo completo, incluidas memoria virtual, administracin de procesos y multiprogramacin. Sin embargo, Windows 95 no era un programa de 32 bits cabal. Contena grandes fragmentos de cdigo ensamblador antiguo de 16 bits (adems de algo de cdigo de 32 bits) y segua usando el sistema de archivos de MS- DOS, con casi todas sus limitaciones. El nico cambio importante al sistema de archivos fue la adicin de nombres de archivo largos en lugar de los nombres de 8 + 3 caracteres que se permitan en MS-DOS. Incluso en Windows 98, liberado en junio de 1998, MS-DOS segua presente (ahora en la versin 7.1) y ejecutando cdigo de 16 bits. Aunque haba migrado an ms funcionalidad de la parte MS-DOS a la parte Windows, y ahora se usaba de forma estndar una organizacin de disco apropiada para discos mayores, en su interior Windows 98 no era muy diferente de Windows 95. La diferencia principal radicaba en la interfaz de usuario, que integraba en forma ms estrecha el escritorio e Internet. Fue precisamente esta integracin lo que atrajo la atencin del Departamento de Justicia de Estados Unidos, que emprendi una accin legal en contra de Microsoft alegando que era un monopolio ilegal, acusacin que Microsoft rechaz con vigor. En abril de 2000, una corte federal de Estados Unidos determin que el gobierno tena razn. Adems de contener un gran trozo de cdigo ensamblador antiguo de 16 bits en el kernel, Windows 98 tena otros dos problemas graves. Primero, aunque era un sistema de multiprogramacin, el kernel en s no era reentrante. Si un proceso estaba ocupado manipulando alguna estructura de datos del kernel y derepente se agotaba su cuanto y otro proceso comenzaba a ejecutarse, el nuevo proceso poda encontrar la estructura de datos en un estado inconsistente. Para evitar este tipo de problemas, despus de entrar en el kernel, un proceso por lo general obtena primero un mutex gigante que cubra todo el sistema, antes de ponerse a hacer algo. Aunque este enfoque eliminaba las posibles inconsistencias, tambin eliminaba gran parte de la utilidad de la multiprogramacin, porque los procesos a menudo se vean obligados a esperar hasta que procesos no relacionados salieran del kernel, para poder entrar en l. Segundo, cada proceso de Windows 98 tena un espacio de direcciones virtual de 4 GB. De esto, 2 GB eran completamente privados para el proceso, pero el siguiente 1 GB se comparta (de forma escribible) con todos los dems proceso del sistema. El 1 MB de hasta abajo tambin se comparta entre todos los procesos, para que todos pudieran tener acceso a los vectores de interrupcin de MS-DOS. Casi todas las aplicaciones de Windows 98 utilizaban en forma intensiva esta rea compartida, por lo que un error en un programa poda borrar estructuras de datos clave empleadas por un proceso no relacionado y hacer que todos fallaran. Peor an, el ltimo 1 GB se comparta (de forma escribible) con kernel y contena algunas estructuras de datos del kernel en espacio de usuario no era
factible, porque era indispensable para que los anteriores programas de MS-DOS funcionaran bajo Windows 98. En el ao del milenio, 2000, Microsoft sac una modernizacin menor de Windows 98 llamada Windows Me (Windows Edicin del Milenio). Aunque en ella se corregan algunos errores y se aadan unas cuantas funciones,. En los aspectos internos era en esencia igual a Windows 987. Las nuevas funciones incluan mejores formas de catalogar y compartir imgenes, msica, pelculas, ms soporte para redes caseras y juegos multiusuario, y ms funciones relacionadas con Internet, como manejo de mensajes instantneos y conexiones de banda ancha (mdems de cable y ADSL). Una nueva funcin que result interesante fue la capacidad de restaurar la computadora a sus parmetros anteriores despus de una configuracin errnea. Si un usuario reconfigura el sistema (por ejemplo, cambia la definicin de la pantalla de 640 x 480 a 1024 x 768) y ya no funciona, esto permite revertir el sistema a la ltima configuracin conocida que s funcionaba 2.1.3 Windows NT A fines de los aos ochenta, Microsoft s dio cuenta que construir un sistema operativo moderno de 32 bits encima del MS-DOS de 16 bits, con todos sus defectos, quiz no era la mejor estrategia. La compaa reclut a David Cutler, uno de los diseadores clave del sistema operativo VMS de DEC, para que encabezara un equipo que produjera un sistema operativo de 32 bits completamente nuevo y compatible con Windows. Este nuevo sistema, despus llamado Windos NT (Windows Nueva Tecnologa), estaba pensado para aplicaciones de negocios de misin crtica y tambin para usuarios caseros. En ese entonces los mainframes todava dominaban el mundo (de los negocios), as que disear un sistema operativo bajo el supuesto de que las compaas usaran computadoras personales para hacer algo importante era una meta visionaria. Sin embargo, el tiempo ha demostrado que era la correcta. Funciones como seguridad y alta confiabilidad, ausentes en las versiones de Windows basadas en MS- DOS, eran prioridades en Windows NT. Los antecedentes de Cutler con VMS asoman con claridad en varios lugares, y la similitud entre el diseo de NT y el de VMS va ms all de la superficie. El proyecto tuvo xito y la primera versin, llamada Windows NT 3.1, sali altercado en 19993. Se escogi este nmero para la versin inicial con objeto de que coincidiera con el de sistema Windows 3.1 de 16 bits que entonces gozaba de gran popularidad. Microsoft confiaba en que NT pronto reemplazara a Windows 3.1 porque en el aspecto tcnico era un sistema muy superior. Para su gran sorpresa, casi todos los usuarios prefirieron quedarse con el viejo sistema de 16 bits que conocan, en vez de cambiar a un sistema de 32 bits que no conocan, aunque fuera mucho mejor. Adems, NT requera mucha ms memoria que Windows 3.1 y no haban programas de 32 bits que pudiera ejecutar, as que, para qu tomarse la
molestia? Esta incapacidad de NT 3.1 para apoderarse de un segmento importante del mercado fue la razn por la que Microsoft decidi construir una versin de Windows 3.1 con algunos aspectos de 32 bits: Windows 95. Luego, la persistente resistencia de los usuarios ante NT hizo que Microsoft produjera Windows 98 y por ltimo Windows Me, afirmando en cada aso que ahora s ya no habra ms versiones de los sistemas basados en MS-DOS. A pesar de que casi todos los consumidores y la mayora de las empresas se negaron a cambiar a NT 3.1 para sus sistemas de escritorio, s surgi un pequeo grupo de seguidores en el mercado de los servidores. En 1994 y 1995 aparecieron unas cuantas versiones 3.x nuevas con pequeos cambios, las cuales comenzaron a adquirir tambin seguidores entre los usuarios de sistemas de escritorio. La primera modernizacin importante de NT lleg con NT 4.0 en 1996. Este sistema tena toda la potencia, seguridad y confiabilidad del nuevo sistema operativo, pero tambin presentaba la misma interfaz de usuario que el para entonces muy popular Windows 95. Esta compatibilidad hizo que para los usuarios fuera mucho ms fcil migrar de Windows 95 a NT, y muchos de ellos lo hicieron. En la figura 2 1 se resumen algunas de las diferencias entre Windows 95/98 y Windows NT. Desde el principio, NT se dise de modo que fuera portable, as que se escribi casi por completo en C, consol un poco de cdigo ensamblador para funciones de bajo nivel, como el manejo de interrupciones. La versin inicial abarcaba 3.1 millones de lneas en C para el sistema operativo, las bibliotecas y los subsistemas de entorno. Cuando sali NT 4.0, el cdigo haba crecido a 16 millones de lneas, en su mayor parte todava en C, pero con una pequea porcin de C++ en la parte de interfaz de usuario. A estas alturas el sistema ya era muy portable y haba versiones para Pentium, Alpha. MIPS y PowerPC, entre otras CPUs. Algunas de estas versiones ya han desaparecido. La historia del desarrollo de NT se relata en el libro Showstopper (Zachary, 1994), el cual tambin revela mucho acerca de los principales protagonistas. 2.1.4 Windows 2000 La versin de NT que seguira a NT 4.0 iba a llamarse NT 5.0, pero en 1999 Microsoft le cambi el nombre a Windows 2000, sobre todo en un intento por tener un nombre neutral que tanto los usuarios de Windows 98 como los de NT pudieran ver como un siguiente paso lgico que dar. Si tal estrategia tiene xito, Microsoft tendr un solo sistema operativo principal basado tecnologa confiable de 32 bits pero con la popular interfaz de usuario de Windows 98. Puesto que Windows 000 en realidad es NT 5-0, hereda muchas propiedades de NT
4.0. Se trata de un verdadero sistema multiprogramado de 32 bits (que pronto ser de 64 bits) con procesos protegidos de manera individual. Cada proceso tiene un espacio de direcciones virtual privado de 32 bits (pronto de 64 bits), paginado por demanda. El sistema operativo se ejecuta en modo de kernel, mientras que los procesos de usuario lo hacen en modo de usuario, lo que ofrece proteccin completa (eliminando por completo los defectos de proteccin de Windows 98). Los proceso pueden tener uno o ms subprocesos, que el sistema operativo puede ver y calendarizar. Se cuenta con seguridad C2 del Departamento de Defensa para todos los archivos, directorios, procesos, procesos y dems objetos que pueden compartirse (al menos, si se retira el disco flexible y se desconecta la red). Por ltimo, este sistema operativo tiene soporte completo para ejecutarse en multiprocesadores simtricos con hasta 32 procesadores. El hecho de que Windows 2000 sea en realidad NT 5.0 es evidente en muchos aspectos. Por ejemplo, el directorio del sistema se llama \winnt y el binario del sistema operativo (en \winnt\system32) se llama ntoskrnl.exe. Si se hace clic con el botn derecho del ratn en este archivo para examinar sus propiedades, puede verse que su nmero de versin es 5.xxx.yyy.zzz, donde el 5 representa NT 5, xxx es el nmero de versin, yyy es el nmero de compilacin, y zzz es la variante menor. Adems, muchos de los archivos de \winnt y sus subdirectorios tienen nt en su nombre, como ntvdm, el emulador virtual de MS-DOS de NT. Windows 2000 es ms que el NT 4.0 mejorado con la interfaz del usuario de Windows 98. Por principio de cuentas, contiene muchas otras funciones que anteriormente se hallaban slo en Windows 98. stas incluyen soporte completo para dispositivos Plug and Play, bus USB, IEEE 1394 (FireWire), IrDA (el enlace infrarrojo entre computadoras porttiles e impresoras) y administracin de energa, entre otras cosas. Adems, se han agregado varias funciones ms que no estn presentes en ningn otro sistema operativo de Microsoft, como un servicio de directorios de directorio activo, seguridad de Kerberos, manejo de tarjetas inteligentes, herramientas para vigilar el desempeo, mejor integracin de laptops con computadoras de escritorios, una infraestructura para administracin del sistema y objetos de trabajo, Adems, el principal sistema de archivos, NTFS, se extendi para manejar archivos cifrados, cuotas, archivos enlazados, volmenes montados e indizacin de contenido, por ejemplo. Otra novedad de NTFS es el almacn de instancia nica, que es una especie de enlace de copiar al escribir con el que dos usuarios pueden compartir un archivo enlazado hasta que uno de ellos escribe en l, momento en el cual se crea una copia en forma automtica. La otra mejora importante es la internacionalizacin. NT 4.0 vena en versiones distintas para diversos idiomas, con las cadenas de texto incorporadas al cdigo. La instalacin de un paquete de software en ingls en una computadora holandesa a menudo haca que partes del sistema operativo dejaran de usar holands y comenzaran a usa ingls, porque se sobrescriban ciertos archivos que contenan cdigo y cadenas de texto. Este problema se ha eliminado, Windows 2000 tiene un solo binario que se ejecuta en cualquier lugar de mundo. Una instalacin, o incluso un usuario individual, puede
escoger el idioma que usar en el momento de la ejecucin, pues todas las opciones de men, cadenas de dilogo, informes de error y otras cadenas de texto se han sacado del sistema operativo y se han puesto en directorios distinto, uno por cada idioma instalado. Al igual que todas las versiones anteriores de NT, Windows 2000 utiliza Unicode en todo el sistema para poder manejar idiomas que no usan el alfabeto latino, como ruso, griego, hebreo y japons. Algo que no tiene Windows 2000 en MS-DOS. Simplemente no est presente en ninguna forma (como no estaba en NT). Tiene una interfaz de lnea de comandos, pero se trata de un nuevo programa de 32 bits que incluye la antigua funcionalidad de MS-DOS, adems de un buen nmero de funciones nuevas. A pesar de las muchas caractersticas de portabilidad en cuanto a cdigo, hardware, idioma, etctera, en un sentido Windows 2000 es menos portable que NT4.0: slo se ejecuta en dos plataformas: Pentium e Intel IA-64. En un principio NT reconoca otras plataformas, incluidas PowerPC, MIPS y Alpha, pero con los aos Microsoft las ha ido desechando por motivos comerciales. Al igual que versiones anteriores de NT, Windows 2000 se vende en varios niveles de producto, que por ahora son Professional, Servidor, Servidor avanzado y Servidor avanzado y Servidor de centro de datos. Sin embargo, las diferencias entre todas estas versiones son menores, y en todas se usa el mismo binario ejecutable. Cuando se instala el sistema, el tipo de producto se registra en una base de datos interna (el Registro). Durante el arranque, el sistema operativo consulta el Registro para ver de qu versin se trata. Las diferencias se presentan en la figura 2-2-
Figura 1.2 Las diferentes versiones de Windows 2000. Como se muestra en la figura, las diferencias incluyen el mximo de memoria que puede manejarse, el nmero mximo de procesadores (en una configuracin multiprocesador) y el nmero mximo de clientes que es posible atender. El tamao de clster se refiere a la capacidad de Windows 2000 para hacer que dos o cuatro mquinas parezcan un solo servidor desde la perspectiva del mundo exterior, funcin til en el caso de servidores Web, por ejemplo. Por ltimo, los parmetros predeterminados se han afinado de diferente manera en la versin Profesional, para dar preferencia a los programas
interactivos por sobre los trabajos por lotes, aunque es fcil modificar los parmetros si se desea. Una ltima diferencia es que los servidores incluyen un poco de software adicional y el Servidor de centro de datos cuenta con herramientas adicionales para administrar trabajos grandes. El motivo para tener mltiples versiones es simple mercadotecnia: esto permite a Microsoft cobrar a las grandes empresas ms de lo que cobra a individuos por lo que en esencia es el mismo producto. Sin embargo, esta idea no es nueva, y Microsoft no es la nica empresa que la usa. Durante aos, las aerolneas han estado cobrando a los viajeros de negocios mucho ms, no slo por Clase de Negocios, sino tambin por Clase Rebao si quieren el lujo de comprar un pasaje un da antes del vuelo, en vez de un mes antes. Tcnicamente, la forma en que se mantienen las diferencias diversin es que en unos cuantos puntos del cdigo se leen dos variables del Registro, ProductType y ProductSuite. Dependiendo de sus valores, se ejecuta cdigo un poco diferente, La modificacin de estas variables constituye una violacin de la licencia. Adems, el sistema detecta cualquier intento de alteracin y lo registra de forma indeleble para que pueda comprobarse despus. Adems del sistema operativo bsico, Microsoft ha desarrollado varios kits de herramientas para usuarios avanzados, entre los que se incluyen las herramientas de apoyo, el Kit para Desarrollo de Software (SDK), el Kit para Desarrollo de controladores de dispositivo (DDK) y el Kit de Recursos, los cuales contienen un gran nmero de programas utilitarios y herramientas para afinar y supervisar el sistema. Las herramientas de apoyo estn en el CD-ROOM de Windows 2000 en el directorio \support\tools. El procedimiento de instalacin estndar no las instala, pero en ese directorio hay un archivo setup.exe que lo hace. Los desarrolladores pueden conseguir el SDK y el DDK en msdn.microsoft.com. El Kit de Recursos es un producto de Microsoft que se vende en una caja. Tambin hay diversas herramientas de tercero para nhusmear en el interior de Windows 2000, entre ellas un bonito conjunto de herramientas que puede obtenerse sin costo en el sitio Web www.sysinternals.com. Algunas de estas herramientas proporcionan incluso ms informacin que las herramientas de Microsoft correspondientes. Windows 2000 en un sistema inmensamente complejo, que ahora comprende ms de 29 millones de lneas de cdigo C. Si se imprimieran 50 lneas por pgina y 1000 pginas por volumen encuadernado, el cdigo completo ocupara 580 volmenes. Esta obra llenara 25 metros lineales de espacio en anaquel (en la versin rstica). Si se acomodara en libreros de 1 m de anchura y seis entrepaos por librero, el conjunto cubrira una pared de 4 m de anchura. Nada ms por diversin, en la figura 2-3 se presenta una comparacin del tamao del cdigo de unos cuantos sistemas operativos. Sin embargo, esta tabla debe leerse
con mucha cautela porque los sistemas presentan grandes diferencias en cuanto a lo que constituye el sistema operativo. Por ejemplo, en Windows todo el sistema de ventanas y la GUI son parte del kernel, pero no en las versiones de UNIK, donde tan slo es un proceso de usuario. Si contamos X Windows habra que aadir otro milln y medio de lneas de cdigo a todas las versiones de UNIX, y eso sin contar el cdigo de GUI (Motif, GNOME, etctera), que tampoco forma parte del sistema operativo en el mundo UNIX. Adems, algunos sistemas incluyen cdigo para mltiples arquitecturas (por ejemplo, cinco en 4.4BSD y nueve en Linux), y cada arquit3ectura aade de 10,000 a 50,000 lneas de cdigo. El motivo por el que FreeBSD 1.0 slo tiene 235,000 lneas de cdigo mientras que 4BSD lneas de cdigo,. El motivo por el que FreeBSD 1.0 slo tiene 235,000 lneas de cdigo mientras que 4BSD Lite, del cual se deriva, tiene 743,000, es que en FreeBSD se elimin el soporte para todas las arquitecturas obsoletas (como la VAX). Asimismo, el nmero de sistemas de archivos, controladores de dispositivos y bibliotecas que se proporciona vara de manera considerable de un sistema a otro. Adems, Windows contiene grandes cantidades de cdigo de prueba de UNIX no contiene, as como ciertos programas utilitarios y soporte para numerosos idiomas adems del ingls. Por ltimo, las mediciones fueron hechas por diferentes personas, lo cual presenta una variacin considerable (por ejemplo, se contaron los archivos make, de encabezado y de configuracin, as como la documentacin, y qu tanto haba de esto?. No es como comparar manzanas y naranjas; es como comparar manzanas y telfonos. Sin embargo, todos los recuentos dentro de una familia dada provinieron de la misma fuente, por lo que son un poco ms significativos. A pesar de todas estas reservas, pueden sacarse dos conclusiones obvias: 1.- La inflacin de los sistemas parece tan inevitable como la muerte y los impuestos. 2.- Windows es mucho ms grande que UNIX. La cuestin de mientras menos, mejor, o mientras ms, mejor, es tema de acaloradas controversias. El argumento a favor de los primero es que un tamao pequeo y una mentalidad gil producen, un sistema manejable y confiable que pueden entender los usuarios. El argumento a favor de lo segundo es que muchos usuarios quieren una abundancia de funciones. En todo caso, tambin deber quedar claro que cualquier estudiante que piense escribir un sistema operativo de vanguardia con todas las de la ley, comenzando desde cero, enfrente una tarea de dimensiones descomunales. Aunque Windows 2000 ya es el campen mundial de los pesos pesados desde el punto de vista de la mesa bruta, sigue creciendo conforme se corrigen errores de programacin y reaaden nuevas funciones. Vale la pena describir la forma en que Microsoft administra su labor de desarrollo. Ciertos de programadores trabajan en
diversos aspectos de Windows 2000 todo el da. Cada vez que se termina un fragmento de cdigo, el programador lo presenta en forma electrnica al equipo de compilacin. A las 6 p.m. de cada da se cierra la puerta y el sistema se reconstruye (es decir, se recompila y se enlaza). Cada compilacin recibe un nmero consecutivo nico, que puede verse examinando el nmero de versin de ntoskrnl.exe (la primera versin pblica de Windows 2000 fue la compilacin 2195). Ao 1976 1979 1980 1982 1984 1986 1987 1989 1991 1993 1994 1996 1997 1999 2000 Free 1.4M 4.0 AT&T V6 9K V7 21K Sys III 58K 4.2 98 K 4.3 179 K SVR3 92K SVR4 280K Free 235K 4.4 743K 1.0 Lite 2.0 62K 2.2 1M 5.8 2.0M 2000 29M 1.0 165K 2.0 470K 5.6 1.4M 1.0 13K 0.01 10K 5.3 850 K 3.1 6M 3.5 10M 4.0 16M BSD 4.1 38K MINIX Linux Solaris Win Nt
Figura 2.3 Comparacin del tamao de algunos sistemas operativos. El primer elemento en cada celda es la versin; el segundo es el tamao medio en lnea de cdigo fuente, donde K = 1000 Y m = 1,000,000. Las comparaciones dentro de una misma columna tienen significado real; las que estn entre filas no lo tienen, como se explica en el texto. El nuevo sistema operativo se distribuye en forma electrnica a miles de mquinas dentro del campus de Microsoft en Redmond, Washington, donde se somete a intensas pruebas de rendimiento durante toda la noche. Al da siguiente, muy temprano, se envan los resultados de todas las pruebas a los grupos pertinentes, para que puedan ver si funciona su nuevo cdigo. Entonces, cada equipo decide en cul cdigo quiere trabajar ese da. Durante el da, los programadores trabajan con su cdigo, y a las seis de la tarde se reinicia el ciclo de compilacin y prueba. 2.2 PROGRAMACION EN WINDOWS 2000
2.2.1 La interfaz de programacin de aplicaciones Win32 Al igual que todos los dems sistemas operativos, Windows 2000 cuenta con un conjunto de llamadas al sistema que puede ejecutar. Sin embargo, Microsoft nunca ha publicado la lista de llamadas al sistema Windows, y adems las cambia de una versin a la siguiente. Ms bien, lo que ha hecho es definir un conjunto de llamadas funciones denominado interfaz de programacin de aplicaciones (API; Application Programming Interface) Win32, que se conoce de manera pblica y est documentado en forma plena. Se trata de procedimientos de biblioteca que efectan llamadas al sistema para realizar el trabajo o, en algunos casos, realizan el trabajo ah mismo, en el espacio de usuarios. Las llamadas de la API Win32 existentes no cambian al cambiar la versin de Windows, aunque con frecuencia se aaden nuevas. Los programas binarios para Intel x86 que se ajustan con exactitud a la API Win32 se ejecutan sin necesidad de modificaciones en todas las versiones de Windows a partir de Windows 95. Como se aprecia en la figura 2-4, se necesita una biblioteca adicional para que Windows 3.x haga corresponder un subconjunto de las llamadas de la API de 32 bits con las del sistema operativo de 16 bits, pero en los dems sistemas no se requiere adaptacin alguna. Cabe sealas que Windows 2000 aade una buena cantidad de funcionalidad nueva a Win32, as que cuenta con llamadas adicionales en la API que no estn incluidas en versiones anteriores de Win32 y que no funcionan en versiones ms antiguan de Windows.
Figura 2.4. La API Win32 permite ejecutar programas en casi todas las versiones de Windows.
La filosofa de la API Win32 es completamente diferente de la filosofa de UNIX. En esta ltima, todas las llamadas al sistema se conocen en forma pblica y constituyen una interfaz mnima: la sola eliminacin de una de ellas reducira la funcionalidad del sistema operativo. La filosofa de Win32 consiste en proporcionar una interfaz exhaustiva, a menudo con dos o tres formas de hacer lo mismo, e incluir muchas funciones (es decir, procedimientos) que a todas luces no son (ni deberan ser) llamadas al sistema, como una llamada de API Win32 crean objetos de kernel de una especie u otra, incluidos archivos, procesos, subprocesos, canalizaciones, etc. Toda llamada que crea un objeto devuelve un resultado llamado identificador (handle) a su invocador. Este identificador puede utilizarse despus para ejecutar operaciones con el objeto. Los identificadores son especficos para el proceso que cre el objeto al que se refiere el identificador; no pueden pasarse en forma directa a otro proceso y usarse ah (as como los descriptores de archivo de UNIX no pueden pasarse a otros procesos y usarse en ellos). No obstante, en ciertas circunstancias es posible copiar un identificador y pasarlo a otros procesos empleando un mecanismo protegido, lo que hace posible tener acceso controlado a objetos que pertenecen a otros procesos. Adems, cada objeto tiene asociado un descriptor de seguridad que indica de forma detallada quin est y quin no est autorizado para realizar algn tipo de operaciones con el objeto. No todas las estructuras de datos creadas por el sistema son objetos, y no todos los objetos son objetos del kernel. Los nicos que son verdaderos objetos de kernel son los que deben nombrarse, protegerse o compartirse de alguna manera. Todo objeto de kernel tiene un tipo definido por el sistema, tiene operaciones bien definidas que se ejecutan con l y ocupa espacio en la memoria del kernel. Aunque los usuarios pueden realizar las operaciones (emitiendo llamadas de Win32), no pueden tener acceso a los datos de manera directa. El sistema operativo en s tambin puede creer y usar objetos, y lo hace en forma intensiva. Casi todos esos objetos se crean con el fin de que un componente del sistema pueda almacenar cierta informacin durante un tiempo considerable o pasar alguna estructura de datos a otro componente. Por ejemplo, cuando se carga un controlador de dispositivo, se crea un objeto para l con sus propiedades y apuntadores a las funciones que contiene. Entonces, se hace referencia al controlador dentro del sistema operativo, utilizando su objeto. A veces se dice que Windows 2000 est orientado a objetos porque la nica forma de manipular objetos es invocando operaciones con sus identificadores o emitiendo llamadas a la API Win32. Por otra parte, el sistema carece de algunas de las propiedades ms bsicas de los sistemas orientados a objetos, como herencia y polimorfismo. Las llamadas de la API Win32 cubren todas las reas concebibles de las que podra ocuparse un sistema operativo, y un buen nmero de reas de las que, en opinin de algunos, no debera ocuparse. Por supuesto, hay llamadas para crear y administrar procesos
y subprocesos. Tambin hay muchas llamadas relacionadas con la comunicacin entre procesos (en realidad, entre subprocesos), como la creacin, destruccin y uso de mutexes, semforos, sucesos y otros objetos de IPC. Aunque gran parte del sistema de administracin de memoria es invisible para el programador (en esencia es paginacin por demanda), s es visible una caracterstica importante: la capacidad de un proceso para establecer la correspondencia entre un archivo y una regin de su memoria virtual. Esto permite al proceso leer y escribir partes del archivo como si fueran palabras de memorias de memoria. Un rea importante para muchos programas es la E/S archivos. Desde la perspectiva Win32, un archivo es slo una secuencia lineal de bytes. Win32 proporciona ms de 60 llamadas para crear y destruir archivos y directorios, abril y cerrar archivos, leer y escribir archivos, solicitar y establecer atributos de archivos, y muchas cosas ms. Otra rea en la que Win32 proporciona llamadas es la seguridad. Cada proceso tiene un ID (identificador) que indica quin es, y cada objeto puede tener una lista de control de acceso que indica con lujo de detalles cules usuario pueden tener acceso a l y qu operaciones pueden efectuar con l. Este mtodo hace posible una seguridad de grano fino en la que puede otorgarse o negarse a personas individuales un acceso especfico a cada objeto. Las llamadas al sistema relacionadas con procesos, subproceso, sincronizacin, administracin de memoria, E/S de archivos y seguridad no son algo nuevo. Otros sistemas operativos tambin las tienen, aunque en general no por centenares, como en Win32. Sin embargo, lo que en realidad distingue a Win32 son los miles y miles de llamadas para la interfaz grfica. Hay llamadas para crear, destruir, administrar y usar ventanas, mens, barras de herramientas, barras de estado, barras redesplazamiento, cuadros de dilogo, iconos y muchos otros elementos que aparecen en la pantalla. Hay llamadas para dibujar formas geomtricas, rellenarlas, administrar las paletas de color que usan, manejar fuentes (tipos de letra) y colocar iconos la pantalla. Por ltimo hay llamadas para manejar el teclado, el ratn y otros dispositivos de entrada, as como audio, impresin y otros dispositivos de salida. En pocas palabras, la API Win32 (sobretodo la parte de la GUI) es inmensa y no podramos comenzar siquiera a describirla con sus pormenores en este captulo, as que ni lo intentaremos. Si est interesado puede consultar uno de los muchos libros sobre Win32 (por ejemplo, Perzold, 1999; Simon, 1997; Rector y Newcomer, 1997). Aunque la API Win32 est disponible en Windows 98 (as como en el sistema operativo para apartaos electrnicos de consumo, Windows CE), no todas las versiones de Windows implementan todas las llamadas, y a veces tambin hay diferencias
menores. Por ejemplo, Windows 98 no tiene seguridad, as que las llamadas de la API relacionadas con seguridad slo devuelven cdigos de error en Windows 98. Adems, los nombres de archivo de Windows 2000 empelan el conjunto de caracteres Unicode, que no se maneja en Windows 98, y los nombres de archivo de Windows 98 no distinguen entre maysculas y minsculas, mientras que en Windows 2000 s (aunque ciertos tipos de bsquedas de nombres de archivo no distinguen entre maysculas y minsculas). Tambin hay diferencias en los parmetros de algunas llamadas a funciones de la API. En Windows 2000, por ejemplo, todas las coordenadas de pantalla dadas en las funciones de grficos son verdaderos nmeros de 32 bits; en Windows 98 slo se usan los 16 bits de orden bajo, porque gran parte del subsistema de grficos sigue siendo cdigo de 16 bits. La existencia de la API Win32 en varios sistemas operativos distintos facilita el traslado de programas entre ellos, pero dado que existen variaciones menores, hay que tener un poco de cuidado para lograr la portabilidad. 2.2.2 El Registro Windows necesita mantenerse al tanto de una gran cantidad de informacin acerca del hardware, el software y los usuarios. En Windows 3.x esta informacin se almacenaba en cientos de archivos .ini (de iniciacin) dispersos por todo el disco. A partir de Windows 95, casi toda la informacin necesario para arrancar y configurar el sistema y adaptarlo al usuario actual se reuni en una gran base de datos central llamada Registro (registry). En esta seccin presentaremos un panorama general de Registro de Windows 2000. Para empezar, vale la pena sealar que si bien muchas partes de Windows 2000 son complicadas y sin orden aparente, el Registro es una de las peores, y la extraa nomenclatura no ayuda en nada. Por fortuna, se han escrito libros enteros para describirlo (Born, 1998; Hipson, 2000, y Ivens, 1998). Habiendo dicho eso, hay que decir que la idea en la que se basa es muy sencilla. El Registro consiste en una coleccin de directorio, cada uno de los cuales contraen subdirectorios o entradas. En este sentido es una especie de sistema de archivos para archivos muy pequeos, que tiene directorio y entradas (los archivos). La confusin principal con el hecho de que Microsoft llama clave a un directorio, cosa que definitivamente no es. Adems, todos los directorios del nivel ms alto comienzan con la cadena HKEY, que significa Identificador de clave. Los subdirectorio suelen tener nombres escogidos con un criterio ms lgico, aunque no siempre es as. En la base de la jerarqua estn las entradas, llamadas valores, que contienen la informacin. Cada valor tiene tres partes: un nombre, un tipo y los datos. El nombre no es ms que una cadena de Unicode, a menudo default (predeterminado) si el directorio slo contiene un valor. El tipo es uno de los 11 tipos estndar. Los ms comunes son cadena Unicode, lista de cadenas Unicode, entero de 32 bits, nmero binario de longitud arbitraria
y enlace simblico a un directorio o entrada en algn otro lugar del Registro. Los nombres simblicos son iguales a los enlaces simblicos que se usan en los sistemas de archivos o a los accesos directos del escritorio de Windows: constituyen un punto de ingreso a otra entrada o directorio. Los enlaces simblicos tambin pueden usarse como claves, lo que implica que algo que parece ser un directorio slo es un apuntador a un directorio distinto. En el nivel ms alto, el Registro de Windows 2000 tiene seis claves, llamadas claves raz, que se enumeran en la figura 2-5. Tambin se muestran ah algunas subclaves (subdirectorios) interesantes. Para ver esa lista en un sistema Windows 2000, puede usar uno de los editores del Registro, regedit o regedt32, que por desgracia exhiben diferente informacin y usan formatos distintos. Con ellos tambin pueden modificarse los valores del registro No se recomienda a los aficionados alterar las claves ni los valores si es que planean volver a arrancar el sistema. Sin embargo, no hay peligro si slo los miran. La primera clave (es decir, directorio), HKEY_LOCAL_MACHINE, tal vez sea la ms importante porque contiene toda la informacin acerca del sistema local. Tiene cinco subclaves (subdirectorios). La subclave HARDWARE contiene muchas subclaves que describen por completo el hardware e indican cul controlador controla cun dispositivo. El administrador de Plug-and-Play construye esta informacin sobre la marcha cuando arranca el sistema. A diferencia de las otras subclaves, sta no se almacena en disco. La subclave SAM (administrador de cuentas de seguridad; Security Account Manager) contiene los nombres de usuario, grupos, contraseas y otra informacin de cuentas y seguridad necesaria para iniciar sesin. La subclave SECURITY contiene informacin general acerca de la directiva de seguridad, como la longitud mnima de las contraseas, cuntos intentos fallidos de iniciar sesin se toleran antes de llamar a la polica, etctera. La subclave SOFTWARE es donde los fabricantes de software almacenan preferencias, entre otras cosas. Por ejemplo, si un usuario tiene instalados Adobe Acrobat, PhotoShop y Premiere, habr una subclave Adobe aqu, y debajo de ella subclaves para Acrobat, PhotoShop, Premiere y otros productos de Adobe que se tengan. Las entradas de estos subdirectorios pueden almacenar cualquier cosa que quieran poner ah los programadores de Adobe, por lo general, propiedades vlidas para todo el sistema, como el nmero de versin y de compilacin, cmo desinstalar el paquete, qu controladores usar y cosas as. El Registro les ahorra la molestia de tener que inventar su propio mtodo para almacenar esta informacin. En el Registro tambin se almacena informacin especfica para usuarios, pero bajo HKEY_USERS.
Clave HKEY_LOCAL_MACHINE HARDWARE SAM SECURITY SOFTWARE SYSTEM HIKEY_USERS USER-AST-ID AppEvents Console Control Panel Evironment Keyboard Layout Printers Software
Descripcin Propiedades del hardware y el software Descripcin de hardware y correspondencia entre hardware y controladores Informacin de seguridad y cuentas de usuarios Polticas de seguridad para todo el sistema Informacin genrica acerca de aplicaciones instaladas Informacin para arrancar el sistema Informacin acerca de usuarios; una subclave por usuario Perfil de usuario AST Qu sonido emitir (al llegar correo electrnico/fax, error, etc.) Parmetros del indicador de comandos (colores, fuentes, historial, etc.) Apariencia del escritorio, protector pantalla, sensibilidad del ratn etc. Variables de entorno de
Teclado: 102 teclas EU, AZERTY, Dvorak, etc. Informacin acerca de impresoras instaladas Preferencias de usuario para software de Microsoft y de terceros HIKEY_PERFORMANCE_DATA Cientos de contadores que supervisan el desempeo del sistema HIKEY_CLASSES_ROOT HIKEY_ CURRENT_CONFIG HIKEY_CURRENT_USER Enlace con HIKEY_LOCAL_MACHINE/SOFTWARE/CLASSES Enlace con el perfil de hardware actual Enlace con el perfil de usuario actual
Figura 2.5 Claves raz del Registro, y subclaves selectas. El uso de maysculas no tiene significado; slo sigue la prctica de Microsoft La subclave SYSTEM contiene sobre todo informacin acerca del arranque del sistema; por ejemplo, la lista de controladores que hay que cargar, Tambin contiene la lista de servicios (demonios) que hay que iniciar despus del arranque, e informacin de configuracin para todos ellos. La siguiente clave de nivel ms alto es HKEY_USERS, que contiene los perfiles de todos los usuarios. Aqu se almacenan todas las preferencias especficas para cada usuario
en lo tocan te a varias reas. Cuando un usuario cambia una preferencia empelando el Panel de control, por ejemplo, la combinacin de colores del escritorio, aqu se asientan los nuevos parmetros. De hecho, muchos de los programas del Panel de control se limitan a solicitar informacin al usuario y efectuar los cambios necesarios en el Registro. Unas cuantas de las subclaves bajo HKEY_USERS aparecen en la figura 2-5 y no debern requerir muchos comentarios ms. Algunas de las subclaves, como Software, contienen un nmero sorprendentemente grande de subclaves, aunque no estn instalados paquetes de software. La siguiente clave del nivel ms alto, HKEY_PERFORMANCE_DATA, no contiene datos ledos del disco ni datos recolectados por el administrador de Plug-andPlay, sino que ofrece una ventana hacia el sistema operativo. El sistema mismo contiene cientos de contadores para supervisar el desempeo del sistema. Puede tener acceso a esos contadores por medio de esta clave del Registro. Cuando se consulta una subclave, se ejecuta un procedimiento dado para recabar y devolver la informacin (quiz leyendo uno o ms contadores y combinndolos de alguna manera). Esta clave no puede verse con regedit ni con regedit32. Para ello se necesitan las herramientas de desempeo, como pfmon, perfmon y pview. Hay muchas de esas herramientas, algunas en el CD-ROM de Windows 2000, algunas en los kits de recursos y algunas en productos de terceros. Las siguientes tres claves del nivel ms alto no existen en realidad. Todas son enlaces simblicos a algn otro lugar del Registro. La clave HKEY_CLASSES_ROOT es la ms importante: apunta al directorio que maneja objetos COM (Modelo de Objetos Componentes; Component Object Model) y las asociaciones entre extensiones de archivo y programas. Cuando un usuario hace doble clic en una archivo que termina en, digamos, .doc, el programa que atrapa el clic del ratn examina esta clave para ver qu programa debe ejecutar (tal vez Microsoft Word). La base de datos completa de extensiones reconocidas y sus correspondientes programas est bajo esta clave. La clave HKEY_CURRENT_CONFIG se enlaza con la configuracin de hardware vigente. Un usuario puede construir mltiples configuraciones de hardware, por ejemplo, inhabilitando diversos dispositivos para ver si son la causa del algn comportamiento extrao del sistema. Esta clave apunta a la configuracin actual. De forma similar, HKEY_CURRENT_USER apunta al usuario actual, con el fin de que sus preferencias puedan hallarse rpido. Ninguna de las tres ltimas claves aade algo en realidad, pues la informacin de todos modos est disponible en otros lugares (aunque no es tan cmodo tener acceso a ella). As, a pesar del hecho de que regedit y regedt32 mencionan cinco claves de nivel superior, en realidad slo hay tres directorios de nivel superior, y uno de ellos no aparece entre los cinco que se muestran.
El programador de Win32 tiene acceso pleno al Registro. Hay llamadas para crear y eliminar claves, buscar valores dentro de claves y ms. En la figura 2-6 se presentan algunas de las ms tiles. Funcin de API WIN32 RegCreateKeyEx RegDeleteKey RegOpenKeyEx REgEnumKeyEx RegQueryValueEx Descripcin Crea una nueva clave del registro Borra un clave del Registro Abre una clave para obtener un identificador Enumera las subclaves subordinadas a la clave del identificador Busca los datos de un valor dentro de una clave
Figura 2.6 Algunas de las llamadas de la API Win32 para usar el Registro. Cuando se apaga el sistema, la mayor parte de la informacin del Registro (pero no toda, como ya mencionamos) se almacena en el disco, en archivos llamados subrboles (hives). Casi todos ellos estn en \winnt\system32\config. Dado que su integridad es crucial para el funcionamiento correcto del sistema, cuando se actualizan, se preparan en forma automtica copias de seguridad, y las escrituras se efectan empleando transacciones atmicas para evitar la corrupcin, en caso de que el sistema falle durante la escritura. La prdida del Registro requerira reinstalar todo el software. 2.3 ESTRUCTURA DEL SISTEMA En las secciones anteriores examinamos Windows 2000 desde el punto de vista del programador. Ahora miremos la organizacin interna del sistema, qu hace los distintos componentes y cmo interactan entre s y con los programas de usuario. Aunque existen muchos libros acerca de cmo usar Windows 2000, son muchos menos los que explican cmo funciona. Por mucho, el mejor lugar para buscar informacin adicional sobre este tema es Inside Windows 2000, 3. Ed., por Solomon y Russinovich (2000). Una parte del material del presenta captulo se basa en informacin de ese libro y en informacin de sus autores. Microsoft fue otra fuente clave. 2.3.1 Estructura del sistema operativo Windows 2000 consta de dos componentes principales: el sistema operativo en s, que se ejecuta en modo de kernel, y los subsistemas de entorno, que se ejecutan en modo de usuario. El kernel es tradicional en el sentido de que se encarga de la administracin de procesos, la administracin de memoria, los sistemas de archivos, etc. Los subsistemas de entorno se salen un poco de lo comn, en cuanto a que son procesos individuales que ayudan a los programas de usuario a realizar ciertas funciones del sistema.
Unas de las muchas mejoras de NT respecto a Windows 3.x fue su estructura modular. Consista en un kernel moderadamente pequeo que se ejecutaba en modo de kernel, ms algunos procesos de servidor que se ejecutaban en modo de usuario. Los procesos de usuario interactuaban con los procesos de servidor empleando el modelo cliente-servidor: un cliente enviaba un mensaje de solicitud a un servidor y ste efectuaba el trabajo y devolva el resultado el cliente en un segundo mensaje. Tal estructura modular facilitaba el traslado a varias computadoras no pertenecientes a la lnea Intel, como DEC Alpha, IBM PowerPc y SGI MIPS. Tambin protega al kernel contra errores de programacin en el cdigo del servidor. Sin embargo, por razones de desempeo, a partir de NT 4.0 casi todo el sistema operativo (por ejemplo, el manejo de las llamadas al sistema y todos los grficos de pantalla) volvi a ponerse en modo de kernel. Este diseo se perpetu en Windows 2000. No obstante, sigue habiendo cierta estructura en Windows 2000. El sistema est dividido en varias capas, cada una de las cuales usa los servicios de las que estn abajo. La estructura se ilustra en la figura 2-7. Una de las capas est dividida de manera horizontal en muchos mdulos. Cada mdulo tiene una funcin especfica y una interfaz bien definida con los otros. Las dos capas de software ms bajas, HAL y el kernel, estn escritas en C y en lenguaje ensamblador y dependen en parte de la mquina. Las capas superiores estn escritas en su totalidad en C y son independientes de la mquina casi por completo. Los controladores estn escritos en C, o en unos pocos casos en C++.
Figura 2.7. Estructura de Windows 2000 (Un poco simplificada ) . El rea sombreada es el ejecutivo Los cuadritos con D con controladores de dispositivos. Los procesos de servicios son demonios del sistema.
La capa de abstraccin de hardware Una de las metas de Windows 2000 (y de Windows NT) era que el sistema operativo fuera porttil entre plataformas. De manera ideal, cuando llega una nueva mquina, debera ser posible simplemente recompilar el sistema operativo con el compilador de la nueva mquina y hacer que se ejecute la primera vez. Por desgracia, la vida no es as. Aunque puede lograrse que las capas superiores del sistema operativo sean porttiles por completo (porque en su mayor parte manejan estructuras de datos internas), las capas inferiores se ocupan de registros de de dispositivos, interrupciones, DMA y otras caractersticas de hardware que difieren en forma apreciable de una mquina a otra. Aunque casi todo el cdigo de bajo nivel est escrito en C, no es posible tan slo tomarlo de una Pentium, ponerlo en una Alpha, digamos, recompilarlo y rearrancarlo, debido a las mltiples pequeas diferencias de hardware entre Pentium y Alpha, que nada tiene que ver con los diferentes conjuntos de instrucciones y que el compiladote no puede ocultar. Consciente de este problema, Microsoft hizo un intento serio por ocultar muchas de las dependencias de la mquina en una capa delgada situada hasta abajo llamada capa de abstraccin de hardware (HAL; Hardware Abstraction Layer). (El nombre HAL sin duda se inspir se inspir en la computadora HAL de la pelcula del ya desparecido Stanley Kubrick, 2001: Odisea del espacio. Hay rumores de que Kubrick escogi el nombre HAL tomando el nombre de la empresa de computadoras dominante entonces IBM y restando 1 a cada letra.) La tarea de HAL consiste en presentar el resto del sistema operativo dispositivos de hardware abstractos, y sobre todo privados, de las verrugas y peculiaridades que en tanta abundancia posee el hardware real. Estos dispositivos se presentan en forma de servicios independientes de la mquina (llamadas a procedimientos y macros) que pueden usar el resto del sistema operativo y los controladores. Al emplear los servicios de HAL (que son idnticos en todos los sistemas Windows 2000, sea cual sea el hardware) y no direccionar de manera directa el hardware, los controladores y el kernel requieren menos cambios al trasladarse a hardware nuevo. El traslado de HAL en s es directo porque todo el cdigo dependiente de la mquina est concentrado en un solo lugar y las metas del traslado estn bien definidas, a saber, implementar todos los servicios de HAL. Los servicios que se escogieron para incluirse en HAL son los que tienen que ver con el conjunto de chips (chipset) de la tarjeta matriz y que varan de una mquina a otra dentro de lmites razonablemente predecibles. Dicho de otro modo, estn diseados para ocultar las diferencias entre la tarjeta matriz de un fabricante y la de otro, pero no las diferencias entre un Pentium y un Alpha. Los servicios de HAL incluyen acceso a los registros del dispositivo, direccionamiento de dispositivos independiente del bus, manejo y restablecimiento de interrupciones, transferencias por DMA, control de los temporizadores y del reloj de tiempo real, bloqueos giratorios de bajo nivel y sincronizacin de
multiprocesadores, y comunicacin con el BIOS y su memoria de configuracin CMOS. HAL no proporciona abstracciones ni servicios para dispositivos de E/S especficos como teclados, ratones o discos, ni para la unidad de administracin de memoria. Como ejemplo de lo que hace la capa de abstraccin de hardware, consideremos la cuestin del uso de E/S con correspondencia en memoria o de puertos de E/S. Algunas mquinas tienen una cosa y otras tienen la otra. Cmo debe programarse un controlador: de modo que use E/S con correspondencia en memoria o de modo que use puertos? En vez de forzar una decisin, lo cual hara que el controlador no pudiera trasladarse a una mquina que hiciera las cosas del otro modo, la capa de abstraccin de hardware ofrece tres procedimientos que los creadores de controladores pueden utilizar para leer los registros de dispositivo, y otro tres para escribirlos: Uc = READ_PORT_UCHAR (puerto; WRITE_PORT_UCHAR (puerto,uc); Us = READ_PORT_USHORT (puerto); WRITE_PORT_USHORT (puerto,us); Ul = READ_PORT_ULONG (puerto); WRITE_PORT_ULONG (puerto,ul); Estos procedimientos leen y escriben enteros sin signo de 87, 16 y 32 bits, respectivamente, en el puerto especificado. Corresponde a la capa de abstraccin de hardware decidir si aqu se necesita E/S con correspondencia en memoria. As, un controlador puede trasladarse sin necesidad de modificaciones entre mquinas que difieren en la forma de implementar los registros de dispositivos. Muchas veces los controladores necesitan acceso a dispositivos de E/S especficos para hacer diversas cosas. En el nivel de hardware, un dispositivo tiene una o ms direcciones en cierto bus. Puesto que las computadoras modernas suelen tener mltiples buses (ISA, PCI, SCSI, USB, 1394, etctera), puede suceder que dos o ms dispositivos tengan la misma direccin de bus, por lo que necesita alguna forma de distinguirlos. Hal proporciona un servicio para identificar dispositivos, estableciendo una correspondencia entre las direcciones de dispositivo relativas al bus y direcciones lgicas vlidas para todo el sistema. As, los controladores no necesitan recordar cul dispositivo est en cul bus. Estas direcciones lgicas son anlogas a los identificadores que da el sistema operativo a los programas de usuario para referirse a los archivos y a otros recursos del sistema. Este mecanismo tambin escuda a las capas superiores de las propiedades de estructuras de bus y convenciones de direccionamiento alternas. Las interrupciones tienen un problema similar: tambin dependen del bus. En este caso, en forma anloga, HAL proporciona servicios que asignan a las interrupciones nombres vlidos para todo el sistema, as como servicios que permiten a los controladores anexar rutinas de servicio a las interrupciones de forma porttil, sin tener que saber cul vector de interrupcin es para cul bus. La administracin de niveles de solicitud de interrupcin tambin se maneja en HAL.
Otro servicio de HAL es preparar y administrar las transferencias por DMA de forma independiente del dispositivo. Pueden manejarse tanto el motor de DMA para todo el sistema, como los motores de DMA de tarjetas de E/S especficas. Se hace referencia a los dispositivos por sus direcciones lgica. Hal tambin implemente la dispersin/aglomeracin del software (escribir o leer de bloques de memoria fsica que no son contiguos). HAL tambin administra relojes y temporizadores de manera porttil. Se lleva el control del tiempo en unidades de 100 ns a partir del 1 de enero de 1601, lo cual tiene una precisin mucho mayor que el esquema de MS-DOS, con unidades de dos segundos a partir del 1 de enero de 1980, y maneja las muchas actividades relacionadas con las computadoras efectuadas en los siglos XVII, XVII, XIX. Los servicios de tiempo desligan los controladores de las frecuencias reales con que operan los relojes. Los componentes del kernel a veces tienen que sincronizarse en un nivel muy bajo, sobre todo cuando es necesario prevenir condiciones de competencia en sistemas multiprocesador. HAL proporciona algunas primitivas para administras esta sincronizacin, como bloqueos giratorios, en los que una CPU tan slo espera a que se libere un recurso que est en manos de otra CPU, sobre todo en situaciones en las que el recurso regularmente slo se retiene durante unas cuentas instrucciones de mquina. Por ltimo, una vez que arranca el sistema, HAL s comunica con el BIOS e inspecciona la memoria de configuracin CMOS, si existe, para averiguar los buses y dispositivos de E/S existentes en el sistema y cmo se han configurado. Esta informacin se coloca entonces en el Registro para que otros componentes del sistema puedan consultarla sin tener que entender cmo funcionan el BIOS y la memoria de configuracin. En la figura 2-8 se presenta un resumen de algunas de las cosas que hace HAL. Puesto que HAL depende en alto grado de la mquina, debe encajar a la perfeccin con el sistema en el que se instala; por ello, se incluyen diversas HAL en el CD-ROM de Windows 2000. En el momento de instalar el sistema, se escoge la HAL apropiada y se copia en el directorio del sistema \winnt\system32 del disco duro, con el nombre hal.dll. Despus, cada vez que se arranque la mquina se usar esta versin de HAL para hacerlo. La eliminacin de este archivo impedir arrancar la mquina. Aunque HAL es razonablemente eficiente, en el caso de aplicaciones multimedia podra ser lo bastante rpida. Por ello, Microsoft produjo adems un paquete de software llamado DirectX, que acrecienta HAL con procedimientos adicionales y permite a los proceso de usuario tener un acceso mucho ms directo al hardware.
Figura 2.8 Algunas de las funciones de hardware que administra HAL La capa del kernel Arriba de la capa de abstraccin de hardware est una capa que contiene lo que Microsoft llama el kernel, as como los controladores de dispositivos. Algunas de las primeras versiones de la documentacin llaman microkernel al kernel, cosa que nunca fue en realidad porque el administrador de memoria, el sistema de archivos y otros componentes principales residieron en el espacio de kernel y se ejecutaron en modo de kernel desde el principio. Es indudable que el kernel no es un microkernel ahora, porque casi todo el sistema operativo se puso en el espacio de kernel a partir de NT 4.0. Una parte del kernel (y gran parte de HAL) reside de forma permanente en la memoria principal (es decir, no se pagina). Al ajustar su prioridad, es posible controlar si puede tolerar ser expropiada por interrupciones de E/S o no. Aunque una fraccin considerable del kernel es especfica para la mquina, de todos modos est escrita en su mayor parte en C, excepto cuando la necesidad de obtener un mximo desempeo domina todas las dems consideraciones. El propsito de kernel es hacer que el resto del sistema operativo sea independiente por completo del hardware, y por lo tanto muy porttil. El kernel, contina la labor de HAL; tiene acceso al hardware por medio de HAL y se apoya en los servicios de HAL de extremadamente bajo nivel para construir abstracciones de mas alto nivel. Por ejemplo, HAL tiene llamadas para asociar procedimientos de servicio de interrupciones a las interrupciones y establecer sus prioridades, pero no hace mucho ms en esta rea. El kernel, en cambio, proporciona un mecanismo completo para realizar conmutaciones de contexto. Guarda en forma correcta todos los registros de la CPU, cambia las tablas de paginas, escribe en disco el cach de la CPU, etctera, de modo que, cuando termina, el subproceso que se estaba ejecutando antes ya se ha guardada en tablas en la memoria.
Luego, el kernel prepara el mapa de memoria del nuevo subproceso y carga sus registros para que pueda iniciar su ejecucin. El cdigo para calendarizar subproceso tambin est en el kernel. Cuando llega el momento de ver si puede ejecutarse un nuevo subproceso, por ejemplo, despus de que se agota un cuanto o despus de que termina una interrupcin de E/S, el kernel escoge el subproceso y efecta la conmutacin de contexto necesaria para ejecutarlo. Desde el punto de vista del resto del sistema operativo, las capas inferiores manejan en forma automtica la conmutacin de subprocesos de forma porttil, sin que el resto del sistema operativo tenga que efectuar trabajo alguno. Adems de proporcionar una abstraccin de ms alto nivel del hardware y de encargarse de las conmutaciones de subprocesos, el kernel tiene otra funcin clave: proporcionar apoyo de bajo nivel para dos clases de objeto: objetos de control y objetos de despachador. stos no son los objetos para los cuales los procesos de usuario reciben identificadores, sino objetos internos sobre los que el ejecutivo construye los objetos de usuario. Los objetos de control son aquellos que controlan el sistema e incluyen los objetos de proceso primitivos, los objetos de interrupcin y dos objetos de tanto extraos llamados DPC y APC. Un objeto de llamada diferida a procedimiento (DPC; Deferred Procedure Call) sirve para separar la parte de un procedimiento de servicio de interrupcin para la cual el tiempo no es crtico, de la parte para la cual s lo es., En general, un procedimiento de servicio de interrupcin guarda unos cuantos registros de hardware voltiles asociados al dispositivo de E/S interruptor para que no se sobrescriban, y vuelve a habilitar el hardware, pero deja el grueso procesamiento para despus. Por ejemplo, cuando se oprime una tela, el procedimiento de servicio reinterrupcin el teclado lee el cdigo de tecla de un registro y vuelve a habilitar la interrupcin del teclado, pero no necesita procesa la tecla de inmediato, sobre todo si est sucediendo algo ms importante (es decir, de ms alta prioridad) en ese momento. Mientras la tecla se procese en un plazo mayor de 1000 ms, el usuario no notar el retraso. Las DPCs tambin se usan con los vencimientos de temporizador y otras actividades cuyo procesamiento real no tiene que ser instantneo. La cola de DPC es el mecanismo para recordar que hay ms trabajo por hacer despus. Otro objeto de control de kernel es la llamada asncrona a procedimiento (APC; Asynchronous procedure call). Las APCS son como las DPCs, excepto que se ejecutan en el contexto de un proceso especfico. Al procesar una pulsacin, no importa en qu contexto se ejecute la DPC porque lo nico que va a sucede es que va a inspeccionarse el cdigo de tecla y tal vez se colocar en un bfer del kernel. En cambio, si una interrupcin requiere que se copie un bfer del espacio de kernel en un bfer del espacio de direcciones
de algn proceso de usuario (por ejemplo, como cuando se termina de leer del mdem), entonces el procedimiento de copiado necesitar ejecutarse en el contexto del receptor. Se requiere el contexto del receptor para que la tabla de pginas contenga tanto el bfer de kernel como el bfer de usuario (todos los procesos contienen el kernel completo en sus espacios de direcciones). Por este motivo, el kernel distingue entre las DPCs y las APCs. El otro tipo de objetos de kernel comprende los objetos de despachador. stos incluyen semforos, mutexes, suceso, temporizadores susceptibles de esperarse y otros objetos que pueden esperar los subprocesos. La razn por la que stos tienen que manejarse (en parte) en el kernel es que estn ntimamente enlazados con la calendarizacin de subprocesos, que es una tarea de kernel. Por cierto, los mutexes se llaman mutantes en el cdigo porque tenan que implementar la semntica de OS/2 para no abrirse en forma automtica cuando termina e subproceso que los cerr, algo que los diseadores de Windows 2000 consideraron de lo ms extrao. (La semntica de OS/2, el sistema operativo que vena con la PC/s de IBM.) El ejecutivo Arriba del kernel y de los controladores de dispositivos est la porcin superior del sistema operativo, llamada ejecutivo, que aparece como rea sombreada en la figura 11-7. El ejecutivo est escrito en C, es independiente de la arquitectura y puede trasladarse a mquinas nuevas relativamente con poco esfuerzo. Consta de 10 componentes, cada uno de los cuales no es ms que una coleccin de procedimientos que colaboran para alcanzar alguna meta. No existen fronteras bien demarcadas entre los componentes y los distintos autores que describen el ejecutivo, podran incluso agrupar los procedimientos en componente e de diferente manera. Cabe sealar que dos componentes que estn en el mismo nivel pueden invocarse uno al otro de manera extensa, y lo hacen. El administrador de objetos administra todos los objetos que conoce el sistema operativo. stos incluyen proceso, subprocesos, archivos, directorios, semforos, dispositivos de E/S, temporizadores y muchos otros. El administrador de objetos asigna un bloque de memoria virtual de espacio de direcciones del kernel cuando se crea un objeto, y lo devuelve a la lista libre cuando se quita el objeto. Su tarea es seguir la pista de todos los objetos. Para evitar confusiones, casi todos los componentes del ejecutivo rotulados como administrador (adm) en la figura 2-7 no son proceso ni subprocesos, sino simples colecciones de procedimientos que pueden ejecutar otros subprocesos cuando estn en modo de kernel. No obstante, unos cuantos de ellos, como el administrador de consumo de electricidad y el administrador de Plug-adn-Play (PnP), en realidad son subprocesos independientes.
El administrador de objetos tambin administra un espacio de nombres en el que pueden colocarse los objetos recin creados para referirse a ellos despus. Todos los dems componentes del ejecutivo utilizan objetos de manera intensiva para realizar su trabajo. El administrador de E/S proporciona un marco para administrar dispositivos de E/S fsica. Tambin es el lugar donde residen todos los controladores de dispositivos (indicados con D en la figura 2-7). Desde el punto de vista tcnico, los sistemas de archivos son controladores de dispositivos bajo el control del administrador de E/S. Existen dos sistemas de archivos distintos para los sistemas FAT y NTFS, independientes entre s y cada uno controlando diferentes particiones del disco. Todos los sistemas rearchivos FAT son administrados por un solo controlador. El administrador de procesos maneja los procesos y subprocesos, incluidas su creacin y terminacin. Se ocupa de los mecanismos empleados para administrarlos, no de sus polticas de uso. Se basa en los objetos de proceso y subproceso de kernel y les aade funcionalidad adicional. Este componente es la clave de la multiprogramacin en Windows 2000. El administrador de memoria implementa la arquitectura de memoria virtual paginada por demanda de Windows 2000. Este componente s encarga de establecer la correspondencia entre pginas virtuales y marcos de pgina fsicos;; por tanto, hace cumplir las reglas de proteccin que restringen el acceso de cada proceso exclusivamente a las pginas que pertenecen a su espacio de direcciones y no a a los de otros proceso (excepto en circunstancias especiales). Tambin maneja ciertas llamadas al sistema relacionadas con la memoria virtual. El administrador de seguridad hace que se respete el complejo mecanismo de seguridad de Windows 2000, que satisface los requisitos C2 del Libro Naranja del Departamento de Defensa de Estados Unidos. El Libro Naranja especifica un gran nmero de reglas que debe cumplir un sistema, desde validar los inicios de sesin hasta administrar el control de acceso y llenar con ceros la pginas virtuales antes de reutilizaras. El administrador de cach mantiene en la memoria los bloques de disco ms recientemente utilizados para agilizar el acceso a ellos en el (probable) caso deque se vuelvan a necesitar. Su labor consiste en determinar cules bloques es probable que se vayan a necesitar vez y cules no. Es posible configurar Windows 2000 con mltiples sistemas de archivos, en cuyo caso el administrador de cach trabajar para todos ellos, de modo que no tenga que efectuar su propia administracin de cach cada uno. Cuando se necesita un bloque, se pide al administrador de cach que los proporcione. Si el administrador de cach no tiene el bloque, lo silicita al sistema de archivos apropiado. Puesto que los archivos pueden tener correspondencia con los espacios de direcciones e los procesos, el administrador de cach debe interactuar con el administrador de
memoria virtual para mantener la consistencia necesaria. La cantidad de espacio dedicada al cach es dinmica y puede aumentar o reducirse al cambiar la demanda. El administrador de Plug-and-Play recibe todas las notificaciones de dispositivos nuevos recin conectados. En el caso de algunos dispositivos, se efectan una verificacin en el momento del arranque pero no despus. Otros dispositivos, como los USB, pueden conectarse en cualquier momento y su conexin genera un mensaje dirigid al administrador de Plug-and-Play, que entonces localiza y carga el controlador. El administrador de consumo de electricidad trata de reducir al mnimo el consumo de energa. Esto lo hace apagando el monitor y los discos si han estado inactivos durante cierto tiempo. En las laptops, el administraodr de consumo de electricidad vigila el consumo de la batera y toma ciertas medidas cuando la batera est a punto de agotarse. Esas acciones por lo regular incluyen avisar a los programas que guarden sus archivos y se preparen para una terminacin ordenada, y que se apresuren a hacerlo. El administrador de configuracin est a cargo del Registro; aade nuevas entradas y consulta claves cuando se le pide hacerlo. El administrador de llamadas a procedimientos locales (LPCs; local procedure calls) ofrece un mecanismo muy eficiente de comunicacin entre procesos, que se usa entre los procesos y sus subsistemas. Puesto que este mecanismo es necesario para ejecutar algunas llamadas al sistema, la eficiencia es crucial aqu, y es por ello que no se emplean los mecanismos estndar de comunicacin entre procesos. El mdulo GDI Win32 del ejecutivo maneja ciertas llamadas al sistema (pero no todas). En un principio estaba en espacio de usuario pero se pas al espacio de kernel en NT 4.0 para mejorar el desempeo. La Interfaz de Dispositivos Grficos (GDI; Graphics device interface) se encarga de administrar imgenes para el monitor y las impresoras. Ofrece llamadas al sistema que permiten a los programas e usuario escribir en el monitor y en las impresoras en forma independiente del dispositivo. Tambin contiene el administrador de ventanas y el controlador de pantalla. Antes de NT 4.0, este componente tambin estaba en espacio de usuario, pero su desempeo era decepcionante, as que Microsoft lo pas al kernel para acelerarlo. Vale la pena mencionar que la figura 2-7 no est en absoluto dibujada a escala. Por ejemplo, el mdulo de interfaz Win32 y de dispositivos grficos es ms grande que el resto del ejecutivo combinado. En la parte ms alta del ejecutivo est una capa delgada llamada servicios del sistema. Su funcin es proporcionar una interfaz con el ejecutivo. Esta capa acepta las verdaderas llamadas al sistema de Windows 2000 e invoca a otras partes del ejecutivo para que las ejecute.
En el momento del arranque, Windows 2000 se carga en la memoria en forma de una coleccin de archivos. La parte principal del sistema operativo, que consta del kernel y ejecutivo, est en el archivo ntoskrnl.exe. HAL es una biblioteca compartida situada en otro archivo, hal.dll. Win32 y la interfaz de dispositivos grficos estn juntas en un tercer archivo, win32k.sys. Por ltimo, tambin se cargan muchos controladores de dispositivos. Casi todos tienen la extensin .sys. En realidad, las cosas no son tan sencillas. El archivo ntoskrnl.exe viene en dos versiones, uniprocesador y multiprocesador. Tambin hay versiones para el procesador Xeon, que puede tener ms de 4GB de memoria fsica, y el Pentium, que no puede. Por ltimo, las versiones pueden consistir en una compilacin libre (que se vende en tiendas y la preinstalan los fabricantes de computadoras) o una compilacin verificada (para fines de depuracin). En total podra haber ocho combinaciones, aunque dos pares se combinaron, con lo que slo quedan seis. Una de stas se copia en ntoskrnl.exe cuando se instala el sistema. Vale la pena hablar un poco de las compilaciones verificadas. Cuando se instala un dispositivo de E/S nuevo en una PC, siempre debe instalarse un controlador, proporcionado por el fabricante, para que funcione. Supongamos que se instala una tarjeta IEEE 1394 en una computadora y al parecer funciona bien. Dos semanas despus el sistema falla de pronto. A quin culpa el dueo? A Microsoft. El error de programacin s podra ser de Microsoft, pero algunos se deben en realidad a controladores defectuosos, sobre los cuales Microsoft no tiene ningn control y que se instalan en la memoria de kernel con pleno acceso a todas sus tablas, as como a todo el hardware. En un intento por reducir el nmero de clientes iracundos que llaman por telfono, Microsoft trata de ayudar a quienes crean los consoladores a depurar su cdigo colocando instrucciones de la forma. ASSERT (alguna condicin) Por todo el cdigo. Estas instrucciones verifican que todos los parmetros sean congruentes con los procedimientos internos del kernel (que pueden ser invocados libremente por los controladores) y efectan adems muchas otras verificaciones. En las compilaciones libres ASSERT est definido como una macro que no hace nada, con lo que elimina todas las verificaciones. En las compilaciones verificadas ASSERT est definido como #define ASSERT (a) if ( (a)) error( ) Lo que hace que todas las verificaciones aparezcan en el cdigo ejecutable de ntoskrnl.exe y se realicen en tiempo ejecucin. Aunque esto hace mucho ms lento el
sistema, ayuda a los creadores de controladores a depurar sus controladores antes de entregarlos a los clientes. Las compilaciones verificadas tambin tienen activadas muchas otras funciones de depuracin. Los controladores de dispositivos La ltima parte de la figura 2-7 consiste en los controladores de dispositivos. Cada uno de stos puede controlar uno o ms dispositivos de E/S, pero tambin puede hacer cosas no relacionadas con un dispositivo especfico, como cifrar un flujo de datos o simplemente proporcionar accesos a estructuras de datos del kernel. Los controladores de dispositivos no forman parte del binario ntoskrnl.exe. La ventaja de este enfoque es que un vez que un controlador se instala en un sistema, se aade a una lista del Registro y se carga en forma dinmica cuando arranca el sistema. As, ntoskrnl.exe es el mismo para todo mundo, pero cada sistema se configura de forma precisa para los dispositivos que contiene. Hay controladores para dispositivos de E/S macroscpicamente visibles, como los discos e impresoras, pero tambin para muchos dispositivos internos y chips de los que casi nadie ha odo hablar. Adems, los sistemas rearchivos tambin estn presentes como controladores de dispositivos, como ya mencionamos. El controlador de dispositivo ms grande, el de Win32, GDI y vdeo, aparece a la derecha de la figura 2-7. Este componente maneja muchas llamadas al sistema y casi todas las funciones de grficos. Puesto que los clientes pueden instalas controladores de dispositivos nuevos, pueden afectar el kernel y corromper el sistema. Por ellos, debe tener mucho cuidado al escribir controladores. 2.3.2 Implementacin de objetos Los objetos quiz sean el concepto individual ms importante de Windows 2000. Proporcionan una interfaz uniforme y coherente para todos los recursos del sistema y estructuras de datos, como procesos, subproceso, semforos, etc. Esta uniformidad tiene diversas facetas. En primer lugar, se tiene acceso y seda nombre a todos los objetos de la misma forma, empleando identificadores de objeto. Segundo, dado que todos los accesos a objetos se efectan por medio del administrador de objetos, es posible colocar todas las verificaciones de seguridad en un lugar y garantizar que ningn proceso pueda evitarlas. Tercero, el compartimiento de objetos entre procesos puede manejarse de manera uniforme. Cuarto, puesto que todas las aperturas y cierres de objetos se tramitan por medio del administrador de objetos, es fcil llevar el control de cules objetos estn en uso todava y cules pueden eliminarse sin peligro. Quinto, este modelo uniforme de administracin de objetos facilita administrar las cuotas de recurso en forma directa. Algo fundamental para entender los objetos es darse cuenta de que inobjeto (del ejecutivo) no es ms que cierto nmero e palabras consecutivas en la memoria (es decir, en
el espacio de direcciones virtual del kernel). Un objeto es una estructura de datos en RAM, ni ms ni menos. Un archivo en disco no es un objeto, aunque se crea un objeto (es decir, una estructura de datos en el espacio de direcciones virtual del kernel) para un archivo cuando se abre. Una consecuencia del hecho de que los objetos no son sino estructuras de datos del kernel es que cuando el sistema vuelve a arrancarse (o cuando falla), se pierden todos los objetos. De hecho, cuando el sistema arranca no hay ningn objeto presente (excepto el proceso inactivo o nulo [idle] y el de sistema, cuyos objetos estn incluidos de forma permanente en el archivo ntoskrnl.exe). Todos los dems objetos se crean sobre al marcha a medida que arranca el sistema y se ejecutan diversos programas de iniciacin (y despus, programas de usuario). Los objetos tienen una estructura, como se muestra en la figura 2-9. Caa objeto contiene un encabezado con cierta informacin que poseen todos los objetos de todos los tipos. Los campos de este encabezado incluyen el nombre del objeto, el directorio de objetos en el que reside dentro del espacio de objetos, informacin de seguridad (para que pueda efectuarse una verificacin cuando se abre un objeto) y una lista de los procesos que tienen identificadores abiertos para el objeto (si est habilitada cierto indicador de depuracin).
Figura 2.9 Estructura de un objeto Cada encabezado de objeto contiene tambin un campo de cuota por uso, que es el cargo que se hace un proceso por abrir el objeto. Si un objeto archivo cuesta 1 punto y un proceso pertenece a un trabajo que tiene una cuota de 10 puntos de archivo, los procesos de este trabajo slo podrn abrir 10 archivos en total. Esto permite imponer lmites de recursos a cada tipo de objetos de manera individual.
Lo objetos ocupan terreno valioso trozos del espacio de direcciones virtual del kernel- por lo que cuando un objeto ya no es necesario, debe eliminarse, debe eliminarse para reciclar su espacio de direcciones. El mecanismo de reciclaje emplea un contador de referencias en el encabezado de cada objeto, el cual cuenta el nmero de identificadores abierto que tienen los procesos. Este contador se incrementa cada vez que el objeto se abre y se decrementa cada vez que se cierra. Si el contador llega a cero, quiere decir que ningn usuario tiene identificadores para el objeto. Cuando un componente del ejecutivo obtiene o libera un objeto, un segundo contador reincremente o decremente, aunque no se entregue un identificador real. Si ambos contadores estn en cero, quiere decir que ningn proceso de usuario y ningn proceso del ejecutivo estn usando el objeto, as que puede eliminarse para liberar su memoria. El administrador de objetos necesita mantener estructuras de datos dinmicas (sus objetos), pero no es la nica parte del ejecutivo que tiene esa necesidad. Otros componentes tambin necesitan asignar y liberar en forma dinmica trozos de memoria del kernel. Para satisfacer estas necesidades, el ejecutivo mantiene dos reservas de pginas en el espacio de direcciones del kernel: para objetos y para otras estructuras de datos dinmicas. Tales reservas operan como heaps: algo similar a las llamadas malloc y free para administrar datos dinmicos en el lenguaje C. Una reserva se pagina pero la otra no (es decir, est fija en la memoria). Los objetos que se necesitan a menudo se mantienen en la reserva no paginada; los objetos a los que rara vez se tiene acceso, como las claves del Registro y cierta informacin de seguridad, se mantienen en la reserva paginada. Si la memoria escasea, estas ltimas pueden paginarse a disco y traerse cuando se produzca un fallo de pgina. De hecho, hay porciones considerables del cdigo y estructuras de datos del sistema operativo que pueden paginarse a fin de reducir el consumo de memoria. Los objetos que podran necesitarse cuando el sistema est ejecutando cdigo crucial (y cuando no se permite paginar) deben colocarse en la reserva no paginada. Si se requiere una cantidad de almacenamiento pequea, puede tomarse una pgina de cualquiera de las dos reservas y dividirse en unidades que pueden tener desde 8 bytes.
Figura 2.10. Algunos tipos de objetos comunes del ejecutivo, administrados por el administrador de objetos Los objetos tienen tipo, lo que significa que cada uno tiene ciertas propiedades comunes a todos los objetos de su tipo. El tipo se indica en el encabezado con un apuntador a un objeto de tipo, como se muestra en la figura 2-9. La informacin de tipo del objeto incluye cosas como el nombre del tipo, si un subproceso puede esperar o no a ese objeto (s en el caso de mutexes, no en el caso de archivos abiertos), y la reserva (paginada o no paginada) en la que se colocan los objetos nuevos de este tipo. Cada objeto apunta a su objeto de tipo. El ltimo elemento de un objeto de tipo es tambin el ms importante: apuntadores al cdigo para ciertas operaciones estndar como open, close y delete. Cada vez que se invoca una de estas operaciones para un objeto, se sigue el apuntador al objeto de tipo y de ah se localiza y ejecuta el cdigo pertinente. Este mecanismo proporciona al sistema la oportunidad de asignar valores iniciales a los objetos nuevos y recuperar memoria cuando se eliminan. Los componentes del ejecutivo pueden crear nuevos objetos en forma dinmica. No existe una lista definitiva de tipos de objetos, pero en la figura 2-10 se presentan los ms comunes. Los procesos y subproceso son obvios: hay un objeto para cada proceso y para cada subproceso, el cual contiene las principales propiedades que se necesitan para administrarlo. Los siguientes tres objetos, semforo, mutex y suceso, se ocupan de la sincronizacin de procesos. Los semforos y mutexes funcionan como cabra
esperar, pero con diversas funciones adicionales (como valores mximos y plazos). Los sucesos pueden estar en uno de dos estados: sealizados o no. Si un subproceso est esperando un suceso que est sealizado, el subproceso se libera de inmediato. Si el suceso no est sealizado, el subproceso se bloquea hasta que algn otro subproceso enva una seal al suceso, con lo cual se liberan todos los subprocesos bloqueados. Tambin es posible configurar un suceso de modo que, una vez que un subproceso ha esperad con xito una seal, el suceso se revierte de manera automtica al estado no sealizado, en vez de quedarse en el estado sealizado. Los objetos de puerto, temporizador y cola tambin tienen que ver con la comunicacin y la sincronizacin. Los puertos son canales entre procesos para intercambiar mensajes. Los temporizadores ofrecen un mecanismo para bloquearse durante un intervalo especfico. Las cosas sirven para notificar a los subproceso que ya termin una operacin de E/S asncrona que se haba iniciado antes. Los objetos de archivo abierto se crean cuando se abre un archivo. Los archivos que no se abren no tienen objetos administrados por el administrador de objetos. Las fichas de acceso son objetos de seguridad; identifican a un usuario e indican qu privilegios especiales tiene, si acaso. Los perfiles son estructuras que sirven para almacenar muestras peridicas del contador de programa de un subproceso en ejecucin, a fin de ver dnde pasa su tiempo el subproceso. Las secciones son objetos que el sistema de memoria utiliza para manejar archivos con correspondencia en memoria. En ellas se registra cul archivo (o cul parte de un archivo) tiene correspondencia con cules direcciones de memoria. Las claves son claves de Registro y sirven para relacionar nombres con valores. Los directorios de objetos son locales por completo respecto al administrador de objetos, y ofrecen un mecanismo para reunir objetos relacionados, de forma exactamente anloga a la funcin de los directorios en el sistema de archivos. Los enlaces simblicos tambin son similares a sus contrapartes en el sistema de archivos: permiten que un nombre en un aparte del espacio de nombres de objetos se refiera a un objeto que est en otra parte del espacio de nombres de objetos. Cada dispositivo conocido tiene un objeto de dispositivo con informacin acerca de l y sirve para referirse al dispositivo conocido tiene un objeto de dispositivo con informacin acerca de l y sirve para referirse al dispositivo dentro del sistema. Por ltimo, cada controlador de dispositivo que se ha cargado tiene un objeto en el espacio de objetos. Los usuarios pueden crear objetos nuevos o abrir objetos existentes emitiendo llamadas de Win32, como CreateSemaphore u OpenSemaphore. stas son llamadas a procedimientos de biblioteca que en ltima instancia hacen que se emitan las llamadas apropiadas al sistema. El resultado de cualquier llamada que crea o abre con xito un objeto es una entrada de 64 bits en una tabla de identificadores privada del proceso que se almacena en la memoria de kernel. El ndice de 32 bits que indica la posicin del identificador dentro de la tabla se devuelve al usuario APRA que lo utilice en llamadas
subsiguientes. La entrada de 64 bits de la taba de identificadores que est en el kernel contiene dos palabras de 32 bits. Una palabra contiene un apuntador de 29 bits al encabezado del objeto. Los tres bits de orden bajo se usan como indicadores (por ejemplo, para indicar si un proceso hijo heredar o no el identificador). Estos bits se tapan con una mscara antes de que se siga el apuntador. La otra palabra contiene una mscara de derechos de 32 bits, necesaria porque los permisos slo se verifican en el momento en que se crea o abre el objeto. Si un proceso slo tiene autorizacin para leer un objeto, todos los dems bits de derechos de la mscara sern ceros, y as el sistema operativo podr rechazar cualquier operacin distinta de la lectura que se intente ejecutar con el objeto. En la figura 2-11 se ilustran las tablas de identificadores de dos procesos y sus relaciones con algunos objetos. En este ejemplo, el proceso A tiene acceso a los subprocesos 1 y 2 y acceso a los mutexes 1 y 2. El proceso B tiene acceso a subproceso 3 y a los mutexes 2 y 3. Las entradas correspondientes de las tablas de identificadores contienen los derechos a cada uno de esos objetos. Por ejemplo, el proceso A podra tener derecho a cerrar y abrir sus mutexes, pero no a destruirlos. Cabe sealar que los dos procesos comparten el mutex 2, lo que permite sincronizar a sus subproceso. Los dems mutexes no se comparten, lo que podra implicar que los subproceso dentro del proceso A utilizan el mutex 1 para su sincronizacin interna, y los subproceso dentro del proceso B usan el mutex 3 para su sincronizacin interna. El espacio de nombres de objetos Conforme se crean y eliminan objetos durante l ejecucin, el administrador de objetos necesita un mecanismo para llevar el control de ellos. Con este fin, el administrador mantiene un espacio de nombres en el que se encuentran todos los objetos del sistema. Un objeto puede usar el espacio de nombres para localizar y abrir un identificador para un objeto de algn otro proceso, siempre que se le haya dado permiso para hacerlo. El espacio de nombres de objetos es uno de tres espacios de nombres que mantiene Windows 2000. Los otros son espacios jerrquicos con mltiples niveles de directorios para organizar las entradas. Los objetos de directorio mencionados en la figura 2-10 ofrecen los medios para implementar este espacio de nombres jerrquico para los objetos. Puesto que los objetos del ejecutivo son voltiles (es decir, desaparecen cuando se apaga la computadora, a diferencia de las entradas del sistema de archivos y de Registro), en el momento en que arranca el sistema no hay objetos en la memoria y el espacio de nombres de objetos est vaco. Durante el arranque, diversas partes del ejecutivo crean directorios y luego llenan con objetos. Por ejemplo, conforme el administrador de Plugand-Play descubre dispositivos conectaos, crea un objeto de dispositivo para cada uno y lo
coloca en el espacio de nombres. Cuando el sistema termina de arrancar, todos los dispositivos de E/S, particiones de disco y dems descubrimientos ininteresantes estarn en el espacio de nombres de objetos. No todos los objetos se registran empleando el mtodo de Coln: simplemente ir a ver qu se encuentra. Algunos componentes del ejecutivo consultan el Registro para ver qu deben hacer.
Figura 2.11 Relacin entre tablas de identificadores, objetos y objetos de tipo Un ejemplo clave de esto es el de los controladores de dispositivos. Durante el arranque, el sistema consulta el registro para ver cules controladores de dispositivos se necesitan. Conforme se cargan uno por uno, se crea un objeto para cada uno y su nombre se inserta en el espacio de objetos. Dentro del sistema se hace referencia a un controlador, empleando un apuntador a su objeto. Aunque el espacio de nombres de objetos es crucial para el funcionamiento del sistema pocas personas saben siquiera que existe, porque los usuarios no pueden verlo sin herramientas especiales. Una de esas herramientas es winobj, que puede obtenerse gratis
en www.sysinternals.com. Cuando se ejecuta esta herramienta, muestra un espacio de nombres de objetos que por lo regular contiene los directorios de objetos que se enumeran en la figura 2-12, y tambin algunos ms. El directorio con el nombre de un tanto extrao de \?? Contiene los nombres de todos los nombres de dispositivo estilo MS-DOS, como A: para el disco flexible y C: para el primer disco duro. En realidad, estos nombres son enlaces simblicos al directorio \Device donde residen los objetos de dispositivos. Se escogi el nombre \?? Para que apareciera primero en orden alfabtico y as acelerar la bsqueda de todos los nombres de ruta que principian con una letra de unidad. El contenido de los dems directorios de objetos no deber requerir explicacin. 2.3.3 Subsistemas de entorno Volviendo a la figura 2-7, vemos que Windows 2000 consta de componentes en modo de kernel; ahora toca examinar los componentes de modo de usuario, que son de tres tipos: Directorio ?? Device Driver ObjectTypes Windows BaseNamedObs Arcname NLS FileSystem Security KnownDLLs Contenido Punto de partida para buscar dispositivos de MS-DOS como C: Todos los dispositivos de E/S descubiertos Objetos correspondientes a cada controlador de dispositivo cargado Los objetos de tipo de la figura 2.11 Objetos para enviar mensajes a todas las ventanas Objetos creados por usuarios, como semforos, mutexes, etc. Nombres de particiones descubiertas por el cargador de arranque Objetos para manejar idiomas nacionales Objetos de controlador de sistema de archivos y de reconocedor de sistemas de archivos Objetos pertenecientes al sistema de seguridad Biblioteca clave compartidas que se abren pronto y se mantienen abiertas
Figura 2.12 Algunos directorios representativos del espacio de nombres de objetos.
DLLs, subsistemas de entorno y procesos de servicio. Estos componentes colaboran para proporcionar a cada proceso de usuario una interfaz distinta de la interfaz de llamadas al sistema de Windows 2000. Windows 2000 maneja tres APIs distintas documentadas: Win32, POSIX y OS/2. Cada una tiene una lista publicada de llamadas de biblioteca que pueden usar los programadores. La tarea de las DLLs y de los subsistemas de entorno es implementar la funcionalidad de la interfaz publicada, ocultando as la verdadera interfaz de llamadas al sistema para que no puedan verla los programas de aplicacin. En particular, la interfaz Win32 es la interfaz oficial para Windows 2000, Windows NT, Windows 95/98/Me y, hasta cierto punto, Windows CE. Utilizando las DLLs y el subsistema de entorno Win32, puede escribirse un programa que se ajuste a la especializacin Win32, que se ejecutar sin necesidad de modificaciones en todas estas versiones de Windows, aunque las llamadas al sistema no sean las mismas en los diversos sistemas. Para ver cmo se implementan estas interfaces, examinaremos Win32. Un programa Win32 normalmente contiene muchas llamadas a funciones de la API Win32, como CreateWindow (crear ventana), DrawMenuBar (dibujar barra de mens) y Open Semaphore (abrir semforo). Hay miles de estas llamadas, y casi todos los programas utilizan una buena cantidad de ellas. Una posible implementacin ser enlazar de manera esttica cada programa binario contendra en su binario ejecutable una copia de cada procedimiento empleado. El problema con este enfoque es que desperdicia memoria si el usuario tiene varios programas abiertos a la vez y muchos de los procedimientos de bibliotecas que esos programas usan son los mismos. Por ejemplo, Word, Excel y PowerPoint utilizan exactamente los mismos procedimientos para abrir cuadros de dilogo, dibujar ventanas, exhibir mens, administrar el Portapapeles, etctera, as que si un usuario tiene abiertos y activos los tres programas a las vez habr en la memoria tres copias (idnticas) de cada una de las bibliotecas. Para evitar este problema, todas las versiones de Windows manejan bibliotecas compartidas, llamadas bibliotecas de vnculos dinmicos (DLLs; Dynamic Link Libraries). Cada DLL rene un grupo de procedimientos de biblioteca ntimamente relacionados entre s, junto con sus estructuras de datos, dentro de un solo archivo, que por lo regular (aunque no siempre) tiene la extensin .dll. Cuando se liga o enlaza una aplicacin, el enlazador ve que algunos de los procedimientos de biblioteca pertenecen a las DLLs y asienta esta informacin en el encabezado del programa ejecutable. Los procedimientos de las DLLs se invocan de manera indirecta a travs de un vector de transferencia que est en el espacio de direcciones del invocador. En un principio, este vector est lleno de cero, porque todava no se conocen las direcciones de poros procedimientos a invocar.
Cuando se inicia el proceso de la aplicacin, se localizan las DLLs necesarias (en disco o en la memoria) y se establece una correspondencia entre ellas y el espacio de direcciones virtual del proceso. Despus se colocan las direcciones correctas en el vector de trasferencia para poder invocar los procedimientos a travs de dicho vector, con una merma insignificante en la eficiencia. La ventaja aqu es que aunque varios programas de aplicacin tengan correspondencia con la misma DLL, slo se necesitar una copia del texto de la DLL en la memoria fsica (pero cada proceso obtiene su propia copia de los datos estticos privados de la DLL). Windows 2000 utiliza en forma intensiva las DLLs en todos los aspectos del sistema. Cada proceso de usuario por lo regular se enlazaron varias DLLs que juntas implementan la interfaz Win32. Para efectuar una llamada a la API, se invoca uno de los procedimientos de una DLL (paso1 en la figura 2-13). Lo que suceda a continuacin depender de las llamadas a la API Win32, pues las llamadas se implementan de distintas maneras.
Figura 2.13. Diversas rutas que se siguen para implementar las llamadas a funciones de la API Win32. En algunos casos, la DLL invoca a otra DLL (ntdll.dll) que salta al sistema operativo por una interrupcin de sistema. Esa ruta se muestra como pasos 2 y 3 en la figura 2-13. Tambin puede ser que la DLL realice por su cuenta todo el trabajo sin efectuar ninguna llamada al sistema. Con otras llamadas a la API Win32 se sigue una ruta distinta: primero se enva un mensaje al proceso del subsistema Win32 (csrss.exe), que efecta ciertas taras y luego emite una llamada al sistema (pasos 2b, 3b y 4b). Aqu tambin hay algunos casos en que el subsistema de entorno efecta todo el trabajo en espacio de usuario y regresa de inmediato. La transferencia de mensajes entre el proceso de aplicacin y el proceso de subsistema de Win32 se ha optimizado con cuidado en cuanto
a desempeo, empelando un mecanismo especia de llamadas a procedimientos locales implementado por el ejecutivo y que se indica con LPC en la figura 2-7. En la primera versin de Windows NT, casi todas las llamadas a la API Win32 seguan la ruta 2b, 3b, 4b, colocando una porcin considerable del sistema operativo en espacio de usuario (por ejemplo, los grficos). Sin embargo, a partir de NT 4.0 gran parte del cdigo se coloc en modo de kernel (en el controlador Win32/GDI, en la figura 2-7) por motivos de desempeo. En Windows 2000 slo un nmero reducido de llamadas a la API Win32, como a la API Win32, como la creacin de procesos y subprocesos, siguen la ruta larga; las dems toman la ruta directa, pasando por alto el subsistema de entorno Win32. En la figura 2-13 se muestran las tres DLLs ms importantes, pero no son las nicas. Hay ms de 800 DLLs distintas en el directorio \winnt\system32 que ocupan en total 130 MB. Para evitar confusiones, el nmero de archivos de DLL es mayor que 800; el nmero de llamadas de API contenidas en ellos excede 13,000. (La compilacin de los 29 millones de lneas de cdigo tuvo que producir algo, no?) En la figura 2-14 se presentan algunas de las DLLs ms importantes. Se da el nmero de funciones exportadas (es decir, las que pueden verse afuera del archivo) por cada una, pero esa cifra suele cambiar (es decir, aumentar) co el tiempo. El nmero de funciones exportadas (es decir, aumentar) con el tiempo. El nmero de funciones exportadas en la primera versin publicada de ntdll.dll en Windows 2000 es de 1179. stas son las verdaderas llamadas al sistema. Las 1209 llamadas exportadas por ntoskrnl.exe son las funciones con que cuentan los controladores de dispositivos y dems cdigo enlazado con el kernel. La lista de funciones exportadas por cualquier archivo .exe o .dll puede verse con el programa depends en la plataforma SDK Kit. Archivo Hal.dll Ntoskrnl.exe Win32.sys Ntdll.dll Csrss.exe Kernel32.dll Gdi32.dll User32.dll Modo Kernel Kernel Kernel Usuario Usuario Usuario Usuario Usuario Func Contenido s 95 Administrador de hardware de bajo nivel, por ejemplo, E/S de puertos 1209 Sistema operativo de Windows 2000 (kernel+ejecutivo) Muchas llamadas al sistema, incluidas casi todas las de grficos 1179 Despachador de modo de usuario a modo de kernel 0 Proceso de subsistema de entorno Win32 823 Casi todas las llamadas al sistema centrales (no grficos) 543 Llamadas de fuentes, texto, color pincel, pluma, mapa de bits, paleta, dibujo, etc. 695 Llamadas de ventana, cono, men, cursor, dilogo, portapapeles, etc. 557 Llamadas de seguridad criptografa, registro, administracin
Advapi32.dll Usuario
Figura 2.14. Algunos archivos clave de Windows 2000, el modo en que se ejecutan, el nmero de llamadas de funcin que exportan y el contenido principal de cada uno. Las
llamadas de win32k.sys nos e exportan de manera formal porque win332k.sys no se invoca de forma directa. Aunque la interfaz de procesos Win32 es la ms importante, hay otras dos: POSIX y OS/2. El entorno POSIX ofrece apoyo mnimo para aplicaciones UNIX. Slo maneja la funcionalidad P1003.1 y casi nada ms. No tiene subprocesos, ventanas ni conectividad de redes, por ejemplo. En la prctica, trasladar cualquier, trasladar cualquier programa UNIX real a Windows 2000 empleando este subsistema es casi imposible, Se incluy slo porque partes del gobierno estadounidense exigen que los sistemas operativos para computadoras del gobierno se ajusten a P1003.1. Este subsistema no es autosuficiente y utiliza el sistema Win32 para realizar una buena parte de su trabajo, pero sin exportar la interfaz Win32 completa a sus programas de usuario (lo cual habra hecho que sirviera de algo, sin costo adicional para Microsoft). Para que los usuarios de UNIX puedan migrar a Windows 2000, Microsoft tiene un producto llamado Interix que proporciona un grado ms alto de compatibilidad con UNIX que el subsistema POSIX. El subsistema OS/2 tiene limitaciones similares en cuanto a su funcionalidad y no maneja aplicaciones grficas. En la prctica, este subsistema tambin es intil por completo. Por tanto, la idea original de implementar mltiples interfaces de sistemas operativos mediante diferentes procesos en espacio de usuario casi ha desaparecido. Lo que queda es una implementacin completa de Win32 en modo de kernel y casi nada ms. 2.4 Procesos y subprocesos en Windows 2000 Windows 2000 se basa en varios conceptos para administrar la CPU y agrupar los recursos. En las secciones que siguen examinaremos esos conceptos, comentaremos algunas de las llamadas pertinentes a las API Win32 y mostraremos cmo se implementan los conceptos. 2.4.1 Conceptos fundamentales
Windows 2000 maneja procesos tradicionales, capaces de comunicarse y sincronizarse entre s, igual que en UNIX. Cada proceso contiene por lo menos un subproceso, que a su vez contiene al menos una fibra (subproceso ligero). Adems, los procesos pueden reunirse en trabajos para ciertos fines de administracin de recursos. Juntos, los trabajos, procesos, subprocesos y fibras proporcionan un conjunto muy general de herramientas para manejar el paralelismo y los recursos, tanto en uniprocesadores (mquinas con una sola CPU). En la figura 2.15 se presenta un resumen breve de estos cuatro conceptos.
Examinaremos estos conceptos del ms grande hasta el ms pequeo. Un trabajo (Job) en Windows 2000 es una coleccin de uno o ms procesos que se van a administrar como una unidad. En particular, hay cuotas y lmites de recursos asociados con cada trabajo, los cuales se almacenan en el objeto de trabajo correspondiente. Las cuotas incluyen cosas como el nmero mximo de procesos (evita que algn proceso genere un nmero ilimitado de hijos), el tiempo total de CPU disponible para cada proceso individual y para todos los procesos combinados, y el consumo mximo de memoria, tambin por proceso y total. Adems, los trabajos pueden imponer restricciones de seguridad a los procesos que contienen, como no poder adquirir facultades de administrador (superusuario), ni siquiera con la contrasea correcta.
Figura 2.15. conceptos bsicos para administracin de CPU y recursos Los procesos son ms interesantes que los trabajos y tambin ms importantes. Al igual que en UNIX, los procesos son contenedores de recursos. Cada proceso tiene un espacio de direcciones de 4GB, de los cuales el usuario ocupa los 2 GB de abajo (de manera opcional, 3 GB en las versiones Advanced Server y Datacenter Server), mientras que el sistema operativo ocupa el resto. As, el sistema operativo est presente en el espacio de direcciones de cada proceso, aunque el hardware de la unidad de administracin de memoria lo protege contra alteraciones. Cada proceso tiene un identificador de proceso, uno o ms subprocesos, una lista de identificador (administrada enlodo de kernel) y una ficha de acceso que contiene su informacin de seguridad. Los procesos se crea con una llamada de Win32 que toma como entrada el nombre de un archivo ejecutable, el cual define el contenido inicial del espacio de direcciones y crea el primer subproceso. Todo proceso inicia con un solo subproceso, pero pueden crearse en forma dinmica nuevos subprocesos. stos constituyen la base de la calendarizacin de la CPU, pues el sistema operativo siempre escoge el subproceso que se ejecutar, no un proceso. Por consiguiente, cada subproceso tiene un estado (listo, en ejecucin, bloqueado, etctera), mientras que los procesos no tienen estado. Lo subprocesos pueden crearse de manera dinmica con una llamada de Win32 que especifica la direccin dentro del espacio de direcciones del proceso circundante en la que deber comenzar a ejecutarse. Cada suproceso tiene un identificador, que se toma del mismo espacio que el identificador de proceso, de modo que un identificador dado nunca puede estarse usando par aun subproceso y para un proceso al mimo tiempo. Los identificadores de subprocesos y procesos son mltiplos de cuatro para que puedan usarse como ndices de byte con las tablas de kernel, igual que otros objetos.
Los subprocesos por lo regular se ejecutan en modo e usuario, pero cuando emiten una llamada al sistema cambian a modo de kernel y es siguen ejecutando con el mismo identificador, propiedades y lmites que tenan en el modo de usuario. Cada subproceso tiene dos pilas, una para usara en modo de usuario y otra para usarla en modo de kernel. Adems de un estado, un identificador y dos pilas, cada subproceso tiene un contexto (en el que se guardan sus registros cuando no se est ejecutando), un rea privada para sus propias variables locales y tal vez su propia ficha de acceso. Si el subproceso tiene su propia ficha de acceso, sta sobrescribe a la ficha de acceso del proceso para que los subproceso cliente puedan pasar sus derechos de acceso a subprocesos servidores que estn trabajando para ellos. Cuando un subproceso termina de ejecutarse, puede salir. Cuando sale el ltimo subproceso que estaba activo en un proceso, ste termina. Es importante darse cuenta de que los subprocesos son un concepto de calendarizacin, no de posesin de recursos. Cualquier subproceso puede tener acceso a todos los objetos que pertenecen a su proceso; lo nico que tiene que hacer es tomar el identificador y emitir la llamada Win32 apropiada. No hay restricciones en cuanto a que un subproceso no puede tener acceso a un objeto porque ste fue creado o abierto por un subproceso distinto. El sistema ni siquiera lleva el control de cul subproceso cre cul objeto. Una vez que un identificador de objeto se ha colocado en la tabla de identificadores de un proceso, podr usarlo cualquier subproceso del proceso. Adems de los subprocesos normales que se ejecutan dentro de procesos de usuario. Windows 2000 tiene varios subprocesos demonios que slo se ejecutan en espacio de kernel y no estn asociados con ningn proceso de usuario (estn asociados con los proceso especiales de sistema o con el proceso inactivo). Algunos realizan tareas administrativas, como escribir pginas modificadas en el disco, mientras que otros integran una reserva que puede asignarse a un componente del ejecutivo o a un controlador que necesite realizar alguna tarea de forma asncrona en segundo plano. La conmutacin de subprocesos en Windows 2000 es relativamente costosa porque requiere ingresar en modo de kernel y salir despus de l. Para ofrecer un seudoparalelismo muy ligero, Windows 2000 proporciona fibras, que son como subprocesos, excepto que el programa que las cre (o su sistema de tiempo de ejecucin) los calendarizar en espacio de usuario. Cada subproceso puede tener varias fibras, as como un proceso pude tener varios subprocesos, excepto que cuando una fibra se bloquea en forma lgica, se coloca a s misma en la cola de fibras bloqueadas y selecciona otra fibra para que se ejecute en el contexto de su subproceso. El sistema operativo no es consciente de tal transicin porque el subproceso sigue ejecutndose, aunque primero est ejecutando una fibra y despus otra. De hecho, para el sistema operativo las fibras no existen, as que no hay objetos del ejecutivo relacionados con fibras, como los hay para trabajos, procesos y subprocesos. Tampoco hay verdaderas llamadas al sistema para administrar subprocesos, aunque s hay llamadas de la API
Win32. stas se cuentan entre las llamadas de la API que no emiten llamadas al sistema, y que mencionamos al explicar la figura 2-13. La relacin entre trabajos, procesos, subprocesos y fibras se ilustra en la figura 2-16. Aunque no daremos pormenores, Windows 2000 puede ejecutarse en un sistema multiprocesador simtrico. Este requisito implica que el cdigo del sistema operativo debe ser capaz de reentrar en forma plena; es decir, que todo procedimiento debe escribirse de tal manera que dos o ms CPUs puedan estar modificando sus variables al mismo tiempo sin que eso cause problemas. En muchos casos, esto implica que algunas secciones de cdigo tienen que protegerse con bloqueos giratorios o mutexes para que las otras CPUs no entren en ellas hasta que la primera termine (es decir, forzar un acceso en serie a las regiones crticas). El nmero de procesadores que el sistema puede manejar l determinan las restricciones de la licencia y se da en la figura 2-2. N hay razones tcnicas por las que Windows Professional no pueda ejecutarse en un multiprocesador de 32 nodos; despus de todo, el binario es idntico al de Datacenter Server. El lmite superior de 32 procesadores es un lmite fijo, porque se usan mapas de bits de una sola palabra para llevar el control de consumo de CPUs de diversas maneras. Por ejemplo, mapas de bits indica cules de las (hasta) 32 CPUs estn inactivas en ese momento, y se usa otro mapa de bits por cada proceso para indicar en cules CPUs puede ejecutarse. La versin de 64 bits de Windows 2000 deber poder manejar sin mucho esfuerzo hasta 64 procesadores; para manejar ms sera necesario efectuar cambios considerables al cdigo (para usar mapas de bits de ms de una palabra).
Figura 2.16. La relacin entre trabajos, procesos y subprocesos. posible multiplexar fibras en un solo subproceso ( no se muestra).
Tambin es
2.4.2 Llamadas de la API para administracin de trabajos, procesos, subprocesos y fibras. Para crear nuevos procesos se utiliza la funcin CreateProcess de la API Win32. Esta funcin tiene 10 parmetros, cada uno de los cuales tiene muchas opciones. Es obvio que este diseo es mucho ms complicado que el esquema e UNIX, en el que fork no tiene parmetros y exec tiene apenas tres: apuntadores al nombre del archivo a ejecutar, el arreglo de parmetros de lnea de comandos (analizado) y las cadenas de entorno. Agrandes rasgos, los 10 parmetros de CreateProcess son: 1. Un apuntador al nombre del archivo ejecutable. 2. La lnea de comandos en s (sin analizar) 3. Un apuntador a un descriptor de seguridad para el proceso 4. Un apuntador aun descriptor de seguridad para el subproceso inicial. 5. Un bit que indica si el nuevo proceso hereda o no los identificadores del proceso que lo cre. 6. consolas) Indicadores diversos (por ejemplo, modo de error, prioridad, depuracin,
7. Un apuntador a las cadenas de entorno. 8. Un apuntador al nombre del directorio de trabajo actual del nuevo proceso. 9. Un apuntador a una estructura que describe la ventana inicial en la pantalla. 10. Un apuntador a una estructura que devuelve 18 valores. Windows 2000 no impone ningn tipo de jerarqua padre-hijo ni de Otoro tipo. Todos los procesos son igual a crearse (no se crean unos procesos ms iguales que otros). Sin embargo, puesto que uno de los 18 parmetros que se devuelven al proceso creador s un identificador para el nuevo proceso (que permite ejercer un control considerable sobre el nuevo proceso), existe una jerarqua implcita desde el punto de vista de quin tiene un identificador para quin. Aunque estos identificadores no pueden pasarse en forma directa a otros proceso, existe un mecanismo con el cual un proceso puede crear un duplicado de un identificador que se apropiado para otro proceso y luego entregrselo, as que la jerarqua implcita dese el punto de vista de quin tiene un identificador para quin. Aunque estos identificadores no pueden pasarse en forma directa a otros procesos existe un mecanismo con el cual un proceso puede crear un duplicado de un identificador que se apropiado para otro proceso y luego entregrselo, as que la jerarqua implcita de los procesos podra no durar mucho.
Todo proceso de Windows 2000 se crea con un solo subproceso, pero puede crear ms subprocesos despus. La creacin de subprocesos es ms sencilla que la de procesos: Create Thread slo tiene seis parmetros, en vez de 10: 1. El descriptor de seguridad opcional. 2. El tamao inicial de la pila. 3. La direccin de inicio. 4. Un parmetro definido por el usuario 5. El estado inicial de subproceso (listo o bloqueado) 6. El identificador del subproceso El kernel se encarga de crear los subproceso, as que es obvio que tiene conocimiento de ellos (es decir, no se implementan exclusivamente en el espacio de usuario, como sucede en algunos otros sistemas). Comunicacin entre procesos Los subprocesos pueden comunicarse de muy diversas maneras, que incluyen canalizaciones, canalizaciones con nombre, ranuras de correo, sockets, llamadas a procedimientos remotos y archivos compartidos. Las canalizaciones tienen dos modos: de byte y de mensaje; el modo se selecciona en el momento en que se crean. Las canalizaciones en modo de byte operan igual que en UNIX. Las de modo de mensaje son algo similares pero conservan las fronteras de los mensajes, de modo que cuatro escrituras de 128 bytes se leern como cuatro mensajes de 128 bytes, no como un mensaje de 512 bytes, como podra suceder con las canalizaciones en modo de byte. Tambin hay canalizaciones con nombre, y tienen los mismos dos modos que los normales. Las canalizaciones con nombre tambin pueden usarse en una red; las normales no. Las ranuras de correo (mailslots) son una caracterstica de Windows 2000 que no est presente en UNIX. Estas ranuras tienen ciertas similitudes con las canalizaciones, pero tambin presentan diferencias. Una de ellas es que son unidireccionales, mientras que las canalizaciones son bidireccionales. Tambin pueden usarse en una red pero no garantizan la entrega. Por ltimo, permiten al proceso trasmisor difundir un mensaje a muchos recptroes, en vez de a un solo. Los sockets son parecidos a las canalizaciones, excepto que por lo regular conectan procesos de mquinas distintas. Por ejemplo, un proceso escribe en un socket y otro que est en una mquina remota leer de ese socket. Tambin pueden servir para conectar proceso en la misma mquina, pero como implican un mayor gasto adicional que las
canalizaciones, por lo genera slo se usan en el contexto de conectividad de redes. Las llamadas a procedimientos remotos permiten al proceso A pedir al proceso B que invoque un procedimiento en el espacio de direcciones de B, a nombre de A, y devulvale resultado a A. Los parmetros tienen varias restricciones. Por ejemplo, no tiene sentido pasar un apuntador a un proceso distinto. Por ltimo, los procesos pueden compartir memoria estableciendo una correspondencia con el mismo archivo al mismo tiempo. As, todo lo que un proceso escriba en el archivo aparecer en los espacios de direcciones de los otros procesos. Con este mecanismo es fcil implementar el bfer compartido que se usa en problemas de productor-consumidor. As como Windows 2000 ofrece varios mecanismos de comunicacin entre procesos, tambin proporciona numerosos mecanismos de sincronizacin, que incluyen semforos, mutexes, regiones crticas y sucesos. Todos estos mecanismos operan con subprocesos, no procesos, de modo que cuando un subproceso es bloqueado por un semforo, los dems subprocesos de ese proceso (si los hay) no resultan afectados y pueden seguir ejecutndose. Para crear un semforo se utiliza la funcin CreateSemaphore de API, que puede asignarle un valor inicial dado y tambin definir un valor mximo. Los semforos son objetos de kernel y por tanto tienen descriptores de seguridad e identificadores. Puede crearse un duplicado del identificador de un semforo con DuplicateHandle y luego pasarlo a otro proceso para que mltiples proceso puedan sincronizarse con el mismo semforo. Hay llamadas para up y para down, aunque tienen nombre ms bien peculiares de ReleaseSemaphroe (up) y WaitForSingleObject (down). Tambin es posible asignar un plazo a WaitForSingleObject, de modo que el subproceso invocador pueda liberarse de algn momento, aunque el semforo siga en 0 (pero el uso del temporizador reinstroduce la psibilidad de competencias). Los mutexes tambin son objetos de kernel empleados para sincronizacin, pero ms sencillos que los semforos porque no tiene contadores. En esencia son bloqueos con funciones API para cerrarse (WaitForSingleObjet) y abrirse (releaseMutex). Al igual que los identificadores de semforo, los mutex pueden duplicarse y pasarse entre procesos para que subprocesos de diferentes procesos tengan acceso al mismo mutex. El tercer mecanismo de sincronizacin se basa en secciones crticas. Las secciones crticas son similares a los mutexes, excepto que son locales respecto al espacio de direcciones del subproceso que las crea. Dado que las secciones crticas no son objetos del kernel, no tienen identificadores ni descriptores de seguridad y no pueden pasarse entre
procesos El cierre y la apertura s efectan con EnterCriticalSection y LeaveCriticalSection, respectivamente. Puesto que estas funciones API se ejecutan al principio en espacio de usuario y slo efectan llamadas al kernel cuando es necesario bloquear, son ms rpidas que los mutexes. El ltimo mecanismo de sincronizacin emplea objetos de kernel llamados sucesos, que son de dos tipos: sucesos de restablecimiento manual y sucesos de restablecimiento automtico. Cualquier suceso puede estar en uno de dos estados: activado o desactivado. Un subproceso puede esperar a que ocurra un suceso con WaitForSingleObject. Si otro subproceso sealiza un suceso con SetEvent, lo que suceda depender del tipo de suceso. Si es de restablecimiento manual, todos los subprocesos se librarn y el suceso permanecer activo hasta que se desactive en forma manual con ResetEvent. En el caso de un suceso de restablecimiento automtico, si uno o ms subprocesos estn esperando, se liberar exactamente un subproceso y el suceso se desactivar. Una operacin alterna es PulseEvent,que es como SetEvent, excepto que si nadie est esperando la pulsacin se pierde y el suceso se desactiva. En cambio, un SetEvent que se presenta cuando ningn subproceso subsiguiente que lo espere se libere de inmediato. Es posible poner nombre a los sucesos, mutexes y semforos y guardarlos en el sistema de archivos, como canalizaciones con nombre. Dos o ms procesos pueden sincronizarse abriendo el mismo suceso, mutex o semforo, en vez d que uno de ellos cree el objeto y luego produzca duplicados del identificador para los otros, aunque este ltimo enfoque tambin es una opcin. El nmero de llamadas de la API32 que se ocupan de procesos, subprocesos y fibras asciende a casi 100, y de stas una buena parte se ocupa de la comunicacin entre procesos en una forma u otra. En la figura 2-17 se presenta un resumen de las llamadas que hemos mencionado, junto con otras que tambin son importantes. Casi todas las llamadas de la figura 2-17 ya se han explicado, o bien, no requieren mayor explicacin. Cabe Sealar una vez ms que no todas son llamadas al sistema. Windows 2000 no tiene conocimiento de las fibras; stas se implementan por completo en el espacio de usuario. Por consiguiente, la llamada CreateFiber realiza su trabajo exclusivamente en el espacio de usuario sin emitir llamadas al sistema (a menos que tenga que asignar memoria). Muchas otras llamadas de Win32 tienen esta propiedad, incluidas EnterCriticalSection y LeaveCriticalSection.
Funcin de PI Win 32 CreateProcess CreateThread CreateFiber ExitProcess ExitThread
Descripcin Crea un nuevo proceso Crea un nuevo subproceso en el proceso existente Crea una nueva fibra Termina el proceso actual y todos sus subprocesos Termina este subproceso
ExitFiber SetPriorityClass SetThreadPriority CreateSemaphore CreateMutex OpenSempahone OpenMutex WaitForSingleObjetcs WaitForMultipleObjets PulseEvent ReleaseMutex ReleaseSemaphore EnterCriticalSection LeaveCriticaSection
Termina esta fibra Establece la case de prioridad para un proceso Establece la prioridad de un proceso Crea un nuevo semforo Crea un nuevo mutex Abre un semforo existente Abre un mutex existente Se bloquea por un solo semforo, mutex, etc Se bloque por un conjunto de objetos cuyos identificadores se dan Configura un suceso como sealizado y luego como o sealizado Libera un mutex para que otro subproceso lo pueda obtener Incrementa la cuenta de semforo en 1 Obtiene el bloqueo de una seccin crtica Libera el bloque de una seccin crtica
Figura 2.17 Algunas de las llamadas de Win32 para administrar procesos, subprocesos y fibras. 2.4.3 Implementacin de procesos y subprocesos Los procesos y subprocesos son ms importantes y complicados que los trabajos y las fibras, as que nos concentraremos en ellos. Un proceso se crea cuando otro proceso emite la llamada Win32 CreateProcess. Esta llamada invoca un procedimiento (en modo de usuario) contenido en kernel32.dll que crea el proceso en varios pasos, empleando llamadas al sistema y otras acciones. 1. El archivo ejecutable que se dio como parmetro se examina y se abre. Si es un archivo POSIX, OS/2, Windows de 16 bits o MS-DOS vlido, se establece un entorno especial para l. Si es un archivo .exe de 32 bits para Win32, se verifica el Registro para ver si se trata de un programa especial en algn sentido (por ejemplo, si debe ejecutarse bajo la supervisin de un depurador). Todo esto se hace en modo de usuario dentro de kernel32.dll. 2. Se emite una llamada al sistema, NtCreateProcess para crear el objeto de proceso vaco e introducirlo en el espacio de nombres del administrador de objetos. Se crean tanto el objeto de kernel como objeto del ejecutivo. Adems, el administrador de procesos crea un bloque de control de proceso para el objeto y le asigna valores iniciales de
identificador del proceso, cuotas, ficha de acceso y otros campos. Tambin se crea un objeto de seccin para llevar el control del espacio de direcciones del proceso. 3. Cuando kernel32.dll recupera el control, efecta otra llamada al sistema, NtCreateThread, para crear el subproceso inicial. Tambin se crean las pilas de usuario y de kernel del subproceso. El tamao de la pila se den el encabezado del archivo ejecutable 4. Ahora kernel32.dll enva un mensaje al subsistema de entorno de Win32 para notificarle del nuevo proceso y pasarle los identificadores de proceso y de subproceso. El proceso y el subproceso se asientan en las tablas del subsistema para que tenga una lista completa de todos los procesos y subprocesos. Luego el subsistema exhibe un cursor que contiene un puntero con un reloj de arena para indicar al usuario que est ocurriendo algo pero que puede usar el cursor mientras tanto. Cuando el proceso efecta su primera llamada de GUI, por lo regular para crear una ventana, el cursor desaparece (se vence en un plazo de dos segundos si no se emite ninguna llamada). 5. Ahora ya puede ejecutarse el subproceso. Lo primero que hace es ejecutarse un procedimiento de sistema de tiempo de ejecucin para completar la inicializacin. 6. El procedimiento de tiempo de ejecucin establece la prioridad del subproceso, indica a las DLLs cargas que hay un nuevo subproceso, y realiza otras labores de mantenimiento. Por ltimo, comienza a ejecutar el cdigo del programa principal del proceso. La creacin de subprocesos tambin comprende varios pasos, pero no entraremos en muchos pormenores. Se inicia cuando el proceso en ejecucin ejecuta CreateThread, que invoca un procedimiento contenido en kernel32.dll. Este procedimiento asigna memoria a una pila de usuario dentro del proceso invocador y luego emite la llamada NtCreateThread, para crear un objeto de subproceso del ejecutivo, asignarle valores iniciales y tambin crear y asignar valores iniciales a un bloque de control de subproceso. Una vez ms, se notifica al subsistema Win32 y se asienta el nuevo subproceso en sus tablas. Luego el subproceso comienza a ejecutarse y termina su propia inicializacin. Cuando se crea un proceso o subproceso, se devuelve un identificador para l. Este identificador puede servir para poner en marcha, parar, terminar e inspeccionar el proceso o subproceso. El dueo de un identificador puede pasrselo a otro proceso de una forma controlada y segura. Esta tcnica sirva para que los depuradores puedan tener control sobre los procesos que estn depurando. Calendarizacin Windows 2000 no tiene un subproceso calendarizador central. En vez de eso, cuando un subproceso ya no puede seguir ejecutndose, ingresa en modo de kernel y ejecuta el calendarizador l mismo para cul subproceso cambiar. Las condiciones
siguientes hacen que el subproceso que se est ejecutando en ese momento active el cdigo del calendarizador: 1. El subproceso se bloquea por un semforo, mutex, suceso, E/S, etc 2. El subproceso enva una seal a un objeto (por ejemplo, ejecuta up con un semforo). 3. El cuanto del subproceso se agota. En el caso 1, el subproceso ya se est ejecutando en modo de kernel para realizar la operacin con el despachador u objeto de E/S. Le es imposible continuar, as que debe guardar su propio contexto, ejecutar el cdigo del calendarizador para que escoja a su sucesor y cargar el contexto de ese subproceso para ponerlo en marcha. En el caso 2, el subproceso que se est ejecutando tambin est en el kernel. Sin embargo, despus de enviar la seal al objeto definitivamente puede continuar, porque el envo de seale no hace que un objeto se bloquee. De todos modos, el subproceso est obligado a ejecutar el calendarizador para ver si el resultado de su accin ha liberado un subproceso de ms alta prioridad que ahora ya est libre para ejecutarse. En tal caso, habr una conmutacin de subproceso porque Windows 2000 es expropiador en forma plena (es decir, puede haber cambios de subproceso en cualquier momento, no slo cuando termina el cuanto del subproceso actual). En el caso 3, hay un salto al modo de kernel por una interrupcin de sistema, y el subproceso ejecuta el cdigo del calendarizador para ver quin se ejecutar a continuacin. Dependiendo de qu otros subprocesos estn esperando, podra seleccionarse el mismo subproceso, en cuyo caso recibir un nuevo cuanto y seguir ejecutndose. En otro caso, habr una conmutacin de subproceso. El calendarizador tambin se invoca cuando se cumplen otras dos condiciones: 1. Termina una operacin de E/S 2. Expira un plazo de espera En el primer caso, un subproceso podra haber estado esperando esta E/S y ahora ya est listo para ejecutarse. Es preciso verificar si debe expropiarse el subproceso que se est ejecutando, ya que no se garantiza un tiempo mnimo de ejecucin. El calendarizador no se ejecuta en el manejador de interrupciones mismo (pues podra mantener desactivadas las interrupciones durante demasiado tiempo), sino que una DPC (llamada diferida a procedimiento) se pone en la cola para un momento despus, cuando
termine el manejador de interrupciones. En el segundo caso, un subproceso habr ejecutado down con un semforo o habr sido bloqueado por algn otro objeto, pero con un plazo que acaba de expirar. Una vez ms, el manejador de interrupciones tiene que poner en la cola de DPC para que ele calendarizador no se ejecute mientras se est ejecutando el manejador de interrupciones de reloj. Si el vencimiento de este plazo ha hecho que un subproceso que listo, se ejecuta el calendarizador y, si no hay algo ms importante que hacer, se ejecuta a continuacin la DPC. Ahora legamos al algoritmo de calendarizacin en s. La API Win32 proporciona dos ganchos para que los procesos influyan en la calendarizacin de subprocesos. Estos ganchos determinan en buena medida el algoritmo. En primer lugar, hay una llamada SetPriorityClass que establece la clase de prioridad de todos los subprocesos del proceso al que pertenece el subproceso que invoc al calendarizador. Los valores permitidos son: tiempo real, alta, mayor que la normal, normal, menor que la normal e inactiva. En segundo lugar, hay una llamada SetThreadPriority que establece la prioridad relativa de algn subproceso (quiz, pero no necesariamente, el subproceso invocador) en comparacin con los dems subprocesos de su proceso. Los valores permitidos son: tiempo crtico, ms alta, mayor que la normal, normal, menor que a normal, ms baja e inactiva. Con seis clases para los procesos y siete clases para los subprocesos, un subproceso puede tener cualquiera de 42 combinaciones. sta es la entrada para el algoritmo de calendarizacin. El calendarizador funciona como sigue. El sistema tiene 32 prioridades, numeradas del 0 al 31. Se establece una correspondencia entre las 42 combinaciones y las 32 clases de prioridad segn la tabla de la figura 2-18. El nmero de la tabla determina la prioridad base del subproceso. Adems, cada subproceso tiene una prioridad actual que podra ser ms alta (pero no ms baja) que la prioridad base, y de la cual hablaremos en breve. Para calendarizador funciona como sigue. El sistema tiene 32 prioridades, numeradas del 0 al 31. Se establece una correspondencia entre las 42 combinaciones y las 32 clases de prioridad segn la tabla de la figura 2-18. El nmero de la tabla determina la prioridad base del subprocesos. Adems, cada subproceso tiene una prioridad actual que podra ser ms alta (pero no ms baja) que la prioridad base, y de la cual hablaremos en breve. Para calendarizar con base en estas prioridades, el sistema mantiene un arreglo con 32 entradas, que corresponden a las prioridades o a 31 derivadas de la tabla de la figura 218. Cada entrada del arreglo apunta a la cabeza de una lista de subprocesos listos con la prioridad correspondiente. El algoritmo de calendarizacin bsico consiste en explorar el arreglo dese la prioridad 31 hasta la 0. Tan pronto como se halla una ranura no vaca, se selecciona el subproceso que est a la cabeza de la cola y se ejecuta durante un cuanto
expira, el subproceso se coloca al final de la cola correspondiente a su nivel de prioridad y a continuacin se escoge el subproceso que ahora est al frene de la cola. Dicho de otro modo, cuando hay vario subprocesos listos en el nivel de prioridad ms alto, se ejecutan por turno circular (round robin) durante un cuanto cada uno. Si ningn subproceso est listo, se ejecuta el subproceso inactivo. Prioridades de clase de procesos Win32
Tiempo real Prioridades de subprocesos Win32 Tiempo crtico Mas alta Mayor que normal Normal Menor que normal Ms baja Inactiva Alta Mayor Que normal Normal Menor Que normal Inactiva
31 26 25 24 23 22 16
15 15 13 12 11 1
15 12 11 10 9 8 1 10 9 8 7 6 1
15 8 7 6 5 4 1
15 6 5 4 3 2 1
15
Figura 2.18. Windows 2000
Correspondencia entre prioriddes de Win32 y prioridades de
Cabe sealar que la calendarizacin se efecta escogiendo un subproceso sin importar a qu proceso pertenezca. Por tanto, el calendarizador no escoge primero un proceso y luego un subproceso de ese proceso; slo examina los subprocesos. El calendarizador ni siquiera sabe cul subproceso pertenece a cul proceso. En un multiprocesador, cada CPU se calendarizar a s misma empleando el arreglo de prioridades. Se utiliza un boqueo giratorio para asegurarse de que slo una CPU est inspeccionando el arreglo en un momento dado. El arreglo de encabezados de cola se muestra enla figura 2-19. La figura muestra que en realidad hay cuatro categoras de prioridades: tiempo real, usuario, cero y espera inactiva, que de hecho es -1. Vale la pena comentar algo al respecto. Las prioridades 1631 se caracterizan como de tiempo real, pero no lo son. No se ofrecen garantas ni se cumplen plazos. Tan slo son prioridades ms altas que las 0-15. No obstante, las prioridades 16-31 se reservan para el sistema en s y para los subprocesos a los que el administrador del sistema asigna de manera explcita esas prioridades. Los usuarios ordinarios no pueden ejecutar ah por una razn de peso. Si un subproceso de usuario se ejecutara con mayor prioridad que, digamos, el subproceso del teclado o del ratn, y entrara en un ciclo, el subproceso del teclado o del ratn jams se ejecutara, y el sistema se paralizara de manera efectiva.
Los subprocesos de usuario se ejecutan con prioridades entre 1 y 15. Al establecer las prioridades de proceso y de subproceso, el usuario puede determinar cules subprocesos tienen preferencia. El subproceso cero se ejecuta en segundo plano y consume el tiempo de CPU que nadie ms quiere. Su tarea consiste en llenar de ceros las pginas que asignar el administrador de memoria. Analizaremos su papel ms adelante. Si no hay nada que hacer en absoluto, ni siquiera llenar pginas de cero, se ejecuta el subproceso inactivo, que no es en realidad un subproceso completo. Con el tiempo, se aadieron algunos parches al algoritmo de calendarizacin bsico para mejorar el desempeo del sistema. En ciertas condiciones especficas, el sistema operativo puede elevar la prioridad actual de un subproceso de usuario por encima de la prioridad base, pero nunca ms all de la prioridad 15. Puesto que el arreglo de la figura 219 se basa en la prioridad actual, un cambio en esta prioridad afecta la calendarizacin. Nunca se efectan ajustes a los subprocesos que se ejecutan con prioridad 15 o superior. Siguiente Ejecutar subproceso que se
Subproceso de pginas en ceros 0 Subproceso inactivo Figura 2.19 Windows 2000 maneja prioridades para los subprocesos En primer lugar, cuando termina una operacin de E/S y libera un subproceso que estaba en espera, la prioridad se eleva para que el subproceso tenga oportunidad de volver a ejecutarse pronto e iniciar ms operaciones de E/S. Lo que se busca aqu es mantener ocupados los dispositivos de E/S. El grado de elevacin depende del dispositivo de E/S, y suele ser 1 en el caso de un disco, 2 para una lnea en seri, 6 para el teclado y 8 para la tarjeta de sonido. En segundo lugar, si un subproceso estaba esperando un semforo, mutex u otro suceso, cuando se libere tendr una elevacin de 2 unidades si pertenece al proceso de primer plano (el proceso que controla la ventana a la que se envan las entradas del teclado) y de1 unidad en caso contrario. Este ajuste tiende a colocar los procesos interactivos por arriba de la multitud que est en el nivel 8. Por ltimo, si un subproceso de la GUI se activa porque ya estn disponibles entradas de una ventana, tiene una elevacin de su prioridad por el mismo motivo. Estas elevaciones no continan de manera indefinida. Surten efecto de inmediato, pero si un subproceso consume todo su siguiente cuanto, pierde un punto y baja a la cola en el nivel inmediato inferior del arreglo de prioridades. Si consume otro cuanto completo, baja otro nivel y as hasta llegar a su nivel base, donde permanecer hasta que tenga otra evasin. Es evidente que si un subproceso quiere recibir un buen servicio, le conviene tocar mucha msica. Existe otro caso en el que el sistema altera las prioridades. Imaginemos que dos subprocesos estn trabajando juntos en un problema tipo productor-consumidor. La labor del productor es ms ardua, as que se le asigna una prioridad alta, digamos 12, mientras que el consumidor recibe 4. En cierto momento, el productor ha saturado un bfer compartido y se bloquea por un semforo, como se ilustra en la figura 2-20. -------------------
Figura 2.20 Ejemplo e inversin de prioridad Antes de que el consumidor pueda ejecutarse otra vez, un subproceso no relacionado, con prioridad 8, queda listo y comienza a ejecutarse, como se muestra e la figura 2-20b. Mientras este subproceso quiera ejecutarse, podr hacerlo, pues tiene mayor prioridad que el consumidor y el productor est bloqueado, aunque tiene prioridad ms alta. En estas circunstancias, el productor no podr ejecutarse otra vez si no lo permite el subproceso de prioridad 8. Windows 2000 resuelve este problema de forma no muy elegante que digamos. El sistema se mantiene al tanto de cunto tiempo ha pasado desde que se ejecut por ltima vez un subproceso que est listo. Si ese tiempo excede cierto umbral, el subproceso se pasa a la prioridad 15 durante los dos cuantos. Esto podra darle oportunidad de desbloquear al productor. Una vez expirados los dos cuantos, la elevacin se cancela en forma abrupta, en lugar de bajar de manera gradual. Quiz una mejor solucin sera castigar a los subprocesos que consumen su cuanto una y otra vez, reduciendo su prioridad. Despus de todo, el problema no fue culpa del subproceso que sufra inanicin, sino del subproceso codicioso, Este problema es muy conocido y recibe el nombre de inversin de prioridad. Se presenta un problema anlogo si un subproceso con prioridad 16 se apodera de un mutex y no tiene oportunidad de ejecutarse durante mucho tiempo, impidiendo que se ejecuten subproceso de sistemas ms importantes que estn esperando ese mutex. Este problema puede prevenirse dentro del sistema operativo permitiendo que un subproceso que necesita un mutex durante un tiempo corto tan slo desactive la calendarizacin mientras lo usa. En un multiprocesador debe usarse un bloqueo giratorio. Antes de dejar el tema de la calendarizacin, vale la pena decir unas cuantas palabras acerca del cuanto. En Windows 2000 Professional el valor predeterminado es de
20 ms; en servidores uniprocesador es de 120 ms; en los multirproceadores se usan diversos valores distintos, dependiendo de la frecuenta del reloj. Un cuanto corto favorece a los usuarios interactivos, mientras que un cuanto largo reduce las conmutaciones de contexto y, por tanto, mejora la eficiencia. ste es el significado de la ltima columna de la figura 2-2. Estos valores predeterminados pueden incrementarse en forma manual en 2x, 4x o 6x si se desea. Por cierto, el tamao del cuanto se escogi hace una dcada y no ha cambiado desde entonces, a pesar de que las mquinas actuales son ms de un orden de magnitud ms veloces. Es probable que las cifras pudieran reducir en un factor de 5 a 10 sin perjuicio y tal vez mejorara el tiempo de respuesta de los subprocesos interactivos en un sistema muy cargado. Un ltimo parche aplicado al algoritmo de calendarizacin hace que, si una ventana nueva se convierte en la ventana de primer plano, el cuanto de todo sus subprocesos aumente en una cantidad que se toma del Registro. Este cambio le otorga ms tiempo de CPU, que por lo regular se traduce en un mejor servicio para la ventana que acaba de pasar al primero plano. 2.4.4 Emulacin de MS-DOS Una de las metas de diseo de Windows 2000 se hered de NT: tratar de ejecutar tantos programas MS-DOS razonables como fuera posible. Esta meta es muy diferente de la explicita Windows 98: ejecutar toros los programas MS-DOS antiguos (a lo que aadimos: aunque tengan muy mal comportamiento). La forma en que Windows 2000 maneja programas antiguos es ejecutndolos en un entorno protegido en forma plena. Cuando se inicia un programa MS-DOS, se inicia un procesos Win32 normal y se carga con un problema de emulacin de MS- DOS, ntvdm (mquina virtual DOS de NT; NT virutal DOS machine) que vigila el programa MS-DOS y ejecuta sus llamadas al sistema. Puesto que MS-DOS slo reconoca memoria de hasta 1MB en el 8088 y slo hasta 16 MB con conmutacin de bancos y otros trucos en el 286, no hay problema si se coloca ntvdm en la parte alta de espacio de direcciones virtual del proceso donde el programa no tiene forma de direccionarlo. Esta situacin se muestra en la figura 2-21.
Figura 2.21 como se ejecutan programas MS-DOS antiguos bajo Windows 2000 Cuando el programa MS-DOS se limita a ejecutar instrucciones normales, puede operar el hardware desnudo, ya que el Pentium incluye toda la instrucciones de 8088 y 286 como subconjuntos. La parte interesante es qu sucede cuando el programa MS-DOS quiere efectuar E/S o interactuar con el sistema. Un programa bien comportado tan slo emite una llamada al sistema. Previendo esto, ntvdm ordena a Windows 2000 reflejar hacia l todas las llamadas al sistema de MS-DOS. En efecto, la llamada al sistema tan slo rebota el sistema operativo y es atrapada por el emulador, como se muestra en los pasos 1 y 2 de la figura 2-21. Esta tcnica se conoce como uso de trampoln. Cuando el emulador obtiene el control, determina qu estaba tratando de hacer el programa y emite sus propias llamadas Win32 para efectuar el trabajo (pasos 3 y 4 de la figura 2-21). Mientras el programa se porte bien y slo emita llamadas MS-DOS vlidas al sistema, esta tcnica funciona bien. El problema es que algunos programas MS-DOS antiguos pasaban por alto el sistema operativo y escriban en forma directa en la RAM de vdeo, lean directo el teclado, etctera, cosas que son imposibles en un entorno protegido. En la medida en que el comportamiento indebido causa una interrupcin de sistema, hay cierta esperanza de que el emulador pueda dilucidar lo que el programa estaba tratando de hacer y lo emule. Si no entiende lo que el programa quiere, tan slo lo termina porque una emulacin de 100% no era un requisito de Windows 2000.
2.4.5
Arranque de Windows 2000
Para que Windows 2000 pueda ponerse en marcha, necesita arrancar. El proceso de arranque (boot) crea los procesos iniciales que ponen el sistema en memoria. El proceso de arranque en hardware consiste en leer el primer sector del primer disco (el registro de arranque maestro) y saltar a l. Este corto programa en lenguaje ensamblador lee la tabla de particiones para ver cul contiene el sistema operativo arrancable. Cuando encuentra la particin del sistema operativo, lee su primer sector, llamado sector de arranque, y salta a l. El programa del sector de arranque lee el directorio raz de su particin y busca en l un archivo llamado ntldr (otro indicio arqueolgico de que Windows 2000 es en realidad NT). Si encuentra ese archivo, lo lee y lo ejecuta. Ntldr carga Windows 2000. Por cierto, hay varias versiones del sector de arranque, dependiendo de si la particin tiene formato de FAT-16, FAT-32, o NTFS. Cuando se instala Windows 2000, se escribe en el disco la versin correcta del registro de arranque maestro y del sector de arranque. Ahora ntldr lee un archivo llamado Boot.ini, que contiene la nica informacin de configuracin que uno est en el Registro. Aqu aparece una lista de todas las versiones de hal.dll y ntoskrnl.exe con que se cuenta para arrancar en esta particin. El archivo tambin proporciona muchos parmetros, como el nmero de CPU y cunta RAM usar, si debe darse a los procesos de usuario 2 3 GB, y a qu ritmo operar el reloj de tiempo real. Luego ntldr selecciona y carga los archivos hal.dll y ntoskrnl.exe as como bootvid.dll, el controlador de vdeo predeterminado para escribir en la pantalla durante el proceso de arranque. Ahora ntldr lee el Registro para averiguar los controladores que se necesitan para completar el arranque (por ejemplo, los controladores de teclado y de ratn, y docenas ms para controlar diversos chips de la tarjeta matriz). Por ltimo, se leen todos estos controladores y se transfiere el control a ntoskrnl.exe. Una vez iniciado, el sistema operativo asigna algunos valores iniciales generales y luego invoca los componentes del ejecutivo para que realicen su propia asignacin de valores iniciales. Por ejemplo, el administrador de objetos prepara su espacio de nombra para que otros componentes puedan invocarlo e insertar sus objetos prepara su espacio de nombres para que otros componentes puedan invocarlo e insertar su objetos en dicho espacio. Muchos otros componentes realizan tareas especficas relacionadas con su funcin, como el administrador de memoria que establece las tablas de pginas iniciales y el administrador de Plug-and-Play que averigua cules dispositivos de E/S estn presentes y carga sus controladores. En total, se efectan docenas de pasos, durante los cuales la barra de avance que se exhibe en la pantalla se va llenando cada vez que termina un paso. El ltimo paso es la creacin del primer proceso de usuario verdadero, el administrador de sesin, smss.exe. Cuando ya est operando este proceso, ha terminado el arranque. El administracin de sesin es un proceso original de Windows 2000. Emite verdaderas llamadas al sistema y no usa el subsistema de entorno Win32, que ni siquiera
est operando todava. De hecho, una de sus primeras tareas es iniciarlo (csrss.exe). Tambin lee los subrboles del Registro del disco y averigua qu otras cosas debe hacer. Por lo regular su labor incluye introducir muchos objetos en el espacio de nombres del administrador de objetos, crear los archivos de paginacin adicional que se necesiten, y abrir DLLs importantes para que estn presentes todo el tiempo. Una vez realizado casi todo esto, crea el demonio de inicio d sesin, winlogon.exe. En este punto, el sistema operativo ya est funcionando en forma cabal. Es el momento de poner enmarca los procesos de servicio (demonios en espacio de usuario) y permitir que los usuarios inicien sesin. Winlogon.exe primero crea el administrador de validacin (lsass.exe) y luego el proceso padre de todos los servicios (services.exe). Este ltimo consulta el Registro APRA averiguar cules procesos demonio en espacio de usuario se necesitan y en qu archivos estn, y luego comienza a crearlos. Esos procesos se muestran en la figura 2-7. El hecho de que el disco, por lo general, est sometido a uso intensivo inmediatamente despus de que el primer usuario ha iniciado sesin (pero antes de que haga algo) no es culpa del usuario. El culpable es services.exe, que est creando todos los servicios. Adems, este programa carga los controladores de dispositivos que todava no se hayan cargado. Winlogon.exe tambin se encarga de todos los inicios de sesin de usuarios. El cuadro de dilogo de inicio de sesin propiamente dicho corre por cuenta de un programa aparte que est en msgina.dll; esto se hizo para que terceros pudieran sustituir el inicio de sesin estndar por identificacin de rostros o algn otro mecanismo distinto del nombre y contrasea. Despus de un inicio de sesin con xito, winlogon.exe obtiene del Registro el perfil del usuario y a partir de l determina cul shell debe ejecutar. Muchas personas no se dan cuenta de ello, pero el escritorio estndar de Windows no es ms que Explorer.exe con algunas opciones establecidas. Si lo desea, el usuario puede seleccionar cualquier otro programa como shel, incluido el indicador de comandos o incluso Word, editando el Registro. Sin embargo, editar el Registro no es para los principiantes; un error puede dejar inutilizado el sistema.

UNIDAD II Lab Oratorio Sistema Operativo

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UNIDAD II Lab Oratorio Sistema Operativo

Uploaded by

Copyright:

Available Formats

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

UNIDAD II : HISTORIA DE WINDOWS 2000 INTRODUCCIN

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar

Laboratorio Sistemas Operativos Vctor Crdenas Villacura, Ao 2010 e-mail:victor.cardenas@udelmar.cl

Carreras Pregrado Campus Global Universidad del Mar