Sistemas operativos modernos

La gran ventaja de los archivos ASCII es que pueden exliibirse e imprimirse tal cual, y pue­ den editarse con cualquier editor de texto. Además, si un gran número de programas usa archivos ASCn como sus entradas y salidas, es fácil conectar la salida de un programa con la entrada de otro, como en las canalizaciones de shell. (La plomería entre procesos no se facilita, pero sí es más fácil interpretar la información si se usa una convención estándar, como ASCII, para expresarla.) Otros archivos son binarios, lo que simplemente significa que no son archivos ASCII. Si se es­ criben en una impresora se produce un listado incomprensible que parece estar lleno de basura. Por lo regular, estos archivos tienen alguna estructura interna conocida por los programas que los usan. Por ejemplo, en la figura 6-3a vemos un archivo binario ejecutable sencillo tomado de una versión de UNIX. Aunque desde el punto de vista técnico el archivo no es más que una sucesión de bytes, el sistema operativo sólo puede ejecutar un archivo si éste tiene el formato correcto. Este archivo tiene cinco secciones: encabezado, texto, datos, bits de reubicación y tabla de sím­ bolos. El encabezado inicia con lo que se conoce como número mágico, el cual idenfifica el ar­ chivo como ejecutable (para evitar la ejecución accidental de un archivo que no tenga este formato). Luego vienen los tamaños de los diversos componentes del archivo, la dirección don­ de inicia la ejecución y algunos bits que actúan como indicadores. Después del encabezado vienen el texto y los datos del programa propiamente dicho. Éstos se cargan en la memoria y se reubi- can empleando los bits de reubicación. La tabla de símbolos sirve para depurar el programa. Nuestro segundo ejemplo de archivo binario es un archivo permanente, tomado también de UNIX. Consta de una colección de procedimientos de biblioteca (módulos) compilados pero sin enlazar. Cada uno va precedido por un encabezado que indica su nombre, la fecha en que se creó, el dueño, un código de protección y el tamaño. Al igual que en el archivo ejecutable, los encabezados de módulo están llenos de números binarios. Si se escribieran con la impreso­ ra se obtendría algo incomprensible. Todo sistema operativo debe reconocer al menos un tipo de archivo: su propio archivo eje­ cutable, pero algunos reconocen más. El viejo sistema TOPS-20 (para la DECsystem 20) lle­ gaba al extremo de examinar la hora de creación de cualquier archivo a ejecutar. Luego buscaba el archivo fuente y veía si había sido modificado desde la hora en que se había creado el bina­ rio. En tal caso, recompilaba en forma automáfica el archivo fuente. En términos de UNIX, el programa make se había incorporado en el shell. Las extensiones de archivo eran obligatorias para que el sistema pudiera saber cuál programa binario se había obtenido de cuál fuente. Tener archivos de tipo estricto como éstos causa problemas cuando el usuario hace algo que los diseñadores del sistema no contemplaron. Consideremos, por ejemplo, un sistema en el que los archivos de salida de los programas tienen la extensión .dat (archivos de datos). Si un usuario es­ cribe un formateador de programas que lee un archivo .c (programa en C), lo convierte (por ejem­ plo, a un esquema de sangrado convencional) y luego escribe el programa convertido como salida, el archivo de salida será de fipo .dat. Si el usuario trata de compilar este archivo con el compilador de C, el sistema se negará porque no fiene la extensión correcta. El sistema rechaza­ rá también cualquier intento por copiar archivo.dat en archivo.c por considerarlo incorrecto (para proteger al usuario contra equivocaciones). Aunque esta “amabilidad con el usuario” podría ayudar a los novatos, exaspera a los usua­ rios experimentados, porque deben dedicar un fiempo considerable a buscar formas de sustraer­ se al concepto que fiene el sistema operafivo de lo que es razonable y lo que no lo es.