A una indecisión pegado

Air and Rod

2011-05-22T10:41:00.000+02:00

Tu pequeño padawan te echaba de menos.

Ilusiones

2011-03-02T23:19:00.002+01:00

Me parece enormemente curiosa la manera en que la vida da giros inesperados y te sorprende con cosas que jamás hubieses esperado. Cosas que solamente unos meses atrás hubiesen parecido situaciones imposibles si en algún momento las hubiesen planteado.

A mí, al menos, me parecían imposibles.

Pero esos imposibles se han convertido en hechos y últimamente duermo mejor, me despierto con una sonrisa en la cara y hago aquellas cosas que hago con más ilusión y con más ganas.

Y la responsable directa de todo eso es una persona, probablemente la única persona que lea esta entrada (espero que esbozando esa dulce sonrisa que tanto me gusta en su cara).

Todo esto que está sucediendo me hace recordar esa hermosa obra maestra que es Blankets de Craig Thompson cuando el autor dice: Qué satisfacción produce dejar una marca en una superficie en blanco. El dibujar el mapa de mis movimientos... ...sin que importe que no sea para siempre.

No importará si esto que sucede no es para siempre, porque mientras tanto el viaje está siendo maravilloso.

Gracias, pequeña.

qtDbf 0.9.3 en eComStation

2011-02-03T19:51:00.003+01:00

Ahora he compilado qtDbf 0.9.3 en OS/2 y está disponible en Hobbes. Es la segunda aplicación QT4 que consigo compilar sin problemas.

ehm 0.2 en eComStation: una pequeña calculadora en QT4

2011-02-03T19:06:00.005+01:00

Mi primer "port" para OS/2 de una calculadora muy simple llamada ehm ya está en Hobbes.

Compilarlo ha sido absolutamente trivial.

Adiós, Barry

2011-01-31T13:09:00.004+01:00

John Barry (3 de noviembre de 1933 - 30 de enero de 2011).

Un instalador de gnuplot para Windows

2011-01-20T00:00:00.002+01:00

Esta entrada va dedicada a una amiga que no para de burlarse del abandono de mi blog (aunque también se quejará de lo técnica que es la entrada). Va por ti, pequeña.

Hace unos escasos minutos he terminado un instalador de gnuplot para Windows para mi amigo José Joaquín y se lo he mandado por correo.

Hacía bastante tiempo que no tocaba sistemas de creación de instaladores para Windows tales como Inno Setup, NSIS y MakeMSI. Últimamente había creado algún que otro paquete instalable WarpIN para OS/2 y algún que otro paquete deb para distribuciones Linux basadas en Debian y podría decir que había olvidado el barroquismo y la insuficiencia de la documentación de esas herramientas para Windows, pero mentiría.

Y es que con la influencia recibida por OS/2 por un lado y por Linux por el otro, ciertos detalles de los instaladores de Windows le hacen a uno pensar que Windows está mal diseñado (tal vez algún día explique por qué tengo esa impresión, pero hoy no).

A pesar de todo, ha sido estimulante.

newLISP 10.2.8 en eComStation

2010-05-31T19:01:00.003+02:00

Estos días he conseguido compilar la última versión del intérprete newLISP (la 10.2.8) para OS/2. He subido a Hobbes el resultado, si bien sé que al menos tiene un fallo (el servidor web que incluye solamente funciona con páginas estáticas).

Todo el mérito de mi compilación lo tiene Norman Deppenbroek. Me he limitado a ejecutar:

make -f makefile_os2

y a añadir un icono.

QT 4.6.2 en eComStation

2010-05-30T22:39:00.002+02:00

No deja de resultarme sorprendente la vitalidad de un sistema operativo que lleva "muerto" desde hace diez años.

Gracias a las donaciones de usuarios de este viejo sistema operativo, netlabs ha conseguido pagar el trabajo de Dmitry A. Kuminov que ha terminado con una versión de QT 4.6.2 para eComStation. Esto ha abierto la posibilidad de que docenas de aplicaciones basadas en la célebre librería gráfica de Nokia estén disponibles para el sistema operativo.

El australiano Paul Smedley ha actualizado los ports de LyX y Scribus; Silvan Scherrer ha actualizado los de KDiff3, SMPlayer, QBitTorrent y Blubbels; el coreano KO Myung-Hun ha actualizado su beta de VLC... E imagino que eventualmente el holandés Elbert Pol actualizará algunos de sus ports como el editor S.T.E (entre muchos otros) y el japonés que ha hecho el de Qwit también lo actualizará.

Espero ver algunos programas más en eComStation funcionando en breve gracias a QT 4.6.2:

- YACReader: es un lector de cómics. Visualiza cómics en formatos CBR y CBZ.
- Kid3: es un editor de etiquetas para ficheros de audio.
- Arora: es un navegador web basado en WebKit.

Es cierto que yo mismo he sugerido como característica para nuevas versiones de Lucide un nuevo plugin que permita abrir cómics en formato digital. También es cierto que ya existen dos programas de edición de etiquetas en OS/2 basados en QT4. Y es muy cierto que hay versiones de Firefox y SeaMonkey para OS/2...

...pero me gustan las alternativas.

Aquellos usuarios de Windows, Linux, Mac OS X o cualquier otra plataforma que tenga su versión de QT deberían echarle un vistazo a todos estos programas. Son alternativas interesantes.

NO SE ASUSTE: 25 de mayo

2010-05-25T00:00:00.000+02:00

Feliz día...

...de la toalla.

muStringConverter 0.2.0

2010-05-24T18:03:00.000+02:00

Acabo de subir a Hobbes la nueva versión de la pequeña utilidad muStringConverter.

Una de las cosas que añade es el menú que copia al portapapeles lo que se encuentra en cada uno de los campos (binario, decimal, hexadecimal, octal y ASCII) tal como puede verse en la captura de pantalla.

Otra de las cosas es menos evidente: he añadido el control externo del programa a través de una tubería con nombre (named pipe en inglés).

Aquellos usuarios de OS/2 o eComStation están habituados a ellas (cuando menos a que se las mencione); numerosos programas las utilizan. El reproductor de audio Z! permite controlar el reproductor a través de una de estas tuberías: pausar la reproducción, salir del programa, preguntar al programa la información sobre el fichero que está reproduciendo, añadir un fichero a la lista de reproducción... El editor de texto Fed permite usar una tubería con nombre para cambiar la posición del cursor... El visualizador de documentos PDF Lucide permite avanzar o retroceder páginas, pasar a modo de presentación y más cosas a través de una tubería con nombre...

En el caso de muStringConverter si en la consola se teclea:

echo *quit > \PIPE\MUSTRINGCONVERTER

el programa se cierra.

Desde un script REXX podríamos hacer lo siguiente:

/**/

pipeName = '\PIPE\MUSTRINGCONVERTER'

call lineout pipeName, '*putbin 1010'
call lineout pipeName
call SysSleep 0.1

call charout pipeName, '*getdec'
say 'Decimal: ' linein(pipeName)
call charout pipeName
call SysSleep 1

exit

Este script simplemente pone la cadena 1010 en el campo de entrada, la convierte como si fuese una cadena binaria y después extrae el valor decimal resultante.

Para aquellos usuarios de Linux y sistemas UNIX acostumbrados a usar tuberías con nombre en sus sistemas operativos: efectivamente, las tuberías con nombre de OS/2 (y de Windows) funcionan de un modo diferente a las de Linux.

Adiós a Martin Gardner

2010-05-23T19:31:00.000+02:00

Martin Gardner, columnista de las revistas Scientific American y Skeptical Inquirer, falleció ayer sábado a la edad de 95 años.

Hace unas semanas pude ver la mal llamada Alicia en el país de las maravillas de Tim Burton. Eso me trajo a la memoria una nota anecdótica de The League of Extraordinary Gentlemen (el segundo volumen) de Alan Moore y Kevin O'Neill respecto al personaje de Alicia tras los sucesos de A través del espejo. A su vez eso me hizo recordar quién fue la primera persona que me habló de la homoquiralidad biológica en la literatura: Martin Gardner en El universo ambidiestro.

(Acerca de este tema llevo tiempo queriendo añadir una entrada en el blog.)

Desde entonces he retomado la lectura de algunos de los pasajes de la obra de Gardner (tanto de sus juegos matemáticos como de sus artículos contra las pseudociencias) a lo largo de estos días. Y tras enterarme hoy mismo de la noticia, como ocurre con cada autor que me enseña tanto y me hace disfrutar en el proceso, no puedo evitar sentirme apenado por su muerte.

Si no habeis leído nada de él, hoy es un buen día para hacerlo. Es lo yo que haré esta noche.

eComStation 2.0 ya está aquí

2010-05-21T18:25:00.000+02:00

Al entrar hoy en OS2 World.Com me he encontrado con el banner publicitario que anuncia la salida al mercado de la nueva versión de eComStation.

El banner muestra a un hombre y a una mujer en blanco y negro sacados de los años cincuenta de los Estados Unidos dándose la noticia por teléfono: Hey listen up! Version 2 is here! (¡Ey, escucha! ¡La versión 2 está aquí!). Se ven las dos versiones del mismo, la Home and Student y la Business Edition, el logotipo del sistema operativo y las palabras secure, versatile, powerfull, reliable (seguro, versátil, poderoso y fiable).

Confieso que he encontrado el anuncio tan encantadoramente pasado de moda e ingenuo que me ha hecho sonreír.

muStringConverter

2010-05-15T12:58:00.000+02:00

Hace un par de semanas subí a Hobbes (el repositorio de aplicaciones de OS/2 por excelencia) una pequeña aplicación que programé allá por el 2004: muStringConverter.

Creo que queda claro por la imagen que es un pequeño programa que se limita a convertir una cadena entre distintos formatos (binario, decimal, hexadecimal, octal y ASCII). Creo recordar que la interfaz fue una imitación de un pequeño programa que me enseñó mi amigo Manolo Pavón por aquel entonces.

En su momento este programa me resultó útil como ayuda para el juego de deducir el funcionamiento del formato MSG. Los ficheros MSG en OS/2 se utilizan como ficheros de mensajes de aplicaciones y son de tipo binario. A golpe de editor hexadecimal y con esta pequeña utilidad, conseguí crear un pequeño decompilador de ficheros MSG escrito en REXX.

Probablemente el hecho de que las cadenas resultantes de la conversión estén en campos de entrada no editables sea un fallo de diseño, pero lo escogí así para que el usuario pueda moverse entre los campos de entrada fácilmente con el teclado.

Tengo una nueva versión lista que añade unos atajos de teclado para copiar los campos de entrada directamente al portapapeles y que además puede controlarse desde una tubería con nombre.

La versión en Hobbes puede encontrarse aquí.

GBM 1.52 o de la timidez de SSI

2007-09-16T23:16:00.000+02:00

Heiko Nitzsche ha actualizado su versión mejorada de GBM (Generalised Bitmap Module) una librería y una serie de utilidades para trabajar con diversos formatos de imagen de mapa de bits (como los formatos JPEG, GIF o PNG). La última versión anterior al trabajo de Nitzsche de la dll (GBM.DLL) forma parte de eComStation 1.2; el procedimiento multimedia para ver ficheros JPEG (un reemplazo del original hecho por IBM, programado por Chris Wolgemuth) depende de esa biblioteca.

El trabajo de Nitzsche no es moco de pavo: ha añadido nuevos formatos y mejorado el soporte de los formatos ya existentes, ha actualizado los visualizadores de imagen, ha añadido un plugin para Firefox (y familia) y otro para Lucide, así como un API que permite previsualizar las imágenes en los diálogos de apertura de ficheros y una extensión que permite acceder a todas estas funcionalidades desde REXX y además todo esto lo hace utilizando compiladores modernos (OpenWatcom 1.7).

De hecho, el conjunto de procedimientos multimedia parte de eSchemes Deluxe denominado Imagination que añade nuevos formatos de imagen al sistema multimedia de OS/2 está basado en el trabajo de Nitzsche.

Y ahora pasamos a Serenity Systems International, los responsables de eComStation y los listados de características de las betas de la próxima versión de su distribución de OS/2 (eComStation 2.0): en ningún lugar se habla de la inclusión de la versión de GBM mejorada por Nitzsche.

Y eso me hace preguntarme por qué SSI realiza tan timidamente muchas modificaciones al sistema operativo (las referentes a ACPI, controladores de tarjetas de red y demás controladores podría decirse que son por necesidad). Hay docenas de programas que podrían ser incluidos y GBM es solamente un ejemplo: programas de grabación de CDs y DVDs (Audio/Data-CD-Creator, dvddao, cdrtools, All2Iso), clientes para compartir archivos (ctorrent -del que parece existir un front-end-), clientes de correo (está incluido Thunderbird, pero RexxMail ¡es tan WPS...!), gestores de descargas (las últimas versiones de wget y el maravilloso Auto WGet Daemon), utilidades varias (la utilidad para el portapapeles ClipView), extensiones REXX (rxu, por mencionar el ejemplo más notable)...

Además, uno supone que no debería ser difícil para SSI sustituir el visor de imágenes incluido en OS/2 por algo más moderno (al estilo del de Windows XP), hacer un conversor de formatos de imagen, un editor de imágenes (al estilo del MS Paint) e incluir un capturador de imágenes sencillo (Gotcha es un punto de partida para hacer uno bien integrado con el sistema, el visor de GBM incluye otro capturador)... por mencionar solamente uno de los tipos de datos que puede manejar un sistema operativo.

¿Por qué no lo hacen? ¿Miedo a que el sistema pierda estabilidad? ¿Falta de recursos económicos y humanos (invertidos en el corazón del sistema, que es esencial para que todo lo demás funcione)? ¿Implicaciones legales? ¿Falta de ideas?

Como averiguar si un script está en una consola

2007-09-15T22:21:00.000+02:00

En un mundo en el que las interfaces gráficas de usuario en general y los entornos de escritorio son algo omnipresente no deja de resultar muy curioso el hecho de que cada sistema operativo ha optado por métodos muy diferentes a la hora de ejecutar sus scripts diseñados para la consola desde el entorno de escritorio. Es decir, cuando hacemos doble click sobre el icono correspondiente al script.

Windows y OS/2, por ejemplo, abren una consola cada vez que se ejecuta un fichero bat o cmd (en el caso de OS/2, los ficheros cmd pueden ser programas escritos en REXX o incluso pueden ser programas escritos en Python o Perl no simples ficheros de proceso por lotes). Windows no ofrece muchas facilidades para ocultar la ventana de la consola. OS/2 ofrece bastantes alternativas para ocultarlo si es necesario y modos de ejecutar pequeños diálogos gráficos cuando la consola está oculta.

BeOS nunca abre una consola cuando se ejecuta un script. Tradicionalmente en BeOS todo aquel script que estuviese pensado para el escritorio utilizaba el comando alert de BeOS que permitía mostrar al usuario pequeños diálogos con sus correspondientes mensajes y botones.

Con los entornos de escritorio usuales en Linux (Gnome y KDE, aunque haya docenas más con muy buenas ideas, por cierto) lo habitual es que el comportamiento fuese el mismo que en BeOS. Actualmente lo usual en Gnome (por ejemplo) es que cuando un usuario hace doble click sobre un script aparezca un diálogo que le pide confirmar si quiere ejecutarlo, ejecutarlo abriendo una terminal, editarlo o cancelar la apertura.

Ocasionalmente puede ser interesante que un script averigüe si se está ejecutando en una consola o no y para ello el comando tty nos puede servir muy bien puesto que la salida de ese comando nos indica el número de terminal en el primer caso o nos dice "not a tty" en caso contrario. Así podemos hacer de forma sencilla lo siguiente:

  #!/bin/bash

  if [ "$(tty)" = "not a tty" ]; then
    echo "No es una terminal"
  else
    echo "Sí es una terminal"
  fi

  exit 0

Lo que en REXX quedaría como:

  /*bin/true;exec rexx "$0" "$@";exit # REXX */

  'tty | rxqueue'
  parse pull tty

  if tty = 'not a tty' then
    say 'No es una terminal'
  else
    say 'Sí es una terminal'

  exit 0

El código de retorno del comando nos da la misma información:

  #!/bin/bash

  tty=$(tty)

  if [ $? = 1 ]; then
    echo "No es una terminal"
  else
    echo "Sí es una terminal" # $? es igual a 0
  fi

  exit 0

En REXX:

  /*bin/true;exec rexx "$0" "$@";exit # REXX */

  'tty > /dev/null'

  if rc = 1 then
    say 'No es una terminal'
  else
    say 'Sí es una terminal' /* rc es igual a 0 */

  exit 0

Esto nos permite, por ejemplo, forzar la ejecución del programa en una terminal:

  #!/bin/sh
  # Ejemplo para BeOS
  # Cada entorno de escritorio tiene su propio ejecutable
  # para la terminal.
  myself=$0
  if [ "$(tty)" = "not a tty" ]; then
    Terminal -t "Ejemplo" /bin/sh -c "$myself"
  else
    echo 'Sí una terminal'
  fi

Con kdialog, zenity o xdialog podemos hacer pequeños scripts interactivos como en el siguiente caso:

  /*bin/true;exec rexx "$0" "$@";exit # REXX */

  current_date = date('S')

  'tty > /dev/null'

  gui = rc

  if gui = 1 then do
    'zenity --title "Escoja su fecha de nacimiento"' ||,
      ' --calendar --date-format %Y%m%d | rxqueue'
    pull birthday_date
    if rc = 1 then
      exit 1 /* Pulsado el botón "Cancelar" */
    end
  else do
    say 'Introduzca su fecha de cumpleaños (19770223):'
    parse pull birthday_date
    end

  age_in_days = say date('B', current_date, 'S'),
                - date('B', birthday_date, 'S')

  if gui = 1 then do
    'zenity --warning --text "Su edad en días es:',
      age_in_days '"'
  else do
    say 'Su edad en días es' age_in_days

  exit 0

La máquina expendedora de ooRexx

2007-09-13T22:10:00.000+02:00

David Ashley, uno de los líderes del desarrollo del intérprete Open Object REXX (también conocido como ooRexx) anuncia hoy en comp.lang.rexx que el servidor de compilación de Open Object REXX está listo y la página asociada para acceder a él, también lo está. Tal como estaba previsto hace ya bastantes meses y como al parecer se comentó en el simposio internacional de este año.Básicamente ese servidor es una máquina con un Fedora Core 6 y un conjunto de sistemas operativos ejecutados como invitados a través de un VMware Server 1.0.3. Por ahora las elecciones no son muy variadas: Fedora 7, Ubuntu 7, Windows 2000 y Windows XP. Esto deja fuera otros sistemas para los que ya existen versiones oficiales del intérprete (AIX, Mac OS X y Solaris) y versiones no oficiales (FreeBSD).Lo que más me llama la atención de esta iniciativa es la enorme conexión que establece entre un lenguaje que deriva de REXX y SmallTalk (y que por lo tanto tiene una tradición tan larga que hace que sea fácil tacharlo de antigüedad) y algo tan en boga y de moda como son las máquinas virtuales.La máquinas virtuales no son el único punto de conexión de ooRexx con cosas que no están nada trasnochadas: gracias a Rony Flatscher y sus alumnos tenemos BSF4Rexx que permite ejecutar código Java desde REXX (desde Object REXX de forma completamente transparente) y código REXX desde Java; gracias también a Rony se puede acceder a OpenOffice y su sistema de componentes UNO desde Open Object REXX permitiendo el control externo de la aplicación, así como el escribir macros en ooRexx; gracias a David Ashley también disponemos de una mod_rexx apto para las últimas versiones del servidor Apache; René Vincent Jansen insinua en su blog que la integración entre ooRexx y el sistema de scripting de Mac OS X es cada vez mejor...En definitiva, la comunidad de viejos dinosaurios se mueve aun y se moderniza. Que el equipo de desarrolladores pongan al servicio de la comunidad esta máquina expendedora que escupe la versión binaria más reciente correspondiente al código almacenado en los depósitos Subversion resulta (al menos desde el punto de vista intelectual) muy estimulante.

Free Pascal Compiler 2.2.0 en OS/2 y eComStation

2007-09-11T23:10:00.000+02:00

Ayer me enteré a través de Barrapunto de la salida de la versión 2.2.0 de Free Pascal Compiler, un compilador de Pascal y Object Pascal de código abierto multiplataforma (OS/2, Linux -versiones de 32 y 64 así como para arm-, FreeBSD, Windows -incluidos Vista y CE-...) y me llama bastante la atención que no se haya mencionado nada todavía en ninguno de los portales dedicados a OS/2.

Y me llama la atención porque Pascal, sus dialectos y sus derivados siempre han dado un buen puñado de programas populares y útiles para OS/2 (dejamos de lado el hecho de que en otros sistemas operativos uno de mis programas favoritos de todos los tiempos esté hecho en Delphi: Total Commander de Christian Ghisler).

Por poner un ejemplo, en este mismo instante estas líneas las escribo en el editor de texto de eComStation, el AE de Aaron Lawrence, que está hecho en Sibyl (una especie de Delphi para OS/2), mientras tengo un cliente IRC hecho con Virtual Pascal (Virtual IRC) conectado y escucho esa deliciosa excentricidad de Mike Oldfield llamada Amarok con el reproductor Z! hecho con Virtual Pascal. Y hay cientos de ejemplos así:

En Virtual Pascal: el reproductor MP3 en modo texto Z! (también disponible para Windows), Web/2 (un estupendo servidor web, ligero y sencillo también disponible para Windows), Virtual IRC (un cliente IRC), Normal Player (un reproductor que usa el sistema multimedia de OS/2)...
En Sibyl o su variante GPL WDSibyl (disponible para Windows): NewView (el nuevo visor de ayuda que es componente de eComStation), AE (el editor de texto que es componente de eComStation), el USB Resource Manager, el programa de configuración de TCP/IP de Reinhard Berger...
En Modula, un lenguaje derivado de Pascal: FTPServer (un estupendo servidor FTP) y Weasel (un estupendo servidor de correo) ambos de Peter Moylan.
En Oberon, otro derivado de Pascal, DrDialog (una herramienta gratuita de desarrollo RAD en REXX).

Viendo la tradición de Pascal en OS/2, me llama la atención que la comunidad en torno a este sistema operativo no se haya hecho hecho eco de la noticia de esta nueva versión del compilador FPC.

Como nota curiosa, he descubierto que el cliente IRC está programado con Virtual Pascal cuando mi amiga Nerea ha intentado pasarme un fichero a través de DCC y el cliente ha dado un típico fallo en tiempo de ejecución de los que dan los programas hechos con ese compilador. Y el fallo era por una razón bastante peculiar: ¡me había quedado sin espacio en mi partición de OS/2!

Macros REXX en IBM Works

2007-09-09T23:59:00.000+02:00

Mientras intento recuperarme de la impresión de ver 300, la adaptación del cómic de Frank Miller al cine (Miller, aunque algunos no le perdonemos aun el guion de Robocop 2, parece tener bastante más suerte en esto que el pobre de Alan Moore), me gustaría hablar de cómo estaban implementadas las macros en una aplicación que ya tiene más de 10 años: IBM Works.

Las macros, desde el punto de vista de un usuario final, son conjuntos de acciones que permiten ahorrar trabajo al usuario en un programa concreto. Ejecutando la macro al pulsar una combinación de teclas, pulsar un elemento de un menú, seleccionarla en un diálogo o como permita el programa, el usuario puede evitar realizar tareas repetitivas como inserta el carácter hebreo aleph, selecciona el párrafo y dale otro formato...

Ocasionalmente, las macros pueden tener una lógica interna más allá de una secuencia de tareas repetitivas y entonces el modo de realizarlas es a través de un lenguaje de programación de macros. Y son de estas macros de las que quiero hablar.

El problema que siempre ha existido con los lenguajes de programación de macros es que son específicos de la aplicación: el cliente IRC mIRC tiene su lenguaje de macros, Microsoft Office hasta ahora ha utilizado una variante de BASIC (Visual Basic for Applications), Open Office ha utilizado otra variante de BASIC, Lotus SmartSuite utiliza LotusScript, el editor de audio Audacity usa su propio lenguaje...

Esto quiere decir que si el usuario desea aprender un lenguaje de macros, probablemente no pueda reutilizar sus conocimientos en otro sitio. Además, en algunos casos, la complejidad del lenguaje de macros para el tipo de tarea que desea el usuario puede resultarle excesiva (se encuentra con tipos de variables, declaraciones, módulos, objetos, métodos, sistemas de componentes y similares incluso para las macros más sencillas).

Cuando hace más de 25 años, Mike Cowlishaw creó el lenguaje de programación REXX, uno de sus propósitos era que fácilmente pudiera ser utilizado como un lenguaje de macros. Y cuando IBM empezó a introducirlo como lenguaje de scripts de todos sus sistemas operativos, también empezó a convertirse en el lenguaje de macros de muchas aplicaciones para esos sistemas.

En el mundo de la informática personal, dos sistemas operativos (uno ajeno a IBM) escogieron implementaciones de REXX como su lenguaje de macros preferido: OS/2 y Amiga OS.

En OS/2 existía un pequeño paquete de oficina llamado IBM Works cuya hoja de cálculo utiliza macros REXX aunque apenas aproveche las posibilidades de esto.

Como puede verse en la segunda imagen, la primera columna corresponde a nombres de personas, la segunda a un NIF (Número de Identificación Fiscal) y la tercera muestra una comprobación de la validez del NIF utilizando una función de la hoja de cálculo IBM Works: =rexx("isValidNIF.fnc",1,1,B4). La función rexx de IBM Works busca un fichero indicado en el primer parámetro (isValidNIF.fnc), decide que el valor de la celda será texto (si tuviésemos 0 en lugar de 1 tras la primera coma, trataría la celda como número) y lo ejecuta pasándole el número de parámetros indicado en el tercero de sus parámetros (en este caso uno)... Y el código de la macro no puede ser más sencillo:

/* isValidNIF.fnc */
  parse arg nif
  letras  = 'TRWAGMYFPDXBNJZSQVHLCKE'
  numeros = '0123456789'

  letra   = right(nif, 1)
  dni     = left(nif, length(nif) - 1)

  select
  when pos(letra, letras) = 0 then
    ret = 'ERROR: Último carácter no es una letra'
  when verify(dni,'1234567890') <> 0 then
    ret = 'ERROR: El NIF debe comenzar por un número válido'
  when letra = substr(letras, dni//23 + 1, 1) then
    ret = 'NIF válido'
  otherwise
    ret = 'ERROR: La letra no corresponde al DNI'
  end

return ret

En esta aplicación concreta, la utilización de REXX como lenguaje de macros se ve reducida a su mínima expresión (al contrario que en casos como gnuplot, gdb, Photo>Graphics, GoServe, EPM...) y a pesar de ello se aprecia la sencillez.

Esto no solventa uno de los problemas de los sistemas de lenguajes de macros: la dependencia de un lenguaje concreto.
Microsoft intentó eliminar la dependencia del lenguaje a través de su sistema de componentes COM que permite utilizar cualquier lenguaje para el que exista un WSE (Windows Scripting Engine) en cualquier aplicación que funcione como WSH (Windows Scripting Host) como son Internet Explorer o IIS, por ejemplo (y no es Microsoft Office, curiosamente), pero el sistema es incómodo para un no iniciado. OpenOffice desde sus últimas versiones permite ejecutar macros en más de un lenguaje, pero el sistema es tan barroco como el caso de los sistemas de Microsoft.
Quizás la aproximación que dando independencia de lenguaje conserva la sencillez es una de las que siguen virtualmente todos los servidores web y algunos editores de texto: la macro se ejecuta por el intérprete deseado y coge la információn necesaria de la entrada estándar, los parámetros y las variables de entorno y devuelve la información a la aplicación a través de su salida estándar. Así es como funcionan los CGIs en los servidores web y las macros en el editor de texto para programadores TextMate (aunque en este caso, la documentación del editor restringe el concepto de macro), por ejemplo.

Es una pena que a veces las cosas sean innecesariamente complejas.

Incidentalmente: en la distribución del intérprete newLISP para Windows puede encontrarse un ejemplo de fichero de Excel que incluye una macro en Visual Basic que define una función que permite ejecutar código newLISP en cualquier fórmula de Excel de un modo muy similar al ejemplo de IBM Works. Y el mismo sistema puede utilizarse para ejecutar código de otros lenguajes.

Synergy en OS/2

2007-09-09T23:25:00.001+02:00

,a href="http://www.netlabs.org":Netlabs,/a: cumple 10 aos, lo que es un buen motivo de celebracin... No es que me haya equivocado de tecla, es que estoy usando el teclado y el ratn del porttil de mi hermana (Windows) en mi ordenador de sobremesa (eComStation). Y que nadie piense que he sido tan bruto como para despedazar el porttil y hacer una chapuza, simplemente estoy usando Synergy a travs de la red. Pero volvamos a mi teclado...

Hace unos días, Netlabs cumplía 10 años y explorando el directorio incoming en su servidor FTP como hago de vez en cuando me tropecé con un misterioso fichero llamado synergybart.zip. El bart me sugería quién era probablemente el autor (Bart van Leeuwen), pero el synergy me dejó descolocado y como la curiosidad extrema es uno de mis numerosos defectos, descargué el fichero y le eché un vistazo para encontrarme... que no llevaba ninguna documentación.

Una rápida búsqueda a través de Google permite ver que Synergy es un programa libre multiplataforma (hay versiones para Windows, Linux y Mac OS X) que permite usar el teclado y el ratón de un ordenador concreto (el servidor) en varios ordenadores conectados en una red. Es decir, podemos tener tres monitores correspondientes a tres CPUs distintas y controlar todos desde el mismo teclado y ratón. Moviendo el puntero a los bordes de un monitor, pasamos al siguiente...

El que comparte el teclado y el ratón funciona como servidor ejecutando synergys.exe con la configuración y los parámetros adecuados. En mi caso, el fichero de configuración synergy.conf es así:

section: screens
        salva:
        fran:
end
section: links
        salva:
                right = fran
        fran:
                left = salva
end
section: options
        screenSaverSync = false
end

En él se indican los nombres de los monitores y además la posición relativa de los mismos (fran está a la derecha de salva y salva está a la izquierda de fran).

Si mi máquina tiene mi como IP la 192.168.0.3 y la de mi hermana tiene como IP la 192.168.0.1 y la mía funciona como servidor, debo ejecutar synergys.exe --config synergy.conf --name salva en mi máquina y synergyc.exe --name fran 192.168.0.3 en el portátil de mi hermana. Mientras que en el caso en el que el servidor es el portátil, debo ejecutar synergys.exe --config synergy.conf --name fran en el portátil y synergyc.exe --name salva 192.168.0.1 en mi ordenador.

La versión de OS/2 del servidor parece no funcionar bien; solamente consigo que el puntero en el portátil se mueva, pero renqueando y sin que funcionen los botones y el teclado envía la señal al servidor en lugar de al cliente. (Digo parece porque puede ser culpa de la configuración.) La versión de OS/2 del cliente parece funcionar bien, salvo por lo que queda patente en el primer párrafo de la entrada.

De hecho, lo más espectacular es ver cómo se copia y pega texto del clipboard (portapapeles) de forma completamente transparente entre una máquina y otra. (ClipView, la utilidad de Dave Saville también permite compartir el portapapeles entre dos máquinas a través de la red.)

La sentencia parse version

2007-09-08T20:47:00.000+02:00

La instrucción parse de REXX permite, entre muchas otras cosas, saber con qué intérprete y qué versión del mismo estamos trabajando. A través de la sentencia parse version rexxVersion, el intérprete da a la variable un valor que indica el nombre del intérprete, el nivel del lenguaje y la fecha del intérprete.

Así, por ejemplo, si es el intérprete de REXX clásico de eComStation el que interpreta el código, la variable valdrá REXXSAA 4.00 3 Feb 1999. Si es Regina, puede resultar algo como REXX-Regina_3.3(MT) 5.00 25 Apr 2004 en las versiones más recientes o REXX-Regina_3.0 4.95 25 Apr 2002 en versiones anteriores. Si es Reginald, puede devolver REXX-Reginald_4.6 4.00 13 Aug 2005, por ejemplo. Si es Open Object REXX, el resultado podría ser REXX-ooRexx_3.0(MT) 6.00 28 Mar 2005.

En el primer ejemplo, REXXSAA identifica el intérprete REXX como el que forma parte de OS/2 y eComStation (si bien el intérprete REXX que forma parte del sistema operativo PC-DOS de IBM también se identifica a sí mismo como REXXSAA como probablemente le ocurra a alguna implementación más de IBM). El número 4.00 corresponde al nivel del lenguaje: el 4.00 corresponde al definido por la segunda edición de The REXX Language de Mike Cowlishaw, el nivel 5.00 corresponde al definido por el estándar ANSI de 1996 y el 6.00 corresponde al superconjunto de REXX clásico que es Object REXX. Y la fecha se supone que indica la fecha del intérprete en el mismo formato que date().

El estándar ANSI especifica que el nombre del intérprete debe ser la palabra REXX en mayúsculas seguida del nombre del intérprete en si mismo. Pero en algunos casos, el intérprete no sigue esa norma, como en el caso del Object REXX de IBM, que devuelve OBJREXX 6.00 18 May 1999, o BRexx, que devuelve brexx 2.1.0 Mar 11 2003 (debe apreciarse que en este caso BRexx tampoco indica el nivel del lenguaje, sino su versión y que el formato de fecha no es el que se considera correcto por el estándar ANSI).

Entre los intépretes más modernos se ha extendido la costumbre de indicar la versión del intérprete y la indicación de si es o no multithreaded (multihilo):

Regina (multihilo): REXX-Regina_3.3(MT) 5.00 25 Apr 2004
Regina (ejecutable estático): REXX-Regina_3.3 5.00 25 Apr 2004
Reginald: REXX-Reginald_5.0 4.00 9 Apr 2006
Reginald Lite: REXX-RegLite_5.0 4.00 3 Apr 2006
Open Object REXX: REXX-ooRexx_3.0(MT) 6.00 28 Mar 2005

El distinguir que intérprete y/o que nivel del lenguaje ejecuta nuestro código nos permite aprovechar características de un intérprete concreto o un nivel del lenguaje sin dejar a los otros fuera.

El manejo de ficheros en REXX es una de las cosas que más cambian de una implementación a otra del lenguaje. Utilizando parse version podemos hacer lo siguiente:

parse version rxInterpreter rxLevel rxDate
select
when rxLevel < 4 then
  IO_routines = 'EXECIO'
when rxLevel < 5 then
  IO_routines = 'ANSI'
when rxLevel >= 5 then
  IO_routines = '.STREAM'
otherwise
  nop
end

para decidir si usamos el comando EXECIO de los mainframes como sistema de manejo de ficheros, las funciones del estándar ANSI (stream, charin, lineout...) o el objeto Stream propio de Object REXX. O, si queremos dar soporte a BRexx y AREXX:

parse version rxInterpreter rxLevel rxDate
select
when rxInterpreter = 'AREXX' then
  IO_routines = 'AREXX'
when rxInterpreter = 'brexx' then
  IO_routines = 'BREXX'
when rxLevel < 4 then
  IO_routines = 'EXECIO'
when rxLevel < 5 then
  IO_routines = 'ANSI'
when rxLevel >= 5 then
  IO_routines = '.STREAM'
otherwise
  nop
end

En ese ejemplo, consultando la variable IO_routines, podemos decidir qué código queremos ejecutar.

Evidentemente este sistema es de utilidad limitada. Hay tantos intérpretes REXX para tantas plataformas que es imposible para cualquier programador conseguir que un programa de mediana envergadura se aproveche de parse version para que se ejecute en todos ellos.

Salvando datos a través de FTP

2007-09-07T22:24:00.000+02:00

Un cliente nos trajo hace muy poquito un portátil HP al que deseaba que le realizásemos un formateo y una reinstalación del sistema operativo (un Windows XP Home Edition) sin borrarle sus ficheros y directorios de la partición de datos.

El procedimiento no sería difícil de no ser por tres puntos esenciales:

El sistema operativo no arranca ni en modo seguro.

El cliente ha destruido la partición de recuperación de HP

Un Windows XP Home Edition Service Pack 2 ordinario no reconoce el disco duro SATA del citado portátil.

La partición de recuperación que suelen incluir la mayor parte de los fabricantes que venden equipos preinstalados (HP, Dell, Acer...) generalmente es accesible a través de algún tipo de obscuro atajo de teclado en el arranque del PC. El PC arranca el sistema desde la partición de recuperación y normalmente puede recuperarse la partición del sistema tal como venía "de fábrica" sin tocar para nada la partición de los datos.
En el peor de los casos, cuando desconocemos el atajo de teclado o éste no funciona, podemos establecer con una herramienta de particionado de disco duro (como DFSee no como Partition Magic) la partición de recuperación como partición de arranque, dejar que recupere el sistema y volver a establecer la partición del sistema como partición activa.

Al no tener partición de recuperación se puede optar por instalar desde un CD ordinario (dado que no tenemos los discos de recuperación del sistema y aunque los tuviésemos, no tenemos garantías de que respeten la partición de datos), pero se da la circunstancia de que Windows XP Home SP2 no tiene los drivers necesarios para detectar el disco SATA y como el portátil no tiene disquetera (y no, una disquetera USB NO sirve) y por lo tanto no podemos instalar.

Entonces es evidente que es necesario sacar los datos de algún modo del portátil. Un CD arrancable y un disco duro externo por USB parecen una buena opción, hasta que es patente que el único disco duro externo que tenemos no tiene suficiente espacio libre (y en ese momento no podemos liberar el espacio ocupado).

Pienso un poquito y decido montar un servidor FTP con Filezilla en uno de nuestros ordenadores. Entonces inicio el portátil desde CD con un Puppy Linux (esa distribución es una verdadera joya en cuanto a ligereza y funcionalidad), configuro la red y con el cliente FTP que incluye (gFTP) transfiero todos los datos.

Si los clientes fuesen conscientes de los malabarismos que a veces tenemos que hacer para proteger sus datos, quizás nos mirasen con otros ojos...

Multifunción que bloquea el arranque de un PC

2007-09-06T22:18:00.000+02:00

Esta tarde me he enfrentado a uno de esos momentos tan poco gratificantes que se encuentran las personas demasiado a menudo en el mundo de la informática cuando un ordenador nuevecito, montado hacía apenas 24 horas, se negaba a arrancar.

Puede ser bonito saber que el ordenador lleva en su interior una WinFast, pero cuando el logotipo permanece en la pantalla durante cinco minutos seguidos sin inmutarse por mucho que se pulsen las teclas (primero de uno de estos detestables teclados inalámbricos por USB -detestables por inalámbricos y por USB- y después con un teclado PS/2 de toda la vida) uno desea sacar un lanzagranadas y volar por los aires todo el equipo informático. Un equipo completamente nuevo.

De todos modos, en estos casos se impone el sentido común antes que la ira y uno piensa que tal vez algún dispositivo externo o un extraíble está causando el problema aunque solamente sea porque ya ha visto cómo ordenadores se han bloqueado en el arranque al tener un llavero USB pinchado. Y un rápido vistazo permite comprobar que lo único inusual que tiene pinchado el PC es una multifunción Lexmark.

En cuanto se despincha la multifunción, el ordenador arranca con completa normalidad.

Presumiblemente el problema reside en el mismo punto que el caso de los llaveros USB pinchados en el momento del arranque, dado que la multifunción tiene un lector de tarjetas digitales que es tratado por el PC como un simple MSD (Mass Storage Device, es decir, un dispositivo de almacenamiento masivo).

Si alguien piensa que apagando la impresora se soluciona el problema, lamento decepcionarle. Si alguien está pensando que basta con desactivar en la BIOS la búsqueda de arranque en removables (extraíbles), lamento decepcionarle.

La solución más sencilla es quitar el cable de la multifunción y pincharla exclusivamente cuando el ordenador esté encendido.

Sería interesante probar con distintas combinaciones de placas y multifunciones (conozco muchos casos de gente con multifunciones de HP que no tienen este tipo de problemas, desafortunadamente no sé si alguna de esos ordenadores tiene una WinFast) para ver cuáles dan este problema. Pero que no cuenten conmigo para ello.

Precisión arbitraria en la aritmética REXX

2007-09-05T22:33:00.000+02:00

Una de las características de la familia REXX (REXX clásico, Object REXX, NetREXX y otras variaciones) que la diferencia de otros lenguajes de programación más extendidos es su aritmética.

En ella no nos encontramos cosas como los clásicos conceptos de variables numéricas de tipo int, float o double... pero de lo que quisiera hablar hoy es de una característica concreta de la aritmética REXX: la precisión arbitraria.

¿Qué queremos decir con precisión arbitraria?

El siguiente código imprime el resultado del cociente de 1 entre 3:

say 1/3

es decir: 0.333333333. Cualquiera que tenga claras ciertas nociones de matemáticas básicas sabrá que en realidad eso no es 1/3, sino simplemente una aproximación con 9 cifras significativas a 1/3 porque la representación decimal de 1/3 tiene infinitos decimales.

REXX nos da el resultado con 9 cifras significativas porque es el número de cifras con el que trabaja.

Si hacemos lo siguiente:

say 1000000000 + 1

obtendremos 1.00000000E+9. Es decir, que perdemos ese 1 que hemos sumado. Puede que bajo ciertas circunstancias nos interesase ese dígito, pero dado que el lenguaje trabaja con 9 cifras significativas y que ese dígito extra sobrepasa los 9 parece que debamos quedarnos sin el mismo. Y aquí es donde entra en juego el carácter arbitrario de la precisión:

numeric digits 100
say 1000000000 + 1

Con esta sentencia nueva en el código, el resultado se convierte en 1000000001. Y en el caso anterior de 1/3 obtendríamos una ristra de cien cifras significativas (es decir, cien bonitos números 3 uno detrás del otro). La instrucción numeric digits nos permite variar el número de cifras significativas.

Consideremos la clásica función factorial escrita iterativamente:

factorial: procedure
  parse arg n
  factorial = 1
  do i = 1 for n
    factorial = factorial * i
  end
  return factorial

Si ejecutamos:

say factorial(100)

el resultado es 9.33262137E+157. Mientras que si ejecutamos:

numeric digits 1000
say factorial(100)

el resultado es exactamente el factorial de 100:

93326215443944152681
69923885626670049071
59682643816214685929
63895217599993229915
60894146397615651828
62536979208272237582
51185210916864000000
000000000000000000.

Intentad haced esto utilizando exclusivamente la aritmética básica de otro lenguaje de programación y probablemente descubrais que no podeis o es terriblemente más complicado. Esto no significa que REXX sea mejor, simplemente que es diferente.

¡Contagie su ordenador a través de USB en tres sencillos pasos!

2007-09-04T22:35:00.000+02:00

Esta misma mañana he invertido varias horas entre otras cosas en limpiar de malware (esto es, de software malintencionado como son los virus, los troyanos y los gusanos) unos cinco ordenadores de sobremesa, tres portátiles, seis llaveros USB y cuatro tarjetas de memoria (MMC y SD). Si bien no todos estaban infectados, era necesario comprobarlo uno a uno porque estaba claro cuál había sido el sistema de propagación de la mayoría de las infecciones presentes: los llaveros USB.

Últimamente es algo muy común ver llaveros USB que transmiten virus de un ordenador a otro como si fuesen el mosquito anófeles transmitiendo la malaria. Y por lo que he podido ver, es algo que se produce con cierta frecuencia en centros públicos como colegios e institutos donde los usuarios llevan su información de un ordenador a otro. Sospecho que en estos casos la propagación es especialmente rápida y en una semana probablemente casi todos los ordenadores estén infectados.

El modo en el que funciona el contagio es enormemente sencillo y se basa en lo que ya hace muchos años era para mí un fallo de diseño y seguridad de Windows 98: el autorun.

Cada vez que se inserta un dispositivo extraíble como un CD, un DVD o un sistema de almacenamiento como una llave USB, Windows busca en la raiz de esa unidad un fichero de texto llamado autorun.inf. Ese fichero de texto indica a Windows cosas como el icono con el que debe aparecer en Mi PC, las acciones que deben agregarse al menú contextual de la unidad (el menú que aparece al pinchar con el botón derecho del ratón) y lo que debe pasar automaticamente al detectarse la unidad. Generalmente esto es utilizado en CDs y DVDs para iniciar algún tipo de asistente de instalación aunque yo mismo en un arranque de malicia hace años grabé algunos CDs con un autorun.inf que apagaba el ordenador en el se introdujese y esa característica de Windows estuviese activada.

Los CDs, que eran comunes como medio de transporte de información hace cinco años, y los DVDs (que para el caso podemos considerar como CDs grandes) son dispositivos de sólo lectura. No podemos arrastrar ficheros a ellos para copiarlos en ellos, no podemos modificar ficheros existentes y es IMPOSIBLE añadir nada al CD si está finalizado. No son un modo cómodo de propagación para el malware.

Pero desde que los llaveros USB y similares han desplazado casi completamente a los disquetes el malware tiene un método de propagación nuevo puesto que son dispositivos de lectura y escritura. Y ahí tenemos el primero de los pasos: si se pincha un llavero en un ordenador infectado por cierto tipo de malware, éste puede crear una o varias copias en el llavero y un fichero autorun.inf con instrucciones para ejecutar alguna de las copias. El segundo paso consiste en que el usuario lleva el llavero USB a otra máquina. Y en el tercero, al pinchar el llavero infectado en un ordenador limpio, si la característica de autorun está activada del modo adecuado, se ejecutará la copia del malware que se copiará a sí misma en el disco duro del ordenador obligándole a ejecutarla cada vez que lo encendamos.

Un método sencillo, simple y efectivo.

Evitar el contagio no es sencillo pero hay algunas cosas que probablemente ayuden:

Si la llave USB lleva un método de bloqueo (los reproductores MP3 suelen llevar algún sistema de bloqueo generalmente etiquetado como hold y otro tanto ocurre con muchas tarjetas digitales) y simplemente nos interesa llevar algo a un ordenador que no es de confianza (y el que lea esto debe pensar como un paranoico que, en el mejor de los casos, solamente su ordenador es de confianza) lo activamos y así el dispositivo no podrá ser infectado.

Desactivar algunas de las características del autorun en nuestro Windows para que nada se ejecute automáticamente sin nuestro permiso (para ello, buscad información en Internet).

Darnos cuenta de que cuando en la ventana emergente que aparece al pinchar dispositivos extraíbles en Windows XP hay indicadores extraños sobre la lista de acciones con el nombre de "Programa", es probable que el llavero USB esté infectado y debamos someter a un escaneo tanto el llavero como el equipo.

Todo lo dicho solamente es aplicable a usuarios de Microsoft Windows. Aquellos que utiliceis otro sistema operativo (Linux, BeOS, Mac OS X, OS/2, FreeBSD... el que sea) podeis estar razonablemente seguros de que este sistema de infección no os afectará.

Reimplementando BIFs en REXX

2007-09-03T23:06:00.000+02:00

En REXX es frecuente referirse oficiosamente a toda función que forma parte del núcleo del lenguaje como BIF: Built-In Function. El estándar ANSI de 1996 define una serie de funciones dentro de esta categoría como por ejemplo abbrev, words, date o address. En general las implementaciones del lenguaje tienen todas las BIFs definidas en el estándar, añadiendo aportaciones propias o tal vez careciendo de alguna concreta.

Lo peculiar del caso es que REXX permite que el programador defina las funciones internas de su programa (aquellas que se incluyen dentro del mismo fichero) utilizando los mismos nombres que alguna BIF y aun así seguir utilizando la BIF cuyo nombre hemos utilizado.


  /* words.rex */

  parse pull frase
  say words(frase)

  exit

Este sencillo ejemplo se limita a contar el número de palabras que tiene una cadena que introduce el usuario utilizando la BIF words. La línea con la sentencia parse pull frase se limita a meter la entrada del usuario en la variable frase. Y la siguiente línea nos dice la salida de la función words aplicada sobre la variable frase, es decir, muestra en pantalla el número de palabras.

Si el programador introduce una función en el código como en el siguiente caso:


  /* words.rex */

  parse pull frase
  say words(frase)

  exit

  words: procedure
    return 'No me apetece contar palabras'

El resultado es que en lugar de ejecutarse la BIF words, se ejecuta nuestra función. Es decir, que sea cual sea la entrada del usuario, el programa siempre imprimirá que no le apetece contar palabras.

A pesar de tener ocupado el nombre de la BIF words, podemos seguir accediendo a ella llamandola por su nombre en mayúsculas entrecomillado (por comillas simples). Así, en el siguiente ejemplo, se imprime siempre que no le apetece contar palabras e inmediatamente después el número de palabras tal como lo cuenta la BIF words:


  /* words.rex */

  parse pull frase
  say words(frase)
  say 'WORDS'(frase)

  exit

  words: procedure
    return 'No me apetece contar palabras'

Evidentemente podemos ejecutar la BIF desde dentro de nuestra función:


  /* words.rex */

  parse pull frase
  say words(frase)

  exit

  words: procedure
    parse arg cadena
    return 'WORDS'(cadena)

Esto nos permite cierto número de posibilidades como cambiar el comportamiento de las BIFs de nuestro intérprete. Esto puede ser interesante, por ejemplo, cuando un intérprete no implementa una BIF como estamos acostumbrados a utilizar. Imaginemos que un programador acostumbrado a las características de la BIF date para hacer aritmética de fechas propias del estándar y presentes en Object REXX y Regina desea que su código funcione en REXX clásico en OS/2 (que carece de esa característica). Si hace una función date que supla esas características ausentes en ese intérprete, solamente tiene que añadir esa función en la versión de su programa para OS/2 y no tendrá que tocar ninguna línea más de código.

Lo interesante es que podemos reimplementar muchas de las BIFs orientadas a manejo de cadenas solamente utilizando bucles condicionales y la instrucción PARSE. En el caso que nos ocupa, podríamos hacer:


  words: procedure
    parse arg string
    n = 0
    do while string <> ''
      parse var string . string
      n = n + 1
    end
    return n

parse coge el argumento de la función que hemos escrito y lo introduce en la variable string, mientras la variable string no esté vacía parse coge la primera palabra de la variable string y la descarta (.) metiendo el resto en string. Cada vez que descarta una palabra, aumenta el contador, y cuando las ha descartado todas, nos devuelve el valor de ese contador, es decir, del número de palabras. (Podríamos habernos ahorrado un par de líneas, pero he preferido dejarlo así por claridad.)

Como ejercicio para principiantes, el intentar reimplementar BIFs sin utilizar BIFs es algo, creo yo, muy educativo. Permite apreciar el valor de la instrucción parse y familiarizarse con las BIFs orientadas a cadenas.

Solamente podemos "redefinir" las BIFs a través de funciones internas de nuestro programa. Las funciones externas no nos valdrán y tampoco aquellas que estén en el macroespacio (si la implementación lo tiene). Pero cuando la BIF no está definida en nuestro intérprete (como ocurre con countstr en REXX clásico para OS/2), entonces podemos implementarla como una función externa y cargarla en el macroespacio...

Pero, como decía Jack Lemmon en Irma la dulce: Eso es otra historia.

mplayer en OS/2 y eComStation

2007-09-02T23:26:00.000+02:00

Aún recuerdo cómo hace años el proyecto mplayer puso en su lista negra a WarpVision, que por aquel entonces era practicamente el único reproductor de vídeo para OS/2 con cierta funcionalidad, porque había utilizado código fuente de mplayer (código bajo la licencia GPL) y se trataba de un programa comercial.

Tras el paso de los años el proyecto WarpVision cambió de tutela y pasó a Netlabs que liberó su código fuente. Y lo que hace años era un prometedor reproductor multimedia para una plataforma de software virtualmente abandonada, ahora sigue siendo exactamente eso: un proyecto prometedor.

Y precisamente el hecho de que las funcionalidades del programa y su estabilidad hayan mejorado tan poco significativamente resulta enormemente frustrante (como el mismo Adrian Gschwend, responsable de Netlabs, comentaba no hace muchos meses ante la decisión de despedir al desarrollador del programa). WarpVision no sigue un esquema de numerado de versiones claro y resulta muy difícil decidir qué versión utilizar porque hay características que dejan de funcionar en una versión nueva que ha corregido algún problema que tenía la versión anterior.

En el transcurso de estos años el panorama ha cambiado en OS/2 de un modo curioso; toda una serie de personas individuales y comunidades han aportado una serie de herramientas de desarrollo que mantienen vivo a un sistema operativo que lleva muerto ya más de media década: Knut St. Osmundsen es el responsable de las versiones del compilador GCC y la biblioteca libc más actuales existentes para la plataforma (con características nuevas de las que carecen los equivalentes anteriores: EMX); Doodle ha portado SDL y Cairo; Dmitry A. Kuminov ha portado QT3; la comunidad OpenWatcom ha sacado recientemente la versión 1.7 de su compilador de C, C++ y Fortran; varias personas mantienen todos los programas de la familia de productos Mozilla al día...

En estas circunstancias en las que el software libre da una inyección de vitalidad al sistema, varias personas, probablemente insatisfechas con WarpVision, han mirado hacia afuera para ver qué podían traer hacia el sistema. Ese bendito australiano llamado Paul Smedley portó ffplay (el reproductor basado en ffmpeg) y mplayer utilizando SDL con resultados discretos. El coreano KO Myung-Hun, basandose probablemente en el trabajo de Paul, ha hecho sus propias versiones de estos programas eliminando la dependencia de la biblioteca SDL y activando aceleración 2D a través de WarpOverlay y en el caso de mplayer ha creado una verdadera joya.

Mi máquina es muy modesta en recursos: un AMD K6-2 a 450 MHz, una tarjeta gráfica de tan solo 8 megas, una RAM de unos 500 megas... y en muchos casos no conseguía reproducir la mayor parte de los vídeos (aun en mis restantes sistemas operativos). Por poner un ejemplo: no conseguía ver los capítulos de Naruto Shipuuden de ningún modo, no importaba el sistema operativo o el reproductor que utilizase o lo que jugase con las opciones de reproducción.

Hasta el port de mplayer de KO Myung-Hun.

Hasta ahora ha resultado extraordinariamente estable, me ha permitido ver casi todos los vídeos que he probado (hasta ahora solamente se le resisten los FLV bajados de YouTube y los WMV), carga y sincroniza correctamente ficheros de subtítulos externos, reproduce DVDs sin problemas... y si un vídeo me da problemas con su resolución completa, con la opción "-lavdopts lowres=1:fast:skiploopfilter=all" puedo verlo en baja resolución sin inconvenientes (salvo, claro está, la resolución misma).

Le faltan pequeñas cosas como reproducir VCD, ocultar el puntero de ratón en pantalla completa, desactivar el salvapantallas mientras está reproduciendo, que el ejecutable y la ventana de reproducción tenga un icono (es sorprendente lo que me importa una nimiedad como esa, teniendo en cuenta lo poco que suele importarme la estética)... Tal vez una interfaz gráfica sería deseable y dado que el trabajo de Myung-Hun incluye un modo esclavo que es necesario para hacer un front-end (con el que he intentado jugar sin éxito alguno) ya existe todo lo necesario para ello (de hecho, el front-end multiplataforma SMPlayer, basado en QT es un buen candidato a port).

Pero mientras llegan esas cosas que no son vitales, ¡qué irónico es que OS/2 se haya convertido en el sistema que he de usar para ver vídeos!

Pseudocompiladores REXX, la instrucción TRACE y la función SOURCELINE

2007-08-31T22:44:00.000+02:00

Aunque IBM ha desarrollado compiladores del lenguaje de programación REXX que se han utilizado y se siguen utilizando en entornos de producción, el lenguaje es principalmente conocido por un gran abanico de intérpretes.

El abanico es tan amplio que la lista pasa por los comerciales como uni-REXX, los que forman parte del sistema operativo como el venerable REXX clásico de OS/2, los "shareware" para una plataforma concreta como REXX para Palm OS, los gratuitos que incluyen una herramienta de desarrollo RAD como Reginald o los libres presentes virtualmente en todas las plataformas de software existentes como Regina... Pero ocasionalmente el abanico se queda pequeño porque es necesario generar un ejecutable bien sea porque el programa en concreto lo requiere o porque nos interesa ocultar el código. Y en estos casos lo que necesitamos es lo que personalmente suelo denominar como pseudocompilador.

Un pseudocompilador genera un ejecutable a partir de un script REXX, pero en ningún caso lo hace traduciendo el código REXX a código máquina. Se limita a añadir el código de algún modo a la estructura del ejecutable generado y ese ejecutable se limita a usar las bibliotecas dinámicas de una implementación concreta de intérprete REXX para interpretar el código que lleva adjunto.

Por poner un ejemplo sencillo, partamos de un programa que nos pide una cadena y la devuelve invertida contenido en un fichero "bucle.cmd" para OS/2:


  /* bucle.cmd */
  signal on halt

  do forever
    call charout , 'Introduzca una cadena: '
    parse pull cadena
    say reverse(cadena)
  end

  exit

  halt: exit

Ahora podemos recurrir a uno de los pseudocompiladores REXX disponibles para OS/2 como los de Dennis Bareis (rexx2exe), Veit Kannegieser (REXX_EXE) o Mark Hessling (Rexx/Wrapper) para generar un ejecutable:


  [C:\home\salvador] rexx2exe bucle.cmd bucle.exe

Y ya tenemos un ejecutable que está enlazado dinámicamente con la biblioteca dinámica que implementa el intérprete REXX en OS/2 (REXX.DLL). Es decir, el ejecutable depende del intérprete REXX del sistema y utiliza el intérprete para ejecutar el código que lleva dentro.

La mayor parte de los pseudocompiladores permiten encriptar el código o tokenizarlo, lo que representa una oportunidad estupenda de ocultar el código. De hecho, las cuatro herramientas de desarrollo gráfico RAD disponibles para OS/2 (VisPro/REXX, VX-REXX, GPF REXX y DrDialog) pueden considerarse pseudocompiladores puesto que hacen exactamente lo mismo que los mencionados anteriormente y hay cientos de programas populares pseudocompilados para OS/2.

La tokenización, para aquellos de vosotros que hayais llegado hasta aquí que sintais algo de curiosidad es el proceso que realiza el intérprete REXX al pasar del código que escribe el programador a una representación intermedia que es lo que se ejecuta. La tokenización inevitablemente oculta el código original y permite ejecutar el código tokenizado sin problemas. Pero como el proceso de tokenización es tremendamente dependiente del intérprete, al decirle a un pseudocompilador tokenice el código nos encontramos con que el ejecutable generado en principio solamente funcionará con una versión concreta de un intérprete particular.

(Incidentalmente: Regina incluye opciones para generar programas tokenizados -no ejecutables- y ejecutarlos posteriormente y otro tanto podemos decir de IBM Object REXX y Open Object REXX.)

Eso nos deja con la encriptación del código como modo de ocultarlo sin que el ejecutable quede inutilizable por un cambio de intérprete o versión del intérprete y con una impresión de seguridad que echa por tierra una característica del intérprete REXX de OS/2 (y algunos otros): la variable de entorno RXTRACE.


  [C:\home\salvador] rexx2exe bucle.cmd bucle.exe
  []-------------------------------------------------------------------------[]
  | REXX2EXE version 99.349 (C)opyright Dennis Bareis 1994                    |
  | http://www.labyrinth.net.au/~dbareis/index.htm (dbareis@labyrinth.net.au) |
  []-------------------------------------------------------------------------[]

  CHECKING : bucle.cmd

          * Rexx Source length 176 bytes
          * Rexx Binary length 176 bytes

          * Target EXE  length 27,618 bytes
          * Target code will not run in OS/2 version 2.x
          * Rexx code encrypted in target (Key=0xF772F1AC)
          * Code can't be recovered
  [C:\home\salvador] SET RXTRACE=ON

  [C:\home\salvador] bucle.exe
       2 *-*   Signal On halt;
         +++   Interactive trace. "Trace Off" to end debug, ENTER to Continue.

¿Qué ha sucedido?

La variable de entorno RXTRACE cuando tiene el valor "ON" tiene el efecto de añadir la sentencia TRACE '?R' al comienzo del cualquier programa REXX que ejecutemos en ese entorno. La instrucción TRACE es una de esas joyas del lenguaje REXX: es lo que activa el depurador del lenguaje que forma parte de todo intérprete en tiempo de ejecución.

A partir de este momento podemos inyectar código nuestro en la ejecución del ejecutable encriptado "bucle.exe". Pero puesto que tenemos la función sourceline que permite decirnos el contenido de una línea concreta de un script REXX, podemos inyectar lo siguiente:


  do i=1 to sourceline();call lineout "source.cmd",sourceline(i);end;exit

Y ya tenemos todo el código encriptado sacado sin problemas del ejecutable. Cualquiera que hubiese leído esa pequeña joya que es el REXX Tips & Tricks de Bernd Schemmer conocería este detalle y habría experimentado con buenos resultados con ejecutables generados con todos los pseudocompiladores para OS/2 (salvo VX-REXX) y algunos para otras plataformas.

La solución es sencilla: añadir la sentencia "rc=trace('o')" como primera sentencia de nuestro programa para desactivar el rastreo del programa si se activa a través de la variable de entorno RXTRACE.

Desafortunadamente en las herramientas de desarrollo RAD para OS/2 como VisPro/REXX, es difícil determinar cuál es la primera sentencia. De hecho, en este caso particular la primera sentencia NO es responsabilidad del programador, puesto que VisPro/REXX añade un bloque de código sobre el cual no tenemos control salvo que hagamos un parche binario sobre el ejecutable generado o sobre el pseudocompilador (el ejecutable BLDNTEST.EXE). Es una tarea sencilla que se deja como ejercicio al lector.

Un comienzo a 56k

2007-08-29T22:34:00.000+02:00

Decían los geniales Les Luthiers que Johann Sebastian Mastropiero tras titular cierto famoso madrigal como La bella y graciosa moza marchose a lavar la ropa consideró que la longitud no era la apropiada para un título así que le dio en nuevo título de La bella y graciosa moza marchose a lavar la ropa, la mojó en el arroyuelo y cantando la lavó, la frotó sobre una piedra, la colgó de un abedul.

Al abrir este blog me he encontrado en un dilema similar salvo por el detalle de que no soy tan decidido como Mastropiero y tras mucho cavilar, pensando que, después de todo, un nombre no importa tanto, he optado por una sugerencia de mi buena amiga Nerea (cuya paciencia deja a la de Job a la altura del betún)... que después de todo me recuerda aquel genial soneto de Quevedo.

Esta tímida entrada, escrita al ritmo de los geniales compases de Horizontes de grandeza de Jerome Moross, tras una conexión de 56 k, con un navegador que renquea al renderizar texto en un campo de entrada, es solamente un comienzo de una serie de divagaciones que iré plasmando por aquí ocasionalmente acerca de mis intereses y aficiones.