FoxDev Studio revive Visual FoxPro 9 en 64 bits: mismo lenguaje, runtime nuevo

Microsoft enterró Visual FoxPro en 2007 y el producto se quedó en la versión 9, en 32 bits y sin sucesor. Ahora un grupo de desarrolladores ha publicado FoxDev Studio, un IDE y un runtime que abren los proyectos, formularios y tablas .dbf que ya existen y los ejecutan sin reescribir, sin convertir y sin exportar. El código está en el repositorio de FoxDevCommunity, y hay instalador .exe y runtime .zip para x64 en la nightly.

La propuesta no es reimplementar el lenguaje de memoria, sino respetar lo que hay en disco. Proyectos, formularios, bibliotecas de clases, menús e informes se abren desde los ficheros originales. Tablas, índices, memos y bases de datos se leen y escriben en su sitio, de modo que lo que queda en el disco después es el mismo tipo de fichero que había antes. Las llamadas al sistema, los objetos de automatización y las viejas bibliotecas .fll siguen respondiendo, y las de 32 bits se ejecutan en un proceso aparte, fllhost.exe.

El runtime, hecho de nuevo

Debajo hay una máquina distinta. Un compilador y un intérprete de bytecode escritos en Rust y compilados a WebAssembly, de forma que el mismo motor corre allí donde corra la aplicación. El editor valida lo que se teclea con ese mismo compilador, así que lo que subraya y lo que el runtime rechaza no se separan. Un programa en ejecución es una fibra: cuando necesita algo de fuera (un cuadro de mensaje, un formulario modal, el siguiente registro) no llama y se bloquea, hace yield, el trabajo se resuelve con la máquina fuera de la pila y la respuesta vuelve. De ahí que MESSAGEBOX() detenga el programa sin congelar la ventana de detrás y que READ EVENTS espere sin girar en vacío.

La interfaz es React dibujando directamente el árbol de objetos vivo, no una imagen de él. Cada objeto se observa solo a sí mismo, así que una asignación como THISFORM.lblGreeting.Caption = cMsg repinta una etiqueta y no el formulario entero.

El comportamiento se fija preguntándole al propio Visual FoxPro y replicando su respuesta, no leyendo una página de referencia. De la referencia del lenguaje de VFP 9 el runtime conoce 1.722 elementos y 1.534 pasan por una prueba que compara la salida con la del producto original; tres no están cubiertos. Las capturas que enseña el proyecto son sesiones reales sobre las muestras del propio VFP: la solución de ejemplo importada, con sus 123 formularios, 7 menús y 11 bibliotecas de clases, y el depurador parado un paso después de un breakpoint con pila de llamadas, locales y watches.

El techo de los 32 bits

Que Visual FoxPro sea un programa de 32 bits decide más de lo que parece. Es la razón de que una tabla se pare a 2.147.483.647 bytes, de que un fichero memo tenga el mismo tope y de que un informe grande se quede sin memoria en una máquina sobrada. Son números con signo enterrados en el manejo de ficheros, no una decisión de licencia: el bit de signo es lo que deja el límite en 2 GB y no en 4.

FoxDev Studio es de 64 bits de arriba abajo. Cada offset de fichero es de 64 bits y una tabla nunca se carga entera en memoria, así que el mismo .dbf pasa de esos 2 GB a cientos de gigas. La cifra que maneja el proyecto es 9.223.372.036.854.775.807 bytes de offset, con el contador de registros de la cabecera DBF como único freno real. Dicho de otro modo: 279 bloques del tamaño de todo lo que cabía en una tabla de FoxPro, o una tabla de registros de 130 bytes que llega a 558 GB, que con registros de 1 KB se va a 4,4 TB.

Hay un aviso que conviene leer antes: una tabla que crezca por encima de 2 GB ya no volverá a abrirse en Visual FoxPro. Si se trabaja con los dos, es una puerta de un solo sentido.

El proyecto está en fase nightly, así que la pregunta abierta no es si el lenguaje revive, sino hasta dónde aguanta en aplicaciones reales. Los propios autores admiten que hay rincones del lenguaje a los que todavía no han llegado, aunque los nombran en vez de disimularlos.