XVT DSC
Volume Number: 12
Issue Number: 9
Column Tag: Tools Of The Trade
XVT DSC++ 
Cross-platform compatibility, but at a cost
By Edward Ringel
Development, Money, and Reality
As most of us are painfully aware, the Mac OS does not exactly hold a dominant share of
the market in personal computers. Therefore, just as a matter of simple economics,
anyone who wants to make high-end profits selling software needs to support more
than just the Macintosh platform. Furthermore, corporate MIS gurus prefer that
users, if they must employ various platforms, should still not only use the same apps
but also see similar interfaces - rightly, since this reduces training and support costs.
It’s hard, though, for one person to write commercial-quality native code for
multiple platforms; and it’s expensive to have multiple talented programmers for
multiple platforms. Consequently, the freelancer with the killer app and the in-house
or contract programmer facing a deadline seek the same Holy Grail - write the code
once, put it through a bunch of different compilers, come out with applications that
work the same way on a variety of platforms, yet preserve the native look and feel of
each host platform.
The challenge of making this possible is taken up by XVT Software, Inc., of
Boulder, Colorado (www.xvt.com). The resulting product, DSC++ (Development
Solution for C++) is a rich environment, but one that may not prove to be the right
answer for every developer.
Some Preliminaries
This is an expensive and complex product, and I wanted to evaluate it from within a
clearly defined mindset, partly to introduce order, and partly because my comments
might influence others’ purchase or evaluation decisions. Accordingly, I played the
role of an experienced Macintosh procedural programmer, ready to migrate to C++ and
a framework. I imagined that I had a contract that would ultimately need porting to a
second or even third platform, and that therefore I would need a cross-platform tool; I
was evaluating DSC++ with intent to purchase.
The depth, breadth, and expense of the product are such that, if purchased,
DSC++ would be a core development tool; the expertise, diligence, and policies of XVT
Software, Inc., would have a significant impact on your development efforts.
Accordingly, this review addresses not only the class library and framework, but the
other elements of the package: a C function library that implements a significant
portion of the cross-platform compatibility, a universal resource descriptor system,
and application construction tools. I also report on my interactions with technical and
customer support. I believe that all of this information is critical to being able to
make a purchase decision in this rapidly changing area of application development.
Out of the Box
I reviewed DSC++ version 3.22.01 for a 68K Macintosh. The product was installed on
a Performa 6200CD, and CodeWarrior 8 was used for builds and perusal of code. The
carton weighed fourteen pounds, and contained several books, a few papers, and 7 HD
disks. Review of the books is a good place to start, as the printed materials reflect the
components of the system:
Tools.h++ Introduction and Reference Manual. Instructions for the use of Tools.h++,
a collection of useful foundation classes for data management and manipulation.
Used throughout the C++ product.
Guide to XVT Development Solution for C. Guide to the C function underpinnings of the
C++ framework and library and the resource language.
Guide to XVT Development Solution for C++. This is the guide to the C++ application
framework and the class library.
XVT Portability Toolkit Reference. Comprehensive reference to the function library
common to all XVT products.
XVT Power++ Reference. In-depth reference to the class library for DSC++.
XVT Architect Manual. Manual about and tutorial for XVT Architect, the application
construction tool for XVT Power++.
XVT Platform-Specific Book for Macintosh and Power Macintosh. Some specifics
regarding implementation of XVT products on a Mac OS platform.
XVT Development Solution for C++ Quick Reference; XVT Development Solution for C
Quick Reference. Two small books that prototype classes, structs, enums and
functions.
The published materials are of the highest quality. They are visually pleasing,
physically well manufactured, and very well written. The writers use a consistent,
clear, systematic approach to describing functions, classes and functionality. It was
very easy to find and learn about material that I wanted to study. In particular, Rogue
Wave’s Tools.h++ manual is among the best pieces of technical writing that I have
encountered. The sole exception is the XVT Architect Manual, which was not quite as
clear and not at the same depth. Additionally, some of the tutorial code in the XVT
Architect Manual did not match exactly that generated by the XVT Architect. However, I
could still follow along pretty easily.
Installation of DSC++ was a disappointment, and the first indication that I would
be dealing with a product that did not follow the Macintosh Way. The environment
comes as a seven-disk Compact Pro self-extracting archive. After performing the
extraction, I looked somewhat unhappily through the various folders with their
cryptic, UNIX-type designations (pwr, ptk, shell, bin, for instance.) One could argue
that retaining this naming convention is a constraint imposed by the cross-platform
compatibility requirements, but obviously it defeats one of the nicest features of the
Mac OS. I then spent ten minutes sifting through these folders, pulling out several
megabytes-worth of Symantec and MPW files unrelated to my CodeWarrior
environment. Compact Pro is not an appropriate installer for a complex multi-option
installation. (As implied, XVT DSC++ will support CodeWarrior, Symantec, and MPW
IDEs. Support for Symantec THINK products was dropped as of March, 1996.)
Content and Structure
My next task was to correlate documentation with files, and to try to develop some
mental apprehension of how the pieces fit together (I had to “get it”). The excellent
documentation made this fairly easy.
XVT Portability Toolkit
XVT makes two closely interrelated products, a cross-platform development
environment for C, and another for C++. Mac OS, Windows, Windows NT, Sun, and
other UNIX platforms (essentially any OS that has a GUI) are supported. XVT has a
collection of C functions, the XVT Portability Toolkit, that acts as a uniform interface
to the various native GUIs. Thus, to draw a rectangle in the current GrafPort with a
1-by-1 pixel pen, as we might on the Mac with this code:
Rect myRect;
SetRect(&myRect, 10,10,100,100);
PenNormal();
FrameRect(&myRect);
we write instead:
RCT myRCT;
/* RCT is a rectangle structure that is identical to a Rect */
xvt_dwin_set_std_cbrush(theWindow,TL_BRUSH_WHITE);
/* need to set the “brush” to paint the inside of the rectangle. theWindow is assumed to be previously
defined, and is a long. TL_BRUSH_WHITE is a macro that fills in the fields of a CBRUSH struct, which is
a descriptor of the painting environment. */
xvt_dwin_set_std_cpen(theWindow,TL_PEN_BLACK);
/* need to set the pen; TL_PEN_BLACK is a macro that fills in the fields of a CPEN struct */
xvt_rect_set(&myRCT,10,10,100,100);
/* same as the real thing */
xvt_dwin_draw_rect(theWindow,&myRCT);
/* ditto */
Functions use a uniform naming convention. An XVT call always starts with xvt_.
The next “word” specifies the general category; in this case it is drawing in a window,
dwin. The next word specifies the action, such as set or get or draw. Finally, if
appropriate, the last word or two indicates the actual object in question, such rect or
cpen. The function xvt_dwin_draw_rect, then, is virtually self-explanatory. Of
course, before I could even begin to use the product, there would be a whole series of
new macros and typedefs to learn. However, this is part of the price of admission to
any comprehensive class library and/or framework system. The ability to use the
same call with the appropriate result on a Mac, PC, or Sun workstation is obviously
the core of this product.
It is important to emphasize the word appropriate: the XVT Toolkit is a layer
which interacts with the native toolbox, so that a window on a Mac looks like a Mac
window, a scrollbar in Windows looks like a Windows scrollbar, and so on. This
permits the cross-platform application to meet the interface expectations of each
platform’s users. The Portability Toolkit covers a wide variety of operations, though
still just a subset of the Macintosh feature set. Features pertaining to the application,
clipboard, controls, drawing, windows, dialogs, fonts, texts, images, errors, memory,
iostreams, lists, printing, rectangle utilities, and cursors are all supported.
Of course, there may be an efficiency hit. Since all I had are binary libraries I
don’t know for certain, but I suspect (given the theWindow parameter in
xvt_dwin_draw_rect) that the implementation contains code that on a Mac either
every drawing call. Normally, I can SetPort() when I want to, and just do high-speed
The dynamic throughout is thus one of well documented, well thought out
functions that might well be less efficient than native Toolbox calls. (The XVT
Portability Toolkit does not exclude the use of native calls. It is possible to extract
intercept the event loop and process a raw event. However, once you make the code
platform-dependent, it is obviously no longer 100% portable.) And, of course, these
functions weren’t what I was used to. Facile use will require an extensive
re-education of the programmer. The prospective purchaser must balance the
drawbacks of all this against the problems of supporting multiple platforms using
multiple native development environments: this is the crux of the purchase decision.
URL and Curl
GUI calls in the absence of some description of the interface make for a
cumbersome programming task. The Macintosh concept of resources is appealing, and
XVT uses a Universal Resource Language (URL) to describe the GUI components. This
resource language is cross-platform portable. In each development scenario, the
interface description is translated into the appropriate platform-specific resource
descriptor. On the Mac, a URL file is turned into an .r file by curl, an MPW tool
which I ran under ToolServer. I then used MPW Rez, still under ToolServer, to create
my resource file. There is also a freestanding app, called curl.app, but scripting and
the CW environment made curl much easier to use. curl.app was very slow, had a poor
interface, and was not user-friendly. (As an example, in order to set access paths for
#include files for this program, I needed to type full path names into a
specially-named text file.)
The resources described are, again, a subset of the Mac feature set. Window,
control, dialog, string, picture, menu, and icon formats form the basic kernel of
interface development. URL resources can be created by text coding as with Rez, or by
drawing with the XVT Architect application, discussed below. (The companion C
product has an application for drawing the interface as well.)
XVT Power++
XVT Power++ is the class library and application framework produced by XVT.
The class library and framework have similarities to and differences from the “big
three” on the Mac scene (MacApp, TCL, and PowerPlant). The biggest difference, of
course, is the absence of reliance on native Mac calls for execution of each method.
Instead, a combination of native Macintosh calls (in the binary libraries), C++
methods designed specifically for DSC++, and XVT Portability Toolkit C calls are used
for implementation of the functions. Because of this structure, there is often an extra
calling layer between C++ and the Macintosh Toolbox.
The general organization of the framework is that of the model-view-controller
popularized by Smalltalk. Each application has a single application object which is at
the apex of the hierarchy. This object is responsible for opening and closing
documents, initializing the application, and the like. The application object has
methods for doing saves, changing fonts, etc., which to my recollection is somewhat
different from other frameworks on the Mac. Inheritance is generally single (like
MacApp), rather than multiple (like PowerPlant). There are a lot of pros and cons to
this approach, and while multiple inheritance is elegant and parsimonious, single
inheritance is clearer and easier to learn. I think particularly for a cross-platform
product, single inheritance is a safer, more appropriate approach.
The application creates a document, which controls the data seen both within a
view and in a file. XVT’s document diverges from TCL and PowerPlant documents in the
ability to incorporate Automatic Data Propagation (ADP) into applications. This
feature allows changes in data shared among views to be automatically propagated;
when operations in one view change data, the change is reflected in the linked views