Código fuente de MSDOS v1.25 y v2.0

Microsoft acaba de publicar en github el código fuente de MS-DOS, v1.25 y v2.0. Lo hace con licencia MIT, una de las licencias más permisivas dentro del software libre.

La versión 1.25 fue la primera que se vendió a aquellos fabricantes que comenzaron a ofrecer clones compatibles con el IBM PC. En la negociación entre IBM y Microsoft, esta última consiguió que pudieran ofrecer el sistema a otros fabricantes, abriendo el camino que aupó a Microsoft hasta ser una de las mayores compañías de software del mundo.

Aunque el código fuente fue publicado en el Computer History Museum el año 2014, tenerlo ahora en github y permitir su uso con una licencia tan permisiva abre un abanico de oportunidades a aquellos que quieran estudiar los sistemas de los primeros PC y adaptarlo, llegado el caso, para su uso personal

Ya sólo falta que Apple haga lo mismo con Snow Leopard :)

Autotools, tutorial de uso (VIII): Añadir soporte para ejecutar tests

Introducción

Test-driven development (TDD) es una técnica de desarrollo de software consistente en escribir primero las pruebas que debe de superar una unidad de código determinada, posteriormente implementar dicha unidad y llegado el caso, refactorizarla. Por otra parte, las pruebas se puede desarrollar para probar ciertas unidades de código que ya se tienen . Estos últimos años, donde los sistemas de integración contínua son cada vez más comunes, implementar pruebas que nos permitan detectar cuanto antes problemas en el código es una práctica muy recomendable de ingeniería de software.

Las autotools (automake, autoconf, etc) permite construir de manera fácil los ejecutables de las pruebas. Después de generar el makefile, estas pruebas se ejecutarán con un simple:

make check

Esta pequeña entrada se dan los pasos básicos para poder incorporar a nuestro proyecto que usa las autotools la ejecución de las pruebas.

Añadiendo los tests a nuestro proyecto con automake

Supongamos que tenemos una estructura de directorios tal que así de un proyecto llamado tut6:

tut6
  src
    tests

Queremos que cuando se ejecute la orden make check se ejecuten los tests necesarios de nuestro paquete de software. Estos checks pueden ser programas compilados o bien scripts que llaman a otros programas. Para eso, se define una varible TESTS en nuestro Makefile.am situado en el directorio tests, que es donde residierán los programas o scripts que se quiere ejecutar en la fase de pruebas. Por ejemplo, si el programa que hace los tests se llama list_test bastaría con poner en el Makefile.am:

TESTS = list_test

Por otra parte, puede que sea necesario compilar programas específicos para tests, que no se instalarán y que sólo se ejecutaran cuando el usuario quiera pasar los tests. Para ello existe una serie de variables, cuyo prefijo es check_ que nos permitirán compilar el programa, librerias, etc que nos interese durante la ejecución de los pasos asociados al make check.

Siguiendo el ejemplo anterior, supongamos que el programa list_test depende del fichero list_test.c y del fichero situado en las fuentes list.c. Queremos que dicho programa se compile cuando se ejecuta la orden make check en nuestro proyecto. Bien, pues basta con añadir a nuestro fichero Makefile.am las siguientes líneas:

TOP = $(top_srcdir)
TESTS = list_test
check_PROGRAMS = list_test
# List lib
list_test_SOURCES = list_test.c $(TOP)/src/list.c
list_test_CFLAGS = -I$(TOP)/src/

Como puede verse, las variables se establecen con el prefijo del programa (list_test_ en este ejemplo) corresponde a opciones que se pasarán al compilador de C (si fuera, C++, sería _CPPFLAGS)

Puede encontrarse el código de un ejemplo de todo lo anterior en tut6

Tutorial de las autotools. Índice de artículos

Hace algunos años escribí varios artículos en el blog a modo de tutorial sobre el uso de las autotools . Para que la información sea más fácil de localizar, he organizado este pequeño índice con los artículos.

• Autotools, tutorial de uso (I): Introducción
• Autotools: Tutorial de uso (II), un ejemplo sencillo
• Autotools, tutorial de uso (III): Las rutas de instalación
• Autotools, tutorial de uso (IV): Las rutas de instalación en make
• Autotools, tutorial de uso (V): Añadiendo opciones
• Autotools (VI): Creando librerías estáticas
• Tutorial autotools (VII): Crear librerías dinámicas con libtool
• Autotools, tutorial de uso (VIII): Añadir soporte para ejecutar tests

Aunque hace bastante tiempo que no escribo sobre el uso de esta herramienta, tengo otro par de artículos en la recámara que estoy retocando para añadir a esta lista. Espero que os sea útil.

The Art Of The Algorithms

(vía RomanSoft) Para el que le guste la Demoscene - esa manera de hacer arte programando los ordenadores - , os dejo aquí este documental titulado The Art Of The Algorithms. ¡Disfrutadlo! :)

Los cohetes en el INTA

Hace unos días, leyendo el foro FAS, encontré una referencia al INTA-156 Banderilla: Se trataba de un misil aire aire de guía infrarroja que se empezó a desarrolar en el Instituto Nacional de Técnica Aeroespacial a finales de los años 60 en colaboración con la francesa Matra. Desconocía que en España se intentó conseguir un misil que mejorara los AIM-9B que por aquellos tiempos se usaban en los aviones comprados a Estados Unidos.

Buscando información sobre dicho misil, encontré un libro publicado por el INTA, Los Cohetes del INTA (pdf) donde se da una descripción bastante detallada de lo que se empezó a desarrollar en España desde la década de los 40 hasta nuestros días, con un capítulo completo dedicado al Capricornio, una investigación que de seguir adelante nos hubiese dado la posibilidad de poner en órbinta mini satélites de 50 kg. Este proyecto - como tantos otros - fue abandonado por el INTA. Quizás - y esto es mera especulación - por los complejos españoles de una tecnología dual con usos militares como era esta.

Sólo he leído la parte del misil INTA-156 Banderilla, y es bastante interesante para aquellos que les guste la tecnología de estos misiles guiados. Otro proyecto cancelado - y especulando de nuevo -, probablemente la venta por EEUU de un AIM-9 Sidewinder más avanzado que el que teníamos (la versión B) hiciera perder al Ejército del Aire el interés en este proyecto.