Dennis Ritchie: cómo C hizo portable a Unix

El 9 de septiembre de 2026 se cumplen 85 años del nacimiento de Dennis Ritchie. Su trabajo en C y Unix cambió cómo podía pasar el software de un ordenador a otro. Pero código portable nunca significó ejecutar el mismo archivo en todas las máquinas.

Imagina que entregas a un amigo un disquete con tu programa. Su ordenador tiene otro procesador, otro sistema operativo y otra forma de manejar los archivos. ¿Le has dado algo que puede ejecutar, un punto de partida para recompilar o un proyecto que tendrá que rehacer? Esa pregunta permite entender a Dennis Ritchie mejor que una lista de aparatos famosos vinculados, de alguna manera, a su legado.

El Heidelberg Laureate Forum sitúa su nacimiento el 9 de septiembre de 1941. Hoy se cumplen 85 años de esa fecha, también recogida en nuestro calendario nerd. La pregunta del aniversario es qué parte del trabajo puede sobrevivir al ordenador para el que fue creada.

C y Unix no hacen el mismo trabajo

C es un lenguaje de programación: permite describir operaciones que un compilador puede traducir. Unix es un sistema operativo: administra recursos y ofrece servicios a los programas. Confundirlos oculta precisamente lo interesante de su relación. Un cálculo no necesita conocer el modelo del disco. El sistema operativo puede facilitar el acceso a un archivo sin exponer todos los mecanismos del dispositivo.

El Computer History Museum reconoce a Ritchie como creador de C y cocreador de Unix junto con Ken Thompson. Sitúa ese trabajo en Bell Labs a comienzos de los setenta. Fue una construcción colectiva, no la invención de todas las capas de la informática por una sola persona.

Podemos separar un programa en tres decisiones: qué debe calcular, cómo solicita servicios y qué instrucciones de máquina realizan el trabajo. Es posible mezclarlas hasta que cualquier cambio afecte a todo. También es posible distinguirlas lo suficiente para sustituir una parte sin tirar las otras dos. La portabilidad empieza cuando esa separación resulta útil de verdad.

La reescritura de 1973 no fue un interruptor mágico

Ritchie y Thompson fechan la reescritura en C en el verano de 1973 en su artículo sobre Unix. El texto archivado es la revisión de 1978 del artículo de 1974. Describe un sistema más fácil de comprender y modificar, aunque de mayor tamaño.

Reescribir un núcleo en un lenguaje de alto nivel cambia lo que debe expresar quien programa. El ensamblador sigue de cerca las instrucciones del procesador. C permite trabajar con funciones, datos y flujo de control mientras el compilador resuelve muchas decisiones sobre instrucciones concretas. La máquina sigue importando; sus detalles rutinarios aparecen menos directamente en el código principal.

La portabilidad tampoco fue el gran plan desde el primer día. En su historia de C, Ritchie explica que el interés llegó después. C evolucionó a partir de B y vivió su etapa más creativa en 1972. Mejorar el entorno de trabajo abrió posibilidades que no estaban fijadas de antemano.

Código fuente portable no significa ejecutable universal

Volvamos al disquete. Puede contener código fuente, un texto legible escrito en C. O puede llevar un ejecutable, ya traducido para un destino concreto. No son el mismo regalo. Un compilador adecuado puede generar distintas instrucciones de máquina a partir de un código fuente apropiado. Copiar el ejecutable antiguo no realiza esa traducción.

Pensemos en un programa pequeño que lee temperaturas y encuentra la más baja. La lógica de comparación no necesita saber nada de la tarjeta gráfica. Si la entrada y la salida emplean funciones disponibles en ambos entornos, quizá sea posible recompilar el mismo código para los dos. Añadir una ventana mediante una biblioteca gráfica específica introduce otra dependencia.

Además, compilar correctamente solo supera una etapa. También deben coincidir las bibliotecas necesarias, los formatos de entrada y el comportamiento esperado. Un archivo puede abrirse sin problemas y contener los números en un formato inadecuado. Dos programas pueden arrancar y aun así interpretar los datos de manera diferente. Comprobar los resultados forma parte de la portabilidad.

Dónde se esconde el ordenador original

Una forma útil de leer un programa consiste en buscar qué presupone sobre su entorno. Hay tres lugares especialmente reveladores:

• La representación de los datos. ¿Da por hecho un tamaño concreto para los enteros? ¿Guarda una estructura copiando directamente su memoria? Un formato de intercambio definido no equivale a una distribución interna en memoria.
• Los servicios del sistema operativo. ¿Cómo obtiene archivos, hora, entradas y otros recursos? Una interfaz pequeña resulta más fácil de adaptar que las llamadas específicas repartidas por todas las funciones.
• El acceso al hardware. El código que habla directamente con un dispositivo debe conocerlo. Encerrarlo detrás de una frontera clara concentra la adaptación; no hace desaparecer el trabajo.

Estas preguntas son nuestra propuesta práctica para examinar código, no una afirmación sobre todos los programas históricos en C. El lenguaje ofrece posibilidades de separación, pero alguien tiene que aprovecharlas. Un programa muy breve puede esconder numerosas suposiciones. Otro algo más largo puede expresar sus requisitos con claridad y permitir que otras personas los comprueben.

El beneficio real: conservar trabajo humano

Stephen C. Johnson y Ritchie documentaron el traslado al Interdata 8/32 en su estudio de portabilidad de 1978. Su criterio práctico era el esfuerzo ahorrado frente a reescribir. Gran parte del código fuente permanecía común entre entornos, aunque seguían haciendo falta adaptaciones.

Ese criterio ayuda a entender el logro. Lo decisivo no es eliminar absolutamente cualquier modificación, sino conservar las soluciones que ya contienen conocimiento: algoritmos, decisiones y una comprensión acumulada del problema. Cambiar de ordenador no debería obligarnos, automáticamente, a resolver de nuevo la misma cuestión desde cero.

Nuestro artículo sobre los ordenadores personales de Steve Wozniak ofrece una lectura complementaria. Son dos preguntas de diseño distintas: ¿cómo hacer accesible una máquina y cómo evitar que el software útil quede atrapado para siempre dentro de ella?

Lee este artículo en otros idiomas: inglés · alemán · francés.

Un pequeño experimento para el aniversario

No hace falta portar un sistema operativo para probar esta idea. Elige un programa pequeño que entiendas. Anota sus entradas y salidas esperadas y localiza una suposición sobre el entorno. Puede ser una ruta de directorio, una codificación de caracteres o una biblioteca para mostrar información en pantalla.

Lleva esa suposición a un punto claramente identificado. Si dispones de otro entorno, recompila allí y compara los resultados usando los mismos ejemplos. Si no, documenta qué habría que verificar al trasladarlo. Eso todavía no demuestra una portabilidad universal. Sí convierte una aspiración vaga en una cuestión concreta que otra persona puede investigar.

Al cumplirse 85 años del nacimiento de Ritchie, es un homenaje apropiado: facilitar que una pequeña pieza de conocimiento siga viajando. C y Unix no borraron las diferencias entre ordenadores. Su historia muestra el valor de reducir el coste de esas diferencias.