Resumen Sistemas Operativos

CAP 1
Introducción
El sistema operativo (SO) proporciona servicios a usuarios y programadores que permiten utilizar una
computadora sin tener que tratar con los comandos de hardware de bajo nivel difíciles de usar.
Proporciona interfaces relativamente uniformes para acceder a la amplia variedad de dispositivos con los
que interactúa una computadora, desde dispositivos E/S
(impresoras,cámaras digitales) hasta componentes inalámbricos de red que permiten la comunicación de
las computadoras.
Permite que los usuarios creen, gestionen y organicen diferentes tipos de archivos, además los S.O
modernos proporcionan diferentes interfaces gráficas fáciles de usar (GUI, graphical user interfaces)
¿De que tratan los SO?
Desfasaje o Asincronicidad es la ocurrencia de eventos al azar o en momentos inesperados, ej: en juegos
manuales a botones cuando presionas todas las teclas.
Vista del Usuario contra Vista del sistema en un SO
Para un Sistema operativo las dos perspectivas más importantes son la Vista del usuario y la Vista del
sistema.

Vista de los usuarios y los tipos de usuarios

La vista del usuario concierne a cómo los usuarios o los programas – los programas son los usuarios más
importantes del SO. – ellos utilizan el SO; por ejemplo la forma en que un programa lee la pulsación de
una tecla. A la vista del sistema concierne la forma en que el software del SO. ejecuta realmente la acción
requerida: como obtiene las pulsaciones de las teclas, separa algunas teclas especiales como el Shift, y las
pone a disposición del usuario o del programa.
Tipos de usuarios
Hay varios tipos de usuarios, por ejemplo, usuarios finales, programadores de aplicaciones,
programadores del sistema y los administradores del sistema.
Un usuario final o usuario de aplicaciones incluye a todos generalmente usa programas de aplicación o
del sistema operativo.
Los programadores de aplicaciones describen a quienes escriben programas de aplicaciones como
procesadores de palabras o sistemas de correo electrónico. Los programadores de aplicaciones son muy
exigentes al Sistema Operativo “¿Cómo leo y escribo en un archivo?” son algunas de las preguntas típicas
de ellos cuando aprenden a usar un nuevo SO. Las facilidades con las que cuenta el SO. son la vista de los
programadores acerca del SO. Algunas veces denominadas Llamadas al sistema o Interfaz de
programación de aplicaciones (API), además de esto, los programadores también desean que el software
que desarrollan sea fácilmente transferible a otras plataformas.
Programadores del sistema Se trata de quienes escriben Software – programas o componentes – está
estrechamente relacionado con el SO, ejemplo de estos son: una utilidad que muestre el estado de la
conexión de una red de computadoras o de un controlador
inestable para una pieza de hardware. Los programadores del sistema necesitan comprender en detalle
el funcionamiento interno del SO, y en muchos casos requieren acceder a estructuras de datos especiales
del SO. o llamadas privilegiadas al sistema.
Los administradores del sistema incluyen a los que gestionan facilidades de la computadora y por tanto
son responsables de instalar y actualizar el sistema operativo, también son responsables de crear y
mantener las cuentas de los usuarios, así como proteger el sistema, deben comprender en detalle cómo
se instala y actualiza el SO, y como interactúa con otros programas y utilidades, también comprender las
características de seguridad y autorización del SO. a fin de proteger de manera efectiva su sistema y a los
usuarios.

Vista del sistema

La vista del sistema se refiere a cómo el sistema operativo proporciona realmente los servicios, se refiere
a los trabajos internos del SO, esta vista es menos común, solo pocas personas, como diseñadores e
implementadores del SO. comprenden o les importan los trabajos internos de un SO, esa información a
menudo es considerada secreta de las compañías que la producen y venden.
Los Sistemas de fuente abierta son aquellos sistemas el cual el código fuente está disponible a la vista de
los usuarios.
EJEMPLO: El movimiento de un mouse ( y el cursor del mismo )
Aunque este ejemplo parece directo, ilustra las muchas vistas de un SO, cuando el dispositivo apuntador
se mueve, genera un evento de hardware interrupción , que manipula el SO, el SO. observa los
movimientos del mouse en término de algunas unidades específicas de hardware, es decir; las lecturas
son en un número de pulsos generados en lugar de en milímetros por
ejemplo. Esta es la visión de bajo nivel del sistema. La lectura real del software del movimiento del ratón
es parte del SO, y se denomina controlador de dispositivo ratón. Este controlador de dispositivo lee la
información de bajo nivel del movimiento del ratón y otra parte del SO. la interpreta, de modo que puede
ser convertida en una visión de nivel superior del sistema , como coordenadas que reflejan los
movimientos del ratón, pero..¿Que ve el usuario? , la vista del usuario es que el cursor se desplaza de
manera continua sobre la pantalla y que a medida que el ratón se mueve grandes distancias cada vez más
rápido , también el movimiento de pantalla parece más rápido, entre estas vistas se encuentra la vista del
programador de aplicaciones ¿Cómo obtengo la información del movimiento del ratón a fin de usarla y
mostrarla en mi aplicación? También otra cuestión es cómo la información sobre el movimiento del ratón
se presenta al programador de aplicaciones. Esta es la visión del nivel superior del sistema mencionada
anteriormente. Y para completar las vistas un bit permite volver a la vista del sistema. ¿Qué aplicación
obtiene este movimiento del ratón si hay abiertas varias ventas? Podría ser necesario que los movimientos
del ratón permanezcan en una cola si hay movimientos múltiples antes de que la aplicación los recupere.
Los movimientos podrían incluso perderse si el SO. está ocupado haciendo otras cosas – por ejemplo
cargando una página web a través de una conexión con la red – y no podría recibir la entrada
oportunamente del controlador del dispositivo.
OTRO EJEMPLO : Archivos
A veces la vista del usuario final mas critica de un SO. es el sistema de archivos; en particular, los nombre
de los archivos. ¿ los nombres de los archivos pueden contener espacio? ¿Qué
longitud deben tener? Etc, Un SO. puede incluso ser llamado bueno o malo simplemente porque no se
usan nombres de archivos largos o porque no se distingue la diferencia entre mayúsculas y minúsculas.
En la vista del programador de aplicaciones , el sistema de archivos es una parte crítica frecuentemente
usada del sistema. Proporciona comandas para crear un nuevo archivo, usar uno existente, leer o anexar
datos a un archivo y otras operaciones con archivos, incluso puede haber diferentes tipos de archivos
proporcionados por el sistema .
La vista del sistema de archivos es tan extensa que suele dividirse en subpartes: nombres de archivos y
manipulación de nombres (servicios de escritorio ), servicios de archivos de localización y mapeo del
nombre de un archivo en sus datos (asignación y almacenamiento ), mantener parte de archivos abiertos
en memoria principal a fin de acelerar el acceso a sus datos ( envío de archivos a la memoria y
almacenamiento de archivos en caché ) y la gestión real de los dispositivos de almacenamiento (
programación del disco ).
Por ejemplo, suponemos que un usuario describe el nombre de un archivo que se copiara de un CD a un
disco duro. El programa podría requerir primero ver si ese archivo existe en el CD, y en caso afirmativo
sobreescribir un archivo con ese nombre en el disco duro, encontrar espacio en el para almacenar los
datos y encontrar y obtener los datos del CD, que han sido grabados en piezas (sectores ) que serán
copiadas. Y todo esto debe efectuarse en segundos o incluso milésimas

Algunos términos, conceptos básicos e ilustraciones del SO

Terminología básica
El Sistema operativo ( o solo sistema ) es una colección de uno o más módulos de software que gestionan
y controlan los recursos de una computadora u otro dispositivo de cómputo o electrónico, y proporciona
a los usuarios y programas una interfaz para utilizarlos. Los recursos gestionados incluyen memoria,
procesadora, archivos, dispositivos de entrada o salida, etcétera.
Un Dispositivo es una pieza de hardware conectada al hardware del sistema de cómputo principal. Discos
duros, DVD y monitores de video son dispositivos típicos gestionados por un sistema operativo, muchos
cuentan con una interfaz electrónica ( hardware ) especial denominada dispositivo controlador, que
ayuda a conectar un dispositivo o un grupo de de dispositivos semejantes a un sistema de computo.
Algunos ejemplos incluyen controladores de disco duro y controladores de monitores de video, que suelen
cumplir normas de la industria como SCSI, SATA y otros acrónimos comunes pero crípticos. Los
dispositivos controladores son los aglutinantes de hardware que conecta todos los dispositivos de
hardware del sistema de cómputo principal, casi siempre por medio de un bus.
Controlador de dispositivo Este dispositivo es una rutina de software que forma parte del S.O y se utiliza
para comunicarse con un dispositivo y controlarlo a través de su dispositivo controlador.
Kernel o núcleo Se refiere a la parte del S.O que implementa funcionalidad básica y siempre está presente
en la memoria.
Servicios son funciones que el kernel del S.O proporciona a los usuarios, a través del API mediante
llamadas al S.O. Estos servicios pueden agruparse en forma conveniente en categorías basadas en su
funcionalidad;
ej: servicio de manipulación de archivos (creación,lectura,copiado)
ej: servicio de asignación de memoria(obtención,liberación)
La clave para que un programador comprenda a un sistema es comprender los servicios del S.O
proporcionados al sistema.
Utilidad: Son programas que no forman parte del núcleo ( o kernel ) del S.O, sino que trabajan
estrechamente con el kernel para facilitar el uso o el acceso a la información del sistema.
Un ejemplo de utilidad es el Shell o Intérprete de comandos. La Utilidad Shell proporciona una interfaz
del usuario a muchos servicios del sistema. Ej: solicitudes del usuario como listar los nombres de archivos
en un directorio, ejecutar un programa o salir (logging out).
El Shell puede invocar otras utilidades para efectuar el trabajo, ej: listado de archivos en un directorio
algunas veces es un programa útil en sí mismo.
IMÁGENES
La siguiente figura (1.2) es una representación simplificada de una pequeña computadora personal (PC)
que muestra algunos dispositivos básicos conectados a la memoria de la computadora y a la CPU.
El programa (o núcleo) del SO incluye varios controladores de dispositivos que manipulan los periféricos (
dispositivos) del sistema bajo control de la CPU. Ej: parte del contenido de la memoria puede transferirse
al controlador de video para su exhibición en el monitor o el contenido de una parte del disco duro ( un
sector ) puede transferirse al controlador de disco y finalmente a memoria ( para una lectura en disco )

La siguiente figura (1.3) es una imagen simplista de parte de un SO. El SO controla (o gestiona ) los recursos
del sistema, así como discos, teclados, monitor y otros dispositivos. Controla la asignación de memoria y
el uso de la CPU al decidir que programa ejecutar, proporciona servicios al Shell y a otros programas de
por medio del uso de API, también proporciona una abstracción del hardware al ocultar detalles
complejos de dispositivos de hardware de los programas.
Esta figura, común para ilustrar los SO, es una representación lógica, no física. Por ejemplo el núcleo del
SO reside físicamente dentro de la unidad de memoria y corre en la CPU, así como las flechas entre el
núcleo – que es software – y los dispositivos – que son hardware – representan un control lógico, no físico
La figura (1.4) representa un enfoque por capas del SO donde el círculo exterior representa la capa
utilidades/aplicaciones que accede a la capa del núcleo del SO, que a su vez gestiona el acceso a la capa
de hardware.

El SO de una computadora personal (PC)

La figura 1.5 muestra más detalles de un Sistema Operativo de una computadora Personal o PC, El SO
tiene dos componentes adicionales que no aparecen en la figura 1.3 : Controladores de dispositivos y BIOS
(Sistema básico de entrada/salida )
BIOS: Abstrae el hardware, es decir, gestiona dispositivos comunes, como teclados, video básico y reloj
del sistema. Esto permite que la parte principal o de nivel superior del SO trate con todos los dispositivos
del mismo tipo – por ejemplo, todos los teclados – de la misma manera, Así el núcleo del SO no cambia,
sin importar el teclado que tengas.
Capas de abstracción
En los inicios de la época de las computadoras personales, los aficionados se divertían ensamblando y
construyendo el hardware, y haciendo funcionar programas simples, normalmente escritos en lenguaje
ensamblador o en lenguaje máquina, esto era una buena herramienta para algunas personas, aunque la
programación era muy tediosa, la gente deseaba disfrutar la experiencia de escribir programas más
interesantes y por tanto más largos y complicados, Así requerían mejores herramientas como editores
fáciles de usar y compiladores o intérpretes para el lenguaje de alto nivel, sin embargo para los usuarios
finales, el deseo era usar la computadora como herramienta de negocios o productividad. Estos usuarios
necesitaban el procesamiento de palabras, hojas de cálculo y software de comunicaciones, se construían
muchos sistemas de hardware para computadora bastante diferentes. Estos sistemas podían contar con
una CPU elaborada por el mismo fabricante o una CPU compatible con el mismo conjunto de
instrucciones, sin embargo podían tener dispositivos de video distintos. Por ejemplo, un sistema podría
tener un dispositivo semejante a una terminal que estaba conectado a un puerto serie, mientras que otro
podía contar con un controlador de video integrado con muchas capacidades para elaborar gráficas
avanzadas. Los teclados podrían diferir típicamente en cuanto a las teclas de función o “flecha” o a teclas
de movimiento del cursor, con la adición o remoción de otras teclas.
A fin de que los programadores pudiesen crear programas ejecutables en estos sistemas diferentes con
cambios menores o ningún cambio al programa cuando se moviera a otros sistemas, el SO proporcionaba
la misma interfaz al hardware para todos los distintos dispositivos soportados por él. Por ejemplo, un
programa podía leer el pulso de una tecla desde un teclado sin importar que tipo de teclado fuera por
medio de una llamada al sistema que leyese una tecla.
El SO se haría cargo de traducir las teclas ubicadas en sitios distintos en teclados diferentes o que se
hubieran codificado de otra manera.
A fin de evitar complicaciones y costo por el hecho de tener varias versiones del SO para teclados ,
monitores y discos diferentes, entre otros, el SO se dividió en una parte que estaba adaptada a los
distintos dispositivos de hardware ( el BIOS y controladores de dispositivos ) y una parte que
permanecía igual para todo el hardware ( la cual se muestra como el núcleo en fig 1.5 ). Esta técnica de
trabajo complicado en varias capas o niveles es una técnica establecida de software usada para grandes
y complicados sistemas de software incluyendo los SO.
Así adaptar un SO a un nuevo sistema de cómputo compatible con diferentes dispositivos implicada
modificar o escribir un BIOS, pero usando el mismo módulo para el resto del núcleo y los mismos
programas y utilidades. Esto era una idea bastante atractiva para todo el mundo: usuarios, fabricantes y
escritores de SO.
Surgía un problema cada vez que un fabricante de periféricos de computadora ( por ejemplo fabricante
de vídeo de tarjetas ) diseñaba un nuevo dispositivo y deseaba venderlo a los usuarios a fin de que pudiera
actualizar su computadora a diseños más recientes de hardware. A menudo el BIOS existente en la
computadora era instalado en la ROM (memoria de solo lectura ) y su reemplazo era difícil y costoso.
La solución a este problema fue la creación de un BIOS modificable que permite que los controladores de
dispositivos fueran cargables en el momento en el que el SO se cargaba en la memoria. Contar con un
código BIOS que sea posible sustituir el arranque del sistema permite agregar nuevas características a la
computadora o sustituir características en el BIOS con nuevo software y quizá soportar nuevas funciones
en hardware existente.
ORIGEN DE LOS SISTEMAS OPERATIVOS
Antes de la aparición de las PC (personal computer ) hubo computadoras más grandes, fueron demasiado
gigantes y costosas, pimirivas según estándares modernos, y había muy pocos
programadores. Los programas estaban limitados en cuanto a sus capacidades porque la memoria
principal (RAM) era muy pequeña Los procesadores de la CPU eran muy lentos y solo existían unos pocos
dispositivos E/S, uno de los primeros sistemas típicos de computadora hubiera podido contar con unos
miles de palabras ( una palabra solo podía ser de 6 caracteres, aunque se difería de un sistema a otro ) de
memoria principal, un procesador que ejecutara varios miles de instrucciones por segundo y un dispositivo
teletipo( es un teclado y una impresora electromecánicos, elaborados para telegráfica que podía imprimir
o escribir a una velocidad de alrededor de una docena de caracteres por segundo ) para E/S, las
capacidades limitadas de estas primeras computadoras requerían bastante cuidado y programas bien
pensados , que en su mayoría se escribían en el código básico de máquina de la computadora, en lenguaje
de máquina o ensamblador.
Estos programas eran sorprendentes en el sentido de que unos cientos de miles de instrucciones de
máquina lograban una cantidad enorme de trabajo. Sin embargo, todos enfrentaban necesidades
semejantes: ¿Cómo puede un programa imprimir alguna salida? ¿Cómo es posible cargar un programa en
la memoria para iniciar su ejecución? Esas necesidades – la necesidad de cargar programas en memoria,
ejecutar un programa, obtener datos de entrada y producir datos de salida – eran la motivación para crear
los primeros SO.
En aquella época, al ser tan escasos los programadores, se conocían entre sí y podían compartir rutinas (
códigos de programa ) ya depuradas para simplificar el trabajo de programación. Estas rutinas
compartidas ( por ejemplo “imprimir el valor del registro A en el teletipo “) terminarían por unirse en una
biblioteca que podría combinarse ( vincularse ) con un programa de aplicación para formar un programa
completo a ejecutar.
Estas primeras computadoras eran sistemas de usuario único - solo un usuario y solo un programa –
podían ejecutarse en un momento dado. Por lo regular los programadores podían reservar el uso de la
computadora en pequeños bloques temporales, tal vez incrementos de 10 y 15 min. Un programador
podía usar ese bloque para ejecutar o depurar un programa. Debido a que las computadoras eran muy
costosas y el tiempo de computadora era muy valioso, los bloques más grandes de tiempo estaban
disponibles solo a la mitad de la noche o temprano a la mañana, había menos administradores alrededor
y era posible hacer mucho más durante el día.
Los programas una vez escritos y ensamblados se vinculan o ligaban con rutinas de utilidad para entrada,
salida , funciones matemáticas, formateo de impresión y otras tareas comunes, en un programa
ejecutable listo para cargarse en la memoria y ejecutarse. El programa podía
almacenarse en cinta de papel perforado o en tarjetas perforadas. El hardware de la computadora era
capaz de saber como empezar a leer el desde el dispositivo de entrada, aunque solo podía cargar la
primera tarjeta o el primer bloque de la cinta. Así ese bloque debía incluir una pequeña rutina capaz de
cargar el resto de la aplicación en la memoria. Esta rutina corta se denomina cargador. A su vez el cargador
debía leer el programa ejecutable del programador y colocarlo junto con las rutinas de utilidad necesarias
en la memoria o en alguna ubicación específica, luego debía transferir la ejecución – por medio de una
llamada ramificada o una “subrutina” – al programa que había cargado. La cinta o el mazo de tarjetas del
programa cargable podía verse como se ilustra en (fig 1.6) ( el cargador a menudo se denomina “cargador
de arranque”). El delimitador END indica a ese cargador que no hay más rutinas a cargar, ya que a
continuación de las rutinas puede haber registros de datos.
Como los programadores tenían tiempo para desarrollar más rutinas de utilidad, el cargador creció en
forma más sofisticada. Pronto, los cargadores fueron capaces de cargar programas que se habían
traducido ( compilado ) a partir de lenguajes de programación de nivel superior.
A medida que crecía el tamaño de los cargadores, las rutinas de utilidad y los programas de usuarios, los
mazos de tarjetas o las cintas de papel se volvieron muy grandes ( y desafortunadamente se volvió común
dejar caer un mazo de tarjetas o romper una cinta de papel ). Estos cargadores y rutinas de utilidad se
convertirían en el inicio de los primeros SO, que a menudo se dominaban Monitores.

ELMASRI CAP 2 ( Conceptos, componentes y arquitecturas del SO) ¿Qué hace un SO?
Un proceso ( algunas veces denominado trabajo o tarea ) es básicamente un programa en ejecución que
puede estar en espera de ser ejecutado, en ejecución, esperando que ocurra algo o terminando.
Algunos de los eventos que puede estar esperando un proceso pueden ser: incluir la pulsación de una
tecla de parte del usuario, la lectura de algunos datos desde una unidad de disco, o bien, que otro
programa le suministre datos
Antes de poder iniciar un proceso, el archivo del programa ejecutable ( binario ) que será ejecutado debe
estar en la memoria principal. Ésta suele cargarse desde un disco o alguna memoria flash, para lograr lo
anterior se requiere llevar a cabo varias actividades fundamentales del SO. Primero, se requiere una
porción de la memoria principal para obtener el código ejecutable del programa así como una memoria
adicional para los datos, las variables y el almacenamiento temporal del programa.
Estas actividades para asignar la memoria son parte de la Gestión de memoria que debe realizar el SO. A
menudo varios programas pueden estar en la memoria al mismo tiempo. El módulo de gestión de la
memoria del SO controla los procesos que se ubicaran en la memoria, el sitio en que serán colocados y la
cantidad de memoria que se proporcionará a cada uno.
La gestión del proceso –la decisión de cual proceso ejecutar, durante cuánto tiempo y tal vez con qué
prioridad – constituye otra actividad crucial de gestión del SO, por lo regular manipulada parcialmente
por el planificador de la CPU del SO.
Adquirir golpes de teclado o caracteres y mostrar estos últimos en la pantalla se realiza en una serie de
pasos mediante el componente de gestión de E/S y de dispositivos del SO.
Dato:al presionar una tecla ya sea oprimida o soltada se almacena en un buffer temporal.
Pero en un PDA o un PC puede haber un chip especial controlador que del teclado, que guarde la
información de la acción de la tecla y luego envíe una interrupción al procesador. El procesador puede
contar con su propio controlador de dispositivo del teclado además del chip controlador en el teclado. La
interrupción ocasiona que la CPU detenga el proceso que está ejecutándose. Esto puede hacerse de
inmediato si la CPU se encuentra realizando trabajos de prioridad inferior. O más tarde si ha estado
efectuando trabajos de prioridad superior. Luego , el SO. inicia una rutina de interrupción del servicio para
manipular la acción del teclado. La rutina de interrupción del servicio es parte de la manipulación de la
interrupción y del control del dispositivo en el SO. Este procedimiento se repite para cada carácter
tecleado. El carácter debe enviarse al proceso de edición y mostrarse en la pantalla; otra acción que realiza
el SO. En este caso se efectúa una operación de salida hacia el monitor de video.
Una vez que el usuario termina de escribir, la guarda como un archivo. Esto puede implicar el movimiento
de un dispositivo apuntador. Como un ratón ,para apuntar el menú archivo en
pantalla. El movimiento del ratón y los clics en este son manipulados por un controlador de dispositivo,
que sigue las coordenadas del ratón y las envía al SO. El icono de seguimiento del ratón ( flecha ) que debe
moverse y mostrarse por pantalla. Cuando se hace clic en el botón del ratón, el controlador envía esta
información al SO, que transmite las coordenadas donde ocurrió el clic al sistema de ventanas que
gestiona la interfaz del usuario. El sistema de ventanas tendrá información relacionada con la ventana
activa actualmente y con las posiciones de varios botones e iconos dentro de esa ventana. Al usar esta
información, hará coincidir las coordenadas del cursor cuando el usuario hizo clic. El sistema de ventanas
que manipula la interacción con el usuario suele ser bastante complicado. Hay quienes lo consideran un
programa de sistemas, separado del SO, y quienes lo consideran parte integral del SO.
Ahora cuando el usuario quiera escoger un directorio llamado notas personales, en el que desea guardar
su archivo. Esto introduce la participación del componente gestión de archivos del SO. Cuando el usuario
selecciona el directorio (doble clic) esto ocasiona que el gestor de archivos del SO. emprende varias
acciones. Primero debe abrir el directorio mediante la recuperación de información que hay en él, a partir
de las tablas internas del SO. La información del directorio incluye los nombres de archivos ( y
posiblemente otros directorios ) almacenados bajo el directorio, así como la ubicación del directorio en el
disco. Luego, el usuario debe escribir el nombre de un archivo como “recordatorio-concierto” y el sistema
de archivos comprobará lo necesario a fin de asegurarse de que ninguno de los archivos que hay en ese
directorio tenga el mismo nombre. A continuación puede invocar el módulo de asignación de espacio en
el disco para encontrar una zona de espacio libre en el disco para almacenar el archivo en cuestión.
Finalmente, el administrador de archivos del SO. crea una entrada de archivo en el directorio para guardar
la información concerniente al nuevo archivo, como su nombre, tipo de archivo y ubicación en el disco.
A Partir de este ejemplo vemos que el SI participa en prácticamente todos los aspectos de interacción
entre usuario y programa: desde acciones de bajo nivel, como procesar golpes de teclado y movimientos
del ratón, hasta algoritmos de asignación de recursos como asignación de espacio en memoria y tiempo
de procesador, pasando por acciones de nivel superior como la gestión de nombres de archivos y
directorios.

Recursos gestionados por el SO. y Módulos más importantes del SO.

Un papel fundamental del SO. es la gestión de recursos del sistema

Tipos de recursos gestionados por un SO.

Algunos de los recursos por un SO. típicos son: CPU, Memoria principal y caché, almacenamiento
secundario y dispositivos E/S al nivel más bajo, así como el sistema de archivos e interfaces del usuario a
nivel superior. El SO. también gestiona el acceso a redes y proporciona seguridad para proteger los
diversos recursos
CPU
El SO. necesita planear cuál proceso ejecutar en cada CPU en cualquier instante. En sistemas de proceso
único más antiguos es más simple, porque un solo proceso reside en la memoria de modo que el SO es el
responsable de iniciar el proceso residente en la memoria al proporcionarle el control de la CPU.
Aun así en estos sistemas tan simples, el SO. debe efectuar otras tareas, como establecer cualquier
registro de protección de la memoria y cambiar al modo de ejecución del usuario antes de otorgar al
proceso el control de la CPU.
En sistemas multitareas, la gestión del recurso CPU es muy complicada porque en la memoria hay
múltiples procesos, Además puede ser más complicado si en el sistema hay múltiples CPU.
El SO. mantiene varias listas de procesos. La cola más relevante para la programación de la CPU se
denomina Cola lista, la cual contiene todos los procesos que están listos para su ejecución. Si los procesos
tienen prioridades distintas, para cada nivel de prioridad puede haber una cola lista por separado. A cada
proceso se le asigna, por lo regular, control de la CPU durante un lapso máximo, denominado Cuánto
temporal. Si el Cuánto temporal expira antes de que el proceso termine la ejecución, un interruptor de
tiempo puede iniciar un proceso del SO. denominado Conmutación de contexto, que puede cambiar el
control de la CPU a otro proceso.
Memoria principal y cachés
El SO. necesita asignar espacio de memoria a un proceso antes de poder ejecutarlo. El código ejecutable
de un programa suele almacenarse en el disco duro ( o en algún otro medio de almacenamiento
secundario). Cuando un usuario o un programa desea ejecutar un programa que se encuentra en un disco,
el SO. debe localizar el archivo del código del programa en el disco y asignar suficiente espacio de memoria
para mantener una parte inicial del programa. Debido a que muchos programas son bastantes grandes,
el So debe cargar solo parte del programa desde el disco. Una de las funciones de gestión de la memoria
consiste en la asignación de espacio de memoria inicial a un proceso y quizá cargar partes adicionales del
programas desde un disco a medida que el proceso las necesita. Si todo el espacio de la memoria está
lleno, el módulo de gestión de la memoria del SO. debe intercambiar a un medio externo algo de la
información residente en la memoria, a fin de poder cargar las porciones adicionales necesarias por el
proceso.
Almacenamiento secundario
Generalmente suelen ser los discos duros, La mayoría de los archivos de código del programa y los archivos
de datos están almacenados en el disco duro hasta que hay una petición para cargar algunas partes de
estos en la memoria principal. Siempre que un proceso requiere datos o códigos que no están en la
memoria, se envía una petición al módulo de planificación del disco del SO. El SO. típicamente suspende
el proceso de la petición hasta que los datos requeridos se leen en la memoria. En un sistema multitareas
puede haber muchas peticiones para leer ( cargar en memoria ) y escribir datos en el disco ( almacenar en
el disco ). El SO. suele mantener una o más colas para las solicitudes de lectura y escritura en el disco, y
usa varios algoritmos para optimizar la atención de estas solicitudes. Como parte de nuestro análisis de
gestión de E/S.
Dispositivos de E/S
El SO. también debe controlar y gestionar varios dispositivos de E/S conectados a un sistema de computo.
El SO. incluye módulos denominados controladores de dispositivos que vigilan el acceso a estos
dispositivos, y a menudo que los usuarios agregan nuevos dispositivos de E/S a sus sistemas, los SO.
modernos cuentan con la capacidad de detectar nuevo hardware e instalar dinámicamente los
controladores de dispositivos idóneos. Un controlador de dispositivo manipula la interacción a bajo nivel
con los controladores de dispositivos de hardware y
presenta una vista de nivel superior de los dispositivos de E/S al resto del SO. De esta forma el SO. puede
manipular dispositivos semejantes en una forma abstracta y uniforme.
Sistemas de archivos
Los recursos de bajo nivel son los del hardware El SO. gestiona recursos de nivel superior que se crear por
medio del software. Uno de los más importantes es el sistema de archivos, este sistema es un módulo del
SO. que proporciona una interfaz de nivel superior que permite que los usuarios y los programas creen,
borren, modifiquen, abran , cierren y apliquen otras operaciones a varios tipos de archivos, El sistema de
archivo permite a los usuarios poner nombres a los archivos, organizar los archivos en directorios,
proteger archivos y acceder a estos usando diversas operaciones de archivos.
Intefaces del usuario
Muchos SO. incluyen otro componente de alto nivel para manipular la interacción con el usuario. Esto
incluye la funcionalidad para crear y gestionar ventanas en la pantalla de una computadora a fin de
permitir que los usuarios interactúen con el sistema. Al tener este componente el SO, el usuario puede
acceder a varios recursos en forma uniforme por ejemplo: acceder al directorio del sistema de archivos.
Acceso a redes
El acceso a redes permite que los usuarios y los programas en una PC accedan a otros servicios y
dispositivos en una red de computadoras. Un SO. es capaz de proporcionar funcionalidad tanto de bajo
como de alto nivel para el acceso a redes. Un ejemplo de funcionalidad de bajo nivel es la capacidad
otorgada a un programa para crear puertos de redes y conectarse con un puerto en otra maquina, y un
ejemplo de funcionalidad de alto nivel es la capacidad de acceder a un archivo remoto.
Suministro de protección y seguridad
El SO. cuenta con mecanismos para proteger los diversos recursos de algún acceso no autorizado, así como
técnicas de seguridad para permitir que los adm del sistema refuercen sus políticas de seguridad. El tipo
de seguridad más simple es la autorización de acceso mediante contraseñas, aunque en general no son
suficientes.
Módulos más importantes de un SO.

En la siguiente figura podemos ver los módulos más importantes de un SO. a un nivel abstracto ( muchos
de estos módulos corresponden a los recursos que se estén gestionando).
Los módulos proporcionan funciones a las que acceden usuarios y programas del sistema, así como los
otros módulos del SO. Se restringe algo de funcionalidad de modo que solo sea posible acceder a esta en
modo privilegiado por otros módulos del SO, por ejemplo: las
funciones de los controladores de dispositivos a menudo están restringidas para el acceso al SO. Otra
funcionalidad está disponible para módulos del SO, usuarios y programas de aplicación, como funciones
del sistema de archivos.
En la figura no se muestra la forma en que los módulos interactúan entre sí, esto se debe a que los tipo
de interacción dependen de la arquitectura particular usada para implementar el SO. Por ejemplo, en una
arquitectura por capas los módulos estarían separados en capas, en general los módulos de un nivel
deben llamar a las funciones proporcionadas por los módulos que están en el mismo nivel o en niveles
inferiores. Por otra parte, en una Arquitectura orientada a objetos cada módulo está implementado como
uno o más objetos con servicios, y cualquier objeto puede invocar los servicios proporcionados por otros,
y en una Arquitectura Monolítica todos los módulos están implementados como un programa gigante.
Definición de proceso y estados del proceso
BCP ( bloque de control de procesos ) es la estructura de datos que mantiene el SO. para seguir la pista
de cada proceso
Un Proceso es un programa que está corriendo o en ejecución, para ser un proceso, un programa necesita
haber sido iniciado por el SO, sin embargo un proceso no necesariamente está en ejecución todo el tiempo
durante su existencia; puede estar en espera de E/S (como esperando que se presione una tecla) o
esperando que el SO. le asigne algún recurso ( un bloque de ram).
Todo proceso tiene una secuencia particular de ejecución y, por tanto, un contador de programa que
especifica la ubicación de la siguiente instrucción a ejecutar, también cuenta con varios recursos que le
asigna el SO. Por ejemplo, algo de espacio de la memoria en donde almacenar todo o parte de su código
y datos del programa ( como variables del programa ). Seguramente accederá a archivos, de modo que tal
vez tenga asociados con él algunos archivos abiertos. Además un proceso también se denomina trabajo
o tareas.
Una vez que se crea un proceso puede estar en varios estados:
En ejecución (si tiene el control de la CPU)

Listo para su ejecución ( si otros procesos están usando actualmente todas las CPU) En espera ( de que

ocurra algún evento )

Y así sucesivamente, en la sig figura se muestran los estados típicos por lo que puede pasar un proceso;
esta figura se denomina Diagrama de transición de estados. Los nodos ( hexágonos ) representan los
estados del proceso y las líneas dirijas (flechas) representan las transiciones de estados.

La transición de estado 0 (cero) crea un nuevo proceso, que puede ser provocado por uno de los sig
eventos:
1) Un proceso del SO. en ejecución puede crear o generar un nuevo proceso, ej: cuando un usuario
interactivo entra a un sistema de cómputo, el proceso del SO. que manipula los registros de entrada crea,
un nuevo proceso para manipular algunas funciones del SO. como un proceso manejador de
interrupciones o de errores
2) Un proceso de un usuario también puede crear un nuevo proceso al llamar a la función del SO. para su
creación. Por ejemplo, un buscador de la red podría crear un nuevo proceso para ejecutar un módulo
externo “enchufado” para manipular un tipo particular de contenido multimedia que esté en un sitio de
la red.
3) Cuando el SO. inicia un trabajo como un evento programado ( por ejemplo, un trabajo “cron” en un
sistema UNIX), el SO. crea un proceso para ejecutarlo.

A medida que se crea un nuevo trabajo, este se encuentra en un estado nuevo. El SO. debe elaborar la
tabla que contiene información sobre el proceso, asignar recursos necesarios ( memoria ), localizar el
archivo ejecutable del programa y cualquier dato inicial para el proceso, y ejecutar las rutinas idóneas
para cargar en la memoria las partes iniciales del proceso. La transición de estado 1 ( en la figura ) muestra
que el SO. mueve un proceso desde el nuevo estado hasta el estado listo, lo cual indica que el proceso ya
está listo para la ejecución. Una vez que ha ocurrido todo esto, el proceso puede ser movido al estado
listo.
Incluso después de que un proceso se encuentra en el estado listo, no inicia su ejecución hasta que el SO.
le proporciona el control de la CPU. (transición 2 de la fig). El proceso ahora está en ejecución y se
encuentra en el estado ejecución. Si en el estado listo hay más de un proceso la parte del SO. que escoge
uno de estos para su ejecución se denomina planificador de la CPU o planificador del proceso.
Si un proceso se ejecuta hasta el final o tiene un error que provoca que el SO. lo aborte (origina la
transición de estado 6 en la fig ). Esto conduce a un proceso llamado terminado, en cuyo momento el SO.
efectúa operaciones de limpieza en el proceso, como borrar la información del
proceso y las estructuras de datos, así como memoria del proceso y otros recursos, cuando la limpieza
está lista, pasa a (transición 7 de fig ) lo cual origina que el proceso salga del sistema.
Otras dos transiciones de estado pueden ocurrir cuando un proceso se encuentra en su estado de
ejecución: (transiciones 3 y 5 en la fig)
La transición de estado 3 ocurrir si el proceso requiere algún recurso que no está disponible o si requiere
que ocurra alguna operación de E/S (presionar una tecla) Esto conduce a un proceso al estado espera o
bloqueo
Un proceso permanece en estado de espera hasta que se le asigna un recurso que requiere o su petición
de E/S se ha completado, en cuyo momento la transición de estado 4 regresa el proceso desde el estado
de espera hasta el estado de listo. Por otro lado, la transición de estado 5 directamente desde el estado
de ejecución hasta el estado de listo suele ocurrir cuando el SO. decide suspender el proceso debido a que
tiene procesos más urgentes que ejecutar. Esto puede deberse a un cronómetro o algún otro tipo de
interrupción, lo cual puede ocurrir por varias razones. La razón más común es asignar la CPU a otro
proceso debido al algoritmo de planificación de la CPU.
Información del proceso mantenida por el SO.
Para seguir una pista del proceso el SO. suele asignarle un identificador único de proceso (o ID del
proceso). También crea una estructura de datos denominada bloque de control de proceso (o BCP) para
seguir la pista de la información del proceso, como la id del proceso, los recursos que éste usado solicita,
su prioridad, sus derechos de acceso a varios recursos o archivos del sistema, etc.
El BCP también incluye referencias a otras estructuras de datos del SO, que incluyen información sobre
cómo localizar el espacio en la memoria y archivos abiertos en uso por el proceso. Para procesos que no
están en el estado de ejecución el BCP guarda información en el hardware estado del procesador del
proceso, como los valores almacenados en el registro contador del programa y otros registros del
procesador. Esta información es necesaria para reiniciar el proceso cuando regresa al estado de ejecución.
(fig muestra algo de la info que por lo regular se mantiene en un BCP)

La información sobre archivos abiertos que está usando el proceso suele mantenerse en una estructura
de datos del SO. por separado, que crea y usa el módulo de gestión de archivos de SO.
La información sobre qué áreas de la memoria están ocupadas por el proceso suele mantenerse en tablas
de páginas o registros límite creados y usados por el módulo de gestión de memoria del SO. Se hace
referencia a estas dos tablas desde la estructura de datos del BCP. Además en el BCP se incluye
información adicional como el nivel de prioridad del proceso y una referencia a los niveles de seguridad o
protección de este.
Tipos de procesos y modos de ejecución
Los procesos pueden clasificarse en varios tipos:
1. Procesos del usuario o de aplicación. Estos son los procesos que se encuentran ejecutando programas
de aplicación en representación de un usuario. Algunos ejemplos incluyen un proceso que está ejecutando
un programa de contabilidad, una transacción de base de datos o en un juego de computadora
2. Procesos del programa del sistema. Son otros programas de aplicación que efectúan un servicio del
sistema común en lugar de un servicio específico de un usuario final. Tales programas a menudo
interactúan estrechamente con el SO. y requieren información especial sobre interfaces y estructuras del
sistema, como el formato de un módulo de programa relocalizable o un archivo de programa ejecutable.
Algunos ejemplos son los compiladores de lenguaje de programación y los entornos de desarrollo de
programas.
3. Procesos del SO. También se les conoce como demonios, y se trata de procesos que se encuentran
ejecutando servicios y funciones del SO. Algunos ejemplos son: gestión de memoria, planificación de
procesos, control de dispositivos, manipulación de interrupciones, servicios de archivos y de red.

La mayoría de los procesadores cuentan con dos modos de ejecución para los procesos: el modo
privilegiado y el modo regular ( o del usuario ).
Los procesos del núcleo del SO. por lo regular se ejecutan en Modo privilegiado – también llamado modo
supervisor, modo núcleo o modo del monitor – permitiéndoles ejecutar todos los tipos de operaciones
de hardware y acceder a todos los dispositivos de memoria y de E/S.
Otros procesos se ejecutan en Modo del usuario, que les prohíbe ejecutar algunos comandos, como los
comandos de E/S de bajo nivel.
El modo del usuario también introduce el mecanismo de hardware de protección de la memoria, de modo
que un proceso solo puede acceder a la memoria dentro de su espacio de memoria predefinido. Esto
protege al resto de la memoria – usada por el SO. y otros procesos – de acceso erróneo o malicioso a su
espacio de la memoria que puede dañar sus datos o el código del programa.
Sistemas operativos Monotarea y Monousuario
Este SO. ejecuta un solo proceso a la vez. Los primeros SO. eran de este tipo, así como los SO. de las
primeras PC – Como las CP/M – y las primeras versiones del MS-DOS. Hoy es posible encontrar SO
semejantes en sistemas con recursos limitados como los sistemas embebidos. Existen algunas cuestiones
que deben manipular. Los servicios principales que proporciona son la manipulación de E/S e iniciar y
terminar programas. La gestión de la memoria es bastante
simple, ya que solo el SQ y un proceso residen en memoria en cualquier instante, no hay necesidad de
planificación de la CPU.
Sistemas operativos Multitareas
Un SO. así controla la ejecución simultánea de múltiples procesos. Por tanto, debe contar con un
componente de planificación de la CPU que escoja cuales de los procesos listos ejecutar a continuación.
La mayoría de las computadoras modernas admiten la característica multitareas. Una de las razones para
crear SO. multitareas fue para mejorar la utilización del procesador al mantener ocupada la CPU mientras
se efectuaban operaciones E/S y requiere esperar a que termine la operación, entonces la CPU permanece
sin hacer nada hasta que se completa la solicitud de E/S. Al tener varios procesos listos en memoria para
ejecutar, la CPU puede cambiar a la ejecución de otro proceso mientras se efectúan las operaciones de
E/S. Cambiar de la ejecución de un proceso a la ejecución de otro se denomina cambiar de contexto. Pero
hay un costo muy elevado para hacer esto. Es necesario guardar todo el estado de la CPU, de modo que
sea posible restaurarlo una vez que el proceso se reanude más tarde. Básicamente, cuando un proceso en
ejecución – por ejemplo , un proceso A – solicita operaciones E/S que puede manipular un controlador
E/S, el módulo de planificación de la CPU del SO. debe comprobar si hay algún proceso en el estado listo.
En caso afirmativo, uno de los procesos listos – por ejemplo , el proceso B – se selecciona con base en el
algoritmo de planificación de la CPU. El SO. guarda el estado de procesador del proceso A ( en el BCP de
A) y carga el estado de procesador del proceso B (del BCP de B) en los registros idóneos de la CPU. Luego,
otorga el control de la CPU al proceso B, que se mueve al estado de espera (o bloqueado) hasta que se
completa la operación de E/S
La característica multitarea ahora está disponible en los SO. de casi todas las computadoras, incluyendo
las personales. Aun cuando una PC tiene por lo general un solo usuario interactivo, este puede crear
múltiples tareas. Por ejemplo si hay ventanas múltiples en la pantalla a menudo cada una es manipulada
por una tarea o proceso por separado, además en el fondo puede haber otras tareas en ejecución. Algunos
de los primeros SO. multitarea podían manipular solo trabajos por lotes, que eran cargados en el disco
por volumen mediante lectoras de tarjetas o otros dispositivos de E/S. Muchos sistemas actuales
manipulan tanto trabajos por lotes como interactivos. Los trabajos interactivos son procesos que
manipula un usuario al interactuar directamente con la computadora a través del ratón, teclado, la
pantalla, y otros dispositivos E/S.
Es posible distinguir aún entre dos tipos de SO. multitarea:
Los que suelen interactuar con usuarios únicos y los que admiten usuarios interactivos múltiples. Los
sistemas multitarea de usuario único incluyen la mayor parte de las PC modernas que admiten la apertura
de ventanas. En tales sistemas es común que un usuario interactúe con el sistema aunque el usuario pueda
tener varias tareas que iniciaron a la vez, cada uno en ventanas separadas. La tarea que constituye el
centro de atención actual del usuario se denomina tarea de primer plano, mientras que las otras se
denominan tarea de fondo. El otro tipo de sistema multitarea manipula usuarios interactivos múltiples en
forma simultánea, por lo que se denomina SO de tiempo compartido.
SO y Servidores de tiempo compartido
Un SO multiusuario o de tiempo compartido también admite multitareas, pero con un gran número de
tareas ( procesos ) en ejecución son usuarios que interactúan con la máquina. Estos sistemas se llamaban
así pues el tiempo de la computadora era “compartido” por los múltiples
usuarios simultáneos. En término de las partes internas del SO. la diferencia principal entre procesos
interactivos y por lotes consiste en sus requerimientos de respuesta.
Los trabajos interactivos por lo regular admiten muchas interacciones cortas y requieren que el sistema
responda rápidamente a cada interacción. Pero una respuesta pronta a los requisitos de los usuarios
interactivos demanda un gran nivel de intercambio de contexto, lo cual introduce bastantes gastos
indirectos improductivos. Los trabajos por lotes, no cuentan con usuarios vivos, por lo que la respuesta
rápida no es un requerimiento. En consecuencia se requiere menos intercambio de contexto y se gasta
más tiempo en cálculos productivos. Un SO. de tiempo compartido admite tanto trabajos interactivos
como por lotes, y generalmente proporciona prioridades más altas para los trabajos interactivos. Los
primeros sistemas de tiempo compartido en las décadas de 1960 y 1970, como el OS 360 TSO de IBM y el
MULTICS de Honeywell admitían grandes cantidades de usuarios interactivos que estaban conectados al
mismo sistema mediante monitores y terminales falsos, debido a que en esa época los terminales
costaban varios órdenes de magnitud menos que el sistema de la computadora en sí.
A medida que el precio del hardware y de los procesadores se reducía en forma dramática la necesidad
por tiempo compartido declinaba. En computación moderna la nueva generación de sistemas que puede
considerarse como la sucesora de los sistemas interactivos de tiempo compartido la constituyen los
sistemas que se usan en servidores de archivos, y en bases de
datos y de la red. Los servidores de archivos y los servidores de bases de datos manipulan solicitudes
para el acceso a archivos y bases de datos desde decenas hasta miles de usuarios. En lugar de localizarse
en terminales falsas conectadas a procesos de ejecución en el servidor, los usuarios trabajan en PC o en
estaciones de servicio y las solicitudes llegan al servidor mediante la red.
Grandes servidores de bases de datos a menudo se denominan sistema de procesamiento de
transacciones ,ya que manipulan una multitud de transacciones de usuario por segundo. Los servidores
de red manipulan solicitudes para documentos de la red y a menudo recuperan algo de la información
desde los servidores de base de datos. Los servidores de base de datos y de la red requieren que los SO.
sean capaces de manipular cientos de procesos actuales.
La Red y los SO. Distribuidos
Sabemos que las computadoras están conectadas permanentemente a una red, esto permite compartir
información y recursos entre múltiples máquinas, y requiere que el SO. proporciona funcionalidad
adicional para estas conexiones, esta funcionalidad puede clasificarse en dos niveles principales:
1 –Servicios de bajo nivel de acceso a redes El SO. incluye por lo regular una funcionalidad adicional para
establecer conexiones a redes y para enviar y recibir mensajes entre las máquinas conectadas
2 –Servicios de alto nivel. Los usuarios desean poder conectarse a otras máquinas para buscar
información, descargar archivos o programas, esto suele llevarse a cabo mediante buscadores de la red o
servicios especializados, como el telnet para entrar a máquinas remotas o FTP para transferencia de
archivos.

Los protocolos de redes normales proporcionan varios niveles de servicio,desde el nivel de hardware
básico hasta el nivel de interacción del usuario. En forma separada de la conexión de red, un SO.
distribuido es capaz de proporcionar un amplio espectro de capacidades. Un SO. distribuido es muy básico,
también conocido como SO. de la red, proporciona la capacidad de conexión de una máquina en la que
está trabajando el usuario – denominado cliente – con una
maquina remota – denominada servidor – y acceder al servidor remoto. Para esto el cliente debe conocer
el nombre o dirección de la máquina específica a la que desea acceder. Los servicios telnet o FTP
proporcionan este servicio.
Además de esto un SO. distribuido puede permitir que un usuario que inició sesión en la máquina de un
cliente acceda de forma transparente a todos los servicios y archivos posibles, esto se denomina
transparencia de ubicación. Los archivos y servicios pueden reproducirse físicamente en múltiples
sistemas, de modo que el SO. pueda escoger la copia que le sea más fácil o eficiente acceder, esto se
denomina transparencia de recopilación. El SO. también es capaz de realizar equilibrio de carga dinamico
para escoger una máquina que no esté muy cargada al elegir un servidor.
SO. de tiempo real
Estos son sistemas multitarea que cuentan con el requerimiento adicional de plazos temporales para
completar algunas o todas sus tareas, son dos tipos de plazos:
1 –Plazos duros. Una tarea con un plazo duro de, ej: en milisegundos debe completarse en menos de
milisegundos de misión, en caso contrario sería inútil y podría haber graves consecuencias, algunos de
estos ejemplos son tareas de funciones o en refinación de petróleo.
2 –Plazos blandos o suaves. Un proceso con un plazo blando de n milisegundos debe completarse en n
milisegundos de sumisión, sin embargo , el plazo puede no respetarse sin que haya ninguna consecuencia
catastrófica, ej: una tarea para actualizar la imagen en un reality game a medida que el usuario se desplaza
ahí.

Enfoques arquitectónicos para construir un SO.

 Enfoque del SO. con núcleo único y monolítico
Sabemos que los primeros SO. se escribieron como un programa único, este enfoque para construir el SO.
se denomina enfoque del núcleo o del núcleo monolítico, ya que el SO. con un núcleo monolítico incluye
más funcionalidad, su tamaño es mayor desde unos cuantos miles de bytes, con memoria limitada y
costosa, el size overhead del SO. ( porcentaje de la MP ocupada por el SO. ) se consideraba demasiado
grande, esto molestaba no solo la memoria ocupada por el SO, sino como la mayoría de los programas
grandes, el SO. era menos eficiente que un sistema minimo, tenia mas errores, más difícil de mantener,
esto condujo a los diseñadores de SO. basados en un diseño más modular, POR CAPAS.
Enfoque por capas del SO.
Para este enfoque, el SO. debía dividirse en módulos que estuvieran limitados a una función específica,
como planificación del procesador o gestión de memoria. Los módulos estaban agrupados en capas de
abstracción creciente – cada capa proporciona una vista más abstracta del sistema y depende de los
servicios de la capa que está abajo –. Este enfoque por capas oculta las peculiaridades y los detalles que
surgen al manipular los dispositivos de hardware, y proporciona una vista común abstracta del resto del
SO. Así, cuando nuevos dispositivos ingresaron al mercado, fue posible agregar nuevos controladores de
dispositivos al núcleo sin afectar a los otros módulos del SO, que proporcionan gestión de memoria,
planificación del procesador e interfaz del sistema de archivos.
Este enfoque puede extenderse para implementar un SO. con varias capas, generalmente se usan dos o
tres capas.

DATO:Los sistemas operativos actuales están construidos con base en una arquitectura por capas.
Enfoque del micronúcleo en un SO.
En el enfoque micro núcleo solo se incluye funcionalidad básica (generalmente las interfaces a los varios
tipos de controladores de dispositivos ). Específicamente, el único código en estos módulos debe
ejecutarse en modo supervisor, porque usa recursos privilegiados, como instrucciones protegidas o
accede a la memoria que no está en el espacio del núcleo. El resto de las funciones del SO. siguen siendo
parte del SO. residente, pero ejecutándose en modo usuario. El código que se ejecuta en modo protegido
puede hacer cualquier cosa, por lo que un error en este código podría producir un desastre completo. Así,
la teoría del micronúcleo es que los beneficios de este enfoque surgen parcialmente del hecho de que la
cantidad de código que se ejecuta en modo supervisión es más pequeña, lo cual lo robustece más.
También les facilita la inspección de defectos. Así mismo, el esfuerzo adicional de diseño requerido hace
más probable que la implementación sea correcta. Finalmente es más fácil transportar con un
micronúcleo pequeño a una nueva plataforma que un núcleo grande, con capas, pero monolítico. Por otro
lado, un micronúcleo debe usar interrupciones a fin de efectuar las llamadas necesarias de las porciones
en modo usuario del SO. a las porciones del modo supervisión. Estas interrupción requieren interruptores
de contexto.

Algunas técnicas y
cuestiones para la implementación de un SO.
Manejo de interrupciones usando vectores de interrupción
Recordando..Una interrupción es un mecanismo que usa un SO. para advertir al sistema que ha ocurrido
algún evento de alta prioridad que requiere atención inmediata. Muchos eventos de interrupción están
asociados con E/S. Algunos de estos eventos típicos de interrupción señalan que se ha completado una
operación de escritura o de lectura en un bloque de discos, lo cual indica que se ha oprimido un botón del
ratón o alguna tecla. Como se puede ver, la mayoría de estas interrupciones corresponden a alguna acción
del hardware. El hardware asocia con cada evento de interrupción un número que el controlador de
interrupciones suele colocar en un registro de interrupciones una vez que ocurre el evento
correspondiente , y , dependiendo del tipo particular de interrupción, el SO. debe emprender ciertas
acciones, pero.. ¿Cómo el SO. puede determinar de manera eficiente cuál evento de interrupción ha
ocurrido y cómo inicia el proceso idóneo que atienda esa interrupción?
La técnica normal para la manipulación de interrupciones utiliza una estructura de datos llamada vector
de interrupción. El vector tiene un elemento por cada número de interrupción. El elemento contiene la
dirección en la memoria de la rutina que atiende ese tipo de interrupción. El número de interrupción
colocado en el registro de interrupciones se usa como un índice en el vector de interrupción. El elemento
del vector de interrupción es escogido por el hardware como una dirección, y el hardware llama de manera
efectiva la rutina de interrupción idónea como una subrutina. Cuando la rutina de interrupción termina,
simplemente regresa desde la llamada, continuando el proceso que se interrumpió.
En un pequeño sistema embebido con solo unos cuantos dispositivos E/S, el hardware puede no contar
con un sistema de interrupción. La alternativa se llama sistema impulsado por estado, en este sistema, la
aplicación (o el SO.) en general es un gran ciclo que comprueba el estado de cada dispositivo a la vez para
ver si requiere ser atendido.
Llamadas al Sistema
Los programas de aplicación normalmente necesitan usar datos y servicios gestionados por el SO, los SO.
suelen gestionar todos los dispositivos de hardware en el sistema como tarjetas de sonido o de audio y
no se permite que las aplicaciones accedan directamente a ellos. Las aplicaciones pueden necesitar
comunicarse entre sí, y el SO. debe actuar como intermediario.
Cualquier aplicación normal requiere tales habilidades, y la forma en que solicita servicios al SO. es usando
una llamada al sistema. Esta es similar a cualquier otra llamada a una función. Primero, la aplicación carga
ciertos registros con información que describe el servicio requerido y luego ejecuta una instrucción de
llamada al sistema. Sin embargo, en lugar de llamar directamente a una sección del código que efectúe la
función, la instrucción de la llamada al sistema en general origina una interrupción que manipula el SO. El
SO. realiza el servicio solicitado y luego devuelve el control a la aplicación. Este mecanismo también
permite que el SO. implemente algo de seguridad al comprobar primero si a la aplicación se le permite
acceder al recurso en la forma solicitada.
Colas y tablas
Un SO. gestiona muchas estructuras de datos para llevar a cabo sus tareas. Dos de las estructuras de datos
comunes que se usan son tablas y colas.
Las tablas se utilizan para almacenar la información sobre varios objetos que gestiona el SO, por ejemplo
el BCP es un ejemplo de tabla que usa el SO. mantiene a fin de seguir la pista de información asociada con
cada proceso. Otra tabla usada es la tabla de páginas, que es usada para seguir la pista del espacio de
direcciones de un proceso cuando el hardware admite memoria en páginas. El SO. mantiene un BCP y una
tabla de páginas para cada proceso. Otra tabla típica es la tabla de archivos abiertos, que mantiene un
elemento por cada archivo abierto en el sistema.
El SO. también mantiene varias colas para seguir la pista de información que está ordenada de alguna
forma. Cada recurso que puede compartirse por múltiples procesos requiere una cola, a fin de mantener
solicitudes de servicio para ese recurso. Por ejemplo, debido a que múltiples procesos pueden requerir
páginas de discos para operaciones de lectura y escritura, el SO. mantiene una cola de planificación de
disco que tiene una lista de procesos esperando a operaciones de E/S en el disco. Las solicitudes para
servicios de impresión pueden mantenerse en una cola de impresión. Una lista de procesos listos para su
ejecución puede mantenerse en una cola de procesos listos.
Enfoque orientado a objetos
En este enfoque, cada módulo del SO. debe diseñarse como una colección de objetos y cada objeto incluye
métodos que se proporcionan como servicios a otras partes del SO. o a programas de aplicación El hecho
de construir el SO. con objetos ofrece diversas ventajas, como el encapsulado de estructuras de datos
objeto, separando una interfaz de su implementación, extensibilidad y facilidad de reuso de objetos, entre
muchas otras ventajas. La característica clave de un objeto es que su estructura interna oculta, y cualquier
acceso a los datos que contiene un objeto es a través de los métodos del objeto. Esto hace menos probable
que una aplicación pueda usar indebidamente un objeto y provocar así problemas para otros módulos.
Máquinas virtuales
Otro enfoque al diseño de un SO. es la técnica de usar un emulador de software para abstraer o virtualizar
un sistema total ( Dispositivos, CPU y memoria). Este concepto se denomina Máquina Virtual ( MV ). Una
razón fundamental de las MV es que permiten que los distintos entornos de emulación se protejan entre
sí de modo que la caída en un programa no hace caer a los demás. El diseño del sistema que está
abstrayendo puede ser un diseño de hardware real o una máquina virtual de aplicación idealizada.
Máquinas virtuales de hardware
En este enfoque un programa o un subsistema de núcleo proporciona una emulación de software de una
máquina de hardware real. Hay dos clases distintas de tal emulación, una en la cual el sistema de hardware
huésped en sí está siendo emulado y otra donde otra CPU está siendo emulada.
La emulación de la máquina huésped a menudo se usaba para permitir la ejecución simultánea de
múltiples núcleos de SO. En tales casos, la emulación se efectúa por medio del núcleo de un SO. Huésped.
Este modelo permite que uno o más núcleos de SO. corran en la parte superior de la capa de una máquina
virtual denominada SO. Huésped. La capa MV crea una interfaz que abstrae el hardware, de modo que
cada núcleo cree que solo él está en ejecución en el hardware. Los núcleos pueden ser de SO. distintos o
instancias diferentes del mismo SO. Una de las dificultades más importantes en el modelo de MV es crear
una MV que emule en forma precisa al hardware, de modo que los núcleos puedan ejecutarse en una MV
de la misma forma en que se ejecutan directamente en el hardware real ( solo que mas lento ya que en
realidad se encuentra compartiendo el hardware con otros núcleos).
Máquinas virtuales de aplicación
Muchas veces, la máquina que se está emulando no es una CPU real, sino una especificación de máquina
idealizada, diseñada para manejar ya sea un lenguaje específico o una amplia variedad de lenguajes Tales
sistemas algunas veces se denominan máquinas virtuales de aplicación. Una MV muy popular es la
Máquina virtual de Java (MVJ), que crea una máquina abstracta que ejecuta programas de Java.
Otro paquete como estos es el lenguaje común en tiempo de ejecución (CLR) creado por Microsoft para
manejar su arquitectura .net
Puesto que la emulación de una MV puede ser ineficaz, el código creado para ejecutar una MVA también
puede compilarse en código navito de máquina, a efecto de que se ejecute más rápido, esta técnica se
llama justo en el momento ( JIT ).
Enfoque minimalista contra maximalista de la funcionalidad de un SO. y compatibilidad hacia atrás
COMPATIBILIDAD HACIA ATRÁS
Es la capacidad de ejecutar antiguos programas de aplicación en versiones más recientes del SO. Esta
capacidad es un punto de venta para casi todas las versiones nuevas de cualquier SO.

ElMasri cap 8 hasta 8.3 (INTRODUCCIÓN A PROCESOS)

Recordando.. Una función fundamental de un SO. es la ejecución de un programa, y un programa en
ejecución se denomina proceso. Un programa es algo estático. En la mayor parte del SO, un programa se
guarda en un archivo en almacenamiento secundario.Finalmente, un SO. recibe instrucciones, por lo
regular de un usuario, aunque algunas veces de algún otro proceso, para ejecutar un programa –tal vez
uno se está ejecutando en otro sistema – el SO. trae ese programa a almacenamiento primario (RAM) y
comienza a ejecutarlo. Esta entidad en
La ejecución se denomina proceso. Es posible ejecutar varias copias del mismo programa al mismo tiempo
en un sistema. Por ejemplo, es posible iniciar varias copias de un entorno de desarrollo de un programa
en ejecución al mismo tiempo. Cada copia en ejecución de ese programa debe ser un proceso por
separado. Otros términos usados en vez de proceso puede ser trabajo o tarea.
A medida que un proceso se ejecuta cambia su estado. De manera evidente cambia el contador de
programa (PC o registro de dirección de instrucciones) a medida que se ejecuta llama a subrutinas o
funciones o invoca métodos, bucles y así sucesivamente. También cambia cada contenido de los registros
de la CPU, el registro de estado y el apuntador de pila, estas cuestiones se denominan colectivamente
estado del proceso.
A la vez que se desea poder ejecutar muchos procesos al mismo tiempo, se requiere que este intercambio
entre procesos sea transparente para ellos mismos ( es decir un proceso no necesita saber si será
suspendido como cuando para la ejecución de otro proceso ). Estamos creando “una cpu virtual” en el
sentido de que todo proceso puede actuar como si fuese el único en ejecución. Puesto que todo este
intercambio se efectúa entre procesos, cuando detenemos uno para iniciar otro es necesario guardar el
estado del proceso que se está deteniendo y restituir el estado previo del que está iniciando. ( esto supone
que el proceso que está iniciado no es un proceso nuevo.) En la memoria se crea una estructura donde es
posible guardar información que describe el estado del proceso que se está deteniendo. Esta estructura
se denomina bloque de control de procesos (BCP).
DESCRIPTOR DE PROCESOS: BLOQUE DE CONTROL DE PROCESOS
Una imagen de un BCP típico. SO. diferentes guardan información diferente en el BCP, aunque hay algunas
cosas bastante comunes:
Es importante saber que mientras el proceso está en ejecución, la información de estado de la CPU no se
actualiza; solo se guarda cuando el proceso se detiene por alguna razón.
ESTADO Y TRANSICIONES DE LOS PROCESOS

El estado más evidente para un proceso es el de ejecución. Pero solo puede ejecutarse un proceso a la vez
en cualquier CPU; pero ¿que están haciendo los otros procesos? Algunos están listos para su ejecución y
algunos están esperando que algo ocurra antes de continuar.
Diseñadores y autores diferentes usan modelos distintos para explicar la gestión de procesos por un SO.
Resulta común ver el modelo de 3 estados que elimina los estados nuevos y de salida. Los estados (o
nodos) se indican con hexágonos. Las fechas ( o transacciones) son los eventos que originan la transición
de un estado a otro. (los de 5 estados se ven como nuevos,listos,en ejecución, en espera y de salida).
El estado nuevo representa un proceso que el SO. está preparando en el momento para ejecutar pero que
aún no está listo. Cuando el usuario indica al módulo procesador de comandos ejecutar un programa, este
pasa por una transición marcada como “0-Programa cargado” y es colocado en el estado nuevo. Primero,
el SO. debe crear un nuevo BCP, asignar una identificación del proceso, y llenar todos los demás
parámetros del otro BCP. Luego, debe reservar memoria, leer el programa del almacenamiento
secundario, etc. Especialmente en un sistema de múltiples CPU, no se desea que una instancia del SO. se
ejecute en otra CPU intentando despachar este proceso, de modo que hasta que esté realmente listo para
ejecutar se marca como si estuviese en el estado nuevo.
Cuando el proceso está listo para su ejecución se coloca en el estado listo. Esto se ve como la transición
“1- proceso iniciado”. Al final será seleccionado por el SO como el siguiente proceso a ejecutar. Luego es
despachado( es decir, se coloca en ejecución). Esta transición se indica por
la flecha identificada como “2-Obtiene tiempo de CPU”. A medida que el proceso se ejecuta puede decidir
esperar que ocurra algo antes de continuar. Una causa muy común es que el proceso ha solicitado un
operación de E/S y desea esperar hasta que la operación se complete
y así se mueve al estado de espera, también llamado suspendido. Esta transición se identifica como “3-
Necesita algo”.
Cuando un proceso está en el estado en espera, tarde o temprano ocurre el evento que está esperando
el proceso, por supuesto este evento puede no ocurrir jamás, como ejemplo de esta transición, quizá la
E/S solicitada por un proceso ya haya terminado. Esta transición se ha identificado como “4- Obtiene lo
que necesita” y el SO coloca el proceso en estado listo. La siguiente transición en este modelo se identifica
como “5- interrumpido”. El SO. puede escoger interrumpir un proceso en ejecución por varias razones,
aunque no todos los SO. proceden así.
La primera instancia es un sistema por espacios de tiempo donde a cada proceso a la vez se le proporciona
una breve cantidad de tiempo para ejecución. Si no ha hecho nada en ese lapso, provoca que el proceso
vaya al estado en espera, y luego al SO. lo saca del estado en ejecución y lo coloca en listo y permite la
realización de otro proceso. Una segunda instancia sería donde un proceso con alta prioridad ha estado
esperando que ocurra un evento y esto ocurre. Este SO. es por Tiempo.
Si el proceso en ejecución tiene prioridad más baja que el que estaba en espera, entonces el SO. puede
detener el proceso de prioridad más baja que el que estaba en espera, entonces el SO. puede detener el
proceso de prioridad más baja , colocarlo de vuelta en el estado listo y situar el proceso de prioridad más
alta en el estado de ejecución. Este último SO. es por planificación de prioridad
El estado de salida se reserva para procesos que han sido terminados por el SO. Puede haber varios
varones por las que un proceso llega a este estado. Esta transición se ha identificado como “6-Terminado
o abortado”. El proceso o el SO. han detectado un problema y el proceso
se ha detenido antes de que ocurra más daño. Pero hay otra razón por la cual el proceso podría abandonar
el estado en ejecución y pasar al estado de salida. Como por ejemplo, un proceso padre de éste puede
decidir que el proceso hijo ya no es necesario y solicitar al SO. que lo elimine.
El estado de salida es más bien peculiar, pues los procesos no permanecen ahí mucho tiempo, pero estos
procesos no están en ejecución, listo o en espera, de modo que es posible hablar razonablemente acerca
de este estado como si fuese algo distinto de los demás. El SO. requiere hacer mantenimiento para este
proceso, como liberar los recursos que el proceso pudo haber adquirido y aún no devuelve, asegurar que
los archivos estén cerrados y arrancar el BCP para el proceso. Hasta que los recursos se han recuperado
por completo, no es aconsejable que este proceso sea elegido para su ejecución, de modo que permanece
en este estado mientras prosigue el trabajo.
Observando, excepto en el estado de ejecución, normalmente puede haber muchos procesos en cualquier
estado, Así que no debe haber sorpresa el hecho de encontrar que para la mayor parte de los SO. existe
un mecanismo elaborado para seguir todos los procesos que hay en cualquier de los otros estados. El
estado listo consta de por lo menos una estructura, se identifica ésta como cola lista.
El estado en ejecución contiene solo un proceso, a menos que se cuente con un sistema con múltiples
CPUs, en ese caso los procesos en ejecución en las diversas CPU pueden están vinculados en una lista por
separado.

Para el estado en espera puede haber muchas colas, algunas son operadas con FCFS o FIFO. ElMasri CAP

10 (GESTION BASICA DE MEMORIA)

GESTIÓN DE MEMORIA ¿PORQUE GESTIONAR LA MEMORIA PRIMARIA?
Anteriormente vimos que uno de los trabajos fundamentales de un SO. es la gestión de procesos que se
ejecutan en la CPU, ahora vamos a ver el segundo trabajo más importante del SO: la gestión de memoria
primaria (RAM).
El objetivo básico de la gestión de la MP es permitir la ejecución de la mayor cantidad de procesos posible.
El SO. proporciona funciones API para permitirnos asignar, acceder y regresar memoria.
Cuando a los procesos se le asigna memoria, el SO. debe seguir la pista de qué partes de la memoria están
libres, cuales se han asignado y a que procesos se les asignaron. Algunas veces el SO. también debe
apropiarse de la memoria de los procesos. En este caso debe estar preparado para guardar el contenido
actual de la MP en la MS (memoria secundaria) rastrear dónde se almacena el contenido para cada parte
de cada proceso y restituir el contenido de la memoria primaria cuando se reanuda el proceso apropiado.
En la mayor parte de las situaciones el SO. intenta gestionar la memoria en formas transparentes para la
aplicación, pero en algunos casos la transparencia no es completa.
MODELO VINCULANTE: PASOS EN EL CICLO DE DESARROLLO
Primero vamos a describir el modelo estándar de los pasos para construir una aplicación, cargarla en la
memoria y ejecutarla.
Hay cinco pasos en la secuencia de eventos que resultan en un proceso de ejecución en la memoria.
1 –Codificar o escribir el programa ( por lo regular lenguaje simbólico)
2 –Traducir el programa simbólico ( generalmente un ensamblador o compilador, a veces intérprete)
3 –Ligamos o enlazamos el módulo con módulos semejantes por separado 4 –Cargamos el programa en
memoria
5 –Ejecución del programa

Supongamos que estamos creando un proceso que consta de dos módulos. Contamos con un
procedimiento principal que denominamos subrutina XYZ que hemos escrito previamente.
A medida que pasamos hacia modelos más complejos, la idea es que nos enfocamos en una cuestión de
vinculación . Vincular es el proceso de determinar en qué parte de la memoria física debe ir la subrutina
y de hacer referencia en el punto de la rutina principal hacia subrutina.
VINCULACIÓN EN TIEMPO DE CODIFICAR
En un entorno muy simple como un sistema embebido BIOS muy delgado, podríamos decidir
manualmente el sitio en que debe ir cada parte del programa. Podríamos colocar el módulo principal en
la ubicación 100 y la subrutina XYZ en la ubicación 500. Si codificamos el módulo principal en lenguaje
ensamblador, podríamos incluir una directriz ensambladora como ORG 100, y en la subrutina podríamos
incluir un ORG 500. Estas directrices hacen que el ensamblador genere un código que haga referencia
absoluta a estas direcciones de la memoria. En nuestro módulo principal debemos saber que la subrutina
XYZ estará en la dirección 500 de modo que en lugar de emitir una llamada XYZ podemos producir la
llamada a la ubicación 500.
Ejemplo: En las primeras computadoras y microcomputadoras, los primeros sistemas tenían muy poco
software y pocos periféricos. Los programadores no solo asignaban estas direcciones manualmente;
escribían los programas en lenguaje máquina, e incluso los introducían manualmente en la memoria al
manipular interruptores y botones en el panel delantero de las máquinas. En algunas, había dispositivos
periféricos que usaban una dirección de la memoria fija como buffer, de modo que el programador ni
siquiera tenía opciones, el hecho de que los programadores asignan manualmente la memoria era algo
propenso a errores y consumía tiempo.
Cuando los programas se perforaban rutinariamente en tarjetas y no se contaba con cintas magnéticas o
memorias giratorias, era un proceso bastante complicado cargar el programa ensamblador en la memoria,
alimentar el programa fuente, obtener un módulo objeto perforado en las tarjetas, cargar el programa
ligador en la memoria, alimentar ese módulo objeto en el ligador, perforar un programa ejecutable y,
finalmente cargar el programa objeto en la computadora y ejecutarlo. Como resultado, era común parchar
programas ejecutables que se habían perforado en tarjetas. Los listados en ensamblador incluían el
lenguaje de máquina que se producía para cada instrucción, lo que permitía a los programadores
encontrar la tarjeta que contenía una instrucción incorrecta, cargarla en la perforado y reparar el
programa al modificar el lenguaje máquina. Desafortunadamente, esta práctica continuó durante algún
tiempo, y era propensa a errores. Finalmente el número de parches se volvió poco manejable, de modo
que el programador debía regresar al mazo fuente, hacer todos los cambios al programa fuente y volver
a ensamblar. Lamentablemente resultaba demasiado fácil perder uno de los cambios realizados en el
fuente, de modo que era raro encontrarse arreglando errores en el código fuente que ya se habían
reparado con un parche.
VINCULACIÓN EN TIEMPO DE LIGAR
En el entorno CP/M, se suponía que todos los programas empezaban en la ubicación 100, de modo que
era imposible incluir la declaración ORG 100 en el módulo principal. Sin embargo, quizá no tengamos
cuidado respecto a donde termina la subrutina XYZ, de modo que en nuestra rutina principal usamos el
nombre simbólico XYZ. Cuando el ensamblador produce nuestro módulo objeto, incluye todas nuestras
instrucciones y datos, aunque también información que indica al programa ligador que tenemos algunas
referencias que requiere reparar. Una vez que el jugador procesa nuestra rutina principal, contará con
una lista de nombres que requiere resolver. Entonces comenzará a procesar otros módulos que le dijimos
que incluyera. A medida que incluye estos módulos en el paso de cargar, encontrará en ellos los nombres
que se definieron ahí. En este caso “XYZ” estará definido en uno de los módulos, al que le dijimos que
procesa el ligador. Cuando el ligador supone donde reside el módulo XYZ en el espacio de direcciones,
regresa y liga las referencias en el módulo principal con las direcciones en el módulo de la subrutina. Ahora
ya se ha tomado la decisión de vinculación en tiempo de ligado en vez de en tiempo de codificación.
Observemos que cuando aplazamos la vinculación hasta un paso después ganamos algo de flexibilidad. Si
en el tiempo de codificación hubiéramos decidido colocar el módulo XYZ en la ubicación 500 y después
encontráramos que era necesario moverlo a alguna otra ubicación, hubiéramos tenido bastantes
problemas para cambiar todas las referencias a esa dirección. El hecho de dejar que el jugador decida
dónde colocar el módulo lo hace más sencillo. Sin embargo, pagamos un poco por la flexibilidad
aumentada. En este caso estamos transportando información extra en los módulos objetos que define los
nombres y las referencias a los nombres, y dedicamos un poco de tiempo extra en el paso de ligado
mientras se efectúa la vinculación. A medida que las computadoras se volvían
más grandes y veloces, no obstante este tiempo y espacio extra se han vuelto muy poco costosos, de
modo que ni siquiera pensamos en ello.
UN PROCESO ÚNICO
En el entorno CP/M, el SO. residia en la parte superior de la memoria. Los programas de aplicación
empezaban en la ubicación 100 para evitar el vector de interrupción en la memoria baja y crecían hacia
arriba. Desafortunadamente, a medida que el SO. crecía, podía volverse tan grande que un SO. actualizado
podría utilizar la memoria que necesitaba un programa que estaba ejecutándose bien antes de la
actualización. MS-DOS cambió el enfoque: el SO. se cargaba en la RAM baja y el programa se cargaba
arriba de esta. Cuando la aplicación intentaba cargar el programa, si había suficiente memoria disponible,
este se cargaba y comenzaba su ejecución. En caso contrario, cuando se creaba una aplicación bajo el MS-
DOS, este se cargaba para su ejecución en una versión específica del SO. Este paso define la dirección de
las rutinas de servicio en el SO. y dirección en que la aplicación debía empezar a cargarse.
Lamentablemente esto significaba que cuando salía una versión de MS-DOS que modificaba el tamaño
absoluto del SO. residente, todas las aplicaciones debían volver a ligarse para su ejecución en la nueva
versión.

En la sig figura vemos la arquitectura típica de uno de los primeros SO para una computadora central que
sólo ejecutaba un proceso único. El programa ejecutable podía crearse para residir en una dirección
particular arriba del núcleo del SO. Además, un registro base podía cargarse con una dirección baja que el
programa ejecutable no podía redireccionar. Si el programa hacía una referencia a memoria baja de esta
dirección, se generaba una interrupción y el programa no terminaba. Estos sistemas siguen presentando
el problema de que, si el SO. crece, los programas deben ligarse con nuevas direcciones. La solución a este
problema era modificar de alguna manera la función del registro base.
REUBICACIÓN DINÁMICA
Lo que antes se llamaba registro base ahora es registro de reubicación , el valor cargado en el registro ya
no era un límite, en lugar de ello se creó el programa ejecutable para actuar como si estuviera ubicado en
la dirección 0, y el valor en el registro de reubicación se añadió a cada referencia a la memoria que hacía
el programa. Ahora el programa no tiene que ligarse cada vez que cambiaba el SO, puesto que toda
referencia a la memoria se ubicaba de manera automática a medida que se ejecutaba el programa.

ESPACIO DE RAM FÍSICO CONTRA ESPACIO DE RAM LÓGICO

La diferencia entre el espacio de dirección lógico y el físico, cuando se compilaba un programa se creaba un
programa que había que cargar en la RAM en la dirección que se le asignaba, ya fuera en el paso de traducción o
en ligado. El programa ejecutable se compilaba para referir un rango de dirección que corresponden uno a uno con
las direcciones de memoria física. En realidad había dos espacios de direcciones en uso, el primer espacio es el
conjunto de
direcciones que genera la CPU a medida que se ejecutaba el programa, este espacio se llama espacio de direcciones
lógicas. El programa ejecutable se cargaba en memoria primaria. El conjunto de direcciones usado para acceder a
esta memoria se denomina espacio de
direcciones físicas, Cuando se introdujo el registro de reubicación se hizo evidente que ambos espacios eran
diferentes. El programa ejecutable en el disco se había creado de modo que generará direcciones con una dirección
baja de cero. Pero cuando se ubicó en la memoria, en realidad cargaba en la dirección lógica 10000. El hardware de
la dirección de la memoria ubicaba dinámicamente las direcciones lógicas que generaba el programa a medida que
se ejecutaba, y al añadir el valor en el registro de ubicación transformaba el espacio de
direcciones lógicas en el espacio de direcciones físicas. La aplicación cuando se está ejecutando en la CPU genera
una referencia a memoria. Esta podría ser la dirección de la siguiente instrucción en el programa, una llamada a un
subrutina, una referencia a un dato o muchas otras cosas, en esta caso la referencia es a la dirección 456 en el
espacio de direcciones lógicas del programa. El SO, ha cargado el registro de ubicación con la dirección física del
inicio del programa, en este caso 10000. El hardware de la memoria agrega el valor en el registro de ubicación a la
dirección lógica y genera la dirección física de 10456.

SUPERPOSICIONES ( OVERLAYS )
Los programadores requieren agregar funciones que pueden ejecutarse en estas memorias pequeñas, sigue siendo
bastante común tener un programa integrado por 3 partes, fase inicial, bucle principal de computación y alguna
fase final de reporte. Ellos se percataron de que estas partes de un programa no necesitaban estar en la memoria
al mismo tiempo, de modo que decidieron dejar que se superpusieron entre sí en la memoria. La parte fundamental
del programa es justo una serie de llamadas a subrutinas que implementan las tres fases, quizá “init”, “main- loop”
y “wrap-up”. Las llamadas a la función del SO. pueden agregarse al programa para cargar la subrutina idónea antes
de que se efectúe la llamada. La parte principal siempre estaba en la memoria, y las otras fases se traían antes de
ser llamadas. Un programa simple como un ensamblador o un compilador, fácilmente podía ajustarse a la memoria
sin utilizar ninguna superposición, pero si se separaba en fases podía permitir que el traductor procesa programas
fuente más grandes en un espacio de memoria dado.

INTERCAMBIO DE ESPACIO ( SWAPPING )

La primera técnica consistía en mantener varios programas en ejecución al intercambiarlos , lo que funcionaba
como se muestra en la sig figura

Esta muestra el programa A en ejecución en la MP. Este programa llama a la impresión de una línea en la impresora.
Durante este tiempo podemos hacer mucho de E/S de disco y muchos cálculos, de modo que sea posible
intercambiar el programa al escribir el contenido de la MP en el disco e intercambiar el programa B. Podemos
dejarlo en ejecución hasta que emita una E/S para un dispositivo más lento y luego intercambiar de regreso y traer
el programa A. algunas veces el intercambio se denomina roll-out / roll-in.
MÚLTIPLES PROCESOS CON UN NÚMERO FIJO DE PROCESOS
Sin embargo, la técnica de intercambio no fue suficiente y los propietarios de estas máquinas querían lograr que se
hiciera mas trabajo, asi que empezaron a buscar más formas

La MP continuaba volviéndose más barata, de modo que empezaron a pensar en formas para man tener múltiples
programas en la MP y ejecutar más el alternar entre ellos sin intercambio – donde el intercambio es una operación
que requiere muchos recursos – terminaron dándose cuenta que el registro de reubicación podía ejecutar un
programa en cualquier parte, y no solo en la parte superior del SO. residente. Se desplazaron a una organización de
la memoria del SO. como la que se muestra en la figura de arriba (a). Al principio el registro base se había usado
para evitar que las aplicaciones dañen el SO. Luego, el uso de este registro se modificó como un registro de
reubicación, esencialmente para resolver el problema del crecimiento del SO. Ahora que el SO. ejecuta múltiples
programas y un programa realiza una operación de E/S hacia algún dispositivo lento, el SO. simplemente coloca la
dirección de la memoria del segundo programa en el registro de reubicación y empieza a ejecutar el segundo
programa (b).
Además, había otras aplicaciones en ejecución, así que era necesario arreglar las cosas de modo que las aplicaciones
no pudieran dañarse entre sí. La solución era agregar un registro límite que pudiera establecer una cota superior
más allá de la cual un programa no puede direccionar, justo como no podía direccionar más abajo del
establecimiento del registro de reubicación, este registro contiene el tamaño del programa más que la dirección
alta. El hardware agrega esta dirección a la dirección de reubicación con la intención de establecer el límite superior.
Así como es el caso con el límite inferior, si el programa intenta acceder a la memoria más allá del límite establecido
por el registro límite, el hardware genera una interrupción y el SO. aborta la aplicación, así cuando el SO. cambia
de la ejecución de un programa a la de otro, ahora debe fijar tanto el registro de reubicación como el registro límite.
 FRAGMENTACION INTERNA
Cuando se instala este tipo de SO, el administrador debe decidir cuánta memoria apartar para cada área del
programa: una partición. El SO. no modifica el tamaño de estas particiones a medida que el sistema está en
operación, como en los primeros SO. un programa podría no usar toda la memoria. Ahora el SO. está tratando de
colocar más programas en la misma memoria.
El espacio sin usar se denomina fragmentación interna y se muestra en la siguiente figura. Podríamos establecer
una o dos particiones pequeñas

Para ejecutar pequeños trabajos rápidos y una o dos particiones más grandes para las aplicaciones grandes. Esto
haría tender a minimizar el espacio desperdiciado debido a la fragmentación interna.
DISTRIBUCIÓN DE TIEMPO
Otro caso en que el intercambio se utiliza en sistemas diseñados para soportar muchos usuarios en terminales en
un modo denominado distribución de tiempo . Cuando los usuarios editan y prueban los programas, la mayoría del
tiempo ese proceso está en espera del usuario en la terminal. En este caso el sistema puede intercambiar el proceso
mientras el usuario está pensando o tecleando. Cualquier otro proceso podría intercambiarse al almacenamiento
secundario. En el caso de la distribución de tiempo es más probable que haya varias particiones. Podríamos tener
la memoria solo aquellas que no estén esperando que el usuario termine de introducir una línea y estén ya sea en
ejecución o esperando cualquier cosa que no sea E/S de la terminal. El tamaño fijo de las particiones desperdicia
memoria, recordemos que la fragmentación interna. En este caso solo teníamos fragmentación en una sola
partición. Ahora tenemos fragmentación interna en todas las particiones. Sería conveniente poder usar alguno de
estos fragmentos. Si ahorramos suficiente memoria, tal vez podamos ejecutar otro programa y así mantener
ocupada la CPU.
MÚLTIPLES PROCESOS CON UN NÚMERO VARIABLE DE PROCESOS
Una solución parcial a la fragmentación interna consiste en no hacer las particiones de tamaño fijo o en número;
en lugar de ello, usamos tanta memoria como se necesite para ejecutar un programa, requerimos que antes de
ejecutar el programa el programador estime la cantidad de memoria máxima de MP que necesitará. Cuando
empezamos el programa le asignamos toda esa memoria. Si este intenta usar más de la indicada, entonces el SO.
termina con un error. Cuando un programa termina, el SO. vuelve a poner disposición esa memoria para otro
programa. Este espacio suele denominarse hueco o fragmento externo – un bloque de memoria que no estamos
usando en absoluto – en la sig fig lo vemos en un sistema ejecutando 4 apps (a). En la fig (b) se ve que las apps dos
y cuatro han terminado. El SO. suele mantener una lista de huecos disponibles En la fig (c ) se ve que el SO. ha
iniciado la apps 5 en una parte del hueco que quedó donde estaba la apps 2. Ahora quedando un hueco más
pequeño
Pero..Supongamos que el SO. tiene otro programa para ejecutar pero hay muchos huecos, ¿qué hueco escoge? El
primer algoritmo simplemente consiste en explorar la lista de huecos y usar el primero que encontremos lo
suficientemente grande para ejecutar el programa, este se denomina primer ajuste; presenta la ventaja de que es
simple pero puede no ser la mejor opción. Otro algoritmo consiste en usar el hueco más pequeños que se ajuste al
programa, este algoritmo se llama mejor ajuste – desperdiciamos la menor cantidad de MP – este algoritmo
desafortunadamente requiere explorar toda la lista o mantenerla en orden de tamaño.
Pero qué ocurre si el programa necesita 10MB, se tiene un programa a ejecutar que requiere 8MB y se tienen
huecos de 12 MB y 18 MB , si usamos el hueco de 12 MB entonces quedará un hueco de 4 MB, y en general no
podremos usarlo. Si usamos una parte del 18 MB, entonces tendremos un hueco de 10 MB que podremos utilizar,
así el sig algoritmo dice que debemos usar el hueco de peor ajuste, ya que deja el mayor hueco ( y por tanto el más
útil ) , nuevamente este algoritmo requiere la lista de huecos o mantenerla en orden de tamaño.
Una variante del primer algoritmo se llama ajuste siguiente, en este cada búsqueda no se inicia desde el frente de
la lista, no mantenemos ordenada la lista y siempre iniciamos la siguiente búsqueda desde el sitio donde quedo la
ultima, el algoritmo de primer ajuste tiende a romper los huecos en el frente de la lista, de modo que terminamos
con varios huecos pequeños que seguimos buscando aunque son de uso raro, la variante del ajuste siguiente tiene
a distribuir esta fragmentación en toda la lista. En la práctica el peor ajuste resulta ser el peor, son mejores ya sea
el mejor ajuste o el ajuste siguiente.
Ahora supongamos que tenemos dos huecos, cada uno de 5 MB, y que tenemos un proceso por ejecutar que indica
que requiere 8MB, tenemos 10 MB de bloques de memoria libre en los dos huecos – memoria suficiente para
ejecutar este proceso – .Pero la memoria libre no
está en una pieza, de modo que no podemos ejecutar el programa. Esta situación se denomina fragmentación
externa. Recordemos que nuestros procesos son reubicables – pueden ejecutarse en cualquier parte de la memoria
física porque el hardware de la memoria reubica su espacio de direcciones dinámico en la medida que se ejecutan
– Así es posible mover un programa en la memoria aun después que ha comenzado su ejecución. Normalmente el
proceso se suspende, se mueve a otra ubicación y vuelve a empezar. El SO. solo tiene que modificar el valor
colocado en el registro de reubicación de modo que indique el inicio de la
nueva ubicación de la aplicación en la memoria física. Por ej: en la fig (a) si los dos huecos (indicados como “sin
usar” ) juntos fueran muy grandes como para ejecutar la app 6 , entonces el SO. dentro la app 3, la movería al
espacio justo arriba de la app 5 y colocaría esa dirección en el registro de reubicación siempre que se reinicie la app
3. Luego podría iniciar la app 6 ejecutándose en el hueco resultante más grande. Ese resultado se muestra en (b).
Este proceso se denomina compactación .Es posible apreciar que cuando el SO. está moviendo programas en la
memoria no se realiza ningún trabajo en representación de las apps. El SO. está decidiendo gastar la CPU y el ancho
de banda de la memoria para efectos de ejecutar más trabajos en paralelo.
Fig compactación
Ahora podemos apreciar que el hardware de reubicación usa una longitud para un límite superior en lugar de usar
el extremo superior del programa. Si usara la dirección superior entonces cuando reubicamos un programa también
sería necesario volver a calcular el límite superior. Este no es un cálculo complicado y no es necesario hacerlo tan a
menudo, pero si el hardware puede trabajar tan bien como de la otra manera, entonces tenemos suerte de no
tener que hacerlo.
Una complicación en este proceso puede ser que el hardware de E/S puede no usar el hardware de reubicación. En
otras palabras, la E/S se lleva a cabo usando direcciones físicas, más que lógicas. Esto significa que si un proceso
tiene E/S pendiente, entonces no es posible moverlo en la memoria. Así, los procesos que empiezan E/S deben
marcar temporalmente como inamovibles.
También podríamos sufrir a causa de la fragmentación interna, ya que los huecos pueden hacerse cada vez más
pequeños. Para el SO. no resulta eficiente seguir la pista de trozos muy pequeños en la memoria, de modo que hay
una cantidad mínima de memoria que el SO. intenta gestionar.
CARGA DINÁMICA
Con los overlays (superposiciones) no es aconsejable cargar todo el programa en MP al mismo tiempo. En lugar de
ello, el programador decide cuándo cargar las superposiciones y cuándo llamar a las rutinas que están en la
superposición. También es posible que el sistema haga algo semejante. Cuando el SO. carga un programa en MP,
podría cargar solo el cuerpo principal
del programa en memoria. Para acceder a varias subrutinas, podría usar una tabla que muestre cuales rutinas ya
están cargadas en memoria y cuales no, muchos programas siguen una regla, entonces, si no cargamos las
subrutinas cuando el programa empieza por primera vez quizá jamás se necesite cargarlas en absoluto. En
consecuencia, el programa empieza algo más rápido. Si más tarde el programa llama a la rutina, entonces podemos
cargarla en ese instante y habremos pagado muy poca penalización por la espera.
BIBLIOTECA DE ENLACE DINÁMICO
Podemos posponer la vinculación aún un paso más. Podemos aplazar incluso la vinculación de la subrutina con el
módulo principal. En este caso la rutina de biblioteca en si no se vuelve parte del programa ejecutable. Dejamos
intacta la referencia simbólica a la rutina de biblioteca que produjo el compilador. Así como con la carga dinámica,
si nunca se hace referencia a la rutina, entonces no solo nos preocupamos por cargarla en la memoria; ni siquiera
vinculamos el símbolo con una dirección lógica. Dejamos las rutinas en bibliotecas especiales que suelen
denominarse bibliotecas de enlace dinámico o DLL. Cuando se hace referencia a una subrutina en una biblioteca de
estas, entonces , el SO. carga la rutina en la memoria y vincula el enlace en el momento en que se ejecuta el
programa.
Observemos que con este mecanismo se obtienen otros beneficios al mismo tiempo:
● Puesto que las rutinas no son parte del programa ejecutable, el programa es más pequeño, requiere menos
espacio en disco y se carga más rápido en RAM
● Se tienen muchos programas que usan los mismos módulos de la biblioteca
● Si en uno de los módulos de la biblioteca se corrigió un error fijo, solo se necesita corregir esa biblioteca
inclinándose y cargándola en el sistema, lo que corrige automáticamente ese error en todo programa que haga
mención de esa DLL

ElMasri CAP 12 (GESTIÓN DE ARCHIVOS)

SISTEMAS DE ARCHIVOS
Los archivos constituyen una de las abstracciones más importantes con que cuenta un SO. Los programadores no
quieren pensar en unidades de discos o cualquier otro medio; más bien se quieren ocupar de los datos que están
procesando y los consideran como una recopilación. En
una computadora, esta recopilación se abstrae como un archivo. Los programas necesitan datos con los cuales
trabajar. Solemos guardar los datos en dispositivos de almacenamiento secundario porque la MP es demasiado
costosa. En la actualidad estos dispositivos donde almacenamos son discos magnéticos giratorios o de estado
sólido. Una de las funciones más importantes de los SO. es contar con la abstracción de una archivo en
almacenamiento secundario. El contenido de un archivo suele ser significativo sólo para los programas de
aplicación. Con esto queremos decir que en general el SO. no está consciente de la estructura interna de los
archivos. Hay unas cuantas excepciones, como los programas ejecutables (binarios) que pueden ejecutar el SO. y
los módulos objeto que se usan para hacer estos archivos. Tales archivos tienen estructuras definidas por el SO.
mismo. Estas estructuras son conocidas por todas las utilidades del ligador o cargador que se usa para hacer los
archivos ejecutables y los compiladores y ensambladores utilizados para producir los módulos objetos a partir del
programa fuente.
INTRODUCCIÓN
Los sistemas de archivos suelen tener diseños por capas, donde cada capa proporciona servicios a la capa que está
arriba de ella. Todo SO. cuenta con una partición única de las
funciones por medio de estas capas. Respecto a los sistemas de archivos, hay dos cosas que son verdaderas; la
capa superior API es una abstracción del concepto de archivos y la capa inferior interactuar directamente con el
hardware

DIRECTORIOS
Para que un programa pueda usar un archivo, primero debe encontrarlo. El SO. requiere contar con algún tipo de
índice de los archivos que el programa puede buscar. Estos índices se denominan directorios. ( también llamados
folder o carpetas ) resulta evidente que estos directorios deben almacenar el nombre del archivo, pero también
otros datos sobre el mismo. Esta otra info sobre el archivo que no forma parte de los datos del mismo se denomina
metadatos del archivo.
 ESTRUCTURA LÓGICA
Hay muchas estructuras lógicas diferentes que pueden usarse a fin de almacenar una estructura de directorio para
un sistema de archivos. Como por ejemplo:
● De un solo nivel : La forma de organizar lógicamente el directorio en un disco depende en cierta medida del
tamaño de este último. Normalmente había un solo directorio para todo el disco

● Estructura de árbol : A medida que el tiempo fue avanzando las unidades de disco cuentan con capacidades de
miles de millones de bytes ( GB ). Es normal que un disco asi contenga miles de archivos. Un solo directorio no
podría funcionar en tales unidades de disco. Así, un desarrollo clave en la organización de la estructura lógica de
los directorios de discos fue permitir directorios múltiples. El truco era permitir que los directorios se refiere a otros,
además de referirse a archivos. Con esta organización jerárquica de directorio es posible dividir los archivos en
varias categorías. Pero un efecto lateral a esta organización es que puede haber muchos archivos con el mismo
nombre con solo mantenerlos en directorios por separado, sin embargo, por esta característica los nombre de
archivos no pueden especificarse de manera única solo por el nombre, para hacer referencia sin ambigüedad a un
archivo es necesario proporcionar la ruta completa de los directorios que llevan a ese archivo, suele ser común
separar los nombres de los subdirectorios por medio de “/”.

● Directorios de gráfica acíclica : Con un solo directorio estructurado como árbol a menudo estamos en un dilema
respecto a cómo clasificar algún archivo. Una solución usada es permitir que los directorios formen gráficas acíclicas
dirigidas (DAG). La forma de lograr esto es usar un tipo especial de entrada del directorio denominada alias. Un
alias es una entrada que no apunta directamente a un archivo, sino a otra entrada del directorio. Sin embargo,
desplazarse desde una estructura de árbol hasta una DAG introduce algunos problemas que deben considerarse.
Uno es cuando un programa trata de sumar todo el espacio en todos los archivos del sistema, si no se consideran
los alias, el programa podría salir con un total erróneo si a algunos archivos se tiene acceso más de una vez. Otro
gran problema es como el sistema debe decidir
que un archivo puede realmente ser eliminado. Para resolver esta cuestión hay dos mecanismos que pueden
aplicarse. El primero consiste en distinguir la referencia primaria a un archivo y cualquier alias para un archivo. El
SO. también incluye un conteo de referencia en la entrada del directorio primario. Cuando se agrega un alias para
un archivo, el conteo de referencia se decrementa, y si el conteo se hace 0 es posible borrar el archivo. La segunda
técnica consiste en convertir a todos los alias en referencias simbólicas incluyendo cualquier referencia de ruta.

ESTRUCTURA FÍSICA
En sistemas antiguos se prestaba mucha atención a la velocidad para buscar directorios. Como resultado, algunas
técnicas usadas como el hashing (picando) para acelerar las búsquedas en directorios. La gran parte de los SO.
modernos no se preocupan por estas cuestiones, y los directorios no están ordenados en ningún orden particular.
Por lo tanto la búsqueda es simplemente secuencial.
OPERACIONES EN DIRECTORIOS
El SO. debe atender varias operaciones en diferentes directorios. Podría pensarse que estas deben ser sólo las
operaciones atendidas en los archivos, ya que los directorios son archivos. Pero con algunas diferencias, debido a
las consecuencias catastróficas de cometer un error en el sistema de archivos, la mayoría de los SO. no permiten
que un programa de aplicación escriba en un directorio. En lugar de eso, la aplicación debe llamar a rutinas
especiales para crear un nuevo archivo o un nuevo directorio o cualquier operación en directorios, en la siguiente
tabla se muestran el número de operaciones que un SO. podría atender en directorios.

La primera operación es cambiar el directorio de trabajo. Cada subdirectorio puede contener archivos con el mismo
nombre local que otros subdirectorios, de modo que para identificar sim
ambigüedad un archivo se requiere un nombre de ruta. Cuando se introducen nombres en una línea de comandos
para ejecutar un programa, no se desea tener que seguir tecleando nombres de ruta todo el tiempo, de modo que
el SO. usa el concepto de directorio de trabajo. La idea es que el usuario indique que un directorio específico sea el
directorio de trabajo actual . Una forma de determinarlo es registrarlo en el sistema. Los sistemas que atienden
estos registros suelen asignar al directorio de inicio del usuario como el directorio de trabajo actual en el momento
de ingresar al sistema. Una referencia al nombre de un archivo que no incluye ninguna info de ruta se denomina
nombre sin calificar. Cualquier comando que haga referencia a un nombre sin calificar implica que el archivo está
en el directorio de trabajo actual. Así como se muestra en la figura, si el directorio W fuera el DTA, una referencia
al archivo S se asumiría como una referencia al archivo en ese directorio. Para hacer referencia al archivo S en el
subdirectorio T del directorio W es probable que el programa especifique una ruta a ese directorio como parte del
nombre. Podría decir “/W/T/S” o “./T/S” la primer referencia es un nombre de ruta absoluto que empieza como si
su inicio fuera la raíz del árbol. La segunda referencia se denomina nombre de ruta relativo. El “.” Especifica el DTA.
METADATOS DE UN SISTEMA DE ARCHIVOS
Existe información en el sistema de archivos que no es sobre archivos específicos y por tanto no forma parte de las
entradas del directorio. Esta forma colectiva se denomina metadatos del sistema de archivos.
MÉTODOS DE ACCESO
Un SO. presenta un programa de aplicación con una API que representa la abstracción de un archivo. La API no
incluye matices sobre la forma en que la aplicación indica al SO. a qué porción del archivo quiere tener acceso.
Aplicaciones diferentes necesitan modos de acceso diferentes.
● Acceso secuencial : Inicialmente, las aplicaciones de computadora estaban diseñadas para procesar información
por lotes que están secuenciados por alguna información clave como un número de parte o un número de cliente.
Estas aplicaciones necesitan procesar los archivos en forma secuencial. Para procesamiento secuencial en
almacenamiento de disco, el SO. debía contar con alguna definición del tamaño del registro para cada archivo y
luego debía seguir la pista de la posición actual o apuntador de registro actual para cada aplicación que tuviera
abierto el archivo. El SO. incrementa el apuntador de registro actual cada vez que hay una lectura o escritura.

● Acceso aleatorio : En este modelo la aplicación indica al SO. que registró en el archivo necesita y el SO. se mueve
directamente a ese registro y tiene acceso a él para leer o escribir. Podemos observar que el acceso secuencial sigue
siendo posible en archivos de acceso aleatorio a un archivo, esto coloca el apuntador de registro en el registro
siguiente. Ahora la app puede emitir una operación read next y el SO. regresa el siguiente registro e incrementa el
apuntador de registro actual. Si la app ejecuta una operación leer el siguiente, obtiene el registro siguiente.

MÉTODOS DE ACCESO DE
NIVEL SUPERIOR
La gran mayoría de los SO. cuenta por lo menos con estos dos métodos de acceso. La mayor parte de los métodos
de acceso de nivel superior están incluidos en sistemas de bases de datos y algunas veces se proporcionan como
módulos de biblioteca como soporte para lenguajes de alto nivel. El hecho de que estos métodos de acceso los
proporcione el So significa que es necesario hacer menos trabajo de desarrollo para atender muchos lenguajes de
alto nivel en la medida en que la semántica de todas las API sea lo suficientemente parecido para que el método
de acceso del SO. los atienda.
● Acceso indexado : También llamado ISAM. La fig muestra un archivo de datos para una tienda al menudeo. Tiene
tres áreas: el área de datos primarios donde se guardan los
datos, el área de clave única o clave principal , que es un índice para el campo clave principal en el registro, y un
área de clave secundaria , que es un índice para una variable diferente. A medida que se agregan registros al
archivo, estos se escriben secuencialmente en el área de datos primarios. Sin embargo, para cada archivo escrito
en el área de datos primarios , en el área de clave principal se escribe un registro adicional y en el área de clave
secundaria se escribe otro registro.

● Acceso HASH : Es otro método de acceso de nivel superior que a veces tienen los SO. Puede aplicarse la técnica
hash a un campo clave para crear un valor clave aleatorio para tener acceso a un archivo de acceso aleatorio cuando
no se usan todos los valores clave. Pero el hecho de generar claves hash probablemente crea números de registro
que chocan para diferentes valores de la clave fuente, de modo que debe contarse con un mecanismo para resolver
estas colisiones.

ACCESO EN BRUTO
Para algunas apps, los servicios proporcionados por el sistema de archivos pueden ser contraproducentes. Esto
puede ocurrir cuando una app tiene altos requerimientos de desempeño y los desarrolladores de la app conocen
muy bien los patrones de acceso a los archivos que esta utiliza. El SO. algunas veces cuenta con un método de
acceso en bruto . en este caso el SO. no suministra ninguna estructura de archivos, sino que reserva un área del
disco donde las apps pueden proporcionar su propia estructura. Algunos ej: almacén de paginación del SO. en sí y
sistemas de bases de datos.
RASTREO DEL ESPACIO LIBRE
El SO. almacena archivos y directorios en bloques del disco. Para hacerlo, debe saber cuáles bloques aún no se han
usado. Hay dos formas para seguir la pista de ese espacio libre, Listas ligadas y Mapas de bits. Inicialmente los
sistemas de archivos seguían la pista del trozo más pequeño de espacio al que era posible tener acceso en una
unidad de disco: un sector. A medida que el disco aumentaba también aumentaban los apuntadores a los sectores
en el disco. La simple asignación de dos vectores juntos podía duplicar el alcance del apuntador. El proceso era
ampliado, y en algunos casos los sistemas de archivos asignaban hasta 64 sectores. La estructura se denomina
Bloque o algunas veces clúster.
RASTREO DEL ESPACIO LIBRE DE UNA LISTA LIGADA
Una forma de seguir la pista del espacio libre es colocar todos los bloques libres en una lista. El SO. debe seguir la
pista del primer bloque de la lista. Cada bloque libre contiene entonces un apuntador hacia el siguiente bloque
libre. La lista no está en ningún orden. Podríamos
ordenarla, pero cuando la aplicación libera un bloque es necesario poder colocarlo en la parte frontal de la lista, de
modo que tengamos que preocuparnos por cambiar cualquier otro sector en el disco para apuntar a este nuevo
bloque recientemente liberado. Tomamos el apuntador
hacia el bloque que se encuentra en la cabeza de la lista y lo colocamos en el nuevo bloque recientemente liberado.
Escribimos el sector del bloque que contiene el apuntador del siguiente bloque libre al disco y registramos el bloque
reciente liberado como el primer bloque en la lista. Otros problemas con este mecanismo es que para obtener la
dirección del siguiente bloque libre, el SO. debe leer el bloque libre porque contiene el apuntador hacia el siguiente.

LISTAS LIGADAS MEJORADAS

Lo que las listas ligadas requieren para trabajar mejor es contar con algún medio para que no tengamos que leer
cada sector antes de usarlo a fin de obtener el siguiente sector libre disponible. Hay varias maneras de hacer esto.
Dos formas incluyen agrupamiento e indexación. Con la indexación simplemente almacenamos varios apuntadores
de espacio libre en un solo bloque. Supongamos que un bloque es solo sector de 512 bytes, y que los apuntadores
son de 32 bits o 4 bytes; entonces un bloque puede almacenar 128 apuntadores. Así el bloque en la cabeza de la
cadena en lugar de apuntar al siguiente bloque libre, apunta a los 128 bloques siguientes. Este primer bloque se
llama bloque índice. Podemos usar todos los bloques a los que apunta el primer bloque índice y luego este bloque
en sí. El último bloque al que se apunta debe ser otro bloque índice en el disco, de modo que permanezca
actualizado, aunque tenga una ligera optimización sería capaz de sacar varios apuntador del bloque al mismo
tiempo y volver a escribir el bloque, manteniendo temporalmente estos apuntadores del bloque en la memoria
RAM o MP. Esto se denomina pre asignación. Se trata de una técnica que puede usarse con muchos de los
mecanismos de rastreo de espacio libre para minimizar la actualización de los datos en el disco.
Otro mecanismo para mejorar el rastreo de espacio libre de las listas vinculadas es el agrupamiento. En esta técnica,
el SO. aprovecha todas las oportunidades para determinar que dos o más bloques en la cadena son adyacentes.
Esto puede ocurrir si los bloques pueden asignarse a varios archivos en vez de a uno solo a la vez. En este caso, el
primer bloque en ese
El grupo contiene no solo un apuntador al siguiente bloque libre, sino también una indicación de cuántos de los
siguientes bloques en la lista son adyacentes entre sí. Esto permite que algunas veces el mecanismo de asignación
coloque bloques contiguos más fácilmente. Pero también, el
El primer bloque puede leerse y luego el resto de los bloques del grupo pueden manipularse sin necesidad de leer
nuevamente el disco.
 RASTREO DE ESPACIO
LIBRE DEL MAPA DE BITS
Otro enfoque para el rastreo de espacio libre es contar con un mapa de bits en el que cada bloque en el sistema de
archivos esté representado por un solo bit en una gran cadena. Si el primero se establece de una forma, el bloque
es libre; si se establece de otra manera, entonces se está usando. El hecho de que el bit “1” indique que el bloque
está libre o que el bloque está en uso depende sobre todo el conjunto de instrucciones de la computadora.
Recordemos que un problema con el mecanismo de las listas ligadas es la dificultad de asignar múltiples bloques
contiguos. Con un mapa de bits esto es mucho más fácil. Basta con encontrar una cadena de bits contiguos del
tamaño requerido. Es esta búsqueda por un bloque contiguo la que queremos efectuar en forma eficiente. El
conjunto de instrucciones de la computadora puede ser tal que resulta mucho más eficiente encontrar una cadena
de ceros que una de unos, o lo contrario.
Observemos que usar un mapa de bits para seguir la pista del espacio libre disponible ocupa más memoria que el
mecanismo de las listas ligadas. Debemos mantener en la memoria una porción del mapa de bits. Lo más probable
es que mantengamos todo un bloque porque es más fácil leer de esta manera, el costo de la memoria ya es muy
bajo actualmente y está declinando en forma continua, de modo que probablemente sea un factor importante
Necesitamos actualizar la copia en disco del mapa de bits a medida que asignamos bloques. Pero podemos seguir
usando la técnica de preasignación analizada con el mecanismo del rastreo de las listas ligadas. Es muy importante
actualizar el mapa antes de usar el espacio. En caso contrario, corremos el riesgo de tener un bloque asignado a
más de un archivo.
El mapa de bits no solo ocupa espacio en RAM, sino también en disco. El mapa de bits debe estar en un punto
especial del disco, esta ubicación no puede usarse para almacenamiento de datos. En el mecanismo de listas ligadas,
los apuntadores se almacenaban en los bloques libres en si.
Hay otro mecanismo más común para rastrear el espacio libre, pero es subproducto del mecanismo usado para
vincular juntos los bloques del archivo en la estructura FAT, de modo que lo analizaremos bajo ese encabezado.
 ASIGNACIÓN DE ARCHIVOS
Otra decisión fundamental es como los archivos en si deben organizarse en la unidad de disco. La abstracción que
el SO. presenta al usuario por medio de la API ( interfaz de programa de aplicación) determina parcialmente los
tipos de organización que puede usar el SO. Hay básicamente 3 mecanismos para asignar el espacio a un archivo.
Son los mecanismos contiguo,ligado e indexado. No es necesario que un SO. utilice solo uno, algunos atienden
múltiples tipos de asignación de archivos, solo necesita las API que atienden ambos tipos de solicitudes de
asignación y seguir la pista del espacio libre correctamente.
ASIGNACIÓN CONTIGUA
Esto significa que los bloques fijados a un archivo tienen números en una secuencia estrictamente creciente por 1.
Por ejemplo en la sig figura vemos que el archivo B ocupa de manera contigua los bloques 1000-1799. Estos bloques
no necesariamente empiezan en el límite de una pista. Simplemente son adyacentes en el esquema de numeración.
Este esquema de asignación de espacio de archivos presenta varias ventajas. Para encontrar los datos se requiere
poca información. Basta con la dirección del sector del primer bloque y la longitud del archivo en los bloques. El
método de asignación efectúa un acceso aleatorio a los datos de
manera muy simple. El mecanismo de la API varía del SO. y del tamaño del bloque que va a ser asignado.
Un problema de la asignación contigua es que una vez que se ha asignado un archivo, puede ser difícil hacerlo más
grande porque es probable que algún otro archivo sea asignado después del que queremos hacer más grande. Por
ejemplo en la fig vemos que no es posible hacer más grande el archivo A sin mover el archivo B. Para evitar este
problema, se tiende a asignar más almacenamiento para que el archivo que está siendo requerido por los datos.
De esa forma, el archivo puede crecer durante un tiempo antes de que sea necesario hacerlo más grande. Por
ejemplo, el programador podría saber que el sistema tiene 100 registros y suele agregar dos registros más al mes.
El archivo se asigna entonces con espacio para 130 registros y puede operar durante algo más de dos años sin
llenarse. Esto se denomina fragmentación del programador. Esto desperdicia mucho almacenamiento. Si no hay
suficiente espacio para la nueva copia, es necesario descargar el archivo a un dispositivo de almacenamiento
terciario, borrar el archivo anterior, mover otros archivos para hacer suficiente espacio contiguo para el nuevo
archivo, asignar el nuevo archivo y cargar los datos.
Lo tedioso de este mecanismo condujo a una variante del mecanismo de asignación de espacio: el uso de
extensiones. En este esquema un archivo no está limitado a una asignación contigua única. La asignación inicial es
un bloque contiguo, pero si está lleno, en lugar de hacer una nueva copia se efectúa la asignación secundaria, no
necesariamente contigua al asignación inicial.
Hay varias instancias de desperdicio en el esquema de asignación contigua. La primera es provocada por el hecho
de que la porción más pequeña del espacio al que podemos tener acceso es un sector. Por lo general arreglamos el
problema al rastrear la asignación en bloques en lugar de en sectores. Así, podríamos asignar los bloques de cuatro
sectores, pero en la mayor parte de los casos no es necesaria toda esa asignación.Este espacio sin usar provocado
por la granularidad de la asignación se denomina fragmentación interna.
Otro problema de mayor consecuencia es la fragmentación externa. El problema surge cuando estamos a punto
de llenar el disco. A medida que vamos asignando archivos contiguos, tendemos a cortar el espacio libre porque
seguimos sacando un espacio libre del espacio libre más grande. Los huecos quedan demasiado pequeños para la
siguiente asignación. La solución a
este problema es la desfragmentación. La idea básica es mover algunos archivos hacia huecos donde quepan
dejando huecos más grandes para los archivos que queremos asignar.
La tercera clase de fragmentación es la fragmentación del programador que analizamos donde el programador
asigna más espacio a un archivo del que realmente se necesita, surge debido a la dificultad de hacer más grande un
archivo contiguo por lo que es necesario mencionarlo.
ASIGNACIÓN VINCULADA
Este mecanismo es como una estructura de lista ligada al MP, pero acá los elementos vinculados son siempre del
mismo tamaño: un bloque de disco. Cada bloque contiene la dirección del sector de inicio del siguiente bloque en
el archivo. Un inconveniente de este mecanismo es que en este vínculo se desperdicia una parte de cada bloque. Si
los bloques son mayores que un sector, la capacidad disponible resulta aún menor.
Otro inconveniente del mecanismo de asignación por lista ligada es que algunas veces es difícil efectuar métodos
de acceso aleatorio en tales archivos, pero no imposible.
El lado bueno es que con archivos vinculados no hay fragmentación del programador, no hay presión para
sobreasignar el espacio inicial del archivo.
El problema con los archivos vinculados es que a medida que crece el archivo, el bloque “siguiente disponible”
puede estar en cualquier parte del disco. Como resultado, la lista ligada tiende a rebotar de un lado a otro en el
disco, dependiendo de cuál bloque estaba disponible cuando fue alargado el archivo. El procesamiento de tal
archivo con un programa que está haciendo mucha E/S y muy poco procesamiento puede ser muy costoso. El hecho
de volver a agrupar los archivos de modo que los bloques asignados a cada uno estén en orden y sean contiguos se
denomina fragmentación. Esto puede acelerar significativamente el procesamiento de los archivos.
Muchos SO. tienen ambos tipos (asignación contigua y vinculada) y el resultado es que tienen tanto el problema de
fragmentación externa como el de cadena aleatoria. En tales sistemas, la desfragmentación puede ayudar con estos
problemas.

ASIGNACIÓN INDEXADA
Así como hay un método indexado para seguir la pista del espacio libre, hay un mecanismo semejante para seguir
la pista de la estructura de un archivo. La estructura de archivo indexada es algo así como una lista vinculada excepto
que separamos un bloque índice para mantener los apuntadores, en lugar de colocar los apuntadores en cada
bloque de datos. Así como el mecanismo de rastreo de espacio libre, en la implementación más simple estamos
limitados a un bloque índice único. Esta restricción limita el tamaño del archivo, puesto que los bloques son de
tamaño fijo y en consecuencia el índice solo puede mantener apuntadores hacia un número máximo de bloques.
Hay dos formas en que es posible expandir el mecanismo para eliminar este límite: podemos usar múltiples niveles
de índices, en forma semejante a como se hizo con las tablas de pagina de RAM o podemos vincular los bloques de
índices mismos en una lista.
● Índices multinivel: con índices multinivel de nuevo usaremos un bloque para contener apuntadores en forma
semejante como se hizo con la estructura de índice único. Pero en este caso el primer bloque índice no contiene
apuntadores a un bloque de datos. En lugar de ello, contiene apuntadores a bloques de índice de segundo nivel.
Con una estructura de índices de dos capas, estos bloques índices contienen apuntadores hacia bloques de datos.
Si un bloque índice contiene 100 apuntadores, cuando se introduce una estructura de dos capas, lo anterior se
multiplica por 100. Entonces es posible direccionar un archivo que contiene 10 000 bloques. Si esto no es suficiente
podríamos introducir otra capa de índices, multiplicando cada vez el espacio original por 100. El siguiente nivel sería
1 millón. De bloques . Observemos que no necesariamente se requiere leer todo el conjunto de bloques de índices
en la memoria cuando el archivo se abre por primera vez. Podemos esperar hasta que la aplicación intente tener
acceso a la porción del archivo cubierta por un índice para leerlo. Esto es especialmente útil
para archivos muy grandes abiertos y leídos brevemente: por ejemplo para buscar una palabra en un diccionario.

● Listas ligadas de bloques indexados: Así como con las listas ligadas de espacio libre, podemos simplemente ligar
bloques indexados entre sí en una cadena. Cada bloque indexado contiene un apuntador menos hacia bloques de
datos porque necesitamos uno para tener acceso al siguiente bloque índice, pero es poco probable que esto sea un
factor importante para la mayor parte de los bloques y tamaños del disco. Si se está teniendo acceso aleatorio a un
archivo, este mecanismo requiere seguir la cadena ligada una vez que se abre el archivo y leer los bloques índice
en la MP. Por supuesto, podemos postergar la lectura de todos los
bloques hasta que sea necesario. Si se está teniendo acceso al archivo secuencialmente, es posible leer cada bloque
índice cuando estamos próximos al último apuntador en el bloque previo.
 CAP 14 (ELMASRI)
Planificación del Disco y Gestión de Entrada/Salida

La capa más baja de cualquier sistema de archivos es una colección de controladores de dispositivos y
manipuladores de interrupciones.

Características del Dispositivo

Hay algunas categorías de entrada/salida que, de manera amplia, las dividen en grupos que los SO. tratan
de manera diferente:

Acceso Aleatorio y Acceso Secuencial

En una época se usaban cintas magnéticas para almacenamiento secundario. Pero las cintas tienen la
inconveniente característica de que en ellas no es posible leer de manera aleatoria. Para obtener cualquier
tipo de datos en la cinta es necesario pasar por todos los datos entre el sitio en que se encuentra la cabeza
y el sitio a donde se debe llegar. Por fortuna, las unidades de disco no tienen esta característica.
Clases de Dispositivos

La mayor parte de los SO. dividen de manera amplia los dispositivos en tres clases: de bloque, de
caracteres y de red. Cada una de esas categorías tiene características sustancialmente diferentes y puede
abstraerse en una forma significativa.

Dispositivos de Bloque

Un dispositivo de bloque se lee o escribe uno a la vez. Incluyen, por ejemplo, todas las clases de unidades
de disco y de cinta.

Estos dispositivos a menudo tienen acceso aleatorio directamente a cualquier bloque en el dispositivo; es
decir, en el bloque es posible leer o escribir en cualquier orden. Los sistemas de archivos suelen residir en
dispositivos de bloque y son el mecanismo normal para tener acceso a estos dispositivos.
Cuando algún software requiere acceso a estos dispositivos directamente en lugar de hacerlo mediante
el empleo del sistema de archivos se conoce como E/S en bruto.

Dispositivos de Caracteres

Los dispositivos de caracteres transfieren datos a razón de un solo byte a la vez. Incluyen impresoras,
teclados, ratones, etc. Atienden la mayor parte de tipos de operaciones básicas como los archivos en
modo de bloques: apertura, cierre, lectura y escritura.

Para efectuar una operación que no se ajusta a la semántica del modelo del sistema de archivos, un
programa puede usar la llamada al sistema ioctl.

Dispositivos de Red

Los dispositivos de red no se ajustan en absoluto a la semántica tradicional de las operaciones con
archivos. El problema es que las aplicaciones que están esperando datos de entrada desde una red nunca
saben cuándo estarán disponibles los datos, o si es que lo estarán en algún momento. Es por esto que los
dispositivos de red cuentan con un conjunto de interfaces, completamente diferentes de los dispositivos
de bloques y de caracteres, con sus operaciones de lectura y escritura.

Tecnología de E/S

Un enfoque alterno al sistema de interrupciones que suele usarse a menudo en sistemas más pequeños
es el polling (sondeo). En este sistema, el control del
SO. se escribe en un solo bucle largo donde el SO. verifica el estado de cada dispositivo a la vez para ver
si requiere atención.

Técnicas Generales Usadas en Sistemas de E/S

Tecnología de E/S

● Buffers.
● Cachés.
● Operaciones en bloque.

Almacenamiento en Búfer

Un búfer es una porción de la memoria donde se almacena un registro que se usará en una operación de
E/S.

· Doble almacenamiento en búfer: Se asignan dos búferes para el proceso. Primero llenamos un búfer y
luego iniciamos la
operación para escribir en el dispositivo de salida. A medida que empezamos a escribir, comenzamos a
usar el segundo búfer para los datos de entrada. Para el momento en que el segundo búfer está lleno, la
escritura del primero debe estar terminada y entonces podemos empezar a escribir en el
segundo mientras comenzamos a llenar nuevamente el
primero.

Otra razón para usar los búferes podría ser que estamos tratando con dos dispositivos que son de acceso
a bloques, aunque el tamaño de bloque de los dispositivos sea distinto.

Almacenamiento en Caché

Se usa tanto en hardware como software. Su propósito es hacer parecer que una memoria más grande,
más lenta pero más barata se desempeña a la misma velocidad que una memoria más pequeña, más
rápida y más costosa. Las memorias caché funcionan porque los procesos en realidad los procesos no
tienen acceso aleatorio a la memoria. En lugar de ello, operan según el principio de ubicación de
referencia, el cual establece que es más probable hacer referencia a direcciones en la memoria que estén
más próximas a las que ya se ha hecho referencia que hacerlo a direcciones que no lo estén.

Uso de Bloques de Registros Pequeños

Consiste en empacar varios registros lógicos en un bloque físico para escribir en un dispositivo.

Organización física de discos (Pág 161 del PDF)

La organización física de un disco se llama Geometría. Los discos están divididos en pistas de la 0 a la
noche y cada una de esas pistas está dividida en dos sectores. La pista más interna tiene la misma cantidad
de sectores que la más externa. Los sectores van de 0 a s. Un disco tiene dos caras. La cantidad de cabezas,
pistas y sectores es a lo que se denomina Geometría de disco.

Los sectores son la unidad de datos más pequeña que una unidad de discos puede transferir.

La técnica de grabación por zonas de bits divide las pistas del disco en zonas de pistas de tamaño
semejante y cambian la sincronización para las pistas en cada zona.

Velocidades: Búsqueda, Transferencia y almacenamiento de búferes

El tiempo de búsqueda o tiempo de posicionamiento es el tiempo que requiere la unidad para mover el
montaje de la cabeza de una pista (o cilindro) a otra.

Organización Lógica del Disco

Particiones

Consiste en dividir una unidad de disco única en múltiples partes y que cada una sea tratada como una
unidad por separado.

Bloque de Arranque

La información sobre la partición de un disco duro se almacena en una parte del primer sector físico del
disco, sin importar cómo se establece la partición. Este sector se denomina sector de arranque o bloque
de arranque del disco y contiene la tabla de particiones. Además, contiene un programa corto que busca
la tabla de particiones, verifica cuál partición es la partición activa en ese momento y lee el primer sector
de esa partición. El bloque de arranque de esa partición contiene otro programa pequeño que lee la
primera parte del SO almacenado en esa partición y empieza a ejecutarla. El resto del programa de
arranque lee partes del núcleo y monta la raíz de la estructura de directorio que se encuentra en esa
partición.
Detección y Corrección de Errores
Los códigos de detección de errores son técnicas que calculan un número pequeño que es una función
del contenido del bloque de datos. El cálculo se realiza cuando los datos se escriben en el disco y el valor
calculado se escribe junto con los datos. Cuando los datos se leen de regreso en el disco, la función se
calcula de nuevo y se compara con el valor almacenado durante la operación de escritura. Si estos valores
no coinciden, se ha cometido un error, ya sea durante la escritura o la lectura.

Notas

Tiempo de disco: Tiempo de recuperación de los datos dependiendo de la posición donde la cabeza los
haya almacenado.

CAP 3 ELMASRI (CP/M)

Sistema Operativo CP/M (Monoproceso)
Fue uno de los primeros sistemas operativos de la computadora personal (PC), estos sistemas eran de proceso único
con funcionalidad limitada. Los sistemas de esta época eran limitados – solo ejecutaban una aplicación por usuario
a la vez –. La gestión del proceso inicialmente estaba limitada a cargar y arrancar un programa de aplicación
particular, más tarde con el CP/M se añadió una función de impresión de fondo, este montaje fue el inicio del
concepto de multiprocesamiento que tienen los SO. más modernos. La gestión de memoria en el SO. estaba limitada
a cual parte de la memoria usar para el SO, el vector de interrupción, el programa de usuario, los datos del
programa, etc. Debido a que la memoria era bastante limitada los programas grandes no cabían completamente
en memoria o la cantidad de datos a manipular era limitada. Era necesario que el programador dividiera esos
programas en secciones y sustituye una sección en la memoria por otra según fuera necesario. Esta técnica de
gestión de memoria se denomina superposiciones ( overlays ).
MONITORES Y EL CP/M
En este análisis vamos a ver sobre las razones por las cuales surgió la necesidad de un sistema operativo para una
PC. Los predecesores de estos SO. se denominan monitores (Monitor es un módulo de software que es precursor
de un SO.) , y tienen capacidades limitadas. No había ningún parámetro para los monitores – cada fabricante de los
primeros sistemas de PC escribía su propio programa de monitores, que tenía comandos y convenciones únicos –
Esta variedad significaba que los primeros programas de aplicación debían volver a escribirse para cada monitor.
INTRODUCCIÓN A LOS MONITORES: LOS PREDECESORES DE LOS SO SIMPLES.
En esa época muchas empresas vendían Kits de PC para armarla a su gusto, en ese tiempo no había ningún SO. En
lugar de ello, había un pequeño programa monitor casi siempre almacenado en la ROM que permite que una
aplicación realizará tareas simples como:
- Emitir un carácter a un dispositivo como una pantalla de video o teletipo - Obtener un carácter desde el teclado
- Guardar el contenido de toda o parte de la memoria en una cinta de casete o en un disco
- Imprimir un carácter en la impresora
- Restituir la memoria desde una imagen guardada en cinta o disco El monitor solo efectuaba estas tareas básicas.

Un programa de aplicación podía imprimir un carácter por ejemplo “1” en la consola al llamar al monitor usando
los pasos sig:
1) Colocar el carácter en un registro específico según especifique el monitor ej: registro E
2) Seleccionar la función del monitor “imprimir un carácter” y el valor de la función se coloca en un registro C
3) Se ejecuta una llamada al monitor a través del interruptor 5 la cual llamaba a la función almacenada en el registro
C usando el carácter en el registro E
4) Una vez que el monitor emite el carácter devuelve un código de estado en un registro A, lo cual indica OK o No
OK. La aplicación consideraba el estado del registro A.
¿PORQUE CP/M? ¿CUAL ERA LA CRISIS DE SOFTWARE?
Debido a todas las compañías que elaboran kits de computadoras para armar y cada una de estas debía
proporcionar el software para un pequeño monitor. Estos monitores no eran grandes en términos de requerimiento
de memoria. Por lo general un monitor solo contaba con alrededor de una docena de funciones, aunque estas
requerían tiempo y experiencia para su desarrollo, depuración y construcción. Cada fabricante implementa
cualesquiera funciones que se imaginaba que los programadores querían. Por ejemplo al usar parámetros a
funciones se podía usar registros en un monitor. En otro monitor los parámetros podían ser pasados en ubicaciones
de la memoria. Podía usar alguna combinación de ambos métodos en un tercer monitor. Esto originó un problema
para la programación de aplicaciones. ¿Cómo era posible escribir un programa portátil? Es decir que pudiera ser
ejecutado en diferentes PC para distintos fabricantes de PC. Esta situación condujo al desarrollo del CP/M ( Control
Program/Monitor ) Creado para microcomputadoras con base en los circuitos CPU Intel 8080/8085, fue el producto
de Gary Kindall de Digital Research.
COMPONENTES DEL CP/M
Este sistema operativo fue escrito para permitir que los desarrolladores, usuarios y fabricantes de software tuvieran
interfaz única, simple y estándar. Los dispositivos de hardware podían aislarse del sistema operativo por medio de
una capa de software: el BIOS ( Basic Input/Output System ) (Sistema básico de entrada/salida ) Este BIOS seria
semejante a un monitor pero con funciones e interfaces específicas estándar. Cada fabricante podía adaptar el BIOS
al conjunto de dispositivos incluido en su PC. Transportar el CP/M a un nuevo sistema consistía en escribir las rutinas
del BIOS para el hardware.
El corazón del SO. se denomina BDOS ( Basic Disk Operating System ) (Sistema operativo básico de disco ) Es lo que
actualmente se llama Núcleo. Debía ser independiente del hardware y debía llamar los servicios más primitivos en
el BIOS. El software del BDOS debía ser el mismo para cualquier sistema en el que habría de ejecutarse en CP/M.
Este tipo de interfaz estandarizada que proporciona funciones generales del sistema pero oculta los enredados
detalles del hardware se denomina Abstracción.
La última parte del SO. fue una interfaz del usuario para el SO, denominada CCP ( Console Command Processor )
(Procesador de los comandos de la consola ) Los otros programas que ejecutaba CP/M eran programas en el disco.
Estos 3 componentes eran pequeños en tamaño de memoria y todo el CP/M cabía en unos cuantos sectores de un
disquete para arrancar la computadora.
En resumen los componentes del primer SO. CP/M eran los siguientes:
BIOS ( Sistema Básico de Entrada/Salida )
BDOS ( Sistema Operativo Básico de Disco )
CCP ( Procesador de los Comandos de la Consola )
La existencia de una norma de facto en el CP/M alertó a muchos programadores que desarrollan programas de
aplicación para PC construidos por un montón de fabricantes. El software admitía muchos dispositivos E/S – como
disquetes, discos duros y terminales de video – No era necesario que las aplicaciones fuesen a la medida para cada
tipo de computadora. Para los programadores había editores de texto, compiladores para muchos lenguajes de
programación y depuradores.
CARACTERÍSTICAS DE UN SISTEMA DE PC SIMPLE
Los primeros sistemas de PC contaban con una tarjeta principal de circuitos denominada Tarjeta madre o Placa
madre, esta tenía una pastilla microprocesadores ( CPU ), algo de memoria RAM, una memoria ROM que contenía
al BIOS y varios circuitos integrados (CI) que unían entre sí estas pastillas. La tarjeta madre contaba con algunas
ranuras para insertar tarjetas de circuitos de expansión adicionales denominadas tarjetas.
En la sig figura se muestra un esquema simple de los componentes de hardware típicos en uno de los primeros
sistemas de PC. Algunas de las características de este tipo de sistema que tenía efectos fundamentales en el diseño
del sistema operativo son los siguientes:
1 ) El tamaño de la MP era demasiado limitado. Se decidió que el diseño del SO. cargará un solo programa de
aplicación a la vez en memoria. Debido que el SO. CP/M era demasiado pequeño, estaría ubicado
permanentemente en memoria esto incluye el cargador, el manipulador de interrupciones y los controladores de
dispositivos. Si un programa de aplicación no cabía en la memoria restante, era necesario escribir la aplicación de
modo que cupiera en la memoria de manera individual. Cuando se necesitaba una nueva sección, podía usarse la
técnica de gestión de memoria Superposición ( Overlays ) para sustituir la sección antigua con la nueva
2) El formato de disco se estandarizó. En estos primeros sistemas se fijaron el tamaño y el formato del bloque del
disco tanto para disquetes como para discos duros. Esto condujo a un diseño estandarizado del sistema de archivos
que estaba basado en el formato estándar de disco.
3) La manipulación de interrupciones era principalmente para dispositivos de E/S . Como solo era posible ejecutar
una aplicación a la vez, no era necesario intercambiar entre aplicaciones. En el SO. no se requería planificación de
la CPU. Los tipos principales de interrupción era para manipular dispositivos de E/S.

GESTIÓN DE
ENTRADA/SALIDA
La manipulación de E/S era limitada en los primeros SO. pues los dispositivos eran limitados en comparación a dia
de hoy. La mayor parte de los programas de aplicación para las primeras PC requerían los siguientes servicios E/S:
1) Leer caracteres desde el teclado
2) Escribir caracteres en la pantalla de video
3) Imprimir un carácter en la impresora
4) Usar el sistema de archivos en el disco para crear un nuevo archivo, leer y escribir en el archivo y cerrar un
archivo.
Un problema para muchos programadores era la falta de flexibilidad en la manipulación de entrada desde el teclado
y la salida a través de la pantalla. Debido a que había muchos fabricantes de hardware para computadoras que
trabajan en forma diferente, el SO. intentó proporcionar una manera estándar para tratar con estos problemas.
Otro problema era el desempeño: la ejecución de algunos comandos de E/S por medio de llamadas directas al BIOS
o al hardware era mucho más rápido y más flexible que si llama al comando idóneo del SO, esto condujo a la
portabilidad – Si los diseñadores de la app solo usaban llamadas al SO. para ejecutar operaciones de E/S – contra
la flexibilidad y mayor velocidad que eran posibles si los diseñadores de la app usaban llamadas directas al BIOS y
funciones de hardware.
Entrada desde el teclado: portabilidad contra flexibilidad
Como los teclados podían ser de diferentes letras, conectado en serie o paralelo y los caracteres podían
representarse mediante siete u ocho bits ¿ como se podría estandarizar eso? El BIOS estaba personalizado para
cada tipo de teclado, Luego la BDOS usaría las funciones del BIOS para crear una interfaz con el SO. más simple para
el teclado. Estas funciones – llamadas internas al SO. – eran: 1) leer el carácter del teclado y 2) comprobar si se
había oprimido una
tecla. Pero algunas aplicaciones requieren una flexibilidad adicional , por ejemplo un procesador de palabras
necesitaba usar las teclas “modificadas” como controles para guardar un archivo. Estos golpes o combinaciones de
teclado originaron un problema porque no eran reconocidos por el BIOS y por tanto no podían pasar a una app.
Pero algunas combinaciones también podían ser interpretadas por el BIOS o por el BDOS y provocar alguna acción
del SO. como un rearranque. En este caso, evidentemente la combinación de teclas no pasaría a la app.
Las aplicaciones que requerían flexibilidad para manipular el teclado de modo que las combinaciones tuvieran
sentido para la app esquivaban el BDOS. Era trivial lograr lo anterior. Podría significar leer las teclas desde el BIOS
en lugar de leer desde el BDOS e incluso leer teclas desde el hardware de teclado ( en realidad la pastilla de interfaz
del teclado ) . Resultaba fácil evitar el SO. (BDOS) porque en los primeros sistemas no había protección de la
memoria. Cualquier app podía manejar cualquier parte de la memoria. Era tan fácil usar llamadas al BIOS como
llamadas al BDOS y la llamada al BDOS podía no hacer lo que era necesario por la app. El problema con este enfoque
es que los programas dejarían de ser portátiles, especialmente si la app se dirigía directamente al hardware.
Salida desde el monitor de video: movilidad contra funcionalidad y desempeño
La pantalla planteaba problemas más complicados. Primero las funciones disponibles a través de las funciones de
interfaz del BDOS y el BIOS eran más limitadas. Había muchas características de sistemas de video que no era posible
usar directamente por las llamadas simples al sistema del SO. Por ejemplo era imposible utilizar color, escribir
páginas múltiples de memoria de video para simular movimientos al presentar rápidamente una serie de imágenes
o mover el cursor al tiempo que se escribía en pantalla.
Segundo, la salida desde la pantalla usando BDOS era muy lenta. Muchas app podían escribir caracteres
directamente en la memoria de la pantalla y tener acceso directamente al hardware del controlador de video. La
razón más importante para evitar el BDOS era mejorar el desempeño de la app.
Escribir directamente en la memoria de video proporcionaba no solo más funcionalidad sino que era mucho más
rápido que ir a través de una llamada al sistema del SO.
GESTIÓN DE DISCO Y EL SISTEMA DE ARCHIVOS
Debido a que muchas apps evitaban el teclado y las llamadas al SO. de video, en realidad que proporcionaba el SO?
Uno de los principales servicios que proporcionaba un SO. así era un sistema de archivos estándar y portátil.
Alrededor de 75 de llamadas al SO. estaban relacionadas con el archivo de disco.
El sistema de disco
En los primeros sistemas de PC había una norma para los dispositivos de hardware del disco para usar el sistema
de archivos. Este disquete tenía un orificio en el centro donde la unidad de disco lo ubicaría sobre un eje. El eje está
conectado al motor de una unidad de disco duro que haría girar el disquete a 360 rpm. El disco normal tenía 77
pistas numeradas desde la pista 0 hasta la pista 76. Las pistas eran círculos concéntricos. Una pista tenía 26 sectores
o bloques. Con el primer sector 1 y el último 26. Cada sector contiene 128 bytes de datos. Los disquetes tenían dos
lados. Con los dos lados numeras, como 0 y 1. Había un pequeño orificio denominado orificio índice.
Las pistas empiezan en 0 pero los sectores en 1 ( esto no es así en los discos modernos).
El sistema de disco comprendía la unidad de disco y el controlador de disco. La unidad de disco contenía y giraba
los medios del disco ( un disquete ) que tenía los datos almacenados. El controlador de disco solía estar integrado
en la tarjeta madre de la computadora o en una tarjeta de circuitos enchufada a la tarjeta madre. Las unidades de
disco pueden mover la cabeza del disco – que contiene detectores magnéticos de lectura y escritura – de pista a
pista. Para leer cualquier sector individual en una pista, la unidad debe esperar a que el sector gire bajo la cabeza
del disco.
Un controlador puede tomar comandos para leer o escribir un sector o múltiples sectores en una pista dada en un
lado determinado del disco. Cada sector de cada pista contiene el número de la pista. El controlador debe
reorientarse a sí mismo a fin de comenzar a buscar sectores en pistas empezando después de que el orificio índice
gira. Todas estas actividades son invisibles para el SO. y para el BIOS. Este software integrado en la ROM se
denomina firmware.
Un disco estándar para las primeras PC contenía: 77 pistas * 26 sectores por pista * 128 bytes por sector * 2 lados
= 512 512 bytes de datos ( 500 Kbytes)
El formateo de discos es el proceso de escribir información de control en el disco para dividir las pistas del disco en
sectores.
El sistema de archivos
El SO. contaba con un sistema de archivos integrado en la parte superior del BIOS para almacenar archivos del
usuario y del sistema. Una parte de los archivos del sistema que pueden almacenarse en un disco contiene el código
binario del SO. en sí. Además, cada disco tiene un directorio que almacena información acerca de todos los archivos
almacenados en el disco, sus tamaños, ubicación física ( sectores) donde están almacenados, etc. Los archivos
almacenados en disco pueden contener cualquiera de los sig tipos de datos:
o Datos producidos por la aplicación ( docs,hojas de cálculo,código fuente) o Ejecutables del programa de aplicación
( código bin )

o Información del directorio ( nombres de archivos, datos creados, ubicación ) o El ejecutable binario del SO. ( el
SO. ejecutable, usado para cargar o “ arrancar” del SO.)

Cada disco físico está dividido en 3 áreas para un sistema de archivos BIOS como se muestra en la fig
o Área reservada donde está colocado el SO. ejecutable ( también llamada área de arranque del disco )
o Área del directorio de archivos, contiene entradas con información sobre cada archivo almacenado en el disco
o Área de almacenamiento de datos para datos y archivos del programa, que ocupa el resto del disco y es la parte
más grande del disco.

El BIOS contiene una

tabla integrada que proporciona el tamaño de cada una de estas áreas, a continuación en detalle cada una de ellas…
Area de arranque del disco
Esta área tiene el binario del SO. para arrancar la PC. Esta área no es visible desde el sistema de archivos – no tiene
entrada ni nombre en el directorio – La imagen que se carga del BIOS , BDOS y CCP está escrita en esta área, sector
por sector, pista x pistera , empezando en la pista 0, sector 1. Estos no son parte de ningún archivo, simplemente
ocupan las primeras pistas del disco.
Cuando la computadora se enciende o reinicia, se ejecuta un pequeño programa en la ROM que copia la imagen
del ejecutable del SO. desde el disco hasta la memoria y luego empieza a ejecutar este programa – el SO. – Esto se
denomina arranque o carga del SO.
Área del directorio de archivos
El tamaño del área de directorio es fijo y se registra en una tabla en el BIOS. La disposición de una entrada del
directorio del disco se muestra en la sig figura y cada entrada en un directorio contiene lo sig:
o Un número de usuario: Es un número de grupo que va de 0 a 15, lo cual permite que usuarios múltiples o grupos
compartan un disco y reúnan sus archivos en un grupo. ( no hay subdirectorios ) - todos los archivos están en un
directorio – Los números de grupo dan la ilusión de contar con subdirectorios ( serán virtuales)
o Un nombre de archivo y un tipo de archivo. Pueden considerarse como artículos que consta de 1 a 8 caracteres
de nombre de archivo y de 0 a 3 caracteres de tipo de archivo, lo cual a menudo se denomina nombre de archivos
8.3
o Un controlador de extensión. Es una porción de un archivo controlada por una entrada de un directorio. Si un
archivo toma más bloques de los que pueden ser apuntados por una entrada del directorio, proporciona entradas
adicionales.
o El número de registros. Es en realidad el número de registros de 128 bytes usados en la extensión. Si la cuenta es
080x, esta extensión está llena y puede haber otra en el disco.
o Un mapa de asignación. Este es un grupo de números o apuntadores hacia los bloques de disco que contiene los
datos para el archivo. Hay 8 apuntadores de 16 bits cada uno. Cada valor apunta a un sector en el disco que contiene
parte del archivo. Si el archivo es pequeño, que contenga menos de 8 sectores, los apuntadores sin utilizar se
establecen a cero. Si el
El archivo es demasiado grande, la extensión adicional se asigna y se llena otra entrada del directorio.
Área de almacenamiento de datos
Esta área contiene los bloques de datos para los archivos. Para que el sistema tenga acceso a un archivo, el
programa de app del usuario debe proporcionar el nombre del archivo y el sistema de archivos debe buscar en el
directorio de disco para determinar si un archivo con ese nombre fue almacenado en el disco. Si se encuentra el
nombre del archivo, la entrada del directorio cuenta con la dirección de los sectores donde se almacenó el archivo,
de modo que es posible tener acceso a los datos del archivo.
Dato: en lugar de apuntar a un sector individual, los sectores están agrupados entre sí en bloques de asignación,
que son sectores consecutivos agrupados entre sí. El tamaño del disco determina el tamaño de estos bloques de
asignación.
Observaciones acerca de esta estructura de sistema de archivo así como sus limitaciones: o En el directorio no hay
fechas ni horas

o No hay ningún tamaño de entrada determinado, debe calcularse o Solo hay un directorio único, sin subdirectorios
o Un archivo debe almacenarse totalmente en disco
o Si el directorio está lleno, también el disco. ( el tamaño de directorio es fijo, por lo que en un disquete sólo pueden
almacenarse 64 archivos o menos )
Observaciones: una de las quejas mas importantes contra CP/M eran los nombres 8.3 de archivos. Las entradas del
directorio, donde están almacenados los nombres de los archivos, son de 32 bytes de longitud. Hubiera sido posible
asignarles fácilmente su longitud igual a 48 o 64 entradas de directorio, permitiendo 23.3 o 40.3 nombres. Lo más
importante del diseño era minimizar el espacio del disco ( y el espacio de memoria ) para cada entrada del
directorio.

GESTIÓN DE PROCESOS Y DE
LA MEMORIA
Creación y ejecución de un programa de aplicación
Al escribir un programa de app se escriben instrucciones en lenguaje máquina a un editor de texto, luego se compila
o ensambla o ambas, y por último se vincula junto con las rutinas de la
biblioteca usando un editor de enlace. El resultado es un archivo imagen de un programa listo para ser cargado en
la memoria y ser ejecutado. A la imagen del programa se le han asignado muchos nombres, por ejemplo programa
ejecutable o binario del programa, al cabo de unas cuentas vueltas de depuración, el programa está listo para
usarse.
Para que empiece a correr el programa debe cargarse en memoria su código binario ejecutable. Este proceso de
carga suele llevarse a cabo por el CCP. El CCP en sí es un programa de aplicación que cuenta con algunas funciones
integradas. El CCP lleva a cabo su trabajo haciendo llamadas al BDOS – jamás llama directamente al BIOS o al
hardware – Esto hace que el BDOS sea más transportable a un nuevo sistema de hardware. Cuando se introduce
un nombre al CCP, primero ve si se trata del nombre de un comando integrado, el CCP intenta encontrar un archivo
de programa ejecutable en el disco con ese nombre. Si existe, el contenido de ese archivo se carga en memoria y el
programa empieza a correr. Había un código especial en la cabecera del programa que podía identificar el archivo
como programa ejecutable. Alternativamente, los comandos que introducía el usuario podrá nombrar un archivo
de texto que fuese una cadena de comandos que el CCP debía leer y ejecutar uno por vez. Había subarchivos en el
CPM después de la extensión .sub que eran la segunda parte del nombre del archivo. Los archivos de comandos de
este tipo se denominan guiones ( script ) o por lotes ( batch)
En CP/M los programas de aplicación normales se cargaban en la RAM empezando en la dirección 0100 Hex. El
hecho de contar con una dirección fija para todos los programas facilita a los compiladores y enlaces a crear
ejecutables ya que la dirección inicial del programa se conoce de antemano.
Los programas requieren memoria adicional para datos estáticos – por ejemplo para datos predefinidos de tamaño
fijo como cadenas estáticas – Además se requiere una pila para datos dinámicos – por ejemplo para variables
temporales – Los datos estáticos se cargan en la memoria, a continuación de la carga del archivo con el programa
binario. Se reserva memoria adicional para otros datos después de los datos estadísticos. La sig fig ilustra el mapa
general de la memoria para las diversas partes de un programa en ejecución.
La pila está colocada en la ubicación superior en la memoria justo debajo del código del SO. La pila crece en la
memoria hacia dirección de memorias más bajas. Una vez completada la carga, el SO. llama a la primera instrucción
del programa como si estuviera llamando a una subrutina. El programa se ejecuta hasta que termina su trabajo, en
cuyo momento el control temporal simplemente regresa al programa CCP que lo cargó. El CCP puede seguir estando
en la memoria, pero si no es así, puede usar memoria disponible en el momento que lo requiera para memoria
reservada que contiene al SO. o partes de él.
El proceso se ejecuta desde el principio hasta el final. Si requiere E/S, la CPU permanece ociosa hasta que completa
la E/S requerida. Para programas grandes que no caben totalmente en memoria, el código del programa suele estar
dividido en varios segmentos que llegan por separado a la memoria. Cuando un segmento llama a una función cuyo
código no está en la memoria, se usa una técnica de superposición ( overlay ) de la memoria para llevar el segmento
de código nuevo en lugar de otro segmento de código que está actualmente en la memoria. La implementación de
la superposiciones se le dejaba al programa de aplicación, aunque solía tener algo de asistencia de las bibliotecas
de aplicación
 Procesamiento de
comandos por medio del CCP
El CCP es un programa bastante parecido a otros, quizá el CCP está mejor estructurado que otros programas, ya
que solo usa llamadas al sistema del SO. y nunca evita el SO. En otros SO, el componente semejante al CCP se
denomina Shell o intérprete de comandos. Un usuario puede invocar directamente a los comandos del CCP, al
escribir un comando del CCP o el nombre de un archivo con el ejecutable del programa. Otro nombre para este tipo
de intérprete de comandos es interfaz de línea de comandos, ya que cada comando se introduce en una línea de
la pantalla y se somete al intérprete de comandos cuando el usuario oprime la tecla. El CCP estaba enlazado para
su carga en la memoria alta exactamente bajo el BDOS. Una vez que terminaba la ejecución de un programa, podía
salir al regresar el control al BDOS, que podía comprobar si el CCP estaba intacto en la memoria. En caso afirmativo
el BDOS devolvía el control al CCP sin recargarlo.
Gestión de la memoria
Todos los programas se cargan en una dirección fija en la memoria. Los programas se dividen en dos partes:
1 ) El código ejecutable del programa
2 ) Datos fijos ( estáticos ) – Como valores constantes en el programa –.
El software que copia estas dos partes en la memoria desde el disco se denomina cargador y forma parte del
procesador de comandos del CCP. Un programa también necesita algo de espacio de pila para almacenar variables
temporales, pasar parámetros a subrutinas llamadas y regresar datos desde estas rutinas. La pila fue colocada en
la ubicación más alta en la memoria, debajo del SO. Esto para que la pila creciera hacia abajo en la memoria y no
chocará con los datos del programa.
Pero el CP/M no contaba con previsiones para detectar una colisión entre la pila y los datos fijos. Esto por lo regular
provocaba la caída del programa o producir resultados extraños porque la CPU no tenía registros para la gestión de
memoria para su protección. Estos problemas sucedían generalmente en CP/M.

Para prog escritos en lenguajes de alto nivel como pascal o C , hay gran cantidad de memoria que puede asignarse
y regresar dinámicamente denominada heap ( montículo ) Este era dejado de lado por el cargador, pero era
gestionado por las rutinas en bibliotecas de lenguajes de alto nivel en tiempo de ejecución. Y si había algún
programa que usará el heap podía ubicarse en la memoria entre los datos fijos y la pila.
Una cabecera del programa estaba ubicada en la memoria inmediatamente antes del código binario ejecutable. La
cabecera del programa contiene apuntadores a direcciones de la memoria donde estaban ubicados la pila y los
datos fijos. También contiene un apuntador a las cadenas pasadas como parámetros al programa cuando el usuario
escribe el comando y suministra argumentos al programa.
¿Por qué el SO. estaba localizado en la parte más arriba de la memoria y no en la memoria baja?
Porque no todos los sistemas CP/M tenían la misma cantidad de memoria. Algunas PC podían tener 32KB de
memoria, otras 48 o 64KB. Así el SO. se generaba ( configuraba) para ocupar las ubicación más elevadas en la
memoria dejando una dirección fija – siempre 100 hex – para cargar programas. Si el SO. se volvía más grande podía
empezar en una dirección más baja en la memoria, pero sin obligar a ningún programa a cambiar de dirección,
aunque el programa de un usuario podía tener menos memoria disponible para la ejecución. Lo anterior quiere
decir que cuando el SO. se actualiza a una nueva versión no era necesario volver a vincular todos los programas de
aplicación.
Superposiciones ( overlays )
El tamaño máximo de memoria en CP/M estaba restringido por la cantidad de memoria que podía manipular la
CPU. Inicialmente era de 64 KB, pero en algunas versiones posteriores de la CPU se permitía más memoria y algunos
PC tienen hardware añadido para proporcionar “bancos” de memoria que pudieran trazarse en espacios de la
memoria por control del programa.
¿Los programas manipulan grandes cantidades de datos, podían mantener algunos de ellos en el disco, en lugar de
en la memoria, trayendo solo lo necesario en un instante dado, pero que podía hacerse con los programas con
código binario grande? Estas partes o programas podían sobreponerse entre sí en las mismas ubicaciones en la
memoria y se llamaban superposiciones ( overlays ). Los programas que tenían grandes cantidades de código
podían dividirse en una parte principal y otras secciones del programa. La parte principal estaría en memoria y
aquellas secciones del programa que solo eran necesarias ocasionalmente podían llevarse a la memoria como
superposiciones que sustituyen a otras secciones. Los candidatos habituales para las superposiciones eran algunas
grandes rutinas computacionales o de manipulación de errores. La carga real de superposiciones se efectuaba por
medio de la biblioteca del lenguaje de programación en tiempo de ejecución, que usaba llamadas al sistema CP/M
para cargar una superposición. Un ejemplo de un programa que podía usar superposiciones es un ensamblador.

Procesos y
multitarea básica
Los usuarios requerían hacer algún trabajo en paralelo al que estaban haciendo. Por ejemplo imprimir un archivo
en un proceso de fondo a la vez que se editaba o se jugaba un juego en un proceso de primer plano. Este proceso
de impresión tardaba aprox 30 min o una hora y se desperdiciaba el recurso más valioso: el tiempo de la persona.
La solución del CP/M fue un proceso de impresión de fondo. En la parte más alta de la memoria se cargaba un
pequeño programa, exactamente debajo del SO. Este programa se iniciaba así mismo y luego regresaba el control
al CCP, permitiendo la ejecución de otro programa. Cuando un usuario desea imprimir en el fondo, el nombre del
archivo a imprimir era pasado al manipulador de impresión de fondo. Este podría imprimir un poco del archivo –
una línea o dos – una vez que tenía el control. El proceso de fondo por lo regular tenía el control en cualquier
instante en que un proceso de fondo hiciera una llamada al sistema o posiblemente al establecer un cronómetro y
provocar una interrupción del proceso de fondo.
La impresión de fondo aparentaba que la computadora hacía dos cosas a la vez, algo denominado multitarea. El
manipulador de impresión de fondo sólo permite imprimir en el fondo y nada más.

McIver CAP 14 (MS-DOS)

INTRODUCCIÓN
MS-DOS también conocido como DOS, fue desarrollado para su ejecución en computadoras de escritorio de usuario
único e independiente. MS-DOS era el SO. normal entregado con millones de estas máquinas.
Este SO. ejemplifica los primeros SO. porque administra trabajos en forma secuencial desde un usuario único. Sus
ventajas son: su operación fundamental y sus comandos de usuario directos MS-DOS fue escrito para una sola
familia de microprocesadores: los chips Intel 8088,8088, 80186 y 80286.
MS-DOS fue el primer SO. para una generación de microcomputadoras.
Este SO. fue el sucesor de CP/M. Se ejecutaba en las primeras PC, máquinas de 8 bits comercializadas por Apple y
Tandy. Pero cuando las primeras PC de 16 bits fueron desarrolladas requerían un SO. con más capacidad que CP/M.
IBM junto a Digital Research ofreció el nuevo SO. para las computadoras de 16 bits CP/M-86 y Softech su sistema
P. Mientras que Bill Gates y Paul Allen, descubrieron un SO. innovador denominado 86-DOS, diseñado por Seattle
Computer Products para ejecutar esa línea de productos de PC de 16 bits. Microsoft lo compró y lo denominó MS-
DOS (Microsoft Disk Operating System ) y lo puso a disposición para IBM.
IBM escogió MS-DOS y lo denominó PC-DOS y proclamó la norma para su línea de PC. Mientras MS-DOS se volvía
el SO. normal para PC.
Los programas escritos para su ejecución en versiones antiguas también eran compatibles en versiones más
actuales, también significaba que entre fabricantes diferentes, con los mismo comandos se obtenía la misma
respuesta del SO, sin importar quien había fabricado el hardware.
OBJETIVOS DE DISEÑO
Este SO. fue diseñado para atender a un usuario único en un entorno de proceso único. ( como se muestra en la fig
) Su soporte normal de E/S incluye, teclado,monitor,impresora y unidad de almacenamiento secundario. Sus
comandos de usuario están basados en palabras y frases en inglés y son indicativos de la acción a realizar. Estos
comandos son interpretados por el procesador de comandos.
El enfoque por capas es fundamental para el diseño de todo el sistema MS-DOS, que es “proteger” al usuario de no
tener que trabajar con los bits y bytes de la máquina desnuda que
integran la capa inferior. Cada capa está construida sobre la capa precedente empezando de abajo hacia arriba.
La capa inferior del MS-DOS es el BIOS ( Basic Input/Output System ). Esta capa del SO. se interconecta directamente
con los distintos dispositivos E/S. El BIOS contiene los controladores de dispositivos que controlan el flujo de datos
hacia y desde cada dispositivo excepto las unidades de disco. Recibe información del estado sobre el éxito o fracaso
de cada operación E/S y le pasa al procesador. BIOS se ocupa de las pequeñas diferencias entre unidades de E/S,
de modo que el usuario puede comprar cualquier impresora de cualquier fabricante sin tener que escribir un
controlador de dispositivo para ella.
La capa del medio, el núcleo DOS, contiene las rutinas necesarias para conectarse con las unidades de disco. Se lee
en la memoria en el momento de iniciar desde el archivo MSDOS.SYS que reside en el disco de arranque. El núcleo
del DOS es un programa registrado proporcionado por Microsoft Corporation que implementa MS-DOS. Al núcleo
tienen acceso los Programas de aplicación y el núcleo proporciona una colección de servicios independientes del
hardware, como administración de memoria y administración de archivos y registros. Estas se denominan funciones
del sistema. Como BIOS, el núcleo DOS compensa diferencias de un fabricante a otro, de modo que todas las
unidades de disco funcionan del mismo modo. El núcleo hace que la administración de archivos sea transparente
para el usuario, de modo que no es necesario recordar en qué pistas y sectores están almacenados sus archivos, y
que sectores del disco están dañados y deben evitarse. El núcleo hace este trabajo por el usuario; administra el
almacenamiento y la recuperación de archivos, asigna y libera dinámicamente el almacenamiento secundario según
sea necesario.
La tercera capa, el procesador de comandos, también llamado Shell. Esta es la parte del sistema que envía
desplegados al usuario, acepta los comandos escritos, ejecuta los comandos y emite las respuestas idóneas. El
procesador de comandos reside en un archivo denominado COMMAND.COM, que consta de dos partes
almacenadas en dos secciones diferentes de la MP. Este es solo uno de varios programas que integran el MS-DOS;
los demás están ocultos (COMMAND no es donde reside el SO.).
El trabajo del procesador de comandos consiste en llevar a cabo los comandos del usuario introducidos desde el
signo del sistema sin tener que esperar las instrucciones de algún controlador de dispositivos. Por ejemplo, cuando
el usuario emite el comando PRINT, el procesador de comandos dirige el resultado hacia la línea de impresión
mediante el BIOS.
La debilidad del procesador de comandos es que no es interpretativo, es decir no pueden tomar atajos para abreviar
los comandos. Debía aprenderse a introducir cada comando correctamente y de forma completa.
Administración de memoria
Su tarea es sencilla, porque solo administra un solo trabajo para un único usuario. Para ejecutar un segundo trabajo,
el usuario debe cerrar o hacer una pausa en el primer archivo antes de abrir el segundo. El administrador de la
memoria usa un esquema de asignación de memoria del primer ajuste. El primer ajuste fue escogido para las
primeras versiones de DOS porque es la estrategia más eficiente en un entorno de usuario único.
Estructura
La MP viene en dos formas: memoria de solo lectura ( ROM ) y memoria de acceso aleatorio ( RAM).
La ROM es de tamaño pequeño y contiene un programa, una sección de BIOS con la única tarea de iniciar el sistema.
El proceso de inicialización es llamado rutina de arranque debido a que efectivamente el sistema sale adelante por
sí mismo por medio de sus rutinas de arranque. Este programa en ROM inicia la computadora. También recupera
el resto de la porción residente del sistema operativo de almacenamiento secundario y lo carga en RAM.
RAM es la parte de la MP donde se cargan y ejecutan los programas. La disposición de la RAM para una computadora
con 1 MB de memoria se muestra en la fig

La parte inferior de la RAM denominada memoria baja porque es donde empieza la memoria: 0,1,2 .. está ocupada
por 256 vectores de interrupción y sus tablas.
Un vector de interrupción específica donde está ubicado el programa manejador de interrupciones para un tipo de
interrupción específico. Lo anterior es seguido por tablas BIOS y tablas DOS, y por el núcleo DOS con controladores
adicionales instalables, en caso de haber alguno, que se especifican en el archivo de configuración del sistema
denominado CONFIG.SYS. Esto es seguido por la parte residente del intérprete de comandos COMMAND.COM; la
sección necesaria para ejecutar programas de aplicación.
Cualquier programa del usuario puede cargarse ahora en el área transitoria de programas TPA. Si un gran programa
requiere más espacio, el área superpuesta de COMMAND.COM, localizada en la ubicación de memoria alta, también
puede usarse para el programa de aplicación. Los programas COMMAND.COM en esta área se consideran
transitorios porque se usan para ejecutar comandos, como FORMAT, que no puede ejecutar el usuario cuando está
ejecutándose un programa de aplicación, de modo que es posible que otros programas se superpongan ( o
sobreescribir ).
ASIGNACIÓN DE LA MEMORIA PRINCIPAL
Las primeras versiones de MS-DOS proporcionaban toda la memoria disponible al programa residente, pero esto
es ineficiente porque el esquema simple de asignación de memoria contigua no permitía que los programas de
aplicación asignan y liberan de manera dinámica bloques de memoria. Con la versión 2.0, MS-DOS comenzó a
entender asignación y modificación dinámica, y a liberar de la MP bloques por medio de programas de aplicación.
La cantidad de memoria que realmente pertenece a cada programa de aplicación depende tanto del tipo de archivo
como del programa que se cargue y del tamaño del área transitoria de la TPA.
Toda la TPA se proporciona a los programas con la extensión COM, la necesiten o no.
A los programas con extensión EXE solo se les proporciona la cantidad de memoria que necesitan. Estos archivos
tienen un encabezado que indica la cantidad mínima y máxima de memoria necesarias para la ejecución del
programa. Si el mínimo es más que la cantidad de espacio disponible, no es posible ejecutar el programa.
Excepto por archivos COM, en la TPA puede haber cualquier número de archivos a la vez, pero ¿Por qué un sistema
puede tener dos programas en la memoria cuando solo puede ejecutar uno? RTA: al contar con varios archivos en
memoria, un usuario puede abrir rápidamente uno, trabajar con él y cerrarlo antes de abrir el siguiente. No es
posible abrir ambos al mismo tiempo, pero esto se vuelve más rápido al usuario.
Si un programa que ya está en ejecución requiere más memoria, como para buffers adicionales de E/S, el
administrador de memoria verifica si queda bastante memoria suficiente. En caso afirmativo, la asigna al programa
mientras actualiza la tabla de asignación de bloques de memoria para ese programa. En caso contrario, se regresa
un mensaje de error al usuario y el programa se detiene.
ASIGNACIÓN DE BLOQUES DE MEMORIA
El administrador de memoria asigna la memoria usando un algoritmo del primer ajuste y una lista enlazada de
bloques de memoria. Pero con la versión 3.3 y posteriores, es posible escoger la estrategia de primer o último
ajuste. Cuando se usa el último ajuste DOS asigna el bloque de memoria direccionable más alto suficientemente
grande para satisfacer la solicitud del programa.
El tamaño del bloque puede variar desde tan pequeño como 16 bytes denominado párrafo hasta tan grande como
la máxima memoria disponible. Cuando se forma un bloque, los cinco primeros bytes de un bloque de memoria
definen las características estructurales del bloque.
Siempre que llega una solicitud por memoria, DOS busca en la lista de bloques libres/ocupados, hasta que encuentra
un bloque libre que se ajusta a la solicitud. Si la lista de bloques se desconecta se genera un mensaje de error y el
sistema se detiene, es necesario reiniciarlo.
Un programa de aplicación bien diseñado libera el bloque de memoria que ya no necesita. Y si no está bien diseñado
amontona sus bloques de memoria hasta que termine su ejecución; sólo entonces MS-DOS puede liberar los
bloques de memoria usados por ese programa.
Si dos bloques de memoria son libres contiguos, de inmediato se fusionan en un bloque y se enlazan a la lista.

ADMINISTRACION DEL PROCESADOR

ADMINISTRACIÓN DE PROCESOS
Como no es posible ejecutar dos trabajos al mismo tiempo, ya que MS-DOS fue diseñado para un entorno de tarea
única y de usuario único. Pero algunos programas de software dan esa ilusión como Microsoft Windows, por
ejemplo parecen interrumpir el programa padre, cambiar lo que aparece por pantalla, ejecutar programas no
relacionados y luego regresar al padre; pero esto no es multitarea ( multitarea es sinónimo de la industria de
microcomputadoras para multiprogramación ). Estos programas se ven y se siente como operaciones multitareas
porque retienen su área de la memoria y ejecutan programas ejecutables, pero no están en el estado de ejecución
al mismo tiempo. Esta ejecución es posible porque los manejadores de interrupciones integrados en MS-DOS
proporcionan a los programadores la capacidad de guardar toda la información sobre su programa padre, lo cual
permite su reinicio idóneo una vez que termina el programa hijo.
MANEJADORES DE INTERRUPCIONES
Los manejadores de interrupciones son los responsables de la sincronización de procesos. Una PC cuenta con 256
interrupciones y manejadores de interrupciones, a los que tiene acceso por medio de la tabla de vector de
interrupciones residente en los bytes inferiores de la memoria, (como se muestra en la fig). Las interrupciones
pueden dividirse en 3 grupos:
● interrupciones internas de hardware son generadas por ciertos eventos que ocurren durante la ejecución de un
programa, como división por cero.
● Interrupciones externas de hardware son ocasionadas por controladores de dispositivos periféricos. El software
no puede modificar estas asignaciones porque están conectadas directamente; implementadas como conexiones
eléctricas físicas
● Interrupciones de software son generadas por el sistema y por programas de aplicación. Tienen acceso a
funciones del DOS y del BIOS, las que a su vez tienen acceso a los recursos del sistema.
Algunas interrupciones de software se usan para activar programas de aplicación especializados que asumen el
control de la computadora. Este tipo de manejador de interrupciones denomina Terminate and Stay Resident ( TSR
).Su función consiste en terminar un proceso sin liberar memoria, proporcionando así facilidades de programas
residentes en la memoria. El TSR suele ser utilizado por bibliotecas de subrutinas que son llamadas una vez desde
el nivel de comandos MS-DOS y luego son puestas a disposición para proporcionar servicios a otras aplicaciones a
través de una interrupción de software. Cuando un TSR empieza a funcionar, establece sus tablas de la memoria y
se prepara para su ejecución al conectarse a una interrupción DOS; cuando todo está listo, el programa determina
cuanta memoria debe mantener. Luego, cuando el programa sale, se hace pasar un código de regreso al padre.
¿Cómo se sincronizan estas interrupciones? Cuando la CPU detecta una interrupción, hace dos cosas: 1) coloca en
una pila el contenido del PSW ( programa de estado de palabra ), el segmento del código de registro y el registro
del apuntador de instrucciones; y 2) deshabilita el

sistema de interrupciones de modo que todas las otras interrupciones se apaguen hasta que se haya resuelto la
interrupción actual. La CPU usa el número de 8 bits colocado sobre el bus del sistema por el dispositivo de
interrupciones idóneo de la tabla del vector de interrupciones y obtiene ejecución en esa dirección.
Finalmente, el manejador de interrupciones reactiva la interrupción del sistema para permitir que interrupciones
de alta prioridad ocurran, salvando cualquier registro que este necesite usar y procesando la interrupción lo más
rápido posible.
Este procedimiento es delicado. La sincronización de las actividades del TSR con funciones del DOS ya en progreso
debe diseñarse e implementarse con cuidado para evitar modificar cosas que no deben modificarse o la caída del
sistema.
ADMINISTRACIÓN DE DISPOSITIVOS
Como MS-DOS está diseñado para un entorno de usuario único, todas las solicitudes se manejaban sobre la base
primero en llegar, primero en salir , pero desde la versión 3.0, BIOS puede atender spooling al permitir que los
usuarios planifiquen la impresión de varios archivos uno después de otro. Para hacer esto, BIOS transfiere de
manera continua datos desde un buffer específico de la memoria hacia la impresora hasta que se vacía el buffer.
El administrador de dispositivos MS-DOS permite trabajar con cualquier dispositivo de almacenamiento, disquetes,
discos duros, etc.
Estos sistemas solo usan un tipo de dispositivo E/S para cada puerto, de modo que los canales de dispositivos no
forman parte del MS-DOS y debido a que cada dispositivo cuenta con su propia unidad de control dedicada, los
dispositivos no requieren administración especial del SO. En consecuencia, los manejadores de dispositivos son los
únicos dispositivos necesarios para que el administrador de dispositivos haga funcionar el sistema. Un controlador
de dispositivos es un módulo de software que controla un dispositivo de E/S aunque maneja sus interrupciones.
Cada dispositivo tiene su propio controlador. BIOS es la porción de administrador de dispositivos que manipula el
software del controlador de dispositivos.
El BIOS está almacenado en ROM y en RAM. En muchos otros sistemas MS-DOS, las partes más primitivas de los
controladores están ubicadas en ROM, de modo que pueden usar las aplicaciones y diagnósticos independientes,
así como el programa bootstrapping del sistema. Una segunda sección se carga desde el disco hacia la RAM y
extiende las capacidades de las funciones básicas almacenadas en RM, de modo que BIOS puede manejar todas las
solicitudes de E/S al sistema. BIOS responde a interrupciones generadas por hardware y software.
ADMINISTRACIÓN DE ARCHIVOS
MS-DOS atiende organizaciones de archivos secuenciales, directos e indexados secuenciales.
Los archivos secuenciales pueden tener registros de longitud variable o fija. Sin embargo, los archivos directos y los
indexados secuenciales solo pueden tener registros de longitud fija.
CONVENCIONES DE NOMENCLATURA DE ARCHIVOS
Un nombre no contiene espacios en blanco y consta de la identificación de la unidad, el directorio. DOS no es
sensible a minúsculas o mayúsculas de modo que los nombres de archivos pueden escribirse de cualquier forma.
La identificación de la unidad ( A ; B ; C ; D ) está seguida por dos puntos ( : ).
Los directorios o subdirectorios pueden tener entre uno y ocho caracteres de longitud y van precedidos por un
backslash ( \ ) . el nombre de archivo puede tener entre 1 y 8 caracteres de
longitud y la extensión de 1 a 3 caracteres ( ej : exe ). El nombre base y las extensiones van separadas por un punto.
Un nombre relativo de archivo consta de su nombre base y una extensión, en caso de usarse. Un nombre absoluto
de archivo consta de su identificación de unidad y la ubicación de su directorio ( denominado ruta ) seguidas por su
nombre relativo.
Cuando un usuario está trabajando en un directorio o en un subdirectorio, del directorio en cuestión se denomina
directorio de trabajo y a cualquier archivo en ese directorio puede tenerse acceso mediante su nombre relativo.
Pero para tener acceso a un archivo que está en otro directorio se requiere el nombre absoluto.
Si estoy en el directorio actual y tengo un archivo “trabajo.doc” entonces lo llamaré de la misma manera.
Si estoy en otro directorio debo incluir el nombre del directorio cuando llame a ese archivo /Tomi/TPS/trabajo.doc
Si estoy en otra unidad, debo poner la unidad donde está ubicado C:\Tomi\TPS\trabajo.doc

ADMINISTRACIÓN DE ARCHIVOS
Las primeras versiones de MS-DOS mantenían cada archivo en un solo directorio. Esto era lento y engorroso,
especialmente a medida que se agregan más archivos.
Para recuperar un solo archivo, el administrador de archivos buscaba desde el principio de la lista hasta encontrar
el archivo o llegar al final de la lista. Si un usuario olvidaba el nombre de un archivo, había posibilidad de no verlo
nunca más. Para resolver esto Microsoft implementó una estructura jerárquica de directorios en la versión 2.0; una
estructura de árbol invertida ( raíz en parte superior y hojas en la parte inferior)
Cuando se formatea un disco ( usando el comando FORMAT ) sus pistas se dividen en sectores de 512 bytes cada
uno. ( esto corresponde al tamaño del buffer de 512 bytes ) Los discos de un solo lado tiene una superficie grabable;
los de dos lados tienen dos, y los discos duros tienen de dos a cuatro platos, cada uno con dos superficies grabables.
Los sectores ( de dos a ocho ) están agrupados en clusters y esa es la manera en que el administrador de archivos
asigna espacio a los archivos. Cuando un archivo requiere espacio adicional, DOS le asigna más clusters. Además de
dividir el espacio del disco, FORMAT crea tres áreas especiales sobre el disco:
el registro de arranque es el primer sector de todo disco lógico, ya sea una unidad – entidad totalmente física
(como un disco duro o disquete) o solo un disco virtual (como un disco RAM).
Empezando con la versión 2.0 el registro de arranque contiene el programa del disco de arranque y una tabla con
las características del disco.
el directorio raíz es donde el sistema empieza su interacción con el usuario cuando arranca. El directorio raíz
contiene una lista de los subdirectorios y archivos primarios del sistema, incluyendo cualquier archivo de
configuración generado por el sistema y cualquier instrucción de arranque generada por el usuario que pudiera
estar incluida en un archivo AUTOEXEC.BAT se trata de un archivo por lotes que contiene una serie de comandos
definidos por el usuario. Cada vez que se enciende o restablece la CPU, el sistema ejecuta de manera automática
los comandos de este archivo.
La información que contiene el directorio raíz es:
- Nombre del archivo
- Extensión del archivo
- Tamaño del archivo en bytes
- Fecha y hora que se realizó la última modificación
- Número del cluster inicial para el archivo
- Los códigos de los atributos del archivo
Con el comando DIR se muestran los primeros 4 elementos.
El número de entradas en el directorio raíz es fijo. Ej: para un disco duro de 20MB solo se permiten 512 entradas.
El tamaño del directorio raíz es limitado porque DOS requiere saber donde empieza el área de datos del disco.

FAT que significaba Tabla de Asignación de Archivos contiene información crítica del estado, incluyendo la
capacidad de cada sector para ser asignado o no, lo que puede ser el resultado de errores de formateo que
interpretan al sector como no utilizable.
El directorio nota el número del primer sector o cluster del archivo; ese número se registra en el directorio cuando
se crea el archivo. Todos los sectores o clusters sucesivos asignados a ese archivo se registran en la FAT, y se enlazan
entre sí para formar una cadena, donde cada entrada del AFAT proporciona el número de sector/cluster a la
siguiente entrada. La última entrada de cada cadena contiene el valor Hex FF para indicar el final de la cadena.
Como se ve en la sig fig
MS-DOS busca en los datos en un archivo del disco como una cadena continua de bytes. En consecuencia, las
operaciones de E/S solicitan los datos por byte relativo (relativo con respecto al inicio del archivo ) en vez de por
sector relativo. La transformación de un sector físico ( o cluster) en una dirección relativa de byte la efectúa el
administrador de archivos de modo que parece que el acceso a los datos sobre un disco es justo como el acceso a
los datos en la MP.
Como ya sabemos, MS-DOS atiende el almacenamiento de archivos no contiguo y asigna de manera dinámica
espacio de disco a un archivo, en el supuesto de que en el disco no hay suficiente espacio. Lamentablemente a
medida que en el disco se agregan y borran archivos, un archivo puede volverse demasiado fragmentado haciendo
cada vez más engorroso y consumidora de tiempo de recuperación.
La compactación se volvió una característica de la versión 6.0 de MS-DOS con la inclusión de DEFRAG.EXE, una
utilidad usada para desfragmentar discos al escoger los fragmentos de un archivos posicionarnos como una sola
pieza en espacio contiguo.
Para determinar la necesidad de compactación puede usarlas otro comando. Dado CHKDSK ( nombre del archivo )
el sistema responde con el número de bloques no contiguos donde está almacenado el archivo. Es decisión del
usuario compactar al archivo, en caso de ser necesario, de modo que se almacena en el menor número de bloques
no contiguos para acelerar el tiempo de acceso y reducir el mantenimiento sobre el mecanismo de búsqueda.
La habilidad para restringir el acceso del usuario al sistema de cómputo y sus recursos no está incluida en MS-DOS.
Se cuenta con software de seguridad que puede agregarse aunque para la mayoría de los usuarios, los datos se
mantienen seguros al mantener la computadora cerrada físicamente o al retirar los discos y guardarlos en un sitio
seguro.
INTERFAZ DE USUARIO
MS-DOS es una interfaz controlada por comandos. El símbolo C:> es el símbolo para el disco duro y A:> es para
disquetes, el símbolo del sistema predeterminado puede cambiarse usando el comando PROMPT.
Algunos comandos también eran DIR,CD,COPY,DEL,RENAME, etc.
Los comandos son ejecutados por el archivo COMMAND.COM, que forma parte de MS-DOS, cuando
COMMAND.COM se carga durante el inicio del sistema, una de sus secciones se almacena en la sección baja de la
memoria: esta es la porción residente del código. Contiene el intérprete de comandos y las rutinas necesarias para
atender un programa activo. Además contiene las rutinas necesarias para procesar CTRL-C , CTRL-BREAK y los
errores críticos.
El código transitorio, la segunda sección de COMMAND.COM, se almacena en las direcciones más altas de la
memoria y pueden sobreescribirse por programas de aplicación si necesitan usar su espacio de memoria. Después
de terminar el programa, la porción residente de COMMAND.COM verifica si el código transitorio sigue intacto. En
caso negativo, carga otra copia.
A medida que un usuario escribe un comando, cada carácter se almacena en la memoria y aparece por pantalla.
Cuando se oprime la tecla enter, el SO. transfiere el control a la porción del intérprete de comandos de
COMMAND.COM, que entonces tiene acceso a la rutina que lleva a cabo la solicitud o muestra un mensaje de error.
Si la rutina reside en la memoria, entonces el control se le proporciona de manera directa. Si la rutina reside en
almacenamiento secundario, se carga en la memoria y después se le proporciona el control.
Como no es posible describir todos los comandos de MS-DOS merece la pena destacar la flexibilidad de este SO.
ARCHIVOS POR LOTES
Al crear archivos por lotes personalizados, los usuarios pueden ejecutar rápidamente combinaciones de comandos
DOS para configurar sus sistemas, realizar tareas de rutina o facilitar que usuarios no técnicos puedan ejecutar
software.
Por ejemplo si un usuario verifica rutinariamente la fecha y hora del sistema, carga un controlador de dispositivos
para un ratón, se desplaza cierto subdirectorio y carga un programa denominado MAIL.COM, entonces ese
programa, denominado START.BAT, realiza cada uno de esos pasos a su vez.
Para ejecutar este programa, el usuario sólo necesita escribir START en el símbolo del sistema. Para que este
programa se ejecute automáticamente cada que se reinicia el sistema, entonces el archivo debe volverse a nombrar
AUTOEXE.BAT y cargarse en el directorio raíz del sistema. Al usar archivos por lotes cualquier combinación tediosa
puede reducirse a unos cuantos comandos personalizados fáciles de usar.
REDIRECCION
MS-DOS puede redirigir la salida desde un dispositivo de entrada o salida normal hacia otro. Por ejemplo, el
comando DATE envía el resultado directamente a la pantalla pero al usar el símbolo de redirección ( > ) en lugar de
lo anterior la salida se redirige a otro dispositivo o archivo.
La sintaxis: command > destination

Por ejemplo para enviar una lista del directorio a la impresora

DIR > PRN y la lista aparece en la página impresa , en lugar de en pantalla.
Es posible redirigir y agregar nuevos resultados hacia un archivo existente al usar el símbolo agregar (>>). Por
ejemplo: si ya se ha creado el archivo DIRFILE con el comando de redirección y se desea generar una lista del
directorio y agregarla en el archivo DIRFILE creado previamente, debe escribirse: DIR >> B:DIRFILE
Ahora DIRFILE contiene dos listas del mismo directorio.
La redirección también funciona de manera opuesta. Si se quiere modificar la fuente a un dispositivo o archivo
específico, debe usarse el símbolo ( < )
Por ejemplo : se tiene un programa INVENTRY.EXE que espera datos de entrada desde el teclado, aunque para
efectos de prueba y depuración se requiere que acepte datos de entrada desde un archivo de prueba de datos. En
este caso debe escribirse:
INVENTRY < B:TEST.DAT

FILTROS
Los comandos filtro aceptan datos de entrada desde el dispositivo predeterminado, manipulan los datos de alguna
manera y envían los resultados al dispositivo de salida predeterminado. Un filtro de uso común es el SORT, que
acepta los datos de entrada desde el teclado, ordena esos datos y los muestra por pantalla. Este comando filtro se
vuelve más útil al usar esos
parámetros de redirección. Por ejemplo, si usted desea ordenar un archivo de datos denominado STD.DAT y
almacenarlo en otro SORTSTD.DAT, debe escribir:
SORT < STD.DAT> SORTSTD.DAT
El archivo almacenado puede estar en orden creciente empezando con el primer carácter en cada línea del archivo.
Si desea que el archivo este almacenado en orden inverso, debe escribir:
SORT / R < STD.DAT> SORTSTD.DAT
Es posible ordenar el archivo por columnas también, usando
SORT /+14 <EMP.DAT> SORTSTD.DAT

TUBERÍAS
Una tubería puede ocasionar que la salida normal de un comando sea utilizada como entrada normal para otro
comando; este símbolo es una barra vertical ( | ) Es posible ordenar alfabéticamente el directorio y mostrar la lista
ordenada en la pantalla al escribir:
DIR | SORT
También es posible cambiar tuberías y otros filtros. Por ejemplo para mostrar en la pantalla el contenido del archivo
INVENTRY.DAT a la vez, sería:
TYPE INVENTRY.DAT | MORE
Es posible ordenar el archivo y mostrar el resultado en la pantalla a la vez al usar tuberías con este comando
DIR | SORT | MORE
COMANDOS ADICIONALES
Había 3 comandos adicionales que se usan a menudo en MS-DOS son FIND, PRINT y TREE
FIND es un comando filtro que busca una cadena específica en un archivo o archivos datos y despliega todas las
líneas que contienen la cadena de esos archivos.
PRINT permitia que el usuario establezca una seria de archivos para imprimir mientras libera al COMMAND.COM
para aceptar otros comandos. El comando PRINT tiene muchas opciones pero para usar las dos siguientes estas
deben proporcionarse la primera vez que se usa el comando PRINT después de arrancar el sistema.
● El comando PRINT/B permite cambiar el tamaño del buffer interno. Por defecto es de 512 bytes, pero aumentar
su valor acelera el proceso PRINT.
● El comando PRINT/Q especifica el número de archivos permitidos en la siguiente cola de impresión. El valor
mínimo para Q es 4 y el máximo 32.
TREE muestra los directorios y subdirectorios en una lista jerárquica y con sangría. También tiene opciones que
permite que el usuario borre archivos mientras se está generando el árbol. También puede usarse para borrar
archivos duplicados en diferentes directorios.
CONCLUSIÓN
MS-DOS fue escrito para rendir servicio a los usuarios de PC, incluyendo las primeras versiones de las computadoras
personales de IBM. Tuvo éxito pero su flexibilidad limitada lo hizo inutilizable a medida que evolucionan las PC.
MS-DOS se recuerda como el primer SO. normal que fue adoptado por muchos fabricantes de maquinas de calculo
personales.
La debilidad de MS-DOS fue su diseño de sistema de usuario único de tarea única que no podía atender multitarea,
redes y otras aplicaciones sofisticadas requeridas por computadoras de todos tamaños.
TÉRMINOS
Archivo por lotes: Archivo que incluye una serie de comandos que se ejecutan en secuencia sin ningún dato de
entrada de parte del usuario. Contrasta con una sesión interactiva.
Asignación de memoria del primer ajuste: Esquema de asignación de memoria que busca desde el principio del
bloque de árbol y escoge para su asignación el primer bloque de memoria suficientemente grande para satisfacer
la solicitud. Contrasta con la asignación de memoria del mejor ajuste.
Bootstrapping: proceso de arrancar una PC inactiva al usar un pequeño programa de inicio para cargar otros
programas
BIOS: sistema básico de entrada-salida, un conjunto de programas codificados en un chop para cargarse en ROM al
inicio.
Comando filtro: comando que dirige los datos de entrada desde un dispositivo o archivo, los modifica y después
envía el resultado a una impresora o pantalla
Compactación: proceso de reunir fragmentos de espacio de memoria disponible en bloques contiguos al mover
programas y datos en la memoria o en almacenamiento secundario de una PC.

Controlador de dispositivo: módulo del programa específico que maneja las interrupciones y controla un tipo
particular de dispositivo
Extensión: parte del nombre del archivo que indica cual compilador o paquete de software es necesario para
ejecutar los archivos
FAT ( tabla de asignación de archivos): tabla usada para seguir la pista de segmentos de un archivo
Tubería: símbolo que dirige al SO para diversificar los resultados de un comando, de modo que se vuelvan los datos
de entrada de otro comando. En MS-DOS símbolo (|)

ElMasri CAP 8.4 en adelante (PLANIFICACION DE PROCESOS)

PLANIFICACIÓN DE PROCESOS
Como habíamos visto, un proceso puede abandonar el estado de ejecución por varias razones. Cuando lo hace,
puede ir de inmediato al estado listo, por ejemplo si fue interrumpido por haber llegado a los límites de su quantum.
Si un proceso está esperando algún evento, quizá que concluya alguna operación de E/S, y el evento ocurre,
entonces es necesario colocar el proceso en el estado listo, de modo que pueda llegar al estado de ejecución y
manipular el evento. Cuando un proceso se coloca en el estado listo, es necesario decidir cuándo debe ejecutarse
en relación con los procesos que ya se encuentra en el estado listo. Esta decisión la tomó un módulo del SO
denominado Planificador a corto plazo.
Algunos algoritmos utilizados
Planificación Primero en llegar, primero en ser atendido
El método más simple e históricamente usado por muchos SO, consiste en ejecutar un programa primero en entrar,
primero en salir ( FIFO ) con una cola normal. Este algoritmo se denomina FCFS (first come, first served : primero
en llegar, primero en ser atendido ) Presenta algunas ventajas. Es el algoritmo más justo ( bajo ninguna
circunstancia favorece a un proceso en detrimento de otro ). FCFS es mejorado a menudo al permitir que un proceso
en ejecución haga una llamada al sistema que otorgue control al siguiente proceso en el estado listo. Esto se
denomina multitarea cooperativa. Por supuesto, los procesos en ejecución podrían tener un error o podrían
intentar contar con una mejor respuesta del usuario al usar más tiempo de CPU de lo debido, por lo que no era una
solución ideal.
PLANIFICACIÓN POR PRIORIDAD
Hay algunas circunstancias en la que no es aconsejable utilizar FCFS por alguna que otra razón, podrían tener
algunos procesos más importantes que otros. En este caso podemos utilizar el algoritmo de planificación por
prioridad. En este algoritmo damos precedencia a cada proceso, por ejemplo nuestro manipulador de teclazos y
del ratón puede tener la prioridad más alta.
Siempre que permitimos que algunos trabajos tengan prioridad sobre otros hay un problema especial, es posible
que los procesos con prioridad más alta estén postergando un proceso de baja prioridad hasta el punto en que este
último jamás sea ejecutado. Este problema se denomina inanición. Hay varias formas en que es posible tratar este
problema, colectivamente se denominan envejecimiento. En general monitoreamos los procesos que se han
postergado
y siempre que un proceso se pospone demasiadas veces, simplemente elevamos temporalmente su prioridad,
finalmente el proceso obtendrá una prioridad suficientemente alta que origina que sea ejecutado una vez, luego
hacemos descender la prioridad a donde estaba originalmente, al final incluso los procesos con prioridad baja
terminan, aunque a trabajos con prioridad superior se les proporcionará la mayor parte del tiempo.
PLANIFICACIÓN GARANTIZADA
La programación FCFS proporciona a cada proceso una posibilidad justa de ser ejecutado, pero si un proceso tiene
demasiadas llamadas a bloqueos no recibe ninguna cantidad justa de tiempo de CPU si otros procesos con menos
llamadas a bloques están en ejecución. En planificación garantizada, el SO necesita seguir la pista de la cantidad
total de tiempo de CPU por proceso y el total del tiempo reloj, luego calcula la razón del tiempo de CPU que el
proceso uso en realidad a la cantidad de tiempo que el proceso estuvo autorizado y ejecuta el que tiene la razón
más pequeña. Esto también se llama algunas veces planificación por participación equitativa. Sería una especia de
programación por prioridad.
PLANIFICACIÓN SRTF
Este algoritmo se llama Primero con el tiempo de ejecución más corto ( también denominado algunas veces como
primero con el tiempo restante más corto; STRF ) o menor trabajo siguiente (SJN) Este simplemente selecciona el
siguiente trabajo a ejecutar tal que se ejecute durante la menor cantidad de tiempo posible. Pero como no es
posible saber cuándo será el siguiente arrebato de un proceso de parte de la CPU, es posible rastrear el desempeño
pasado de cada proceso y pronosticar que en el siguiente arrebate de la CPU se comportará en forma muy
semejante a como lo hizo en arrebatos previos.
ALGORITMO HRRN ( SIGUE EL DE RAZÓN DE RESPUESTA MÁS ALTA )
La planificación es semejante a la planificación menor trabajo siguiente, donde la prioridad de cada trabajo es
dependiente respecto a su tiempo de ejecución estimado. Pero HRRN también incluye la cantidad de tiempo que
el proceso emplea en espera. Un proceso obtiene prioridad más alta mientras más tiempo espere. Esta variante se
usa principalmente porque disminuye la probabilidad de inanición (cuando es posible que un proceso de prioridad
más alta estén
postergando un proceso de baja prioridad hasta el punto en que este último jamás sea ejecutado)
APROPIACIÓN
Suponiendo que otro proceso de prioridad superior ha estado esperando la terminación de un evento de E/S.
Puesto que sabemos que la prioridad de este proceso es superior a la del proceso que estaba ejecutándose,
podemos detener este último e iniciar el de prioridad superior. El hecho de alejar un recurso de un proceso se
denomina Apropiación. En este caso el recurso que estamos apropiando es la CPU en si.
Podemos aplicar apropiación a cada uno de los algoritmos vistos más arriba, si permitimos la apropiación al
algoritmo FCFS se convierte en el algoritmo Round-Robin. En este caso la apropiación no está basada en la prioridad
sino en un cuanto de tiempo. Dejamos que cada proceso ejecute una cantidad específica de tiempo sin hacer
ninguna operación de E/S. Si el proceso excede ese tiempo, apropiamos la CPU y colocamos ese proceso al final de
la cola de ejecución.
Si aplicamos apropiación al algoritmo NJS( menor trabajo siguiente), se convierte en el algoritmo primero la menor
cantidad de tiempo que queda. Cuando se apropia un proceso en
ejecución por un proceso de prioridad más alta, en el BCP anotamos la cantidad de tiempo que queda en nuestra
conjetura del tiempo de ejecución de ese proceso. Cuando lo reiniciamos más tarde, no hacemos ninguna conjetura
nueva.
En el algoritmo por prioridad podemos aplicar la apropiación cuando un proceso de prioridad superior entra en el
estado listo. Este algoritmo especial carece de una denominación especial, se le conoce como Prioridad con
apropiación.
COLAS MULTINIVEL
Los SO más modernos, usan un algoritmo de planificación más complicado denominado colas multinivel. En lugar
de tener una cola única se tienen varias. Un nuevo trabajo se coloca en una de las colas. Todas las colas individuales
pueden usar el mismo algoritmo de planificación, o pueden usar algoritmos distintos. Si todos los algoritmos
emplean espacios de tiempo, cada una de las colas puede tener asignado un cuanto de tiempo diferente. Las colas
tienen prioridades diferentes y la cola con la prioridad más alta se atiende primero. Una cuestión que es necesario
decidir es el mecanismo utilizado para compartir la CPU entre las colas. Hay dos enfoques. Primero podemos hacer
que el mecanismo sea de prioridad estricta, osea que en la medida en que haya procesos en las colas de prioridad
superior, estas se ejecuten primero.
La mayoría de los SO modernos cuentan con un mecanismo feedback ( retroalimentación ) a las colas multinivel. El
supuesto inicial es que un nuevo proceso es interactivo, de modo que se coloca en una cola de alta prioridad. Si el
proceso se ejecuta por más tiempo del permitido por el cuanto de tiempo para esta cola sin hacer ninguna llamada
de bloqueo al SO, entonces el SO supone que en realidad no es proceso interactivo, de modo que lo mueve hacia
la siguiente cola de prioridad menor, esta cola también puede tener un cuanto de tiempo más largo. Entonces si el
proceso no termina su cuanto de tiempo en la cola rápida, quizá sea conveniente darle más tiempo a la cola inferior.
Por lo regular hay al menos 3 de esas colas. Así en caso de que un proceso en ejecución en la segunda cola aún no
haya realizado ninguna llamada de bloqueo en el cuanto de tiempo para esa cola, es desplazando a una cola inferior,
quizá con un cuanto de tiempo más grande.
SELECCIÓN DEL MEJOR ALGORITMO
¿Con tantos algoritmos como compararlos? Hay varias medidas del desempeño del sistema que se han usado para
comparar algoritmos de planificación. Algunas incluyen lo siguiente:
● Producción : número de trabajos que se ejecutan por hora o por minuto.
● Tiempo promedio de retorno : tiempo transcurrido desde el inicio hasta el final del trabajo.
● Tiempo promedio de respuesta : tiempo transcurrido desde que se presenta el trabajo hasta el inicio del
resultado.
● Utilización de la CPU : porcentaje del tiempo en que la CPU ejecuta trabajos reales ( sin intercambiar entre
procesos o hacer alguna otra tarea)
● Tiempo promedio de espera : Tiempo que el proceso pasa a la cola de listo.
La forma más fácil de comparar el tiempo promedio de espera de los diversos algoritmos consiste en aplicar un
método denominado modelado discreto. Se toma una muestra de procesos y sus tiempos de ejecución y
manualmente se simula la ejecución de cada proceso en la muestra de datos, luego se calcula el tiempo de espera
de los procesos que no están en ejecución y se compraran los valores.
UN PLANIFICADOR A LARGO PLAZO.
Algunos SO cuentan con otro módulo planificador denominado planificador a largo plazo. En un SO PC con una
GUI, normalmente no existe este planificador.
La tarea del programador a largo plazo es decidir cuántos trabajos tratar de ejecutar al mismo tiempo y cuales
ejecutar cuando. El primer aspecto de esta decisión es que hay algún número mínimo de trabajos que se quiere
ejecutar al mismo tiempo. La ejecución empieza con este número mínimo de trabajos, en el supuesto de que haya
más de los que es posible ejecutar a la vez. Un aspecto de esta decisión tiene que ver con el nivel de utilización de
la CPU. Todos los trabajos en ejecución son esencialmente trabajos que usan bastante E/S, entonces el planificador
a largo plazo trata de encontrar algunos trabajos que considera que pueden elevar el nivel de utilización de la CPU.
AFINIDAD DE LOS PROCESADORES
Sabemos que hay considerables gastos generales implicados cuando una CPU cambia de un proceso a otro, debido
al uso de la memoria caché que lleva a cabo el hardware, la ejecución del proceso aminora drásticamente su
velocidad durante un lapso hasta que los buffers de la memoria caché cambian del proceso anterior al nuevo.
En un sistema multiprocesamiento a menudo es posible que el SO mantenga afinidad de procesadores para un
proceso dado (afinidad es parecido, similar , etc ) Esta afinidad constituye un valor que el SO usará para indicar una
preferencia para ejecutar este proceso en alguna CPU particular siempre que sea posible. En algunas instancias, un
administrador de sistema puede indicar que un proceso particular debe estar estrechamente acoplado con una CPU
específica. En otros casos, el SO simplemente intenta ejecutar un proceso en la misma CPU que uso la ultima vez
que ejecuto un proceso. En algunos SO es posible dedicar una CPU a un proceso, de modo que solo este sea
ejecutado en ella.
UN BUEN PROCESO MERECE OTRO ( CREO QUE ES MODELO DE CREACIÓN DE PROCESOS)
Cuando un usuario manda señales al intérprete de comandos para iniciar un nuevo proceso, debe haber alguna
manera para que el proceso de ese intérprete de comandos inicie el proceso del usuario. El intérprete de comandos
envía una llamada normal al supervisor para iniciar otro proceso.
Esta llamada al supervisor se denomina fork. El proceso que hace la llamada se denomina proceso padre, y el
proceso iniciado como resultado se denomina proceso hijo. Todo el mecanismo se denomina “bifurcado un hijo” o
“ generando un hijo “. Así resulta evidente la necesidad de que el intérprete de comandos inicie otro proceso. Pero
porque debe hacer eso la aplicación de un usuario? La primera razón es el desempeño. Si un proceso tiene muchas
tareas por efectuar que pueden iniciarse al mismo tiempo, puede iniciar procesos adicionales para ejecutar algunas
de esas tareas y el SO puede hacer que todos los procesos se ejecuten. Esto es factible si el sistema cuenta con
múltiples CPUs . Pero hay varias complicaciones que surgen cuando se deja que un proceso inicie otro. Por ejemplo
Si por alguna razón el proceso padre termina ¿ dejamos que cualquier proceso hijo continúe su ejecución o también
lo terminamos? La mayor parte de los SO terminan de manera automática cualquier proceso hijo si el proceso padre
termina. Algunos no, en los SO modernos es posible elegir. Un proceso hijo cuyo proceso padre ha terminado se
denomina proceso huérfano.
Otra cuestión tiene que ver con la propiedad de los recursos. Si un proceso padre tiene un archivo abierto ¿El
proceso hijo puede tener acceso al archivo? Todavía otra cuestión está relacionada con el programa que está
ejecutando el proceso hijo. En la mayor parte de los casos de una llamada fork, el proceso hijo tiene una copia
exacta del proceso padre en otro bloque de la memoria. Observa que tanto el proceso padre como el hijo a
continuación ejecutan la instrucción que sigue a la llamada fork. Pero cómo sabe cada uno de los procesos cuál
instancia es el padre y cuál el hijo? En general el código de regreso proviene del fork y se fija en cero para el proceso
hijo y un número positivo distinto de cero para el proceso padre.
Por lo regular, contar con otra instancia en ejecución del proceso padre no es lo que se quiere. No es aconsejable
tener otra copia del intérprete de comandos, lo que desea es ejecutar algún otro programa, lo que realmente se
quiere es la ejecución de otro programa en un proceso hijo. Así luego de la llamada fork, se hace otra llamada para
cargar un nuevo programa en el espacio de la memoria asignada para el proceso hijo. Esta suele ser una llamada al
sistema EXEC.
Por supuesto, si en realidad lo que se desea es la ejecución de otro programa, entonces el paso inicial de copiar el
proceso padre en otro bloque de la memoria es un desperdicio de muchos recursos. Por tanto, algunos SO
proporcionan una llamada diferente denominada comando Shell. Este comando crea un nuevo proceso pero nunca
copia el proceso padre en el espacio hijo – carga el programa deseado inmediatamente – Algunos SO ofrecen tanto
el par FORK / EXEC como el comando SHELL y otros solo ofrecen uno u otro.
¿QUÉ ES UN HILO?
Es una secuencia de tareas encadenadas muy pequeña que puede ser ejecutada por un sistema operativo.
Un BCH (bloque de control de hilos o TCB (thread control block ) es una tabla donde se guardan todos los datos
que representan el estado de la CPU.
Supongamos que iniciamos un proceso desde el principio y lo guardamos en esa tabla, ahora supongamos que
iniciamos otro proceso. De nuevo lo dejamos en ejecución durante algún tiempo, luego lo detenemos y guardamos
el estado de la CPU en otro BCH. Ahora podemos regresar y restituir el estado guardado de la CPU del primer hilo
y reanudar su ejecución ¿Cómo sería esto diferente de la ejecución de múltiples procesos? Hay varias maneras de
utilizar diversos hilos que pueden ser mejores que el uso de varios procesos. Por una razón solo contamos con una
copia del programa y los datos en la memoria, de modo que hay más memoria para utilizar para otras cosas. Por
otra razón hay menos gastos generales para intercambiar entre hilos que para cambiar entre procesos puesto que
solo estamos guardando el estado de la CPU. En general esto significa almacenar unos cuantos registros ( incluyen
el apuntador de instrucciones ) y el apuntador al espacio de la pila. Finalmente cuando se están usando múltiples
procesos para implementar un sistema, tiene un difícil problema de comunicación temporal. Los diseñadores han
experimentado bastantes problemas para aislar procesos entre sí, de modo que un proceso no puede modificar el
contenido de la memoria de otro proceso, ya sea intencionalmente o no. Se han inventado muchos mecanismos
para permitir que los procesos cooperativos se comuniquen. Sin embargo los hilos no tienen ese problema. Por
definición todos los hilos creados por un proceso único están en ejecución en el mismo espacio de direcciones y
comparten tanto el código como los datos, en consecuencia los hilos tienen acceso a las mismas variables. La
dificultad más importante es impedir que los hilos individuales manipulen los mismos datos al mismo tiempo.
Cuando iniciamos un segundo hilo, no lo comenzamos al principio del proceso, recordando que simplemente
afirmamos que diversos hilos comparten una simple copia del código del
programa y los datos que posee el proceso. Normalmente una de las primeras cosas que hace un proceso es iniciar
tablas de datos, pero solo la hace el primer hilo.
HILOS A NIVEL DEL USUARIO CONTRA HILOS A NIVEL DEL NÚCLEO.
El uso de múltiples procesos apareció antes que la idea de hilos. Cuando los programadores se dieron cuenta de
que el intercambio entre procesos usaba tantos recursos y aminoraba tanto la velocidad, empezaron a desarrollar
el concepto de hilos,así el desarrollo original de los hilos se hizo como un conjunto de subrutinas de biblioteca. Por
supuesto, esto significaba que todo
El paquete de hilos se ejecutaba en el modo del usuario y el SO no estaba consciente de que una aplicación estaba
intentando mantener múltiples actividades ejecutándose en paralelo. En consecuencia, si cualquiera de los hilos en
un sistema hacia una llamada al sistema que pudiera bloquear por alguna razón toda la aplicación, incluso todos
los hilos de esa aplicación quedarían bloqueados al mismo tiempo. Este paquete de hilos se denomina paquete de
hilos al nivel de usuario porque se ejecuta completamente en el modo usuario.
Finalmente, los diseñadores de SO decidieron que los hilos eran tan buena idea que incorporaron sus funciones en
el núcleo. Ahora el SO estaba consciente de que la aplicación estaba utilizando hilos. Estos paquetes de hilos se
denominan paquetes de hilos al nivel del núcleo también puesto que el SO está consciente de los hilos individuales,
es posible que los hilos se ejecuten en una CPU por separado en un sistema con múltiples CPU. Esta es una ventaja
fundamental para los hilos al nivel del núcleo.
En general, los hilos a nivel del núcleo son mucho más fáciles de usar que los a nivel de usuario, porque el
programador no tiene que evitar llamadas a bloqueos.
MODELOS DE SOPORTE DE HILOS
Cuando los SO empezaron a ofrecer paquetes de hilos al nivel del núcleo, había 3 métodos comunes para hacer que
las rutinas de la bibliotecas del usuario usen hilos al nivel del núcleo. La cuestión más importante que los distingue
es el método de mapeo de los hilos al nivel del usuario a hilos al nivel del núcleo. Los 3 métodos son:
uno a uno : cuando la aplicación llama a la rutina de la biblioteca para crear un nuevo hilo, dicha rutina llama al
mecanismo de hilos al nivel del núcleo para crear un hilo a ese nivel. Este modelo tiene la ventaja de ser rápido y
fácil de desarrollar y comprender para el usuario
muchos a uno : Recuerda que la biblioteca del usuario que se está modificando bloquea todo el proceso cuando
cualquier hilo en la aplicación hace una llamada de bloqueo al SO. Este modelo hace exactamente lo mismo, solo
se crea un hilo al nivel del núcleo y todos los hilos al nivel del usuario se mapean sobre el mismo hilo al nivel del
núcleo. Este modelo es menos aconsejable que el modelo uno a uno porque no ofrece la ventaja de hilos a nivel
del núcleo
muchos a muchos : En este modelo, el programador indica al sistema cuantos hilos al nivel del usuario y cuantos
hilos al nivel del núcleo serán necesarios y cómo deben mapearse. La idea básica es tener un grupo de hilos al nivel
del núcleo disponible y asignarles dinámicamente hilos al nivel del usuario según sea necesario.
Aunque los hilos son más fáciles de crear y destruir que los procesos, sigue habiendo algo de trabajo adicional
implicado en la creación de aquellos, como resultado algunos paquetes de hilos crean un grupo de estructuras de
hilos cuando el procedimiento llama por primera vez al paquetes de hilos. Este paquete se llama banco de hilos.

PROCESOS CONTRA HILOS

Los hilos y los procesos son – ambos – métodos para agregar paralelización a una aplicación. Los procesos son
entidades independientes, donde cada uno contiene su propia información de estado y espacio de direcciones. Solo
interactúan a través de mecanismos de comunicación interprocesos mediante el SO. Las aplicaciones suelen
dividirse típicamente en procesos durante la fase de diseño. Un único proceso de control invoca a los otros
procedimientos cuando tiene sentido separar lógicamente la funcionalidad de aplicaciones importantes.
Por el contrario, un hilo es una técnica de codificación que no afecta la arquitectura de una aplicación. Un proceso
único a menudo contiene múltiples hilos. Todos los hilos en un proceso comparten el mismo estado y mismo
espacio de la memoria e implícitamente se comunican entre sí de forma directa mediante la manipulación de los
datos compartidos.
Los hilos se crean para su uso a corto plazo, que suele considerarse como una tarea en serie que no requiere ser
ejecutada en secuencia, sino que más bien puede ejecutarse en paralelo. Una vez que dejan de ser necesarios se
destruyen, el alcance de un hilo está dentro de un módulo de codificación específico de modo que el hilado puede
introducirse en un proceso sin afectar al diseño global de la aplicación.

ElMasri CAP 11 de 11.1 a 11.6.2 (GESTIÓN AVANZADA DE MEMORIA) PAGINACIÓN

En lugar de usar el registro base para verificar una dirección, lo utilizamos para reubicarla. Esto nos permitió la
reubicación dinámica. Sin embargo, encontramos que el hecho de permitir que programas de tamaño variable
entren y salgan de la memoria provocaba fragmentación externa. Desafortunadamente, la compactación es solo
una tarea que hace el SO para que las cosas funcionen mejor en sentido global.
Finalmente se desarrolló otra solución: dividimos el espacio de la memoria en bloques de tamaño fijo, y en lugar
de asignar a una aplicación todo el espacio que necesita en un gran segmento, le asignamos una cantidad suficiente
de bloques más pequeños para proporcionarle lo que necesita. Los bloques que asignamos pueden estar en
cualquier parte de la memoria porque solicitamos a la MMU que reasigne dinámicamente cada bloque por
separado. Esta técnica se denomina paginación.
Dividimos el espacio en direcciones físicas en bloques de tamaño uniforme, que denominamos marcos. El número
de bytes en un bloque siempre es una potencia de 2.
La CPU genera una dirección de la memoria. En general, el programa ignora el hecho de que la memoria se manipula
en páginas separadas. La MMU considera que la dirección está compuesta por dos partes, mostradas aquí como el
número de página, p, y el desplazamiento, d. El desplazamiento es la dirección del byte específico dentro del marco.
El resto de la dirección lógica es el número de página.

Tendremos un registro que guarda la

dirección de la memoria de la tabla de páginas para el proceso en ejecución. Se denomina registro de dirección de
la tabla de páginas. La unidad de control de la memoria añade el número de la página de la dirección lógica que
genera el proceso en ejecución en la CPU al valor en el registro de dirección de la tabla de páginas. El valor
almacenado en esa ubicación de la tabla de páginas es la dirección de reubicación del marco particular al que se
está intentando tener acceso.
ACCESOS REQUERIDOS A LA MEMORIA DUAL
Aunque ya hemos descrito este mecanismo. Para cada referencia a la memoria es necesario hacer una segunda
referencia, a fin de encontrar en la tabla de páginas la entrada a utilizar como factor de reubicación para esta página.
Nuestra solución es que la unidad de gestión de la memoria guarde en memoria caché los factores más recientes
de reubicación, de modo que podamos usarlos nuevamente sin necesidad de buscarlos en la memoria. Esto se lleva
a cabo con un dispositivo especial de hardware denominado búfer duplicado de traducción, o TBL (translation
lookaside buffer). La esencia de estos circuitos es que cuando intentan verificar si ahí hay un número de página,
todas las entradas se buscan en paralelo. Las entradas en el TBL no tienen que mantenerse en ningún orden.

CONTROL DE ACCESO A LA MEMORIA

Cuando teníamos accesos a la memoria principal con un registro de reubicación para todo el programa también
teníamos un registro que prohibía que un proceso accediera fuera del área de la memoria que tenía asegurada. Con
hardware de paginación se requiere un mecanismo semejante.
Se requieren algunos mecanismos para limitar el acceso a la tabla de páginas. Para este problema hay dos enfoques.
El primer enfoque consiste en usar un tamaño fijo de tabla de páginas. En este caso se requiere un bit válido en
cada palabra de la tabla de páginas para indicar si una dirección de la tabla de páginas es correcta. El otro enfoque
de control de acceso a la memoria consiste en usar una tabla de páginas de tamaño variable. En este caso, se tiene
un registro de longitud de la tabla de páginas. Con un solo rastreo de reubicación se tenía un registro que
especificaba la longitud del proceso en la memoria principal. Es decir, contiene la dirección del número de página
más grande para un proceso. Si una dirección generada por la CPU contiene un número de página más grande que
el número en el registro de longitud de la tabla de páginas, el hardware genera un error de interrupción de
direccionamiento.

PROTECCIÓN DE ACCESO A PÁGINAS

La paginación, permite que el SO restrinja los tipos de acceso posibles a las diversas páginas. El hardware puede
fijarse para sólo permitir acceso de lectura a una página, o para ejecución.
TABLAS DE PÁGINAS GRANDES
En máquinas modernas con SO, los programas se están volviendo muy grandes. Esto significa que las tablas de
páginas también son muy grandes. Se ha vuelto cada vez más difícil gestionar
la memoria asignada a las tablas de páginas en sí. Para tratar con estas grandes y dispersas tablas de páginas se han
adoptado varios enfoques.
La primera técnica consistió en hacer una tabla de páginas multinivel. En una tabla de páginas de dos niveles
(Imagen insertada abajo): esencialmente se página la tabla de páginas. La MMU considera la dirección lógica
generada por la CPU como si estuviese compuesta por varias partes; en este caso, tres. Tenemos el desplazamiento
de páginas, que será llevado y usado como el marco de desplazamiento. Consideramos los números de página como
p1 y p2; p1 será utilizado por el hardware para tener acceso al nivel superior de la tabla de páginas. Los bits restantes
del número de página, mostrados como p2, se usan para tener acceso a la tabla de páginas de segundo nivel
seleccionada. Esta entrada es el número de marco para el número de página representado en la dirección original
por p1 y p2 juntas. Este número de marco se usará con el desplazamiento original para tener acceso a la ubicación
de la memoria deseada en la memoria física.
 TABLAS DE PÁGINAS INVERTIDAS
Un enfoque ligeramente diferente al problema de la memoria externa consistió en invertir el problema. La idea era
asignar los marcos físicos en páginas lógicas. La tabla se mantiene en orden a través del número de marco físico. Se
busca en la tabla en sí para encontrar una referencia. Puesto que sólo hay una tabla, los números de página de los
diversos procesos no son suficientes para especificar el mapeo. El tiempo para buscar una tabla de páginas invertida
a menudo es más lento que para una tabla de páginas normal. El SO puede acelerar esta búsqueda al usar una
función hash o de distribución para tener acceso a la tabla. Dependemos bastante de la búsqueda en TLB. Las tablas
de páginas invertidas requieren mucho menos RAM que las tablas de páginas normales.

TABLAS DE PÁGINAS CON MÚLTIPLES TAMAÑOS DE PÁGINA

En sistemas posteriores se volvió común tener más de un tamaño de tabla de páginas. La razón de esto es que el
núcleo del SO puede mapearse en la tabla de páginas. La mayor parte de las páginas del núcleo serán las mismas
en todo proceso; nunca se mueven de su lugar, causan fragmentación y siempre están ahí, de modo que no es
necesario dividirlas en páginas pequeñas. Algunas veces las páginas ni siquiera están en la memoria. Este no suele
ser el caso con el núcleo. En consecuencia, tener una sola página para mapear el núcleo es una gran ventaja puesto
que puede fijarse y manipularse más fácilmente y sólo se requiere una entrada del TLB para mapearlo.
SEGMENTACIÓN
La segmentación sería una pista de desarrollo diseñada principalmente para ayudar a resolver los mismos
problemas que solucionaba la paginación, además de algunos otros. Esta técnica se denomina segmentación. La
segmentación surgió de la observación de que un programa puede considerarse como si estuviese compuesto por
varias partes. Se tiene una rutina principal y a menudo se cuenta con subrutinas y funciones que son reconocidas
por el compilador como elementos por separado. Algunas veces se compilan por separado y se colocan en
bibliotecas.
Cada una de estas partes puede considerarse independiente de las otras y puede tener un espacio de direcciones
lógicas por separado. Consideramos que el espacio de dirección está separando en: número de segmento (s) y un
desplazamiento (d). Con la segmentación tenemos un número más o menos pequeño de segmentos, cada uno de
los cuales puede ser razonablemente grande en sí, de modo que el número de segmentos en general es un número
más pequeño de bits y el desplazamiento dentro del segmento es de tamaño más grande. Normalmente el
programador no ejerce ningún control manifiesto sobre la segmentación. Los compiladores generan segmentos por
separado para las porciones más importantes del módulo que se está compilando, y colocan referencias simbólicas
en los módulos de objeto. El ligador asigna número de segmentos reales para ser usados cuando se combinan los
módulos objeto en el programa binario ejecutable y para que el SO los use cuando se cargue dinámicamente
módulos de bibliotecas.

La subrutina usará la entrada de la tabla de segmentos especificada por el número en la parte del segmento de la
dirección. Tomará el apuntador que se encuentra en esa entrada de la tabla de segmentos y lo añadirá a la parte
de desplazamiento de la dirección lógica. Hardware de paginación sustituyó el número de página con un número
de marco.
Puesto que los segmentos son de variable, también pueden ubicarse en cualquier parte, de modo que para obtener
la dirección de la memoria física usamos el apuntador de la tabla de segmentos más el desplazamiento.. Así, los
sistemas con segmentación también usan TLB para acelerar el acceso. Esta no es una solución óptima para evitar
fragmentación externa. Sigue siendo necesario seguir la pista de los huecos de la memoria. En consecuencia, se
tendrá algo de fragmentación interna. Pero ahora la variación del tamaño de los huecos es menor que la variación
que se tenía que considerar al seguir la pista de procesos enteros. En consecuencia, tendremos menos problemas
con fragmentación externa.
Puesto que los segmentos son de tamaño variable, es necesario contar con un mecanismo para que el sistema
verifique las direcciones de modo que sea posible tener la certeza de que el proceso no se está direccionando fuera
de los límites del segmento. Es posible incrementar la protección que se está proporcionando al sistema al limitar
los tipos de accesos que se hacen a los diversos segmentos. Cada segmento es común tener un conjunto de
banderas grandes que controlan los tipos de accesos que pueden hacerse.
En algunos SO es posible que los procesos compartan segmentos. La gestión de los número de segmentos a través
de múltiples procesos puede ser bastante engorrosa para el SO. Los programadores de lenguajes de alto nivel en
general no están enterados de que un SO está usando segmentación. Los programadores en lenguaje de nivel bajo
deben estar enterados de
la segmentación y la forma en que el SO la usa y pueden controlar la segmentación en caso necesario.
SEGMENTACIÓN CON PAGINACIÓN
Hay una diferencia fundamental entre paginación y segmentación. La paginación es transparente para el proceso
en ejecución. Un programa de aplicación que fue creado para su ejecución en un SO donde el proceso asignado es
una gran partición única puede ejecutarse sin modificación en un sistema que use una arquitectura de memoria
paginada. La segmentación, por otra parte, requiere que de alguna manera los programas estén estructurados de
modo que puedan dividirse en partes lógicas con diferentes espacios de dirección. Con un diseño de hardware
idóneo es posible ejecutar una arquitectura de programa segmentado en combinación con una arquitectura de
memoria paginada.
Hay dos formas en que es posible combinar segmentación y paginación. En el primer diseño se tiene una tabla de
páginas para cada segmento, en lugar de una sola tabla de páginas para el proceso.

El segundo diseño sigue habiendo una tabla de segmentos pero, en lugar de apuntar a tablas de páginas separadas
para cada segmento, las direcciones en la tabla de segmentos están dentro de un espacio de dirección lineal, que
luego se mapea a la memoria física de la misma manera en que funciona un sistema paginado.
La mayor parte de los SO modernos usan este último mecanismo de una u otra forma aunque limitan el uso de los
segmentos. Los segmentos se usan para restringir el direccionamiento y controlar el acceso.

→ → PAGINACIÓN POR DEMANDA

A medida que los programas se ejecutan no requieren tener acceso aleatoriamente a las direcciones en todo su
espacio de direcciones lógicas. A las instrucciones en el segmento de código se accede secuencialmente, de modo
que para alrededor de mil instrucciones podría accederse a una sola página en la porción del código del espacio de
direcciones lógicas. O bien, el programa podría entrar en un bucle, algunas veces durante un largo lapso y
permanecer en una sola página de código. Cuando dividimos la ejecución de un programa en pequeñas porciones
de tiempo, normalmente encontramos que el proceso sólo accede a unas cuantas páginas en cualquier porción de
tiempo dada. Este fenómeno es muy importante en el diseño del SO. Denominado localidad de referencia.
El truco para aprovechar este fenómeno se denomina paginación por demanda. Se modifica ligeramente el
significado del bit válido en la tabla de páginas. Ahora el bit indica que no hay marco asignado a esta página. Cuando
cargamos la primera página fijamos su bit válido en verdadero para indicar que está en la memoria. Marcamos el
bit válido de cualquier otra página para mostrar que está página no está en memoria. Luego se inicia la ejecución
de un programa. El SO puede conectarse con el proceso en la memoria y dejar que el mecanismo de fallo de página
traiga incluso la primera página del programa. Esto se denomina carga perezosa.

Si la referencia es una página que no está en el espacio de direcciones lógicas del proceso, el programa ha cometido
un error y se origina una excepción de direccionamiento, con lo cual es muy probable que aborte el proceso.
Si la dirección que ha provocado un fallo está en el espacio de direcciones lógicas del proceso, simplemente la
página no se ha asignado en la memoria física, ya sea porque nunca ha sido llevada a ésta o porque ha sido sacada
de ahí. Esta condición se denomina fallo de página.
→ EAT CON PÁGINA POR DEMANDA
Consideremos lo que ocurre cuando tenemos acceso a una página que no está en la memoria. Nuestro tiempo de
acceso efectivo consta de cuatro componentes.

La tabla E/S del disco rebasa ampliamente las velocidades de la memoria. Esta dominación conduce a varios
mecanismos que parecen complicados que se han desarrollado simplemente para evitar efectuar una operación de
E/S en un sólo disco para paginación por demanda.
→ EL CONJUNTO DE TRABAJO Y REEMPLAZO DE PÁGINA
A medida que se ejecuta un programa, este hace referencia a algún conjunto de páginas, este grupo al que hace
referencia un proceso en un breve lapso se denomina conjunto de trabajo. Este conjunto se mide sobre un intervalo
fijo denominado ventana deslizante. Resulta normal encontrar que un proceso tiene varias páginas en la memoria
a las que ya no hace referencia. Lo que sería lógico es identificar esas páginas y eliminarlas de la memoria una vez
que ya no sean necesarias. Desafortunadamente, el no haber referenciado alguna página durante un tiempo no
significa que la siguiente instrucción no lo haga. Por suerte, eliminar una página que será necesaria más tarde no
causa ningún problema, sólo que no es eficiente, la siguiente referencia a la página originaria sería un fallo de página
, de modo que la buscaría de nuevo.

Existe una estrategia de reemplazo muy simple:

● FIFO (primera en entrar, primera en salir): El SO mantiene una cola con los números de páginas de acuerdo a
cómo estas van entrando para cada proceso y simplemente se expulsa la más antigua. El algoritmo es de baja
sobrecarga (poca carga de parte del SO), es barato y fácil de comprender e implementar.
● Algoritmo de reemplazo de página óptimo: Cuando es necesario reemplazar una página, el SO sustituye la página
cuyo uso siguiente será el más alejado en el futuro. Imposible de implementar ya que necesita saberse si una página
será usada en un futuro.
● Página menos usada recientemente: Se establece la hipótesis de cual pagina es la que tiene mayor probabilidad
de no ser usada nuevamente, de modo que se la quita. ● Algoritmo del reloj: Es el más sencillo, el hardware puede
asegurar cuando se hace referencia a una página, en una entrada de la tabla de páginas se establece un bit,
denominado bit de referencia a la página o bit de acceso o bit de uso, el hardware verifica ese bit. Si ya está
establecido, no se hace nada. Caso contrario es encendido. El SO puede limpiar estos bits para las páginas que están
actualmente en memoria.

El hardware enciende a los bits para todas las páginas a las que se está haciendo referencia. Cuando se requiere
hacer una página se busca en la tabla y si se encuentra una página con un bit válido encendido y un bit de referencia
que se limpia, podrá ser reemplazado.
→ PÁGINAS SUCIAS
Cuando una parte de un programa se carga en una página y se sustituye por otra cosa, no es necesario guardarlo,
porque es posible volver al programa original y obtener la página se de nuevo se hace referencia a ella. Sin embargo,
si una página contiene datos y se ha modificado parte del contenido, entonces no es posible reemplazarla.

Las páginas que han sido modificadas se denominan páginas sucias, las cuales se escriben en un sitio especial del
almacenamiento secundario, denominado archivo de intercambio (swap) o almacenamiento de respaldo (backing
store). En consecuencia, este archivo de intercambio
actúa como una extensión de la memoria primaria del sistema, dando origen a la expresión memoria virtual.
→ MÁS ALGORITMOS DE REEMPLAZO DE PÁGINAS
● Algoritmo de segunda oportunidad: Modificación del algoritmo de reloj, busca a través de la tabla de páginas, si
el bit de referencia está establecido, entonces lo limpia. Actualiza los bits de referencia. A medida que se desplaza
a través de la tabla, si no encuentra ninguna que esté libre en la primera revisión, encuentra algo en la segunda.
Las operaciones de fondo son tareas que se efectúan cuando en el estado de listo no hay procesos de alta prioridad.
Así, las instrucciones que se ejecutan en una tarea de fondo no lo hacen a costa del proceso de cualquier usuario,
de modo que son más o menos libres.
● Algoritmo no utilizado recientemente (NRU) o Algoritmo no utilizado (NUR): Las páginas se dividen en cuatro
clases según las posiciones de estos dos bits: ○ Limpio y sin referencia
○ Sucio pero sin referencia
○ Limpio pero con referencia
○ Sucio con referencia
En la primera clase se busca encontrar páginas sin referencia y limpia para poder usarse de inmediato. Si no se
encuentra, vuelve a buscarse de nuevo en la clase dos y así sucesivamente.
→ CUANTAS PÁGINAS PARA CADA PROCESO?
Podemos estudiar programas en ejecución en un sistema prototipo y fijar algún límite arbitrario. Pero si no se
cuenta con los suficiente procesos en ejecución para llenar con páginas toda la memoria, se producen fallos de
páginas cuando no se las desea. Por lo que no es buena idea. Es posible hacer que el sistema sea un poco más
dinámico.
● Asignación equitativa: Dividir el número de páginas disponibles entre el número de procesos en ejecución.
● Asignación proporcional: Deducir que programas puedan utilizar más páginas comparar sus tamaños.
→ BALANCE AUTOMÁTICO DEL LÍMITE DE PÁGINAS
La mayor parte de los SO usan este mecanismo. Alguno de estos son variantes del algoritmo de la frecuencia de
fallo de página y depende de la idea de que la tasa de fallo de un proceso es un buen indicador de si se tiene el
número correcto de páginas. Si hay muy pocas páginas, la tasa de fallo de página aumenta rápidamente. Si no se
está generando ningún fallo, también puede tener páginas en la RAM que no se utilicen. Este mecanismo establece
un límite superior y un límite inferior para la tasa de fallo.

Este mecanismo tiende a mantener a todos los procesos del sistema que están ejecutándose a una tasa de fallos
de página semejantes y sólo asigna tantos marcos a un proceso como sea necesario para permanecer en ese
intervalo.

→ Hiperpaginación
La hiperpaginación es un fallo generado por la sustitución de páginas en un proceso ya asignado dando
como consecuencia poco trabajo real y reflejando en el sistema una excesiva cantidad de E/S en el disco.
Si la suma de los conjuntos de trabajo de todos los procesos en ejecución es mayor que la memoria
principal real, todo el sistema dedica más tiempo reemplazando páginas que el que dedica para la
ejecución de procesos y entonces se dice que el sistema está efectuando hiperpaginación.
→ Bloqueo de la Página
Un SO que está haciendo paginación por demanda debe permitir que una aplicación asegure una página
de modo que el mecanismo de paginación no la seleccione.
→ Mecanismos de Página Limpia
Para el reemplazo resulta importante usar una página limpia, en lugar de una sucia, para que ésta no
tenga que ser escrita en el archivo de intercambio.
Podemos reducir el impacto de usar una página sucia al mantener disponible para su uso un grupo de
marcos libres que estén limpios. Cuando el algoritmo de reemplazo de página selecciona una página sucia
para esta acción, el SO puede usar uno de los marcos limpios del grupo de marcos disponibles. Luego, en
el fondo, el contenido de la página sucia suele escribirse fuera del disco. Cuando la página está limpia, el
marco puede colocarse en el grupo de marcos disponibles.
Otra tarea que es posible efectuar en el fondo es limpiar páginas que estén sucias.
→ Diseño de Programas y Tasas de Fallo de Página (11.5.10)
(No le encontré nada importante)

→ → Temas Especiales de Gestión de la Memoria

→ Distribución de la Memoria entre Procesos
Tanto la paginación como la segmentación permiten que porciones de la memoria sean compartidas entre
procesos. Con esto se pueden lograr grandes ahorros de la memoria.
El mecanismo copiar al escribir consiste en compartir todo el espacio de dirección física entre dos
procesos, pero a medida que se ejecutan, los cambios hechos por un proceso no son vistos por el otro.
→ Archivos Mapeados en Memoria
La mayor parte de los SO modernos permiten un modo especial de distribución de la memoria
denominado archivos mapeados en memoria. En este modo un proceso solicita al SO abrir un archivo y
asociar todos los datos o parte de ellos en el archivo con una región del espacio de direcciones lógicas del
proceso. Luego, el proceso puede referir la información en ese espacio como un arreglo o a través de
apuntadores de memoria. Este sistema cuenta con dos ventajas principales. La primera es que el proceso
no tiene que usar declaraciones de E/S para tener acceso a los datos; el sistema de paginación por
demanda se hace cargo de tener acceso a los datos idóneos desde el archivo. La segunda ventaja es que
dos o más procesos pueden pedir al SO acceso al mismo archivo al mismo tiempo. Los mismos marcos de
la memoria se asignan a los espacios de direcciones lógicas de ambos procesos, permitiéndoles compartir
el acceso a la memoria.
ElMasri CAP 5.1 a 5.10 ( MacOS )

EL SISTEMA OPERATIVO MACINTOSH SISTEMA 1

La GUI
El sistema 1 tenía una zona de escritorio, ventanas, iconos, un ratos, menús y barras de desplazamiento. Podías
borrar artículos al arrastrarlos y dejarlos caer en la papelera. La pantalla solo era blanco y negro y contaba apenas
con una resolución de 520x342pixeles de modo que las graficas eran bastantes limitadas. Al tratarse de una GUI y
no de una interfaz de línea de comandos, se hacia mas amigables a los usuarios.
 La GUI es la cuestión más
importante sobre el SO porque hacía carecer de soporte. TAREAS ÚNICAS
Para ese entonces Apple decidió sacar la multitarea que había usado con Lisa ( la que falló por sus altos costos ).
Aun cuando una ventana de aplicación no ocupará toda la pantalla, en un principio el SO Mac no permite la
ejecución de más de un programa a la vez, ni para impresión de fondo. Para permitir algo de funcionalidad paralela,
el SO incluyó accesorios en el escritorio como calculadora, un reloj de alarma, un sistema de panel de control y un
bloc de notas, estas aplicaciones estaban cuidadosamente limitadas que no consumieran demasiada RAM. Estaban
implementadas como “controladores de dispositivos” más que como programas por separado y eran capaces de
abrir una ventana única. La sig fig nos muestra el panel de control que permite al usuario cambiar muchas
disposiciones del sistema. Este contaba con una aplicación llamada Finder que se usaba para encontrar archivos en
el sistema. La ventana del finder era el procesador de comandos, osea la consola de línea de comandos ( en otros
SO ). La versión del sistema 1 se denominaba Finder Única porque sólo un programa de aplicación se ejecutaba a la
vez.

ALMACENAMIENTO
SECUNDARIO
Vimos que en CP/M los programas se guardaban en una unidad de disquete única y se cargaban en RAM cuando
iban a ejecutarse. El sistema de disco disponible en las Mac era solo de 400 kbytes. Este era un espacio chico para
buscar archivos fácilmente, de modo que todos los archivos se guardaban en un único directorio, además de esto
los desarrolladores agruparon todos los archivos parecidos entre sí en carpetas en el disco. Esto permitió que los
usuarios pudieran buscar dentro de las carpetas y anidar las mismas dentro de otras.

GESTIÓN DE LA MEMORIA

Sabemos que el SO Mac tiene un espacio de direcciones único, se dice que esta arquitectura es plana, lo cual quiere
decir que en cualquier instante cualquier instrucción puede hacer referencia directamente a la memoria. En este
SO no hay protección de la memoria, de modo que cualquier programa puede modificar cualquier cosa en ella,
incluyendo el SO en sí. Además el código de la aplicación se ejecuta en modo supervisor, por lo que no existe
protección de instrucciones para limitar lo que puede hacer la aplicación. El tamaño de espacio de direcciones es
determinado cuando arranca el SO. Una partición del sistema ocupa la parte inferior de la memoria. Esta área
contiene algunos valores globales del sistema a los que las aplicaciones no deben acceder directamente. En vez de
lo anterior deben usar las interfaces de programación de aplicaciones ( API ) del SO para leer y manipular cualquier
dato del sistema. Pero sin protección de la memoria o de las instrucciones no hay nada para prevenir a una
aplicación de tomar un atajo y acceder directamente a tal información.
Se asigna una partición de la aplicación desde la parte superior de la memoria hacia abajo. En la parte superior hay
un bloque de datos de tamaño fijo llamado A5 World que contiene los datos estáticos de la aplicación y algunos
metadatos sobre ella. Debajo está la pila con su parte “superior” creciendo hacia abajo. El montículo crece desde
el fondo de la partición de la aplicación hacia arriba, e incluye segmentos de código. Así un problema que debe
manejar el SO es asegurarse de que estas dos áreas no queden una junto a la otra.

ROM
En la mayor parte de las PC solo se usaba una ROM para contener el código de POST ( power-on self-test ) y algunas
rutinas de BIOS. La ROM del Mac contenía mucho del SO actual ya que era mucho más grande que los otros SO. El
objetivo inicial de contar con tanto código en la ROM era evitar llenar el almacenamiento limitado disponible en un
disquete, dado que las primeras Mac no tenían disco duro. También ayudaba al sistema arrancar más rápido, ya
que no era necesario leer ese código desde la unidad de disquete. Esta arquitectura ayudó a asegurar que solo las
PC de Apple y clones autorizados pudieran ejecutar el SO de Mac y evitar clones truchos.
SISTEMA 2
Este aparte de ser una versión mayor, carecía de características importantes desde el punto de vista teórico. El
finder era algo más rápido. Se eliminaron ciertos iconos/comandos y se añadieron otros para crear una carpeta
nueva, así como para apagar el sistema. Ahora los disquetes podía expulsarse simplemente al arrastrar su icono a
la papelera, en lugar de seleccionar el comando EjectDisk y luego arrastrarlo a la papelera. Al escritorio se le agregó
el accesorio Choose Print, que permite que el usuario escogiera una impresiona por defecto.
Esta utilidad más tarde se volvió el Chooser, una utilidad para acceder a recursos compartidos como impresoras,
módems y volúmenes de discos alojados en otros sistemas y puestos a disponibilidad a través de una red.
GUI
A los usuarios les agradaba la GUI y la capacidad de copiar y pegar información de una aplicación a otra. Pero esto
significaba cortar los datos de un programa, detenerlo, iniciar el nuevo programa y luego pegarle los datos, una
operación que normalmente se hacía en minutos, en cada nuevo modelo de Macintosh se incluyó más RAM que en
los anteriores y contiene 4 veces más RAM que la Mac original. Esto era suficiente para hacer posible alguna forma
de multitarea. Primero se implementó en el programa swit-cher, que permite que un usuario inicia varios
programas. Luego el usuario podía cambiar entre estas aplicaciones al hacer clic en un icono sobre la barra del
menú. La aplicación que se estaba utilizando se deslizaba horizontalmente de la vista y aparece la siguiente. Cuando
un usuario cambiaba a uno de los programas en ejecución se decía que “tenía el foco”. Así, el usuario podía cortar
y pegar entre aplicaciones en segundos, en lugar de hacerlo en minutos.
MULTITAREA
Switcher creó varias ranuras fijas en RAM, en las que se cargaban las aplicaciones. El programa switcher asignaba
un montículo por separado para cada aplicación que iniciara el usuario obviamente sujeto a la disponibilidad de
memoria. Cuando el usuario activaba o desactivaba una función con la misma tecla de un proceso a otro, el
programa switcher podía realizar un interruptor de contexto y arreglar la gestión de datos del SO de la memoria de
modo que el SO podría empezar a trabajar con la nueva aplicación. Pero como no había protección de la memoria
o de las instrucciones, el switcher podía ajustar las estructuras de memoria del SO para afectar al interruptor. A
todo esto, está multitarea era muy limitada, en el sentido que aún había un proceso en ejecución a la vez. El usuario
podía cambiar de un proceso a otro, pero mientras un proceso no tenía el foco no estaba en ejecución realmente.
A pesar de este inconveniente, este enfoque funcionó con el esquema existente de gestión de memoria, ya que no
se requería cambiar los programas con switcher para trabajar. Los cambios también eran transparentes para el
núcleo del SO.

SISTEMA 3
SISTEMA DE ARCHIVOS JERÁRQUICO ( HFS )
Como sabemos, las unidades disco iban creciendo en consecuencia había más cantidad de archivos, así que se
estrenó un nuevo sistema de archivos HFS. Este reemplazó al sistema de archivo Macintosh MFS. Las carpetas eran
verdaderos subdirectorios en lugar de etiquetas en las entradas de los archivos y podían contener otras carpetas.
Fue mucho más útil que se denominó sistema estándar de archivos del SO Mac. Las entradas del directorio
contenían marcas de tiempo que mostraban cuando se había creado el archivo y cuando se había modificado, el
tipo de archivo y los códigos de su creador y otros metadatos del archivo. El espacio libre era seguido por un mapa
de bits y los directorios se almacenaban como árboles binarios.
REDES
Las redes de área local (LAN) se volvieron populares, pues permitían el acceso compartido a dispositivos costosos,
como grandes unidades de disco, impresoras láser de alta gama, grupos de módems, etc. También facilitaban la
comunicación a través de archivos y directorios compartidos en servidores centrales. Así Apple agregó soporte para
AppleShare, un protocolo registrado para compartir archivos. El protocolo de la pila también incluye tecnología
registrada en otras capas: AppleTalk en redes y LocalTalk en las capas de enlace de datos y física. Entonces Chooser
adquiere mucha más importancia que solo la selección de impresoras por defecto.
SISTEMA 4
Este sistema se introdujo con el SO Macintosh y Macintosh 2. Este sistema agregó soporte para unidades disco
mayores que 32 Mb.
En este sistema el SO Mac posibilitó una versión del Finder que pudiera lanzar múltiples aplicaciones. Apple lanzó
en el SO dos opciones Finder y Multifinder, pero como este último era nuevo y Apple no estaba seguro de que todos
los programas pudieran operar bajo este, finder continuo distribuyéndose con el SO.

MULTIFINDER
Cuando el SO implementó el multifinder, los usuarios podían cambiar entre finder, que admitía sólo un programa
a la vez y multifinder que podía manejar múltiples programas. A diferencia de switcher que simplemente cambiaba
el SO de la ejecución de una aplicación a la ejecución de otra, multifinder permite que cada programa continuará
su ejecución, dando a cada una tiempo de la CPU. El SO Mac no fijaba límites establecidos respecto al tiempo que
un proceso podría continuar su ejecución sin cambiar a otros procesos. La técnica que usaba se denominaba
multitarea cooperativa. Con esta técnica, un proceso podía ejecutarse el tiempo que quisiera. Si el proceso hacia
una llamada al SO que este no podía atender de inmediato, como la lectura de un disco, entonces hacía esperar al
proceso, mecanismo denominado bloqueo. Cuando un proceso lleva a cabo un bloque de proceso así, entonces el
SO añade el proceso bloqueado a una cola de procesos que están en espera de algo y cambia a la ejecución de otro
proceso. Si un proceso no hace llamadas de bloqueo, entonces puede ejecutarse tanto como quiera. A fin de que
todos los procesos proporcionen una pronta respuesta a las solicitudes de los usuarios, todos requieren algo de
tiempo de la CPU. Así si un proceso se ejecuta durante mucho tiempo, puede hacer que el desempeño del sistema
sea desparejo. Para evitar eso, se supone que todos los procesos hacen una llamada especial al sistema a menudo
para indicar al SO que el proceso aún no termina pero que está renunciado voluntariamente al control y que está
listo para ejecutarse nuevamente. Esto permite que los demás procesos compartan de una manera justa el tiempo
de la CPU.
LA GUI BAJO EL MULTIFINDER
Multifinder contaba con una forma para la coexistencia de ventanas de aplicaciones distintas por medio de un
modelo por capas. Ahora que era posible tener múltiples aplicaciones en ejecución, cada una podía tener abierta
múltiples ventanas en el escritorio al mismo tiempo. Cuando un programa obtiene el foco, todas sus ventanas eran
traídas hacia delante en una capa. Esto era necesario para efectos de compatibilidad con ventanas de la interfaz
del programa de aplicación (API) existentes.
GESTIÓN DE RAM CON MULTIFINDER.
Multifinder también contaba con un mecanismo para que las aplicaciones comunicaran sus requerimientos de
memoria al SO, de modo que pudiera asignar RAM a cada programa según sus necesidades. Lamentablemente la
cantidad específica podría no ser suficiente para algunas tareas, de modo que al usuario se le proporcionaba una
interfaz para sobreescribir ese número. A menudo a un programa se le otorgaba más memoria de la necesaria, y a
otro se daba demasiado poco, como resultado, la aplicación poco alimentada de memoria podía desempeñarse
defectuosamente. Cuando se ejecutan múltiples aplicaciones, la gestión de RAM suele ser mucho más complicada
que cuando se ejecuta una sola aplicación. Pero cuando se estaba desarrollando Multifinder, una consideración
clave era que los programas que corrían bajo finder debían trabajar sin cambio bajo multifinder. Así la arquitectura
de memoria es bastante semejante, aunque ligeramente más complicada. A medida que la ejecución se desplaza
de una aplicación a otra, el SO modifica el contenido de ciertas variables del sistema a fin de reflejar los tamaños y
las ubicaciones de la partición de la aplicación y sus partes para nuevas aplicaciones. Este cambio se denomina
intercambio de contexto.
SISTEMA 5
Algunas referencias dicen que el sistema 5 nunca fue lanzado, se reconoce como sistema 4/5 y otras afirman que
se lanzó por un tiempo nomás, pero no hay nada importante en este sistema para efectos de estudio de evolución
de SO.
SISTEMA 6
Este sistema fue la primera actualización verdadera del SO Mac. La RAM estaba siendo más barata y más grande y
los usuarios siempre querían más de ella. Así el sistema 6 comenzó la migración para manejar la Mac en modos
verdaderos de direccionamiento de memoria de 32 bits que ya habían aparecido con la CPU 68020 de Motorola.
Estas direcciones de 32 bits permitieron que la Mac pudiera manejar hasta 64Gb de RAM. Versiones anteriores
usaban los 24 bits inferiores para direccionamiento y los 8 superiores para banderas que indican por ejemplo que
el bloque al que se apuntaba estaba marcado como “bloqueado”, etc. Había sido esto una solución efectiva para
hardware anterior con RAM limitada, pero después se volvió un estorbo. Apple se refería a un código que usaba el
modelo de direccionamiento 24+8 bits como no limpio de 32 bits y sugiere que los desarrolladores eliminaran este
código de sus aplicaciones. Sabemos que mucho del SO Mac estaba en ROM. Pero lamentablemente mucho de ese
código ROM no era limpio de 32 bits, de modo que las Mac anteriores no podían migrar a este nuevo modo. El
nuevo modo requería nuevas versiones de hardware. El cambio al modo de direccionamiento de 32 bits facilitó
multitud de cuestiones que persistían incluso hacia versiones actuales del SO Mac. El SO mantiene la capacidad de
ejecutar aplicación en un modo de 24 bits aunque es mucho más lento que el modo de 32 bits.
En ese tiempo la RAM se veía como un recurso muy apretado y querían dirigirse a grandes longitudes para ahorrar
uno o dos bytes acá y allá. Con el transcurso del tiempo, se encontraban tales ahorros de bytes que tuvo un impacto
negativo, el error Y2K (año 200) Pues se acortó el formato de parte de la fecha del año hasta los dos últimos bytes.
SISTEMA 7
Este sistema fue el mayor cambio de software del sistema. Continuó con la migración del SO Mac hasta el
direccionamiento completo de 32 bits y mejoró su manipulación de gráficas, establecimiento de contactos
profesionales y multitarea e introdujo una forma de memoria virtual. Esta versión eliminó la versión del Finder, Así
la multitarea cooperativa se convirtió en el modo normal de operación del sistema. También establecer contactos
profesionales por medio del AppleTalk y compartir archivos mediante AppleShare se integraron al SO en lugar de
ser opciones.
LA GUI
El sistema 7 contaba con varias mejoras en cuanto a usabilidad, muchas en el área de la GUI, en el extremo derecho
de la barra de menús, se agregó uno denominado menú de aplicaciones, que mostraba una lista de programas en
ejecución y permitía a los usuarios cambiar entre ellos. Ahora los usuarios pueden arrastrar y soltar: un bloque de
texto podría arrastrar de un programa a otro con el ratón en lugar de tener que copiar y pegar.
El finder del sistema 7 utilizó características cromáticas e hizo que algunos elementos de la interfaz parecieran más
tridimensionales. Otras características de usabilidad también se agregaron al SO en versiones del sistema 7. World
Script contaba con lenguaje a nivel del sistema para diferentes idiomas además del inglés. También se lanzaron
tecnologías como AppleScript, un macrolenguaje para automatización de tareas, ColorSync,software multimedia
QuickTime y gestión de fuentes TrueType.
MEMORIA VIRTUAL
A veces un usuario quería ejecutar más programas de los que cambian al mismo tiempo en la RAM. O quizá el
programa se usaba con un archivo de datos que era muy grande. Una solución a esto es la memoria virtual o MV.
La MV es una técnica que usa algo de espacio en una unidad de disco duro para simular una memoria RAM más
grande. Para hacer posible el trabajo requiere hardware extra de gestión de la memoria. Poco después la memoria
se divide en bloques denominados páginas. Cuando un programa empieza su ejecución , solo la primera página del
programa se lleva a la RAM. Cuando el programa en ejecución hace referencia a una parte del programa que aún
no está en memoria, el hardware provoca una interrupción llamada fallo de página y el SO lee la página que falta
en la RAM desde la unidad de disco.
Para que el SO pueda admitir MV se requiere hardware especial en un sistema de computo. La computadora debe
tener una unidad de gestión de la memoria ( MMU ) especial capaz de traducir las direcciones lógicas generadas
por el programa en ejecución de la CPU y traducirlas en una dirección física, de modo que las páginas del programa
puedan localizarse en cualquier parte de la RAM. La MV se implementó por primera vez en este sistema 7.
UNA NUEVA CPU
Apple para ese entonces formó una alianza con IBM y Motorola para desarrollar una nueva familia de procesadores
basada en una combinación de la arquitectura de la IBM y la línea de la PC de Intel. Esto se conocería como PowerPC.
La Mac inicial con la CPU PowerPC se proporcionó con el sistema 7, requirió cambios en el diseño del SO Mac.
Una pieza de código doblaba un nanonucleo gestionado por la CPU PowerPC. Se ejecutaba en modo supervisor y
proporcionaba interfaces de bajo nivel para gestión de hardware para el resto del sistema. La API de este
nanonucleo estaba restringida a software y depuradores del sistema. Poseía compatibilidad universal, así el SO era
capaz de comenzar a ejecutarse en los sistemas basados en la PowerPC casi de inmediato.
El principal bus del sistema de Apple se llamaba NuBus, fue desarrollado por ellos a diferencia del bus ISA que tenían
las PCs de otros fabricantes. Para ese entonces Intel desarrolló el bus PCI lo cual fue algo competitivo para Apple
hasta que lo terminó incorporando en las PC Power Macintosh.
MEJORAS DE E/S
Los disquetes de PC IBM y de Mac Apple eran físicamente idénticos, se utilizaban en forma diferente en dos
sentidos, primero , el formateo de bajo nivel es distinto. Este formateo de bajo nivel escribe encabezados en las
pistas, que más tarde indican al hardware donde empieza cada sector, cuáles son los números de la pista y el sector,
y cuál es su longitud.Una vez que se hace el formateo de bajo nivel, el usuario puede dar formato del disquete a un
nivel superior, creando un sistema de archivo vacío en el disco. En caso de IBM y de Mac era diferente, así como el
formateo de bajo nivel. El hecho de añadir al SO Mac la capacidad de leer y escribir en disquetes MS-DOS hizo
mucho más aceptables las Mac en el mundo de oficina, donde el intercambio de archivos fácilmente era una
necesidad.
Las laptops para ese momento incluían una ranura llamada PC Card que permitían la inserción de un dispositivo
que no estaba integrado en la laptop original. Como por ejemplo: tarjetas de redes, controladores para unidades
de disco externas, unidades de disco en sí y tarjetas RAM. Pero una tarjeta de RAM no podría direccionarse como
MP porque la ranura PC Card no estaba
conectada al bus de E/S. Así una técnica común era considerarlas como un tipo especial de unidad de disco y crear
un sistema de archivos en ellas. Puesto que el formato del disquete era idóneo, lo anterior se creaba a menudo con
un sistema de archivos compatible con el MS-DOS ya que entonces también podían utilizarse para mover datos de
las PC con IBM a las Mac, pues el SO Mac también podía leer estos dispositivos. En versiones posteriores del sistema
7 se quería un disco duro en la PC.
SISTEMA 8
El sistema 8 agregó soporte para nuevos modelos Mac con múltiples CPU. Estas máquinas experimentaban mejor
desempeño en un rol de servidores. El soporte en SO modernos para tales sistemas se denomina
multiprocesamiento simétrico o SMP. El SO se ejecuta en cualquier CPU disponible. Esto puede plantear problemas
especiales para el SO porque puede estar ejecutándose en dos o más CPU a la vez. Esto significa que es necesario
tomar precauciones especiales para evitar que haya dos instancias de ejecución manipulando cualquier elemento
de datos al mismo tiempo. Este sistema también introdujo la posibilidad de compartir web personal. Esta
herramienta permitió que los usuarios fueran anfitriones de páginas de la red en sus computadoras.
SISTEMA DE ARCHIVOS JERÁRQUICO PLUS
Con el tiempo los discos duros fueron incrementando de tamaño, pero los sistemas de archivos se habían diseñado
para unidades de disco más pequeñas a fin de ahorrar espacio valioso tanto en el disco como en RAM. Estos
apuntadores no podían direccionar todos los sectores en unidades más grandes, de modo que se inventaron
mecanismos para extender los primeros sistemas de archivos a unidades más grandes. La primera técnica fue
asignar bloques múltiples en lugar de sectores únicos.Si la asignación se hacía con base en dos sectores entonces
el mismo apuntador de 16 bits podía direccionar una unidad de disco de 64Mb. Esto podría aumentarse a cualquier
número de sectores que fuera una potencia de dos. Esta técnica ya se había implementado en CP/M. Pero esta
asignación de bloque tenía algunos problemas, por eso este sistema 8 incluyó una versión mejorada del sistema de
archivos jerárquico denominada sistema de archivo jerárquico plus o HFS +. Usaba un apuntador de 32 bits y era
capaz de direccionar una unidad de disco de 4Gb. Utilizaba un bloque de asignación de 32 sectores y podía emitir
unidades de disco de hasta 127Gb. También permitió que los nombres de los archivos fueran hasta de 255 bytes de
longitud.
OTROS CAMBIOS EN EL HARDWARE
Para este entonces el sistema 8.6 añadió gestión de energía mejorada y mejoró el soporte para nuevas clases de
dispositivos como USB y FireWire
A fin de permitir que una aplicación única use más de una CPU, el sistema 8.6 introdujo la idea de permitir que una
aplicación se dividiera en múltiples hilos de ejecución ( threads) independientes ( denominados tareas en el SO de
Mac ) que luego el SO planifica para ejecutarlos en múltiples procesadores. Apple modificó el nanonucleo para
hacer posible este multihilo. También añadió soporte para que las prioridades se asociaran con tareas. Esto permitió
que la aplicación diseñara algunas tareas como más importantes que otras. Si una tarea había estado esperando
algún evento que había finalizado y esa tarea tenía una prioridad más alta que la tarea en ejecución actual, entonces
el SO se adelanta a la CPU al detener la tarea en ejecución e iniciar la tarea con prioridad más alta.

SOPORTE UNICODE
Apple comenzó a desarrollar un nuevo mecanismo para exhibir otros idiomas diferentes del inglés, utilizando una
norma denominada Unicode – una norma mundial de codificación de caracteres – En comparación con otros
mecanismos más antiguos, este simplifica lo anterior al hacer que el software trabaje con otros idiomas, un proceso
denominado localización.
Al usar esta norma para representar cadenas de caracteres y datos, un programador puede facilitar el intercambio
de datos al usar un archivo binario único para cada código de caracteres posible. Además también admite
numerosos guiones ( script ) usados por diferentes idiomas en el mundo y cubre muchos símbolos técnicos y
caracteres especiales. Unicode puede representar la amplia mayoría de caracteres en el uso de las computadoras.
FIN