Archivo por años: 2006

Programando para Windows Mobile 5 con Mono

Programación, tutoriales

La política no es la única que hace extraños compañeros de cama: en estos momentos estoy compartiendo mi vida con una PDA con Windows Mobile 5.

La razón es que, por motivos laborales, tengo que escribir un programa para dicho sistema operativo, y aunque los entornos de desarrollo de Micro$oft son conocidos por su gran calidad, la idea de cambiar mi escritorio del trabajo a Windows (con todo lo que ello conlleva: configurar de nuevo el programa de correo, enlaces del navegador, etc) me tiraba mucho para atrás. Por eso decidí realizar el programa con .NET, para lo cual podría usar Mono y MonoDevelop desde GNU/Linux. Además podría vender la moto de que el mismo programa también les funcionará en GNU/Linux…

Por supuesto, las cosas no fueron sencillas. El primer problema era conseguir comunicar la PDA con Linux, problema que parecía resuelto con SynCe (y su Wiki de documentación). Tras un par de pruebas confirmé que el driver ipaq no reconocía a la PDA, así que me puse a bucear en la página de documentación para Windows Mobile 5 y descubrí que los procesadores Intel PXA27x todavía no están soportados por un fallo en su controlador USB.

Como no podía ser de otra manera, mi PDA tenía un procesador de esa familia, lo que reducía mis opciones a una: usar BlueTooth. Afortunadamente, en la documentación anterior se explica muy bien como configurarlo, aunque hay un par de detalles que no comentan bien y que hay que tener en cuenta:

  • Para establecer la conexión no sirve el comando triggerconnection, sino que hay que lanzar ActiveSync y escoger Conectar por BlueTooth en el menú.
  • Una vez conectado toda la comunicación se realiza a través del puerto 990 de TCP/IP, por lo que es necesario abrir en el firewall el acceso a nuestro equipo a través de la interfaz ppp0.
  • De las dos direcciones IP especificadas en el fichero /etc/ppp/peers/dun, la primera es la que se le asigna a nuestro ordenador y la segunda la de la PDA.
  • La misma conexión TCP/IP está disponible para otros programas, aunque en mi caso no puedo usar Internet Explorer para navegar porque se empeña en conectar de nuevo mediante alguno de los otros perfiles disponibles.
  • Parece que no basta con añadir el servicio SP (serial port) para que aparezca el ActiveSync en la PDA, sino que también tiene que estar el servicio LAN y el DUN.
  • Al contrario de lo que dice en la documentación para BlueTooth, hay que lanzar vdccm y no dccm. Además no hay que olvidarse de los parámetros que aparecen en Iniciando la conexión.

Añadir que hay un bug en la pila BlueTooth actual (la que traen Ubuntu Edgy y Debian testing/inestable) que desactiva el ISCAN nada más lanzar el servicio, por lo que el ordenador no aparecerá en la lista de dispositivos BlueTooth de la PDA. Para solucionarlo hay que añadir el comando discovto 0; en la sección device del fichero hcid.conf, y cada vez que se inicie la pila BlueTooth (al arrancar el ordenador o hacer un /etc/init.d/bluetooth restart) ejecutar el comando:

dbus-send --system --dest=org.bluez /org/bluez/hci0
org.bluez.Adapter.SetMode string:discoverable

para activar el ISCAN de nuevo. Podemos comprobar el estado con

hciconfig -a

Por último, para los usuarios de Ubuntu Dapper, añadir que la versión de SynCe que trae es demasiado antigua y no soporta Windows Mobile 5, así que es necesario bajarse los fuentes desde la página y recompilar.

La parte de como escribir programas para la PDA la dejo para una segunda entrada, que esta ya es demasiado larga.

GAG, amenazado por las patentes de software

Sin categoría

Hace unos días recibí un correo-e, proveniente de la mismísima oficina europea de patentes, en el que me preguntaban la fecha en la que lancé GAG 1.0 y, a ser posible, el código fuente de dicha versión para comprobar si se podía considerar arte previo de una patente que estaban examinando. La patente en cuestión es, nada más y nada menos, que la de un gestor de arranque gráfico.

Tras el acojone inicial rebusqué en mis viejos CDs y molesté a varios colegas por teléfono hasta que por fin encontré el mensaje original, fechado el 12 de mayo de 1999… o sea, ocho meses después de la fecha de presentación de la solicitud de patente. Afortunadamente recordé que un colega (hola David) había creado otro gestor de arranque gráfico anterior a GAG. Se trata de MBRMenu y la versión 2.0 se había publicado en marzo de 1998 (en su página no indicaba la fecha de la versión 1.0, pero con esa era suficiente).

Respondí al correo con toda esta información y pedí que me informasen del estado de la patente. Al día siguiente recibí una respuesta dándome las gracias y explicándome que el proceso aún llevaría algunos años más (?). Esa respuesta me chocó bastante: si la solicitud de patente se había hecho hacía siete años ¿cuantos más iban a tardar en concederla? Empecé a considerar que se tratase de una broma, pero no pude encontrar nada raro en la cabecera del mensaje (parece que realmente vino del dominio epo.org), y el dominio espacenet.com parece que está registrado a nombre de la EPO también; además, el texto de la patente no son dos hojas precisamente, y tiene bastante pinta de legal… si es una broma se la han currado mucho. Y además ¿una broma de quien?

Pocas horas después, a raíz de una noticia sobre el registro de arte previo que quiere montar el OSDL, leí un texto en el que Richard Stallman afirmaba que si un revisor de patentes considera que un trabajo determinado no es arte previo, en un posterior juicio de patentes los jueces suelen no aceptar dicho trabajo como posible prueba para anularla, aunque el revisor estuviese bebido (o presionado para aprobar la patente) ese día. Por desgracia me enteré de esto bastante después de responder el mensaje, lo que significa que, quizás, les he dado la patente en bandeja de plata.

Definitivamente las patentes de software son una locura. Tenemos que hacer lo que sea para impedir que se aprueben en Europa, o el software libre pasará a la historia.

Nueva versión de DeVeDe

Nueva versión

Inauguraré este blog con el anuncio de la nueva versión 2.4 de DeVeDe. Entre las principales novedades está el poder especificar que un fichero de vídeo ya está en formato MPEG-PS, con lo que DeVeDe no lo volverá a comprimir, sino que lo meterá tal cual en el disco. Esto es especialmente útil cuando capturas algo directamente de la televisión, pues no pierdes calidad.

Otra novedad es que ahora se puede escoger el algoritmo de MBD (MacroBlock Decission), con lo que se puede escoger entre mayor velocidad de conversión o mayor calidad final. También activa el Trellis por defecto (aunque se puede eliminar). Además permite aplicar algoritmos de desentrelazado; especialmente útil para cuando metemos un vídeo que tiene los campos invertidos (aunque en la próxima versión espero añadir una opción para invertir los campos).

Por último, he refactorizado el código para dejarlo un poco más limpio y facilitar el mantenimiento. Por supuesto aún falta mucho por hacer en ese aspecto, pero por algo hay que empezar…

Por cierto: acepto parches para el código 😉