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 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 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.

.

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 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.

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 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

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.

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

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.

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 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 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 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 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.

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.

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Á