CA-Visual Objects 2.0

CA-Visual Objects 2.0 was the 32-bit release of Visual Objects (VO), which Computer Associates published as the successor to Clipper. Clipper was the dBase-derived compiler that many DOS business applications were written in. VO kept Clipper’s xBase language but added classes, optional strong typing and a native-code compiler. It stored programs in a repository rather than in source files, and it targeted Windows. Version 1.0 shipped as a 16-bit product at the end of 1994, and 2.0 moved it to Windows 95 and NT 4.0 in March 1997. After a slow start, VO kept a committed developer community for another twenty years. Its dialect still exists today through Vulcan.NET and the open-source X# compiler.

History and origins

Aspen, at Nantucket

Nantucket Corporation’s Clipper started out as a compiler for dBase III programs. By the early 1990s its customers wanted a Windows product. Nantucket’s answer was a research project code-named Aspen. In his October 1995 Dr. Dobb’s article, Rod da Silva described it as a plan for “a completely object-oriented, repository-based, cross-platform application-development environment”, based on “a strongly typed, object-oriented version of the Clipper language”.

Aspen had not shipped when Computer Associates bought Nantucket at the beginning of May 1992. Computer Business Review reported that month that the sale came sooner than Nantucket had expected. The company had planned to release its Windows products first. At the time, Aspen’s core architecture was said to be “pretty much finished”. CBR also said Aspen “will not be compatible with Clipper but will share syntax for the classes”.

Visual Objects 1.0

CA took more than two years to finish the product. CA-Visual Objects 1.0, a 16-bit Windows application, shipped around the end of 1994. A 1999 version list from the Clipper community gives December 1994, and Computer Business Review reported it shipping on 11 January 1995, priced from $900. English Wikipedia and the X# project’s history both say the first release was not ready for market. The X# account calls it “very buggy and unstable” and says “many of the Clipper users were lost”. A string of patches followed (1.0a through 1.0d). Delphi, Borland’s competing product, shipped in February 1995, soon after VO.

Version 2.0: going 32-bit

CA launched CA-Visual Objects 2.0 in March 1997. Computer Business Review covered it on 14 March and called it “a catch-up tactic”. CA said 2.0 had taken “nearly a year to develop”. It ran on Windows 95 and Windows NT 4.0 and came with libraries for GUI programming, OLE and database management. It also added support for Win32 common controls and long filenames, plus an undo/redo command in the editor that users had long asked for. CBR noted that the 32-bit support was “very late compared with competitive products from Microsoft, Powersoft and Borland”.

There were two editions:

A Software Development Kit followed separately. Community version lists record later 2.0 builds and patches such as “2.0b3”. The 2.0 upgrade prices that CA quoted in 1999 confirm that both editions were sold.

Design philosophy

VO tried to keep the huge body of existing xBase code while giving Windows developers the tools of a compiled, object-oriented language. Three design choices follow from that.

• Compatibility first, strictness optional. Old-style code with undeclared variables still compiled. Developers could then add types module by module where speed mattered. Da Silva wrote that legacy code “can be ported (often without change)”.
• Native code, not p-code. Clipper compiled to p-code for a runtime interpreter. VO compiled to native machine code, and it ran fully typed code with less overhead.
• A repository instead of files. Code was stored as separate entities (functions, classes, methods, defines and globals) in a repository called “Adam”. The IDE tracked dependencies between these entities rather than between files.

Key features

Optional strong typing over a dynamic core

An untyped variable in VO is a USUAL, a polymorphic value that can change type whenever something new is assigned to it. VO also offers C-like types (BYTE, WORD, DWORD, SHORTINT, INT, LONG, FLOAT, REAL4, REAL8, PTR, PSZ, STRING, LOGIC, ARRAY, OBJECT and C-style STRUCTUREs) plus class types. Here is the same function written both ways, taken from Dr. Dobb’s (October 1995):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

// Classic xBase: a lexically scoped but polymorphic variable
FUNCTION SomeUDF
   LOCAL nX, cY
   nX := 4
   ? nX
   cY := "Hello"
   ? cY
RETURN NIL

// VO strong typing: the compiler resolves and type-checks these
FUNCTION SomeUDF AS VOID
   LOCAL wX AS WORD
   LOCAL cY := "Hello" AS STRING
   wX := 4
   ? wX
   ? cY
RETURN

The compiler also had a type-inferencing switch. It worked out a type for an untyped variable from how the variable was used, such as a loop counter being treated as a WORD or LONG, and generated native code for it. Memory for strings, arrays and objects was managed automatically by a garbage collector. VO had no new/delete or malloc/free.

Calling conventions and the Windows API

VO supported four calling conventions: STRICT (C-style), PASCAL, CALLBACK and its own CLIPPER. A CLIPPER function receives its arguments as untyped USUALs on a separate evaluation stack. That is what lets callers leave out arguments or pass a different number of them, as in Clipper:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

ShowMessage()
ShowMessage(,,"A message at the default location")
ShowMessage(100,100)

FUNCTION ShowMessage( nXCoord, nYCoord, cMessage ) CLIPPER
  IF IsNil( nXCoord )
     nXCoord := 0
  ENDIF
  IF IsNil( nYCoord )
     nYCoord := 620
  ENDIF
  IF IsNil( cMessage )
     cMessage := "One Moment Please..."
  ENDIF
  // Code to display message goes here...

VO shipped the Windows API prototypes as a precompiled library, so programs could call Windows directly without header files:

1

_DLL FUNCTION UpdateWindow( hWnd AS WORD ) AS VOID PASCAL:USER.UPDATEWINDOW

VO could build two kinds of DLL. A “VO-only” DLL could contain anything but could be loaded only by VO applications. A “foreign-hosted” DLL was a conventional Windows DLL that other languages could call, but it could export only strongly typed STRICT, PASCAL or CALLBACK functions.

Classes, messages and ACCESS/ASSIGN

VO classes have instance variables at three visibility levels: EXPORT, PROTECT and HIDDEN. Methods are not declared inside the class. Each method is a separate repository entity that names its own class with a CLASS clause. As a result, a developer could add a method to a class, including a framework class like Window, without touching that class’s source. Objects are created with {} and messages are sent with :. The example below is modelled on the examples in the 1995 Dr. Dobb’s article:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

CLASS Account
   EXPORT  cOwner AS STRING
   PROTECT nBalance := 0 AS FLOAT

METHOD Init( cName ) CLASS Account
   cOwner := cName
   RETURN SELF

METHOD Deposit( nAmount ) CLASS Account
   nBalance := nBalance + nAmount
   RETURN SELF

ACCESS Balance CLASS Account
   RETURN nBalance

CLASS SavingsAccount INHERIT Account

FUNCTION Start
   LOCAL oAcct AS Account
   oAcct := SavingsAccount{ "Ada" }   // a subclass may be assigned to its parent type
   oAcct:Deposit( 100 )
   ? oAcct:cOwner, oAcct:Balance

Init() plays the part of a constructor, and arguments placed inside the braces are passed to it. ACCESS and ASSIGN methods look like instance variables to the caller but run code, so a class can hide its state without forcing callers to use get/set methods. As of 1995, methods were always late-bound and all methods were public. Da Silva timed “one million method invocations on an object in just over two seconds” on a Pentium 90. That was an informal measurement by the article’s author on VO 1.x, with nothing to compare it against. The same article lists what VO 1.x lacked: multiple inheritance, compiler-enforced abstract classes, const declarations and typed pointers.

Data access

VO inherited Clipper’s Replaceable Database Drivers (RDDs), so one program could read and write DBF files with NTX, CDX or MDX indexes. For SQL it used ODBC. Both kinds of data were reached through the same server classes (such as DBServer and the SQL classes), so the same code could work with either. VO also kept Clipper’s procedural commands such as SKIP and EOF().

Evolution

Version 2.5 came about partly because CA-VO user groups lobbied CA to keep investing in the product, according to Greg Holmes’s 1999 announcement page. In April 2002 CA handed design, development, testing and marketing to GrafX Software of West Palm Beach, Florida, under a licensing agreement. The CA logo stayed on the box. GrafX’s president, Brian Feldman, had helped develop the database drivers in both Clipper and VO. He said the deal would “continue CA-Visual Objects (CA-VO) as a viable and robust 32 bit development environment”. According to GrafX’s 2.7 page, the move from Visual C++ 5.0 to 7.1, begun in July 2002, turned up “tens of thousands of errors” in the C code, which took about seven months to fix.

Current relevance

The Visual Objects product is finished. GrafX called 2.8 SP4 “the last version that GrafX will produce” and closed on 31 December 2017. GrafX had built Vulcan.NET from 2005 to bring the VO language to .NET. When that product faded, four of its developers built X#, an open-source compiler based on Microsoft’s Roslyn. X#’s own history says that “since the current developers came from VO, the VO dialect is the most advanced dialect”. X# 3 reached general availability on 23 June 2026, so VO-dialect code can still be compiled today, although the original Win32 IDE and runtime are no longer sold or maintained. That is why the encyclopedia lists VO as historical even though its language is still in use.

Why it matters

Visual Objects was the xBase world’s best-known attempt to move a large procedural DOS community onto Windows and object orientation without making it throw away its code. Optional typing on top of a dynamic core, native compilation of formerly interpreted xBase, and an entity-level repository in place of make files were all unusual for a mid-1990s database tool. Its weak start and late move to 32 bits, as contemporary reviewers pointed out, left it behind rival Windows tools. Still, the users who stayed kept the language alive through two changes of owner and two re-implementations. It is one of the longer-lived dialects in the dBase family.