Disponible la versión 6 de OrganiZATOR
Descubre un nuevo concepto en el manejo de la información.
La mejor ayuda para sobrevivir en la moderna jungla de datos la tienes aquí.

Curso C++

[Home]  [Inicio]  [Índice]


0.2  El Sistema Operativo

§1  Presentación:

Podríamos repetir aquí lo indicado al tratar del Ordenador Electrónico Digital ( 0.1). Deberían ser igualmente conocidos por cualquier estudiante de C++ unos mínimos conceptos generales sobre los Sistemas Operativos, puesto que sin un mínimo "background" en la materia, difícilmente se puede ser un buen programador C++. Incluso diría más; seguramente se necesite un conocimiento más que mediano sobre la plataforma que utilice, y si es el caso de un Sistema "moderno" del tipo de MS Windows, este conocimiento es vital, ya que precisamente una de las características de estos entornos es que hay que acudir a los "servicios" del sistema virtualmente para cualquier cosa que queramos hacer ( 1.7).

El problema es que un sistema moderno como Windows es bastante complejo, y aunque es cierto que algunos lenguajes encapsulan los servicios del sistema mediante una capa de software añadido, que intenta enmascarar su complejidad, como dice Petzold ( PW5E):  "Antes o después esta complejidad saltará fuera y le morderá la pierna".


El presente capítulo incluye unas pinceladas generales sobre esta parte del software que controla el funcionamiento del ordenador, introduciendo algunos conceptos que son imprescindibles para entender otros relacionados con la multiprogramación y multitarea, además de ser fundamentales para entender como y porqué funcionan los programas C++ (o de cualquier otro lenguaje) en los entornos operativos actuales. Sus características las personalizaremos en el Sistema Windows de MS por ser el más popular. Aunque este conocido sistema ha sufrido paulatinas mutaciones, nos referiremos a las que se implementan en las versiones actuales de 32 bits.

§2  El Sistema Operativo

Desde el punto de vista funcional, el Sistema Operativo (SO) es el supervisor de cualquier actividad que se ejecuta en el ordenador. Me gusta decir que el SO viene a ser como el soplo de vida que hace funcionar la máquina. Sin él, el hardware se compararía a un ser humano en coma profundo; quizás con un gran potencial pero incapaz de ninguna acción.

Nota: el término Sistema Operativo data, de finales de los 50. En toda esta obra nos referimos a él como el "Sistema" (con mayúsculas) o por su acrónimo "SO". Cuando utilicemos minúsculas (el sistema) nos referimos al ordenador como conjunto.


En realidad el SO está constituido por un conjunto relativamente grande de programas; solo hay que considerar la ingente cantidad de espacio necesario para cargar un Sistema Windows actual; incluso en su configuración mínima (el código de Windows 3.11 tenía aproximadamente 500.000 líneas de código, el de Windows 2000 tiene 45 millones). Sin embargo, hablando con propiedad, muchos de estos módulos no pertenecen al "Sistema", son programas de aplicación y utilidades adicionales que no tienen que ver demasiado con aquél, sino con técnicas comerciales y de márketing. Pero esto... es ya otra historia.

§3  Programas de aplicación

Desde un punto de vista estructural, el software que controla el funcionamiento de un ordenador está organizado por capas ( 1.7a).De estas, el Sistema Operativo es una capa intermedia, situada entre los programas de aplicación y los controladores de dispositivos ("drivers").

La capa superior, constituida por los programas de aplicación, es la encargada de realizar tareas directamente utilizables por el usuario. Un procesador de textos, una hoja de cálculo, un navegador Web, etc. Son el tipo de programa que, con más probabilidad, será objeto de atención del programador C++ [2].

Una característica de los programas de aplicación es que están compilados para un Sistema específico [10]. Por ejemplo; un procesador de textos WordPefect para Linux correrá en cualquier plataforma hardware que tenga cargado dicho sistema, con independencia de su configuración concreta:  Modelo de procesador; tipo de disco; tipo de bus interno; tipo de tarjeta gráfica. etc.

§4  Controladores de dispositivos

Por su parte, la capa inferior del Software está constituida por unos programas que actúan de interfaz entre el hardware y el Sistema Operativo. Son los denominados controladores de dispositivos, porque son ellos los que controlan los dispositivos hardware.

Nota:  En la arquitectura PC, algunos de estos controladores de dispositivos E/S están integrados en las rutinas de la BIOS ( H4).


Los "drivers" son específicos de cada elemento hardware y Sistema que deba manejarlo, de forma que para un determinado Sistema existen tantos drivers como dispositivos hardware deba soportar. A la inversa, cada fabricante de hardware, por ejemplo digitalizadores, impresoras, controladoras de disco etc. debe disponer de un controlador específico para cada modelo y Sistema Operativo distinto con el que deba usarse el modelo en cuestión.

Nota:  los "drivers" instalables (que se pueden cargar como cualquier otro programa durante la carga inicial del Sistema) se materializan en ficheros [13] y permiten que el SO pueda configurarse según las características particulares de la máquina o preferencias del usuario. Su introducción constituyó un factor de flexibilidad y progreso considerable para los SO's. En MS-DOS este proceso es controlado con un fichero "Script" denominado CONFIG.SYS.

A principios de los 90 era frecuente que, junto con cada nuevo elemento hardware que se adquiriese, el fabricante añadiera un disquete con los "drivers" para los SOs más conocidos, por ejemplo, Xenix, Windows 3.1,  OS/2 etc. En la actualidad, todavía se siguen incluyendo estos programas en forma de disquete o CD. El propio Windows incluye cientos de tales controladores para los modelos de hardware de los fabricantes más conocidos (incluyendo algunos denominados "Genéricos" o estándar); estos controladores son proporcionados a MS por los fabricantes [3].


Los controladores de dispositivo se suelen agrupar en alguna de las siguientes categorías o clases:

  • Adaptadores de audio (tarjetas de sonido).
  • Dispositivos de comunicación (infrarrojos, módems, etc).
  • Dispositivos de visualización; pantallas (displays).
  • Teclados.
  • Ratón ("mouse" y otros señaladores gráficos).
  • Dispositivos multimedia.
  • Dispositivos de Red.
  • Impresoras.
  • Almacenamiento
§4  El núcleo

Como el resto del software, también el SO está construido por capas. Las interior, la que representa su parte más íntima, el "Kernel" o núcleo [1], es un programa multihebra que reside permanentemente en memoria. Se ocupa básicamente de tres tareas primordiales:

  • Gestión de memoria.
  • Gestión de E/S a disco.
  • Control de las tareas en ejecución.

Desde un punto de vista conceptual, quizás sea esta última su actividad principal, de forma que el kernel es antes que nada un gestor de tareas.

Conceptualmente, la gestión del almacenamiento (ficheros de disco), denominada genéricamente como sistema de ficheros ("File System"), no es una parte fundamental del Sistema. De hecho algunos SOs pueden utilizar más de uno (o ninguno). Sin embargo desde un punto de vista funcional, la eficacia del "File System" es determinante en el rendimiento global del Sistema Operativo.

Actualmente se están haciendo importantes esfuerzos para mejorar este apartado, y algunos de los avances más revolucionarios de los futuros SOs vendrán de esta dirección. A título de ejemplo y como pincelada al respecto, incluimos el principio de un artículo de Leander Kahney: "Searching for the Perfect OS", aparecido en Wired News www.wired.com en Julio del 2004:

It may sound idiotically simple, but according to technology's leading seer, Apple CEO Steve Jobs, searching for information -- not sorting it -- is the wave of the future.

At Apple's Worldwide Developers Conference in San Francisco this week, Jobs declared that searching for information on a hard drive, rather than sorting into files and folders, is the future of computing.

"We all have a million file folders and you can't find anything," Jobs said during his keynote speech introducing Tiger, the next iteration of Mac OS X, due next year.

"It's easier to find something from among a billion Web pages with Google than it is to find something on your hard disk," he added.

The solution, Jobs said, is a system-wide search engine, Spotlight, which can find information across files and applications, whether it be an e-mail message or a copyright notice attached to a movie clip. "We think it's going to revolutionize the way you use your system," Jobs declared.

In Jobs' scheme, the hierarchy of files and folders is a dreary, outdated metaphor inspired by office filing. In today's communications era, categorized by the daily barrage of new e-mails, websites, pictures and movies, who wants to file when you can simply search? What does it matter where a file is stored, as long as you can find it?


§3  La máquina virtual

La descripción "oficial" de Windows nos dice que es un Sistema gráfico, multiprograma y multihebra. Dejando aparte los aspectos gráficos, su característica más notoria para el usuario es su capacidad de multiprogramación; lo que permite que puedan ejecutarse de forma simultanea y sin interferencias diversas aplicaciones.

Para implementar esta capacidad, Windows crea un entorno de ejecución propio e independiente para cada tarea; es como si cada aplicación corriese en una máquina independiente, que por esta razón se denomina máquina virtual (MV).

Puesto que los dispositivos físicos son únicos y además pueden ser distintos en cada máquina, se crean también unos dispositivos virtuales (designados de forma genérica como VDs, "Virtual devices") que representan, de forma ideal y normalizada, el "hardware" de las máquinas virtuales. De esta forma se consigue que las MV utilicen un hardware virtual que es independiente del hardware real [4].


Las máquinas virtuales se materializan en una tarea en la que se ejecuta una aplicación y un determinado software de soporte (los controladores virtuales de dispositivo ), que proporcionan a la aplicación una simulación prácticamente perfecta del ambiente que pretenden recrear. La aplicación dispone de todos los posibles dispositivos y servicios como si fuesen reales, incluyendo controlador de interrupciones programable PIC ("Programmable interrupt controller" H2); tabla de vectores de interrupción ( H2.4); servicios de E/S ( H2.1); memoria; registros de UCP ( H3.2); servicios de BIOS ( H2.4.1); acceso directo a memoria (DMA H2.3), etc.

Las implicaciones prácticas son trascendentales, porque a fin de cuentas, cualquier programa Windows está pensado para correr en una de estas máquinas virtuales, lo que le hace realmente independiente del hardware. Se consigue también que los servicios del sistema, encapsulados en librerías .DLL ( 1.4.4b), puedan escribirse igualmente para un entorno independiente del hardware, ya que proporcionan servicios a máquinas virtuales.


El artificio de la máquina virtual no es nuevo. Los mainframes han utilizado desde siempre técnicas análogas para soportar multiprogramación, pero su aplicación de forma segura en la informática personal solo pudo realizarse, cuando a partir del Intel 80386, los microprocesadores dispusieron de determinadas capacidades hardware. Es lo que se conoce como funcionamiento en modo protegido ( H5.1), que presenta una doble ventaja:

  • Simplificar la gestión de estas tareas, que son manejadas por el hardware del procesador en vez de utilizar recursos estrictamente software (el procesador garantiza de forma segura la independencia entre las diversas tareas).
  • Realizar gran parte del control con recursos hardware preconstruidos en el procesador, lo que acelera el rendimiento global del sistema.
§4  Dispositivos virtuales

La máquina virtual utiliza recursos virtuales; estos recursos pueden ser elementos hardware o software, aunque de forma genérica los denominamos dispositivos virtuales  (VDs).

Los VDs son utilizados mediante controladores de dispositivo también virtuales VxDs. Observe que los VDs no existen, son en realidad una abstracción conceptual. Lo que si tiene existencia real son estos controladores virtuales VxDs, representados por ficheros de terminación .VXD.

Estas piezas de software "virtualizan" los mencionados dispositivos, de forma que se comportan hacia la máquina virtual como si estuviese dialogando con un dispositivo hardware real y le proporcionan los mismos servicios que si los dispositivos físicos estuviesen realmente disponibles. La particularidad es que este hardware es ideal, en el sentido que es normalizado. Por ejemplo, para una aplicación que corre en una máquina virtual, la controladora de video es siempre la misma, con independencia de cual sea el modelo realmente conectado.

Así pues, aunque son conceptos distintos, a efectos prácticos los VDs y los VxDs pueden tomarse como sinónimos. Los primeros son abstracciones y los segundos son ejecutables que simulan (virtualizan) dicha abstracción de forma que parezca que las MVs disponen de ciertos recursos (hardware o software) estándar. Aunque la mayoría de los VxDs manejan dispositivos hardware (sus E/S), otros manejan o reemplazan determinados recursos software, por ejemplo rutinas de ROM BIOS.


Estos dispositivos virtuales son únicos, y compartidos por todas las máquinas virtuales que los necesitan en cada momento. Cualquier dispositivo hardware puede ser utilizado sucesivamente por diversas MVs, de forma que si su estado puede ser alterado al cambiar de una máquina virtual a otra,  el dispositivo debe ser utilizado a través de un controlador virtual, que se encarga de restablecer el estatus a los valores correspondientes.

Muchos dispositivos hardware utilizan interrupciones para avisar que los datos están listos o que ellos mismos lo están [11]. Los dispositivos virtuales raramente interceptan estas interrupciones por sí mismos. En su lugar utilizan el Controlador programable de interrupciones virtual VPICD . Para ello instalan un procedimiento callback ( 1.4.4b2a) que es utilizado por VPICD cuando ocurre una interrupción hardware.

Como el lector puede suponer, no existe limitación teórica en cuanto a la cantidad o funcionalidad de los VxDs. Los Sistemas Operativos Windows incluyen VxDs que soportan los dispositivos hardware y software más usuales;  además disponen de las herramientas necesarias para que el usuario pueda crear los que necesite para atender las características especiales de nuevos dispositivos o modificar los existentes [7]. La realidad es que en última instancia, los VxDs de Windows manejan absolutamente todos los dispositivos, desde el sistema de archivos a las tarjetas de sonido y dispositivos de red, ya que proporcionan soporte a un software básico como son los servicios del sistema (encapsulados en las DLLs).

A continuación se relacionan los que actualmente pueden considerarse como estándar, junto con el acrónimo por el que son conocidos y los servicios que proporcionan:

  • Dispositivo de acceso directo a memoria ("Virtual Direct Memory Access Device" VDMAD)

    Este dispositivo virtualiza los accesos directos a memoria DMAs ("Direct Memory Access"). El fichero fuente es VDMAD.VXD.

  • Controlador MS-DOS ("DOS manager" DOSMGR)

    Controlador de dispositivo que virtualiza un Sistema MS-DOS.

  • Intercambiador de páginas de memoria (PAGEFILE y PAGESWAP)

    Controlador de dispositivo encargado de manejar memoria virtual mediante un mecanismo de intercambio de páginas (page swapping). El fichero fuente es DYNAPAGE.VXD.

  • Controlador programable de interrupciones virtual ("Virtual PIC Device" VPICD)

    Controlador de dispositivo que virtualiza el controlador programable de interrupciones PIC ("Programmable interrupt controller"  H2.4).

  • Controlador de memoria virtual (V86MMGR)

    Controlador de dispositivo que virtualiza los modelos de memoria XMS (Extendida) y EMS (Expandida) para aplicaciones que corren en una máquina virtual x86 (V86).

  • Cargador virtual de dispositivos  ("Virtual x Device Loader" VXDLDR)

    Este controlador es en realidad un servicio para el funcionamiento de las máquinas virtuales, ya que permite cargar y descargar dinámicamente (en tiempo de ejecución) los propios controladores virtuales (VxDs).

  • Cache virtual ("Virtual CACHE"  VCACHE)

    Controlador virtual que proporciona servicios de caché ( H5.2).

  • Coprocesador matemático virtual ("Virtual Math Coprocessor" VMCPD)

    Controlador que virtualiza el coprocesador matemático.

  • Dispositivo virtual de energía ("Virtual Power Device" VPOWERD)

    Este dispositivo virtualiza los servicios de ahorro de energía que son estándar en muchos dispositivos actuales. Por ejemplo, placas-base, controladores de disco, etc.

  • Shell virtual ("Virtual Shell Device" SHELL)

    Controlador de dispositivo que virtualiza servicios de shell ( 1.7.3). En este caso, el SHELL se refiere a servicios de envío y visualización de mensajes, monitorización de las propiedades de las máquinas virtuales y comunicación con otras aplicaciones, en especial con librerías de enlazado dinámico (DLLs).

  • Interfaz virtual para el temporizador ("Virtual Timer API" VTDAPI)

    Controlador de dispositivos que virtualiza servicios de temporizado.

  • Temporizador virtual ("Virtual Timer Device" VTD)

    Controlador que virtualiza el reloj del sistema.

  • Servicios virtuales de Windows-32 ("VWIN32 Services" VWIN32)

    Este controlador que virtualiza servicios de VxDs de Windows 32.

§4  Gestor de máquinas virtuales

Con las premisas anteriores, resulta evidente que, en cada momento, deben existir tantas de estas máquinas virtuales como aplicaciones distintas estén en ejecución. Esta tarea de mantenimiento, sincronización, creación y destrucción de las MV, es realizada por un programa supervisor, el denominado VMM ("Virtual machine manager"), fichero VMM32.VXD en un Sistema Windows 32.

El VMM trabaja con librerías de enlazado dinámico de 32 bits que proporcionan las funciones y recursos gráficos que necesitan las aplicaciones Windows. Trabaja también con dispositivos virtuales a través de controladores virtuales;  todo ello en modo protegido, lo que permite a los dispositivos virtuales interceptar interrupciones y fallos, de forma que se puede controlar el acceso a los dispositivos y al software instalado por parte de las aplicaciones que corren en las MVs.


§4.1  En realidad, este gestor de máquinas virtuales es el corazón del Sistema Operativo. Su tarea principal es crear, correr y controlar las MVs en las que corren las aplicaciones. Para ello ofrece un servicio de multiprograma preemptivo de tarea única (single-threaded) en el que el tiempo de UCP se comparte entre las diversas máquinas virtuales.

Cuando el VMM arranca, la primera máquina virtual que crea es la Máquina Virtual del Sistema SVM ("System virtual machine"), capaz de contener aplicaciones Windows de 16 bits [5], aunque también pueden crearse MVs para programas Win32 y aplicaciones MS-DOS si son necesarias. La SVM puede tener varias hebras de ejecución, las demás solo pueden tener una.

El proceso es como sigue:

Inicialmente, el programa WIN.COM carga el fichero VMM32.VXD que contiene el VMM y los controladores virtuales por defecto. El VMM se carga en memoria extendida utilizando un controlador virtual; se inicializa a sí mismo y a los controladores virtuales. A continuación conmuta a un modo de ejecución protegido [12]. El resultado es que el VMM y los controladores virtuales corren en un espacio contiguo de direcciones de 32 bits (flat model address space) denominado anillo 0 (ring 0).

A partir del 80386, los procesadores Intel que "motorizan" los PC's tienen 4 niveles de protección interna en forma niveles de privilegio denominados anillos ("Rings") numerados de 0 a 3. El anillo 3 es donde residen las aplicaciones Windows; el anillo 0 es donde reside el código con mayores privilegios. Por ejemplo el kernel del SO y los programas VxDs que pueden manejar directamente los puertos de E/S ( H2.5). Un código del anillo 0 no solo puede interceptar directamente las E/S de cualquier puerto físico, también redireccionarlas en caso necesario, lo que le permite virtualizar o emular cualquier dispositivo como un modem o un ratón


Cuando se inicializan los controladores virtuales, suelen instalar funciones callback ( 1.4.4b1) para procesar interrupciones y fallos; además asignan memoria para los servicios asociados a la máquina virtual. Generalmente el último controlador virtual que se inicializa es el Shell virtual , que carga el programa KRNL386.EXE (el kernel de Windows), que se encarga a su vez de cargar otros módulos del sistema, el último de los cuales es el Shell de Windows 95/98 (su representación en pantalla es el escritorio).

§4.1  Manejador y bloque de control de la máquina virtual

Un punto muy importante para comprender después las particularidades de la programación C++ para Windows, es conocer que, junto con cada máquina virtual, el VMM crea una estructura (en el sentido C del término 4.5), el denominado Bloque de Control CB ("Control block") que contiene una serie de datos sobre la MV, que se necesitan por el VMM y los controladores virtuales.

Entre otros el CB contiene los siguientes datos:

  • Estado de la máquina virtual. Existencia:  Si está creada o destruida. Actividad: si está en ejecución o suspendida.
  • Identificador;  las aplicaciones Windows pueden identificarse por un nombre.
  • Dirección del espacio de memoria más alto utilizado por la aplicación.
  • Dirección de los registros de la máquina virtual cliente de la aplicación. Tenga en cuenta que cada máquina virtual tiene su propio juego de registros, que reflejan el de los registros del procesador para la aplicación que está corriendo la MV. Cuando el VMM recibe control de una aplicación, el estado de los registros de esta es guardado en la pila del anillo 0 .

Junto con el bloque de control, el VMM crea un manejador "handle" [9], que en este caso es un puntero al espacio de memoria donde comienza el CB. Tanto el VMM como los VxDs utilizan este manejador para designar la máquina virtual sobre la que se realizan las operaciones que ellos promueven.

§4.2  El VMM y la multitarea

El VMM utiliza un planificador de tiempos y prioridades que hace posible una multitarea preemptiva ( 1.7) para las aplicaciones que corren en las MVs. El VMM asigna una prioridad a cada MV en el momento de su creación; prioridad que puede ser aumentada o disminuida en "Runtime", tanto por el VMM como por los VxDs. Solo la MV que tiene la prioridad más alta, recibe tiempo de ejecución, pero los cambios de prioridad antes aludidos originan que el tiempo de ejecución conmute de una MV a otra.

En ocasiones el VMM puede aumentar la prioridad de una máquina virtual que necesite prestar servicio a la interrupción de alta prioridad de un dispositivo, por ejemplo la llegada de datos a un puerto serie.

Además de la prioridad de ejecución, el planificador del VMM tiene dos valores que indican la prioridad de tiempo de ejecución que será asignado a cada MV en primero y segundo plano ("Foreground" y "Background" [6]).

El VMM utiliza la prioridad de primer plano para determinar si una MV recibirá tiempo de proceso si está en foco. En caso contrario, el VMM utiliza la prioridad de segundo plano. Es interesante observar que en la programación de aplicaciones Windows, es posible establecer como se comportará el Sistema con la aplicación. Por ejemplo, si alguna otra dispondrá de tiempo de ejecución mientras ella tenga foco, o si tendrá posibilidad de tiempo de procesador mientras no sea la aplicación de primer plano.

Nota:  Esta última característica de Windows puede ser puesta en evidencia muy fácilmente. Para ello basta abrir una ventana DOS e iniciar en ella un programa que tarde bastante; preferiblemente uno cuya ejecución pueda ser comprobada fácilmente (por ejemplo porque escriba en pantalla). Mientras está en ejecución abrimos una nueva aplicación Windows, con lo que la ventana DOS perderá foco y quedará en segundo plano.

En este momento su comportamiento dependerá de que esté o no habilitado su funcionamiento en segundo plano;  Si no lo está, la ejecución quedará detenida (congelada) hasta que vuelva al primer pano (vuelva a recibir foco). En el otro caso, la ejecución continuará aprovechando los intervalos que conceda la otra aplicación.

La habilitación/deshabilitación para funcionamiento en segundo plano puede controlarse mediante el icono etiquetado "background" de la barra de herramientas de la ventana DOS. A su vez, el estado inicial (que tiene este interruptor cuando se abre la ventana), puede controlarse en el icono "Propiedades" de la misma barra de herramientas; a continuación señalar la pestaña "Varios". Seleccionando "suspender siempre" en la casilla denominada "segundo plano", se consigue evitar que el programa utilice recursos del sistema cuando no está activo.

Es importante señalar que el programa VMM no es reentrante [8], lo que significa que los VxDs deben sincronizar sus accesos a los servicios del VMM para hacerlo de forma ordenada y sucesiva.

  Inicio.


[1]  En lo sucesivo utilizaremos indistintamente el vocablo inglés y el español. Al citar el "kernel" nos referimos exclusivamente al núcleo del Sistema Operativo.

[2]  C++ es un lenguaje potente que no solo se utiliza para construir programas de aplicación. También para escribir controladores de dispositivos e incluso Sistemas Operativos (gran parte de Windows y Linux están programados en C/C++).

[3]  Puede figurarse el lector las escasas posibilidades de venta para cualquier "cacharro" que actualmente no disponga de un "driver" para Windows. A título anecdótico puedo citar que el motivo de "pasarme" a Windows (sistema al que tenía especial aversión) desde OS/2, técnicamente muy superior a los Windows de la época, fue precisamente la falta del "driver" adecuado a una pieza de hardware que debía instalar. Internet no era accesible para mí en aquellos momentos ni estaba tan extendido. Lo único disponible eran las BBSs ("Bulletin Board Systems"), que podían ser conectadas por modem a las "espeluznantes" velocidades de 600/1.200 baudios mediante llamadas de larga distancia. Teniendo en cuenta las tarifas telefónicas de la época, perder unas horas "buscando por ahí" sin la ayuda de Google (que no se había inventado todavía), podía fácilmente suponer una factura telefónica equivalente a la mitad del sueldo.

[4]  A los estudiantes y programadores de Java, seguramente este asunto de la "Máquina virtual" les suene a algo conocido. Una vez más comprobamos que realmente no hay nada nuevo bajo el Sol...

[5]  Esta descripción corresponde a Windows 95/98.

[6]  "Foreground" y "Background". Términos ingleses que tienen un significado específico en Informática. Cuando se habla de entornos multiprograma, Foreground es el primer plano; se refiere a la aplicación que tienen foco (activa). La que acapara la atención del usuario y mayor cantidad de recursos del sistema, incluyendo tiempo del procesador. Background es el trasfondo o segundo plano. Lo componen las aplicaciones que están abiertas pero no reciben atención o foco en ese momento. En algunos sistemas se sitúan en este segundo plano aquellas aplicaciones de prioridad baja que aprovechan los tiempos de inactividad del foreground (por ejemplo porque esté esperando una entrada de datos del operador) para realizar determinadas tareas que no requieren respuesta inmediata.

[7]  La información y herramientas correspondientes se denominan DDK  ("Device Driver Kit"), y forman parte de MSDN ("Microsoft Developer Network"  1.7.2).

[8]  Un programa, aplicación o rutina reentrante significa que puede ser utilizada por diversos usuarios simultáneamente. Evidentemente, para que esto sea posible, las variables de funcionamiento y la información de estado de cada usuario debe almacenarse por separado. Lo que significa que no pueden utilizar información global -utilizable simultáneamente por varias rutinas-, a menos que dispongan de un mecanismo ("mutex") que garantice que un acceso ordenado a tales valores.

[9]  En la programación Windows utilizaremos hasta la saciedad esta palabra. Traducido literalmente "Handle" es asidero, mango, pero en el ámbito de la programación recibe significados distintos, aunque relacionados. En la programación Windows es un número de 16 o 32 bits que referencia a un objeto. En C/C++ puede ser un puntero, una manejador de fichero, o el punto en que se recibe una excepción. En el capítulo dedicado a las técnicas avanzadas de programación se señala alguna otra acepción ( 4.13.4). En este tutorial usaremos indistintamente el vocablo inglés "Handle" o su equivalente informático español "manejador".

[10]  Podría argumentarse que Java es una excepción a la regla, pero no es totalmente cierto. En realidad los programas Java también están escritos para una plataforma específica, la máquina virtual Java. El hecho de que sea "virtual" y pueda ser emulada mediante software en cualquier plataforma no invalida el principio general. Además el principio no es nuevo ni mucho menos. Desde siempre han existido en informática emuladores de ciertos entornos corriendo en plataformas distintas de las que son emuladas. Por ejemplo, una plataforma Intel - MS DOS emulada sobre Macintosh de Apple (de forma bastante aceptable por cierto).

[11]  Ver una descripción detallada del mecanismo de interrupciones en H2.4

[12]  Es de destacar que a partir del 80386, todos los procesadores Intel que permiten trabajar en modo protegido. En principio arrancan en modo real y es precisa la intervención del Sistema para conmutar al modo protegido ( H5.1).

[13]  En Unix/Linux estos ficheros están el directorio /dev/. Utilizando el comando ls -las /dev/, se aprecia que los controladores tienen una letra en la columna de permisos (la segunda) en vez de un guión como los ficheros normales o una d como los directorios. Esta letra indica el tipo de dispositivo. Los tipos más comunes son b, que indica un dispositivo que maneja los datos de E/S en bloques y c, que indica un dispositivo que maneja E/S de un carácter cada vez (si se miran con Konqueror, se indica directamente Dispositivo de caracteres o Dispositivo de bloques). En la columna de tamaño se encuentran dos números asociados major y minor (primario y secundario) asignados al dispositivo. Estos números indican el dispositivo físico al que esta asociado el controlador.