Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived

A new project aims to revive Microsoft’s long-dead FoxPro/Visual FoxPro ecosystem, sparking both nostalgia from developers who built entire businesses on it and skepticism about relying on AI‑generated “vibe coded” tooling. Commenters weigh whether it’s safer to keep legacy FoxPro apps running with minimal changes, migrate them to modern stacks, or use tools like this as a bridge, raising concerns about multiuser reliability, security holes in DBF/DBC file designs, and long‑term maintenance. The conversation broadens into how modern platforms and low‑code tools have failed to fully replace classic RAD environments like FoxPro, Access, Delphi, and VB for small bespoke business apps.

Nostalgia and historical context

  • Many commenters learned programming or did their first paid work in FoxPro/dBASE/FoxBase, often in the 80s–2000s.
  • It was widely used for small business apps (medical offices, telemarketing, real estate, insurance, libraries, martial arts studios, etc.).
  • People recall how quickly they could build CRUD apps, UIs, reports, and how transformative that was for non-technical businesses.
  • Several compare FoxPro-era tools to HyperCard or classic VB in terms of approachability and empowerment.

Why FoxPro and similar tools mattered

  • FoxPro combined database engine, SQL, language, IDE, form designer, and report writer in one integrated package.
  • It excelled at file-based, single-user or LAN-based business apps, with very low barrier to entry and high productivity.
  • A recurring theme: one person with domain knowledge and modest coding skills could build mission-critical systems.

Current FoxPro usage and migration pain

  • Some organizations still run large FoxPro codebases (hundreds of thousands of lines) powering substantial revenue.
  • DBF-based systems over network shares remain in production; people mention corruption, locking issues, and scaling limits.
  • Rewrites are often seen as high-risk and expensive; some are using AI-assisted rewrites to modern stacks.

Foxscript project and technical choices

  • This new project is framed as a 64‑bit Visual FoxPro-compatible runtime, using Rust and WASM, with Electron for the IDE.
  • Goals include removing 2GB table/memo limits, preserving existing FoxPro apps without source changes, and sharing the same VM across desktop and tests.
  • Author notes performance is less critical than I/O and UI; the original VFP was also an interpreter.

Security, architecture, and DBF/DBC issues

  • A major concern is FoxPro’s architectural model: database files are just shared files with no real permissions model.
  • DBC stored procedures are plain text and can execute arbitrary FoxPro/Win32 code; anyone with file write access can alter behavior, bypassing app logic.
  • Some argue this is a fundamental one-tier, client-side design choice rather than a “bug”; still, others label it an “insecure design” or serious footgun.
  • Suggestions include moving to real client/server DBs (SQL Server, Postgres) or layering integrity checks into new runtimes.

Debate over AI “vibe-coded” projects

  • Many feel the project website and some comments “sound AI-generated” and find the style off‑putting or over‑hyped.
  • Concerns include: polished marketing for very young projects, unclear failure modes, and trustworthiness for critical data.
  • Others counter that AI assistance doesn’t necessarily invalidate the code, but agree that audits, history, and testing matter.

RAD tools and modern equivalents

  • Extensive side discussion on the decline of desktop RAD (FoxPro, VB6, Delphi, Access) versus today’s web stacks and low‑code tools.
  • Some lament there’s still no true cross-platform equivalent of Access/FoxPro for non-developers, though alternatives like FileMaker, Lazarus, Gambas, Kivy, Power Apps, etc. are mentioned.
  • Tension highlighted between simple, single‑dev tools and modern expectations: CI/CD, version control, security, multi-user web access, and cross‑platform GUIs.