Sistemas operativos modernos

encarga de administrar imágenes para el monitor y las impresoras. Ofrece llamadas al sistema que permiten a los programas de usuario escribir en el monitor y en las impresoras en forma in­ dependiente del dispositivo. También contiene el administrador de ventanas y el controlador de pantalla. Antes de NT 4.0, este componente también estaba en espacio de usuario, pero su de­ sempeño era decepcionante, así que Microsoft lo pasó al kemel para acelerarlo. Vale la pena mencionar que la figura 11-7 no está en absoluto dibujada a escala. Por ejemplo, el módulo de interfaz Win32 y de dispositivos gráficos es más grande que el resto del ejecufivo combinado. En la parte más alta del ejecutivo está una capa delgada llamada servicios del sistema. Su función 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 colección de archivos. La parte principal del sistema operativo, que consta del kemel y ejecu­ fivo, está en el archivo ntoskml.exe. HAL es una biblioteca compartida situada en otro archi­ vo, haidll. Win32 y la interfaz de dispositivos gráficos están juntas en un tercer archivo, win32k.sys. Por último, también se cargan muchos controladores de dispositivos. Casi todos tienen la extensión En realidad, las cosas no son tan sencillas. El archivo ntoskml.exe viene en dos versiones, uniprocesador y mulfiprocesador. También hay versiones para el procesador Xeon, que puede tener más de 4 GB de memoria física, y el Pentium, que no puede. Por úlfimo, las versiones pueden consistir en una compilación libre (que se vende en fiendas y la preinstalan los fabri­ cantes de computadoras) o una compilación verificada (para fines de depuración). En total po­ dría haber ocho combinaciones, aunque dos pares se combinaron, con lo que sólo quedan seis. Una de éstas se copia en ntoskml.exe cuando se instala el sistema. Vale la pena hablar un poco de las compilaciones verificadas. Cuando se instala un dispo­ sitivo 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 compu­ tadora y al parecer funciona bien. Dos semanas después el sistema falla de pronto. ¿A quién culpa el dueño? A Microsoft. El error de programación sí podría ser de Microsoft, pero algunos se deben en realidad a con­ troladores defectuosos, sobre los cuales Microsoft no tiene ningún control y que se instalan en la memoria del kemel con pleno acceso a todas sus tablas, así como a todo el hardware. En un in­ tento por reducir el número de clientes iracundos que llaman por teléfono, Microsoft trata de ayu­ dar a quienes crean los controladores a depurar su código colocando instrucciones de la forma A SSERT (a lguna condición) por todo el código. Estas instrucciones verifican que todos los parámetros sean congruentes con los procedimientos internos del kemel (que pueden ser invocados libremente por los controla­ dores) y efectúan además muchas otras verificaciones. En las compilaciones libres ASSERT es­ tá definido como una macro que no hace nada, con lo que elimina todas las verificaciones. En las compilaciones verificadas ASSERT está definido como #define A S S E R T {a ) if (! (a)) error(... )