Arquitectura dell So Windows NT (página 2)

5. Administracion De La Memoria

La parte de Windows NT que
soporta la gestión
de la memoria se
denomina Gestor de Máquina Virtual (VMM), y reside en el
Executive, por encima del núcleo pero ejecutándose
en modo supervisor, como vimos en la introducción.

En Windows NT se
utiliza memoria
virtual paginada. En algunas máquinas,
como las CPU Intel 386
en adelante, combina paginación con segmentación. El tamaño de la
página depende de la máquina. En la CPU anterior
es de 4 Kb.

Espacio de Direcciones de un Proceso

Todo proceso que se
crea en Windows NT
posee un espacio de direcciones virtuales de 4 Gb exclusivos de
él. Ningún otro podrá acceder a esas
direcciones, sencillamente porque ¡no las ve!. Para un
proceso, todo
lo que ve es suyo, y ve virtualmente 4 Gb. Los 2 Gb superiores
están reservados al SO, así como los 64 Kb primeros
y los 64 Kb últimos de los 2 Gb inferiores. El resto de
los 2 Gb inferiores son para uso del proceso. Distinguimos varias
zonas:

Direcciones para las DLL del sistema (NTDLL,
KERNEL32, USER32, GDI32 …).

Direcciones para las DLL propias de la
aplicación.

Bloques y pilas de los
subprocesos.

Imagen del archivo
ejecutable: código,
datos,
cabecera, información del depurador y tabla de
activación imagen.

Además, cada proceso posee su propia tabla de
implantación de páginas (TIP), a dos niveles. El
objetivo de
esa tabla (también llamada tabla de traducción) es,
dada una dirección virtual, devolver su dirección física asociada. A
veces la dirección virtual no tiene correspondencia en
memoria
física.
Entonces se dice que se ha producido un fallo o defecto de
página (page fault). En el siguiente apartado vamos a
describir cómo funciona el VMM y qué hace cuando se
dan los fallos de página.

Funcionamiento del VMM

Cada proceso tiene asignado un número que indica el
máximo de páginas físicas que se le pueden
conceder. Dicho número es ajustado por el llamado gestor
del conjunto de trabajo, del que luego hablaremos. Además,
cada proceso lleva asociada una lista que contiene referencias a
las páginas físicas a las que se ha accedido menos
últimamente.

Cuando el proceso accede a una dirección que no
tiene dirección física asociada en la TIP, se
produce un fallo de página. Entonces, el VMM consulta el
número de páginas que el proceso tiene asignadas.
Si no ha llegado al límite, se le concede una nueva
página física y se escribe con la correspondiente
desde el disco. Esto se denomina paginación bajo demanda. Si
por el contrario ya había llegado al límite,
entonces hay que descargar una página física al
disco para subir a memoria la que
ocasionó el fallo. El VMM elige la página
víctima de la lista de menos recientemente usadas del
proceso.

Nótese que aunque existan páginas libres en
la memoria, si
el proceso agota su número de páginas asignadas, se
producirá el swapping, y además de una de sus
propias páginas. Este mecanismo puede parecer
ilógico, pero presenta tanto ventajas como inconvenientes.
Como problema puede nombrar por ejemplo, que si un proceso
estuviera gran parte del tiempo dormido
(en espera de un suceso o de una E/S), dicho proceso
estaría ocupando páginas físicas que de otro
modo podrían ser descargadas. Como ventaja tenemos que,
con este esquema, procesos que
requieran muchos recursos no
dejarán fuera de juego a
aquellos cuya demanda de
memoria sea escasa. No obstante, el problema planteado es paliado
(al menos en gran medida) por una parte del VMM llamada gestor
del conjunto de trabajo. Realiza dos funciones
fundamentales:

Por un lado, periódicamente revisa las estadísticas sobre el uso de la CPU por
cada proceso. Siguiendo este criterio, procede a ajustar el
número que indica el máximo de páginas
físicas asociadas a cada uno. A aquellos procesos con
poca actividad se les bajará el número (lo que
acarreará un descargue de sus páginas
físicas, si las tiene, cuando sean necesarias), y a
aquellos con mucha carga se les subirá el
número.

Por otro lado, y también de forma periódica,
roba a los procesos páginas físicas, elegidas de
entre las menos recientemente usadas por cada uno. Este procedimiento se
reliza a la frecuencia necesaria para que los procesos no se
ralenticen demasiado por los fallos de página. El objetivo de
esto es mantener una reserva de páginas para que una
repentina demanda no ocasione una caída en prestaciones
del sistema completo.
Por ejemplo, cuando se inicia un proceso nuevo se suele requerir
una cantidad considerable de páginas.

Para llevar a cabo estas tareas, las páginas
físicas se clasifican en una de cuatro listas que son
mantenidos por el gestor del conjunto de trabajo:

• lista de páginas modificadas
• lista de páginas no activas
• lista de páginas liberadas
• lista de páginas a cero

Cada página que el gestor roba a un proceso es
borrada su lista de menos recientemente usadas e incluida en la
lista de modificadas (y las entradas correspondientes de la TIP
marcadas como no válidas, de forma que se produzca fallo
de página al acceder el proceso a dichas direcciones).
Dicha lista contiene páginas robadas que aún
están en memoria RAM pero
que no han sido escritas a disco (al archivo de
paginación). Cuando se produzca un fallo de página,
si la dirección física correspondiente estuviera en
una de estas páginas, simplemente se volvería a
insertar en la lista del proceso y se ajustaría su
TIP.

Cuando la lista de modificadas se hace suficientemente
grande, otra parte del VMM (el escritor de páginas) copia
algunas páginas de la lista al archivo de
paginación, las borra de la lista de modificadas y las
añade a la lista de inactivas. Ahí están las
páginas que han sido robadas, que están en RAM y
además en el archivo de paginación. El tratamiento
de un fallo de página aquí también
sería muy rápido y simple.

Cuando un proceso libera memoria, sus páginas
físicas asociadas se añaden a la lista de
liberadas. Son, por tanto, potencialmente utilizables sin
necesidad de escribirlas en el fichero de swapping pero su
contenido no ha sido borrado (están tal y como las
dejó el proceso propietario). Periódicamente, estas
páginas van siendo inicializadas con ceros,y
añadidas a la lista de páginas a cero. El mecanismo
de inicialización es para proteger la intimidad del
antiguo proceso propietario. Cualquier página que se
entrega a un proceso ha de haber sido convenientemente
inicializada.

Cuando un proceso requiere memoria física, el VMM
comienza cogiendo páginas de la lista de inicializadas.
Cuando está vacía, toma de la lista de liberadas, y
las inicializa. Cuando ésta se vacía, toma de la
lista de inactivas, y las inicializa. Sólo como
última opción recurre a las modificadas. Estas
últimas requieren escritura en
el archivo de paginación junto con inicialización,
lo cual es un proceso lento.

En ambientes en los que la memoria es escasa, el gestor del
conjunto de trabajo se centra en mantener un conjunto aceptable
de páginas disponibles, más que en revisar las
estadísticas de uso de la CPU.

Como valores
aproximativos, podemos señalar que si el número de
páginas a cero más las liberadas más las
inactivas suman menos de 20, el gestor robará
páginas a procesos que comparten la CPU. Si el
número de modificadas supera las 30, procederá a
descargar algunas a disco, pasándolas a inactivas.

Archivos Asignados en Memoria

Estudiemos ahora cómo el SO utiliza esta facilidad
para cargar el código
de un ejecutable y sus bibliotecas DLL
asociadas.

Un archivo asignado en memoria es todo aquel archivo para
el que se ha reservado una región del espacio de
direcciones virtuales de un proceso. Puede estar asignado el
archivo completo o sólo una porción del mismo
(llamada vista).

En principio, el VMM no asigna ninguna página
física para el archivo asignado en memoria. El proceso
simplemente supone que en ciertas direcciones de su espacio tiene
cargado el fichero, así que cuando acceda a alguna se
producirá un fallo de página. Es entonces cuando el
VMM le asigna algunas páginas físicas y las copia
desde el disco (paginación bajo demanda, como
comentábamos antes).

La gestión
del VMM de los archivos
asignados en memoria es como cualquier otra región del
espacio direccionable del proceso, excepto que el swapping se
hace directamente sobre el archivo (o sea, el archivo de
intercambio es el propio archivo asignado en memoria).

Cuando se arranca un proceso con su código grabado
en un fichero, el VMM asigna automáticamente dicho fichero
en el espacio de direcciones del proceso. También asigna
todas las bibliotecas
incluidas explícitamente y todas aquellas a las que se
hace referencia en el código. Dentro del ejecutable existe
una tabla llamada tabla de activación imagen, incluida
por el enlazador, cuyas entradas contienen las funciones de
biblioteca que se
llaman durante el código. Una vez que se cargan las DLL
(bibliotecas) en el espacio, el VMM completa la tabla escribiendo
para cada entrada la dirección que ocupa la
correspondiente función en
el espacio del proceso. Por tanto, cada llamada a función
implica una búsqueda en la tabla.

Supongamos ahora que se arranca una segunda instancia del
mismo proceso. Entonces el VMM pagina en

el espacio de direcciones del nuevo proceso el fichero y
las DLL, pero no vuelve a asignar páginas físicas,
sino que ambas instancias comparten todo, al menos en principio.
La ventaja de esto es ahorrar memoria, pero el inconveniente
más claro es que si uno de los procesos modificara, por
ejemplo, alguna variable global de su segmento de datos, el otro la
tendría igualmente modificada. Esto ocurre evidentemente
también él la pila e incluso en el mismo
código (por ejemplo al ejecutar un depurador sobre una de
las instancias para meter puntos de ruptura, se
modificaría el código, lo cual implicaría
que en la otra también).

Para solucionar el problema, Windows NT (y
también UNIX) tiene una
propiedad
denominada "copiar antes de escribir". El VMM intercepta
cualquier instrucción de escritura en
el archivo mapeado en memoria por parte de las instancias. Cuando
ocurre, asigna una o varias páginas físicas para la
instancia escritora, y copia los contenidos de las páginas
originales en las nuevas. A partir de ahora, esa instancia posee
su propia región del archivo para modificar a su antojo.
Análogamente para datos y pila.

UNIX también trabaja así, aunque duplica las
zonas de datos y pila por defecto, de forma que múltiples
instancias comparten, en principio, sólo el
código.

Con respecto a la tabla de activación imagen, decir
que el VMM asigna las DLL por defecto en direcciones fijas dentro
del espacio de direcciones del proceso. Así,
múltiples instancias del mismo pueden compartir la misma
tabla. No obstante, un proceso puede especificar la
dirección base de cada DLL; en ese caso, el proceso
tendría su propia tabla en memoria, con lo que resulta
más eficiente que todos los procesos tengan las DLL
asignadas en las mismas direcciones.

Desde el punto de vista del programador, se pueden asignar
en memoria archivos de hasta
264 bytes usando vistas del archivo.

El archivo se abre con CreateFile. Los primero es crear un
objeto de asignación de archivo para él, con la
función CreateFileMapping indicando el tamaño real
del archivo. Después podemos definir diferentes vistas,
con CreateViewOfFile. La vista se abandona con UnmapViewOfFile (y
fueza al VMM a escribir las modificaciones en disco).

Los archivos asignados en memoria son el único
mecanismo de compartición de datos entre procesos. Existe
un archivo que crea el objeto de asignación, y el resto de
los procesos usarán el mismo objeto referenciado por la
función OpenFileMapping. Si como descriptor de archivo se
pasa a las funciones 0xFFFFFFFF, entonces el VMM usará el
archivo de paginación como medio de compartición de
datos.

En una red no es
posible usar este mecanismo de compartición de datos, pues
el SO no garantiza la coherencia de los mismos. Por ejemplo, una
CPU en un ordenador podría modificar el archivo en disco y
otra en otro distinto tenerlo en memoria, con lo cual no se
percataría de la actualización.

Uso de Memoria
Virtual por parte del Programador

Vamos a ofrecer unas pinceladas sobre cómo el
programador puede hacer uso explícito del mecanismo de la
memoria virtual, y así hacer aplicaciones más
eficientes. Se trata sin duda de una forma elegante de programar,
ya que permite situar objetos de grandes dimensiones en el
espacio de direcciones del proceso, cuyo tamaño real se
desconoce al tiempo de
compilación. Por ejemplo, una hoja de
cálculo.

Consiste en dos etapas: la reserva y la
asignación.

La reserva no es más que indicar al SO que una
región del espacio de direcciones del proceso se va a
destinar a un determinado objeto u objetos. Por tanto no hay
ninguna correspondencia con memoria física. El VMM toma
nota en un VAD (Virtual Address Descriptor) de la
dirección de inicio, número de bytes reservados, y
protección de la zona (en efecto, las páginas
pueden tener permisos de lectura,
lectura/escritura, o ninguno). Si el proceso
accede a una de estas direcciones, se elevará una
excepción. La reserva se hace siempre por trozos de 64
Kb.

La asignación consiste en hacer corresponder toda o
parte de la memoria antes reservada con memoria física. No
obstante, el VMM no va a asignar memoria física
inmediatamente, sino que simplemente actualizará el VAD
para permitir que esa memoria sea ahora accesible, y se
asegurará que en el archivo de paginación haya
espacio suficiente. Cuando el proceso haga un acceso, se
producirá un fallo de página, y es en ese momento
cuando el VMM asignará páginas físicas (para
la página que produzca el fallo y las vecinas) y
actualizará la TIP del proceso.

El problema de usar memoria virtual explícitamente
es que el programador debe llevar una lista de la memoria que ha
asignado de entre la que ha reservado. Otra solución es
instalar un manejador de excepciones, de manera que al acceder a
una dirección reservada pero no asignada se eleve una
excepción. El manejador de esa excepción
hará la asignación y se continuará la
ejecución.

Para reservar memoria se llama a la función
VirtualAlloc pasándole el indicador MEM_RESERVE, y para
asignar, pasándole MEM_COMMIT.

La memoria reservada o asignada se puede liberar con
VirtualFree, pero entonces ha de liberarse por completo.

Con VirtualLock indicamos al VMM que no descargue una
determinada página a disco cuando el proceso esté
ejecutándose (aunque cuando no se ejecute perdamos el
control).

Por último señalar que existen funciones del
API Win32 que permiten verificar si una dirección virtual
tiene correspondencia física o no.

Bloques (heaps)

Los bloques de memoria son muy útiles cuando el
programador no necesita usar memoria virtual
explícitamente. Podemos tener estructuras de
datos distintas en bloques distintos de memoria, de manera que un
fallo en la manipulación de estructuras de
un tipo no repercuta en las demás.

Además, de este modo se gestionaría más
eficientemente la memoria, ya que al borrar estructuras y
escribir otras no se provocaría fragmentación
interna dentro del bloque (al ser todas las de un tipo del mismo
tamaño). Una última razón sería
él poder
minimizar los fallos de página. Estructuras en un mismo
bloque son probables que compartan la misma página, luego
podríamos acceder a todas las de un mismo bloque con
sólo un fallo de página.

6. Sistema De
Archivos

Windows NT soporta cuatro tipos de sistemas de
ficheros (SF) disintos, y puede trabajar con los cuatro a la vez
(un disco con varias particiones, en cada una un SF distinto).
Son los siguientes:

NTFS (New-Technology File System): Es el sistema de
ficheros nativo de Windows-NT. Como características podemos
señalar:

• Permite nombres de archivo de hasta 255 caracteres,
  sensibles al tipo de letra.
• Permite la gestión de medios de
  almacenamiento extraordinariamente
  grandes.
• Incorpora mecanismos para garantizar la seguridad.
• Soporta el concepto de
  enlace (por compatibilidad con el estándar
  POSIX).
• Es capaz de recomponerse rápidamente
  después de una caída del sistema.
• Soporta el estándar Unicode.

El que usa MS-DOS y
Windows 16 bits. Es el SF más pobre, y es se mantiene para
dar soporte a las aplicaciones DOS.

HPFS (High-Performance File System): Es el que usa el
sistema operativo
OS/2. Se ha incluido para dar soporte a las aplicaciones OS/2 y
complementar así al subsistema del mismo nombre. No es
capaz de recomponerse del todo bien después de una
caída del sistema ni de asegurar la no corrupción
de los datos.

CDFS (CD-ROM File
System): Es un SF que Microsoft ha
desarrollado exclusivamente para montarse sobre los CD-ROM.

Vamos a centrarnos en el más importante de los
cuatro: NTFS. Este sistema de ficheros lleva incorporados muchos
conceptos de teoría
de bases de datos
relacionales.

Proporciona la seguridad,
recuperación y tolerancia a
fallos en base a la redundancia de datos. De hecho,

implementa los cinco primeros niveles del
pseudo-estándar RAID. RAID significa Redundant Arrays of
Inexpensive Disks, algo así como "vectores
redundantes de discos baratos". Actualmente, el coste de los
almacenamientos masivos o secundarios es ínfimo, y ya se
pueden encontrar discos de varios Gb por menos de
S/.500.00.

A eso se refieren, a mi entender, las siglas. RAID es
una "norma" de facto que se basa fundamentalmente en conseguir la
integridad de los datos a base de dividirlos en pedazos y
repartir los pedazos entre varios discos, junto con informaciones
redundantes de comprobación de errores. Cada nivel ofrece
una estrategia
distinta para conseguir la integridad. Los niveles
son:

Nivel 0: los datos de cada fichero se dividen en
porciones, las cuales se reparten en un orden fijo entre los
distintos discos con los que cuente el sistema. Realmente
aquí no se usan códigos de comprobación de
errores.

• Nivel 1: de cada disco se realiza una copia o espejo.
  Es la estrategia que
  da mayor fiabilidad (pero también, evidentemente, la
  más costosa).
• Nivel 2: como el 0, pero un algortimo va construyendo
  una serie de códigos correctores de errores. Esos
  códigos son igualmente distribuidos entre unos discos
  destinados especialmente a ese uso.
• Nivel 3: como el 2, pero no se usan códigos
  correctores sino un simple código de paridad, que puede
  ser guardado en un mismo disco para todos los
  ficheros.
• Nivel 4: como el 3, pero dividiendo los ficheros en
  segmentos de datos más grandes.
• Nivel 5: es el nivel más usual; es igual que
  el4, pero no usa un disco separado para almacenar los
  códigos de paridad, sino que divide igualmente esos
  códigos y los distribuye por los disco, intentando que
  no coincidan en la misma zona de disco datos de un fichero con
  sus códigos de paridad correspondientes.
• Nivel 6: igual que el 5 pero se auxilia de elementos
  hardware, tales
  como controladoras de disco especiales, fuentes de
  alimentación.

En NTFS, al igual que en los SF de UNIX, existe
una serie de permisos sobre ficheros y directorios, que son los
siguientes: lectura (R), escritura (W), ejecución (X),
borrado (D), cambio de
permisos (P) y ser el nuevo propietario (O). Todo fichero y
directorio tienen un propietario, que puede conceder permisos
sobre ellos. El Administrador
del sistema puede tomar la propiedad de
cualquier fichero o directorio sobre NTFS, pero no transferirla
de nuevo a ningún otro usuario, a diferencia de UNIX, ni
siquiera a su dueño original.

Ventajas y Desventajas de los Sistemas de
Archivos

A continuación vamos a comentar las llamadas al
sistema más usuales para crear ficheros, leer de ellos,
escribir en ellos, etc.

Creación/Apertura de Ficheros

Para crear/abrir un fichero se usa la llamada al
sistema

HANDLE CreateFile (LPTSTR lpszName, DWORD fdwAccess,
DWORD fdwShareNode, LPSECURITY_ATTRIBUTES lpsa, DWORD fdwCreate,
DWORD fdwAttrsAndFlags, HANDLE hTemplateFile);

lpszName: nombre del archivo a crear o abrir.

fdwAccess: especifica el modo de acceso al archivo:
lectura (GENERIC_READ), escritura (GENERIC_WRITE), o
ambos.

fdwShareMode: permisos que tendrá la
compartición del archivo a abrir: 0 (ningún proceso
podrá abrirlo hasta que nosotros lo cerremos),
FILE_SHARE_READ (otros procesos pueden abrirlo pero sólo
para leer), FILE_SHARE_WRITE (sólo para escribir; no se
suele usar), o una combinación de ambos.

lpsa: la típica estructura de
seguridad de todo objeto en Windows NT. Sólo tendrá
sentido si el archivo se crea en un SF que soporte seguridad,
como NTFS.

fdwCreate: una serie de indicadores
que especifican una acción:

CREATE_NEW: crea un archivo nuevo, y da error si ya
existe

CREATE_ALWAYS: crea un archio nuevo,y si existe lo
machaca

OPEN_EXISTING: abre un archivo, y da error si no
existe

OPEN_ALWAYS: abre un archivo y si no existe lo
crea

TRUNCATE_EXISTING: si el archivo exisye, lo abre pero
truncando su tamaño a 0 bytes; si no existe, da una
error.

fdwAttrsAndFlags: sirve para dar atributos al fichero
(sólo si lo estamos creando) y activar ciertas
banderas.

Veamos algunos.

Atributos:

FILE_ATTRIBUTE_HIDDEN: archivo oculto

FILE_ATTRIBUTE_NORMAL: archivo sin atributos
especiales

FILE_ATTRIBUTE_READONLY: archivo de sólo
lectura

FILE_ATTRIBUTE_SYSTEM: archivo del sistema

FILE_ATTRIBUTE_TEMPORARY: archivo temporal; el Executive
intentará mantenerlo en RAM tanto como le
sea posible

FILE_ATTRIBUTE_ATOMIC_WRITE: para indicar que los datos
de este archivo son críticos; eso hará que el
Executive aumente la frecuencia con que escribe estos datos de
RAM a disco.

A propósito de los dos últimos indicadores,
comentar que el Executive no escribe a disco inmediatamente los
cambios realizados a un archivo en RAM, pues degradaría
las prestaciones
del sistema. Usa un mecanismo de escritura diferida, de manera
que se escribe a disco cuando se cierra el archivo, o cuando el
sistema está desocupado, o cuando es necesario hacer
swapping. Para los ficheros cuyos datos son críticos,
necesitamos que las modificaciones sean escritas
rápidamente a un soporte no volátil, por si el
sistema se cayera.

Banderas:

FILE_FLAG_NO_BUFFERING: con esta bandera le indicamos al
Executive que no gestione buffers de memoria con relación
a la entrada/salida de este archivo, sino que lea y escriba
directamente a disco.

FILE_FLAG_RANDOM_ACCESS: queremos acceso directo al
archivo.

FILE_FLAG_SEQUENTIAL_SCAN: acceso secuencial.

FILE_FLAG_WRITE_THROUGH: con este indicador, el SO
enviará a disco los datos que hayan sido modificados en
memoria, pero los mantendrá en memoria para acelerar las
lecturas

FILE_FLAG_POSIX_SEMANTICS: acceso al archivo
según el estándar POSIX (por ejemplo, sensible al
tipo de letra)

FILE_FLAG_BACKUP_SEMANTICS: cuando un proceso solicita
abrir un archivo, el SO normalmente realiza ciertos tests de
seguridad para comprobar si el proceso tiene o no los permisos
necesarios. Con este indicador se anulan ciertos tests, de manera
que el SO comprueba si el proceso tiene permiso para acceder al
archivo, y si es así, le permite el acceso pero
sólo para realizar una copia de seguridad. Aunque tenga
permiso de escritura, le será anulado.

FILE_FLAG_OVERLAPPED: los accesos a los archivos suelen
hacerse de manera síncrona (el subproceso duerme hasta que
se consuma el acceso). Con este indicador se permite realizar E/S
asíncrona, con lo que el subproceso seguirá
ejecutándose y el SO le informará cuando la E/S
finalice.

hTemplate: el descriptor de un archivo ya abierto; si no
es NULL, los atributos y banderas de dicho archivo serán
asignados a los de nuestro archivo.

La llamada retorna el descriptor al objeto archivo, o -1
si hubo algún error.

Cierre de Ficheros

Se usa la misma llamada que para cerrar un descriptor a
cualquier objeto. El Sistema Operativo
decrementará el contador de uso del archivo, y si es 0 lo
cerrará definitivamente.

BOOL CloseHandle (HANDLE hObject);

Lectura/escritura a ficheros

Windows NT permite que los subprocesos hagan E/S a
ficheros de manera síncrona o asíncrona. EL modo
síncrono es el habitual: un subproceso inicia una
operación de E/S sobre un fichero; el Executive lo
pondrá a dormir hasta que esa E/S de complete. En cambio, en el
modo asíncrono, el subproceso que inicia la
operación puede seguir ejecutándose, y cuando
necesite los datos de la E/S se pondrá voluntariamente a
esperar, de manera que si para ese tiempo la E/S se ha
completado, obtendrá los resultados
inmediatamente.

Se usan las mismas llamadas al sistema para ambos tipos
de acceso. En dichas llamadas existirá un parámetro
de entrada (lpOverlapped) que, si es NULL, indicará que la
llamada es acceso síncrono; si no, indicará acceso
asíncrono, dando la dirección de una estructura
OVERLAPPED que tiene el siguiente formato:

typedef struct _OVERLAPPED{

DWORD Internal;

DWORD InternalHigh;

DWORD Offset;

DWORD OffsetHigh;

DWORD hEvent;} OVERLAPPED;

Internal: cuando la E/S se completa, el sistema guarda
en esa palabra un estado
interno.

InternalHigh: cuando la E/S se completa, el sistema
guarda ahí el número de bytes
transferidos.

Offset,OffsetHigh: indican la posición del byte
del archivo donde queremos comenzar el acceso.

hEvent: el descriptor (opcional) de un objeto
suceso.

Vamos a suponer que un subproceso A desea realizar E/S
asíncrona sobre un fichero, y para ello inicializa el
parámetro lpOverlapped de la llamada con la
dirección correspondiente a una estructura OVERLAPPED.
Entonces sigue ejecutándose. Cuando al Executive le llega
la petición de E/S sobre el fichero, pone el estado de
este objeto a no señalado. Cuando la E/S finaliza, lo pone
a señalado (esto ya lo vimos en el capítulo de los
procesos). En algún momento, A necesita los datos de la
E/S que inició, con lo que se pone a esperar a que el
objeto archivo se ponga a estado
señalado (para lo cual usará una llamada tipo
WaitFor…Object(s), como ya explicamos). Si, en el momento de
hacer la llamada a E/S, el subproceso A hubiera especificado en
hEvent un descriptor a un suceso, el Executive pondría a
señalados tanto el objeto fichero como dicho objeto
suceso, con lo cual el subproceso A tendría la facilidad
de esperar por cualquiera de los dos.

La utilidad de esto
es en la situación de que el fichero es compartido, y
varios subprocesos pueden estar haciendo E/S sobre él y,
por consiguiente, poniéndose a estado señalado/no
señalado múltiples veces. Especificando un objeto
suceso propiedad de A, dicho subproceso sabrá que cuando
el suceso esté señalado, seguro que se ha
completado su operación de E/S y no la de otro.

Una vez explicados estos matices, pasamos sin más
a describir el perfil de las llamadas de lectura/escritura, que
son muy parecidas a las que usa UNIX:

BOOL ReadFile (HANDLE hFile, LPVOID lpBuffer, DWORD
nNumberOfBytesToRead, LPWORD lpNumberOfBytesRead, LPOVERLAPPED
lpOverlapped);

hFile: es el descriptor al archivo.

nNumberOfBytesToRead: es el número de bytes a
leer.

nNumberOfBytesRead: es un parámetro de salida que
indica el número de bytes que se leyeron en
realidad.

lpOverlapped: elige modo
síncrono/asíncrono; ya comentado

BOOL WriteFile(HANDLE hFile, CONST VOID * lpBuffer,
DWORD nNumberOfBytesToWrite, LPDWORD lpNumberOfBytesWritten,
LPOVERLAPPED lpOverlapped);

hFile: es el descriptor al archivo.

lpBuffer: apunta a un área de memoria donde se
encuentran los datos a escribir.

nNumberOfBytesToWrite: número de bytes a
escribir.

nNumberOfBytesWritten: número de bytes escritos
en realidad.

lpOverlapped: elige modo
síncrono/asíncrono; ya comentado.

Nos gustaría señalar que en los accesos
síncronos existe un puntero de lectura/escritura sobre un
archivo para cada subproceso que esté accediendo al mismo.
Ese puntero lo asigna el SO en el momento de apertura del archivo
cuando un subproceso lo abre para accesos síncronos (o
sea, sin especificar el indicador FILE_FLAG_OVERLAPED). El
puntero se modifica al leer y al escribir. En el caso de que el
acceso síncrono sea también acceso directo,
entonces es posible cambiar el puntero usando la llamada
SetFilePointer, que no merece la pena comentar.

Nótese que en los accesos asíncronos no
existe el puntero, por lo que hemos de indicar la
dirección de inicio de cada acceso (recordemos que se
indica en la estructura OVERLAPPED).

Existen unas llamadas de lectura/escritura extendidas
(ReadFileEx y WriteFileEx), que son muy útiles a la hora
de realizar una E/S asíncrona. Permiten que se les pase la
dirección de una función de forma que, cuando la
E/S asíncrona se complete, se salte a la ejecución
de esa función. Para ello, el subproceso ha de estar
esperando por el fin de la E/S con una función
WaitFor…Object(s) extendida (WaitForSingleObjectEx o
WaitForSingleObjectsEx). De hecho, WaitForSingleObject
está construida internamente como una llamada a
WaitForSingleObjectEx pasándole un parámetro que
indica que no queremos uso extendido.

Atributos de Ficheros

Los atributos que se indican al crear un fichero en el
parámetro fwdAttrsAndFlags pueden ser consultados con una
llamada a:

BOOL GetFileInformationByHandle (HANDLE hFile,
LPBY_HANDLE_FILE_INFORMATION lpFileInformation);

Esta llamada devuelve en la estructura apuntada por
lpFileInformation toda la información relativa al fichero cuyo
descriptor es hFile. La estructura tiene los siguientes
campos:typedef struct _BY_HANDLE_FILE_INFORMATION {

DWORD dwFileAtributes;

FILETIME ftCreationTime;

FILETIME ftLastAccessTime;

FILETIME ftLastWriteTime;

DWORD dwVolumeSerialNumber;

DWORD nFileSizeHigh;

DWORD nFileSizeLow;

DWORD nNumberOfLinks;

DWORD nFileIndexHigh;

DOWRD nFileIndexLow;}
BY_HANDLE_FILE_INFORMATION;

dwFileAttributes: los atributos del fichero que se
pasaron en el parámetro fdwAttrsAndFlags en el momento de
su creación (ver CreateFile)

ftCreationTime: fecha de creación del
fichero

ftLastAccessTime: fecha del último acceso al
fichero

ftLastWriteTime: fecha de la última escritura al
fichero

dwVolumeSerialNumber: número de serie del
volumen donde
se encuentra el fichero

nFileSizeHigh, nFileSizeLow: 64 bits que indican el
tamaño del fichero; por tanto, Windows NT permite ficheros
de hasta 264 bytes

nNumberOFLinks: número de enlaces del fichero;
este parámetro asegura la compatibilidad con el
estándar POSIX. Recordemos que en UNIX cada fichero tiene
un número de enlaces que indican los distintos nombres que
referencian al mismo fichero dentro del sistema de ficheros.
Así se evita la redundancia de datos.

nFileIndexHigh, nFileIndexLow: es un identificador
único que el Executive asocia a un fichero en el momento
de que algún subproceso lo abre. Si el sistema se apaga y
se enciende, el identificador puede no ser el mismo. Sin embargo,
en la misma sesión, procesos distintos leerán el
mismo identificador. Esto es útil para determinar si dos
descriptores distintos referencian en realidad al mismo fichero
dentro de un volumen (basta
hacer sendas llamadas a GetFileInformationByHandle y ver si el
identificador y número de volumen coinciden en las
estructuras devueltas por cada una).

Bloqueo de Archivos

Otra llamada muy importante es la que permite el bloqueo
de todo o parte de un fichero, de manera que ningún otro
subproceso pueda acceder a la región bloqueada.

La llamada para bloquear es:

BOOL LockFile (HANDLE hFile, DWORD dwFileOffsetLow,
DWORD dwFIleOffsetHigh, DWORD cbLockLow, DWORD
cbLockHigh);

hFile: descriptor al archivo a bloquear.

dwFileOffsetLow, dwFileOffsetHigh: dirección de
comienzo de la región a bloquear.

cbLockLow, cbLockHigh: tamaño de la región
a bloquear.

La llamada para desbloquear es:

BOOL UnlockFile (HANDLE hFile, DWORD dwFileOffsetLow,
DWORD dwFIleOffsetHigh, DWORD cbUnlockLow, DWORD
cbUnlockHigh);

Los parámetros son análogos a los
anteriores. Es necesario que un subproceso desbloquee un
área que previamente bloqueó antes de que finalice.
En caso contrario, estará impidiendo el acceso al fichero
a todos los demás subprocesos.

Existen versiones extendidas de ambas llamadas
(LockFileEx y UnlockFileEx) que permiten establaces bloqueos pero
sólo de escritura (otros subprocesos podrán leer el
área bloqueada, pero no escribir en ella).

7. Entrada Y
Salida

A lo largo de los capítulos precedentes hemos
hablado de los distintos aspectos de la E/S: gestión de
las caches, E/S síncrona y asíncrona, drivers de
dispositivo, nivel de abstracción de hardware, ficheros y
sistemas de ficheros, por citar algunos. Cuando
describíamos el administrador de
E/S del Executive, hablamos también de que se encargaba de
gestionar los mecanismos relacionados con la red. Me parece conveniente
dedicar parte de este último capítulo al tema de
las comunicaciones
en Windows NT, por tratarse de uno de los aspectos donde
más fuertemente brilla este SO.

Windows NT soporta trabajo en red con varios protocolos de
comunicaciones. Lo más importante es que
las facilidades de red están integradas en el SO, lo que
lo distingue de DOS y de la mayoría de las versiones de
UNIX, en los que las interfaces con la red eran un añadido
al SO, y frecuentemente no se adaptaban del todo bien al
mismo.

Vamos a describir brevemente qué ocurre en cada
uno de los niveles de implementación del modelo
OSI:

En el nivel 0 aparece un dispositivo que es la tarjeta
de interfaz a la red (Network Interface Card, NIC). El NIC conecta el
bus interno de la
máquina con la red, sirviendo de interfaz entre el nivel 0
y el 1 (nivel físico). Es contemplado por el SO como un
periférico más, controlado a través de su
driver correspondiente.

En el nivel 2 (nivel de enlace de datos) aparece un
software llamado
NDIS (Network Device Interface Specification), que es una
interfaz entre los drivers de dispositivo del NIC y los protocolos de
transporte.

En los niveles 3 (nivel de red) y 4 (nivel de transporte)
Windows NT sitúa el software de los protocolos
de transporte. Soporta TCP/IP, NBF,
NWLink, DLC y AppleTalk.

En el nivel 5 (de sesión) aparecen dos interfaces
con los protocolos de transporte, que son los Windows Sockets
(WinSock) y la NetBIOS.

Un socket es un mecanismo para establecer una
conexión entre dos máquinas.
Actúa como una especie de tubería bidireccional
para los datos. Fueron introducidos por primera vez por el UNIX
de Berkeley, y Windows NT incorpora una versión especial
llamada WinSock. Se utilizan cuando se quiere una comunicación a través del protocolo
TPC/IP,
IPX/SPX.

La interfaz NetBIOS es usada por aquellas aplicaciones
que deseen usar protocolos que se adapten a NetBIOS (como el
NBF). Establece conexiones entre distintas máquinas de la
red y se encarga de que la transmisión sea fiable una vez
establecida la conexión.

En la misma capa de sesión están dos
subsistemas integrales
gestionados por el administrador de la E/S, denominados el
redireccionador y el servidor. El
redireccionador es el responsable de enviar peticiones de E/S a
lo largo de la red, cuando el fichero o dispositivo solicitados
son remotos. Al servidor le
llegan peticiones desde los redireccionadores clientes, y las
gestiona de modo que alcancen su destino. Tanto servidores como
redireccionadores son implementados como drivers del sistema de
ficheros. Así, cuando un proceso quiere realizar una E/S,
usará las mismas llamadas al sistema para acceso local o
remoto, con lo que no necesita conocer la ubicación del
recurso (fichero o dispositivo). Pueden existir múltiples
parejas de redireccionadores-servidores
ejecutándose concurrentemente.

En el nivel 6 (capa de presentación) define como
se presenta la red a si misma ante la maquina y sus programas y/o
aplicaciones.

En el nivel 7 (capa de aplicación) existe un
proceso llamado suministrador por cada redireccionador de la capa
5. Cuando una aplicación hace una llamada de E/S, un
software llamado enrutador de suministradores (multiple provider
router)
determina el suministrador adecuado, y le envía la
petición. El suministrador, a su vez, se la pasará
al correspondiente redireccionador. Por ejemplo, el gestor de
ficheros (del administrador de E/S) es una aplicación que
usa los servicios de
los suministradores.

El último tema sobre E/S que vamos a tratar es la
gestión de entradas del usuario (mediante teclado o
ratón). Cuando el sistema se arranca y se crea el proceso
subsistema Win32, este proceso crea a su vez un subproceso
llamado subproceso de entrada inicial (Raw Input Thread, RIT),
que por lo general está inactivo. Cada vez que un usuario
pulsa una tecla, o mueve o pulsa el ratón, el driver de
dispositivo correspondiente añade un suceso hardware a la
cola de mensajes del RIT. Entonces, el RIT despierta, examina el
mensaje, determina qué tipo de suceso es (WM_KEY*,
WM_?BUTTON*, WM_MOUSEMOVE) y a qué subproceso va dirigido,
y lo envía a la cola de mensajes de dicho subproceso. Para
determinar el subproceso destino, el RIT examina sobre qué
ventana se encontraba el ratón cuando se produjo el
suceso, y determina qué subproceso es el propietario de
ese objeto ventana. Si es una secuencia de teclas, el RIT busca
qué subproceso está actualmente en primer plano, y
a él le mandará el mensaje.

No obstante, el RIT también monitoriza qué
tipo de entrada es, para que de esta manera se pueda cambiar de
contexto (Alt-Tab), o llamar al proceso Administrador de Tareas
(si Ctrl-Esc) o visualizar la ventana de diálogo de
la seguridad (si Ctrl-Alt-Del), etc.

8. Windows Nt
5

En la versión 4.0, Microsoft nos
dio una alegría al cambiar la interfaz gráfica de
Windows NT y sustituirla por Indy, la bonita GUI de Windows 95.
Desgraciadamente, NT 4.0 no incluía muchas de las cosas
que se venían anunciando desde hacía tiempo, lo que
nos dejó un sabor agridulce.

En Windows NT 5.0, Microsoft da un paso de gigante,
incluyendo las siguientes novedades importantes:

• Servicios de Directorio al estilo de X.500.
• Modelo de Objetos de Componentes Distribuidos
  (DCOM).
• Sistema de seguridad Kerberos.

Servicios de Directorio: Active Directory

NT 5.0 incluye un servicio de
directorio llamado Active Directory, basado en DNS (Domain
Name Server) y LDAP (Lightweight Directoy Access
Protocol).

El protocolo
DNS da una
manera de nombrar máquinas situadas en cualquier parte del
planeta y nos permite conocer sus correspondientes direcciones
IP, gracias a que estructura los nombres de las máquinas
jerárquicamente por dominios, y cada dominio conoce
potencialmente las direcciones IP de las máquinas que
pertenecen a él. Si quiero conocer la dirección de
la máquina mi_servidor.dom1.edu, preguntaré a
algún servidor del dominio edu, el
cual, o la sabe directamente, o preguntará a algún
servidor de dom1, y así.

Con Active Directory vamos a poder
localizar cualquier objeto llamándolo por su nombre, y
acceder a información sobre él. Un objeto
será algo heterogéneo: una máquina en
Internet, un
fichero, o un proceso en ejecución. La información
sobre ese objeto dependerá de la clase a la que pertenezca
dicho objeto (por tanto será también algo
heterogéneo). El pegamento que aglutina todo esto se llama
Active Directory.

La idea no es nueva: el sistema de directorios X-500
permite algo parecido, pero su complejidad ha hecho que no
esté muy difundido entre los sistemas
operativos. Por ello se desarrolló LDAP, una
versión simplificada de X-500.

En Active Directory va a tener, para cada dominio de
nuestra LAN, un nombre
de dominio al estilo DNS, y uno o varios servidores de dominio
(llamados controladores de dominio). Cuando LDAP sea, al igual
que DNS, un estándar, podremos acceder a la base de datos de
directorios del servidor Active Directory usando un cliente UNIX,
OS/2 o Macintosh.

Tener varios controladores de dominio asociados al mismo
dominio interesa cuando necesitemos alto rendimiento y baja tasa
de errores. Cada controlador va a almacenar la misma base de datos del
dominio del directorio. Active Directory asegura la integridad de
esas BD, de manera que actualizar una implique la
actualización de cada una de sus copias. Para ello se usa
un protocolo de comunicación entre controladores. La
actualización de las copias se realiza sólo sobre
los datos modificados.

La replicación se realiza vía RPCs cuando
estamos en un ámbito local, con alta fiabilidad y baja
tasa de errores. Para redes a través de
líneas telefónicas, se ha incluido la opción
del correo
electrónico como método
para que los controladores se intercambien información de
replicación.

En una LAN, la
replicación se produce cada 5 minutos. En una WAN, el
administrador puede ampliar el intervalo para aumentar así
las prestaciones.

Existen varias alternativas a la hora de elegir una API
para los clientes Active
Directory, destacando ADSI (Active Directory Sservice
Interface).

Modelo de Objetos de Componentes Distribuidos
(DCOM)

DCOM es una extensión natural a COM. COM es un
estándar para la
comunicación entre objetos independientemente del
lenguaje en el
que hayan sido escritos (por ejemplo, objetos Java con obejtos
C++). El objeto cliente
accederá a los métodos
del objeto servidor a través de interfaces COM
normalizados. Quizás nos suene más el nombre de
componentes ActiveX.

DCOM extiende lo anterior a un ámbito de red; los
objetos a comunicarse no tienen porqué compartir la misma
máquina.

Pero esto no es nuevo: lo podíamos hacer desde
hacía tiempo con las RPC. De hecho, DCOM está
construído sobre las RPC; se trata de un estándar
de más alto nivel, con el que podremos escribir
aplicaciones distribuidas en un entorno de red sin necesidad de
conocer todos los entresijos de las RPC, y además con un
enfoque orientado a objetos. De hecho, Microsoft también
se refiere a DCOM como Object RPC (ORPC).

DCOM se incluyó a Windows NT en su versión
4.0 (también salió en 1.996 una versión para
Windows 95), y
actualmente la empresa
Sofware AG prevé lanzar versiones para Solaris, Linux y otros
sistemas a finales de este año. Con esto tenemos que DCOM
se está convirtiendo en un estándar importante en
la industria, y
se podrá utilizar para comunicación entre objetos
corriendo en sistemas
operativos distintos.

Entonces, ¿qué aporta NT 5.0?

Supongamos que tengo un objeto servidor subsumido en un
proceso en mi máquina servidora, y que un cliente quiere
acceder a alguno de los métodos
que mi objeto exporta como públicos. Entonces, el
componente DCOM localiza él solito al objeto servidor en
la red, y le manda una RPC. DCOM encuentra el objeto servidor en
la red de dos posibles maneras:

En Windows NT 4.0, el cliente ha de conocer dónde
está el servidor (lo tiene escrito en el Registro) y se lo
dice a DCOM (trivial).

En Windows NT 5.0, DCOM usa Active Directory para hallar la
dirección del objeto. Ésta es la gran ventaja sobre
el caso anterior. Además de la dirección, puede
encontrar más información sobre el objeto
servidor.

Servicios de Seguridad: el estándar Kerberos

En UNIX, de la seguridad se encarga un módulo
llamado Kerberos, desarrollado por el MIT como parte del Proyecto Atenas.
Kerberos es actualmente un estándar en la industria, y
Microsoft ha implementado la versión 5 de la norma en NT
5.0.

Como sabemos, NT soporta varios protocolos de seguridad.
Existe, no obstante, una interfaz común que los aglutina
(la SSPI, Security Service Provider Interface), y que proporciona
una API común a los niveles superiores. En NT 4.0, la API
cubre los protocolos SSL (Secure Sockets Layer, junto con su
versión PCT) y NTLM (NT Lan Manager). En NT 5.0, Kerberos
se une al grupo. Los
usuarios del nivel de seguridad son otros protocolos, que, usando
la API SSPI, acceden a los servicios que
ofrece ese nivel, eligiendo el protocolo que deseen de entre los
de la lista. Ejemplos de protocolos clientes son HTTP, LDAP, CIFS
(usado por el Sistema de Ficheros Distribuido) y RPC.

En entornos de red, las aplicaciones usan primordialmente
el protocolo NTLM, que da autentificación, integridad de
datos y privacidad. Esto va a cambiar con la introducción del estándar
Kerberos.

Kerberos, al igual que NTLM, proporciona
autentificación, integridad de datos y privacidad. Entre
las mejoras que hace a NTLM se encuentra la
autentificación mutua, es decir, que tanto el cliente ha
de probar su identidad al
servidor como el servidor al cliente. Cada dominio de la red va a
tener su servidor Kerberos, que utiliza la base de datos de
Active Directory, con lo que se habrá de ejecutar sobre la
misma máquina que el controlador de dominio.
También puede estar replicado dentro del mismo
dominio.

De manera muy general, podemos decir que un usuario que
desee acceder a servicios de una máquina remota debe
primero hacer logon sobre el servidor Kerberos del dominio
correspondiente (o sobre alguna de sus copias, si cabe).

Si los procesos de identificación y
declaración de privilegios son correctos, Kerberos entrega
al cliente un "ticket que concede tickets" llamado TGT
(ticket-granting ticket) de acuerdo a los privilegios del
cliente. Usando ese ticket, el cliente podrá de nuevo
solicitar a Kerberos otros tickets para acceder a determinados
servidores del dominio. Kerberos examinará el TGT del
cliente y el servicio que
desea; si el TGT es válido para acceder al servicio
solicitado, Kerberos entregará al cliente un ticket nuevo
para acceder al servicio concreto. El
cliente envía ese nuevo ticket a la máquina donde
se encuentra el servicio al que desea acceder; el servidor
posiblemente lo examinará para comprobar la
identificación del usuario (autentificación). Los
tickets están todos encriptados.

El estándar Kerberos versión 5 no especifica
el contenido de los mensajes que se intercambian para identificar
al cliente. Por ello, los mensajes de cada implementación
de la norma serán distintos, con lo que podríamos
tener problemas al
interactuar con Kerberos de otros sistemas
operativos.

9. Bibliografia

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

Trabajo enviado y realizado por:
Saul Gonzales

Universidad
Nacional Mayor de San Marcos