Resumen Sistemas Operativos

CAP 1
Introduccion
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. Porporciona interfaces relativamente uniformes para acceder a la amplia
variedad de dispositivos con los que interactua una computadora, desde dispositivos E/S
(impresoras,cámaras digitales) hasta componentes inhalambricos 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 porporcionan diferentes interfaces graficas 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 inersperados,
ej: en juegos manuales a botones cuando presionan todas las teclas.
Vista del Usuario contra Vista del sistema en un SO
Para un Sistema operativo las dos perspectivas mas 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 como los usuarios o los programas​ – los programas son los
usuarios mas 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
telcas, separa algunas teclas especiales como el Shift, y las pone a disposicon 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 ​ describe a quienes escriben programas de aplicaciones
como procesadores de apalbras 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 – esta 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 previlegiadas al sistema.
Los ​administradores del sistema ​ incluyen a los que gestionan facilidades de la comutadora y
por tanto son responsabels de instalar y actualizar el sistema operativo, también son
responsables de crear y mantener las cuentas de los usuarios, asi como proteger el sitema,
deben comprender en detalle como se instala y actualiza el SO, y como interactua con otros
programsa 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 como el sistema operativo proprociona realmente los
servicios, se refiere a los trabajos internos del S.O, 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 esta 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 dispositivio
apuntador se mueve, genera un evento de hardware ​interrupción ​, que manipula el SO, el SO
observa los movimientos del mosue en termino de algunas unidades especificas de hardware,
es decir; las lecturas son en un numero 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 raton es parte del SO, y se denomina ​controlador de dispositivo raton. ​Este
controlador de dispositivo lee la información de bajo nivel del movimiento del raton 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 raton, 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 raton se mueve grandes distancias cada vez mas rápido ,
también el movimiento de pantalla parece mas rápido, entre estas vistas se encuentra la ​vista
del programador de aplicaciones ​¿Cómo obtengo la inf del movimiento del raton a fin de
usuarla y mostrarla en mi aplicación? También otra cuestión es como la inf sobre el
movimiento del raton se presenta al ​programador de aplicacione​s. Esta es la ​vision 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 raton si hay abierta
varias ventas? Pordia ser necesario que los mv del raton permanzcan en una cola si hay
movimientos multiples antes que aplicación los recupere. Los mov podrían incluso perderse si
el SO esta ocupado haciendo otras cosas – por ejemplo cargando una pagina web atravez de
una conexión con la red – y no podría recibir la entrada oportunamente del controlador de
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é
largos 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 minisculas.
En la ​vista del programador de aplicaciones ​, el sistema de archivos es una parte critica
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 ),
manetener parte de archivos abiertos en memoria principal a fin de acelerar el acceso a sus
datos ( envio de archivos a la memoria y almacenaiento 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 sobreescrbiri 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

​ Terminologia básica
El ​Sistema operativo ( o solo sistema ) ​ es una colección de uno o mas modulos de software
que gestionan y controlan los recursos de una computadora u otro dispositivo de computo 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 computo
principal. Discos duros, DVD y monitores de video son dispositivos típicos gestionados por un
sistema operativo, muchos cuentan con una interzas electrónica ( hardware ) especial
denominada ​dispositivo controlador​, que ayuda a conectar un dispositivio o un grupo de de
dispositivos semejantes a un sistema de computo. Alguns ejemplos incuyen 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
lso aglutinante de hardware que contecta todos los dispositivos de hardware del sistema de
computo 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 atravez de su dispositivo
controlador.
Kernel o nucleo ​Se refiere a la parte del S.O que implementa funcionalidad básica y siempre
esta presente en la memoria.
Servicios ​son funciones que el kernel del S.O proporciona a los usuarios, atraves del API
mediante llamadas al S.O. Estos servicios pueden agruparse en forma conveniente en
categorías basdadas 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 nucleo ( 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 I​ nterprete 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 efectural el trabajo, ej: listado de archivos en un
directorio algunas veces es un programa utlidad en si mismo.
​ IMAGENES
La siguiente figura (1.2) es una reperesentacion simplificada de una pequeña computadora
personal (PC) que muesta algunos dispositivos básicos conectados a la memoria de la
compudora y al a CPU.
El programa (o nucleo) del SO incluye varios controladores de dispositivos que manipulan los
periféricos ( dispositivos) del sistema debajo 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, asi como discos, teclados, monitor y otros dispositivos. Controla la
asignación de memoria y el uso de la CPU al decidir que programa ejectuar, 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 hardwar de los
programas.
Esta figura, común para ilustrar los SO, es una representación lógica, no física. Por ejemplo el
nucleo del SO reside fisicamene dentro de la unidad de memoria y corre en la CPU, asi como
las flechas entre el nucleo – 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 circulo exterior representa la
capa utilidades/aplicaciones que accede a la capa del nucleo 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 mas detalles de un Sistema Operativo de una computadora Personal o
PC, El SO tiene dos componentes adicionales que no aparencen 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, Asi el nucleo 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 contruyendo el hardware, y haciendo funcionar programas simples,
normalmente escritos en lenguaje asamblador o en lenguaje maquina, esto era una buena
herramienta para algunas personas, aunque la programación era muy tediosa, la gente
deseaba disfrutar la experiencia de esribir programas mas interesantes y por tanto mas largos
y complicados, Asi requerían mejores herramientas como editores fáciles de usar y
compiladores o interpretaes para el lenguaje de alto nivel, sin embargo para los usuarios
fianles, el deseo era usar la computadora como herramienta de negocios o prodcutividad.
Estos usuarios necesitaban el procesamiento de palabras, hojas de calculo y software de
comunicaciones, se contruian muchos sistemas de hardware para computadora bastante
diferentes. Estos sistemas podían contrar 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 podía tener un dispositivo semejante a
una terminal que estaba conetado a un puerto serie, mientras que otro podía contar con un
controlador de video integrado con muchas capacidades para elaborar graficas avanzadas. Los
teclados podían difrerir típicamente en cuento a los teclas de función o “felcha” o a telcas de
movimiento del cursos, con la adicion o remoción de otras teclas.
A fin de que 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 interzas al hardware para todos los distintos
dispositivos soportados por él. Por ejemplo, un programa podía leer el puslo 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 dividio en una parte que estaba
adaptada a los distintos disporitivoos de hardware ( el BIOS y controladores de dispositivos )
y una parte que permanecia igual para todo el harware ​( la cual se muestra como el nucleo 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.
Asi adaptar un SO a un nuevo sistema de computo compatible con diferentes dispositivos
implicada modificar o escribir un BIOS, pero usando el mismo modulo para el resto del nucelo
y los mismos programas y utilidades. Esto era una idea bastante atractiva para todo el mundo:
usuarios, fabricantes y escritores de SO.
Surgia un problema cada vez que un fabricante de periféricos de computadora ( por ejemplo
fabricante de video de tarjetas ) diseñaba un nuevo dispositivo y deseaba venderlo a los
usuarios a fin de que pudiera actualizar su computadora a diseños mas recientes de hardware​.
A menudo el BIOS existente en la computdora era instalado en la ROM (memoria de solo
lectura ) y su remplazo era difícil y costoso​. La solución a este problema fue la creación de un
BIOS modificable que permitia que los controladores de dispositivos fueran cargables en el
momento en el que el SO se cargaba en la moemoria. Contar con un código BIOS que sea
posible sustituir el arranque del sistema perimite agregar nuevas caracterisiticas 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 ) hubó computadoras mas grandes, fueron
demasiado gigantes y costosas, pimirivas según estándares modernos, y había muy pocos
programadores. Los porgramas 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 maquina de la computadora,
en lenguaje de maquina o asamblador.
Estos programas eran sorprendentes en el sentido de que unos cientos de miles de
instrucciones de maquina lograban una cantidad enormde 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, ejectutar 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 si 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 podí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 ejectuarse en un momento dado. Por lo regular los programadores podían
reservar el uso de la computadora en pequeños blques 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 mas 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 mas durante el
dia.
Los programas una vez escritos y emsamblados se vinculaban o ligaban con rutinas de utlidad
para entrada, salida , funciones matemáticas, formateo de impresión y otras tareas comunes,
en un programa ejectutable listo para cargarse en la memoria y ejecutarse. El porgrama 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,
anque solo podía cargar la primera tarjeta o el primer bloque de la cinta. Asi ese bloque debía
incluir una pequñea 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 especifica, luego debía transferir la ejecución – por medio de una llamda 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
denominada “cagador de arranque”)​. El ​delimitador END​ indica a ese cargador que no hay
mas rutinas a cargar, ya que acontinuacion de las rutinas puede haber registros de datos.
Como los programadres tenían tiempo para desarrollar mas rutinas de utilidad, el cargador
crecio en forma mas 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 crecia 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
desafotunadamente se volvió común dejar caer un mazo de tarjetas o romper una cienta de
papel ). Estos cargadores y rutinas de utilidad se convertirían en el inicio de los primeros SO,
que amenudo se donimaban ​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 asi como una memoria adicional para los datos, las variables
y el amacenamiento temporal del programa.
Estas actividades para asignar la memoria son parte de la ​Gestion de memoria ​que debe
realizar el SO. A menudo varios programas pueden estar en la memoria al mismo tiempo. El
modulo 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 proporcionara a cada uno.
La ​gestión del proceso ​–la decisión de cual proceso ejecutar, durante cuanto tiempo y tal vez
con que 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 del a tecla y luego envie una interrupción al procesador. El
procesador pede 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 esta
ejectuandose. Esto puede hacerse de inmediado si la CPU se encuentra realizando trabajos de
prioridad inferior. O mas tarde si ha estado efectuando trabajos de prioridad superior. Luego ,
el SO inicia una rutinade interrupción del servicio para manipular la ccion 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 procesamiento 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 efectua una operación de salía 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 raton ,para apuntar el menú archivo en
pantalla. El movimiento del raton y los clics en este son manipulados por un controlador de
dispositivo, que sigue las coordenadas del raton y las envía al SO. El icono de seguimiento del
raton ( flecha ) que debe moverse y mostrarse por pantalla. Cuando se hace clic en el botón del
raton, el controlador envía esta información al SO, que transmite las coordenadas donde
ocurrio 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, hara
coincidir las coordenadas del cursor cuando el usuario hizo clic. El sistema de ventanas que
manipula la interaccion 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 emprenda varias acciones. Primero debe abrir el directorio mediante la
recuperación de información que ha en él, apartir de las tablas internas del SO. La información
del directorio incluye los nombresde archivos ( y posiblemente otros directorios ) almacenados
bajo directorio, asi como la ubicaion del directorio en el disco. Luego, el usuario debe escribir
el nombre de un archivo como “recordatori-concierto” y el sistema de archivos comprobara 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 modulo 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.
Apartir de este ejmplo vemos que el SI participa en prácticamente todos los aspectos de
interaccion entre usuario y programa: desde acciones de bajo nivel, como procesar golpes de
teclado y movimientos del raton, 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 Modulos mas importantes del SO

Un papel fundamental del SO es la ​gestión de recusos del sistema

Tipos de recursos gestionados por un SO

Algunos de los recuros por un SO típico son: CPU, Memoria principal y caches, alacenamiento
secundario y dispositivos E/S al nivel mas bajo, asi como el sistema de archivos e interfaces del
usuario a nivel superior. El SO también gestiona el acceso a redes y proporciona seguirdad para
proteger los diversos recursos
​ ​ ​ CPU
El SO necesita planear cual proceso ejecutar en cada CPU en cualquier instante. En sistemas de
proceso único mas antiguos es mas 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 asi 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 multiples porcesos, Ademas pude ser mas complicado si en elsistema hay multiples CPU.
El SO mantiene varias listas de procesos. La cola mas 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 tiene 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 ​Cuanto temporal​. Si el Cuanto temporal expira antes de que el
proceso termine la ejecución, un einterruptor de tiempo puede iniciar un proceso del SO
denominado ​Conmutacion 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 esta lleno, el modulo 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 modulo 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 ultitareas 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 mas 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 modulos 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 capidad de detectar nuevo hardware e instalar
dinámicamente los controladores de dispositivos idóneos. Un controlador de dispositivo
manipula la interaccion 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 E​ l SO gestiona recursos de nivel superior que se
crear por medio del software. Uno de los mas importantes es el ​sistema de archivos​, este
sistema es un modulo 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 interaccion 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, asi como técnicas de seguridad para permitir que los adm del sistema refuercen
sus políticas de seguridad. El tipo de seguridad mas simple es la autorización de acceso
mediante contraseñas, aunque en general no son suficientes.
​ Modulos mas importantes de un SO

En la siguiente figura podemos ver los modulos mas importantes de un SO a un nivel abstracto
( muchos de estos modulos corresponden a los recursos que se estén gestionando).
Los modulos proporcionan funciones a las que acceden usuarios y programas del sistema, asi
como los otros modulos del SO. Se restringe algo de funcionalidad de modo que solo sea
posible acceder a esta en modo privilegiado por otros modulos del SO, por ejemplo: las
funciones de los controladores de dispositivos a menudo están restringidas para el acceso al
SO. Otra funcionalidad esta disponibles para modulos 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 modulos interactúan entre si, esto se debe a que
los tipo de interaccion dependen de la arquitectura particular usuada para implementar el SO.
Por ejemplo, en una ​arquitectura por capas ​los modulos estarían separados en capas, en
general los modulos de un nivel deben llamar a las funciones proporcionadas por los modulos
que están en el mismo nivel o en niveles inferiores. Por otra parte, en una ​Arquitectura
orienda a objetos​ cada modulo esta implementado como uno o mas objetos con servicios, y
cualquier objeto puede invocar los servicios proporcionados por otros, y en una ​Arquitectura
Monolitica ​todos los modulos están implementados como un programa gigante.
​ ​ ​ Definicion 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 esta corriendo o en ejecución, para ser un proceso, un
programa necesita haber sido iniciado por el SO, sin embargo un proceso no necesariamente
esta en ejecución todo el tiempo durante su existencia; puede estar en esepera 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, tambien 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 accedera a archivos, de modo que tal vez tenga asociados con el algunos
archivos abiertos. ​Ademas un proceso también se denomina ​trabajo ​o t​ areas.
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 asi 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 ( exagonos )
representan los ​estados del proceso ​y las ​líneas dirigas ​(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 interativo entra a un sistema de computo, 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 llmaar a la función
de lSO para su creación. Por ejemplo un buscador de la red podría crear un nuevo
proceso para ejecutar un modulo 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 el estado ​nuevo​. El SO debe
elaborar la tabla que contiene información sobre el proceso, asignar recursos necesarios (
memoria ), localizar el archivo ejectuale 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 fig ) muestra que el SO mueve un proceso desde el nuevo estado
hasta el estado ​listo​, lo cual indica que el proceso ya esta listo para la ejecución.Una vez que ha
ocurrido todo este inicio, 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 esta en
ejecución y se encuentra en el estado ​ejecución. ​Si en el estado listo hay mas 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 efectua operaciones de limpieza en el proceso, como borrar la información del
proceso y las estructuras de datos, asi como memoria del proceso y otros recursos, cuando la
limpieza esta lista, pasa a (transición 7 de fig ) lo cual original 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 ocurri si el proceso requiere algún recurso que no esta 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 dedice suspender el proceso debido a que tiene procesos mas urgentes que
ejecutar. Esto puede deberse a un cronometro o algún otro tipo de interrupción, lo cual puede
ocurrir por varias razones. La razón mas común es asignar la CPU a otro proceso debido al
algoritmo de planificación de la CPU.
​ ​ ​ Informacion 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​). Tambien 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 como 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 esta usando el proceso suele mantenerse en una
estructura de datos del SO por separado, que crea y usa el modulo de gestión de archivos de
SO.
La información sobre que áreas de la memoria están ocupadas por el proceso suele
mantenerse en tablas de paginas o registros limite creados y usados por el modulo de gestión
de memoria del SO. Se hace referencia a estas dos tablas desde la estructura de datos del BCP.
Ademas 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 esta ejecutando un programa de contabilidad, una
transacción de base de datos o en un juego de compuitadora
2. Porcesos del programa del sistema.​ Son otros programas de aplicación que efectúan
un servicio del sistema común en lugar de un servicio especifico 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
modulo 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.​ Tambien 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 pivilegiado y el modo regular ( o del usuario ).
Los procesos del nucleo del SO por lo regular se ejecutan en ​Modo privilegiado ​– también
llamado ​modo supervisor, modo nucleo ​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 malisioso 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, asi 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 lso sistemas embebidos.
Existen algunas cuestiones que deben manipular. Los servicios principales que prporciona son
la manipulación de eE/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 asi controla la ejecución simultanea de multiples 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 mas tarde. Basicamente,
cuando un proceso en ejecución – por ejemplo , un proceso A – solicita operaciones E/S que
puede manipular un controlador E/S, el modulo de palnificacion 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 algortimo de planificación del
a 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 esta 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 multiples tareas. Por ejemplo si hay ventanas multiples 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 gcargados 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 atravez del raton, teclado, la pantalla,
y otros dispositivos E/S.
Es posible distintguer aun entre dos itpos de SO multitatarea:
Los que suelen interactúan con ​usuario único ​ y los que adminten ​usuarios interactivos
multiples.​ 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
interactue con el sistema aunque el usuario pueda tener varias tareas que iniciaron a la vez,
cada uno en ventanas separadas. La tarea que constituyte 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 multiples en forma
simultanea, 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
numero de tareas ( procesos ) en ejecución son usuarios que interactúan con la maquina. Estos
sistemas se llamaban asi pues el tiempo de la computadora era “compartido” por los multiples
usuarios simultaneos. En termino 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 interaccion. Pero una respuesta pronta a los requisistos
de los usuarios interactivos demanda un gran nivel de intercambio de contexto, lo cual
introduce bastantes gasstons 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 gast amas tiempo en cálculos productivos. Un SO
de tiempo compartido admite tanto trabajos interactivos como por lotes, y generalmente
porporciona prioridades mas 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 estraban conectados
al mismo sistema mediante monitores y terminales falsos, debido a que en esa época los
terminales costaban varios ordenes ed magnitud menos que el sistema de la computadora en
si.
A medida que el precio del hardware y de los procesadores se reducia 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 contituyen 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,
lo 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 amenudo 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 multiples maquinas, y requiere que el SO proporcione
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
maquinas conectadas
2 –Servicios de alto nivel. ​Los usuarios desean poder conectarse a otras maquinas 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 etrar a maquinas
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 interaccion del usuario. En forma separada de la conexión de
red, un SO distribuido es capaz de proporcionar un amplo espectro de capacidades. Un SO
distribuido es muy básico, también conocido como ​SO de la red​, porporciona la capacidad de
conexión de una maquina en la que esta 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 maquina especifica ala que desea acceder. Los
servicios ​telnet o FTP ​proporcionan este servicio.
Ademas de esto un ​SO distribuido​ puede permitir que un usuario que inicio secion en la
maquina 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 reproducrise
físicamente en multiples sistemas, de modo que el SO pueda escoger la copia que le sea mas
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 maquina que no este muy
cargada al elegir un servidor.
​ SO de tiempo real
Estos son sistemas multitarea que cuentan con el requerimineto adicinal 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: n milisegundos debe completarse en
menos de n milisegundos de smision, en caso contrario seria inútil y podría haber graves
consecuencias, algunos de estos ejemplos son tareas de funciones o en refinicion 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 resptarse 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 nucleo ú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 nucleo o del nucleo monolítico​, ya que el SO con un
nucleo monolítico incluia mas 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 consiederaba 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, mas difícil de mantener, esto condujo a los diseñadores de
SO basdados en un diseño mas modular, ​POR CAPAS.
​ ​ ​ Enfoque por capas del SO
Para este enforque, el SO debía dividirse en modulos que estuvieran limitados a una fucnion
especifica, como planificación del procesador o gestión de memoria. Los modulos estaban
agrupados en capas de abstracción creciente – cada capa proporciona una vista mas abstracta
del sistema y depende de los servicios de la capa que esta 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 asbtracta del resto del SO. Asi, cuando nuevos dispositivos
ingresaron al mercado, fue posible agregar nuevos controladores de dispositivos al nucleo sin
afectar a los otros modulos del SO, que porporcionan gestión de memoria, planificación del
procesador e interfaz del sistema de archivos.
Este enfoque puede extenederse 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 micronucleo en un SO
En el enfoque micronucleo solo se incluye funcionalidad básica (generalmente las interafaces a
los varios tipos de controladores de dispositivos ). Especificamente, el único código en estos
modulos debe ejecutarse en modo supervisor, porque usa recursos previlegiados, como
instrucciones protegidas o accede a la memoria que no esta en el espacio del nucleo. 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. Asi, la teoría del micronucleo es
que los beneficios de este enfoque surgen parcialemnte del hecho de que la cantidad de
código que se ejecuta en modo supervisión es mas pequeña, lo cual lo robustece mas. Tambien
les facilita la inspección de defectos. Asi mismo, el esfuerzo adicional de diseño requerido hace
mas probable que la implementación sea correcta. Finalmente es mas fácil transportar con un
micronucleo pequeño a una nueva plataforma que un nucleo grande, con capas, pero
monolítico. Por otro lado, un micronucleo 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 interrupcione 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 mecanisco que usa un SO para adveritr 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 raton o alguna tecla. Como se puede ver, la mayoría de
estas interrupciones corresponden a alguna acción del hardware. El hardware asoscia con cada
evento de interrupción un numero 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 cierrtas acciones, pero.. ¿Cómo el SO
puede determinar de manera eficiente cual evento de interrupción ha ocurrido y como inicia el
proceso idóneo que atienda esa interrupción?
La técnica normal para la manipulan de interrupciones utiliza una estructura de datos llamada
vector de interrupción​. El vector tiene un elemento por cada numero de interrupción. El
elemento contiene la dirección en la memoria de la rutina que atiende ese tipo de
interrupción. El numero 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 escodigo 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 interrumpio.
Eun 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 necesiar 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 si, 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 ejectua una instrucción de llamada al sistema. Sim embargo, en lugar de
llamar directamente a una sección del código que efectue 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 mecaniscmo 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 da datos comunes que se usan son tablas y colas.
Las tablas se utilizan para almacenar la informacon 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 paginas​, que es usada
para seguir la pista del espacio de direcciones de un proceso cuando el hardware admite
memoria en paginas. El SO mantiene un BCP y una tabla de paginas para cada proceso. Otra
tabla tippica 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 esta ordenada de
alguna forma. Cada recurso que puede compartirse por multiples procesos requiere una cola, a
fin de mantener solicitudes de servicio para ese recurso. Por ejemplo, debido a que multiples
procesos pueden requerir paginas 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 pede mantenerse en
una ​cola de procesos listos.
​ ​ ​ Enforque oriendado a objetos
En este enfoque, cada modulo 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 construrir el SO con objetos ofrece diversas ventanas,
como el encapsulado de estructuras de datos objeto, separando una interza 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 atraves de los métodos del objeto. Esto hace menos probable
que una aplicación pueda usar indebidamente un objeto y provocar asi problemas para otros
modulos.
​ ​ ​ Maquinas 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
Maquina Virtual ( MV ). ​Una razón fundamental de las MV es que permiten que los distintos
entornos de emulación se protejan entre si de modo que la caída en un programa no hace caer
a los demás. El diseño del sistema que esta abstrayendo puede ser un diseño de hardware real
o una maquina virtual de aplicación idealizada.
​ ​ ​ ​ ​ Maquinas virtuales de hardware
En este enfoque un programa o un subsistema de nucleo proporciona una emulación de
software de una maquina de hardware real. Hay dos clases distintas de tal emulación, una en
la cual el sistema de hardware huésped en si esta siendo emulado y otra donde otra CPU esta
siendo emulada.
La emulación de la maquina huestped a menudo se usaba para permitir la ejecución
simulatanea de multiples nucleos de SO. En tales casos, la emulación se efectua por medio del
nucleo de un ​SO Huesped​. Este modelo permite que uno o mas nucleos de SO corran en la
parte superior de la capa de una maquina virtual denominada ​SO Huesped​. La capa MV crea
una interfaz que abstrae el hardware, de modo que cada nucleo cree que solo el esta en
ejecución en el hardware. Los nucleos pueden ser de SO distintos o instancias diferentes del
mismo SO. Una de las dificultades mas importantes en el modelo de MV es crear una MV que
emule en forma precisa al hardware, de modo que los nucleos 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 nucleos).
 ​ ​ ​ ​ ​ Maquinas virtuales de aplicación
Muchas veces, la maquina que se esta emulando no es una CPU real, sino una especificación
de maquina idealizada, diseñada para manejar ya sea un lenguaje especifico o una amplia
variedad de lenguajes Tales sistemas algunas veces se denominan ​maquinas virtuales de
aplicación​. Una MV muy popular es la ​Maquina virtual de Java (MVJ)​, que crea una maqina
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 eulacion de una MV puede ser ineficaz, el código creado para ejecutar una MVA
también puede compilarse en código navito de maquina, a efecto de que se ejecute mas
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 atras
​ ​ ​ COMPATIBILIDAD HACIA ATRAS
Es la capacidad de ejecutar antiguos programas de aplicación en versiones mas 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 ​(INTRODUCCION A PROCESOS)
Recordando.. Una función fundamental de un SO es la ejecución de un programa, y un
porgrama en ejecución se denomina proceso. Un programa es algo estatico. 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 esta ejecutando en otro sistema – el SO
trae ese programa a almacenamiento primario (RAM) y comienza a ejecutarlo. Esta entidad en
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 asi sucesivamente. Tambien 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 co cuando para la ejecución de otro proceso ). Estamos
creando “una cpu virtual” en el sentido de que todo proceso puede acutar como si fuese el
único en ejecución. Puesto que todo este intercambio se efectua entre procesos, cuando
detenemos uno para iniciar otro es necesario guardar el estado del proceso que se esta
deteniendo y restituir el estado previo del que esta iniciando. ( esto supone que el proceso que
esta 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 esta 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 esta 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 mas 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 q ​ ue elimina los estados nuevos y de
salida. Los estados (o nodos) se inidican 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
nuevo,listo,en ejecución, en espera y de salida).
El estado ​nuevo ​representa un proceso que el SO esta preparando en el momento para
ejecutar pero que aun no esta listo. Cuando el usuario indica al modulo procesador de
comandos ejecutar un programa, esté 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
un identificación del proceso, y llenar todos los demás parámetros del otro BCP. Luego, debe
reservar memoria, leer el programa del amacenamiento secundario, etc. Especialmente en un
sistema de multiples 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 esta listo para su ejecución se coloca en el estado ​listo​. Esto se ve como la
transición “1- proceso iniciado”. Al final será sleecciona por el SO como el siguiente proceso a
ejecutar. Luego es ​despachado​( es decir, se coloca en ​ejecución​). Esta transición se inidica por
la flecha identificada como “2-Obtiene tiempo de CPU”. A medida qe 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 asi se mueve al estado de ​espera​, también llamado ​suspendido​. Esta transición se identifica
como “3-Necesita algo”.
Cuando un proceso esta en el estado en espera, tarde o temprano ocurre el evento que esta
esperando el proceso, por supuesto este evento puede no ocurrir jamas, 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 oloca 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 asi.
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,
porvoca que el proceso vaya al estado en espera, y luego al SO lo saca del estado en ejecuion y
lo coloca en listo y permite la realización de otro proceso. Una segunda instancia seeria donde
un proceso con alta prioridad ha estado esperando que ocurra un evento y este ocurre.​ ​Este
SO es por ​Tiempo​.
Si el proceso en ejecución tiene priorirdad mas baja que el que estaba en espera, entonces el
SO puede detener el proceso de prioridad mas baja que el que estaba en espera, en tonces el
SO puede detener el proceso de prioridad mas baja , colocarlo de vueta en el estado listo y
situar el proceso de prioridad mas atla en el estado de ejecución. Este ultimo SO es por
planificación de prioridad
El estado ​de salida​ se reserva para procesos que han sido terminados por el SO. Puede haber
varias varones por las que un proceso llega a este estado. Esta transición se ha indentificado
como “6-Terminado o abortado”. El proceso o el SO han detectado un problema y el proceso
se ha detenido antes de que ocurra mas 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 solcitar al SO que
lo elimine.
El estado de salida es mas 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 distitnto de los demás. El SO
requiere hacer mantenimiento para este proceso, como liberar los recursos que el proceso
pudo haber adquirido y aun no devuelve, asgurar 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, exepto en el estado de ejecución, normalmente puede haber muchos procesos
en cualquier estado, Asi 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
multiples 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)
 ​ GESTION 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 mas 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 que 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 memoria de los procesos. En este caso debe estar preparado
para guardar el contenido actual de la MP en la MS (memoria secundaria) rastrear donde 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 secuncia de eventos que resultan en un proceso de ejecución en la
memoria.
1 –Codificar o escribir el programa ( por lo regular lenguaje simoblico)
2 –Traducir el programa simbolico ( generalmente un ensamblador o compilar, aveces
interprete)
3 –Ligamos o enlazamos el modulo con modulos semejantes por separado
4 –Cargamos el programa en memoria
5 –Ejecucion del programa

Supongamos que estamos creando un proceso que consta de dos modulos. Contamos con un
procedimiento principal que denominamos subrutina XYZ que hemos escrito previamente.
A medida que pasamos hacia modelos mas complejos, la idea es que nos enfocamos es una
cuestión de ​vinculación​ . Vincular es el proceso de determinar en que parte de la memoria
física debe ir la subrutina y de hacer referencia en el punto de la rutina principal hacia
subrutina.
​ ​ ​ VINCULACION EN TIEMPO DE CODIFICAR
En un entorno muy simple como un sistema embebido BIOS muy delgado, podríamos decidir
manualente el sitio en que debe ir cada parte del programa. Podriamos colocar el modulo
principal en la ubicación 100 y la subrtuina XYZ en la ubicación 500. Si codificamos el modulo
principal en lenguaje ensamblador, podríamos inculir una directriz ensambladora comc ​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 modulo principal debemos saber que la subrtuina XYZ estará en la
dirección 500 de modo que en elugar 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 maquina, e incluso los introducían
manualmente en la memoria al manipular interruptores y botones en el panel delantero de las
mquinas. En algunas, había dispositivos periféricos que usaban una dirección de la memoria
fija como bufer, de modo que el programador nisiquiera tenia opciones, el hecho de que los
programadores asignaran manualmente la memoria era algo propenso a errores y consumia
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 modulo objeto
perforado en las tarjetas, cargar el programa ligador en la memoria, alimentar ese modulo
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
maquina que se producia para cada instrucción, lo que permitia a los programadores encontrar
la tarjeta que contenia una instrucción incorrecta, cargarla en la perforado y reparar el
programa al modificar el lenguaje maquina. Desafortunadamente, esa practica continuo
durante algún tiempo, y era propensa a errores. Finalmente el numero 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.
​ ​ ​ VINCULACION 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 impsoible incluir la declaración ORG 100 en el modulo principal. Sim embargo,
quizá no tengamos cuidado respecto a donde termina la subrutina XYZ, de modo que en
nuestra rutina principal usamos el nombre simbolico XYZ. Cuando el ensamblador produce
nuestro modulo 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 ligador procesa nuestra rutina principal, contara con una lista de
nombres que requiere resolver. Entonces comenzara a procesar otros modulos que le dijimos
que incluyera. A medida que incluye estos modulos en el paso de cargar, encontrará en ellos
los nombres que se definiern ahí. En este caso “XYZ” estará definido en uno de los modulos, al
que le dijimos que procesara el ligador. Cuando el ligador supone donde reside el modulo XYZ
en el espacio de direcciones, regresa y liga las referencias en el modulo principal con las
direcciones en el modulo 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 decido colocar el modulo 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 deajr que el ligador decida donde
colocar el modulo lo hace mas sencillo. Sim embargo, pagamos un poco por la flexibilidad
aumentada. En este caso estamos transportando información extra en los moduls bojetos que
define los nombres y las referencias a los nombres, y dedicamos un poco de tiempo extra en el
paso de ligado mientras se efectua la viunculacion. A medida que las computadoras se volvían
mas 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 UNICO
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 medid aque el SO crecia, 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 cambio el enfoque: el SO se
cargaba en la RAM baja y el programa se cargaba arriba de esta. Cuando la aplicación
intentaba carga el programa, si había suficiente memoria disponilble, 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 especifica del SO. Este paso definia 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 est 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 solo ejecutaba un proceso único. El programa ejecutable podía crease para residir
en una dirección particular arriba del nucleo del SO. Ademas, un registro base podía cargase
con una dirección baja que el programa ejecutable no podía redireccionar. Si el programa hacia
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.
​ ​ ​ REUBICACION DINAMICA
Lo que antes se llamaba ​registro base ​ ahora es ​registro de reubicación ​, el valor cargado en el
registro ya no era un limite, en lugar de ello se creo 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 hacia el programa. Ahora el programa no tenia que ligarse cada
vez que cambiaba el SO, puesto que toda referencia a la memoria se reubicaba de manera
automática a medida que se ejecutaba el programa.
 ​ ​ ​ ESPACIO DE RAM FISICO CONTRA ESPACIO DE RAM LOGICO
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 correspondían 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
direcciónes 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
generara direcciones con una dirección baja de cero. Pero cuando se ubico en la memoria, en
realidad cargaba en lad ireccion lógica 10000. El hardware de la dirección de la memroai
reubicaba 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 esta 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 ubicacon 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 inicio,
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 ​superpusieran ​ entre si en la memoria. La parte fundamental del
programa es justo una seria de llamadas a subrtuinas 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 efectue 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
procesara programas fuente mas 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 imprsion 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 intercambar el programa al escibrir 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 mas lento y luego intercambiar de regreso y traer el programa A. algunas
veces el intercambio se denomina ​roll-out / roll-in.
​ MULTIPLES PROCESOS CON UN NUMERO FIJO DE PROCESOS
Sim embargo, la técnica de intercambio no fue suficiente y los propietarios de estas maquinas
querían lograr que se hiciera mas trabajo, asi que empezaron a buscar mas formas

La MP continuaba volviéndose mas barata, de modo que empzaron a pensar en formas para
man tener multiples programas en la MP y ejecutar mas el alternar entre ellos sin intercambio
– donde el intercambio es una operación que requiere muchos recursos – terminaron
dandonse 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. S desplazaron a una organización de la
memoria del SO como la que se muestra en la fig de arriba (a). Al principio el registro base se
había usado para evitar que las apliaciones dañaran el SO. Luego, el uso de este registro se
modifico como un registro de reubicación, esencialmente para resolver el problema del
crecimeitno del SO. Ahora que el SO ejecuta multiples 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 rebuicacion y empieza a ejecutar el segundo
programa (b).
Ademas, había otras aplicaciones en ejecución, asi que era necesario arreglar las cosas de
modo que las aplicaciones no pudieran dañarse entre si. La solución era agregar un registro
limite que pudiera establecer una cota superior mas alla de la cual un programa no puede
direccionar, justo como no podía direccionar mas abajo del establecimiento del registro de
reubicación, este registro contiene el tamaño del programa mas 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
limite superior. Asi como es el caso con el limite inferior, si el programa intenta acceder a la
memoria mas alla del limte establecido por el registro limite, el hardware genera una
interrupción y el SO aborta la aplicación, asi cuando el SO cambia de la ejecuion de un
programa a la de otro, ahora debe fijar tanto el registro de reubicación como el registro limite.
​ ​ ​ FRAGMENTACION INTERNA
Cuando se instala este tipo de SO, el administrador debe decidir cuanta 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 esta en operación, como en los primeros SO un programa podía no usar
toda la memoria. Ahora el SO esta tratando de colocar mas programas en la misma memoria.
El espacio sin usar se denomina ​fragmentación interna​ y se muestra en la sig figura. Podriamos
establecer una o dos particiones pequeñas

Para ejecutar pequeños trabajos rapidos y una o dos particiones mas grandes para las
aplicaciones grandes. Esto haría teneder a minimazar el espacio desperdiciado debido a la
framentacion interna.
​ ​ ​ DISTRIBUCION 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 esta en espera del usuario
en la terminal. En este caso el sistema puede intercambiar el proceso mientras el usuario esta
pensando o tecleando. Cualquier otro proceso podría intercambiarse al almacenamiento
secundario. En el caso de la districuon de tiempo es mas problable que haya varias particiones.
Podriamos 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
fragmentacon interna. En este caso solo teníamos fragmentación en una sola partición. Ahora
tenemos fragmentación interna en todas las particiones. Seria conveniente poder usar alguno
de estos fragmentos. Si ahorramos suficiente memoria, tal vez podamos ejecutar otro
programa y asi mantener ocupada ala CPU.
​ MULTIPLES PROCESOS CON UN NUMERO VARIABLE DE PROCESOS
Una solución parcial a la fragmentación interna cosnsiste en no hacer las particiones de
tamaño fijo o en numero; 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 memroai máxima de MP que necesitara. Cuando empezamos el programa le
asignamos toda esa memoria. Si este intenta usar mas dela 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 quedo donde estaba la apps 2. Ahora quedando un hueco mas pequeño
Pero..Supongamos que el SO tiene otro programa para ejecutar pero hay muchos huecos, que
hueco escoge? El primer algoritmo simplemente consiste en explorar la lista de huecos y usar
el primero que contremos lo suficiente mente grande para ejecutar el programa, este se
denomina ​primer ajuste​; presenta la ventaja de que es siemple pero puede no ser la mejor
opción. Otro algoritmo consiste en usar el hueco mas pequeños que se ajuste al programa,
este algoritmo se llama ​mejor ajuste​ – desperdiciamos la menor cantidad de MP – este
algortimo desafortunadamente requiere explorar toda la lista o mantenerla en orden de
tamaño.
Pero que ocurre si el programa necesita 10MB, se tiene un programa a ejecutar que requiere 8
MB y se tienen huecos de 12 MB y 18 MB , si usamos el hueco de 12 MB entonces quedara 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, asi el sig algoritmo dice que debemos
usar el hueco de ​peor ajuste​, ya que deja el mayor hueco ( y por tnato el mas ú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 ajsute 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 practica 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 inidica que requiere 8 MB, tenemos 10 MB de bloques de memoria libre en
los dos huecos – memoria suficiente para ejecutar este proceso – .Pero la memoria libre no
esta en una pieza, de modo que no podemos ejecutar el programa. Esta situación se denomina
fragmentación externa. ​Recordemos que nuestros porceos son reubicables – pueden
ejecutarse en cualquier parte dela memoria física porque el hardware de la memoria reubica
su espacio de direcciones dinamico en la medida que se ejecutan – Asi 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 dentria 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
ejecutandose en el hueco resultante mas grande. Ese resutlado se muestra en (b). Este proceso
se denomina ​compactación ​.Es posible aprecia que cuando el SO esta moviendo programas en
la memoria no se realiza ningún trabajo en representación de las apps. El SO esta decidiendo
gastar la CPU y el ancho de banda de la memoria para efectos de ejecutar mas trabajos en
paralelo.
Fig compactacion

Ahora podemos apreciar que el hardware de reubicación usa una longitud para un limite
superior en lugar de usar el extremo superior del programa. Si usara la dirección superior
entonces cuando reubicaramos un programa también seria necesario volver a calcular el limite
superior. Este no es un calculo 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,
mas que lógicas. Esto significa que si un proceso tiene E/S pendiente, entonces no es posible
moverlo en la memoria. Asi, los procesos que empiezan E/S deben marcase temporalmente
como inamovibles.
Tambien podríamos sufrir a causa de la fragmentación interna, ya que los huecos pueden
hacerse cada vez mas 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 minima de memoria que el SO
intenta gestionar.
​ ​ ​ CARGA DINAMICA
Con los overlays (superposiciones) no es aconsejable cargar todo el programa en MP al mismo
tiempo. En lugar a ello, el programador decide cuando cargar las superposiciones y cuando
llamar a las rutinas que están en la superposocion. Tambien 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á
jamas se necesite cargarlas en absoluto. En consecuencia, el programa empieza algo mas
rápido. Si mas tarde el programa llama a la rtuina, entonces podemos cargarla en ese instante
y habremos pagado muy poca penalización por la espera.
​ ​ ​ BIBLIOTECA DE ENLACE DINAMICO
Podemos posponer la vinculación aun un paso mas. Podemos aplzar incluso la vinculación de la
subrutina con el modulo principal. En este caso la rutian de biblioteca en si no se vuelva parte
del programa ejecutable. Dejamos intacta la referencia simbolica a la rutina de bilbioteca que
produjo el compilador. Asi como con la carga dinámica, si nunca se hace referencia a la rutina,
entonces no solo no 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 dinamico o DLL. Cuando se hace referencia a una subrutina
en una biblitoeca 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 mas
pequeño, requiere menos espacio en disco y se carga mas rapdio en RAM
● Se tienen muchos programas que usan los mismos modulos de la biblioteca
● Si en uno de los modulos de la biblioteca se corrigio un error fijo, solo se necesita
corregir esa biblioteca encaminándola y cargándola en el sistema, lo que corrigue
automáticamente ese error en todo programa que haga mension de esa DLL
ElMasri CAP 12​ (GESTION DE ARCHIVOS)
SISTEMAS DE ARCHIVOS
Los archivos constituyen una de las abstracciones mas importantes con que cuenta un SO. Los
programadores no quieren pensar en unidades de discos o cualquier otro medio; mas 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 solido. Una de las funciones mas
importantes de los SO es contar con la abstracción de una archivo en almacenamiento
secundario. El contenido de un archivo suele ser significativo solo para los programas de
aplicación. Con esto queremos decir que en general el SO no esta consciente de la estructura
interna de los archivos. Hay unas cuantas expciones, como los programas ejecutables (binarios)
que pueden ejecutar el SO y los modulos 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 ejecutalbes y los
compiladores y emsambladores utilizados para producir los modulos objetos apartir del
programa fuente.
​ INTRODUCCION
Los sistemas de archivos suelen tener diseños por capas, donde cada capa proporciona
servicios ala capa que esta 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​ interactura 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 LOGICA
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 ultimo. 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 direcotrio no podría funcionar en tales
unidades de disco. Asi un desarrollo clave en la organización dela estructura lógica de
los directorios de discos fue permitir directorios multiples. El truco era permitir que los
directorios se refirieran a otros, además de referirse a archivos. Con esta organización
jerarquica 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 manterlos en directorios por separado, sim 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
porporcionar 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 grafica aciclica​ : Con un solo directori estructurado como árbol a

menudo estamos en un dilema respecto a como clasificar algún archivo. Una solución
usada es permitir que los directorios formen ​graficas aciclicas 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 mas 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 refencia 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 FISICA
En sistemas antiguos se prestaba mucha atención a la velocidad para ubscar 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 busuqeda es
simplemente secunecial.
​ ​ ​ OPERACIONES EN DIRECTORIOS
El SO debe atender varias operaciones en diferentes directorios. Podria pensarse que estas
deben ser solo 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 direcotorio o cualquier operación en directorios, en la sig
tabla se muestran el num 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
abiguedad 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 especifico 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 dfe 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 esta en directorio de trabajo actual.
Asi como se muestra en la fig, si el directorio ​W​ fuera el DTA, una referencia al archivo ​S ​se
asuimiria 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. Podria 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 especficos y por tanto no
forma parte de las entradas del directorio. Esta forma colectiva se denomina ​metadatos del
sistema de archivos.
​ METODOS 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 inidica al SO a que
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 numero de parte o un numero de cliente. Estas aplicaciones
necesitaban procesar los archivos en forma sencuencial. Para procesamiento
secuencial en almacenamiento de disco, el SO debía contar con alguna definición el
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 tuivera abierto el
archivo. El SO incrementa el apuntador de registro acutal cada vez que hay una lectura
o escritura.
 ● Acceso aleatorio : ​En este modelo la aplicación indica al SO que registro en el archivo
necesita y el SO se mueve directamente a ese registro y tiene acceso a el 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 eimitir 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.

​ ​ ​ METODOS 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 modulos de bilbioteca como soporte para lenguajes de
alto nivel. El hecho de que estos medtodos de acceso los porporcione 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 : ​Tambien 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 aveces 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 reslver 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: almacen de
paginación del SO en si y sistemas de bases de datos.
​ RASTREO DEL ESPACIO LIBRE
El SO almacena archivos y directorios en bloques del disco. Para hacerlo, debe saber cuales
bloques aun 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 mas
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 estrucura 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 psita del primer bloque de la lista. Cada bloque libre contiene entonces un
apuntador hacia el siguiente bloque libre. La lista no esta en cualquier orden. Podriamos
ordenarla, pero cuando la aplicación libera un bloque es necesario poder colcoarlo 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 aputnador
hacia el bloque que se encuentra en la cabeza de la lista yl o 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 obtene 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; entoncs un bloque puede almacenar 128 apuntadores. Asi 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 si. El ultmo bloque al que se apunta
debe ser otro blqoue índice en el disco, de modo que permanezca actualizado, aunque tenga
una ligera optimización seria capaz de sacar varios apuntadore 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 ​preasignacion. ​Se trata de una técnica que puede
usarse con muchos de los mecanismos de rastre de espacio libre para minimizar la
actualización de los datos en el disco.
Otro mecanismo para mejorar el rastre 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 mas 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
grupo contiene no solo un apuntador al siguiente bloque libre, sino también una indicación de
cuantos de los siguientes bloques en la lista son adyacentes entre si. Esto permite que algunas
veces el mecanismo de asignación coloque bloques contiguos mas fácilmente. Pero también, 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 este 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 esta usando. El hecho de que el bit “1” indique que el bloque esta libre o que el bloque esta
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 multiples bloques
contiguos. Con un mapa de bits esto es mucho mas 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 mas 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
mas memoria que el mencanismo de las listas ligadas. Debemos mantener en la memoria una
porción del mapa de bits. Lo mas probable es que mantegamos todo un bloque porque es mas
fácil leer de esta manera, el costo de la memoria ya es muy bajo actualmente y esta declinando
en forma continua, demodo que problablemente sea un factor importante Necesitams
actualizar la copia en disco del mapa de bits a medida que asignamos bloques. Pero podemos
seguir usando la técnica de preasignacion 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 ener un bloque asignado a mas 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 os bloques libres
en si.
Hay otro mecanismo mas 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.

​ ASIGNACION 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 necsario que un SO utilice solo uno, algunos atienden
multiples tipos de asignación de archivos, solo necesita las API que atiendan ambos tipos de
solicitudes de asignación y seguir la pista del espacio libre correctamente.
​ ​ ​ ASIGNACION CONTIGUA
Esto siginifca 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 lite
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 efectua un acceso aleatorio a los datos de
manera muy simple. El mecanismo de la API varia 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 mas grande porque es probable que algún otro archivo sea asignado después
del que queremos hacer mas grande. Por ejemplo en la fig vemos que no es posible hacer mas
grande el archivo A sin mover el archivo B. Para evitar este problema, se tiende a asignar mas
almacenamiento para que el archivo que esta siendo requerido por los datos.
De esa forma, el archivo puede crecer durante un tiempo antes de que sea necesario hacerlo
mas grande. Por ejemplo, el programador podría saber que el sistema tiene 100 registros y
suele agregar dos registros mas al mes. El archivo se asigna entonces con espacio para 130
registros y puede operar durante algo mas 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 esta limitado a una asignación
contigua única. La asignación inicial es un bloque contiguo, pero si esta lleno, en lugar de hacer
una nueva copia se efectua la asignación secundaria, no necesariamente contiuga 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 mas pequeña del espacio al que podemos tener
acceso es un sector. Por lo general arregalmos el problema al rastrear la asignación en bloques
en lugar de en sectores. Asi, 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
mas rande. 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 mas 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 mas espaci a un archivo del que realmente se necesita, surge debido a
la difcultad de hacer mas grande un archivo contiguo por lo que es necesario mencionarlo.
​ ​ ​ ASIGNACION VINCULADA
Este mecanismo es como una estructura de lista ligada en MP, pero aca 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 vinculo se desperdicia una parte de cada bloque. Si los bloques son
mayores que un sector, la capacidad disponible resulta aun menor.

Otro incoveniente del mecanismo de asignación por lista ligada es que algunas veces es difil
efectuar métodos de acceso aleatorio en tales archivos, pero no imposible.
El lado bueno es que con archivos vinculados no hay fragmenacion 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 cual bloque estaba disponible
cuando fue alargado el archivo. El procesamiento de tal archivo con un programa que esta
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. Esta puede acelerar significativamente el prcesamiento
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 aleatorioa. En tales sistemas,
la desfragmentación puede ayudar con estos problemas.

​ ​ ​ ASIGNACION INDEXADA
Asi como hay un método indexado para seguir la pista del espacio libre, hay un mecanismo
semejante par aseguir la pista de la estructura de un archivo. La estrucuta de archivo indexada
es algo asi como una lista vinculada exepto que separamos un bloque inidice para mantener
los apuntadores, en lugar de colocar los aputnadores en cada bloque de datos. Asi como el
mecanismo de rastreo de espacio libre, en la implementación mas 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
numero máximo de bloques. Hay dos formas en que es posible expandir el mecanismo para
eliminar este limite: podemos usar multiples niveles de inidices, en forma semejnate a como se
hizo con las tablas de pagina de RAM o podemos vincular los bloques de inidices mismos en
una lista.
● Indices multinivel: ​con inidices multinivel de nuevo usaremos un bloque para contener
apuntadores en forma sejemante como se hizo con la estrucuta de inidice único. Pero en este
caso el primer bloque inidice no contiene apuntadores aun bloque de datos. En lugar de ello,
contiene apuntadores a bloques de inidice de segundo nivel. Con una estrucuta de inidices de
dos capas, estos bloques inidices contienen aputandores hacia bloques de datos. Si un bloque
índice contiene 100 apuntadores, cuand 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 inidices, multiplicando cada vez el
espacio original por 100. El siguiente nivel seria 1 mill. De bloques . Observemos que no
necesariamente se requiere leer todo el conjunto de bloques de inidices 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:​ Asi como con las listas ligadas de espacio libre,
podemos simplemente ligar bloques indexados entre si en una cadena. Cada bloque indexado
contiene asi un apuntador menos hacia bloques de datos porque necesitamos uno para tener
acceso al siguiente bloque inidice, pero es poco porbable que esto sea un factor importante
para la mayor parte de los bloques y tamaños del disco. Si se esta teniendo acceso aleatorio a
un archivo, este mecanismo requiere seguir la cadena ligada una vez que se abre el archivo y
leer los bloques inidice en la MP. Por supuesto, podemos postergar la lectura de todos los
bloques hasta que sea necesario. Si se esta teniendo acceso al archivo secuencialmente, es
posible leer cada bloque índice cuando estamos próximos al ultimo apuntador en el bloque
previo.

CAP 14 (ELMARSI)

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 cuando 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úfers 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úfers 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 n y cada una de esas pistas está dividida en s
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úfers

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 inicalmente
estaba limitada a cargar y arrancar un programa de aplicación particular, mas 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 mas 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 cabian completamente en memoria o la cantidad de datos a manipular
era limitada. Era necesesario que el programador dividiera esos programas en secciones y
sustituyera 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 surgio la necesidad de un sistema
operativo para una PC. Los predecesores de estos SO se denominaban ​monitores ​(Monitor es
un módulo de software que es precursor de un SO​) , y tenían capacidades limtadas. No había
ningún parámetro para los monitores – cada fabricante de los primeros sistemas de PC escribia
su propio programa de monitores, que tenia comandos y convenciones únicos – Esta variedad
significaba que los primeros programas de aplicación debían volver a escribirse para cada
monitor.
INTRODUCCION 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 permitia que una aplicación realizara tareas simples como:
- Emitir un carácter a un dispoistivo 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 especifico 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 jecuta una llamada al monitr atraves 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 elaboraban 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 temrinos 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, deputacion y construcción. Cada fabricante implementaba 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. Podia usar alguna conbinacion de ambos métodos en
un tercer monitor. Esto origino 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 tuviesen 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 especificas 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 ​Nucleo.​ Debia ser independiente del hardware
y debía llamar los servicios mas 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 ​Abstraccion.
La ultima parte del SO fue una interzas 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 cabia 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 Basico de Entrada/Salida ​)
BDOS ( ​Sistema Operativo Basio 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
desarrollaran programas de aplicación para PC contruidas por un monton de fabricantes. El
software admitia 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.
CARACTERISTICAS 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 tenia una pastilla microprocesadora ( CPU ), algo de
memoria RAM, una memoria ROM que contenia al BIOS y varios cirtuitos integrados (CI) que
unian entre si 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 tipicios en uno
de los primeros sistemas de PC. Algunas de las características de este tipo de sistema que tenia
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 cargara 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 cabia 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 ​Superposicion ( 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 requeria planificación de la CPU. Los tipos principales de interrupción era para
manipular dispositivos de E/S.
GESTION 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 flexibildiad en la manipulación de
entrada desde el teclado y la salida atravez de la pantalla. Debido a que había muchos
fabricantes de hardware para computadoras que trabajan en forma diferente, el SO intento
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 mas rápido y mas 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 lso 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 podía estandarizar eso?
El BIOS estaba personalizado para cada tipo de teclado, Luego la BDOS usaría las funciones del
BIOS para crear una interzas con el SO mas 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 requerían una flexibilidad adicional , por ejemplo un
procesador de palabras necesitaba usar las teclas “modificadas” como control + s 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 porvocar alguna acción del SO
como un rearranque. En este caso, evidentemente la combinación de telcas 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.
Podria 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 mas complicados. Primero las funciones disponibles atravez
de las funciones de interfaz del BDOS y el BIOS eran mas limitadas. Habia 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 paginas multiples
de memoria de video para simular movimientos al presentar rápidamente una serie de
imagines o mover el cursor al tiempo que se escribia 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 mas importante para evitar el BDOS era mejorar el
desempeño de la app.
Escribir directamente en la memoria de video proporcionaba no solo mas funcionalidad sino
que era mucho mas rápido que ir atravez de una llamada al sistema del SO.
GESTION 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
propocionaba el SO? Uno de los principales servicios que porporcionaba un SO asi 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 tenia un orificio en el centro donde la unidad de
disco lo ubicaría sobre un eje. El eje esta conectado al motor de una unidad de disco duro que
haría girar el disquete a 360 rpm. El disco normal tenia 77 ​pistas​ numeradas desde la pista 0
hasta la pista 76. Las ​pistas​ eran círculos concéntricos. Una pista tenia 26 ​sectores​ o ​bloques.
Con el primer sector 1 y el utimo 26. Cada sector contenia 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 empezaban en 0 pero los sectores en 1 ( esto no es asi en los discos modernos).
El sistema de disco comprendia la ​unidad de disco y​ el ​controlador de disco​. La unidad de
disco contenia y giraba los medios del disco ( un disquete ) que tenia los datos almacenados. El
controlador de disco solia 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 multiples sectores en
una pista dada en un lado determinado del disco. Cada sector de cada pista contiene el
numero de la pista. El contrlador debe reorientarse a si mismo a finde 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 contenia: 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 una disco contiene el código binario del SO en si. Ademas, 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 calculo,código fuente)
o Ejectuables del programa de aplicación ( código bin )
o Informacion 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 esta dividido en 3 areas para un sistema de archivos BIOS como se muestra en
la fig
o Area reservada donde esta colocado el SO ejecutable ( tamb llamada ​área de arranque
del disco )
o Area del directorio de archivos, contiene entradas con informacion sobre cada archivo
almacenado en el disco
o Area de almacenamiento de datos para datos y archivos del programa, que ocupa el
resto del disco y es la parte mas gran 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 esta escrita en esta área, sector x sector, pista x pista , 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 pequñeo programa en la ROM
que copia la imagen del ejectuable 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.
​ Area del directorio de archivos
El tamaño del área de directorio es fijo y se registra en una table 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 numero de usuario: Es un numero de grupo que va de 0 a 15, lo cual permite que
usuarios multiples o grupos compartan un disco y reunan sus archivos en un grupo. ( no hay
subdirectorios ) - todos los archivos están en un directorio – Los números de grupo dan la
ilucion de contar con subdirectorios ( serian 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 mas bloques de los que pueden será puntados por una
entrada del directorio, porporciona entradas adicionales.
o El numero de registros. Es en realidad el numero de registros de 128 bytes usados en la
extensión. Si la cuenta es 080x, esta extensión esta 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 pequñeo,
que contenga menos de 8 sectores, los apuntadores sin utilizar se establecen a cero. Si el
archivo es demasiado grande, la extensión adicional se asigna y se llena otra entrada del
directorio.
​ Area 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 entrad del
directorio cuenta con la dirección de los sectores donde se almaceno 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 si en
bloques de asignación​, que son sectores consecutivos agrupados entre si. El tamaño del disco
determina el tamaño de estos bloques de asignación.
Observaciones acerca de esta estrctura de sistema de archivo asi 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 almacernase totalmente en disco
o Si el directorio esta lleno, también el disco. ( el tamaño de directorio es fijo, por lo que
en un disquete solo 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 mas importante del diseño era
minimizar el espacio del disco ( y el espacio de memoria ) para cada entrada del directorio.

GESTION DE PROCESOS Y DE LA MEMORIA

Creacion y ejecución de un programa de aplicación
Al escribir un programa de app se escriben instrucciones en lenguaje maquina a un editor de
texto, luego se compila o emsabla o ambas, y por ultimo 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 ejectuable ​o ​binario del programa​, al cabo de unas
cuentas vueltas de depuración, el programa esta listo para usarse.
Para que empieze 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 si es un programa
de aplicación que cuenta con algunes ​funciones integradas​. El CCP lleva a cabo su trabajo
haciendo llamadas al BDOS – jamas llama directamente al BIOS o al hardware – Esto hace que
el BDOS sea mas 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. Habia un
código especial en la cabecera del programa que podía identificar el archivo como programa
ejecutable. Alternativamente, los comandos que introducia el usuario podían nombrar un
archivo de texto que fuese una cadena de comandos que el CCP debía leer y ejecutar uno por
vez. Habia 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 cargbaban en la RAM empzando en la
dirección 0100Hex. 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
predefinidios de tamaño fijo como cadenas estáticas – Ademas se requiere una pila para datos
dinámicos – por ejemplo para variables temporales – Los datos estáticos se cargan en la
memoria, acontinuacion de la carga del archivo con el programa binario. Se reserva memoria
adicional para otros datos después de los datos estatiticos. La sig fig ilustra el mapa general de
la memoria para las diversas partes de un programa en ejecución.
La pila esta colocada en la ubicación superior en la mmeoria justo abajo del código del SO. La
pila crece en la memoria hacia dirección de memorias mas bajas. Una vez completada la carga,
el SO llama ala primera instrucción de 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
mmeoria, pero si no es asi, puede usar memoria disponible en el momento que lo requiera
para memoria reservada que contiene al SO o partes de el.
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 esta 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 esta actualmente en la
memoria. La implementación de la superposiciones se le dejaba al programa de aplicación,
aunque solia tener algo de asistencia de las bilbiotecas de aplicación
 ​ Procesamiento de comandos por medio del CCP
El CCP es un programa bastante parecido a otros, quizá el CCP esta 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 ​interprete 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
interprete de comandos es ​interfaz de línea de comandos​, ya que cada comando se intruduce
en una línea de la pantalla y se somete al interprete 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.
​Gestion 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 mas alta en la
memoria, debajo del SO. Esto para que la pila creciera hacia abajo en la memoria y no chocara
con los datos del programa.
Pero el CP/M no contaba con previsiones para detectar una colision entre la pila y los datos
fijos. Esto por lo regular provocaba la caída del programa o producia resultados extraños
porque la CPU no tenia 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 regresarse 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 usara 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 contenia apuntadores a direcciones de la
memoria donde estaban ubicados la pila y los datos fijos. También contenia un apuntador a las
cadenas pasadas como parámetros al programa cuando el usuario escribia el comando y
suministraba argumentos al programa.
¿Por qué el SO estaba localizado en la parte mas arriba de la memoria y no en 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. Asi el SO se generaba ( configuaraba) para ocupar las
ubicación mas elevadas en la memoria dejando una dirección fija – siempre 100 hex – para
cargar programas. Si el SO se volvia mas grande podía empezar en una dirección mas 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 memroia 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 dmemoria que
podía manipular la CPU. Inicialmente era de 64KB, pero en algunas versiones posterios de la
CPU se permitia mas memoria y algunas PC tenían hardware añadido para proporcionar
“bancos” de emoria que pudieran trazarse en espacios de la memoria por control del
programa.
¿Los programas manipulaban 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 si en las mismas ubicaciones en la memoria y se llamaban
superposiciones ( overlays ). ​Los programas que tenían grandes cantidades de código podían
dividrse 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 sustituían 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​ al a 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 mas valioso: el tiempo de la persona.
La solución del CP/M fue un proceso de impresión de fondo. En la parte mas alta de la
memoria se cargaba un pequeño programa, exactamente debajo del SO. Este programa se
iniciaba asi mismo y luego regresaba el control al CCP, permitiendo la ejecución de otro
programa. Cuando un usuario deseaba imprimir en el fondo, el nombre del archivo a imprimir
era pasado al manipulador de impresión de fondo. Este podía imprimir un poco del archivo –
una línea o dos – una vez que tenia el control. El proceso de fondo por lo regular tenia el
control en cualquier instante en que un proceso de fondo hiciera una llamada al sistema o
posiblemente al establecer un cronometro y provocar una interrupción del proceso de fondo.
La impresión de fondo aparentaba que la computadora hacia dos cosas a la vez, algo
denominado ​multitarea. ​El manipulador de impresión de fondo solo permitia imprimir en el
fondo y nada mas.

McIver CAP 14 ​(MS-DOS)

​ INTRODUCCION
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 maquinas.
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, maquinas de 8 bits
comercializadas por Apple y Tandy. Pero cuando las primeras PC de 16bits fueron desarrolladas
requerían un SO con mas capacidad que CP/M.
IBM junto a Digital Research ofrecio 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 16bits. Microsoft lo compro y lo denomino MS-DOS (Microsoft Disk
Operating System ) y lo puso a disposición para IBM.
IBM escogio MS-DOS y lo denomino PC-DOS y lo proclamo la norma para su línea de PC.
Mientras MS-DOS se volvia el SO normal para PC.
Los programas escritos para esu ejecución en versiones antiguas también eran compatibles en
versiones mas actuales, también significaba que entre fabricantes diferentes, con los mismo
comandos se obtenia la misma respuesta del SO, sin importan 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
ingles 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 maquina desnuda que
integran la capa inferior. Cada capa esta 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 dipositivos E/S. el BIOS contiene los ​controladores
de dispositivos​ que controlan el flujo de datos hacia y desde cada dispositivo exepto las
unidades de disco. Recibe información de 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 cntrolador de dispositivo para ella.
La capa del medio, el nucleo DOS, contiene las rutinas necesarias para conectarse con las
unidades de disco. Se lee en la memoria en el momento de iniia desde el archivo MSDOS.SYS
que reside en el disco de arranque. El nucleo del DOS es un programa registrado
proporcionado por Microsoft Corporation que implementa MS-DOS. Al nucleo tienen acceso
los Programas de aplicación y el nucleo porporciona 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 nucleo DOS compensa diferencias de un
fabricante a otro, de modo que todas las unidades de disco funcionan del mismo modo. El
nucleo hace que la administración de archivos sea transparente para el usuario, de modo que
no es necesario recordar en que pistas y sectores están almacenados sus archivos, y que
sectores del disco están dañados y deben evitarse. El nucleo 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
tomarse 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 usuario único. 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 mas 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 tamaño pequeño y contiene a 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 si mismo por medio de sus rutinas de arranque.
Este programa en ROM inicia la computadora. Tambien 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 inferiror de la RAM denominada ​memoria baja​ porque es donde empieza la memoria:
0,1,2 .. esta ocupada por 256 vectores de interupcion y sus tablas.
Un vector de interrupción especifica donde esta ubicado el programa ​manejador de
interrupciones ​para un tipo de interrupción especifico. Lo anterior es seguido por tablas BIOS y
tablas DOS, y por el nucleo 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 interprete 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 mas espacio, el área superpuesta de COMMAND.COM, localizada
en la ubicación de memoria alta, también puede usarse por el programa de aplicación. Los
programas COMMAND.COM en esta área se consideran transitorios porque se usan para
jeecutar comandos, como FORMAT, que no puede ejecutar el usuario cuando esta
ejecutándose un programa de aplicación, de modo que es posible que otros porgramas se
superpongan ( o sobreescriban ).
 ​ ASGINACION DE LA MEMORIA PRINCIPAL
Las primeras versiones de MS-DOS porpocionaban toda la memoria disponible al programa
residente, pero esto es ineficiente porque el esquema simple de asignación de memoria
contigua no permitia que los programas de aplicación asignaran y liberaran 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 incida la cantidad minima y máxima de
memoria necesarias para la ejecución del programa. Si el minimo es mas que la cantidad de
espacio disponible, no es posible ejecutar el programa.
Exepto por archivos COM, en la TPA puede haber cualquier numero de archivos a la vez, pero
¿Por qué un sistema puede tener dos porramas 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 el y cerrarlo antes de abrir el siguiente. No es posible abrir ambos al mismo
tiempo, pero esto se vuelve mas rápido al usuario.
Si un programa que ya esta en ejecución requiere mas memroia, como para ​buffers​ a​ dicionales
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.
​ ASIGNACION 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 ultimo ajuste. Cuando se usa ultimo ajuste DOS asigna el bloque de
mmeoria direccionable mas alto suficientemente grande para satisfacer la solicitud del
programa.
El tamaño del bloque puede varias desde tan pequñeo 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 caracterisitcas 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 esta bien diseñado amontona sus bloques de memoria hasta que termina su ejecución; solo
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
​ ADMINISTRACION 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 eston o 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 reicinio 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 y Stay Resident ( TSR ).​Su función consiste en terminar un
prceso sin liberar memoria, proporcionando asi facilidades de programas residentes en la
memoria. El TSR suele ser utilizado por bibliotecas de subrtuinas 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 travez 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 esta listo, el programa determina cuanta
memoria debe mantener. Luego, cuando el programa sale, se hace pasar un código de regreso
al padre.
Como 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 resulto la interrupción actual. La CPU usa el numero 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 mas 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.
​ ​ ADMINISTRACION DE DISPOSITIVOS
Como MS-DOS esta diseñado para un entorno de usuario único, todas las solicitudes se
manejaban sobre el base primero​ en llegar, primero en salir​ , pero desde la versión 3.0, BIOS
puede antender ​spooling a​ l 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​ espeficio de la memoria hacia la impresora hasta que se vacia el​ buffer.
El administrador de dispositivos de MS-DOS permite trabajar con cualquier dispositivo de
almacenamiento, disquetes, disco duros, etc.
Estos sistemas solo usan un tipo de dispositivo E/S para cada puerto, de modo que lso 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 espcial del SO.
En consecuencia, los manejadores de dispositivos son los únicos dispositivos necesarios para
que el administrador de dispositivos haga funcionar el sistema. Un contrlador de dispositivos
es un modulo 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 dipsotivios que manipula el software del controlador de dispositivos.
El BIOS esta almacenado en ROM y en RAM. En muchos otros sistemas MS-DOS, las partes mas
primitivas de los contrladores están ubicadas en ROM, dem odo que pueden usar las
aplicaciones y diagnosticos independientes, asi como el programa bootstrpping 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 interrupciones generadas por hardawre y software.
​ ADMINISTRACION DE ARCHIVOS
MS-DOS atiende organizaciones de archivos secuenciales, directos e indexados secuenciales.
Los archivos secenciales 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 NOMEMCLATURA 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 minisculas o mayúsculas de modo que ls nombres de archivos
pueden escribirse de cualquier forma.
La identificacicon de la unidad ( A ; B ; C ; D ) esta 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 esta trabajando en un idrectorio o en un subdirectorio, el directorio en
cuestión se denomina ​directorio de trabajo​ y a cualquier archivo en ese directorio puede
tenerse acceso median su nombre relativo. Pero para tener acceso a un archivo que esta en
otro directorio se requiere el nombre absoluto.
Si estoy en el directorio actual y tengo un archivo “trabajo.doc” entonces lo llamo 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 esta ubicado C:\Tomi\TPS\trabajo.doc

​ ​ ​ ADMINISTRACION 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 agregaban mas 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 mas. Para resolver esto Microsoft implemento
una estructura jerarquica de directorios en la versión 2.0; una estructura de árbol invertida (
raíz en parte superior y hojas en la parte inferiror)
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 mas ​clusters​. Ademas de divdir 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 interaccion 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 intruccion
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
- Extension del archivo
- Tamaño del archivo en bytes
- Fecha y hora que se realizo la ultima modificación
- Numero 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 numero 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 Asignacion de Archivos ​contiene información critica de 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 numero del primer sector o cluster del archivo; ese numero 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 si para formar una cadena, donde cada
entrada del aFAT proporciona el numero de sector/cluster a la sig entrada. La ultima 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 cmomo 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 efectua 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 mas 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 reposicionarlos como una sla 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 numero de bloques no contiguos donde esta
almacenado el archivo. Es decisión del usuario compactar al archivo, en caso de ser necesario,
de modo que se almacena en el menor numero 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 computo y sus recursos no esta
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
interprete de comandos y las rutinas necesarias para atender un programa activo. Ademas
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
mas altas de la memoria y pueden sobreescribirse por programas de aplicación si necesitan
usar su espacio de memoria. Desp cuando termina 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 interprete 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 memroia 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 ejectuar 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 raton, 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 solo necesita escribir START en el símbolo del sistema.
Para que este programa se ejecute automáticamente cada que se reinicia el sistema, entocnes
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 pagina 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 especifico, 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 escribrse:
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 lso resultados al dispositivo de salida predeterminado. Un
filtro de uso común es el SORT, que acepta los datos de dentrada desde el teclado, ordena esos
datos y los muestra por pantalla. Este comando filtro se vuelve mas ú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 possible ordenar el archive por columnas tambien, usando
SORT /+14 <EMP.DAT> SORTSTD.DAT

​ TUBERIAS
Una ​tuberia ​puede ocasionar que la salida normal de un commando sea utilizada como
entrada normal para otro commando; este simoblo es una barra vertical ( | ) Es posible
ordenar alfabéticamente el directorio y mostrar la lista ordenada en la pantalla al escribir:
DIR | SORT
Tambien es posible combiar tuberías y otros filtros. Por ejemplo para mostrar en la pantalla el
contenido del archivo INVENTRY.DAT a la vez, seria:
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
Habia 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 especifica 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 estás 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 numero de archivos permitidos en la siguiente cola
de impresión. El valor minimo para Q es 4 y el máximo 32.
TREE muestra los directorios y subdirectorios en una lista jerarquica y con sangría. Tambien
tiene opciones que permite que el usuario borre archivos mientras se esta generando el
árbol.Tambien puede usarse para borrar archivos duplicdos en diferentes directorios.
CONCLUSION
MS-DOS fue escrito para rendir servicio a los usuarios de PC, incluyendo las primeras versiones
del as computadoras personales de IBM. Tuvo éxito pero su flexibilidad limitada lo hicieron
inutilizable a medida que evolucionaban 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.
TERMINOS
Archivo por lotes: ​Archivo que incluye una serie de comandos que se ejcutan en secuencia sin
ningún dato de entrada de parte del usuario. Contrasta con una sesión interativa.
Asignacion 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 suficiente 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
Compactacion: ​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: ​modulo deprograma especifico que maneja las interrupciones y
controla un tipo particular de dispositivo
Extension: ​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
Tuberia: ​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)

​ PLANIFICACION DE PROCESOS
Como habíamos visto, un proceso puede abandonar el estado de ejcucion por varias razones.
Cuando lo hace, puede ir de inmediato al estado listo, por ejemplo si fue interrumpido por
haber llegado a los limites de su ​quantum​. Si un proceso esta 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. Cuanod un proceso se coloca en el estado listo, es necesario decidir cuando debe
ejecutarse en realacion con los procesos que ya se encuentra en el estado listo. Esta decisión la
toma un modulo del SO denominado ​Planificador a corto plazo.
​ Algunos algoritmos utilizados
​ Planificacion Primero en llegar, primero en ser atendido
El meto mas 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 (firts come, first served : primero en llegar, primero en ser atendido ) ​Presenta algunas
ventajas. Es el ​mas justo​ ( bajo ninguna circunstacina favorece a un proceso en detrimento de
otro ). FCFS es mejorado a menudo al perimitir 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 mas tiempo de CPU de lo
debido, por lo que no era una solución ideal.
​ PLANIFICACION POR PRIORIDAD
Hay algunas circunstacias en la que no es aconsejable utilizar FCFS por alguna que otra razón,
podrían tenerse algunos procesos mas importantes que otros. En este caso podemos utilizar el
algortimo de ​planificación por prioridad. ​En este algoritmo damos precedencia a cada
proceso, por ejemplo nuestro manipulador de teclazos y del raton puede tener la prioridad
mas alta.
Siempre que permitimos que algunos trabajos tengan prioridad sobre otros hay un problema
especial, es posible que los procesos con prioridad mas alta estén postergando un proceso de
baja prioridad hasta el punto en que este ultimo jamas 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 proporcionara la mayor parte del tiempo.
​ PLANIFICACION 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 mas pequñea. Esto también se llama algunas veces ​planificación por participación
equitativa​. Seria una especia de programación por prioridad.
​ PLANIFICACION SRTF
Este algoritmo se llama ​Primero con el tiempo de ejecución mas corto ​( también denominado
algunas veces como ​primero con el tiempo restante mas 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 cuando 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 RAZON DE RESPUESTA MAS ALTA )
La planficiacion 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
mas alta mientras mas tiempo espere. Esta variante se usa principalmnte porque disminuye la
probabilidad de inanición (cuando es posible que un proceso de prioridad mas alta estén
postergando un proceso de baja prioridad hasta el punto en que este ultimo jamas sea
ejecutado)
​ APROPRIACION
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 ultimo e iniciar el de prioridad
superior. El hecho de alejar un recurso de un proceso se denomina ​Apropiacion​. En este caso
el recurso que estamos apropiando es la CPU en si.
Podemos aplicar apropiación a cada uno de los algoritmos vistos mas arriba, si permitimos la
apropiación al algoritmo FCFS se convierte en el algoritmo ​Round-Robin​. En este caso la
apropiación no esta basada en la prioridad sino en un cuanto de tiempo. Dejamos que cada
proceso se ejecuta una cantidad especifica de tiempo sin hacer ninguna operación de E/S. Si el
proceso exede 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 mas alta, en el BCP anotamos la cantidad de tiempo que
queda en nuestra conjetura del tiempo de ejecución de ese proceso. Cuando lo reinciamos
mas tarde, no hacemos ninguna conjetura nueva.
En el algoritmo por prioridad podemos aplicacar la apropiación cuando un proceso de
piroridad 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 mas modernos, usan un algoritmo de planificación mas complicado denominado ​colas
multinivel. ​En lugar de tener una cola única se tienen varias. Un nuevo trabajo se colca 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 mas alta se atiende primero. Una cuestión que
es necesario decidir es el mecanismo utilizado para compartir la CPU entra 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, demodo que se
coloca en una cola de alta prioridad. Si el proceso se ejecuta por mas 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 tmabien puede tener un cuanto de tiempo mas largo.
Entonces si el proceso no termina su cuanto de tiempo en la cola rápida, quizá sea conveniente
darle mas tiempo a la cola inferior. Por lo regular hay al menos 3 de esas colas. Asi en caso de
que un proceso en ejecución en la segunda cola aun no haya realizado ninguna llamada de
bloqueo en el cuanto de tiempo apra esa cola, es desplazando a una cola inferior, quizá con un
cuanto de tiempo mas grande.
​ SELECCIÓN DEL MEJOR ALGORITMO
Con tantos algoritmo como compararlos? Hay vairas medidas del desempeño del sistema que
se han usado para comparar algoritmos de planificación. Algunas incluyen lo siguiente:
● Produccion ​: numero de trabajos que se ejecutan por hora o por minuto.
● Tiempo promedio de retorno ​: tiempo transcurrido desde el inicio hasta el final de
trabajo.
● Tiempo promedio de repuesta ​: tiempo transcurrido desde que se presenta el trabajo
hasta el inicio del resultado.
● Utilizacion 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 mas 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 tiempo de ejecución y manualmente se simula laejcucion de cada proceso en la
muestra de daots, 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 modulo planificador denominado ​planificador a largo plazo. ​En
un SO PC con una GUI, normalemente no existe este planificador.
La tarea del programador a largo plazo es decidir cuantos trabajos tratar de ejcutar al mismo
tiempo y cuales ejecutar cuando. El primer aspecto de esta decisión es que hay algún numero
minimo de trabajos que se quiere ejcutar al mismo tiempo. La ejecución empieza con este
numero minimo de trabajos, en el supuesto de que haya mas 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 ejcucion 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 cache que lleva a cabo el hardware, la ejecución
del proceso aminora drásticamente su velocidad durante un lapso hasta que los bufers de la
memoria cache 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 usara 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 especifica. En otros casos, el SO simplemente intenta ejecutar un proceso en la misma
CPU que uso la ultima vez que ejecuto un proceso. En algos 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 CREACION DE PROCESOS)
Cuando un usuario manda señales al interprete de comandos para iniciar un nuevo proceso,
debe haber alguna manera para que el proceso de ese interprete de comandos inicie el
proceso del usuario. El interprete 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 “bifurado un hijo” o “ generando un hijo “. Asi resulta evidente que la
necesidad de que el interprete 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 multiples CPU’s . 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 continue 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 huefano.
Otracuestió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? Todavia otra cuestión esta
relacionada con el programa que esta 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 como sabe cada uno de los procesos
cual instacia es el padre y cual el hijo? En general el código de regreso proviene del fork y se
fija en ​cero para el proceso hijo​ y ​un numero 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 interprete de comandos, lo que desea es ejecutar algún
otro programa, lo que realmente se quiere es la ejecucuion de otro programa en un proceso
hijo. Asi luego de la llamda 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.
​ QUE 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 representaban el estado dela CPU.
Supongamos que iniciamos un proceso desde el principio y lo guardamos en esa tabla, ahora
supongamos que iniamos otro proceso. De nuevo lo dejamos en ejecución durante algún
tiempo, luego lo detenoms 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 reanundar su ejecución
¿Cómo seria esto diferente de la ejecución de multiples 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 al memoria, de modo que hay mas
memoria por utilizar para otras cosas. Por otra razón hay menos gastos generales para
intercambiar entre hilos que para cmabiar 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 multiples 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 si, 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 mas 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 talbas de datos, pero solo la hace el primer hilo.
​ HILOS A NIVEL DEL USUARIO CONTRA HILOS A NIVEL DEL NUCLEO.
El uso de multiples 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,Asi 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 multiples actividades ejecutándose en paralelo. En
consecuenca, 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 nucleo. Ahora el SO estaba consciente de que la aplicación
estaba utilizando hilos. Estos paquetes de hilos se denominan paquete de hilos ​al nivel del
nucleo​ también puesto que el SO esta consciente de los hilos individuales, es posible que los
hilos se ejecuten en una CPU por separado en un sistema con multiples CPU. Esta es una
ventaja fundamental para los hilos al nivel del nucleo.
En general, los hilos a nivel del nucleo son mucho mas 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 nucleo, había 3 metodos
comunes para hacer que las rutinas de la bibliotecas del usuario usen hilos al nivel del nucleo.
La cuestión mas importante que los distingue es el método de mapeo de los hilos al nivel del
usuario a hilos al nivel del nucleo. Los 3 metodos son:
uno a uno ​: cuando la aplicación llama ala rutina de la biblioteca para crear un nuevo hilo,
dicha rutina llama al mecanismo de hilos al nivel del nucleo 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 esta 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 nucleo y todos los hilos al
nivel del usuario se mapean sobre el mismo hilo al nivel del nucleo. Este modelo es menos
aconsejable que el modelo uno a uno porque no ofrece la ventaja de hilos a nivel del nucleo
muchos a muchos ​: En este modelo, el programador indica al sistema cuantos hilos al nivel del
usuario y cuantos hilos al nivel del nucleo serán necesarios y como deben mapearse. La idea
básica es tener un grupo de hilos al nivel del nucleo disponible y asignarles dinámicamente
hilos al nivel del usuario según sea necesario.
Aunque los hilos son mas fáciles de crear y destruir que los procesos, sigue habiendo algo de
trabajo adicional implicado en la creación de aquellos, como resutado algunos paquetes
dehilos crean un grupo de estructuras de hilos cuadno 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 paralelizacion 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 atravez 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 multiples hilos. Todos los hilos en un proceso
comparten el mismo estado y mismo espacio de la memoria e implícitamente se comunican
entre si 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 mas bien puede ejecutarse en paralelo.
Una vez que dejan de ser necesarios se destruyen, el alcance de un hilo esta dentro de un
modulo de codificación especifico 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​ (GESTION AVANZADA DE MEORIA)
​ PAGINACION
En lugar de usar el registro base para verificar una dirección, lo utilizamos para reubicarla. Esto
nos permitió la reubicacion 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 numero 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 paginas separadas. La MMU considera que al dirección está
compuesta por dos partes, mostradas aquí como el numero de pagina, p, y el desplazamiento,
d. El desplazamiento es la dirección del byte especifico dentro del marco. El resto de la
dirección lógica es el numero 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 paginas. La unidad de
control de la memoria añade el número de la página de la dirección lógica que genera e
proceso en ejecución en la CPU al valor en el registro de dirección de la tabla de paginas. El
valor almacenado en esa ubicación de la tabla de páginas es la dirección de reubicacion 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 encontraren 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é lso
factores más recientes de reubicación, de modo que podamos usarlos nuevamente sin
necesidad de buscarlos en al memoria. Esto se lleva a cabo con un dispositivo especial de
hardware denominado búfer duplicado de traducción, o TBL (translation lookside 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 reubicacion 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 tenia un
registro que especificaba la longitud del proceso en la memoria principal. Es decir, contiene la
dirección del número de página mas 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.

​ ​ ​ PROTECCION DE ACCESO A PAGINAS

La paginacíon, permite que el SO restrinja los tipos de acceso posibles a las diversas paginas. El
hardware puede fijarse para sólo permitir acceso de lectura a una página, o para ejecución.
​ ​ ​ TABLAS DE PAGINAS GRANDES
En maquinas 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 dificil 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 taba de páginas
de dos niveles (Imagen insertada abajo): esencialmente se pagina 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 PAGINAS INVERTIDAS

Un enfoque ligeramente diferente al problema de la memoria externa consistió en invertir el
problema. La idea era asignar lo 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 PAGINAS CON MULTIPLES TAMAÑOS DE PAGINA
En sistemas posteriores se volvió común tener mas 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 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 paginas ni siquiera están en al 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.
​ SEGMENTACION
La segmentación seria 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 separad. 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: numero 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 combinen 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 usara 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 optima 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 engorroso para el SO. Los
programadores de lenguajes de alto nivel en general no está 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.
​ ​ ​ SEGMENTACION CON PAGINACION
Hay una diferencia fundamental entre paginación y segmentación. La paginacion 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 ultimo 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 aleatoria mente 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 fenomeno es muy importante en el diseño
del SO. Denominado​ localidad de referencia.
El truco para aprovechar este fenomeno 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 lo 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 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 página 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 sacar 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 operación ​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 ide 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 tenia una zona de escritorio, ventanas, iconos, un ratos, menus y barras de
desplazamiento. Podias 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 mas importante sobre el SO porque hacia carecer de soporte.
​ TAREAS UNICAS
Para este entonces Apple decidio sacar la multitarea que había usado con Lisa ( la que falló por
sus altos costos ). Aun cuando una ventana de aplicación no ocupara toda la pantalla, en un
principio el SO Mac no permitia la ejecución de mas de un programa a la vez, ni para impresión
de fondo. Para permitir algo de funcionalidad paralela, el SO incluyo 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” mas que como programas por separados
y eran capaces de abrir una ventana única. La sig fig nos muestra el ​panel de control​ que
permitia 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 Unica porque solo un programa de aplicación se ejecutaba ala
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 400kbytes. Este era un espacio chico para buscar archivos fácilmente, de modo que todos
los archivos se guardaban en un directorio único, además de esto los desarrolladores
agruparon todos los archivos parecidos entre si en ​carpetas​ en el disco. Esto permitio que los
usuarios pudieran buscar dentro de las carpetas y anidar las mismas dentro de otras.

​ GESTION 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 si. Ademas
el código de la aplicación se ejcuta 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 ​A5world​ que contiene los
datos estatitcos de la aplicación y algunos metadatos sobre ella. Debajo esta 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. Asi un problema que debe manejar el
SO es asegurarse de que estas dos áreas no queden una junto a la otra.

​ ROM
En las mayor parte de las PC solo se suaba una ROM para contener el código de ​POST (
power-on self-test ) ​y algunas rutinas de BIOS. La ROM del Mac contenia mucho del SO actual
ya que era mucho mas 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 pimeras Mac no tenían disco duro. También ayudaba al sistema arrancar mas rápido, ya
que no era necesario leer ese código desde la unidad del disquete. Esta arquitectura ayudo 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, carecia de características importantes des del punto de
vista teorico. El finder era algo mas rápido. Se eliminaron ciertos iconos/comandos y se
añadieron otros para crear una carpeta nueva, asi como para apagar el sistema. Ahora los
disquetes podían 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 agrego el
accesorio Choose Printer, que permitia que el usuario escogiera una impresiona por defecto.
Esta utilidad mas 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 atraves 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 hacia en
minutos, en cada nuevo modelo de Macintosh se incluyo mas RAM que en los previos y
contenia 4 veces mas RAM que la Mac original. Esto era suficiente para hacer posible alguna
forma de multitarea. Primero se implemento en el programa ​swit-cher, ​que permitia que un
usuario iniciara 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 aparecia la siguiente. Cuando un usuario cambiaba a
uno de los programas en ejecución se decía que “​tenia el foco​”. Asi, el usuario podía cortar y
pegar entre aplicaciones en segundos, en lugar de hacerlo en minutos.
​ MULTITAREA
Switcher creo varias ranuras fijas en RAM, en las que se cargaban las aplicaciones. El programa
swtcher 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
podí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, esta multitarea era muy limitada, en el sentido que
aun 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 tenia el foco no estaba en ejecución realmente. A pesar de este
inconveniente, este enfoque funciono con el esquema existente de gestión de memoria, ya
que no se requeria cambiar los programas con switcher para trabajar. Los cambios también
eran transparentes para el nucleo del SO.

​ SISTEMA 3
 ​ SISTEMA DE ARCHIVOS JERARQUICO ( HFS )
Como sabemos, las unidades disco iban creciendo en consecuencia había mas cantidad de
archivos, asi que se estreno un nuevo sistema de archivos​ HFS​. Este reemplazo 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 mas útil que se
denomino ​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 arboles
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 laser de alta gama, grupos
de módems, etc. Tambien facilitaban la comunicación atravez de archivos y directorios
compartidos en servidores centrales. Asi Apple agrego soporte para AppleShare, un protocolo
registrado para compartir archivos. El protocolo de la pila también incluia tecnología registrada
en otras capas: AppleTalk en redes y LocalTalk en las capas de enlace de datos y física.
Entonces Chooser adquiria mucho mas 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 agrego soporte para
unidades disco mayores que 32 Mb.
En este sistema el SO Mac posibilito una versión del Finder que pudiera lanzar multiples
aplicaciones. Apple lanzo en el SO dos opciones Finder y Multifinder, pero como este ultimo
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 implemento el multifinder, los usuarios podían cambiar entre finder, que admitia
solo un programa a la vez y multifinder que podía manejar multiples programa. A diferencia de
switcher que simplemente cambiaba el SO de la ejecución de una aplicación a la ejecución de
otra, multifinder permitia que cada programa continuara su ejecución, dando a cada una
tiempo de la CPU. El SO Mac no fijaba limites establecidos respecto al tiempo que un proceso
podí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 hacia esperar al proceso, mecanismo denominado
bloqueo.​ Cuando un proceso lleva a cabo un bloque de proceso asi, 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. Asi 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 aun no termina pero que esta renunciado
voluntariamente al control y que esta listo para ejcutarse 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 multiples aplicaciones en
ejecución, cada una podía tener abierta multiples ventanas en el escritorio al mismo tiempo.
Cuando un programa obtenia 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.
​ GESTION DE RAM CON MULTIFINDER.
Multifinder también contaba con un mecanismo para que las aplicaciones comunicaran sus
requerimientos de memoria al SO, demodo que pudiera asignar RAM a cada programa según
sus necesidades. Lamentablemente la cantidad especifica podría no ser suficiente para algunas
tareas, de modo que al usuario se le proporcionaba una interfaz para sobreescribir ese
numero. A menudo a un programa se le otorgaba mas 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 multiples aplicaciones, la gestión de
RAM suele ser mucho mas complicada que cuando se ejecuta una sola aplicación. Pero cuando
se estaba desarrollando Multifinder, una consideración clave era que los programas que
corrian bajo finder debían trabajar sin cambio bajo multifinder. Asi la arquitectura de memoria
es bastante semejante, aunque ligeramente mas 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 lanzo por un tiempo nomas, 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 mas
barata y mas grande y los usuarios siempre querían mas de ella. Asi el sistema 6 comenzo la
migración para manejar la Mac en modos verdaderos de direccionamiento de memoria de
32bits que ya habían aparecido con la CPU 68020 de Motorola. Estas direcciones de 32 bits
permitieron que la Mac pudiera manjear hasta 64Gb de RAM. Versiones anteriores usaban los
24 bits inferiores para direccionamiento y los 8 superiores para banderas que indicaban por
ejemplo que el bloque al que se apuntaba estaba marcado como “bloqueado”, etc. Habia sido
esto una solución efectiva para hardware anterior con RAM limitada, pero después se volvió un
estorbo. Apple se referia a un código que usaba el modelo de direccionamiento 24+8 bits como
no limpio de 32 bits​ y sugeria que los desarrolladores elminaran este código de sus
aplicaciones. Sabemos que mucho del SO Mac estaba en ROM. Pero lamentablemente mucho
de ese código ROM era no limpio de 32 bits, de modo que las Mac anteriores no podían migrar
a este nuevo modo. El nuevo modo requeria nuevas versiones de hardware. El cambio al modo
de direccionamiento de 32 bits facilito 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 mas 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 aca y alla. Con el transcurso del tiempo, se
encontraban tales ahorros de bytes que tuvo un impacto negativo, el ​error Y2K (año 200) ​Pues
se acorto 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. Continuo con la migración del SO
Mac hasta el direccionamiento completo de 32bits y mejoro su manipulación de graficas,
establecimiento de contactos profesionales y ​multitarea ​e introdujo una forma de ​memoria
virtual.​ Esta versión elimino la versión del Finder, Asi la multitarea cooperativa se converitio en
el modo normal de operación del sistema. Tambien 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 menus, se agrego uno denominado menú de
aplicaciones, que mostraba una lista de programas en ejcucion y permitia a los usuarios
cambiar entre ellos. Ahora los usuarios pueden arrastrar y soltar: un bloque de texto podía
arrastre de un programa a otro con el raton en lugar de tener que copiar y pegar.
El finder del sistema 7 utlizo características cromáticas e hizo que algunos elementos de la
interfaz parecieran mas tridimensionales. Otras caracterisitcas de usabilidad también se
agregaron al SO en versiones del sistema 7. WorldScript contaba con lenguaje a nivel del
sistema para diferentes idiomas además del ingles. Tambien 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
Aveces un usuario quería ejecutar mas programas de los que cabian 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 se usa algo de espacio en una
unidad de disco duro para simular una memoria RAM mas 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 ​paginas​. Cuando un programa empieza su ejecución , solo la primera
pagina del programa se lleva a la RAM. Cuando el programa en ejecución hace refencia a una
parte del programa que aun no esta en memoria, el hardware provoca una interrupción
llamada ​fallo de pagina ​y el SO lee la pagina 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 paginas del programa puedan localizarse en cualquier
parte de la RAM. La MV se implemento por primera vez en este sistema 7.
​ UNA NUEVA CPU
Apple para ese entonces formo 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
proporciono 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 supervisior 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. Poseia compatibilidad universal, asi 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 desarrollo el bus
PCI lo cual fue algo competitivo para Apple hasta que lo termino incorporando en las PC
PowerMacintosh.
​ 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 mas tarde indican al hardware donde
empieza cada sector, cuales son los números de la pista y el sector, y cual 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 vacio en el disco. En caso de IBM y de Mac era
diferente, asi 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 mas acpetables 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: tajertas de
redes, controladores para unidades de disco externas, unidades de disco en si y tarjetas RAM.
Pero una tarejta de RAM no podía direccionarse como MP porque la ranura PC Card no estaba
conectada al bus de E/S. Asi 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 agrego soporte para nuevos modelos Mac con multiples CPU. Estas maquinas
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 mas CPU a la vez. Esto significa que es necesario tomar
precauciones peciales para evitar que haya dos instancias de ejcucion manipulando cualquier
elemento de datos al mismo tiempo. Este sistema también introdujo la posibilidad de
compartir web personal. Esta herramienta permitio que los usuarios fueran anfitriones de
paginas de la red en sus computadoras.
​ SISTEMA DE ARCHIVOS JERARQUICO 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 mas 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 mas grandes, de modo que se inventaron mecanismos para extender los primeros
sistemas de archivos a unidades mas grandes. La primera técnica fue asignar bloques multiples
en lugar de sectores únicos.Si la asignación se hacia con base en dos sectores entonces el
mismo apuntador de 16 bits podía direccionar una unidad de disco de 64Mb. Esto podía
aumentarse a cualquier numero 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 tenia algunos problemas, por
eso este sistema 8 incluyo una versión mejorada del sisteam de archivos jerarquico
denominada ​sistema de archivo jerarquico 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. Tambien permitio que los nombre
de los archivos fueran hasta de 255bytes de longitud.
​ OTROS CAMBIOS EN EL HARDWARE
Para este entonces el sistema 8.6 añadio gestión de energía mejorada y mejoro el soporte para
nuevas clases de dispositivos como USB y FireWire
A fin de permitir que una aplicación única use mas de una CPU, el sistema 8.6 introdujo la idea
de permitir que una aplicación se dividiera en multiples hilos de ejecución ( threads)
independientes ( denominados tareas en el SO de Mac ) que luego el SO planifica para
ejecutarlos en multiples procesadores. Apple modifico el nanonucleo para hacer posible este
multihilo. Tambien añadió soporte para que las prioridades se asociaran con tareas. Esto
permitio que la aplicación diseñara algunas tareas como mas importantes que otras. Si una
tarea había estado esperando algún evento que había finalizado y esa tarea tenia una prioridad
mas alta que la tarea en ejecución actual, entonces el SO se adelantaría a la CPU al detener la
tarea en ejecución e iniciar la tarea con prioridad mas alta.

​ SOPORTE UNICODIGO
Apple comenzó a desarrollar un nuevo mecanismo para exhibir otros idiomas diferentes del
ingles, utilizando una norma denominada ​Unicode​ – una norma mundial de codificación de
caracteres – En comparación con otros mecanismos mas 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. Ademas 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