Windows NT

1.6.1 Arquitectura

Windows NT presenta una arquitectura del tipo cliente-servidor. Los programas de
aplicación son contemplados por el sistema operativo como si fueran clientes a los
que hay que servir, y para lo cual viene equipado con distintas entidades
servidoras uno de los objetivos fundamentales de diseño fue el tener un núcleo tan
pequeño como fuera posible, en el que estuvieran integrados módulos que dieran
respuesta a aquellas llamadas al sistema que necesariamente se tuvieran que
ejecutar en modo privilegiado (también llamado modo kernel, modo núcleo y modo
supervisor). El resto de las llamadas se expulsarían del núcleo hacia otras
entidades que se ejecutarían en modo no privilegiado (modo usuario), y de esta
manera el núcleo resultaría una base compacta, robusta y estable. Por eso se dice
que Windows NT es un sistema operativo basado en micro-kernel.

En la arquitectura se distingue un núcleo que se ejecuta en modo privilegiado, y se
denomina Executive, y unos módulos que se ejecutan en modo no privilegiado,
llamados subsistemas protegidos.

Los programas de usuario (también llamados programas de aplicación)
interaccionan con cualquier sistema operativo (S.O. en adelante) a través de un
juego de llamadas al sistema propio de dicho sistema. En el mundo Windows en
general, las llamadas al sistema se denominan API (Application Programming
Interfaces, interfaces para la programación de aplicaciones).

El núcleo se ejecuta en modo privilegiado (Executive) y en modo no privilegiado
(subsistemas protegidos).

Los subsistemas protegidos

Son una serie de procesos servidores que se ejecutan en modo no privilegiado, al
igual que los procesos de usuario, pero que tienen algunas características propias
que los hacen distintos.

Se inician al arrancar el S.O. y existen dos tipos: integrales y de entorno.

Un subsistema integral es aquel servidor que ejecuta una función crítica del S.O.
(como por ejemplo el que gestiona la seguridad). Un subsistema de entorno da
soporte a aplicaciones procedentes de S.O. distintos, adaptándolas para su
ejecución bajo Windows NT. Existen tres de este tipo:

  • Win32, que es el principal, y proporciona la interfaz para aplicaciones
    específicamente construidas para Windows NT.
  • POSIX, que soporta aplicaciones UNIX.
  • OS/2, que da el entorno a aplicaciones procedentes del S.O. del mismo
    nombre.

El subsistema Win32. Es el más importante, ya que atiende no sólo a las
aplicaciones nativas de Windows NT, sino que para aquellos programas no Win32,
reconoce su tipo y los lanza hacia el subsistema correspondiente. En el caso de
lo que hace es crear un nuevo subsistema protegido. Así, la aplicación DOS o
Win16 se ejecutaría en el contexto de un proceso llamado VDM (Virtual DOS
Machine, máquina virtual DOS), que no es más que un simulador de un ordenador
funcionando bajo MS-DOS. Las llamadas al API Win16 serían correspondidas con
las homónimas en API Win32. Microsoft llama a esto WOW (Windows On Win32).

El subsistema soporta una buena parte del API Win32. Así, se encarga de todo lo
relacionado con la interfaz gráfica con el usuario (GUI), controlando las entradas
del usuario y salidas de la aplicación.

El subsistema POSIX. La norma POSIX (Portable Operating System Interface for
UNIX) fue elaborada por IEEE para conseguir la portabilidad de las aplicaciones
entre distintos entornos Windows NT,UNIX, VMS, etc. Se trata de un conjunto de
23 normas, identificadas como IEEE 1003.0 a IEEE 1003.22, o también POSIX.0 a
POSIX.22, de las cuales el subsistema POSIX soporta la POSIX.1, que define un
conjunto de llamadas al sistema en lenguaje C. El subsistema sirve las llamadas
interaccionando con el Executive.

El subsistema OS/2. Igual que el subsistema POSIX proporciona un entorno para
aplicaciones UNIX, este subsistema da soporte a las aplicaciones del S.O. OS/2.
Proporciona la interfaz gráfica y las llamadas al sistema; las llamadas son servidas
con ayuda del Executive.

El subsistema proceso de inicio. El proceso de inicio (Logon Process) recibe las
peticiones de conexión por parte de los usuarios. En realidad son dos procesos,
cada uno encargándose de un tipo distinto de conexión: el proceso de inicio local,
que gestiona la conexión de usuarios locales directamente a una máquina
Windows NT; y el proceso de inicio remoto, el cual gestiona la conexión de
usuarios remotos a procesos servidores de NT.

El subsistema de seguridad. Este subsistema interacciona con el proceso de
inicio y el llamado monitor de referencias de seguridad, de esta forma se construye
el modelo de seguridad en Windows NT. El subsistema de seguridad interacciona
con el proceso de inicio, atendiendo las peticiones de acceso al sistema. Consta
de dos subcomponentes: la autoridad de seguridad local y el administrador de
cuentas.

El primero es el corazón del subsistema de seguridad, en general gestiona la
política de seguridad local, así, se encarga de generar los permisos de acceso, de
comprobar que el usuario que solicita conexión tiene acceso al sistema, de
verificar todos los accesos sobre los objetos (para lo cual se ayuda del monitor de
referencias a seguridad) y de controlar la política de auditorías, llevando la cuenta
de los mensajes de auditoría generados por el monitor de referencias. El
administrador de cuentas mantiene una base de datos con las cuentas de todos
los usuarios (login, claves, identificaciones, etc.).

El Executive. No debemos confundir el Executive con el núcleo de Windows NT,
aunque muchas veces se usan (incorrectamente) como sinónimos. El Executive
consta de una serie de componentes software, que se ejecutan en modo
privilegiado, uno de los cuales es el núcleo. Dichos componentes son totalmente
independientes entre sí, y se comunican a través de interfaces bien definidas. En
el diseño se procuró dejar el núcleo tan pequeño como fuera posible y, su
funcionalidad es mínima.

El administrador de objetos (Object Manager). Se encarga de crear, destruir y
gestionar todos los objetos del Executive. Se tiene infinidad de objetos: procesos,
subprocesos, ficheros, segmentos de memoria compartida, semáforos, mutex,
sucesos, etc. Los subsistemas de entorno (Win32, OS/2 y POSIX) también tienen
sus propios objetos. Por ejemplo, un objeto ventana es creado (con ayuda del
administrador de objetos) y gestionado por el subsistema Win32. La razón de no
incluir la gestión de ese objeto en el Executive es que una ventana sólo es innata
de las aplicaciones Windows, y no de las aplicaciones UNIX o OS/2. Por tanto, el
Executive no se encarga de administrar los objetos relacionados con el entorno de
cada S.O. concreto, sino de los objetos comunes a los tres.

El administrador de procesos (Process Manager). Se encarga (en colaboración
con el administrador de objetos) de crear, destruir y gestionar los procesos y
subprocesos. Una de sus funciones es la de repartir el tiempo de CPU entre los
distintos subprocesos. Suministra sólo las relaciones más básicas entre procesos
y subprocesos, dejando el resto de las interrelaciones entre ellos a cada
subsistema protegido concreto. Por ejemplo, en el entorno POSIX existe una
relación filial entre los procesos que no existe en Win32, de manera que se
constituye una jerarquía de procesos. Como esto sólo es específico de ese
subsistema, el administrador de objetos no se entromete en ese trabajo y lo deja
en manos del subsistema.

El administrador de memoria virtual (Virtual Memory Manager). Windows NT y
UNIX implementan un direccionamiento lineal de 32 bits y memoria virtual
paginada bajo demanda. El VMM se encarga de todo lo relacionado con la política
de gestión de la memoria. Determina los conjuntos de trabajo de cada proceso,
mantiene un conjunto de páginas libres, elige páginas víctima, sube y baja páginas
entre la memoria RAM y el archivo de intercambio en disco, etc.

El administrador de entrada salida (I/O Manager). Consta de varios
subcomponentes: el administrador del sistema de ficheros, el servidor de red, el
redirector de red, los drivers de dispositivo del sistema y el administrador de
cachés. Buena parte de su trabajo es la gestión de la comunicación entre los
distintos drivers de dispositivo, para lo cual implementa una interfaz bien definida
que permite el tratamiento de todos los drivers de una manera homogénea, sin
preocuparse del funcionamiento específico de cada uno. Trabaja en conjunción
con otros componentes del Executive, sobre todo con el VMM. Le proporciona la
E/S síncrona y asíncrona, la E/S a archivos asignados en memoria y las caches de
los ficheros. El administrador de caches no se limita a gestionar unos cuantos
buffers de tamaño fijo para cada fichero abierto, sino que es capaz de estudiar las
estadísticas sobre la carga del sistema y variar dinámicamente esos tamaños de
acuerdo con la carga. El VMM realiza algo parecido en su trabajo.

El monitor de referencias a seguridad. Este componente da soporte en modo
privilegiado al subsistema de seguridad, con el que interacciona. Su misión es
actuar de alguna manera como supervisor de accesos, ya que comprueba si un
proceso determinado tiene permisos para acceder a un objeto determinado, y
monitoriza sus acciones sobre dicho objeto. De esta manera es capaz de generar
los mensajes de auditorías. Soporta las validaciones de acceso que realiza el
subsistema de seguridad local.

El núcleo (Kernel). Situado en el corazón de Windows NT, se trata de un microkernel
que se encarga de las funciones más básicas de todo el sistema operativo:
ejecución de subprocesos, sincronización multiprocesador, manejo de las
interrupciones hardware.

El nivel de abstracción de hardware (HAL). Es una capa de software incluida en
el Executive que sirve de interfaz entre los distintos drivers de dispositivo y el resto
del sistema operativo. Con el HAL, los dispositivos se presentan al S.O. como un
conjunto homogéneo con el cual interacciona a través de un conjunto de funciones
bien definidas. Estas funciones son llamadas tanto desde el S.O. como desde los
propios drivers. Permite a los drivers de dispositivo adaptarse a distintas
arquitecturas de E/S sin tener que ser modificados en gran medida. Además oculta
los detalles hardware que conlleva el multiprocesamiento simétrico de los niveles
superiores del S.O.

Llamadas a procedimientos locales y remotos. Windows NT, al tener una
arquitectura cliente-servidor, implementa el mecanismo de llamada a
procedimiento remoto (RPC) como medio de comunicación entre procesos clientes
y servidores, situados ambos en máquinas distintas de la misma red. Para clientes
y servidores dentro de la misma máquina, la RPC toma la forma de llamada a
procedimiento local (LPC).

Llamada a Procedimiento Remoto (Remote Procedure Call -RPC). Se puede
decir que el sueño de los diseñadores de Windows NT es que algún día se
convierta en un sistema distribuido puro, es decir, que cualquiera de sus
componentes pueda residir en máquinas distintas, siendo el kernel en cada
máquina el coordinador general de mensajes entre los distintos componentes. En
la última versión de Windows NT esto no es aún posible. No obstante, el
mecanismo de RPC permite a un proceso cliente acceder a una función situada en
el espacio virtual de direcciones de otro proceso servidor situado en otra máquina
de una manera totalmente transparente. Vamos a explicar el proceso en conjunto.

Llamada a procedimiento local (Local Procedure Call –LPC. Se usan cuando
un proceso necesita los servicios de algún subsistema protegido, típicamente
Win32. El subsistema Win32 va guardando en su propio espacio de direcciones
una lista con todos los objetos que le van pidiendo los procesos. Por consiguiente,
los procesos no tienen acceso a la memoria donde están los objetos; simplemente
obtienen un descriptor para trabajar con ellos.

 

Fuente:

MÓDULO
SISTEMAS OPERATIVOS
Primera Edición
Autor: Pilar Alexandra Moreno
Universidad Nacional Abierta y a Distancia