Mais de 5.400 empresas ao redor do mundo ainda rodam Visual FoxPro em produção. Sistemas de logística, ERPs inteiros, controle de estoque, folha de pagamento. Tudo isso funcionando num runtime 32-bit que a Microsoft abandonou oficialmente em 2007 e parou de dar suporte em 2015. Se você nunca ouviu falar de FoxPro, provavelmente é porque ele faz parte daquela categoria de software que “funciona e ninguém encosta”. Até parar de funcionar.

A boa notícia? Alguém decidiu que FoxPro não merecia morrer. O projeto FoxDev Studio acabou de aparecer no Hacker News com uma proposta ambiciosa: uma IDE moderna, um runtime 64-bit escrito em Rust compilado para WebAssembly, e uma linguagem chamada FoxScript que mantém compatibilidade total com o Visual FoxPro 9 enquanto adiciona features de 2026.

A história de como o FoxPro dominou (e foi abandonado)

FoxPro nasceu nos anos 80 como FoxBASE, um sistema de gerenciamento de banco de dados relacional criado pela Fox Software. Era rápido. Absurdamente rápido pra época. Enquanto o dBASE tropeçava em performance, o FoxPro processava tabelas como se fossem nada. Em 1992, a Microsoft comprou a Fox Software e transformou o produto no Visual FoxPro, adicionando uma IDE visual, orientação a objetos e integração com o ecossistema Windows.

Durante os anos 90 e início dos 2000, Visual FoxPro era a ferramenta para desenvolvimento rápido de aplicações de banco de dados. Pequenas e médias empresas construíam sistemas inteiros nele: ERPs, controle de estoque, sistemas de ponto de venda, gerenciamento de clínicas. A linguagem era acessível, o desenvolvimento era rápido, e os arquivos .dbf eram portáveis e simples de entender.

Aí veio o .NET.

A Microsoft decidiu que o futuro era C#, ASP.NET e SQL Server. Visual FoxPro não se encaixava nessa visão. Em 2007, a empresa anunciou que não haveria Visual FoxPro 10. O produto estava morto. O suporte estendido durou até 2015, e depois disso, silêncio oficial.

Mas os sistemas não morreram junto.

5.400 empresas presas no tempo

Segundo dados da Enlyft, mais de 5.400 empresas ainda rodavam Visual FoxPro em 2025. A maioria são pequenas e médias empresas de serviços de TI, logística, escritórios de advocacia e indústria. O perfil é sempre parecido: uma empresa que construiu um sistema crítico em FoxPro nos anos 2000, o sistema funciona bem, ninguém quer gastar centenas de milhares de dólares para reescrever tudo em outra tecnologia, e o desenvolvedor original já se aposentou ou mudou de carreira.

O problema é que Visual FoxPro 9 compila para executáveis Win32 de 32 bits. Isso significa:

Migrar para outra tecnologia é caro e arriscado. Eu já vi projetos de migração de FoxPro que levaram anos e custaram mais do que o sistema original. A lógica de negócio nesses sistemas está embutida de formas que só quem escreveu entende (e às vezes nem quem escreveu).

FoxDev Studio: Rust, WebAssembly e um renascimento inesperado

É aqui que entra o FoxDev Studio. O projeto é open source (licença MIT), disponível no GitHub, e tem uma proposta clara: rodar seus projetos Visual FoxPro 9 existentes sem reescrita, sem conversão, sem etapa de exportação. Você abre o projeto e ele funciona.

A arquitetura é surpreendentemente moderna:

• IDE: Electron + React + Fluent UI. Visual familiar pra quem usava o VFP original, mas com uma interface que não parece ter saído de 2003.
• Compilador e VM: Escritos em Rust, compilados para WebAssembly. O bytecode interpreter tem 199 instruções documentadas.
• Host layer: Gerencia recursos externos como arquivos, diálogos, bibliotecas legadas, e sockets.

A escolha de Rust + WebAssembly é estratégica. WebAssembly roda em qualquer plataforma, o que significa que o FoxDev Studio funciona no Windows (x64), Linux (AppImage e .deb) e eventualmente pode expandir pra mais plataformas. Rust garante segurança de memória sem garbage collector, o que é perfeito pra um runtime que precisa ser previsível e estável.

O runtime 64-bit muda tudo

A limitação mais dolorosa do VFP original era o teto de 2GB por arquivo .dbf. Pra quem trabalha com tabelas pequenas, não era problema. Mas sistemas que acumulam dados há 20 anos facilmente ultrapassam esse limite.

O FoxDev Studio usa offsets 64-bit em todo o sistema de dados. Na prática, isso significa que aquele .dbf que travava com 2GB agora pode crescer até 558GB sem problemas. A tabela nunca é lida inteiramente na memória: o runtime faz acesso direto ao disco com offsets de 64 bits.

* No VFP original, isso causava crash com tabelas grandes:
USE clientes
SCAN
    ? clientes.nome
ENDSCAN

* No FoxDev Studio, o mesmo código funciona com tabelas de centenas de GB
* Sem modificação. Sem conversão. Sem recompilação.

Bridge para bibliotecas 32-bit

Uma jogada inteligente do projeto é o bridge de 32 bits. Muitos sistemas FoxPro dependem de bibliotecas .fll (FoxPro Library Files) que são binários 32-bit. O FoxDev Studio inclui um bridge que permite carregar essas bibliotecas legadas dentro do runtime 64-bit. Isso significa que você não precisa recompilar suas dependências externas.

FoxScript: FoxPro com features de 2026

FoxScript é a linguagem do FoxDev Studio. A regra número um é: “Tudo que você escreveu continua significando exatamente o que sempre significou.” FoxScript só adiciona por cima do Visual FoxPro 9. Nenhuma sintaxe existente foi alterada.

As adições principais são lambdas e um namespace moderno.

Lambdas (funções anônimas)

Visual FoxPro nunca teve funções de primeira classe. Você não podia passar uma função como argumento pra outra função. FoxScript resolve isso com LAMBDA e ENDLAMBDA:

LOCAL multiplicar
multiplicar = LAMBDA(x, y)
    RETURN x * y
ENDLAMBDA

? multiplicar(6, 7)  && Resultado: 42

VARTYPE() retorna "F" para valores do tipo função. Lambdas podem ser armazenadas em variáveis, elementos de array e propriedades de objetos:

LOCAL ARRAY rotas[3, 2]
rotas[1, 1] = "/api/users"
rotas[1, 2] = LAMBDA(req, res)
    res.Send(FoxScript.Json.Stringify(GetUsers()))
ENDLAMBDA

* Chamando a lambda diretamente do array:
rotas[1, 2](oRequest, oResponse)

Pra quem programa em JavaScript, Python ou qualquer linguagem moderna, isso parece básico. Mas pra uma linguagem de 1989, é uma evolução enorme que desbloqueia padrões de programação funcional que antes eram impossíveis.

O namespace FoxScript

O namespace FoxScript é um objeto global de leitura que dá acesso a funcionalidades modernas:

* Versão do runtime
? FoxScript.Version

* Servidor HTTP embutido
oServer = FoxScript.Http.CreateServer()

* JSON nativo
oData = FoxScript.Json.Parse('{"nome": "João", "idade": 30}')
? oData.nome  && "João"

* Converter cursor para JSON
cJson = FoxScript.Data.CursorToJson("clientes")

O tipo JSON (tipo "J") é nativo. Membros são acessados case-insensitive, e elementos por subscript (base 1, como o FoxPro sempre fez):

oData = FoxScript.Json.Parse('[{"id": 1}, {"id": 2}]')
? oData[1].id  && 1

Servidor HTTP embutido

Isso é provavelmente a feature mais impactante. Com FoxScript.Http.CreateServer(), você transforma um aplicativo FoxPro em uma API REST. A implementação usa Node.js por baixo pra gerenciar sockets, mas a lógica de roteamento e resposta fica toda em FoxScript.

Imagine um sistema de estoque escrito em FoxPro nos anos 2000. Com algumas dezenas de linhas de código, ele agora pode expor uma API REST que qualquer frontend moderno consome. Sem reescrever o sistema. Sem middleware. Sem proxy reverso complexo.

oServer = FoxScript.Http.CreateServer()

oServer.Route("/api/produtos", LAMBDA(req, res)
    SELECT codigo, nome, preco FROM produtos INTO CURSOR cProdutos
    res.ContentType = "application/json"
    res.Send(FoxScript.Data.CursorToJson("cProdutos"))
ENDLAMBDA)

oServer.Listen(8080)
? "Servidor rodando na porta 8080"

A IDE que parece familiar (mas não é)

O FoxDev Studio recria a experiência do Visual FoxPro original com ferramentas modernas. O Form Designer tem toolbox, drag-and-resize, snap to grid. O Properties Window tem editores tipados. O editor de código usa CodeMirror com syntax highlighting. Tem Command Window, Output panel, e debugger.

Mas por baixo é tudo Electron + React + Fluent UI. Os arquivos de projeto usam um formato JSON próprio (.fxproject, .fxf, .fxm) que coexiste com os .prg originais.

O compilador cobre 1.722 elementos da referência da linguagem Visual FoxPro 9, com 1.534 deles testados contra o runtime original (vfp9.exe) para garantir paridade comportamental. A filosofia é explícita: “Onde o Visual FoxPro 9 tem uma resposta, a resposta do produto vence.”

Por que isso importa (mesmo se você nunca tocou em FoxPro)

A história do FoxPro é a história de todo software legado. Hoje é FoxPro. Amanhã pode ser o seu sistema em PHP 5, Java 8 ou Node.js 14. Toda tecnologia eventualmente perde suporte, e os sistemas construídos nela ficam presos no tempo.

O approach do FoxDev Studio é diferente do que a indústria normalmente recomenda. Em vez de “migre tudo para uma stack moderna”, a proposta é “mantenha o que funciona, mas num runtime que evolui”. É a mesma lógica que fez o TypeScript funcionar: não reescreva seu JavaScript, adicione tipos por cima. Não reescreva seu FoxPro, adicione lambdas e HTTP por cima.

Pra quem trabalha com modernização de sistemas legados, isso abre um caminho intermediário que raramente é considerado. Em vez de reescrever um sistema de 200 mil linhas de FoxPro em C# (projeto de anos, custo milionário, risco altíssimo), você pode:

1. Rodar o sistema existente no FoxDev Studio sem alterações
2. Expor APIs REST com FoxScript pra integrar com frontends modernos
3. Migrar gradualmente, módulo por módulo, se quiser

Esse approach de “envolver o legado” em vez de “substituir o legado” é muito mais pragmático do que a maioria dos consultores de TI admite.

WebAssembly como strategy de sobrevivência

A decisão de compilar a VM para WebAssembly merece atenção especial. WebAssembly é, na prática, uma máquina virtual universal. Código compilado para Wasm roda no browser, em runtimes server-side (Wasmtime, Wasmer), em edge computing (Cloudflare Workers, Fastly Compute), e em ambientes embarcados.

Hoje o FoxDev Studio roda em Windows e Linux. Mas a fundação em WebAssembly significa que portar para macOS, containers Docker, ou até mesmo para o browser (imagine um sistema FoxPro rodando inteiro numa aba do Chrome) é tecnicamente viável sem reescrever a VM.

Rust + WebAssembly também resolve o problema de distribuição. Em vez de depender de um runtime proprietário de 1998, o FoxDev Studio distribui um binário auto-contido que não precisa de dependências externas. No Linux, é um AppImage. No Windows, um executável x64. Simples.

Os números que importam

O elefante na sala: quem vai manter isso?

O repositório no GitHub tem 50 stars e 1 fork. Isso é, sendo honesto, pouco. O projeto é ambicioso e tecnicamente sólido, mas a comunidade FoxPro não é exatamente a mais barulhenta da internet. A maioria dos desenvolvedores FoxPro tem 50+ anos e não está no Twitter discutindo ferramentas open source.

Mas talvez esse seja justamente o público que precisa de algo assim. As 5.400+ empresas rodando FoxPro em produção não precisam de hype no GitHub. Precisam de um runtime que funcione, que rode em hardware moderno, e que não dependa de uma empresa que abandonou o produto há quase 20 anos.

O fato do projeto ser MIT e open source é crucial. Mesmo que o criador original abandone o desenvolvimento, qualquer pessoa pode dar fork e continuar. Isso é infinitamente melhor do que depender de um executável binário de 2007 que a Microsoft não vai atualizar nunca mais.

O que falta

Nem tudo são flores. Reports (relatórios) ainda estão em desenvolvimento, e isso é uma feature que muitos sistemas FoxPro usam pesadamente. A documentação, embora detalhada, ainda está crescendo. E a compatibilidade com macOS, embora tecnicamente viável pela arquitetura WebAssembly, ainda não existe oficialmente.

Também falta validação em grande escala. Um sistema FoxPro com 200 mil linhas que funciona perfeitamente no vfp9.exe pode ter edge cases que o novo runtime ainda não cobre. Os 1.534 testes contra o runtime original são impressionantes, mas a linguagem tem nuances que só aparecem em código de produção real.

Quem está pensando em adotar o FoxDev Studio para um sistema crítico deveria começar rodando a suíte de testes do próprio sistema no novo runtime antes de qualquer migração de produção.

Como testar

O FoxDev Studio está disponível para download gratuito:

# Linux (AppImage)
chmod +x FoxDevStudio-*.AppImage
./FoxDevStudio-*.AppImage

# Linux (Debian/Ubuntu)
sudo dpkg -i foxdevstudio_*.deb

# Windows
# Baixe o instalador .exe do GitHub Releases

O código fonte completo está no GitHub sob licença MIT. Pra quem quer contribuir, o projeto é TypeScript (IDE) + Rust (compilador/VM), então desenvolvedores modernos podem contribuir sem saber FoxPro.

Se você conhece alguém que mantém um sistema FoxPro, manda esse artigo. Pode ser a diferença entre um sistema preso em 2007 e um sistema que ganha mais 20 anos de vida.

Fonte de inspiração: FoxDev Studio via Hacker News