Agregar a favoritos      Ayuda      Português      Ingles     

Arquitectura de Sistema Operativo Windows

Enviado por mdbastida



  1. Visión General de la Arquitectura de Windows
  2. Modo Kernel
  3. Modo Usuario
  4. Conclusiones
  5. Bibliografía Consultada

Introducción

Con el paso de los años se ha producido una evolución gradual de la estructura y capacidades de los Sistemas Operativos. Sin embargo, recientemente se ha introducido un cierto número de nuevos elementos de diseño en los nuevos Sistemas Operativos y en las nuevas versiones de los Sistemas Operativos existentes. Estos Sistemas Operativos modernos responden a nuevos desarrollos del hardware y nuevas aplicaciones. Entre estos dispositivos de hardware están las máquinas multiprocesador, incrementos enormes de la velocidad de la máquina, alta velocidad en los enlaces de las redes de comunicación e incremento en el tamaño y variedad de los dispositivos de almacenamiento de memoria. En los campos de aplicación que han influido en el diseño de los Sistema Operativos están las aplicaciones multimedia, el acceso a Internet y páginas Web y la ejecución cliente/servidor.

El porcentaje de cambios en las demandas de los Sistemas Operativos, requiere no solamente las modificaciones y mejoras en las arquitecturas ya existentes, sino nuevas formas de organización del Sistema Operativo. Muchos de los diferentes enfoques y elementos de diseño se han probado tanto en Sistemas Operativos experimentales como comerciales, y muchos de ellos encajan dentro de las siguientes categorías

  • Arquitectura Micronúcleo.
  • Multihilos.
  • Multiproceso Simétrico.
  • Sistemas Operativos Distribuidos.
  • Diseño Orientado a Objeto.

La mayor parte de los Sistemas Operativos hasta hace poco tiempo se caracterizaban por un gran núcleo monolítico. Gran parte de la funcionalidad que se pensaba debía tener un Sistema Operativo la proporcionaba este gran núcleo, incluyendo planificación, sistema de archivos, redes, controladores de dispositivos, gestión de memoria y muchas cosas más. Normalmente un núcleo monolítico está implementado como un único proceso, con todos sus componentes compartiendo el mismo espacio de direcciones.

La arquitectura micronúcleo asigna solamente unas pocas funciones esenciales al núcleo, incluyendo espacios de direcciones, comunicación entre procesos (IPC) y planificación básica. Otros servicios del Sistema Operativo los proporciona procesos, algunas veces llamados servidores, que se ejecutan en modo usuario y que el micronúcleo trata como a cualquier otra aplicación. Este enfoque desconecta el núcleo y el desarrollo de servidores. Los servidores pueden estar diseñados para aplicaciones específicas o necesidades del entorno. El enfoque del micronúcleo simplifica la implementación, proporciona flexibilidad y se adapta bien para entornos distribuidos. En esencia, un micronúcleo interactúa de la misma forma con procesos servidores locales y remotos, facilitando la construcción de sistemas distribuidos.

Este trabajo intenta abordar la arquitectura del Sistema Operativo Windows y los servicios que cada uno de sus componentes brinda para llevar a cabo cada una de las categorías antes expuestas.

Visión General de la Arquitectura de Windows.

Un Sistema Operativo serio, capaz de competir en el mercado con otros como Unix que ya tienen una posición privilegiada, en cuanto a resultados, debe tener una serie de características que le permitan ganarse ese lugar. Algunas de estas son:

  • Que corra sobre múltiples arquitecturas de hardware y plataformas.
  • Que sea compatible con aplicaciones hechas en plataformas anteriores, es decir que corrieran la mayoría de las aplicaciones existentes hechas sobre versiones anteriores a la actual, nos referimos en este caso particular a las de 16-bit de MS-DOS y Microsoft Windows 3.1.
  • Reúna los requisitos gubernamentales para POSIX (Portable Operating System Interface for Unix).
  • Reúna los requisitos de la industria y del gobierno para la seguridad del Sistema Operativo.
  • Sea fácilmente adaptable al mercado global soportando código Unicode.
  • Sea un sistema que corra y balancee los procesos de forma paralela en varios procesadores a la vez.
  • Sea un Sistema Operativo de memoria virtual.

Uno de los pasos más importantes que revolucionó los Sistemas Operativos de la Microsoft fue el diseño y creación de un Sistema Operativo extensible, portable, fiable, adaptable, robusto, seguro y compatible con sus versiones anteriores (Windows NT).

Y para ello crearon la siguiente arquitectura modular:

La cual está compuesta por una serie de componentes separados donde cada cual es responsable de sus funciones y brindan servicios a otros componentes. Esta arquitectura es del tipo cliente – servidor ya que los programas de aplicación son contemplados por el sistema operativo como si fueran clientes a los que hay que servir, y para lo cual viene equipado con distintas entidades servidoras.

Ya creado este diseño las demás versiones que le sucedieron a Windows NT fueron tomando esta arquitectura como base y le fueron adicionando nuevos componentes.

Uno de las características que Windows comparte con el resto de los Sistemas Operativos avanzados es la división de tareas del Sistema Operativo en múltiples categorías, las cuales están asociadas a los modos actuales soportados por los microprocesadores. Estos modos proporcionan a los programas que corren dentro de ellos diferentes niveles de privilegios para acceder al hardware o a otros programas que están corriendo en el sistema. Windows usa un modo privilegiado (Kernel) y un modo no privilegiado (Usuario).

Uno de los objetivos fundamentales del diseño fue el tener un núcleo tan pequeño como fuera posible, en el que estuvieran integrados módulos que dieran respuesta a aquellas llamadas al sistema que necesariamente se tuvieran que ejecutar en modo privilegiado (modo kernel). El resto de las llamadas se expulsarían del núcleo hacia otras entidades que se ejecutarían en modo no privilegiado (modo usuario), y de esta manera el núcleo resultaría una base compacta, robusta y estable.

El Modo Usuario es un modo menos privilegiado de funcionamiento, sin el acceso directo al hardware. El código que corre en este modo sólo actúa en su propio espacio de dirección. Este usa las APIs (System Application Program Interfaces) para pedir los servicios del sistema.

El Modo Kernel es un modo muy privilegiado de funcionamiento, donde el código tiene el acceso directo a todo el hardware y toda la memoria, incluso a los espacios de dirección de todos los procesos del modo usuario. La parte de WINDOWS que corre en el modo Kernel se llama Ejecutor de Windows, que no es más que un conjunto de servicios disponibles a todos los componentes del Sistema Operativo, donde cada grupo de servicios es manipulado por componentes que son totalmente independientes (entre ellos el Núcleo) entre sí y se comunican a través de interfaces bien definidas.

Todos los programas que no corren en Modo Kernel corren en Modo Usuario. La mayoría del código del Sistema Operativo corre en Modo Usuario, así como los subsistemas de ambiente (Win32 y POSIX que serán explicados en capítulos posteriores) y aplicaciones de usuario. Estos programas solamente acceden a su propio espacio de direcciones e interactúan con el resto del sistema a través de mensajes Cliente/Servidor.

Capitulo 1

Modo Kernel

1.1 – Capa de Abstracción de Hardware (HAL).

Conocido por sus siglas en inglés HAL (Hardware Abstraction Layer) es una interfaz entre el hardware y el resto del Sistema Operativo, está implementada como una biblioteca de enlace dinámico (dll) y es responsable de proteger el resto del sistema de las especificaciones del hardware, tales como controladores de interrupción e interfaces de entrada/salida. Esta abstracción hace al sistema más portable ya que el resto del sistema no tiene que preocuparse sobre que plataforma está corriendo. Cada plataforma en que el sistema corre necesita un HAL específico. El diseño intenta que cuando Windows sea portado a una nueva arquitectura de procesador, el HAL sea reescrito para el nuevo procesador, pero el resto del sistema simplemente debe ser recompilado.

Este también suministra la interfaz para el multiprocesamiento simétrico (conocido por sus siglas en inglés SMP). Las versiones Server contienen dos HALs para arquitectura de procesador (Intel, MIPS, PowerPC y and Alpha), el primero es usado para soportar un solo procesador, mientras que el segundo soporta hasta cuatro procesadores.

Para cada procesador físico que existe en la computadora el HAL representa un procesador virtualizado al microkernel. La idea es que el procesador virtualizado esconda las características especiales del propio procesador al sistema operativo, quiere esto decir que si por ejemplo se tiene dos sistemas multiprocesadores, uno corriendo sobre un procesador Intel y otro corriendo con un Alpha, los HALs en cada sistema serían diferentes, pero los procesadores virtualizados que este presenta al microkernel en ambos casos pudieran ser idénticos. Sobre un sistema SMP (Multiprocesamiento Simétrico) para cada procesador físico en el sistema el HAL representa un procesador virtualizado al microkernel.

A este componente solo pueden acceder componentes del Ejecutor de Windows y nunca se llama por los programas del Modo Usuario. El HAL también intenta ser la única pieza de software dentro del sistema que se comunique con el hardware, la ventaja de esto es que otros programas no pueden escribir información en el hardware ni accidentalmente, ni intencionalmente y causar una caída del sistema, también impidiendo que programas lean información directamente del hardware.

Aunque la meta de Windows es que todas las llamadas relacionas con el hardware sean a través del HAL, la realidad es que un número pequeño de llamadas de los drivers y del Kernel bordean al HAL e interactúan directamente con el hardware.

La capa de Abstracción de Hardware conocida por sus siglas en inglés (HAL) es una biblioteca de manipulación de hardware con rutinas suministradas por Microsoft o por el fabricante del hardware. Esta capa queda en el nivel más bajo del Ejecutor de Windows (entre el hardware y el resto del Sistema Operativo), esta esconde las características de la plataforma para que todas las plataformas y arquitecturas parezcan igual al Sistema Operativo, esto permite al SO correr sobre diferentes plataformas con uno o varios procesadores, facilitando además a los drivers de dispositivos adaptarse a distintas arquitecturas de E/S sin tener que ser modificados en gran medida.

1.2 – MicroKernel

Es el responsable de todas las acciones que se realizan sobre le sistema y casi todas las funciones del sistema pasan a través de él.

El diseño de este componente asigna muchas de las funciones normalmente asignadas al Kernel en los Sistemas Operativos tradicionales a un grupo de programas llamado Ejecutor de Windows, del cual el microkernel es parte, corre en el modo privilegiado y ambos (el ejecutor y el microkernel) se comunican a través de primitivas del sistema operativo a bajo nivel.

La principal tarea de este componente es la planificación de ejecución de hilos (segmento de código perteneciente a un proceso particular). A cada hilo es asignada una prioridad de 0 a 31, este entonces envía hilos a correr en dependencia de su número de prioridad y los permite ejecutarse un tiempo determinado antes de apropiarse de ellos y permitir que otro proceso corra.

Aquí es importante aclarar que el microkernel no planifica la ejecución de procesos, sino que planifica la ejecución de hilos en el entorno de un proceso, este procedimiento es el que hace posible la multitarea con preferencia al ser el microkernel el que planifica la ejecución de todo el código que corre en el sistema.

En un sistema multiprocesador, una copia del microkernel corre en cada procesador. Estos segmentos del microkernel son usados para mantener la coherencia de los recursos del sistema que son compartidos ya que son accedidos por los hilos que corren en todos los procesadores.

Este también es responsable de la manipulación de interrupciones del sistema desde dispositivos físicos. Normalmente cuando el sistema es interrumpido, el microkernel se apropia del hilo que este corriendo en ese momento para procesar la interrupción.

El microkernel también manipula las excepciones del procesador, donde estas excepciones ocurren cuando el procesador intenta hacer alguna operación que no se le está permitida, como el intento de escribir en una porción de memoria a la cual no tiene acceso o cuando se divide por cero.

El uso final del microkernel es suministrar un soporte para la recuperación del sistema de una caída de energía. Si el sistema esta equipado con un suministrador de energía ininterrumpible (más conocido por sus siglas inglés UPS) el microkernel es advertido cuando la caída de energía es detectada, entonces este coordina un cierre ordenado del sistema, el cual incluye la advertencia a los dispositivos de Entrada/Salida de la caída de la energía y permitir entonces restaurarse consecuentemente.

Puesto que el Microkernel está involucrado en la mayoría de las acciones asumidas por el Sistema Operativo, las porciones críticas de este son escritas en lenguaje ensamblador para garantizar que este pueda correr lo más rápido y eficientemente posible, lo que trae consigo que su optimización sea un factor crítico de funcionamiento cuando el sistema es portado a diferentes arquitecturas.

El microkernel está situado en el corazón de Windows, trabaja muy estrechamente con el HAL (Nivel de Abstracción de Hardware), este planifica la ejecución de hilos y manipula las interrupciones y excepciones de procesos. El papel de este es mantener a los procesadores lo mas ocupado posible. En sentido general este se encarga de las funciones más básicas de todo el SO, como son:

  • Ejecución de subprocesos.
  • Sincronización multiprocesador.
  • Manejo de las interrupciones de hardware.

1.3 – El Ejecutor de Windows.

El Ejecutor de Windows se encarga de las tareas importantes, las que son de vital importancia para el sistema completo, ya que el microkernel está casi siempre demasiado ocupado para dirigirse directamente.

Una definición clara es que el Ejecutor de Windows provee los fundamentos del sistema operativo que serán suministradas a todas las aplicaciones que corren sobre el sistema. Este incluye servicios como la Administración de Objetos, de Memoria virtual, de Entrada-Salida y de Procesos.

El Ejecutor de Windows corre exclusivamente en Modo Kernel y es llamado por los subsistemas de ambiente protegido cuando estos necesitan de sus servicios. Debido a la jerarquía de Windows las aplicaciones que corren en Modo Usuario no pueden llamar segmentos del Ejecutor de Windows directamente, sino servicios de demanda de los subsistemas de ambiente (explicado en capítulos posteriores), como Win32 y POSIX los que a su vez se encargan de llamar los componentes del Ejecutor de Windows.

1.4 – El Administrador de Objetos.

El Administrador de Objetos (Object Manager) es usado para crear, modificar y eliminar objetos (tipos de datos abstractos que son usados para representar recursos del Sistema Operativo) usados por todos los sistemas que conforman el Ejecutor de Windows. Este también proporciona información sobre el estado de los objetos a todo el Sistema Operativo.

Los objetos pueden ser cosas concretas, tales como puertos de dispositivos, o pueden ser más abstractos como hilos. Cuando un objeto es creado a este se le da un nombre por el cual otros programas pueden accederle. Cuando un proceso necesita acceder al objeto este solicita un tratamiento de objeto al administrador de objetos. El manipulador de objetos suministra un puntero que es usado para localizar al objeto, así como una información de control de acceso que dice como se puede acceder a el. Esta información de control de acceso es suministrada por el subsistema de seguridad (tema que se abordará en próximos temas).

Este también se asegura que los objetos no consuman muchos recursos (por lo regular la memoria), manteniendo cuotas para los diferentes tipos de objetos.

Además el Administrador de Objetos se encarga de limpiar objetos huérfanos (objetos que parecen no tener dueño), esto es conocido como recolección de basura. La carencia de esta facilidad en Windows 3.x era la causa de muchos problemas, ya que cuando un programa colapsaba o manipulaba incorrectamente los recursos del sistema, los recursos consumidos por este no eran devueltos al sistema para que volvieran a estar disponibles produciendo un error por falta de recursos del sistema. De hecho esto era un escape de memoria.

A modo de resumen el Administrador de Objetos se encarga de crear, destruir y gestionar todos los objetos del Ejecutor de Windows.

1.5 – El Administrador de Procesos.

El Administrador de Procesos (Process Manager) es el responsable de crear, quitar y modificar los estados de todos los procesos e hilos. Este también proporciona información sobre el estado de procesos e hilos al resto del sistema.

Un proceso, por la definición, incluye un espacio de dirección virtual, uno o más hilos, un segmento de código del programa ejecutable, y un conjunto de recursos del sistema. Un hilo es un objeto ejecutable que pertenece a un solo proceso y contiene a un contador del programa que apunta a su posición actual en el segmento de código ejecutable del proceso, dos pilas, y un conjunto de valores del registro.

El Administrador de Procesos, como todos los miembros del Ejecutor de Windows, juega un papel vital en el funcionamiento del sistema entero. Cuando una aplicación comienza su ejecución, se crea como un proceso lo que requiere una llamada al Administrador de Procesos. Como todo proceso debe tener por lo menos un hilo, el Administrador de Procesos es invocado de nuevo para crear el hilo.

El Administrador de Procesos se usa para manejar los hilos, pero no tiene su propio conjunto de políticas sobre cómo planificar la ejecución de procesos e hilos. Estas políticas son determinadas por el propio microkernel.

El administrador de Procesos (Process Manager) es el responsable de crear, quitar y modificar los estados de todos los procesos e hilos, así como de proporcionar información sobre el estado de procesos e hilos al resto del sistema.

1.6 – El Administrador de Memoria Virtual.

El Administrador de Memoria Virtual (Virtual Memory Manager o VMM) proporciona la gestión de memoria virtual del sistema. La memoria virtual es un esquema que permite usar los recursos del disco en lugar de la memoria física del sistema moviendo las páginas al disco cuando estas no están siendo usadas y recuperándolas cuando se les necesitan. Este es un segmento integral de Windows el cual asigna espacios de direcciones de 32 bit a cada proceso sin preocuparse de la cantidad de memoria física del sistema.

A cada proceso se asigna un espacio de memoria virtual de 4GB. De este espacio, los dos giga bites superiores son reservados para el uso del sistema, mientras que los otros dos giga bites restantes son para el uso del proceso. El Administrador de Memoria Virtual es el responsable de traducir las direcciones de memoria del proceso a las direcciones de memoria reales del sistema. Si la dirección de memoria del proceso hace referencia a un segmento de memoria que ha sido paginada hacia el disco, el Administrador de Memoria Virtual recupera la página del disco.

El Administrador de Memoria Virtual se encarga de todo lo relacionado con la política de gestión de la memoria, determina los conjuntos de trabajo de cada proceso, mantiene un conjunto de páginas libres, elige páginas que se van a pasar a la memoria real, sube y baja páginas entre la memoria RAM y el archivo de intercambio en disco.

1.7 – Servicios de Llamadas a Procedimientos Locales.

El Servicio de Llamadas a Procedimientos Locales (Local Procedure Call Facility o LPC) se integran al diseño cliente/servidor de Windows. Este es la interfaz entre todos los procesos clientes y servidores que corren localmente en el sistema.

La estructura del Servicio de Llamadas a Procedimientos Locales es muy similar a la de las llamadas a Procedimientos Remotos (RPC), excepto que esta está optimizada y solamente soporta comunicación entre procesos clientes y servidores localmente. Más específicamente, el LPC es un mecanismo que permite a dos hilos en procesos diferentes intercambiar información.

Recuerde que nosotros dijimos que el subsistema de Win32 es una aplicación que corre en el Modo Usuario y correrá en su propio espacio de memoria. Cuando un programa se quiere comunicar con el subsistema Win32 para solicitar servicios, llama una función desde la DLL apropiada, esta función entonces usa la LPC para pasar la petición al subsistema de procesos Win32, la que procesa la demanda y realiza la acción pedida y devuelve un mensaje de realización a través de la LPC.

El Servicio de Llamadas a Procedimientos Locales es el módulo que se encarga de recibir y enviar las llamadas de procedimiento locales entre las aplicaciones cliente y los subsistemas servidores.

1.8 – El Monitor de Seguridad.

El Monitor de Seguridad (Security Reference Monitor o SRM) es el lecho de toda la seguridad dentro del sistema WINDOWS y es el responsable de hacer cumplir todas las políticas de seguridad en la computadora local.

Este componente trabaja conjuntamente con los subsistemas de tiempo de corrida, proceso de conexión al sistema (conocido como logon process) y control de la seguridad local (local security authority). Cuando un usuario intenta conectarse al sistema su identidad es verificada, el subsistema de proceso de conexión pide una ficha de acceso de seguridad (conocido por sus siglas en inglés SAT o security access token) del usuario. El SAT contiene una lista de los privilegios de usuarios y grupos. Este se usa como llave para ese usuario durante la sesión de conexión. Siempre que el usuario quiera hacer algo, el SAT es presentado y usado para determinar si el usuario puede realizar las acciones.

Este componente trabaja estrechamente con el Administrador de Objetos. Cada vez que un usuario intenta acceder a un objeto el Administrador de Objetos crea un manipulador para acceder a este y llama al SRM para determinar el nivel de acceso concedido por el manipulador. El SRM usa información contenida en la ficha de acceso del usuario y lo compara con la lista de control de accesos sobre el objeto para ver si al usuario debe concederse el nivel de acceso pedido. De esta forma el SRM tiene el control de la seguridad de acceso de todos los objetos en el sistema.

1.9 – El Administrador de Entrada-Salida.

El Administrador de Entrada-Salida (I/O Manager) es responsable de gestionar la comunicación entre los distintos drivers de dispositivo, para lo cual implementa una interfaz bien definida que permite el tratamiento de todos los drivers de una manera homogénea, sin que intervenga el cómo funciona específicamente cada uno. Tiene una serie de subcomponentes que son:

  • Driver del Sistema de Archivos: este se encarga de establecer la comunicación con los drivers de los Sistemas de Ficheros, ya que el sistema permite la coexistencia de múltiples Sistemas de Archivos en diferentes particiones lógicas de la misma unidad física.
  • El servidor y el redirector de red.
  • Los drivers de dispositivo del sistema.
  • El administrador de caches (Cache Manager): este se encarga de manipular la cache para todo el Sistema de Entrada y Salida. Este es un método que utilizan los sistemas de archivos para mejorar su rendimiento, donde en lugar de leer y escribir en disco un fichero usado frecuentemente este se almacena en una cache de memoria y la lectura y escritura de estos ficheros se realiza desde memoria. Este componente se encarga de la magia negra que es a menudo necesaria para hacer que varios dispositivos se comuniquen entre si y convivan juntos en un segmento. El Administrador de Entrada-Salida (I/O Manager) es responsable de gestionar la comunicación entre los distintos drivers de dispositivo.

Capitulo 2

Modo Usuario

2.1 – Subsistemas de Ambiente Protegido

Dos de los objetivos de WINDOWS son personalidad y compatibilidad. Esto ha sido logrado a través de los subsistemas de ambiente protegido.

La personalidad esencialmente significa que WINDOWS expone múltiples conjuntos de interfaces de programas de aplicación (APIs) y puede actuar eficazmente como si fuera un sistema operativo diferente. WINDOWS viene con una personalidad POSIX y OS/2 además de sus personalidades Win32, Win16 y DOS.

En WINDOWS, hay tres subsistemas de ambiente protegido:

  • El subsistema de Win32
  • El subsistema de POSIX
  • El subsistema de OS/2

Aunque algunas veces se muestran las personalidades Win16 y DOS incluidas en una lista de subsistemas de ambiente protegido, ellas realmente son parte del subsistema Win32.

Los subsistemas de ambiente protegido actúan como los mediadores entre las aplicaciones del Modo Usuario y el Ejecutor de Windows.

Recuerde que el Ejecutor de Windows y todos sus componentes viven en el Modo Privilegiado o Modo Kernel, mientras que todos los demás viven en el Modo Usuario, esto incluye todos los subsistemas de ambiente. Cuando una aplicación hace una llamada a un subsistema de ambiente, este es pasado a través de una capa de servicios del Ejecutor de Windows.

Cada subsistema de ambiente guarda huella de sus propios procesos y trabaja independientemente de los otros subsistemas. Cada aplicación sólo puede correr en el subsistema para el cual fue diseñado. Cuando usted inicia una aplicación en WINDOWS, mira el encabezamiento representado por el archivo y determina en cuál subsistema ejecutar la aplicación.

2.2 – El Subsistema Win32

Win32 es el subsistema nativo y primario de WINDOWS. Las bases para este subsistema es el conjunto de APIs de Win32. Muchos de estas API son extensiones directas de sus homólogas Win16.

Este subsistema actúa como un servidor para todos los otros subsistemas de ambiente soportados en WINDOWS, los que actúan como clientes y traducen sus llamadas API hacia las API apropiadas de Win32.

El subsistema Win32 es responsable de toda la entrada y salida. Este posee el control de la pantalla, el teclado, y el ratón. Cuando otros subsistemas, como OS/2 o POSIX, necesitan beneficiarse de estos dispositivos, ellos piden los servicios al subsistema de Win32.

Algunos de los objetivos que se trazaron para mantener la compatibilidad con las aplicaciones hechas en versiones anteriores fueron:

  • Permitir que los programas hechos sobre DOS pudieran correr sin modificación.
  • Suministrar la capacidad para ejecutar la mayoría de las aplicaciones Windows de 16 bits sin modificación
  • Proteger al sistema y otras aplicaciones de 32 bits de la interferencia de las aplicaciones de 16 bits y DOS.
  • Permitir a las plataformas RISC (Reduced Instruction set Computer, microprocesador cuyo número de instrucciones es reducido para lograr una frecuencia más alta de trabajo) ejecutar aplicaciones Windows de 16 bits y DOS.
  • Suministrar un mecanismo para compartir datos entre aplicaciones Windows de 32 y 16 bits.

Muchas personas piensan en Windows 3.x como un Sistema Operativo. Técnicamente, no es un verdadero Sistema Operativo, sino una interfaz de usuario que es miembro del DOS, el verdadero Sistema Operativo.

Así que, el primer paso en proporcionar compatibilidad fue crear un ambiente de DOS. El ambiente de DOS en WINDOWS se llama la máquina virtual de DOS (Machine DOS Virtual o VDM). El VDM es una aplicación de modo usuario de 32 bits el cual solicita los servicios del subsistema de Win32 y en ocasiones directamente a la capa de servicios del sistema. Es basado en DOS 5.0.

WINDOWS permite ejecutar tantas aplicaciones de DOS como uno desee, donde cada aplicación corre en su propio VDM. Puesto que los VDMs son nada más que procesos normales bajo WINDOWS, ellos también son multitarea preventiva al igual que otros procesos en el sistema. Por consiguiente, puede decirse que WINDOWS permite la multitarea preventiva de programas de DOS.

Uno de los rasgos adicionales del VDM es que le da 620 KB de memoria "convencional" libre al usuario. Lo milagroso sobre esto es que también da a las aplicaciones de DOS soporte de ratón, red, y CD-ROM.

El Subsistema Win32 es el más importante, ya que atiende no sólo a las aplicaciones nativas de Windows, sino que para aquellos programas no Win32, reconoce su tipo y los lanza hacia el subsistema correspondiente. En el caso de que la aplicación sea MS-DOS o Windows de 16 bits (Windows 3.11 e inferiores), lo que hace es crear un nuevo subsistema protegido. Así, la aplicación DOS o Win16 se ejecutaría en el contexto de un proceso llamado VDM (Virtual DOS Machine, máquina virtual DOS), que no es más que un simulador de un ordenador funcionando bajo MS-DOS. El subsistema soporta una buena parte del API Win32. Así, se encarga de todo lo relacionado con la interfaz gráfica con el usuario (GUI), controlando las entradas del usuario y salidas de la aplicación.

2.3 – El Subsistema POSIX.

Microsoft prestó mucha atención a los diferentes estándares de sistemas abiertos cuando Windows NT estaba en vía de desarrollo. Ellos reconocieron el valor de soportar sistemas abiertos como un método para ganar aceptación de su nuevo sistema operativo avanzado dentro del mercado.

Uno de los estándares más frecuentemente citados soportados por Windows es el POSIX (Interfaz de Sistema operativo Portable Basado en Unix), el cual representa la interfaz del Sistema Operativo portable y fue desarrollado por el IEEE (Instituto de Ingenieros en Electricidad y Electrónica) como un método de proporcionar portabilidad a las aplicaciones hechas sobre plataformas UNIX. No obstante, POSIX se ha integrado en muchos sistemas no UNIX.

Existen muchos niveles de obediencia con POSIX. Estos niveles representan un conjunto de evoluciones de propuestas, aunque no todas han sido aprobadas como estándares.

El subsistema de POSIX requiere un mínimo de servicios que son proporcionados por WINDOWS. Cuando una aplicación de POSIX corre en WINDOWS, el subsistema es cargado y traduce las llamadas API del lenguaje C, requeridas para soportarlo en llamadas a APIs de Win32 las que son servidas por el subsistema Win32.

Debido a la naturaleza limitada, el subsistema de POSIX en WINDOWS no suministra soporte para gestión de redes o sistema de seguridad.

El Subsistema POSIX interacciona con el Ejecutor de Windows. Se encarga de definir aspectos específicos del Sistema Operativo UNIX, como pueden ser las relaciones jerárquicas entre procesos padres e hijos (las cuales no existen en el subsistema Win32, por ejemplo, y que por consiguiente no aparecen implementadas directamente en el Ejecutor de Windows).

2.4 – El Subsistema OS/2.

El subsistema de OS/2 está implementado como un subsistema de ambiente protegido, parecido al subsistema POSIX. Este traduce las llamadas API de OS/2 en llamadas a APIs de Win32 que son servidas por el subsistema de Win32.

El subsistema y sus aplicaciones corren en su propio espacio de memoria protegido de 32 bits y constituyen multitarea preventiva unas respecto a otras y respecto a otras aplicaciones que corren en el sistema.

Además de un conjunto de motores APIs de OS/2, el subsistema implementa muchos APIs gestores de LAN (Red de Área Local), incluyendo tuberías, NETBIOS y mailslots. De esta manera difiere del subsistema POSIX ya que este no posee soporte para gestión de redes.

El Subsistema OS/2 igual que el subsistema POSIX proporciona un entorno para aplicaciones UNIX, este subsistema da soporte a las aplicaciones OS/2. Proporciona la

interfaz gráfica y las llamadas al sistema; las llamadas son servidas con ayuda del Ejecutor de Windows.

Conclusiones

Windows es un sistema que aprovecha la potencia de los procesadores, ha sido diseñado para adaptarse a las nuevas tecnologías, ofrece compatibilidad con varias plataformas (OS/2, Unix y versiones anteriores a el mismo), soporta el multiprocesamiento simétrico, buen rendimiento y conectividad, seguridad y al no estar encasillado en ningún modelo estandar de Sistema Operativo tiene la capacidad de combinar las ventajas del modelo cliente/servidor, puede correr además sobre múltiples arquitecturas con un mínimo de cambios, permite que varios procesos sean ejecutados simultáneamente en varios procesadores y estos no se apropien de recursos del sistema por tiempo indefinido, sino por tratamiento del sistema.

Bibliografía Consultada

  1. [Solo00] Solomon, David A.y Russinovich Mark "Inside Microsoft Windows 2000". 3ra Edi. Microsoft Press. Washington. 2000.
  2. [Stal98] Stallings, William. "Operating Systems". 3ra Edi. Prentice-Hall, Inc. New Jersey. 1998.
  3. [Stal01] Stallings, William. "Systemas Operativos". 4ta Edi. Pearson Edicación, S.A. Madrid. 2001.
  4. URL: http://www.monografias.com/trabajos7/arso/arso2.shtml
  5. URL: http://www.windowstimag.com/
  6. URL: http://usuarios.lycos.es/betzweb/

 

 

 

Autor:

Marcos Díaz Bastida

Liseyani Brunet Herrera


Comentarios


Trabajos relacionados

  • Sistemas operativos - Componentes de una PC

    La Tarjeta Madre. El Procesador. Tipos de procesadores. Memoria Cache. Partes de la Tarjeta Madre. El Disco Duro. La Mem...

  • Windows 98

    Conocimiento del Escritorio de Windows 98. ¿Cómo trabajar con una ventana?. ¿Cómo utilizar las Barras de desplazamiento?...

  • Sistemas Operativos I (Netware - Novell)

    Concepto y definición de Sistemas operativos. Características de los Sistemas Operativos. Clasificación de los sistemas ...

Ver mas trabajos de Sistemas Operativos

 

Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.


Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

Iniciar sesión

Ingrese el e-mail y contraseña con el que está registrado en Monografias.com

   
 

Regístrese gratis

¿Olvidó su contraseña?

Ayuda