mcconnell@dssdev.dec.com (John 'Flash' McConnell ZKO2-3/R56 381-2285) (03/12/88)
Several people (Joseph Nathan Hall, Jim Saint, Darin Johnson,... )
have written in about GKS recently. As vice-chair of ANSI X3H3 and
one of the original developers of VAX GKS, I thought I could clarify
a few points.
>> I've been using GKS on a VAXstation GPX for almost a year now. The worst
>> niggling-type problem with GKS under VMS is that GKS is really designed to
>> run under FORTRAN (that's right) and so all the "C" calls are by reference
>> (uggh) and many of the string paramegers [sic] use descriptors (double uggh).
>
>Actually, this is more of a problem with VMS in general, not GKS.
>I haven't used GKS that much, but have used VMS quit a bit (been forced to use
>I should say). Programming is a breeze if you are using FORTRAN, but a
>pain in the butt for anything else. In particular, descriptors are
>done automatically in FORTRAN, but have to be built by hand in other
>languages. I would assume that descriptors are used with GKS in order
>to interface with FORTRAN better, not that GKS itself needs descriptors
>(I seriously doubt that any other OS has descriptors in the same format
>anyway). I haven't seen GKS on a UNIX machine, but a would suspect that
>the C interface has no descriptors or pass by reference parameters.
Well, not quite. The GKS standard is language independent. The
committees that developed GKS, ANSI X3H3 in the U.S. and ISO SC24
internationally, are developing separate standards, called bindings,
for using GKS with particular languages (FORTRAN, C, Pascal, Ada,
and even LISP). Each binding tries to offer the facilities of GKS
within the language, in a manner consistent with current programming
practice for that language.
When we wrote VAX GKS, we had a problem -- only the GKS/FORTRAN
binding was approved. So we provided two interfaces to VAX GKS: one
that conforms to the GKS/FORTRAN binding standard and another that
conforms to the VMS Inter-Language Calling Standard. The second
interface allows an application written in almost any VMS language
to use VAX GKS. The second interface also allows us to support each
additional language binding as it is approved, without rewriting VAX
GKS. All that is required is a thin shell that maps the standard
binding to the Inter-Language Calling Standard interface.
Ironically, VAX GKS is written in C. The reason Digital has decided
against offering a GKS/C binding so far is that this standard has
not been approved, and because the preliminary standard has been
unstable. The usual reason that programmers use a standard is
because of the stability and portability that a standard offers.
Providing a non-standard, unstable C binding would be a disservice
to our customers.
Rather than embedding descriptors and other VMS-isms into your
applications, I suggest defining a macro file for inclusion with
your application that handles this for you, for example:
#define close_ws( wsid )\
gks$close_ws( &wsid );
Then, when the GKS/C binding is finally available, you can modify
the include file, without having to recode your application.
>> Aside from that, GKS is basically bloated, illogical and inefficient and I
>> can't understand why anyone would want to use GKS on a Mac instead of
>> QuickDraw.
Comparing GKS with QuickDraw is like comparing apples (tm?) and
oranges. As I pointed out above, the main reason programmers use GKS
is for stability and portability. GKS implementations exist for
everything from CRAY's to 8080's (but not 8008's as far as I know :-))
and from E&S high-performance workstations to Tektronix 4010
storage tubes. GKS has many faults, but I don't know of a better way
to write portable applications.
I'd also like to say a word for the committee membership. GKS was
designed by a committee, and it shows, but that doesn't mean the
committee members are less intelligent or less in touch with the
state of the art. Quite the contrary -- it shows how difficult it
is to design a graphics system in a committee. I've studied and
worked in several organizations with high-powered reputations, but I
have never worked with such a concentration of intelligent,
cultured, professionals as on the committee.
If anybody would like to see whether they can do a better job, they
should contact me about joining X3H3. We have several new projects
underway; including ones on X11, Image Processing, PHIGS+ and GKS-9X.
John McConnell [+1] (603) 881-2285
Digital Equipment Corp. mcconnell@dssdev.dec.com
110 Spit Brook Road
Nashua, NH 03063
ZKO2-3/R56