Présentation

FoxDev Studio propose d’exécuter des projets Visual FoxPro 9 sans réécriture ni conversion. L’IDE ouvre directement les dossiers contenant formulaires, tables, classes, menus et rapports, en conservant les fichiers DBF, FPT et les bibliothèques .fll d’origine. Aucun processus de migration n’est déclenché ; le disque conserve exactement les mêmes structures que sous le runtime 32 bits.

Architecture et compatibilité

Le cœur du produit repose sur un compilateur Rust qui génère du bytecode exécuté par une machine virtuelle écrite en Rust puis compilée en WebAssembly. Cette VM reproduit le comportement du moteur VFP 9 en interrogeant le vrai Visual FoxPro et en alignant ses réponses, ce qui évite les écarts de spécification. Le rendu de l’interface utilise React : chaque contrôle est un nœud d’arbre vivant, ce qui permet de rafraîchir uniquement l’élément modifié au lieu de redessiner l’ensemble du formulaire. Le système de fibres assure que les appels bloquants (MESSAGEBOX, READ EVENTS, etc.) libèrent la pile et reprennent dès que la réponse est disponible, reproduisant ainsi le modèle d’exécution non bloquant de VFP.

SET LIBRARY TO fllhost.exe

Les bibliothèques 32 bits (.fll) sont chargées via un petit processus auxiliaire 32 bits lancé par la commande ci‑dessus. Le processus principal reste 64 bits, ce qui garantit la compatibilité avec les extensions existantes tout en profitant de la capacité d’adressage étendue.

Gestion des limites de fichiers

Visual FoxPro était limité à 2 GB par table (2 147 483 647 octets) à cause d’un offset signé 32 bits. FoxDev Studio passe à un offset 64 bits, autorisant jusqu’à 9 223 372 036 854 775 807 octets. En pratique, un fichier DBF de 130 octets par enregistrement peut atteindre 558 GB, et avec des enregistrements de 1 KB la capacité dépasse 4,4 TB, limité uniquement par le compteur d’enregistrements du header DBF. Cette extension ne modifie pas le format du fichier ; les applications VFP ne peuvent plus ouvrir les tables dépassant 2 GB, créant une porte à sens unique vers FoxDev.

Analyse des performances et contraintes

Le runtime connaît 1 722 éléments de la référence VFP 9, dont 1 534 sont validés par un test comparatif. Les éléments non supportés sont explicitement ignorés ou refusés, ce qui évite les comportements indéfinis. Le rendu React minimise le coût de rafraîchissement, surtout sur des écrans denses où la mise à jour d’un seul label est perceptible comme « instantanée ». La VM WebAssembly, bien que portable, introduit une couche d’interprétation qui peut ajouter une latence marginale par rapport à l’exécution native p‑code, mais le modèle de fibres compense en évitant les blocages de l’UI. Enfin, la dépendance à un processus 32 bits pour les .fll crée un point de synchronisation : les appels sont synchrones pour garantir la cohérence de l’état, mais ils imposent un léger overhead de commutation de contexte.