Capítulo I

Análisis de la Investigación

Planteamiento del problema:

El conocer el proceso y administración del desarrollo de un sistema
operativo, así como su implementación para el usuario final.

Árbol del problema:

Mejor Mejor Ayudar a

aprovechamie comprensión coprender el
nto de
Su evolución.
Del sistema De su
operativo. administración
.

Conocer el
proceso,
desarrollo e
implementa
ción.
Exceso de información. Falta de conocimiento. Evoluvión constante de

Los sitemas operativos

Objetivo:
 Determinar el porcentaje de personas que conocen y aplican un sistema
operativo.
 Conocer el proceso, la estructura básica de los sistemas operativos.
 Identificar los factores que impiden el conocimiento de un sistema
operativo en cuanto a sus características.

Hipótesis:
 80% de la población no conoce lo que es un sistema operativo.
 Más de la mitad de los usuarios que conocen la estructura básica de un
sistema operativo, son estudiantes de una carrera referente a tecnologías
de la información.

Preguntas de Investigación:
 ¿Qué porcentaje de personas conocen y aplican un sistema operativo?
 ¿Cuál es la estructura básica de un sistema operativo?
 ¿Qué factores influyen para impedir el conocimiento de un sistema
operativo en cuanto a sus características?

Justificación:
Día a día el mundo entero se encentra en el juego de la competitividad, ya que
contantemente se siguen innovando las tecnologías que conocemos, para hacerlas mucho
más eficientes y rendidoras. Es por ello que una de las herramientas que se utilizan en el
mundo es una computadora, la utilizamos desde hacer un simple documento de texto
hasta hacer diseños, imágenes y software, es ahí cuando entra la innovación constante de
esta herramienta tan importante, ya que, bien sabemos, cada día más personas se hacen
de esta herramienta, es por ello que es necesario conocer los más recientes avances en
sistemas operativos para el beneficio del usuario.

Por lo tanto es mejor el rendimiento que se ofrece, y mejor el servicio que se

presta al usuario con un sistema operativo.
 Esta investigación se justifica desde el punto de vista teórico.

Desde el punto de vida teórico, esta investigación generara un conocimiento básico

sobre un sistema operativo dejando afuera el exceso de información que existe conforme
a este tema, se empleara en el mejoramiento de uso usuario-máquina, aparte de dar a
conocer sistemas operativos diversos.

Delimitación:
Tiempo:
Esta investigación comprende los estudios a realizar desde el mes de febrero del
2011 al mes de mayo del mismo año. Los documentos, artículos y materias orientadas a
esta investigación están constantemente en innovación.

Espacio:
El uso de una computadora es casi mundial, ya que es una herramienta
indispensable en empresas desarrolladamente en tecnología, ya que lleva consigo un
sistema operativo consigo para el manejo de su hardware y su software para el usuario.

Actualmente se siguen innovando nuevos y mejores sistemas operativos

especializados para las empresas en el mundo.

Delimitación Geográfica:
País: México.

Estado: Zacatecas

Institución: Instituto Tecnológico Superior de Fresnillo, Av. Tecnológico No. 2000

Col. Solidaridad, Fresnillo de Gonzales Echeverría.

En todo el país cualquiera puede hacer uso de un sistema operativo en sí, pero sin
conocer lo que es, para que sirve y como funciona, en el Instituto Tecnológico Superior de
Fresnillo existen tres carreras orientadas a la utilización e implementación de los sistemas
operativos (Ingeniería en Sistemas Computacionales, Ingeniería en Informática y
Licenciatura en Informática).
Delimitación Académica:
Sector Educacional: Púbico, Estatal.

Organización Primaria: Instituto Tecnológico Superior de Fresnillo.

Centro de Estudios: ITSF.

Plantel: Fresnillo.

Área de Estudios: Ciencias Tecnológicas.

Línea de Investigación: “Sistemas Operativos”.

 Capítulo II
Estructura Básica de los Sistemas Operativos

1. ¿Qué es un sistema operativo?

Un sistema operativo es un programa que actúa como una interfaz entre el

usuario de un ordenador y el hardware del mismo, ofreciendo el entorno necesario
para que el usuario pueda ejecutar programas. Así, su principal objetivo es facilitar
el uso del sistema informático.

El sistema operativo es una parte importante de cualquier sistema

informático. A grandes trazos, todo sistema informático puede dividirse en:

 El hardware (CPU, memoria, dispositivos de E/S).

 El sistema operativo.
 Los programas de aplicación (compiladores, sistemas de base de
datos, videojuegos, programas de administración de empresas).
 Los usuarios (personas, máquinas u otros ordenadores).

Usuario Usuario Usuario Usuario

...
1 2 3 n

… Base de
Compila Ensambl Editor de
dor ador texto datos
Programas de Aplicación

Sistema Operativo

Hardware
Imagen 1.1
 El hardware facilita los recursos básicos de computación. Los programas de
aplicación definen cómo hay que utilizar estos recursos para resolver los problemas de los
usuarios. Puede haber muchos usuarios diferentes tratando de resolver problemas
distintos. Consecuentemente, puede haber muchos programas de aplicación distintos. El
sistema operativo controla y coordina el uso del hardware por parte de los distintos
programas de aplicación de los diversos usuarios.

Un sistema operativo es similar a un gobierno. Los recursos básicos de un sistema

informático son el hardware, el software y los datos. El sistema operativo facilita los
medios para el uso adecuado de estos recursos durante la operación del sistema
informático. Al igual que un gobierno, el sistema operativo no realiza por sí mismo una
función útil, simplemente crea el entorno en el que otros programas puedan hacer un
trabajo útil.

Podemos considerar un sistema operativo como un asignador de recursos. Un

sistema informático tuene muchos recursos (hardware y software) susceptibles de ser
requeridos para resolver un problema: tiempo de CPU, espacio en memoria, espacio de
almacenamiento en ficheros, dispositivos de entrada/salida (E/S), etc. El sistema operativo
actúa como el gestor de estos recursos y los asigna a programas y usuarios específicos,
según las necesidades de recursos, posiblemente conflictivos entre sí, el sistema operativo
tiene que decidir a qué solicitudes asignan los recursos para que el sistema informático
opere fácil y eficientemente.

Una concepción ligeramente distinta del sistema operativo se centra en la

necesidad de controlar los distintos dispositivos de E/S y los programas de usuario. Un
sistema operativo es un programa de control. (Como mínimo, tres sistemas operativos
incorporan este concepto en su nombre: el MCP (Master Control Program) empleado en
los ordenadores Burroughs, el CP/67 (Control Program) del IBM 360/67 y el CP/M (Control
program for Microcomputers) muy extendido por su empleo en los microordenadores.)
Un programa de control supervisa la ejecución de los programas de usuario para evitar
errores y el uso inadecuado del ordenador. A él concierne especialmente la operación y el
control de los dispositivos de E/S.

Sin embargo, en general, no existe una definición completamente adecuada de

sistema operativo. Los sistemas operativos existen porque son una vía razonable para
resolver el problema de crear un sistema informático manejable. El objetivo fundamental
de un sistema informático es ejecutar los programas de usuario y resolver sus problemas.
El hardware se diseña con este propósito. Como el hardware por sí solo no es fácil de
utilizar, se desarrollan programas de aplicación. Los distintos programas requieren ciertas
operaciones comunes, tales como el control de los dispositivos de E/S. Las funciones
corrientes de control y asignación de recursos se reúnen en una pieza de software: el
sistema operativo.

Posiblemente sea más sencillo definir los sistemas operativos por lo que hacen más
que por lo que son. Su objetivo fundamental es la utilidad para el usuario. Los sistemas
operativos existen porque se supone que es más fácil utilizar el ordenador con ellos que
sin ellos. Esto se aprecia claramente cuando se observan los sistemas operativos para
pequeños ordenadores personales.

El funcionamiento eficiente del sistema informático, es un objetivo secundario

especialmente importante en los grandes sistemas multiusuario. Tales sistemas suelen ser
muy caros y por tanto es deseable que sean lo más eficiente posible. Estos dos objetivos,
utilidad y eficiencia, a veces son contradictorios. En el pasado, las consideraciones de
eficiencia solían ser más importantes que la utilidad. Así, gran parte de la teoría de los
sistemas operativos se encuentra en el uso óptimo de los recursos del ordenador.

Para ver qué son y qué hacen los sistemas operativos, revisaremos su desarrollo
durante los últimos treinta años. Siguiendo esta evolución podremos identificar los
elementos corrientes de los sistemas operativos y veremos cómo y por qué se han
desarrollado como lo han hecho.
 Los sistemas operativos y la arquitectura del ordenador se han influido
mutuamente. Para facilitar el empleo del hardware se desarrollaron los sistemas
operativos. A medida que se diseñaban y utilizaban, se hizo obvio que ciertos cambios en
el diseño del hardware podrían simplificar los sistemas operativos. En este breve repaso
histórico, se observará que la introducción de nuevas características del hardware es la
solución natural a muchos problemas de los sistemas operativos.

1.1 Los primeros sistemas.

Inicialmente, lo único que existía era el hardware del ordenador. Los primeros
ordenadores eran (físicamente) máquinas muy grandes que ejecutaban directamente
desde la consola del operador. Primero el programa tenía que ser cargado manualmente
en la memoria, bien fuera desde los conmutadores del panel frontal, desde cinta de papel
o mediante tarjetas perforadas. Seguidamente se pulsaban los botones apropiados para
cargar la dirección de inicio y para empezar la ejecución del programa. A medida que se
ejecutaba el programa, el programador / operador seguía su ejecución por medio de lis
pilotos de la cónsola {1}. Si se descubría algún error el programador podía detener el
programa, examinar el contenido de la memoria y os registros, y depurar el programa
directamente desde la consola. La salida se imprimía, o bien se perforaba sobre cina de
papel o sobre tarjetas para ser impresa más tarde.

Un aspecto importante de este entorno era su naturaleza directamente interactiva.

El programador eral el operador. La mayoría de los sistemas utilizaban un método de
reservas por solicitud para asignar el tiempo máquina. Si uno quería utilizar el ordenador,
iba a la hoja de solicitud, miraba cuál era el siguiente periodo libre que le convenía y lo
solicitaba.

No obstante, este método planteaba algunos problemas. Supongamos que alguien

había solicitado una hora de tiempo de ordenador para ejecutar un programa que estaba
desarrollando. Podría encontrarse con un error particularmente enojoso y ser incapaz de
acabar en una hora. Solo alguien había reservado el siguiente bloque de tiempo, tendría
que parar, recoger lo que pudiera y volver más tarde para terminar. Por otra parte, si las
cosas funcionaban realmente bien, podrían acabar en 35 minutos. Puesto que había
pensado que podría necesitar la máquina durante más tiempo, había reservado una hora,
y de ese modo la máquina permanecía inactiva durante 25 minutos.

Con el tiempo, el hardware y el software se fueron perfeccionando. Aparecieron

los lectores de tarjeta, impresoras de línea y cintas magnéticas. Se diseñaron
ensambladores, cargadores y enlazadores para facilitar la tarea de programación. Se
crearon librerías de funciones corrientes que podían ser copiadas en programas nuevos
sin tener que volver a escribirlas.

Las rutinas que realizaban entradas y salidas eran especialmente importantes.

Cada nuevo dispositivo de E/S tenía sus propias características y requerían una cuidadosa
programación. Se escribía una subrutina especial para cada dispositivo de E/S. Tal
subrutina se llama controlador del dispositivo. Un controlador de dispositivo sabe cómo
utilizar los buffers, indicadores, registros, bits de control, y bits de estado de un dispositivo
dado. Cada tipo diferente de dispositivo tiene su propio controlador. Una tarea sencilla, tal
como leer un carácter de una lectora de cinta de papel, podrían implicar complejas
secuencias de operaciones específicas de un dispositivo. En lugar de escribir el código
necesario cada vez, se utilizaba sencillamente el controlador que estaba en la librería.

Más tarde aparecieron compiladores de Fortran, Cobol y otros lenguajes, haciendo

mucho más sencilla la programación, pero más compleja la operación del ordenador. Por
ejemplo, para preparar la ejecución de un programa en Fortran en el ordenador. El
compilador estaba normalmente en cinta magnética, de modo que había que montar la
cinta adecuada sobre un dispositivo de cinta. El compilador de Fortran generaba una
salida en lenguaje ensamblador que tenía que ser ensamblada. Esto requería el montaje
de otra cinta con el ensamblador. La salida del ensamblador tenía que enlazarse con sus
rutinas de apoyo procedente de la librería. Finalmente, el programa objeto en binario
quedaba listo para su ejecución y podía cargarse en memoria y depurarse desde la
consola.

Obsérvese que la ejecución de un trabajo podía implicar un tiempo de preparación

considerable. Cada trabajo estaba formado por muchos pasos independientes: carga de la
cinta con el compilador de Fortran, ejecución del compilador, ejecución del ensamblador,
descarga de la cinta del ensamblador, carga del programa objeto y ejecución del programa
objeto. Si se producía un error en cualquiera de los pasos quizá había que empezar de
nuevo desde el principio. Cada paso podían implicar la carga y descarga de cintas
magnéticas, cintas de papel y/o tarjetas. (PATERSON, J. L. Y SILBERSCHATZ, A., 1993).

{1} El autor tiene un error de sintaxis (cónsola), consola.

1.2 Estructuras de los sistemas operativos.

Un sistema operativo proporciona el ambiente dentro del cual ejecutan los

programas. Internamente, los sistemas operativos tienen gran variación en su
composición y están organizados en muchas líneas diferentes. El diseño de un nuevo
sistema operativo es una tarea de gran envergadura. Es importante definir bien los
objetivos del sistema antes de comenzar su diseño. El tipo de sistema desead es la base
para elegir entre los diversos algoritmos y estrategias.

Existen varios puntos de vista desde los cuales se puede ver un sistema operativo.
Uno consiste en examinar los servicios que proporciona; otro implica analizar la interfaz
que pone a disposición de los usuarios y los programadores. Un tercero consiste en
desensamblar el sistema en sus componentes y sus interconexiones.
1.2.1 Componentes del sistema

Podemos crear un sistema tan grande y complejo como es un sistema operativo sólo si los
descomponemos en piezas más pequeñas. Cada una de estar piezas deberá ser una porción bien
delineada del sistema, con entradas, salidas y funciones definidas con cuidado. Obviamente
comparten la meta de soportar los componentes del sistema.

1.2.1.1 Administración de procesos

Un programa no tiene efecto a menos que sus instrucciones sean ejecutadas por una CPU.
Un proceso que pueden considerarse como un programa en ejecución, pero su definición se
ampliará a medida que lo exploremos más. Un programa de usuario en tiempo compartido, tal
como un compilador, es un proceso. Un programa de edición de texto ejecutado por un usuario
individual en una PC es un proceso. Una tarea del sistema, como el envío de salida a la impresora,
también es un proceso. Por ahora, usted puede considerar que un proceso es un trabajo o un
programa en tiempo compartido, pero después aprenderá que el concepto es más general.

Un proceso necesita recursos –incluyendo tiempo de la CPU, memoria, archivos y

dispositivos de E/S- para realizar una tarea. Estos recursos son dados al proceso cuando se crea, o
el son asignados mientras está en ejecución. Además de los diversos recursos finitos (entrada)de
inicialización. Por ejemplo, considere un proceso cuya función es mostrar el estado de un archivo,
y ejecutará las instrucciones apropiadas y las llamadas al sistema para obtener y exhibir en la
terminal la información deseada. Cuando el proceso termina, el sistema operativo reclamará todos
los recursos reutilizables.

Hacemos énfasis en que un programa por sí mismo no es un proceso; un programa es una

entidad pasiva, como los contenidos de un archivo almacenado en disco, en tanto que un proceso
es una entidad activa, con un contador de programa especificando la siguiente instrucción a
ejecutar. La ejecución de un proceso debe ser secuencial. La CPU, ejecuta una tras otra las
instrucciones del proceso, hasta que éste se completa. Además, en tanto, aunque dos procesos
pueden estar asociados con el mismo programa, se les considera como dos secuencias distintas de
ejecución. Es común tener un programa que genera muchos procesos a medida que se ejecuta.
 Un proceso es la unidad de trabajo en un sistema. Tal sistema consta de un conjunto de
procesos, algunos de los cuales son del sistema operativo (aquéllos que ejecutan código del
sistema) y el resto son de usuario (que ejecutan código de usuario). Todos estos procesos pueden
potencialmente ejecutarse de manera concurrente, multiplexando a la CPU entre ellos.

El sistema operativo es responsable de las siguientes actividades relacionadas con la

administración de procesos:

 Crear y eliminar procesos de usuario y procesos del sistema.

 Suspender y continuar procesos.
 Proporcionar mecanismos para la sincronización de procesos.
 Proporcionar mecanismos para la comunicación de procesos.
 Proporcionar mecanismos para el manejo de bloqueos mutuos.

1.2.2 Administración de la memoria principal.

La memoria principal es un componente central en la operación de un sistema de

cómputo moderno; es un arreglo grande de palabras o bytes, cuyo tamaño va desde
cientos de miles hasta miles de millones, cada palabra o byte tiene su propia dirección;
también es un depósito de datos a los que se puede tener acceso rápidamente y los cuales
son compartidos por la CPU y los dispositivos de E/S. El procesador central lee las
instrucciones de la memoria principal durante el ciclo de obtener-instrucción, y lee y
escribe datos de ésta durante el ciclo de obtener-datos. Las operaciones E/S
implementadas vía DMA también leen y escriben datos en la memoria principal. La
memoria principal es el único dispositivo de gran almacenamiento que la CPU es capaz de
direccionar, y al que puede tener acceso de manera directa. Por ejemplo, para que la CPU
procese datos del disco, dichos datos deben ser transferidos, primero, a la memoria
principal por medio de llamadas de E/S generadas por la CPU. De manera equivalente, las
instrucciones deben estar en la memoria para que la CPU las ejecute.
 Para que un programa se ejecute, debe convertirse en un mapa de direcciones
absolutas y cargarse en memoria. A medida que el programa se ejecuta, accede a
instrucciones y datos de memoria, generando estas direcciones absolutas. Transcurrido
cierto tiempo, el programa termina, su espacio de memoria se declara disponible, y el
siguiente programa puede cargarse y ejecutarse.

Para mejorar tanto el uso de la CPU como la velocidad de respuesta de la

computadora a sus usuarios, debemos mantener varios programas en la memoria. Existen
muchos esquemas diferentes para administrar la memoria. Estos esquemas se reflejan en
diversos enfoques para la administración de la memoria, y la eficiencia de los diferentes
algoritmos depende de la situación particular. La selección de un esquema de
administración para un sistema específico depende de muchos factores – especialmente
el diseño del hardware del sistema. Cada algoritmo requiere su propio soporte hardware.

El sistema operativo es responsable de las siguientes actividades relacionadas con

la administración de la memoria:

 Llevar un registro de las partes de la memoria que están siendo utilizadas en el

momento y quién las está utilizando.
 Decidir qué procesos se van a cargar en la memoria cuando el espacio de la misma
esté disponible.
 Asignar y liberar espacio de la memoria según se necesite.

1.2.3 Administración de archivos.

La administración de archivos es uno de los componentes más visibles en un

sistema operativo. Las computadoras pueden almacenar información en varios tipos
diferente3s de medios físicos. La cinta magnética, el disco magnético y el disco óptico son
los medios más comunes. Cada uno de éstos tiene sus propias características y
organización física. Cada medio es controlado por un dispositivo, como una unidad de
disco o una unidad de cinta, que también tiene características propias únicas. Estas
propiedades incluyen velocidad de acceso, capacidad, velocidad de tranferencia de datos
y método de acceso (secuencial o aleatorio).

Para un uso conveniente del sistema de cómputo, el sistema operativo

proporciona una visita lógica uniforme del almacenamiento de la información. Este
sistema hace una abstracción de la propiedad física de sus dispositivos de
almacenamiento para definir una unidad de almacenamiento lógico, el archivo. El sistema
operativo hace un mapa de los archivos en los medios físicos y accede a estos archivos vía
los dispositivos de almacenamiento.

Un archivo es un conjunto de información relacionada definida por su creador.

Comúnmente, los archivos representan programas (tanto en forma d fuente como de
objeto) y datos. Los archivos de datos pueden ser numéricos, alfabéticamente o
alfanuméricos. Asimismo, pueden ser de forma libre (por ejemplo, archivos de texto), o
pueden tener un formato rígido (por ejemplo, campos fijos). Un archivo consta de una
secuencia de concepto de archivo es un concepto en extremo general.

El sistema operativo implementa el concepto abstracto de un archivo

administrando medios de almacenamiento masivo, como cintas y discos, y los dispositivos
que los controlan. Asimismo, los archivos por lo regular están organizados en directorios
para facilitar su uso. Finalmente, cuando varios usuarios tienen acceso a los archivos,
resulta deseable controlar dicho acceso y en qué forma (por ejemplo, leer, escribir,
anexar).

El sistema operativo es responsable de las siguientes actividades relacionadas con

la administración de archivos:

 Crear y eliminar archivos.

 Crear y eliminar directorios.
 Dar soporte a primitivas para la manipulación de archivos y directorios.
 Hacer mapa de los archivos en el almacenamiento secundario.
  Respaldar archivos en medios de almacenamiento estables (no volátiles).

1.2.4 Administración del sistema de E/S.

Uno de los propósitos de un sistema operativo es ocultar al usuario las

peculiaridades de los dispositivos específicos de hardware. Por ejemplo, en Unix, el
subsistema de E/S oculta las particularidades de los dispositivos de E/S al resto del sistema
operativo mismo.

El subsistema de E/S consta de:

 Un componente de administración de memoria que incluye manejo de buffers,

asignación de caché y spooling (operación simultánea de periféricos en línea).
 Una interfaz general de manejadores de dispositivo.
 Controladores para dispositivos de hardware específicos.

Sólo el manejador de dispositivos conoce las peculiaridades del sistema específico

al cual está asignado.

Administración del almacenamiento secundario.

2. Estructura del sistema operativo.

2.1 Sistemas monolíticos.

Esta organización, que por mucho es la más común, bien podría calificarse como “El Gran
Embrollo”, La estructura consiste en que no hay estructura. El sistema operativo se escribe
como una colección de procedimientos, cada uno de los cuales puede invocar a cualquiera
de los otros cuando lo necesita. Si se utiliza esta técnica, cada procedimiento del sistema
tiene una interfaz bien definida desde el punto de vista parámetros y resultados, y cada
una está en libertad de invocar a cualquier otra, si ésta realiza alguna operación útil que la
primera necesita.

Para construir el programa objeto del sistema operativo se adopta este enfoque, lo
primero que se hace es compilar todos los procedimientos individuales, o archivos que
contienen los procedimientos, y luego unirlos todos en un solo archivo objeto, utilizando
el enlazador del sistema. Respecto al ocultamiento de la información, éste prácticamente
no existe: cualquier procedimiento puede ver cualquier otro (en contraposición con una
estructura que contiene módulos o paquetes, en la que gran parte de la información
queda oculta dentro de módulos, y desde afuera del módulo sólo se pueden invocar los
puntos de ingreso oficialmente designados).

Incluso en los sistemas monolíticos, empero, es posible tener al menos un poco

estructura. Los servicios (llamadas al sistema) que presta el sistema operativo se solicitan
colocando los parámetros en un lugar bien definido (la pila), y ejecutando después una
instrucción TRAP.

Esta instrucción cambia la máquina de modo de usuario a de kernel y transfiere el

control al sistema operativo. Entonces, el sistema operativo obtiene los parámetros y
determina cuál llamada al sistema debe ejecutarse. Después usa el número de llamada k
como índice para buscar en una tabla apuntador al procedimiento que la realiza.

Esta organización sugiere una estructura básica para el sistema operativo:

1. Un programa principal que invoca el procedimiento de servicio solicitado.

2. Un conjunto de procedimientos de servicio que ejecutan las llamadas al
sistema.
3. Un conjunto de procedimientos utilitarios que apoyan a los procedimientos de
servicio.

En este modelo, por cada llamada al sistema hay un procedimiento de servicio que
se encarga de ella. Los procedimientos utilitarios hacen cosas que varios
 procedimientos de servicio necesitan, como obtener datos de los programas de
usuarios. Esta división de los procedimientos en tres capas se muestra en la figura
2.3.

Imagen 2.1

2.2. Sistemas en capas

Una generalización del enfoque de la figura anterior consiste en organizar el

sistema operativo en una jerarquía de capas, cada una cimentada en la que está
abajo. El primer sistema construido de esta manera fue THE, creado en la
Technische Hogescool Eindhoven en los Países Bajos por E. W. Dijstra (1969) y sus
estudiantes. El sistema THE era un sencillo sistema por lotes para una
computadora holandesa, la Electrologica X8, que tenía 32K de palabras de 27 bits
(los bits eran costosos en ese entonces).

El sistema tenía seis capas, como se muestra en la figura siguiente. LA capa

0 se ocupaba de la asignación del procesador, conmutando entre procesos al
presentarse interrupciones a expirar temporizadores. Arriba de la capa 0, el
sistema consistía en procesos secuenciales, cada uno de los cuales podía
programarse sin tener que preocuparse por el hecho de que varios procesos
estuvieran ejecutando en un solo procesador. En otras palabras, la capa 0 hacía
posible la multiprogramación básica de la CPU.
Imagen 2.2

La capa 1 se encargaba de la administración de memoria: repartía espacio a

los procesos en la memoria principal y en un tambor de palabras 512K en el que se
guardaban las partes de los procesos (páginas) que no cabían en la memoria
principal. Arriba de la capa 1, los procesos no tenían que preocuparse por saber si
estaban en la memoria o en el tambor; el software de la capa 1 se encargaba de
que las páginas se transfieran a la memoria se les necesitaba.

La capa 2 manejaba la comunicación entre cada proceso y la consola del

operador. Arriba de esta capa era como si cada proceso tuviera su propia consola
de operador. La capa 3 se encargaba de administrar los dispositivos de E/S y
colocar en búferes los flujos de información hacia y desde ellos. Arriba de la capa 3
cada proceso podía tratar con dispositivos de E/S abstractos con propiedades
ligeras, en lugar de dispositivos reales con muchas peculiaridades. En la capa 4
estaban los programas de usuario, que no tenían que preocuparse por la
administración de procesos, memoria, consola o E/S. El proceso del operador del
sistema se ubicaba en la capa 5.

Una generalización adicional del concepto de capas sucedió en el sistema

MULTICS. En ligar de capas, el sistema MULTICS tenía una serie de anillos
concentrados, siendo los interiores más privilegiados que los exteriores (lo cual es
efectivamente lo mismo). Cuando un procedimiento de un anillo exterior quería
invocar a uno de un anillo interior, tenía que emitir el equivalente de una llamada
al sistema, es decir, una instrucción TRAP cuyos parámetros se verificaban
cuidadosamente para comprobar que fueran válidos, antes de permitir que se
efectuara la llamada. Aunque en MULTICS todo el sistema operativo formaba parte
del espacio de direcciones de cada proceso de usuario, el hardware permitía
designar procedimientos individuales (en realidad, segmentos de memoria) como
protegidos contra lectura, escritura o ejecución.

Si bien el esquema de capas de THE no era más que una ayuda para el
diseño, porque última instancia todas las partes del sistema se enlazaban en un
solo programa objeto, en MULTICS el mecanismo de anillos sí estaba muy presente
en el momento de la ejecución y el hardware hacía que se respetara. La ventaja del
mecanismo de anillos es que puede extenderse con facilidad para estructurar los
subsistemas de usuario. Por ejemplo, un profesor podría escribir un programa para
probar y calificar los programas de los estudiantes y ejecutarlo en el anillo n,
mientras que los programas de usuario se ejecutarían en el anillo n + 1 para que no
pudieran alterar sus calificaciones.

2.4 Máquinas virtuales

Las primeras versiones de OS/360 eran estrictamente sistemas por lotes.

No obstante, muchos usuarios de la 360 querían tener tiempo compartido, así que
diversos grupos, tanto dentro como fuera de IBM, decidieron escribir sistemas de
tiempo compartido oficial de IBM, TSS/360, se tardó mucho, y cuando por fin llegó
era tan grande y lento que pocos sitios efectuaron la conversión. AL final se le
abandonó después de que su desarrollo había consumido alrededor de 50 millones
de dólares (Graham, 1970). No obstante, un grupo del Centro Científico de IBM,, en
Cambridge, Massachusetts, produjo un sistema radicalmente distinto, que IBM al
final aceptó como producto y que ahora se utiliza en forma amplia en los
mainframes que subsisten.

Este sistema, llamado originalmente CP/CMS y rebautizado más delante

como VM/370 (seawright y MacKinnon, 1979), se basaba en una observación
aguda: un sistema de tiempo compartido proporciona 1) multiprogramación y 2)
una máquina extendida con una interfaz más cómoda que el hardware desnudo. La
esencia del VM/370 consiste en separar por completo estas dos funciones.

El corazón del sistema, llamado monitor de máquina virtual, se ejecuta en el

hardware desnudo y realiza la multiprogramación, proporcionando no una, sino
varias máquinas virtuales a la capa inmediatamente superior, como se muestra en
la figura (siguiente). Sin embargo, a diferencia de todos los demás sistemas
operativos, estas máquinas virtuales no son máquinas extendidas, con archivos y
otras monerías. Más bien, son copias exactas del hardware desnudo que incluyen
modo de kernel/usuario, E/S, interrupciones y todo lo demás que tiene la máquina
real.

Imagen 2.3

Dado que cada máquina virtual es idéntica al hardware verdadero, cada una
puede ejecutar cualquier sistema operativo ejecutable directamente en el
hardware desnudo. Diferentes máquinas virtuales pueden ejecutar sistemas
operativos distintos, y a menudo lo hacen. Algunas ejecutan uno de los
descendientes de OS/360 para el procesamiento de transacciones en lotes,
mientras que otras ejecutan un sistema interactivo monousuario llamado CMS
(Sistema Monitor de Conversaciones; Conversational Monitor System) para
usuarios interactivos de tiempo compartido.
 Cuando un programa CMS ejecuta una llama al sistema, ésta salta
(mediante TRAP) al sistema operativo en su propia máquina virtual, no a VM/370,
como haría si se estuviera ejecutando en una máquina real, no virtual. Luego CMS
emite las instrucciones de E/S normales para leer su disco virtual, o lo que sea que
se necesite para ejecutar la llamada. VM/370 atrapa estas instrucciones de E/S y
luego las ejecuta como parte de su simulación del hardware real. Al separar por
completo las funciones de la multiprogramación y proporcionar una máquina
extendida, cada una de las partes puede ser mucho más sencilla, más flexible y más
fácil de mantener.

El concepto de máquina virtual se usa mucho hoy en día en un contexto

distinto: la ejecución de programas viejos para MS-DOS en una Pentium (u otra
CPU Intel de 32 bits). Al diseñar la Pentium y su software, tato Intel como Microsoft
se percataron de que mucha gente querría ejecutar software viejo en hardware
nuevo. Por ello, Intel incluyó un modo 8086 virtual en la Pentium. En este modo, la
máquina actúa como una 8086 (que es idéntica a una 8088 desde el punto de vista
del software), hasta con direccionamiento de 16 bits con un límite de 1 MB.

Windows y otros sistemas operativos utilizan este modo para ejecutar

programas de MS-DOS. Estos programas se inician en modo 8086 virtual. En tanto
ejecuten instrucciones normales, se ejecutarán en el hardware desnudo, pero
cuando un programa trate de saltar al sistema operativo para efectuar una llamada
al sistema, o intente realizar operaciones protegidas de E/S en forma directa, se
efectuara un salto (TRAP) al monitor de máquina virtual.

Este diseño puede tener dos variantes. En el primero, MS-DOS se carga en

el espacio de direcciones del a 8086 virtual, de modo que lo único que hace el
monitor de máquina virtual es rebotar el salto a MS-DOS, como sucedería en una
8086 real. Más adelante, cuando MD-DOS trate de realizar la E/S él mismo, la
operación será atrapada y ejecutada por el monitor de máquina virtual.
 En la otra variante, el monitor de máquina virtual se limita a atrapar el
primer salto y efectuar él mismo la E/S, pues ya que conoce todas las llamadas ak
sistema de MS-DOS y, por tanto, sabe qué debe hacer cada salto (TRAP). Esta
variante es menos pura que la primera, puesto que sólo emula MD-DOS
correctamente, no otros sistemas operativos, como hace la primera. Por otra
parte, es mucho más rápida, pues ahorra el trabajo de iniciar MS-DOS para que
realice E/S. Una desventaja adicional de ejecutar realmente MS-DOS en modo 8086
virtual es que MS-DOS se mete mucho con el bit que habilita/inhabilita las
interrupciones, y la emulación de esto es muy costosa.

Vale la pena señalar que ninguno de estos enfoques en realidad es igual al

del VM/370, pues la máquina emulada no es una Pentium completa, sólo una
8086. Con el sistema VM/370 es posible ejecutar el VM/370 mismo en la máquina
virtual. Con al Pentium no es posible ejecutar Windows, digamos, en la 8086
virtual, porque ninguna versión de Windows se ejecuta en una 8086; una 286
(mucho menos emulación de Pentium). No obstante, basta modificar un poco el
binario de Windows para hacer posible esta emulación, y esto se ha incorporado
en algunos productos comerciales.

Otra área en la que se usan máquinas virtuales, pero de forma un tanto

distinta, es en la ejecución de programas en Java. Cuando Sun Microsystems
inventó el lenguaje de programación Java, también inventó una máquina virtual (es
decir, una arquitectura de computadora) llamada JVM (Máquina Virtual de Java;
Java Virtual Machine). El compilador de Java produce código para la JVM, que por
lo regular es ejecutado por un intérprete de JVM en software. La ventaja de este
enfoque es que el código JVM puede enviarse por Internet a cualquier
computadora que tenga un intérprete de JVM y ejecutarse allí. Si el compilador
hubiera producido un compilador que produjera binarios para SPARC o Pentium,
por ejemplo, no se podrían haber enviado y ejecutado en cualquier lugar con tanta
facilidad. (Desde luego, Sun podría haber producido un compilador que produjera
binarios para SPARC y luego distribuido un intérprete de SPARC, pero JVM es una
arquitectura mucho más sencilla que se presta a la interpretación.) Otra ventaja de
usar JVM es que si el intérprete se implementa como se debio, lo cual no es del
todo trivial, es posible verificar que los programas JVM que lleguen sean seguros y
luego ejecutarlos en un entorno protegido para que no puedan robar datos ni
causar perjuicios.

2.5 Exokernels

Con el VM/370, cada proceso de usuario obtiene una copia exacta de la

computadora real. Con el modo 808 virtual en la Pentium, cada proceso de usuario
obtiene una copia exacta de una computadora distinta. Yendo un paso más lejos,
investigadores del MIT han construido un sistema que proporciona a cada usuario
un clon de la computadora real, pero con un subconjunto de los recursos (Engler et
al., 1995). Así, una máquina virtual podría obtener los bloqueos de disco del 0 al
1023, la siguiente podría recibir los bloques del 1024 al 2047, y así e forma
sucesiva.

En la capa más baja, ejecutándose en modo de kernel, está un programa

llamado exokernel. Su labor consiste en asignar recursos a las máquinas virtuales y
luego examinar cualquier intento de usuarlos para garantizar qe ninguna máquina
utilice los recursos de otra. Cada máquina virtual en nivel de usuario puede
ejecutarse su propio sistema operativo, como en el VM/370 y las 8’86 virtuales de
Pentium, sólo que cada una está limitada a los recursos que solicitó y le fueron
asignados.

La ventaja del esquema de exokernel es que ahorra una capa de mapeo o

correspondencia. En los otros diseños, cada máquina virtual cree que tiene su
propio disco, cuyos bloqueos van desde el 0 hasta algún máximo, lo que obliga al
monitor de la máquina virtual a mantener tablas para convertir las direcciones de
disco ( y todos los demás recursos). Con el exokernel no es necesario efectuar esta
conversión, pues lo único que tiene que hacer mantenerse al tanto de qué recursos
se ha asignado a cuales máquinas virtuales. Este método sigue teniendo la ventaja
de separar la multiprogramación (en el exokernel) y el código de sistema operativo
del usuario (en el espacio de usuario), pero con menos gastos extra por que la
única tarea del exokernel es evitar que las máquinas virtuales se interfieran
mutuamente.

2.6 Modelo cliente-servidor

El VM/370 gana mucho, desde el punto de vista de la sencillez, al pasar una

buena parte del código de sistema operativo tradicional (la implementación de la
máquina extendida) a una capa superior, CMS. No obstante, sigue siendo un
programa complejo porque la simulación de varias 370 virtuales en su totalidad no
es tan sencilla (sobre todo si se quiere hacer con eficiencia razonable).

Una tendencia en los sistemas operativos modernos consiste en llevar más

lejos aún la idea de subir código a capas superiores y quitar lo más que se pueda
del modo de kernel, dejando un microkernel mínimo. El enfoque acostumbrado es
implementar casi todo el sistema opeativo en procesos de usuario. Para solicitar un
servicio, como la lectura de un bloque o un archivo, un proceso de usuario ( que
ahora se denomina proceso cliente) envía la solicitud a un proceso servidor, que
realiza el trabajo y devuelve la respuesta.

Imagen 2.4

En este modelo, que se muestra en la figura anterior, lo único que hace el

kernel es manejar la comunicación entre clientes y servidores. Al dividir el sistema
operativo en partes, cada una de las cuales se encarga sólo de una faceta del
sistema, como el servicio de archivos, el servicio de procesos, el servicio de
terminal o el servicio de memoria, cada parte puede ser pequeña y manejable.
Además, dado que todos los servidores se ejecutan como procesos en modo de
usuario, no en modo de kernel, no tiene acceso directo al hardware. Por ello, si se
activa un error en el servidor de archivos, el servicio de archivos podría fallar, pero
generalmente no hará que se detenga toda la máquina.

Otra ventaja del modelo cliente servidor es su adaptabilidad para usarse en

sistemas distribuidos. Si un cliente se comunica con el servidor enviándole
mensajes, no necesita saber so el mensaje se maneja en forma local en su propia
máquina, o si se le envió por una red a un servidor en una máquina remota. En lo
que al cliente concierne, en ambos casos sucede lo mismo: se envió una solicitud y
se recibió una respuesta.

La descripción anterior de un kernel que sólo se encarga de transmitir

mensajes de clientes a servidores y de regreso, no es del todo realista. Algunas
funciones del sistema operativo (como la carga de comando en los registros físicos
del dispositivo de E/S) sin difíciles de efectuar, si no imposibles, desde programas
en espacio de usuario. Hay dos formas de resolver este problema. Una es hacer
que algunos procesos servidores cruciales (por ejemplo, controladores de
dispositivos) se ejecuten realmente en modo de kernel, con acceso total a todo el
hardware, pero que se sigan comunicando con otros procesos, empleando el
mecanismo normal de mensajes.

La otra forma es incorporar un mínimo de mecanismo en el kernel pero

dejar las decisiones de política a los servidores en espacio de usuario. Por ejemplo,
el kernel podría reconocer que un mensaje envía a cierta dirección especial implica
tomar el contenido de ese mensaje y cargarlo en los registros de dispositivos de
E/S de algún disco, a fin de iniciar una lectura de disco. En este ejemplo, el kernel
ni siquiera examinaría los bytes del mensaje para ver sin son válidos o lógicos; tan
 sólo los copiaría a ciegas en los registros de dispositivo del disco. (Es obvio que
tendía que utilizarse algún esquema para restringir tales mensajes a los procesos
autorizados.) La división entre mecanismo y política es un concepto importante; se
presenta una y otra vez en los sistemas operativos en diversos contextos.

Imagen 2.5

(Andrew S. Tanenbaum – 2003 pp. 56 – 63).

 Capítulo III
Análisis de Datos Encuesta

Metodología

Una vez que ya hemos conocido la estructura básica y cumplido con uno de
mis objetivos ahora nos concentraremos en cumplir los demás, para esta parte
proseguiré con una encuesta (ver anexo).

La encuesta tiene como fin, determinar si las hipótesis son ciertas o falsas,
también ayudara a determinar el porcentaje de la población que conoce lo que es
un sistema operativo, así como su estructura básica

Esta encuesta se realizara en el Instituto Tecnológico Superior de Fresnillo

a tres carreras que van ligadas a las ciencias tecnológicas, ingeniería en sistemas
computacionales, ingeniería en informática y licenciatura en informática.

De cada una de estas carreras se aplicaron 25 encuestas por cada carrera

tomando en cuenta un porcentaje de los 8 semestres que actualmente se
encuentran en dicha carrera, en la carrera de ingeniería en informática se
aplicaron 10 encuestas dado que solo componen el grupo 15 alumnos y es el
único en existencia en la actualidad.

En total se aplicaron 60 encuestas (como la que se muestra en la parte de

anexos) de la cual conforma el 30% aproximado de la población total de alumnos
por carrera como se muestra en la gráfica G1.
 70

60

50

40
Encustados
30 Población total aproximado

20

10

0
Ing. Informatica Ing. Sistemas Lic. Informatica

Gráfica G1.

De las cuales arrojaron los siguientes resultados:

La población de alumnos de entre 22 y 25 años en adelante conoce más la

estructura básica de un sistema operativo, ya que en sus planes de estudio
abordan una materia referente al tema, solo son pocos los alumnos menores de
esta edad que conocen su estructura básica, tal como lo muestra la gráfica G2.

Rango edad

De entre 18 y 21 años.
De entre 22 y 25 años.

Gráfica G2.
 Es importante hacer notar que solo un pequeña parte de las personas
conocen o saben que es un sistema operativo ya que es muy complejo su
funcionamiento así como su administración de los componentes físicos.

Un sistema operativo solo puede ser entendido si se comprenden y se

ponen en práctica los temas complejos que este aborda. Es por ello que solo la
mayoría de los estudiantes de carrera tecnológica conocen solo un poco de
sistemas operativos.

El 30% de la población encuestada sabe lo que es un sistema operativo, de

entre las carreras ingeniería en sistemas es la carrera con mayor conocimiento
acerca de lo que es un sistema operativo como lo muestra la gráfica G3.

Lo conocen

Ing. En Sistemas
Ing. En Informática
Lic. En Informática

Gráfica G3.

Hacia la siguiente pregunta que trata sobre el conocimiento de la estructura

básica de los sistemas operativos solo una pequeña parte de las personas que
conocen lo que es un sistema operativo la conocen, pero a groso modo.

Calculando entre la población total encuestada el 5% conoce muy

ligeramente de que se compone un sistema operativo.

La población que no conoce la estructura básica de un sistema operativo

expreso los impedimentos por los cuales no la conoce, y estos fueron unos de los
más mencionados:

 Por el exceso de información que existe acerca de ellos.

  Por la falta de conocimiento de las nuevas tecnologías.
 Por su complejidad y lenguaje demasiado técnico y formal.

De los cuales, el más mencionado fue la complejidad y el lenguaje

demasiado técnico y formal tal como lo muestra la gráfica G4.

Causas
60%

50%

40%
Causas
30%

20%

10%

0%
Imperimento 1 Imperimento 2 Imperimento 3 Otros

Gráfica G4.

El lenguaje de los sistemas operativos suele ser demasiado complejo y muy

formal, de tal manera que la mayoría de la gente que no tiene un conocimiento
técnico o basado en la tecnología no suele entender al 100% los términos
utilizados en su desarrollo y funcionamiento.

La información que existe acerca del tema es demasiada, ya que existen

libros escritos por diferentes autores que contienen la funcionalidad y la estructura
pero suele ser aburrido.

De los sistemas operativos los más utilizados en el mercado son los de las
compañías Windows ® y Mac, ya que estas dos, son las más comerciales en el
mundo y casi lo monopolizan, después de ellos le siguen compañías más
pequeñas pero un poco más reconocidas como Ubuntu de Linux.

A través de la encuesta realizada obtuvimos los sistemas operativos más

utilizados y los más conocidos en la población encuestada tal como lo muestra la
gráfica G5.

Dominio

Windows
Ubunto
Mac
Otros

Gráfica G5.

Bibliografía:

PATERSON, J. L. Y SILBERSCHATZ, A. (1993), Sistemas Operativos: Conceptos

Fundamentales, Barcelona: Editorial Reverté S. A., pp. 1-6.
ANDREW S. TANENBAUM (2003), Sistemas Operativos Modernos, México: Paerson
Educación, pp. 56 – 65.

Anexos:

Imagen 1.1 Funcionamiento de un sistema operativo. James L. Paterson, Abraham

Silberschatz, Reveté S. A. (Eds.) (1997). Sistemas Operativos: Conceptos fundamentales.
Pág. 3.

Imagen 2.1 Modelo de estructuración simple para un sistema monolítico. Andrew S.

Tanenbaum, Pearson Educación (Eds.) (2003). Sistemas Operativos Modernos Pág. 57.

Imagen 2.2 Estructura del sistema operativo THE. Andrew S. Tanenbaum, Pearson
Educación (Eds.) (2003). Sistemas Operativos Modernos Pág. 58.

Imagen 2.3 Estructura del VM/370 con CMS. Andrew S. Tanenbaum, Pearson Educación
(Eds.) (2003). Sistemas Operativos Modernos Pág. 59.

Imagen 2.4 El modelo cliente-servidor. Andrew S. Tanenbaum, Pearson Educación (Eds.)

(2003). Sistemas Operativos Modernos Pág. 62.

Imagen 2.5 Modelo de Exokernel. Andrew S. Tanenbaum, Pearson Educación (Eds.) (2003).
Sistemas Operativos Modernos Pág. 65.

Encuesta

Instituto Tecnológico Superior de Fresnillo

Ingeniería en Sistemas Computacionales

Hola. Soy alumno del Instituto Tecnológico Superior de Fresnillo, estoy haciendo esta encuesta
con el fin de adquirir datos para realizar el análisis de una investigación que realizo acerca de
los Sistemas Operativos, en las siguientes preguntas contesta o marca tus respuestas. Gracias.
 1. Carrera: ______________________________________________
2. Marca con una X tu respuesta:
Edad: 18 – 21 ( ) , 22 – 25 ( ).
3. ¿Conoces que es un sistema operativo?
( )Si ( )No
4. ¿Conoces la estructura básica de un sistema operativo?
( )Si ( )No

4.2 Si respondiste que no a la pregunta anterior escribe algún impedimento

por la cual no conoces la estructura básica:

5. Selecciona cuales sistemas operativos conoces:

Linux
( )Ubunto ( )Fedora ( )Mint ( )Linspire ( )Redhat ( )Puppy
Windows
( )Seven ( )Vista ( )XP ( )2000 ( )Millennium ( )98
7
( )Mac
( )Otros

6. Selecciona cuales sistemas operativos has utilizado:

Linux
( )Ubunto ( )Fedora ( )Mint ( )Linspire ( )Redhat ( )Puppy
Windows
( )Seven ( )Vista ( )XP ( )2000 ( )Millennium ( )98
7
( )Mac
( )Otros
7. Si conoces algún otro sistema operativo por favor escríbelo: