Comparación LINUX y Microsoft Windows 95

CAPÍTULO I
LLAMADAS AL SISTEMA
LINUX vs WINDOWS 95
LINUX:
La gestión de procesos en Linux mínix se realiza de las misma forma y por tanto las llamadas al sistema que
se utilizan en los dos sistemas son las mismas. Utiliza la llamada fork() para la creación de procesos hijos y al
igual que minix execv() para cambiar la memoria del proceso hijo.
De esta forma consigue hacer que el padre ejecute un código mientras que el hijo ejecuta otro diferente. En
Línux también existe la llamada wait() para que un padre espere a que el hijo termine de ejecutar un código.
La llamada utilizada para que un proceso termine es exit().
Existen otras llamadas más para la gestión de procesos pero estas son las principales. Estos procesos pueden
estar ejecutándose en paralelo y por tanto es necesario que puedan comunicarse para establecer un orden de
ejecución o simplemente para que de unos a otros puedan pasarse la información que necesiten.
Los procesos en Linux se pueden comunicar de dos formas mediante las señales o mediante ficheros
intermedios que reciben el nombre de tubos. Para el manejo de señales Linux proporciona una serie de
llamadas que permiten a los procesos enviar señales (kill) y prepararse para recibir señales signal, ya que si un
proceso recibe una señal para la que no está preparado este directamente hará exit. En cuanto a la
comunicación mediante tubos de esta forma los procesos pueden pasarse información, como he dicho antes
los tubos son ficheros intermedios y por tanto para leer y escribir en ello se utilizarán las llamadas al sistema
que permiten leer y escribir en ficheros. Para la creación de tubos la llamada al sistema que proporciona Linux
es pipe. Las llamadas al sistema para la gestión del sistema de ficheros de Linux son en este caso también las
mas numerosas.
Existen llamadas que son muy parecidas en todos los sistemas operativos como son las de crear (creat), cerrar
(close), abrir (open), leer y escribir (read , write). También posee una llamada al sistema que nos devuelve el
estado del archivo, esta llamada es fstat y se utiliza mucho ya que también devuelve los permisos de los
archivos ya que en Linux como en Unix y en los demás sistemas que son multiusuario los ficheros están
protegidos según para quien los use. Relacionado con esto de los permisos tenemos un conjunto de llamadas
al sistema que nos permite cambiar los modos de los archivos así como saber que usuario pide una operación
sobre un archivo para saber si este tiene permiso para realizar la operación pedida o no. Estas llamadas son:
Chmod para cambiar los modos de un archivo y getuid, setuid, getgid y setgid para obtener información sobre
los usuarios.
Junto con las llamadas al sistema de gestión den sistema de ficheros tenemos también una serie de llamadas
para la gestión de directorios, estas llamadas entre otras cosas nos permiten , al igual que en minix crear
enlaces con ficheros así como montar sistemas de directorios con la orden mount. A parte de estas dos
operaciones también existen una serie de llamadas que nos permiten movernos por el árbol de directorios del
sistema como puede ser chdir.
WINDOWS 95:
Windows 95 se diseña como un sistema operativo de propósito general para mejorar la facilidad de uso con
respecto a Windows 3.11. Para ello se realiza una nueva interfaz de usuario de modo "intuitiva". El lo
1
referente al código de Windows 95 se escribe para poder ejecutar programas escritos en código de 32 bits.
Para que los programadores puedan escribir su código en este formato es preciso cambiar las llamadas al
sistema. El Windows 3.11 utiliza un conjunto de llamadas denominadas API(Application Programming
Interfaces). Para este nuevo sistema operativo se crea al API Win 32 que también es utilizado por Windows
NT aunque de un modo más desarrollado. Esta API Win 32 es compatible con la de Windows 3.11 y posee
más de 2.000 funciones y macros.
Los objetivos que se plantea microsoft para la creación de WIN 32 son : Amplio soporte lo cual significaba
hacerla compatible con la de Windows 3.11, Capacidad para ampliarla y dar soporte a las nuevas tecnologías
y que fuese adecuada para ajustarse a las diferentes plataformas de Hardware.
La parte incluida en Windows 95 de la API total es muy reducida ya que ésta consta de 2246 macros y
mensajes, de los que sólo 114 están en Windows 95.
En lo referente a las llamadas al sistema las API incluidas en Windows 95 son:
El API OLE que es el más importante y proporciona las llamadas para la gestión de objetos, El API de
consola que proporciona un entorno para aplicaciones que requieren características de E/S en modo carácter.
Aunque este API no está incluido por completo ya que windows 95 permite la gestión de una sola consola
mientras que windows NT permite la gestión de múltiples consolas. También existen otra serie de API más
como la de controles, descompresión, conexión lógica a red, comunicaciones, multimedia, y por último RPC
que da soporte para las llamadas al procedimientos remotos.
Comentarios:
Sobre la arquitectura un modo de funcionamiento de Windows 95 es muy difícil encontrar información pero
se puede observar que es de todos los sistemas operativos el que menos aprovecha las capacidades de la
máquina.
CAPÍTULO II
ADMINISTRACION DEL NUCLEO
LINUX vs WINDOWS 95
LINUX:
Linux, al igual que Mínix, es un sistema operativo que permite la multitarea o multiprogramación, es por esto
que en el núcleo existe una función que se encarga de la organización de los procesos. En el transcurso de la
ejecución un proceso en Linux puede pasar por cinco estados diferentes a diferencia de Minix en el que sólo
hay tres. Estos estados son:
• En ejecución: el proceso es ejecutado por el procesador.
• A punto: el proceso podría ser ejecutado pero otro proceso se está ejecutando en ese momento.
• Suspendido: el proceso está en espera de un recurso.
• Parado: el proceso ha sido suspendido por una intervención externa.
• Zombi: el proceso ha terminado su ejecución pero sigue siendo referenciado en el sistema.
Los atributos que el sistema mantiene mientras un proceso se esta ejecutando son: el estado, el valor de los
registros, la identidad del usuario bajo cuyo nombre se ejecuta, las informaciones utilizadas por el núcleo para
proceder al ordenamiento de los procesos(prioridad), las informaciones respecto del espacio de
direccionamiento del proceso(segmentos de código, de datos, de pila), las informaciones respecto a las
2
entradas/salidas efectuadas por el proceso y las informaciones que resumen los recursos utilizados por el
proceso.
La forma que posee Linux para ejecutar varios procesos es muy parecida a la que poseen los demás sistemas
operativos que admiten la multiprogramación. El sistema mantiene una lista de procesos a punto que podría
ejecutar y procede periódicamente a un ordenamiento. A cada proceso se le atribuye un lapso de tiempo.
Linux elige un proceso a ejecutar, y le deja ejecutarse durante ese lapso. Cuando ha transcurrido, el sistema
hace pasar al proceso actual al estado a punto, y elige otro proceso que ejecuta durante otro lapso. El lapso de
tiempo es muy corto y el usuario tiene la impresión que varios procesos se ejecutan simultáneamente, aunque
sólo un proceso se ejecuta en un instante dado. Se dice que los procesos se ejecutan en pseudoparalelismo.
La función del núcleo que decide qué proceso debe ser ejecutado por el procesador es el Coordinador. Éste
explora la lista de procesos a punto y utiliza varios criterios para elegir el proceso a ejecutar. El coordinador
de Línux proporciona tres políticas de coordinación deferentes: una para los procesos "normales" y dos para
los procesos de "tiempo real".
A cada proceso se le asocia un tipo de proceso, una prioridad fija y una prioridad variable. El tipo de proceso
puede ser:
• SCHED_FIFO para un proceso de "tiempo real" no primitivo.
• SHCED_RR para un proceso de "tiempo real" primitivo.
• SCHED_OTHER para un proceso clásico
La política de coordinación depende del tipo de procesos contenidos en la lista de procesos a punto de
ejecutar:
Cuando un proceso de tipo SCHED_FIFO está a punto, se ejecuta inmediatamente. El coordinador prioriza la
elección del proceso de tipo SCHED_FIFO que posea la más alta prioridad, y lo ejecuta. Este proceso no es
normalmente permisible, es decir, que posee el procesador, y el sistema sólo interrumpirá su ejecución en tres
casos:
• Otro proceso de tipo SCHED_FIFO que posea una prioridad más elevada pasa al estado a punto.
• El proceso se suspende en espera de un evento, como pro ejemplo el fin de una entrada/salida.
• El proceso abandona voluntariamente el procesador por una llamada a la primitiva sched_yield. El proceso
pasa al estado a punto y se ejecutan otros procesos.
Cuando un proceso de tipo SCHED_RR está a punto, se ejecuta inmediatamente. Su comportamiento es
similar al de un proceso de tipo SCHED_FIFO, con una excepción: cuando el proceso se ejecuta, se le
atribuye un lapso de tiempo. Cuando este lapso expira, puede elegirse y ejecutarse un proceso de tipo
SCHED_FIFO o SCHED_RR de prioridad superior o igual a la del proceso actual.
Los procesos de tipo SCHED_OTHER únicamente pueden ejecutarse cuando no existe ningún proceso de
"tiempo real" en estado a punto. El proceso a ejecutar se elige tras examinar las prioridades dinámicas. La
prioridad dinámica de un proceso se basa por una parte en el nivel especificado por el usuario por las llamadas
al sistema nice y setpriority, y por otra parte en una variación calculada por el sistema. Todo proceso que se
ejecuta durante varios ciclos de reloj disminuye en prioridad y puede así llegar a ser menos prioritario que los
procesos que no se ejecutan, cuya prioridad no se ha modificado.
Como se puede observar todo el peso de la planificación de la ejecución de los procesos en Linux la lleva a
cabo el Coordinador, al igual que como veremos más adelante en Windows NT esta función la lleva a cabo el
despachador de hilos. De esta forma nos damos cuenta que una buena planificación del modo de utilizar el
procesador el primordial para sacar el mayor rendimiento posible de éste.
3
.
WINDOWS 95:
También Windows 95 permite la multitarea, de hecho en el momento en que se está ejecutando existe la
multitarea ya que se ejecuta el Administrador de programas y otras diversas tareas que realmente forman parte
del mismo sistema. En Windows 95 un proceso es un objeto al igual que en Windows NT o Amoeba,
Windows considera cada VM−MSDOS como un único proceso independientemente de lo que suceda dentro
de una VM. Cada aplicación en ejecución también es considerada como un proceso, todas estas aplicaciones
son ejecutadas dentro de la VM del sistema y por tanto ésta posee mas de un proceso. En Windows 95, al
igual que en NT, existe también el concepto de hebra (hilo). Una hebra define un camino de ejecución dentro
de un proceso, y cualquier proceso puede crear muchas hebras, compartiendo todas la memoria asignada al
proceso original. En este sistema operativo los servicios para hebras sólo están disponibles para las
aplicaciones de 32 bits y los VxD. Cada aplicación de 16 bits utiliza una única hebra para su ejecución y con
ello se conserva el modelo de multitarea cooperativa de las aplicaciones anteriores de Windows. Cualquier
aplicación de Windows 95 puede crear hebras adicionales y éstas pueden ser planificadas con derecho
preferente. Las hebras múltiples permiten que una única aplicación gestione fácilmente sus propias
actividades en segundo plano y ofrecer al usuario una interfaz más sensible.
Cómo hemos visto un concepto importante en Windows es el de Máquina Virtual (VM) y por eso es el
administrador de la máquina virtual (VMM) el verdadero corazón de la base del sistema de Windows 95. La
eficiencia del VMM tiene un impacto decisivo en el rendimiento de todo el sistema y algunas de los
componentes más complejos del sistema operativo residen ahí. Windows 95 usa los mismos tipos básicos de
máquina virtual que Windows 3.1: La VM del sistema, en la que se ejecutan los componentes como el
Núcleo, Usuario y GDI además de todas las aplicaciones, y la VM MS−DOS que ejecuta cada una sesión de
dos con aplicaciones que se ejecutan bien en modo 8086 virtual o en modo protegido.
El componente del sistema que gestiona la CPU y cómo los procesos y hebras se van a ejecutar en el es el
Planificador. Las técnicas que utiliza Windows 95 para la planificación de procesos son la de Cooperación y
la de derecho preferente. La planificación de derecho preferente pone a disposición del sistema operativo un
control completo sobre qué proceso se ejecuta a continuación y por cuanto tiempo. En cualquier momento, el
planificador puede desplazar de la CPU al proceso en curso y asignársela a otro. Normalmente, tal acto de
apropiación se producirá como respuesta directa a un suceso que demande un cambio de atención. El
planificador asocia una prioridad con cada proceso en ejecución. Si se produce un suceso de interés para un
proceso de alta prioridad, el planificador relega al proceso actual y da preferencia de ejecución al proceso de
alta prioridad.
El planificador consigue el control del sistema tanto cuando un proceso libera la CPU como cuando se
produce una interrupción de reloj. Las prioridades de los procesos se recalculan frecuentemente y en este
cálculo se tiene en cuenta también la duración del lapso de tiempo que el planificador dota a cada proceso.
Con la técnica corporativa, el procesador puede conmutar entre procesos sólo cuando el proceso actualmente
en ejecución entrega la CPU.
En Windows 95 en realidad no existe un sólo planificador sino que dentro del VMM existen dos
planificadores, el planificador principal y el planificador de lapsos de tiempo. El primeros se encarga de
calcular las prioridades de las hebras y el segundo de la asignación de los lapsos. Si una hebra no recibe
tiempo de ejecución, ésta quedará suspendida hasta que el planificador vuelva a evaluar la situación.
El planificador principal examina cada hebra presente en el sistema y calcula un valor de prioridad de
ejecución para la hebra, éste suspende cualquier hebra que tenga un valor de prioridad de ejecución inferior al
valor más alto. Una vez que la hebra está suspendida el planificador principal no le presta más atención en el
cálculo de prioridad durante el lapso en cuestión. Después el planificador de lapsos calcula el porcentaje de
4
lapso a asignar a cada hebra, usando los valores de prioridad y conociendo el estado actual de la VM. Por
último las hebras se ejecutan y el planificador principal volverá a evaluar las prioridades cada 20
milisegundos.
Como podemos imaginar en muchas ocasiones el VM del sistema tendrá muchas hebras que están listas para
ser ejecutadas que poseen prioridades igual de altas, cuando esto ocurre el planificador de lapsos adopta una
política de planificación igualitaria para asegurar una asignación justa de tiempo de ejecución entre éstas
hebras. Una vez que una hebra dentro de la VM del sistema consume su tiempo asignado de ejecución, el
planificador la coloca al final de la cola que contiene las hebras de igual prioridad. Esta técnica clásica
asegura que todas las hebras con el nivel más alto de prioridad tienen una misma oportunidad de consumir su
tiempo de procesador. Si la hebra elegida falla antes de consumir todo su tiempo asignado de procesador, el
planificador concede el procesador a la siguiente hebra de igual prioridad en la VM del sistema.
Internamente el planificador utiliza tres técnicas como ayuda para lograr su objetivo de distribución equitativa
del tiempo del procesador. Estas tres técnicas que utiliza son la de Prioridad dinámica estimulada que
permite al planificador principal subir o bajar la prioridad de una hebra , Decaimiento de tiempo que hace
que la prioridad estimulada vuelva gradualmente a su valor y Herencia de prioridad que permite convertir
rápidamente una hebra de prioridad baja en una hebra de prioridad más alta. Normalmente se invierte la
prioridad de una hebra para permitir que una hebra con una prioridad baja termine rápidamente su utilización
de un recurso exclusivo por el que esperan hebras de prioridad más alta.
CAPÍTULO III
ADMINISTRACION DE PROCESOS
LINUX vs WINDOWS 95
LINUX:
La sincronización de procesos en el núcleo de Linux se realiza mediante la utilización de colas de espera y
semáforos. Una cola de espera no es más que una lista encadenada y circular de descriptores donde cada
descriptor posee la dirección al descriptor de proceso así como el puntero al elemento siguiente. Estas colas
son utilizadas para almacenar los procesos bloqueados por algún motivo. Por otra parte tenemos los semáforos
que son el elemento básico que utiliza Linux para sincronizar los procesos. Me parece lógico en esta parte dar
una definición bien detallada de qué son los semáforos y de qué forma funcionan ya que éstos van a ser
utilizados por otros sistemas operativos.
Un semáforo es un contador y dos operaciones definidas sobre el semáforo:
P: se utiliza cuando un proceso quiere entrar en su sección crítica (por ejemplo para imprimir en una
impresora, o escribir en el área de datos compartida). Lo que realiza es:
• Comprueba el valor del contador.
• Si es positivo pasa a realizar su sección crítica y decrementa el contador.
• Si el contador es menor o igual a 0 el proceso se bloquea y queda en una cola de espera hasta que el
contador sea 1.
V: Es simétrica a la anterior y se realiza cuando un proceso termina de realizar su sección crítica. Las
operaciones que realiza son:
• Decrementa el valor del contador.
• Desbloquea a los procesos en espera.
5
Para solventar el problema de la exclusión mutua basta con dar el valor inicial del contador a 1, de esta forma
si un proceso entra decrementará el contador y lo pondrá a 0 de forma que otro proceso no pueda entrar hasta
que él termine. El otro problema también es fácil imaginarse como se soluciona, simplemente el contador del
semáforo inicialmente se pondrá al número máximo de consumidores que puede haber funcionando al mismo
tiempo.
SEMÁFOROS.PARTICULARIDADES
Como hemos visto Linux utiliza semáforos para sincronizar los procesos en modo núcleo pero Linux también
dota de funciones para que los procesos puedan utilizarlos. En ciertos casos, un proceso necesita poseer varios
recursos para proseguir su acción, por ejemplo deberá acceder tal vez a una memoria intermedia de datos y a
un segmento de memoria compartida si desea desplazar los datos de un lugar a otro. Será necesario que utilice
dos semáforos y ejecuto dos operaciones P a fin de poder disponer de los dos recursos. Esta operación puede
producir que se bloqueen los dos procesos. Para solventar este problema las operaciones P y V en Linux no se
realizan sobre un sólo semáforo sino con una tabla de semáforos. De esta forma un proceso prosigue su
ejecución sólo cuando las operaciones se han desarrollado de forma correcta en todos los semáforos de la
tabla. Esta particularización en el uso d semáforos en Linux viene dada ya que este sistema operativo cumple
el estándar de Unix de comunicación entre procesos System V. Este estándar permite la comunicación entre
procesos también con el paso de mensajes y la posibilidad de tener un segmento de memoria compartida por
dos procesos.
WINDOWS 95:
En Windows 95 existen varios mecanismos para la sincronización entre procesos. En concreto Windows 95
utiliza: semáforos, mutexes, sucesos, archivos, procesos, subprocesos, entrada de terminal y notificación de
cambio de archivos. Todos estos mecanismos son tratados como objetos en este sistema operativo.
SECCIONES CRÍTICAS
Las secciones críticas son un mecanismo para sincronizar subprocesos pertenecientes a un mismo proceso,
pero no son objetos.
Una sección o región crítica (SC) es un trozo de código ejecutable tal que para que un subproceso pueda
ejecutarlo se requiere que tenga acceso a una estructura de datos especial y compartida.
Dicha estructura es del tipo CRITICAL_SECTION, cuyos campos no son interesantes, y además no son
accesibles directamente, sino a través de una llamada al subsistema Win32:
VOID InitializeCriticalSection (LPCRITICAL_SECTION lpCriticalSection);
Veamos algunas llamadas para manejar las SC:
VOID EnterCriticalSection (LPCRITICAL_SECTION lpCriticalSection);
VOID LeaveCriticalSection (LPCRITICAL_SECTION lpCriticalSection);
La primera sirve para que un subproceso solicite entrar en una SC. La segunda permite salir de la SC a un
subproceso que esté dentro de la misma.
La función de entrar opera así: la primera vez que es llamada, se registra en la estructura
CRITICAL_SECTION un identificador del subproceso que la posee. Si antes de que el subproceso la
abandone, el SO entrega la CPU a otro (el caso más frecuente), y entonces ese otro subproceso hace la
6
llamada para entrar en la SC, entonces la función ve que la estructura ya está en uso, con lo que el segundo
subproceso sería puesto a dormir.
Cuando la CPU vuelva al primero y éste haga una llamada para salir, la estructura será asignada al segundo
subproceso.
Si un subproceso vuelve a llamar a la función de entrar estando ya dentro de la SC, simplemente se
incrementará un contador de uso asociado con el objeto SC. Más tarde, deberá hacer tantas otras llamadas a la
función de salir para poner el contador a 0; en caso contrario, ningún otro subproceso podría ocupar la SC.
La estructura CRITICAL_SECTION y todos los recursos que el SO le hubiera asignado se pueden eliminar
haciendo una llamada a
VOID DeleteCriticalSection (LPCRITICAL_SECTION lpCriticalSection)
MÚTEX
Los objetos exclusión mutua (abreviadamente mutex, de mutual exclusion) son muy parecidos a las SC, pero
permiten sincronizar subprocesos pertenecientes a procesos distintos.
Se crean con la llamada:
HANDLE CreateMutex (LPSECURITY_ATTRIBUTES lpsa, BOOL fInitialOwner, LPTSRT
lpszMutexName);
La llamada devuelve un descriptor al objeto creado.
Si otro subproceso llamara a la función pasándole el mismo nombre de mutex, el SO comprobaría que ya está
creado y devolvería otro descriptor al mismo objeto.
HANDLE OpenMutex (DWORD fwdAccess, BOOL fInherit,
LPTSTR lpszMutexName);
Esta función comprobaría si existe algún objeto mutex con nombre lpszMutexName. Si es así, devolvería un
descriptor al mismo. Si no, devolvería NULL. El booleano fInherit permite que el mutex sea heredado por los
subprocesos hijos.
Si el mutex no tuviera nombre, un subproceso podría obtener un descriptor al mismo llamando a
DuplicateHandle.
Otra deficiencia de los mutex con las SC, es que un subproceso mantiene la propiedad de un mutex hasta que
quiera liberarlo, pero hasta el punto de que, si el subproceso muere y no ha liberado al mutex, éste seguiría
siendo de su propiedad. Así, si un mutex está libre (señalado) y es tomado por un subproceso (pasa a no
señalado), y dicho subproceso finaliza antes de liberarlo, el estado del mutex pasaría a señalado; los
subprocesos que estuvieran esperando por el mutex serían despertados pero no se les asignaría el objeto a
ninguno, sino que con el valor WAIT_ABANDONED de retorno de las llamadas WaitFor...Object(s) se les
informaría de lo que ha sucedido, de que el mutex no ha sido liberado sino abandonado. Esto se considera
como una situación de fallo en un programa.
Para liberar un mutex usaremos la llamada
7
BOOL ReleaseMutex (HANDLE hMutex);
donde hMutex es un descriptor al objeto. La función decrementa el contador de uso que el subproceso tiene
sobre el mutex. Cuando sea 0, el objeto podrá ser asignado al primer subproceso que por él esté esperando,
igual que con las SC.
SEMÁFOROS
Un semáforo es un objeto distinto de las SC y los mutex. A diferencia de ambos, el objeto semáforo puede ser
poseído a la vez por varios subprocesos, y no posee dentro ningún identificador del subproceso/s que lo está
usando. Lo que tiene es un contador de recursos, que indica el número de subprocesos que pueden acceder al
semáforo. Cuando un subproceso toma el objeto semáforo, el SO mira si el contador de recursos del mismo es
0. De ser así, pone al subproceso a dormir. Si no es 0, asigna el semáforo al subproceso y decrementa el
contador. Cada vez que un subproceso libera el semáforo, se incrementa el contador.
Un semáforo se crea con la llamada:
HANDLE CreateSemaphore (LPSECURITY_ATTIBUTES lpsa, LONG cSemInitial, LONG cSemMax,
LPTSTR lpszSemName);
cSemInitial es el valor inicial no negativo del contador de recursos; cSemMax es el valor máximo que puede
alcanzar dicho contador (por tanto 0 <= cSemInitial <= cSemMax); lpszSemName es el nombre que le damos
al objeto.
HANDLE OpenSemaphore (DWORD fdwAccess, BOOL fInherit, LPTSTR lpszName);
La semántica de esta llamada es análoga a la de OpenMutex.
Para incrementar el contador de referencia del semáforo se usa:
HANDLE ReleaseSemaphore (HANDLE hSemaphore, LONG cRelease, LPLONG lplPrevious);
donde cRelease indica el número de veces que queremos incrementar el contador (elnúmero de veces que
liberamos el semáforo). A la vuelta de la función, tendremos en lplPrevious un puntero al valor anterior del
contador. Por tanto, si queremos averiguar el valor del contador tenemos que modificarlo. Ni siquiera
llamando a la función con cRelease igual a 0 podríamos saber el valor anterior sin modificar el semáforo, pues
entonces la función devuelve 0 como dato apuntado por lplPrevious.
SUCESOS
A diferencia de los anteriores este concepto no ha sido todavía nombrado en este capítulo. Los sucesos son
objetos utilizados para indicar a los subprocesos que ha ocurrido algo en el entorno. Existen dos tipos de
sucesos con los que trata Windows NT, estos son: los sucesos de iniciación manual y los sucesos con
autonicialización.
Ambos tipos de objeto se crean con la misma llamada:
HANDLE CreateEvent (LPSECURITY_ATTIBUTES lpsa, VOOL fManualReset, BOOL fInitialState,
LPTSTR lpszEventName);
fManualReset a TRUE le indicará al SO que queremos crear un suceso de inicialización manual, y a FALSE,
un suceso de autoinicialización.
8
fInitialState indica el estado inicial del objeto; un valor TRUE significa que el suceso se creará como obejto
señalado, y a FALSE como no señalado.
Sucesos con inicialización manual (manual reset)
Este tipo de objetos se usan para que, cuando el suceso ocurra, es decir, se ponga a señalado, todos los
subprocesos que esperaban por ese suceso se despierten a la vez y todos puedan seguir ejecutándose. Por
tanto, ahora las funciones WaitFor...Objext(s) no van a tocar el estado del objeto, sino que debe hacerlo el
propio subproceso que creó el objeto. Dicho subproceso puede usar las llamadas:
BOOL SetEvent (HANDLE hEvent);
BOOL ResetEvent (HANDLE hEvent);
que ponen, respectivamente, el suceso identificado por hEvent en estado señalado y no señalado. O sea, con
SetEvent indicaremos que la situación asociada al objeto se ha producido, y con ResetEvent indicaremos lo
contrario.
Existe una llamada muy útil con este tipo de objetos:
BOOL PulseEvent (HANDLE hEvent);
que le da un "pulso" al suceso hEvent: lo pone en estado señalado, con lo que se libera a todos los subprocesos
en espera (que se seguirán ejecutando), y entonces lo pone a no señalado, con lo que los subprocesos que a
partir de ese momento esperen por el suceso serán dormidos. Por tanto, equivale a SetEvent + liberación +
ResetEvent.
Sucesos con autoinicialización (auto−reset)
Con estos objetos las funciones WaitFor...Object(s) van a funcionar como con cualquier otro tipo de objeto.
Por tanto, cuando la situación asociada con el suceso ocurra y éste se ponga a señalado (con SetEvent), sólo
uno de los subprocesos que estaban esperando podrá continuar, y su función WaitFor...Object(s)
correspondiente pondrá el estado del objeto a no señalado. La función ResetEvent no tendría efecto aquí. La
función PulseEvent pondría el suceso a señalado, liberaría un sólo subproceso de los que están esperando, y
pondría el suceso a no señalado.
Comentarios: En un sistema como éstos podría ocurrir que estuvieran ejecutándose dos procesos o hilos,
dependiendo del sistema operativo, que estuvieran colaborando el uno con el otro para realizar una tarea, si
éstos poseen un área de memoria compartida a la cual pueden acceder libremente se puede dar el caso en
que uno de ellos modifique un dato que el otro necesita antes de que haya sido capaz de leerlo, esto sin duda
provocaría, en el mejor de los casos, que los datos esperados son incorrectos. Éste es uno de los problemas
que deben solucionar los sistemas operativos y se conoce como el problema de los
productores−consumidores.
Otro de los problemas que se puede dar es que dos procesos intenten al mismo tiempo utilizar un recurso del
sistema que sólo puede ser utilizado por uno cada vez si queremos obtener resultados satisfactorios.
CAPÍTULO IV
ADMINISTRACION DE MEMORIA
LINUX vs WINDOWS 95
9
LINUX:
En Linux la gestión de memoria va a correr a cabo del núcleo a diferencia que en Mínix donde era el gestor de
memoria, ejecutándose en modo usuario el que llevaba esta gestión.
Si va a utilizar la memoria paginada y el intercambio además de la segmentación. La razón por la cual se
utiliza este modo de gestión de memoria más complejo pero también completo es bien sencilla. Como dije en
la primera parte del trabajo este sistema operativo era capaz de poder ejecutar, entre otras muchas cosas, el
entorno gráfico Xwindows, además de dar soporte a la multiprogramación y multiusuario. Si unimos todo esto
es fácil pensar que los programas a ejecutar pueden ser mayores que el tamaño de la memoria y que debido a
tener soporte multiusuario los procesos en ejecución pueden ser muchos. Para realizar el intercambio Linux no
sólo lo hará con el disco duro sino que como veremos más adelante será capaz de gestionar unos dispositivos
llamados swap que no tienen porqué ser el disco duro.
Para poder entender totalmente la gestión que Linux realiza de la memoria me veo obligado a dar una
explicación detallada de como se pagina y se gestiona la memoria.
Protección de zonas de memoria
Al poder estar cargados en memoria varios procesos se pueden producir problemas en cuanto a la protección
de las zonas de memoria. Para solucionar este problema Linux utiliza la segmentación para separar las zonas
de memoria asignadas al núcleo y a los procesos. Dos segmentos se refieren a los tres primeros Gigabytes de
espacio de direccionamiento de los procesos y su contenido pueden leerse y modificarse en modo usuario.
Los segmentos cuando entramos en modo núcleo se refieren al cuarto Gigabyte del espacio de
direccionamiento y se contenido sólo puede leerse y modificarse en modo núcleo. De esta forma el código y
los datos del núcleo quedan totalmente protegidos.
Paginación
Linux utiliza los mecanismos de memoria virtual proporcionados por el procesador sobre el que se ejecuta.
Las direcciones manipuladas por el núcleo y los procesos son direcciones virtuales y el procesador efectúa una
conversión para transformar una dirección virtual en dirección física en memoria central.
El mecanismo de conversión es el siguiente: una dirección de memoria se descompone en dos partes, un
número de página y un desplazamiento en la página. El número de página se utiliza como índice en una tabla,
llamada tabla de páginas, lo que proporciona una dirección física de página en memoria central. A esta
dirección se le añade el desplazamiento para obtener la dirección física de la palabra de memoria en concreto.
Debido al tamaño del espacio de memoria direccionable por los procesadores, la tabla de páginas raramente se
implementa en forma de una sola tabla contiguas en memoria. Como la tabla de páginas debes ser residente en
memoria, necesitaría un exceso un exceso de memoria para esta tabla. Por esta razón la tabla de páginas a
menudo se descompone en varios niveles, con un mínimo de 2. En el siguiente dibujo se puede observar esta
descomposición
El interés de esta tabla de páginas por niveles se basa en que la tabla de páginas no necesita cargarse
completamente en memoria.
Linux gestiona la memoria central y las tablas de páginas utilizadas para convertir las direcciones virtuales en
direcciones físicas. Implementa una gestión de memoria que es ampliamente independiente del procesador
sobre el que se ejecuta.
10
En realidad, la gestión de la memoria implementada por Linux considera que dispones de una tabla de páginas
a tres niveles:
1 la tabla global, cuyas entradas contienen las direcciones de páginas que contienen tablas intermedias;
2 las tableas intermedias, cuyas entradas contienen las direcciones de páginas que contienen tablas de páginas;
3 las tableas de páginas, cuyas entradas contienen las direcciones de páginas de memoria que contienen el
código o los datos utilizados por el núcleo o los procesos de usuario.
Ya que posee esta paginación Linux intenta sacarle el máximo partido y cuando varios procesos acceden a los
mismos datos Linux intenta compartir al máximo las páginas. Por ejemplo, se varios procesos ejecutan el
mismo programa, el código del programas se carga una sola vez en memoria, y las entradas de las tablas de
páginas de los diferentes procesos apuntan a las mismas páginas de memoria.
Además, Linux implementa una técnica de copia en escritura, que permite minimizar el número de páginas de
memoria utilizadas. Cuando se crea un procesos, llamando a fork, hereda el espacio de direccionamiento de su
padre. Evidentemente, el segmento de código no se duplica, pero Linux tampoco duplica el segmento de
datos. Al duplicar el proceso, todas las páginas del segmento de datos s marcan como accesibles en lectura
exclusiva en las tablas de páginas de los dos procesos. Cuando uno de los dos procesos intenta modificar un
dato, el procesador provoca una interrupción de memoria, que gestiona el núcleo. Al tratar esta interrupción,
Linux duplica la página afectada y la inserta en la tabla de páginas del proceso que ha causado la interrupción.
Intercambio (Gestión de dispositivos Swap)
Bajo Linux, todo dispositivo en modo bloque o archivo regular puede usarse como dispositivo de swap. El
núcleo de Linux guarde en memoria una lista de dispositivos de swap activos. Se utiliza una tabla de
descriptores, el la que cada uno describe un dispositivo de swap.
Cuando una página se escribe en un dispositivo de swap, se le atribuye una dirección. Esta dirección combina
el número de dispositivo de swap y el índice de la página utilizada en el dispositivo. Cuando una página debe
descargarse de la memoria, se le asigna una página en un dispositivo de swap, y la dirección de dicha página
se memoriza para que Linux puede recargar la página ulteriormente. En lugar de utilizar una tabla que
establezca una correspondencia entre las direcciones de páginas de memoria y las direcciones d entradas de
swap, Linux utiliza un método original:
• Cuando una página de memoria se descarta, la dirección de la entrada de swap asignada se guarda en
la tabla de páginas, en lugar de la dirección física de la página. Esta dirección está concebida para
indicar al procesador que la página no está presente en memoria.
• Cuando se efectúa una acceso de memoria sobre una página que se ha guardado en un dispositivo de
swap, el procesador detecta que la página no está presente en memoria y desencadena una
interrupción. Al tratar esta interrupción, Linux extrae la dirección de entrada de swap de la entrada
correspondiente de la tabla de páginas, y utiliza esta dirección para localizar la página en el swap y
cargarla.
Asignación de Memoria
Hasta el momento hemos visto como Linux utiliza una memoria paginada y unos elementos para poder
realizar una utilización óptima de la memoria pero no hemos hablado de qué algoritmo o estrategia utiliza
para asignar la memoria. Para llevar la cuenta de como está la memoria en cada momento Linux no utiliza una
lista simple como lo hacía Minix. Linux utiliza el principio del Buddy system. Su principio es bastante
simple: el núcleo mantiene una lista de grupos de páginas. Estos grupos son de tamaño fijo y se refieren a
11
páginas contiguas en memoria.
El principio Básico del Buddy system es el siguiente: a cada petición de asignación, se usa la lista no vacía
que contiene los grupos de páginas de tamaño inmediatamente superior al tamaño especificado, y se
selecciona un grupo de páginas de esta lista. Este grupo se descompone en dos partes: las páginas
correspondientes al tamaño de memoria especificado, y el resto de páginas que siguen disponibles. Este resto
puede insertarse en las otras listas.
Al liberar un grupo de páginas, el núcleo intente fusionar este grupo con los grupos disponibles, a fin de
obtener un grupo disponible de tamaño máximo.
Para simplificar la asignación y liberación de un grupo de páginas, el núcleo sólo permite designar grupos de
páginas cuyo tamaño sea predeterminado y corresponda a los tamaños gestionados en las listas.
Como vemos este método es mucho más complicado que el que utilizaba el sistema operativo anterior pero
con este método se permite una mejor utilización de la memoria.
WINDOWS 95:
Windows 95 sigue admitiendo las funciones de la API presentes en Windows 3.x y aún se pueden construir y
ejecutar aplicaciones que utilizan el esquema de direccionamiento segmentado del procesador 286. Sin
embargo si se observa detenidamente la API de memoria de Windows 95, se verá que todas las funciones de
la API diseñadas en un principio para permitir una gestión más cuidada de un espacio de direcciones
segmentadas se ha quedado obsoletas.
En la actualidad, Windows 95 tiene diversas capacidades nuevas de gestión de memoria a nivel de aplicación.
Todas las funciones se refieren a la gestión de memoria dentro del espacio de direcciones de la aplicación, la
memoria virtual privada asignada al proceso. La gestión de memoria a lo largo de todo el sistema es
responsabilidad del sistema base y la API de Windows intenta ocultar muchos de los pormenores de la
funciones de menor−inferior del sistema.
Memoria virtual de la aplicación.
Toda aplicación Win32 tiene un mapa de memoria similar y cada espacio de direcciones es único. El espacio
privado de direcciones de la aplicación Win32 es también la región donde el sistema asigna memoria para
satisfacer las peticiones de la aplicación en tiempo de ejecución.
Las peticiones de memoria realizadas en tiempo de ejecución se encuentran en una de estas dos categorías: la
aplicación puede realizar una solicitud explícita de memoria extra o el sistema puede responder a una solicitud
implícita de memoria, esto es asignar memoria a una aplicación como efecto secundario de la asignación de
algún otro recurso.
Gestión de la memoria física.
La gestión de la memoria física es el proceso de selección de las páginas del espacio virtual de direcciones de
4 GB del sistema que se hacen corresponder con la memoria física en cada momento. El sistema lleva a cabo
un intercambio de las demás páginas que permanecen activas en el espacio virtual de direcciones hacia y
desde el disco fijo reasignando las páginas de memoria física cuando sea necesario. Las páginas físicas
ocupadas por los componentes del núcleo residentes en memoria no entran en el proceso de gestión de
memoria.
Al contrario del diseño de un sistema multiusuario en el que el sistema operativo no tiene que preocuparse de
12
la compartición equitativa de la memoria, el diseño de Windows 95 permite que el usuario llene su memoria
como quiera, imponiendo, eso si, una restricción a la cantidad de memoria total que una aplicación pueda
bloquear, ya que si no se podría llegar a una situación de interbloqueo. Una vez llena la memoria física, la
siguiente petición de asignación de pagina pone en marcha un proceso de paginación.
El algoritmo de paginación de Windows 95 es la técnica estándar menos utilizada, ésta reasigna las páginas
residentes más antiguas cuando se tiene que satisfacer nuevos requisitos.
Para ayudar en la gestión de los tipos diferentes de memoria, cada página activa tiene asignado un manejador
a un descriptor paginador (PD), este contiene las direcciones de las rutinas utilizadas para la transferencia de
páginas hacia y desde la memoria física y el disco. Independientemente del tipo de memoria que contenga la
página, para poner la página dentro o fuera de memoria, el gestor de la memoria física simplemente llama a la
función apropiada, según esté definido el PD página.
Gestión de la memoria virtual.
La gestión de la memoria virtual en Windows 95 es considerablemente más compleja. Windows 95 establece
varias nuevas exigencias en el gestor de memoria virtual:
• El nuevo tipo de aplicaciones Win32 con muchas nuevas funciones de la API que admiten varios tipos
diferentes de memoria de aplicación compartida y asignada dinámicamente.
• Componentes del sistema cargables dinámicamente.
Windows 95 permite que una aplicación Win32 consuma un espacio virtual de direcciones enorme. El sistema
operativo base asigna todas las regiones de memoria virtual privada de las aplicaciones Win32 dentro de los
2GB inferiores del espacio virtual de direcciones. Todos los objetos de memoria compartidos residen dentro
de la región que va de los 2 GB a los 3 GB, proyectándolas en el espacio de direcciones de la VM del sistema
cuando sea necesario. Las llamadas a las DLL del sistema son llamadas directas sin transición de anillo y sin
cambio de contexto. La ventaja de esta mejora está en la velocidad, la desventaja es que una aplicación puede
obtener un puntero al espacio de direcciones del sistema y acceder. En este caso particular, lo diseñadores de
Windows 95 optaron por el rendimiento por encima de la seguridad.
Comentarios: Como hemos visto Linux realiza una gestión de la memoria eficaz y totalmente independiente
del procesador sobre el que se esté ejecutando. Su forma de mantener el estado de memoria esta definida
como el método de los colegas y señala que es un mecanismo optimo para la gestión de la memoria. Todo
esto nos lleva a pensar, aunque antes ya lo pensaba, que Linux es un sistema operativo mucho más potente de
lo que la gente se imagina y que en un futuro dará mucha guerra a los sistemas implantados en la actualidad.
Desde luego las características para dar esa guerra las tiene pero no se si los medios.
Por lo contrario como se dicho anteriormente según el diseño que tiene la memoria virtual de Windows 95 es
posible que programas se metan en direcciones de memoria que no deberían y esto también dice algo en
contra de este sistema operativo ya que lo puede volver inestable
CAPÍTULO V
ADMINISTRACION DE ARCHIVOS
LINUX vs WINDOWS 95
LINUX:
El sistema de archivos utilizado por Linux va a ser muy parecido al utilizado por Minix. Una de las
13
diferencias esenciales entre Linux y Minix es que la gestión de archivos en Linux va a ser realizada por el
núcleo del sistema y no pro un proceso usuarios.
Debido a que la gestión del sistema de archivos es realizado por el núcleo la comunicación entre los procesos
y este núcleo se va ha realizar mediante el uso general de las llamadas al sistema como ya se explico en el
capítulo de procesos.
También veremos más adelante como las capacidades del sistema de Archivos de Linux son mucho mayores
que las de Minix. Todas estas diferencias son a nivel interno porque en lo referente a lo visto por el usuario los
dos poseen un diseño en forma de árbol donde existen directorios que ha su vez pueden contener otros
directorios o archivos.
Gestión del espacio en disco
Como se ha dicho anteriormente la gestión del espacio en disco que realiza Linux es similar a la que realiza
Minix. Los sistemas de archivos nativos de Linux reciben el nombre de ext2 y están formados por un bloque
de autoarranque, que se ejecuta cuando se enciende la máquina, seguido de unos bloques para los nodos−i y
finalmente los bloques de disco para el almacenamiento de los ficheros.
La cuenta de nodos−i y de los bloques se realiza de la misma forma que en Minix mediante la utilización de
mapa de bits.
Nodos−i
La forma de acceder a los bloques de datos que forman los archivos también es similar ya que para ello se
utilizan los nodos−i que posee la misma estructura que vimos en la figura 2.2.1.
En este apartado explicaré más detalladamente como con la utilización de los nodo−i se accede a un bloque de
disco.
Cuando un proceso llama a una primitiva del sistema pasándole un nombre de archivo el núcleo convierte el
nombre especificado en un descriptor de archivo. Para ello Linux explora cada uno de los directorios
contenidos en la ruta del nombre y compara cada entrada de directorio con el nombre simple del elemento
siguiente. Así hasta llegar al nodo−i que contiene la información del archivo que queremos abrir.
Una vez tenemos el archivo abierto es muy sencillo acceder a los diferentes bloque de datos del fichero ya que
en el nodo−i del fichero se encuentran las direcciones de estos bloques.
Montaje de sistemas de archivo (capa sva)
A lo largo de todo el trabajo hemos comprobado que este sistema operativo es uno de los más completos que
existe. Una de las diferencias principales entre Minix y Linux es la capacidad de gestionar sistemas de
archivos que no son nativos de Linux (recordemos ext2). Linux al igual que Minix permite el montaje de
nuevos sistemas de archivos sobre directorios de su árbol. Pero no sólo permite el montaje de sistemas de
archivo ext2 sino también permite montar y utilizar sistemas de archivos de modo MS−DOS, Minix, ISO0664
(CD−ROM) y de algunos otros.
La gestión de los distintos sistemas de archivos es posible gracias a una capa lógica que posee el núcleo cuya
misión es asegurar la interfaz entre las llamadas al sistema respecto a los archivos y el código de gestión de
archivos propiamente dicho. Esta capa recibe el nombre de sistema virtual de archivos(SVA).
El SVA proporciona funcionalidades independiente de los sistemas de archivos físicos e implementa por
14
ejemplo:
• El caché de nombres:
Cada conversión de n nombre de archivo en números de dispositivo y de nodo−i es costosa, porque necesita
una exploración iterativa de directorios. Por razones de rendimiento, el SVA implementa un caché de nombres
de archivo: cuando un nombre de archivo se convierte en números de dispositivo y nodo−i, el resultado se
memoriza en una lista. En las llamadas siguientes con el mismo nombre de archivo, el resultado guardado
puede reutilizarse sin proceder de nuevo a la exploración de directorios.
• El búfer caché:
Linux mantiene un lista de memorias intermedias en curso de utilización. Al realizar una lectura de bloque un
sistema de archivo, el contenido del bloque se guarde en una memoria intermedia, llamada búfer. (Como
vimos esto también lo hace Minix para agilizar el proceso de lectura de bloques) Esta memoria se guarde
mientras el bloque está en curso de utilización, y mientras el espacio de memoria que ocupa no se necesita
para otro búfer. Al realizarse una modificación de datos en un bloque, el cambio se efectúen en el contenido
del búfer, que se marca como modificado pero no se escribe en disco inmediatamente. A intervalos regulares,
el proceso update llama a la primitiva sync para forzar la reescritura de todos los búfers modificados.
Las funciones internas del SVA asegura también las partes comunes de las llamadas al sistema que opera
sobre archivos. A fin de llamar a las funciones correspondiente a las diferentes acciones, el SVA utiliza una
aproximación orientada a objetos: a cada sistema de archivos montado, archivo abierto, e i−nodo en curso de
utilización se les asignan operaciones implementadas en el código del sistema de archivos correspondiente.
Las operaciones que se definen sobre cada uno de los objetos anteriores están clasificadas en cuatro tipos:
• Operaciones sobre sistemas de archivos: son las operaciones dependientes del formato físico del
sistema de archivos, como la lectura o la escritura de un nodo−i
• Operaciones sobre nodos−i en curso de utilización: son las operaciones directamente vinculadas a los
nodos−i, como la supresión de un archivo.
• Operaciones sobre archivos abiertos: son las operaciones correspondientes a primitivas de
entrada/salida sobre archivos, como la lectura o escritura de datos.
• Operaciones sobre cuotas: son las operaciones llamadas para validar la asignación de bloques e
nodos−i.
Seguridad
Linux es un sistema pensado para la utilización en entornos multiusuario y por tanto el tema de la seguridad
debe ser tratado cuidadosamente. La privacidad de datos y la consistencia de los mismos se asegura en Linux
mediante un serie de permisos que se le dan a los diferentes archivos.
A cada archivo se le asocian varios atributos:
• Su tamaño en bytes
• el identificador del propietario del archivo
• el identificador del grupo de usuarios del propietario
• el número de enlaces que tiene
• sus derechos de acceso
• las fechas de acceso y modificación
A nosotros nos interesan sus derechos de acceso. Estos son los que se van a encargar de la seguridad.
15
Los derechos de acceso se expresan en un tripleta: los permisos del propietario, los permisos del grupo y los
permisos del resto de usuarios.
Cada uno de estos permisos esta formado por tres derechos:
• El derecho a leer os datos del archivo "r"
• El derecho a escribir datos en el archivo "w"
• El derecho a ejecutar el contenido del archivo "x"
Si hablamos de directorios en lugar de archivos el derecho a lectura permite listar el contenido del directorio,
el derecho a escritura permite modificar el contenido del directorio y el derecho a ejecución permite atravesar
el directorio.
Además de estos permisos, los derecho contiene tres bits con un significado especial:
• El bit setuid: Cuando un archivo ejecutable posee este bit al ejecutar su contenido se hace con la
identidad del propietario del archivo y no con la del usuario que ejecuta el programa.
• El bit setgid: Es igual que el anterior pero hablando de grupo en lugar de usuario.
• El bit stkck: Cuando un directorio posee este bit los archivos que hay en el sólo pueden ser suprimidos
por sus propietarios.
Con esta forma de gestión de la seguridad la protección de los datos queda asegurada aunque siempre hay
pequeños agujeros por los que se intenta burlar este sistema de seguridad.
WINDOWS 95:
Windows 95 estaba condenado a ser compatible con MS−DOS y esto es lo que hace que no se introduzca un
nuevo modelo de sistema de archivos.
Sólo se soluciona la diferencia que menos importaba, a nuestro entender, entre los sistemas Linux y Windows
95. La primera versión de Windows 95 da soporte para los nombres largos, es decir, que los nombres ya no
tienen el porqué tener una longitud de 8 caracteres como hasta el momento. Para la imposición de este
"adelanto" los esfuerzos que realizaron los diseñadores de Windows 95 fueron mayúsculos ya que debían
hacer que el sistema soportara tanto nombres largos como cortos. A nuestra opinión podrían haber pensado
esto cuando diseñaron MS−DOS pero parece que no tenían tiempo. La verdad es que me parece inútil explicar
detenidamente las artimañas que se tuvieron que hacer para que Windows aceptara nombres largos ya que el
meollo de la cuestión en el tema de los sistemas de archivos es la gestión que estos realizan de los discos y no
de si soportan nombres largos o no.
Parece que el año pasado, y en vista de que los discos duros cada vez eran más grandes, los diseñadores de
Windows 95 se dieron cuenta de que la FAT de 16 bits que se utilizaba en el principio era escasa y por fin
decidieron arreglar el problema mediante el lanzamiento de un nuevo Windows 95 conocido como versión
"OSR2". Esta versión entre otros adelantos incluía soporte para una nueva FAT de 32 bits.
La fat de 32 bits
Como dije en el apartado de MS−DOS mediante la utilización de la FAT de 16 bits sólo se podían gestionar
65.535 bloques de disco y por tanto para discos muy grandes el tamaño de los bloques debía ser muy grande.
Este tamaño depende del tamaño del disco. Imaginemos que poseemos un disco de 2 Gb (cosa muy frecuente)
esto nos llevaría a tener un tamaño de bloque de 32Kb. Si en el apartado anterior con un tamaño de bloque de
2 K el desperdicio veíamos que era enorme pues imaginemos con este tamaño.
16
Con la nueva FAT de 32 bits se consigue que las entradas de la FAT puedan ser 4.294.967.295. Esto permite
que el tamaño del bloque sea de 4 K y esto significa un ahorro significativo.
Comentarios: Tras esta explicación sólo podemos concluir que como hasta el momento este sistema operativo
lejos de defraudarnos cada vez nos sorprende más. Gracias a la capa SVA, que contiene el núcleo, este
sistema permite no sólo trabajar con sistemas de archivos nativos de él sino con otros que no tienen nada que
ver. Esto como se puede imaginar es una gran avance ya que se puede acceder a datos que están en otras
unidades que no tienen porque estar en formato Linux.
En el tema de la gestión de los dispositivos de almacenamiento es igual que en el sistema del que proviene,
Unix, y como hemos podido observar es de gran sencillez gracias a la utilización de los Nodos−i.
Todas esta razones junto con las que hemos estudiado en los apartados anteriores me hacen pensar que este
sistema operativo es uno de los más potentes que existen en la actualidad y que dará mucho que hablar en un
futuro no muy lejano.
Por lo contrario los sistemas operativos de Microsoft en un principio se crean los sistemas con mucha prisa
si parar a pensar en el futuro y esto hace que luego se tengan que parchear como pasó con la FAT. Sin duda
que la introducción de la nueva FAT hace que el aprovechamiento del disco sea mucho mayor que con la
antigua pero como siempre llegó tarde. Un hecho que demuestra sinceramente las intenciones de la empresa
es que la versión de Windows 95 que soportaba la FAT 32 solamente se podía adquirir comprando un equipo
nuevo. Tal vez esto no tenga mucho que ver con la estructura interna de Windows 95 pero nos da una idea de
la conciencia con la que se hacen estos sistemas operativos.
LINUX VS WINDOWS
3
UNIVERSIDAD TECNOLÓGICA DE PANAMÁ
17