Vulcan.NET

Vulcan.NET was a commercial compiler that took the xBase language as Clipper and Visual Objects had left it - ? for output, USUAL for “whatever type this turns out to be”, DBFCDX for storage - and made it emit Microsoft .NET assemblies. It was sold by GrafX Software of West Palm Beach, Florida, from 2005 to 2017, first as a subscription perk and then as a boxed product. Its purpose was narrow and explicit: give the installed base of Visual Objects business applications a route onto the CLR without a rewrite. It is dormant now, but it did not simply fade. Its own development team left, rebuilt the compiler as open source, and the two sides have published contradictory accounts of why.

The problem it was built to solve

The xBase family runs backwards from dBase III through Clipper - Nantucket’s compiler for the dBase language - to Computer Associates’ Visual Objects, which CA arrived at by buying Nantucket outright and finishing Project Aspen, the Windows successor to Clipper. Visual Objects was a 32-bit, object-oriented, strongly typed evolution of Clipper with its own repository-based IDE, and by the early 2000s CA had lost interest in it and put it in maintenance mode.

GrafX Software - by the X# team’s later account the largest Clipper and Visual Objects reseller in the world - took over development and sales in 2002, under what was reported as an April 2002 licensing, marketing and development agreement rather than a purchase: the copyrights stayed with CA. That left its customers - shops with a decade or two of working business code in VO - facing a platform with no future while the rest of the Windows world moved to .NET. The owner of GrafX, Brian Feldman, started a second product to answer that: a compiler that spoke Visual Objects and produced managed code. Don Caton wrote the first version; over the years Paul Piko, Robert van der Hulst, Chris Pyrgas, Nikos Kokkalis and Fabrice Foray joined the team.

The September 2005 product site put the pitch plainly:

For the last twenty years, businesses have relied on custom software solutions written in high level languages like Clipper, FoxPro, xBase++ and Visual Objects. These custom applications have been the backbone of many businesses who are now faced with moving to the world of Microsoft.NET.

What shipped, and when

The chronology matters because the product’s reputation was shaped by it. Vulcan.NET appeared on the GrafX homepage between 8 and 13 June 2005, already “available through a Platinum Subscription VOPS” and “targeted to ship by the end of 2005”. By June 2006 the same page had moved the target to “spring/summer 2006”; in the newsgroup that month Feldman said shipping would happen “about the time of the German Conference in November of 2006”. A pre-release finally arrived on 31 July 2007 and version 1.0 in November/December 2007 - roughly two and a half years of selling a subscription against a product that had not shipped.

The VO Platinum Subscription was the mechanism that made this possible. A subscriber got regular drops of both Visual Objects 2.8 and Vulcan.NET as they were built, plus support through the GrafX news server; Feldman put the subscriber count at over 250 in mid-2006. It funded development, and it also meant the people paying for the compiler were watching every build.

Version 1.0 landed badly with the subscribers who had waited for it. Erik Visser, a VOPS member, posted a detailed complaint to comp.lang.clipper.visual-objects on 13 November 2007: no IntelliSense, no refactoring, no databinding, no way to edit a transported Visual Objects form anywhere but back in Visual Objects, no interface inheritance, and none of the third-party libraries - Report Pro, bBrowser, VO2ADO - that any real VO application depended on. Most of those gaps closed over the following years; the third-party ones closed because third parties closed them, bBrowser.NET arriving in September 2008.

The language

Vulcan.NET is Visual Objects syntax on the CLR. The vendor’s own statement of scope was that “to the extent that is both possible and practical, Vulcan.NET is syntactically and semantically compatible with Visual Objects version 2.8”, and that unless stated otherwise a programmer should assume any given language element behaves the same in both.

The entry point looks like nothing else on .NET:

FUNCTION Start AS VOID
   ? "Hello World"
   RETURN

? is the Clipper output operator, AS VOID is the VO type-declaration syntax, and Start is the VO convention for a program’s entry point. The runtime library carried the whole Clipper function vocabulary across intact:

LOCAL nNumber AS FLOAT

// Picture-clause formatting, straight from Clipper
? Transform( 123.45, "@B 99999.99" )
? Transform( -123.45, "@X 99999.99" )

// Date and time helpers
? ElapTime( "03:02:01", "09:09:09" )    // 06:07:08
? Today(), DToS( Today() ), CDoW( Today() )

// Fixed-width string conversion
nNumber := 123.45
? Str( nNumber * 10, 7, 2 )             // 1234.50

// Insert, replace and delete in one function
? Stuff( "ABCDEF", 2, 0, "xyz" )        // AxyzBCDEF
? Stuff( "ABCDEF", 2, 3, "xyz" )        // AxyzEF

Alongside that sits a genuine .NET type system. The vendor described the compiler as “fully CLS compliant”, supporting method and operator overloading, strongly typed arrays, reference and value types, enumeration types and low-level pointer operations. Code could be written in the strongly typed style or fall back on the USUAL dynamic type that Clipper programmers expected. The compiler itself was, per the vendor, “all new and built from the ground up in Microsoft C++”.

The compatibility switches

The most revealing part of the design is a numbered family of compiler options - the 2008 release notes mention /vo2, /vo8 and /vo7 through /vo12 - each one re-enabling a specific Visual Objects behaviour that is wrong by any modern standard. The notes describe them with unusual candour. /vo9 allows missing return statements. /vo10 restores VO’s handling of IIF() when the true and false expressions have different types. /vo11 supports what the notes call “VO’s pathological behavior with arithmetic conversions”, pointing readers at the help topic “for the gruesome details”. /vo12 reproduces Clipper-compatible integer division. /vo7 re-permits the @ operator as a way of passing by reference.

The advice attached to each is the same: if your code came through the Transporter, turn the switch on to avoid subtle runtime incompatibilities; if you are writing new code, do not. From 1.1.152 #pragma options let /vo7 and /vo12 be set around a block of code, so a file could be migrated incrementally. This is what a migration compiler actually looks like - not a clean language, but a dial marked “how much of 1993 do you still need”.

Data and deployment

VulcanDB was a class library for .DBF and .CDX files - the storage format of Clipper, FoxPro and Visual Objects - written as 100% managed code, with a DBFNTX driver for the older Clipper index format as well. The vendor’s stated reason for the pure-managed implementation was that it could then run on devices using the .NET Compact Framework. GrafX also published a screenshot page showing a console and a GUI application running under Mono, with the claim “Vulcan.NET can be run on Linux with Mono”. Both of those are vendor claims and neither was backed by a supported-platform statement; Windows and the Microsoft .NET Framework are the only targets documented in any depth.

From 1.1.152 onward the runtime shipped as VulcanRedist.msi, installing the Vulcan assemblies, the VO-compatible class libraries and the C++ runtime into the GAC. That runtime is the object at the centre of the dispute that ended the product.

How it ended

By 2015 the development team had lost confidence in the way the products were being run. The X# account is that Robert van der Hulst had already left, that Nikos Kokkalis, Fabrice Foray and Chris Pyrgas were about to, and that they approached Feldman to buy what was left of Vulcan and offered him a share of revenue - and that the deal collapsed shortly after they asked for proof of source ownership and of the sales figures. Microsoft had open-sourced the C# and VB.NET compilers as Project Roslyn, and the four built a new xBase compiler on top of it. Their motto, as Wolfgang Riedmann’s history of the project puts it, was “we did it before, we can do it again”. The earliest public X# commit is dated 31 December 2015.

X# quickly passed Vulcan.NET. It understood Vulcan syntax, so existing code moved across, and it added generics, LINQ and AnyCPU builds, none of which Vulcan ever supported - and, by the new team’s account, it ended up more Visual Objects compatible than Vulcan had been. It could also be pointed at the Vulcan runtime assemblies for compatibility, which is where the trouble started: X# told its customers they could use their licensed Vulcan runtime with the new compiler.

GrafX Database Systems closed on 31 December 2017. The notice left on the site read, spelling and all:

Sadly, After 20 years, due to the theft of our intellectual property and it’s associated runtime), by an X-contractor, In the Netherlands, we have closed our Business “GrafX Database Systems Inc”.

The X# team answered on 24 March 2018, calling the accusation “a blatant lie”, arguing that using licensed Vulcan assemblies from another .NET language was something the Vulcan documentation itself described how to do, and noting that they had offered again, after the closure, to buy runtime source code and had not received a reply. Both accounts are public and they cannot both be right; this page records what each side published rather than adjudicating between them.

The practical consequence for users was that the only company selling Visual Objects, Vulcan.NET and the ReportPro report writer had vanished. X# picked up ReportPro sales and support for the community.

Why it matters

Vulcan.NET is a clean case study in the economics of a migration compiler. The market was defined and finite - every business still running a Visual Objects application - and it could only shrink. There was no path to new users, because nobody in 2010 was going to choose xBase syntax for a greenfield project. GrafX funded the work by selling subscriptions to a product that did not exist yet, which worked for a while and corroded trust when the ship date moved three times.

The compiler itself was better than its commercial fate suggests. The /vo compatibility switches are an honest engineering answer to a genuinely hard problem: how do you compile a language whose semantics include a decade of accidents, onto a runtime that has opinions? The answer - make every accident an opt-in flag, scoped by #pragma, documented as a thing to remove - is the same answer later reached independently by projects migrating other legacy dialects.

Its most durable contribution is X#. The compiler that replaced it is open source, built on Roslyn, still under active development in 2026 - X# 3 reached general availability in June 2026 - and supports the VO, Vulcan, Visual FoxPro, Xbase++ and Harbour dialects from a single codebase. The xBase code that Vulcan.NET was built to rescue is still running - just not on Vulcan.NET.