El sistema operativo y la programación

Detalles

Categoría: Artículos

Publicado el Jueves, 14 Septiembre 2006 07:57

Sin duda, una de las funciones más importantes del sistema operativo (en adelante lo abreviabremos como SO) es la comunicación con el usuario, lo que se suele llamar la interfaz de usuario. Es más, desde hace ya bastantes años, la interfaz de usuario de los sistemas operativos es gráfica, con elementos comunes como ventanas, botones, barras de desplazamiento, etc., y denominamos GUI a todo este montaje.

Pero desde luego, ésta no es la única función del SO ni mucho menos la más importante.

El SO tiene otras muchas funciones, entre las que cabe destacar

• Organizar el almacenamiento de datos en memoria secundaria (ficheros, directorios, etc)
• Gestionar la carga de ejecutables desde la memoria secundaria a la principal
• Gestionar la memoria principal y la utilización de la CPU por parte de los programas
• Permitir el acceso controlado al hardware a los programas

Vamos a dedicar un poco de atención a cada una de ellas.

Organizar el almacenamiento de datos en memoria secundaria

Sabemos que en los ordenadores cualquier cosa se almacena en forma de tiras binarias, compuestas por unos y ceros. La música, fotos, documentos, e incluso programas no son más que enormes colecciones de 1 y 0.

Para hacer uso de ello, es necesario que estas tiras de 1 y 0 que representan datos se almacenen en la memoria principal , junto con los programas que los gestionan. Pero la memoria principal es limitada y cara comparado con otro tipo de memoria: la secundaria… es decir, discos duros, disquetes , cd, dvd , memorias flash , etc.

Estos dispositivos de memoria secundaria tienen en general un coste por bit muchísimo menor que el de la memoria principal, pero son mucho más lentos. Además, sus contenidos perduran aunque no dispongan de corriente eléctrica (cosa que no ocurre con la memoria principal).

Pues bien, el SO es el encargado de gestionar estos dispositivos, que son muy distintos entre sí, de tal manera que los programas y, en última instancia, los usuarios tengan una experiencia similar con todos ellos. Básicamente, el SO organiza la información en el interior de los dispositivos de memoria secundaria mediante un sistema de ficheros y directorios. (NOTA: En este contexto podemos considerar la palabra “carpeta” como sinónimo de “directorio” y la palabra “fichero” como sinónimo de “archivo”).

Organizando la información en ficheros se logra que dispositivos heterogéneos tengan un comportamiento similar.

Cada SO utiliza uno o varios sistemas de ficheros. Por ejemplo, FAT o NTFS, utilizados por Windows; EXT2 o EXT3, utilizado por Linux; ISO-9660, que es un sistema utilizado por los CD-ROM, etc.

Gestionar la carga de ejecutables desde la memoria secundaria a la principal

Con todos los ficheros que puede haber en un dispositivo de almacenamiento secundario, podemos hacer dos grandes grupos:

• Los que contienen datos
• Los que contienen código ejecutable

En el primer grupo podemos incluir cualquier fichero que contenga información capaz de ser manipulada por los programas de aplicación. Por ejemplo, imágenes GIF o JPG…, sonido MP3, ASF, AU… video AVI, MPG… documentos de texto de Word, de OpenOffice, de WordPerfect, Hojas de cálculo, bases de datos… o cualquier otro tipo de dato imaginable. Hay muchos ficheros en cualquier disco duro que se pueden incluir en este grupo. Algunos de ellos, ni siquiera los manejamos directamente. Las aplicaciones se encargan de manipularlos sin necesidad de que les prestemos atención ninguna.

En el segundo grupo se incluyen todos aquellos ficheros que contienen código que la CPU debe interpretar: son los que conforman los programas y aplicaciones. Ejemplo de ello pueden ser los EXE o DLL de Windows.

Pues bien, cuando iniciamos un programa, realmente le estamos pidiendo al SO que entregue a la CPU una serie de órdenes almacenadas en uno o varios ficheros. Esta acción es más complicada de lo que parece, porque en los SO actuales, normalmente puede haber en ejecución más de un programa a la vez. Pues bien, es el SO el que “carga” el código desde la memoria secundaria a la principal, haciendo todos los preparativos necesarios para recibir al nuevo programa.

Hablamos también de esto en el artículo titulado Code, Stack, data & heap en la ejecución de programas.

Gestionar la memoria principal y la utilización de la CPU por parte de los programas

El SO se encarga también de que los distintos programas en ejecución tengan en memoria principal tanto el código como el espacio extra que necesiten para hacer su tarea y almacenar datos, que no se interfieran entre sí, y que ninguno de ellos acapare la CPU o cualquier otro recurso de hardware.

Permitir que los programas accedan al hardware de manera controlada

De entre todos los dispositivos de hardware de un sistema informático hay dos que son muy especiales: la memoria principal y la CPU .

La CPU, el auténtico corazón de cualquier sistema informático es la encargada de ejecutar los programas, y de la memoria sabemos que almacena tanto órdenes o instrucciones para la CPU (los programas) como los datos que manejan los programas.

Muy simplificadamente, la CPU realiza una y otra vez el mismo ciclo:

1. Toma una órden de la memoria principal
2. Interpreta qué le está pidiendo esa orden
3. Si la orden implica trabajar con datos lee también los datos de la memoria principal o de algún otro periférico
4. Ejecuta la orden
5. Si la orden ha tenido algún resultado que sea necesario recordar, lo escribe en la memoria principal o lo envía a algún periférico
6. Vuelve al punto 1

Pues bien, los sistemas informáticos modernos están concebidos para que los programadores de aplicaciones NUNCA tengan que leer datos desde un periférico o enviarlos directamente a un periférico. Sólo el sistema operativo va a ser el encargado de gestionar POR COMPLETO la comunicación con los elementos periféricos.

Así pues, si ejecutamos una aplicación, como por ejemplo un sencillo programa de dibujo, nos daremos cuenta de que éste programa tiene interacción con los periféricos… con el ratón, con el teclado, con la pantalla, con la impresora…

Realmente, cuando el programa desea conocer, por ejemplo, la posición del ratón en la pantalla, realmente el programador solicita al SO que acceda al ratón y le devuelva esa posición. Cuando el programa pinta una línea verde en la pantalla, realmente el programador le pide al SO que acceda al hardware de la tarjeta de vídeo y pinte esa raya.

Esto se hace por varios motivos. Uno de ellos es que permite que los programadores utilicen un periférico sin preocuparse de los pormenores del funcionamiento de éste. Por ejemplo, hoy en día un programa como Word puede imprimir en casi cualquier impresora del mercado, aunque éstas tengan características muy distintas entre sí.

Otro de los motivos es que con varios programas en ejecución simultáneamente, hay que asegurarse de que cada uno accede correctamente al periférico, sin interferir el trabajo de los demás.

¿Cómo consiguen los SO que un programa sea capaz de imprimir en cualquier impresora del mercado? Pues mediante los drivers o controladores. Cuando compramos un periférico, por ejemplo una impresora, suelen venir acompañados de un CD o disco que contiene los “drivers”. Estos drivers son pequeñas porciones de código que se integran en el sistema operativo, y ese es el código que maneja el hardware.

Los programadores, disponen de una serie de servicios que el sistema operativo presta con respecto al hardware, y que comúnmente se denomina un API (Application Program Interface).

Por ejemplo, cuando un programa quiere conocer la posición del ratón en la pantalla, el programador dispone de un servicio (una función) que le presta el SO y que le permite consultar esa posición. Si un programa solicita esa función al SO, el SO se la pide al driver del ratón, que es el que realmente se comunica con él.

Por poner un símil, es como cuando vamos a un restaurante de hamburguesas y pedimos una hamburguesa con queso sin pepinillos y sin salsa. Nosotros nos dirigimos al empleado que hay detrás del mostrador, y éste a su vez dirige la orden a la cocina, que es donde realmente se prepara la comida. Cuando está lista, la entregan al dependiente, que finalmente la entrega al cliente.

Más o menos, podemos aplicar el mismo esquema cuando un programa desea algo de algún periférico.

Expresándolo de otro modo, varios programas que están ejecutándose simultáneamente, acceden a los periféricos siempre a través del SO, y éste utiliza a los drivers de cada periférico para controlarlo.

Volvamos al principio

Este artículo comenzaba hablando del interfaz de usuario. No nos olvidaremos de él.

Desde el punto de vista de la programación, el SO brinda a los programas una serie de servicios o funciones (un API) para comunicarse con el usuario. Estas funciones son de lo más variopinto, pero intuitivamente podemos asumir que tratan con ventanas, menús, barras de desplazamiento, cajas de edición, fuentes, colores, etc.

• < Previo
• Siguiente >