FoxPro ha muerto. Ahora hay FoxPro de nuevo.
Esta nueva edición de Visual FoxPro, llamada FoxDev Studio, supera el límite de dos gigabytes que detuvo el software original, al tiempo que conserva el mismo lenguaje. Se apoya en una base que no se ha congelado desde 2007. El resultado es un lenguaje congelado en la versión 9, que ahora se ejecuta nuevamente sin necesidad de una reescritura completa.
El Límite Original
El software dejó de numerar sus versiones en 9, y su arquitectura está limitada a 32 bits. Debido a eso, una tabla no puede contener más de dos gigabytes, un archivo de memo tiene un límite similar de dos gigabytes, y un informe extenso puede agotar la memoria en una máquina con mucha todavía disponible. Estos límites no son el resultado de decisiones de licenciamiento tomadas por nadie. En cambio, provienen de números de 32 bits con signo integrados en el código que maneja las operaciones de archivo.
FoxDev Studio se ejecuta completamente en 64 bits. Cada desplazamiento de archivo se maneja en 64 bits, y ninguna tabla se carga realmente en la memoria en absoluto, lo que significa que un archivo .dbf que alguna vez dejó de funcionar ahora puede seguir funcionando hasta cientos de gigabytes. Hay una advertencia a tener en cuenta: una vez que una tabla crece más de dos gigabytes, no se puede volver a abrir en Visual FoxPro. Si todavía trabaja en ambos sistemas, eso se convierte en una puerta de un solo sentido.
La base de la compilación es un lenguaje que se congeló en 2007, reconstruido sobre una base que nunca se ha congelado desde entonces.
El Runtime
Su programa de Visual FoxPro se compiló en p-código y venía con un runtime para ejecutarlo. FoxDev Studio repite esa estructura: un compilador y un intérprete de bytecode, hechos en Rust y compilados a WebAssembly, de modo que una máquina ejecuta su código dondequiera que se ejecute la aplicación. El editor verifica lo que escribe contra ese mismo compilador, de modo que lo que subraya y lo que el runtime rechaza no puede desviarse.
El runtime está recién compuesto, es rápido para iniciarse y es autónomo. Reconoce abiertamente las áreas que aún no ha explorado, y llena esos vacíos preguntándole a Visual FoxPro cómo deben funcionar las cosas, en lugar de depender de una página de referencia y esperar que coincida.
El Formulario y el Puente
Un programa en movimiento es un hilo. Cuando requiere algo del mundo exterior (un cuadro de mensaje, un formulario modal, el siguiente registro) no se extiende y se detiene; cede, y la tarea se lleva a cabo mientras la máquina se aparta de la pila, con la respuesta devuelta. Es por eso que MESSAGEBOX detiene su programa sin congelar la ventana detrás de él, por qué READ EVENTS espera sin girar, y por qué SetFocus puede disparar GotFocus, y Init puede ejecutarse mientras un formulario todavía se está construyendo, en el orden en que FoxPro siempre lo hizo.
React dibuja la interfaz desde un árbol vivo de objetos, que contiene las propiedades que esperaría. Cada objeto vigila solo a sí mismo, así que cambiar THISFORM.lblGreeting.Caption a cMsg repinta solo una etiqueta en lugar de todo el formulario. En una pantalla concurrida, esa es la diferencia entre instantáneo y lento.
Un único árbol es lo que el diseñador da forma, una etapa antes del final. Ningún segundo modelo se mantiene al día con el primero, así que el formulario y su diseñador nunca comienzan a contar historias separadas. La compilación evita ese problema al dar forma al árbol mismo, en lugar de mantener una copia.
El Problema de 32 Bits
El archivo .fll es una imagen de 32 bits, y cada proceso individual dentro de una aplicación de 64 bits es de 64 bits, lo que significa que la propia aplicación no puede abrir uno. En lugar de informarle que es imposible, SET LIBRARY TO lanza un pequeño proceso de 32 bits cuyo único propósito es mantener su biblioteca, con el tiempo de ejecución comunicándose con él. Las llamadas son sincrónicas, ya que un programa puede llamar a una biblioteca en medio de una expresión, y una respuesta que llega más tarde no encajaría con la solicitud. Fue medido contra bibliotecas reales: la biblioteca de cifrado, FoxTools, y bibliotecas construidas a partir de ejemplos de API propios de Microsoft.
No hay un requisito de 64 bits para el puente: una declaración DECLARE … DLL se conecta a una biblioteca moderna en el mismo proceso, y los objetos de automatización se alcanzan como siempre se han alcanzado. El camino antiguo permanece abierto; simplemente no es el único ahora.
El Código Que Ya Escribió
Lo que ha compuesto conserva su significado original por completo. FoxScript simplemente construye sobre esto: un mecanismo que le permite pasar un bloque a otra cosa para que lo ejecute más tarde, junto con un método para responder a una solicitud web desde el código que ya entiende su negocio.
&& sus viejas bibliotecas de complementos se cargan como antes. SET LIBRARY TO «vfpencryption71.fll» ADITIVO LOCAL oServer oServer = FoxScript.Http.CreateServer() oServer.Get(«/api/v1/customers/:id», LAMBDA(req, res) LOCAL lnId lnId = VAL(req.Params(«id»)) SELECT * FROM customer WHERE cust_id = lnId INTO CURSOR c_cust IF RECCOUNT(«c_cust») > 0 res.Status(200).Json(FoxScript.Data.CursorToJson(«c_cust»)) ELSE res.Status(404).Json(‘{«error»: «Not found»}’) ENDIF USE IN c_cust ENDLAMBDA) oServer.Listen(8080) READ EVENTS
Esa plataforma se ejecuta en el mismo entorno de ejecución que sus formularios. Las consultas, el cursor y la llamada a la biblioteca son herramientas estándar de FoxPro; lo que FoxScript agrega son la lambda y el servidor, ambos sin requerir un lenguaje o un servicio separado. Los palabras clave y la API HTTP están establecidas por completo.
La Construcción y el Cronograma
FoxDev Studio se ejecuta en 64 bits de principio a fin. Todos los desplazamientos de archivo se tratan como 64 bits y las tablas nunca se leen en la memoria, lo que significa que un archivo .dbf que una vez se detuvo por completo ahora puede continuar hasta cientos de gigabytes. Hay una limitación que vale la pena mencionar: una tabla que ha crecido más de dos gigabytes no se abrirá en Visual FoxPro nuevamente.
Una versión preliminar del proyecto se publica en GitHub, reconstruida de cada push a main todas las noches. La compilación no está firmada, lo que significa que el primer inicio le solicita confirmar. La documentación cubre cada parte del producto, incluidos los recursos que aún no se han construido. También se incluye la orden aproximada del trabajo que está planeado y mapeado.
| Paso | Qué Es | Dónde Se Ejecuta |
|---|---|---|
| Compilador | Rust, compilado a WebAssembly | Cada Máquina |
| Tiempo de ejecución | Lee tablas en el lugar | Cada máquina |
| Modelo de fibra | Gestiona cuadros de mensajes y formularios modales | Cada máquina |
| Puente .fll | Proceso pequeño de 32 bits | Detrás de escena |
| FoxScript | Agrega lambdas y servidores HTTP | En el mismo tiempo de ejecución que los formularios |
Lo que esto realmente significa )
La construcción mantiene sus proyectos, formularios y tablas de la misma manera en que estaban. No los reescribe ni los transforma en una nueva forma a través de la conversión. Simplemente abre la carpeta que usted señala, y lo que hay dentro es lo que ve, exactamente como estaba.
Lo que se promete es real, y está respaldado por el diseño de la construcción en sí. El tiempo de ejecución pregunta a Visual FoxPro cómo deben funcionar las cosas, y luego se adapta a su respuesta, lo que significa que incluso una pequeña diferencia en un evento o un número de error no se reescribirá, sino que se conservará.
«Los límites son números de 32 bits con signo incrustados en el manejo de archivos, no una decisión de licencia que alguien tomó».
La construcción elimina los límites de memoria que una vez limitaron el lenguaje original. Una tabla que solía detenerse en dos gigabytes ahora puede superar ese punto y crecer hasta cientos de gigabytes. Esta es una solución técnica, pero también es una solución práctica: si tenía datos que llegaban a ese límite, ahora tiene una forma de trabajar con ellos una vez más.
El Intercambio )
Abrir una tabla que ha superado los dos gigabytes ya no es posible en Visual FoxPro. Cualquiera que todavía esté trabajando en ambos se encontrará bloqueado, sin posibilidad de regresar.
Una pequeña concesión conduce al puente que conecta a los usuarios con bibliotecas antiguas. Abrir un archivo .fll de 32 bits directamente dentro de un proceso de 64 bits no funciona, lo que significa que la construcción inicia un pequeño proceso de 32 bits cuya única función es mantener su biblioteca. Este puente se compara con bibliotecas reales: la biblioteca de cifrado, FoxTools y las construidas a partir de los propios ejemplos de API de Microsoft, y funciona, aunque nunca existió antes.
El Veredicto )
Hace seis años, este lenguaje se puso en espera, y ahora funciona de nuevo sin necesidad de ser reescrito. La construcción mantiene lo que escribió en lugar de obligar a un nuevo comienzo, y elimina los límites de memoria que llevaron al original a su fin. Es el tipo de proyecto que te alegra que alguien se preocupara lo suficiente por mantener vivo un lenguaje.
No borra el pasado. Lo lee.
Material fuente: “Microsoft mató a FoxPro en 2007. De todos modos, aquí está FoxPro revivido», foxscript.org.
Recibe El Cuaderno.
Las mejores historias del día y cada veredicto nuevo, en español claro, en tu correo a las siete. Un correo al día, nada más.